Hacking possibility? Real or not?

[Jim Dantin]

Mike Frysinger and other Chromium OS experts -

This rather one-sided Microsoft video brings up some interesting claims. I'll ignore the claim that Windows is more secure, but I wonder about what really is possible with ChromeOS devices.

https://www.youtube.com/watch?v=DJg-mI3tuaU

I'd like us to get ahead of any more fear mongering by having someone knowledgeable examine the actual threat. This appears to be the exploit:

https://samy.pl/poisontap/

For a protected mode ChromeOS device, what are the actual vulnerabilities and dangers? 

I expect that a logged in device could be exposed to data theft if the user (or someone else) plugged in a malicious device, but what about a locked-screen or logged out device?

For logged in, unlocked devices, what mischief could be done?

Anyone care to be a truth-teller here?

Thanks.

[Mike Frysinger]

yeah, that is hilariously disingenuous.  pretty sure the USB device they plug in emulates a USB keyboard & ethernet.  it then sends some keyboard presses to open a tab and go to a known website which then tries to access *http* (not https) sites which it then hijacks (since it reconfigured the networking).  the problem here is that CrOS *already* assumes that the network cannot be trusted.  there is 0 difference between someone plugging in a USB dongle they hacked together and connecting to public WiFi (at the airport, at a cafe, at a hotel, etc...).  CrOS doesn't trust any of them.  so you're left with the same question all the time: do you trust random websites that serve traffic over http ?  no ?  good, because they suck.

the fancy screen flashing you see in the video is just that -- someone wrote some JS to scare people who don't know what is happening.  might as well have put up your typical matrix screensaver and kicked off a hacker montage and dropped some thumpin beats.

when they talk about how Windows offers USB VID/PID filtering, they conveniently ignore the fact that whitelisting VID/PIDs for "good" devices isn't secure.  you can change the microcontroller to report any VID/PID you want and you're back to square one.  plus, the typical user here isn't going to open the management console and zzzzzzzzzzzz.  sorry, what were we talking about ?  g'luck explaining that to anyone.  "look up the VID/PID for every USB keyboard, mouse, ethernet dongle, thumb drive, etc... you care about, then go in here, and then type out those hex digits in this list by hand".  which means Windows and macOS and Linux and CrOS and every other platform is equally susceptible to insecure websites being abused when the network is hostile.

wrt enterprise management, there are knobs there: https://support.google.com/chrome/a/answer/1375678

i don't know at what level the USB VID/PID blacklisting operates at though ... i'd have to actually poke around or ask people.  if that blacklists lower down, then it'd be equiv to Windows.  if it only blacklists USB access for apps (i.e. what you can install from the CWS), then Windows would offer more restrictions here.

i love the closing remarks -- "don't forget to enable Windows update and keep your devices up to date!".  remind me the last time someone said that about CrOS ? ;)

-mike

--
--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

[Mike Frysinger]

to be clear/fair, if Windows offers MMC access on consumer devices to any local admin (and i think it does), then the ability to manage things on one-off systems is more powerful than an unenrolled Chromebook.  all of CrOS management aspects require the device to be enterprise enrolled and then managed through the Google Admin console.  there is no way afaik to manage policy files for your own personal devices (unless you set up an organization and do enrollment all for yourself).  the counter point is that, for the target consumer market, no one is actually doing any of this, making the Windows functionality moot.  in all my years of using Windows, i never once managed group policies for my personal systems, and i don't think i've ever met anyone who even knows what the MMC is outside of enterprise/IT shops.

-mike

[Jim Dantin]

Thanks Mike.

I suspect we'll be hearing a lot of "Chromebooks can be hacked" posts from the trolls.

[Matthias Apitz]

El día domingo, junio 18, 2017 a las 04:26:05p. m. -0700, Mike Frysinger escribió:

> yeah, that is hilariously disingenuous. pretty sure the USB device they
> plug in emulates a USB keyboard & ethernet. it then sends some keyboard
> presses to open a tab and go to a known website which then tries to access
> *http* (not https) sites which it then hijacks (since it reconfigured the
> networking). the problem here is that CrOS *already* assumes that the
> network cannot be trusted. there is 0 difference between someone plugging
> in a USB dongle they hacked together and connecting to public WiFi (at the
> airport, at a cafe, at a hotel, etc...). CrOS doesn't trust any of them.
> so you're left with the same question all the time: do you trust random
> websites that serve traffic over http ? no ? good, because they suck.
>
> the fancy screen flashing you see in the video is just that -- someone
> wrote some JS to scare people who don't know what is happening. might as
> well have put up your typical matrix screensaver and kicked off a hacker
> montage and dropped some thumpin beats.

Hi Mike,

Thanks for your explanation re/ the USB device and letting the CrOS
browser fetch some fancy JS(...) stuff from the crafted USB key. One
question remains: Can the JS software (or whatever the USB http server
offers to the browser) damage something in the CrOS and/or user files?

It is not the same when some user clicks on some HTTP URL, it is his/her
fault being stupid. But when a crafted USB key do so, it is just
another case, i.e. some sophisticated attack.

>
> when they talk about how Windows offers USB VID/PID filtering, they
> conveniently ignore the fact that whitelisting VID/PIDs for "good" devices
> isn't secure. you can change the microcontroller to report any VID/PID you

> ....

Fully agreed. USB VID/PID filtering as they say in the YT show, is
nonsense.

matthias

--
Matthias Apitz, ✉ gu...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdió la Guerra.
May 8, 1945: Who does not celebrate lost the War.

[Mattias Nissler]

On Mon, Jun 19, 2017 at 10:51 AM, Matthias Apitz <gu...@unixarea.de> wrote:

El día domingo, junio 18, 2017 a las 04:26:05p. m. -0700, Mike Frysinger escribió:

> yeah, that is hilariously disingenuous.  pretty sure the USB device they
> plug in emulates a USB keyboard & ethernet.  it then sends some keyboard
> presses to open a tab and go to a known website which then tries to access
> *http* (not https) sites which it then hijacks (since it reconfigured the
> networking).  the problem here is that CrOS *already* assumes that the
> network cannot be trusted.  there is 0 difference between someone plugging
> in a USB dongle they hacked together and connecting to public WiFi (at the
> airport, at a cafe, at a hotel, etc...).  CrOS doesn't trust any of them.
>  so you're left with the same question all the time: do you trust random
> websites that serve traffic over http ?  no ?  good, because they suck.
>
> the fancy screen flashing you see in the video is just that -- someone
> wrote some JS to scare people who don't know what is happening.  might as
> well have put up your typical matrix screensaver and kicked off a hacker
> montage and dropped some thumpin beats.

Hi Mike,

Thanks for your explanation re/ the USB device and letting the CrOS
browser fetch some fancy JS(...) stuff from the crafted USB key. One
question remains: Can the JS software (or whatever the USB http server
offers to the browser) damage something in the CrOS and/or user files?

The JS runs within the Chrome renderer sandbox, so it's tightly sandboxed and doesn't have access to the system or user files.

 

It is not the same when some user clicks on some HTTP URL, it is his/her
fault being stupid. But when a crafted USB key do so, it is just
another case, i.e. some sophisticated attack.

The USB key essentially just gives them the ability to open a tab and navigate the device to an HTTP URL. Note that this assumes that they either (1) trick the user into plugging the bad USB key or (2) assume the attacker gains access to the device while it isn't locked, or be able keep their USB device connected until after the user unlocks the device. #1 is somewhat plausible, #2 is physically difficult (not impossible), unlikely in practice. Either way, navigating to an HTTP URL would probably be pretty low on the list of things a serious adversary would consider ;-)

 

>
> when they talk about how Windows offers USB VID/PID filtering, they
> conveniently ignore the fact that whitelisting VID/PIDs for "good" devices
> isn't secure.  you can change the microcontroller to report any VID/PID you
> ....

Fully agreed. USB VID/PID filtering as they say in the YT show, is
nonsense.

There might be a case for disabling classes of devices, e.g. preventing all (external) HID devices from working. That would only make sense for devices with built-in keyboards of course, and only on corp-owned devices. Adding dskaram@ to consider adding that functionality to Chrome OS device management.

We could also entertain the thought of requiring user consent before communicating with USB peripherals, but it's unclear whether that's a net benefit given that it adds friction and won't be very useful for cases where users get tricked into plugging malicious USB devices themselves.

 

        matthias

--
Matthias Apitz, ✉ gu...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdió la Guerra.
May 8, 1945: Who does not celebrate lost the War.

--
--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsubscribe...@chromium.org.

--

Mattias Nissler | Software Engineer | mnis...@google.com

Google Germany GmbH

ABC-Str. 19

20345 Hamburg

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Registergericht und -nummer: Hamburg, HRB 86891

[Dov W]

At only 61 views the video hasn't exactly gone viral yet. The poisontap exploit targeting unencrypted web traffic from the compromised device was originally against all major OSs including Windows and the Windows mitigation suggested in the video and not even detailed in it comes from a custom workaround that was filed as an open issue against the exploit - https://github.com/samyk/poisontap/issues/26 - so yes, that's pretty disingenuous because that workaround was so non-obvious that even Kamar himself who created the exploit didn't think of it. 

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

--

Mattias Nissler | Software Engineer | mnis...@google.com

Google Germany GmbH

ABC-Str. 19

20345 Hamburg

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Registergericht und -nummer: Hamburg, HRB 86891

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

[Mike Frysinger]

On Mon, Jun 19, 2017 at 1:51 AM, Matthias Apitz wrote:
> El día domingo, junio 18, 2017 a las 04:26:05p. m. -0700, Mike Frysinger escribió:
> > yeah, that is hilariously disingenuous.  pretty sure the USB device they
> > plug in emulates a USB keyboard & ethernet.  it then sends some keyboard
> > presses to open a tab and go to a known website which then tries to access
> > *http* (not https) sites which it then hijacks (since it reconfigured the
> > networking).  the problem here is that CrOS *already* assumes that the
> > network cannot be trusted.  there is 0 difference between someone plugging
> > in a USB dongle they hacked together and connecting to public WiFi (at the
> > airport, at a cafe, at a hotel, etc...).  CrOS doesn't trust any of them.
> >  so you're left with the same question all the time: do you trust random
> > websites that serve traffic over http ?  no ?  good, because they suck.
> >
> > the fancy screen flashing you see in the video is just that -- someone
> > wrote some JS to scare people who don't know what is happening.  might as
> > well have put up your typical matrix screensaver and kicked off a hacker
> > montage and dropped some thumpin beats.
>

> It is not the same when some user clicks on some HTTP URL, it is his/her
> fault being stupid. But when a crafted USB key do so, it is just
> another case, i.e. some sophisticated attack.

as i described, the USB part is irrelevant.  here's what that system looks like at the network level (with some crude ASCII art):
  [CrOS] <-[USB dongle]-> <-[Internet]-> <-[Insecure HTTP site]

the concern is that the USB dongle is malicious right ?  and can inject/modify any HTTP (not HTTPS) request ?  well what does it look like when you're sitting in a hotel/airport/cafe/mall/bad ISP ?
  [CrOS] <-[hotel/airport/cafe/mall/ISP]-> <-[Internet]-> <-[Insecure HTTP site]

it's exactly the same.  the USB dongle is irrelevant to this attack.  "ah, but i trust Starbucks!" you might say.  have you seen firesheep ?  it was all the rage a few years ago because it was able to perpetrate the same exact attack that is being done here, except it was by other patrons sitting near you.

we can go even farther.  if you use unsecured WiFi, anyone can bring in a device that broadcasts the same WiFi name and direct clients to connect to them.  so what does that look like ?

  [CrOS] <-[spoofed WiFi]-> <-[Internet]-> <-[Insecure HTTP site]

most OS's are configured to automatically connect to remembered WiFi names too.  so just set up your phone to be an open hotspot using names like "linksys" and walk around the mall.  i'd bet money you'd see phones automatically connect to that and the users would never even notice.  or name it "Free WiFi" and people would choose to connect to it!

this is why CrOS assumes all network connections are malicious.  the only thing you can trust is HTTPS.  (i'll save the rabbit hole of HSTS bootstrapping for another day.  and the rabbit hole of DNS-vs-DNSSEC.)

the part about "the USB dongle made the user click a 'malicious URL'" can also be ignored.  the only thing that page does is manually trigger connections in the context of the user's browser.  i.e. it made the user navigate to http://cnn.com/ simply so it could hijack/capture content asap.  if the user themselves navigated to http://cnn.com/, then they'd run into the same situation.

i ignored the rest as Mattias already covered it :)
-mike

[Dov W]

The comments here seem focused on the exploit entirely from a protocol perspective and hence the  argument is that http is http and that's anyway unsafe and so the exploit involves nothing new or different.

That's all well and good except that from an end-user perspective, however, the dangers of using a public WiFi network for unencrypted traffic are known whereas it is assumed that an unattended locked machine on a private ISP connection and/or on a private or corporate LAN behind a firewall are safe because from an end-user perspective there is no awareness of the vulnerability that an unattended USB port presents to a USB Ethernet gadget which can introduce a backdoor tunnel to hijack not only external HTTP traffic but additionally internal HTTP traffic such as that to a local network router or internal HTTP website or portal.

For end-users the protocol argument with all its technical merits will provide little comfort and all theory aside, practical security concerns might justify using Windows over ChrOS were it not for the other arguments - the Windows workaround could be easily defeated by changing the USB VID/PID and from a practical standpoint the Windows workaround has not been implemented on any scale

--

--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsub...@chromium.org.

[Mike Frysinger]

to preface, don't let debate here scare people off.  while people might disagree on things, we're always open to discussion as we know we have all have the same goals in mind: we want to make CrOS as secure and user friendly as possible.  we know that there are often non-obvious improvements to be made.  that doesn't mean we'll devolve into peddling snake oil though :).

some high level points.

- first, this/your claim is not specific to CrOS.  every OS which automatically loads drivers/configures things based on USB plugs behaves this way.  which last i looked, all OS's (Windows/macOS/Linux) do.  that doesn't mean we shouldn't strive to do better when feasible, i'm just trying to put things into perspective.

- second, attacking an unlocked/unattended device and owning it is not specific to CrOS.  if i leave my device unlocked and walk away, then bad people can do bad things and it's your fault.  there's nothing the OS can do to protect you.  and this applies to every OS.  you mentioned "locked device" here, but the original thread here did not and specifically required unlocked (to navigate to a site).

- we already covered the white/black listing of devices locally and at the admin level, so there's no need to rehash that.

now let's look at the network level.

- if your network allows unsigned/untrusted devices to connect to it, then sorry to say, but your assumptions are invalid.  whether your local IT shop is also incorrectly making that assumption is irrelevant.  their network is ripe for attack and the USB angle doesn't matter.

- if you can attack the LAN, then you can hijack/poison other systems on there.

- if you have physical access to a system that is wired, you can skip USB entirely and patch your own malicious router into the cables.  desktop<->ethernet<->your router<->ethernet<->lan.

- or you could plug a legitimate USB ethernet dongle in, plug its ethernet into your own malicious router, then plug that into the wall or wherever.

i'm not talking theory here.  i don't think you've made any practical arguments that suggest any OS is more secure relative to any other when your network and the services you're using are garbage.  corporations have been and continue to be attacked because of this failure in opsec.  i saw a virus at my last job where one infected machine started poisoning DHCP/DNS and injecting HTTP and it was hard to trace down the single source machine.  i saw another talk last week where a company mentioned users getting ads injected in their browser while visiting internal corporate sites because another system on the corp LAN was infected and attacking http.  Google internally has deployed 802.1x specifically to combat these scenarios.  if your machine is unknown, it gets punted to a restricted VLAN, and it can't attack anyone else.

if we scope to "the system is locked", we could look at disallowing network reconfigs.  we already disallow people from changing the WiFi while the screen is locked ... automatically switching to ethernet seems to fall into that category.  i just checked a recent version and we do probe/change.  i don't think we want to block all devices as it'd be problematic for people hooking up new inputs (like keyboard/mice) or displays (as we move to a USB Type-C world).  but if the system is locked, it means someone can login, which means the OS can auth you w/out network, so there isn't a strong argument for allowing new network stacks to come up w/out approval.

i've filed https://crbug.com/734826 to track that enhancement.

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsubscribe...@chromium.org.

[Jim Dantin]

Mike, I really appreciate your explanations and efforts on this subject.

[Dov W]

Mike,

Thank you very much for your clarification. The OP included the URL of the exploit site which clearly states that it is designed to work on locked devices. Another video on that site clarifies that they only demo'd on open devices to better show what is going on.

On a practical level the cleverness of the exploit is a combination of the smallness of the device - no standard router needed - the short time that it needs to engage - the lack of any footprint of foreign code on the target machine all of which make this harder to avoid. So although there may be little new in principle in practice the vulnerability is greater.

That said, I strongly agree with your point about there being no fundamental difference between OSs, which is in fact the real story as stated on the exploit site itself and not as disingenuously insinuated in the video the OP linked to. 

Furthermore, the enhancement you created is a great response to this issue.

[Matthias Apitz]

El día lunes, junio 19, 2017 a las 09:58:46p. m. -0400, Dov W escribió:

>
> That said, I strongly agree with your point about there being no
> fundamental difference between OSs, which is in fact the real story as
> stated on the exploit site itself and not as disingenuously insinuated in
> the video the OP linked to.
>

> ...

Re/ the USB attack vector, offering a new notwork on USB, the system I
do use differs a bit: FreeBSD must be pre-configured for the devd(8)
daemon and the cdce(4) driver must be loaded in advance to allow a new
network interface ue0 created on plug-in of an USB gadget. This is
already far behind the knowledge of many normal users :-)
And even then no DHCP is initiated or routing modified. This must be
done in devd(8) hook-up scripts :-)

[Selden Deemer]

Mike and others, thank you for this illuminating discussion. It's been fascinating reading, and I have learned some new things, although others remain above my head. Great reading!

[Will Smith]

This has been great reading, it should be packaged up as a blog post! 

On Tue, Jun 20, 2017 at 12:24 PM, Selden Deemer <lib...@gmail.com> wrote:

Mike and others, thank you for this illuminating discussion. It's been fascinating reading, and I have learned some new things, although others remain above my head. Great reading!

--

--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsub...@chromium.org.

[Mike Frysinger]

in the current scenario, you're right that the system can be attacked passively.  but that would only work on sites that the system is actively hitting.  when the screen is locked, the system is mostly idle, so you're talking about web pages that are continuously updating themselves over http.  if none are, then there's nothing to inject -- the system doesn't care what packets you send it if it didn't ask for anything :).  so it narrows the practical scope a bit (not that, from a security perspective, one would argue makes things acceptable).

i don't think i agree with the "it's new or novel" angle.  the corp attacks i observed at my last job were back in 2009/2010, and those weren't even spearphishing attacks ... just whatever script kiddy copy & paste code was floating around.  firesheep was announced around that timeframe as well.  droidsheep (run firesheep on any android phone) was ~2011.

but you're qualifying as "it's a tiny device that's easy to hook up and no one notices".  the Pwn Plug was announced late 2011/early 2012 and fits exactly that bill.

these attacks might be news to some people, but to the security/tech world, it's over 5 years old.  and i think i'm pretty far down the chain when it comes to bleeding edge, so i assume it's been in active use for much longer :).

-mike

[Dov W]

As far as the hardware the Basic PwnPlug debuted at $480 and today the r3 is on sale for $799. By contrast PoisonTab was written to run on a $5 Rasberry Pi Zero. 

As far as the exploit itself if anyone's interested there's a write-up in Ars Technica:

https://arstechnica.com/security/2016/11/meet-poisontap-the-5-tool-that-ransacks-password-protected-computers/

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org

[Mike Frysinger]

you keep refining the requirements :).  the Pwn Plug is >$500+ because it's a polished product targeting a market willing to pay that price point.  if we ignore cost (which, for motivated attackers is a non-issue), i stand by my claim that there is nothing new here and it's 5+ year old news.  we know unencrypted http traffic can be attacked and all content therein can be exfiltrated/abused.

thanks for the Ars link.

-mike

https://arstechnica.com/security/2016/11/meet-poisontap-the-5-tool-that-ransacks-password-protected-computers/

--
--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsub...@chromium.org.

--
--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

--
--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

[Selden Deemer]

Thanks for the link to the ArsTechnica article, which left me at least as confused as before, but with new questions (emphasis, mine):

PoisonTap is able to become the gateway for all Internet traffic as well. It does this by defining the local network to include the entire IPv4 address space. With that, the device has the ability to monitor and control all unencrypted traffic the locked computer sends or receives over its network connection.

PoisonTap then searches the locked computer for a Web browser running in the background with an open page. When it finds one, the device injects HTML iframe tags into the page that connect to the top 1 million sites ranked by Alexa....

Attackers still must overcome any password protections safeguarding an exposed router.  

1. My habit is to close all windows before putting a Chromebook to sleep or shutting down. If If PoisonTap requires a web browser running in the background (always the case in a Chromebook) with an open page, is there any risk?
   
2. My home router has a fairly secure Wi-Fi password and separate admin password, so I assume that such an attack is impossible at home.
3. When I travel, the security of a router is always unknown, so I never let my Chromebook out of my sight. It's not clear to me if the router is permanently compromised, or if the exposure exists only when a PoisonTap device is active on it. Does using Google name servers make any difference?
4. I normally shut down when I leave a place with public Wi-Fi, such as Starbucks, so that if the Chromebook is stolen, it's unusable. I'm assuming that a Chromebook that is started from a shut down state is not vulnerable, as long as Guest logins are disabled. 

Comments?

[Dov W]

Mike,

I understand your perspective and I also agree with an earlier comment you made that it's not useful to generate paranoia. I also understand that people have lives and don't always have the time to thoroughly investigate every claim.

That said, I do feel that at least initially the comments on this thread seemed to prematurely dismiss the exploit as nothing more than a cheap and irrelevant gimmick. By contrast one web security researcher and chief of security strategy said this:

"I think it’s actually the most cleverly designed and effective backdoor tool that I’ve seen."  

https://www.wired.com/2016/11/wickedly-clever-usb-stick-installs-backdoor-locked-pcs/

If I have either brought some more balance or at least some more information to the discussion, to me at least, that's been worthwhile.

On Wed, Jun 21, 2017 at 1:28 AM Mike Frysinger <vap...@chromium.org> wrote:

you keep refining the requirements :).  the Pwn Plug is >$500+ because i t's a polished product targeting a market willing to pay that price point.  if we ignore cost (which, for motivated attackers is a non-issue), i stand by my claim that there is nothing new here and it's 5+ year old news.  we know unencrypted http traffic can be attacked and all content therein can be exfiltrated/abused.

-mike

https://arstechnica.com/security/2016/11/meet-poisontap-the-5-tool-that-ransacks-password-protected-computers/

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org

[Dov W]

And for anyone who's curious about the creator of this exploit, who's apparently better known for his Myspace Samy worm there's this:

https://en.wikipedia.org/wiki/Samy_Kamkar

[Marc Herbert]

On Sunday, 18 June 2017 15:56:40 UTC-7, Jim Dantin wrote:

This rather one-sided Microsoft video brings up some interesting claims. I'll ignore the claim that Windows is more secure, but I wonder about what really is possible with ChromeOS devices.

https://www.youtube.com/watch?v=DJg-mI3tuaU

From... the operating system who gave us "Autorun"! Remember the days?

http://www.computerworld.com/article/2481506/endpoint-security/the-best-way-to-disable-autorun-for-protection-from-infected-usb-flash-drives.html

https://www.us-cert.gov/ncas/alerts/TA09-020A 

PS: I really enjoyed the acting, thanks for sharing :-)