Hacking Password-Protected Computers via the USB Port

PoisonTap is an impressive hacking tool that can compromise computers via the USB port, even when they are password-protected. What’s interesting is the chain of vulnerabilities the tool exploits. No individual vulnerability is a problem, but together they create a big problem.

Kamkar’s trick works by chaining together a long, complex series of seemingly innocuous software security oversights that only together add up to a full-blown threat. When PoisonTap—a tiny $5 Raspberry Pi microcomputer loaded with Kamkar’s code and attached to a USB adapter—is plugged into a computer’s USB drive, it starts impersonating a new ethernet connection. Even if the computer is already connected to Wifi, PoisonTap is programmed to tell the victim’s computer that any IP address accessed through that connection is actually on the computer’s local network rather than the internet, fooling the machine into prioritizing its network connection to PoisonTap over that of the Wifi network.

With that interception point established, the malicious USB device waits for any request from the user’s browser for new web content; if you leave your browser open when you walk away from your machine, chances are there’s at least one tab in your browser that’s still periodically loading new bits of HTTP data like ads or news updates. When PoisonTap sees that request, it spoofs a response and feeds your browser its own payload: a page that contains a collection of iframes—a technique for invisibly loading content from one website inside another­that consist of carefully crafted versions of virtually every popular website address on the internet. (Kamkar pulled his list from web-popularity ranking service Alexa‘s top one million sites.)

As it loads that long list of site addresses, PoisonTap tricks your browser into sharing any cookies it’s stored from visiting them, and writes all of that cookie data to a text file on the USB stick. Sites use cookies to check if a visitor has recently logged into the page, allowing visitors to avoid doing so repeatedly. So that list of cookies allows any hacker who walks away with the PoisonTap and its stored text file to access the user’s accounts on those sites.

There’s more. Here’s another article with more details. Also note that HTTPS is a protection.

Yesterday, I testified about this at a joint hearing of the Subcommittee on Communications and Technology, and the Subcommittee on Commerce, Manufacturing, and Trade—both part of the Committee on Energy and Commerce of the US House of Representatives. Here’s the video; my testimony starts around 1:10:10.

The topic was the Dyn attacks and the Internet of Things. I talked about different market failures that will affect security on the Internet of Things. One of them was this problem of emergent vulnerabilities. I worry that as we continue to connect things to the Internet, we’re going to be seeing a lot of these sorts of attacks: chains of tiny vulnerabilities that combine into a massive security risk. It’ll be hard to defend against these types of attacks. If no one product or process is to blame, no one has responsibility to fix the problem. So I gave a mostly Republican audience a pro-regulation message. They were surprisingly polite and receptive.

Tags: , , , , ,

Posted on November 17, 2016 at 8:22 AM • 80 Comments

Comments

keiner • November 17, 2016 9:10 AM

“They were surprisingly polite and receptive.”

…and won’t do anything. Fine, how you learned neolib vocabulary “market-failure”, “democratization” and stuff. Did they feed you some chocolate in the end, at least?

Brooke • November 17, 2016 9:41 AM

And how many companies only patch critical/important releases vs everything because “that’s what’s really risky.” I’ve never understood why they do that!?! Just patch everything that’s available, if you’re patching a system with a few patches vs 10, what’s the point? Just patch what’s available and it’ll help your overall security and stability. I don’t think the norm is to patch it all though, everywhere seems to have drawn lines of what is going to be patched and it makes no sense. If you’re patching, patch it all.

john • November 17, 2016 10:05 AM 

Surely the only risk here is the same as
having a  compromised  router  somewhere
between you and the web site?
Given that (domestic)  routers are often
old  software   with   unpatched   known
vunarabilites  which  can  be  exploited
remotely,  is not  the bigget  number of
risks going to come from that direction?
(Though  there may be  bigger risks with
this,  eg.  on  well  secured  corporate
network...  but then  again you  have to
trust  your  ISP's  employees not  to be
adding some snooping device)

Clive Robinson • November 17, 2016 10:13 AM

@ Bruce, The Usual Suspects and Samy if you are reading this blog,

Whilst,

PoisonTap is an impressive hacking tool that can compromise computers via the USB port…

Is true, on reading through the details in a little more depth a thought occurs,

If you consider,

    Even if the computer is already connected to Wifi, PoisonTap is programmed to tell the victim’s computer that any IP address accessed through that connection is actually on the computer’s local network rather than the internet, fooling the machine into prioritizing its network connection to PoisonTap over that of the Wifi network.

And what that actually means, you get the potential to hijack any and all network traffic…

As I’ve said many times before technology is agnostic to it’s use, it’s the “directing mind” that decides the purpose the technology is put to.

So instead of using this device and knowledg for illicit purposes as a variation on “Evil Maid”, how about usining it to build the likes of a “Universal plugin firewall / IDS”. I suspect that it would work not just with the commercial and FOSS OS desktop systems, but laptops, netbooks, and Android pads and smart phones…

Which as the likes of Win10 and Android OS are considered “Telemetry Enabled” in a way you can not turn it off, might help with privacy and stopping such devices getting used as botnet zombies, that the user generaly has no way to see let alone stop.

jones • November 17, 2016 10:31 AM

@ Clive
@ Bruce

As I’ve said many times before technology is agnostic to it’s use, it’s the “directing mind” that decides the purpose the technology is put to.

Indeed, back in ’06 I was cracking jokes referring to my cell phone as a tracking device, folks was telling me “you’re crazy.” Right.

So, I inferred this:

https://americajones.blogspot.com/2006/03/pavlovian-conditioning-and-calculation.html

which I now know to me Foxacid / Quantum courtesy of Mr. Snowden.

I wouldn’t be surprised if the hack discussed here has been discovered before….

I’m done being told I’m crazy.

Welcome to the New World Order.

And please recall:

https://en.wikipedia.org/wiki/National_Defense_Authorization_Act_for_Fiscal_Year_2012#Controversy_over_indefinite_detention

https://en.wikipedia.org/wiki/Posse_Comitatus_Act#Recent_legislative_events

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

and we don’t need to speculate what the NSA might do without oversight:

http://www.aarclibrary.org/publib/church/reports/book3/html/ChurchB3_0004a.htm

https://www.brennancenter.org/publication/what-went-wrong-fisa-court

https://theintercept.com/2015/08/07/psychologists-work-gchq-deception-unit-inflames-debate-among-peers/

beyond the opportunities for automated harassment and psychological manipulation, nobody seems to be talking about the 5th Amendment implications of the surveillance state: if you can be placed under retroactive surveillance at any time for any reason, what does that do to your right to remain silent?

And I’m still amazed at how effective this site’s CAPTCHA is.

Qbert • November 17, 2016 10:53 AM

Also note that HTTPS is a protection

I would assume that Qubes OS is also a protection since their USB VM is designed to thwart this class of attack.

TJ • November 17, 2016 11:27 AM

Use Windows 95-10, Linux, BSD, and Apple out-of-box USB policies if your BIOS doesn’t allow hard-disable.

Kind of like how big-market software vendors had to start use sandboxing cause everyone ran as a privilege user making it easy for shellcode payloads.

Ross Snider • November 17, 2016 11:34 AM

You are testifying about Dyn to a HoR Hearing Sub/Committee?

No wonder your posts have been going on about “only government is the solution” and “we need to regulate these devices.”

I think you know well enough that regulations on IoT aren’t solutions (let alone good ones) to the complexities that were faced by the Dyn DDoS. Regulating authority over Turing Machines is a power grab using a digital “Shock Doctrine” – in this case a DDoS attack that could have only been prevented by a more sane architecture for name resolution.

Disheartening to see you (Schneier) entertaining that power grab rather than explaining carefully that DDoS won’t be stopped if IoT devices are immoveably secure – that indeed DDoS was a problem before the acronym IoT existed.

Your testimony should be that critical internet infrastructure and standards need: A) An overview and update to make them resilient and/or impervious to 21st century security concerns B) A maintenance schedule that allows the architecture of these critical components to be updated without affecting major outages C) Funding, information support and market incentives to support our critical internet services and their dependencies so that they can be upgrades D) A series of laws that make internet hacking with disclosure a safer offense so that the powers of curious and creative people can be put to work probing our technologies.

Recommendations to regulate here are going to raise costs, backdoor our IoT services, and won’t solve the problem.

name, required • November 17, 2016 12:46 PM

A series of laws that make internet hacking with disclosure a safer offense so that the powers of curious and creative people can be put to work probing our technologies.

Yes. Bug bounties, or at least a way to report vulnerabilities, for everything. Right now there.is.no.such.way.
(or perhaps the selective deafness is an act)

markg • November 17, 2016 12:49 PM

On Government fixes:
Never let a good crisis go to waste
Never consider unintended consequences
Never let the market work it out with a clever technological solution when a slipshod regulation do.
…
What we should be thinking: Never bureaucrats near our technology

Ted • November 17, 2016 1:04 PM

“I worry that as we continue to connect things to the Internet, we’re going to be seeing a lot of these sorts of attacks: chains of tiny vulnerabilities that combine into a massive security risk.”

One of the multistakeholder working groups has produced a multi-party vulnerability coordination document for discussion.

The draft outlines a set of guiding principles and vulnerability coordination best practices, supported with use cases that describe various scenarios and disclosure paths. The document is geared for vulnerabilities that could affect many vendors and technologies at one time. (Could PoisonTap’s soup of relational vulnerabilities be mitigated though such a process?)

Here’s one use case:

Variant 3: Missing communication between upstream and downstream vendors.

Description: Direct communication or a security disclosure could be missing between upstream vendors and downstream vendors or between vendors and users. A coordinator could facilitate receiving and distributing information back and forth to relevant parties at various stages of remediation.

Potential causes as well as prevention and response guidance are provided (pages 11 to 14), including the effective utilization of coordinators, vulnerability databases, and streamlined communication channels to connect a range of upstream and downstream providers. The level of oversight for process and relationship-building would be up to each party I’m guessing?

https://www.ntia.doc.gov/other-publication/2016/multistakeholder-process-cybersecurity-vulnerabilities

Skeptical • November 17, 2016 1:07 PM

I’m not convinced this is guaranteed exploitable today. My experience is that Apple disabled USB network adapters by default in either Yosemite or El Capitan. Users have to turn the USB network adapters back on manually. I ran across this when USB tethering suddenly stopped working.

Wael • November 17, 2016 1:11 PM

On a “secure” computer, logging off is an event that needs to shutdown all ports, including the USB ports. Will add some “inconveniences”, but nothing is free. This mechanism mitigates a “class of vulnerabilities” and shrinks the surface of attack. Now apply that to all forms of “energy” to effectively “quasi-energy-gap” (right @Clive Robinson?) the unattended device.

Au revoir, Mademoiselle!

{} • November 17, 2016 1:53 PM

@jones

And I’m still amazed at how effective this site’s CAPTCHA is.

my motto: Security through Obscurity
(at some point, security through obscurity won’t be enough, though)

Correct Me If I'm Wrong But... • November 17, 2016 2:26 PM

… isn’t this just a case of “autorun and plug and play are not always your friend”?

I.e. would this threat model effect a linux kernel configured with minimal hardware support? If there is no usbnet (or whatever) driver on the OS, does this attack still work?

Wake me up when people actually really start getting a clue.

Bong-Smoking Primitive Monkey-Brained Spook • November 17, 2016 2:48 PM

@Correct Me If I’m Wrong But..,

… isn’t this just a case of “autorun and plug and play are not always your friend”?

No.

Wake me up when people actually really start getting a clue.

Wake up and smell what you’re shoveling!

Who? • November 17, 2016 3:58 PM

@ Wael

On a “secure” computer, logging off is an event that needs to shutdown all ports, including the USB ports. Will add some “inconveniences”, but nothing is free. This mechanism mitigates a “class of vulnerabilities” and shrinks the surface of attack. Now apply that to all forms of “energy” to effectively “quasi-energy-gap” (right @Clive Robinson?) the unattended device.

Does “inconvenience” mean you cannot log again into this secure computer? Note: the keyboard is usually another USB device. 🙂

Wael • November 17, 2016 4:14 PM

@who?

Does “inconvenience” mean you cannot log again into this secure computer?

Yes, a minor inconvenience 🙂 But there are ways around it. On a laptop, it should be ok. On a desktop, you’ll need another mechanism — an inconspicuously hidden reed switch would be a simple method. BT token is out… Voice recognition is another, cycling power is a harsh method….

Who? • November 17, 2016 5:26 PM

@ Wael

What you note is certainly a concern on cases like this one. But I am more worried about the ports that remain open on a computer when it is shut down, and barely protected by an insecure firmware (not to say the risks of hardware being backdoored by governments in collaboration with industry)—looking at the LEDs on the ethernet port blinking while the computer is turned off is worrying.

Sebastian • November 17, 2016 5:36 PM

Noscript is a protection too. Nobody should ever take iframes without a fight, they’re toxic.

Is it? Pages can auto-refresh without scripts, and if they’re unencrypted, the attacker can return a redirect to an unencrypted version of a “secure” site you’re logged into. And if they forgot to set the secure cookie flag your browser will send your cookie. So I’d suggest, for sites you care about,

  • Use a browser profile with unencrypted traffic disabled. Blacklist http://* and ws://* at least (with the built-in URLBlacklist setting on Chrome or the Adblock extension on Firefox) or set an http proxy pointing to an unused localhost port and don’t set an https proxy.
  • Use a different browser profile for each “secure” site, separate from your everyday browsing profile. That way they can’t leak credentials between each other.
  • If it’s something really important, consider disabling CAs and manually pinning certs instead (after checking fingerprints in a “normal” browser).
  • And still disable scripting as much as possible, of course. If non-essential sites break in this configuration, complain rather than whitelisting them.

Unfortunately, none of these things are straightforward for the “normal” user. It would be great if sites needing security could use something like DANE to indicate their site is HTTPS-only, but apparently lots of networks blocks DNSSEC lookup.

Steve • November 17, 2016 5:53 PM

I have iframes disabled in NoScript. In fact, I have everything possible disabled in my browser. No javaScript, cookies, flash, and I have the cache size set to zero.

It’s sad that program languages are so insecure I’m forced to surf the web like this. I’ve been infected by multiple drive-by download malware infections.

You don’t even have to click on anything to be infected. Simply visiting Yahoo.com and having a rogue advertisement load in the side-bar is enough. The infection process happens in the blink of a eye with no user interaction. You won’t even know the infection happened.

I’m convinced this huge push behind internet of things is more about data mining people’s lives and selling this data for a profit. It’s double dip profit. First you sell them the product, then you sell data being sent back to Corporate HQ about how they’re using that product you just sold them.

Wael • November 17, 2016 6:13 PM

@who?

But I am more worried about the ports that remain open on a computer when it is shut down

That’s certainly annoying and looks suspicious. In an enterprise setting, it’s none of my business as I am the owner of nothing. On my personal machine, I own everything, and I don’t welcome unadvertised “features”. Anything that happens on my device must happen with my consent.

So I stay away from devices that have a “manageability engine”. If I power my device off, I want the LAN, WiFi and everything else to be off. The alternative is to unplug the device from power and remove all cables which is a hassle. Another method it to add hardware switches that disconnect or connect selected ports such as LANs. These hardware switches must not be susceptible to “remote attacks”. When the device is on, traffic must be funneled through an external firewall / switch / router that’s exclusively under the owner’s control.

not to say the risks of hardware being backdoored by governments in collaboration with industry

Wrap the HW with controls that only you can manage. Assume all HW / FW / SW is backdoored either deliberately, or because some idiot developer decides to get “cutsie”.

looking at the LEDs on the ethernet port blinking while the computer is turned off is worrying.

Easy! Just put electric tape on the blinking LEDs! 😉

Bong-Smoking Primitive Monkey-Brained Spook • November 17, 2016 6:45 PM

@Sancho_P,

Physical access is always the end.

Wrong, number one! It’s the beginning for me. The beginning of the end for you 🙂

anonymous • November 17, 2016 7:08 PM

Can someone explain to me, who would make the new network interface up (with iproute2, ip link set dev eth0 up)?

Then, why would my computer issue a dhcp to a new link which has never been configured?

Of course, if the OS is wakes up each and every new interface appearing on the system, talks to it, and changes network settings on the fly, then nothing is safe, but all these are assumptions.

For example, I at our institute this attack will certainly fail…

anonymous • November 17, 2016 7:16 PM

Also, why do you guys think that there is a “chain of tiny vulnerabilities”?

To me, network and firewall settings MUST NEVER be changed by a software, only by an admin. If this happens, it is not a “tiny” vulnerability, but a grave issue. I don’t know what quality control MS or Apple exercise, but for any sane linux distro, that would be a release blocker…

I think you guys are spreading FUD too much…

anonymous • November 17, 2016 7:21 PM

And to everyone usgin noscript, adblocker and all that… For how long are you going to continue this masturbation?

First, a dev team at Mozilla, Google, etc. add a ton of new JS/CSS/HTML5 capabilities. Then another team of devs adds counter-measures. Am I the only one who thinks this is crazy?

Have you guys forgotten about links2 and similar software. It is still functional, for instance, I wrote last three posts in links 2.13.

Wael • November 17, 2016 7:43 PM

@anonymous,

but for any sane linux distro, that would be a release blocker…

Riiiiiiiiight! Just like shellshock was a release blocker for 25 years, and heartbleed…

I think you guys are spreading FUD too much…

And you’re too comfortable and relaxed. I envy you for the warm and fuzzy feeling you’re experiencing. Ignorance is bliss.

Bong-Smoking Primitive Monkey-Brained Spook • November 17, 2016 7:47 PM

@anonymous,

For how long are you going to continue this masturbation?

Seriously? As if you never polished your bishop!

anonymous • November 17, 2016 8:22 PM

OK, first let me say that I did read the description at samy.pl and, btw, the code is on github, not at that link. Still, noone here even attempted to answer my questions…

My answers to the previous posters follow…

@Wael:
I said already that this exploit is not going to work on any *nix machines that are maintained by me or the IT guys that I know here (here = JILA, google for it).
Also, comparing this to heartbleed is like apples to oranges. For that specific openssl bug, it is instructive to read Paul Vixie’s reply to Bruce here: http://seclists.org/fulldisclosure/2014/Apr/158 . Of course, oftware will have bugs, but heartbleed was way over-advertised. For example, no system running sshd was vulnerable.

On the contrary, you are saying that my OS is supposed to automagically configure new network interfaces. Of course, it is a security issue. But I can readily tell you more of those.

Have you heard of polkit, systemd-networkd and firewalld? If you have, then you know that all of them speak dbus (maybe for networkd it is a WIP). Who else speaks dbus? Firefox and chromium and probably many other browsers. The only barrier that protects your machine now is a properly written polkit policy. Do you feel lucky? Here, you have a material for the next blackhatc or smth…

anonymous • November 17, 2016 8:28 PM

@Wael:
I hope I expressed that I am not all warm and fuzzy 🙂 and that I don’t have the bliss of ignorance (unfortunately). But I am complaining about the sensationalist title of this story. It should have been “Hacking password-protected computers… if the assumptions a, b, c, d, … l are fulfilled”.

@Bong:
In a such perverted way no, never.

Wael • November 17, 2016 8:39 PM

@anonymous,

I said already that this exploit is not going to work on any *nix machines that are maintained by me or the IT guy…

That’s an entirely different story!

Who else speaks dbus?

Gnome does.

Do you feel lucky? Here, you have a material for the next blackhatc…

Thanks, but I don’t need it. Not a blackhat fanboy.

I hope I expressed that I am not all warm and fuzzy :

You have now!

I don’t have the bliss of ignorance (unfortunately)

Clearly you don’t! You should choose a name, though. I suggest “Not Warm and Fuzzy” 😉

anonymous • November 17, 2016 8:49 PM

But “anonymous” is so cool because it means that I am completely untraceable 🙂

Yes, Gnome, KDE and other desktop environments, which is totally fine because that’s what dbus is for (desktop-bus). However, if there is a chance that dbus calls to system software (firewalld for firewall config or systemd-networkd for network interfaces config) can be remotely forged via a browser exploit, it is quite bad. And distros that have firewalld enabled by default (Fedora, I’m looking at you), are insane.

Note, that in the day I am a physicist, not a sysadmin. In fact, all my skills come from observing work of archlinux developers and talking to arch users. This should tell you that if I say that our machines are protected against this exploit, there is nothing complicated to it. Just do your homework…

r • November 17, 2016 8:50 PM

@anonymous,

Have you checked your host information from links?

w3m is the only one other than elinks that out of the box keeps your kernel version quiet.

anonymous • November 17, 2016 8:58 PM

@r:
In the User-Agent string? Lynx, elinks and links allow any user agent to be specified. In fact, does anyone know about a working exploit against apache or nginx that is associated with improper parsing of this string? 😛 Too many websites don’t work if I set it to smth random. I would like to crash those web servers…

anonymous • November 17, 2016 9:07 PM

In fact, in recent links (since 2.11 ish) there is an option to send a Firefox user agent. So now, I am officially running FF 45 on windows 7 🙂 Unfortunately this screws up many websites again because they assume that I can execute JS code 😛

r • November 17, 2016 9:09 PM

I know they can be over-rode and spoofed, just wanted to let ya know they’re pretty liberal with their defaults.

I don’t explore network communications, I’m sure there’s strange cases out there for backends like php or one of the lesser common servers but I don’t know of something to satisfy your query no.

Wael • November 17, 2016 9:09 PM

@anonymous,

Note, that in the day I am a physicis

That’s good! Keep us honest then when we discuss physics! We often do! Problem is there are too many posters with your handle…

r • November 17, 2016 9:13 PM

Also, just because your UA matches FF doesn’t mean the header is sent in the matching order. I think I’ve been down the same road you’re speaking of in the case of links FF spoofin, I think I disabled a bunch of the Accept: string too.

I do that in FF to suppress gd gif89a’s.

Not Warm 'n Fuzzy • November 17, 2016 9:57 PM

OK, ok, here is my new name 🙂

@r:
Yeah, I was ranting. I read smth about improperly escaping HTTP headers in web server software, but am pretty sure that UA is well-sanitized…

For the browser defaults, I don’t see a problem as long as they can be over-ridden (know your software and such). Besides, I still don’t understand why exposing a kernel version and/op compiler/architecture presents a security issue. This sounds like security by obscurity…

Elly brown • November 17, 2016 11:42 PM

Well done..Poison Tap is an impressive hacking tool that can compromise computers via the USB port, even when they are password protected. What’s interesting is the chain of vulnerabilities the tool exploits. No individual vulnerability is a problem, but together they create a big problem.

Matthew • November 18, 2016 1:13 AM

From what I read about this hack, it is basically a raspberry pi zero setup as a malicious man-in-the-middle usb modem/router/ethernet device.
What is interesting is how this device tricks your computer to redirect all traffic to it. I believe this is how it works, other experts here can correct me if I am wrong.

Normally when your computer connects to the internet router via wifi or ethernet cable, the OS will learn from the router, using dhcp, this route “IP_addr:0.0.0.0 Netmask:0.0.0.0 Gateway_IP_addr”. In networking, this means send traffic for network 0.0.0.0/0 which encompasses all IPv4 addresses to the gateway.

When the malicious usb device connects to the computer, it will falsely identify as a network device to the OS. This causes the OS to query the device with dhcp requests and learns 2 routes from it “IP_addr:0.0.0.0 Netmask:128.0.0.0 malicious_IP_addr” and “IP_addr:128.0.0.0 Netmask:128.0.0.0 malicious_IP_addr”. In short, the malicious device is telling to send traffic for 0.0.0.0/1 and 128.0.0.0/1 to it.

Notice that 0.0.0.0/1 and 128.0.0.0/1 is 0.0.0.0/0 divided into two subnets. Since network routing protocols prefer routes with more specific subnets ie. netmasks with a larger value, all traffic is forwarded to the malicious device instead of gateway.

In my opinion, Samy’s explanation is inaccurate. I believe network routes learnt from dhcp to have the same priority/metric regardless of the interface. The hint I get is a graphic on Samy’s website showing poisonTap’s netmask to be 128.0.0.0. A quick google search shows OpenVPN uses the same trick to force all network traffic to the VPN tunnel.

I think static routes set by admin or routes learnt by other means like AD group policies can mitigate against network hijacking.

Not Warm 'n Fuzzy • November 18, 2016 2:13 AM

@Matthew:
In essence, THIS is a standard attack when a client connects to a malicious gateway. Replace USB hijacking and similar buzzwords with plugging network cable to a malicious router. Now you have a computer plugged into a gateway that you own and there is no need to discuss priorities of different subnets. Similarly, you can bring your own wifi access point and hope that clients will reconnect to it. Of course you are screwed if they use radius.

The implications of running unencrypted traffic through an untrusted gateway are well known. Such gateways you see in coffee shops, hotels, airports, etc. On the other hand, online banking (that everyone advises against) is safe if https is used.

Regarding priority, link local addresses are always higher priority that ip on different subnets. For example, if you are on a 192.168.0.0/24 subnet with a gateway at 192.168.0.1, then your traffic destined for other machines on the same subnet never hits the gateway. In this case, the local network is the entire ipv4 range.

Static routes will help, yes. But they need to be properly, configured in conjunction with a DHCP client. A much simpler approach is to make sure that a DHCP client listens only on a specific interface. And of course, properly verify the DHCP server.

All these issues are well known and ages old. So I don’t understand why this is a sophisticated attack. It is a simple hijacking of a gateway.

C U Anon • November 18, 2016 3:10 AM

Not Warm ‘n Fuzzy / Anonymous / …

machines that are maintained by me or the IT guys that I know here (here = JILA, google for it).

Well, what can I say…

Jila is a traditional girls name in Persian and like many names that are old it has a meaning as well (google “Jila meaning”). This meaning has become “Westernised” and thus Jila is now used in a slang form to describe a certain type of personality / behaviour.

The result of this is that Jila has been used for the name of “Gentleman’s clubs” where women of a certain type can be found…

Are you saying you work in a “Gentleman’s Club”?

It might account for your,

In a such perverted way no, never.

Comment in refrence to the clergy 😉

This has the potential to run and run B-)

ab praeceptis • November 18, 2016 6:54 AM

Not Warm ‘n Fuzzy

“This is what would kill this and similar attacks: …”

Would it? Let’s see. Jo is sitting at some linux box with systemd (“Another year and firefox will be built in, too”), the dhcp server is in some metal garbage box (i a company settng. At home them boxen are plastic garbage boxen) running some old creepy linux, too …

And you seriously think that a not yet implemented (certainly not on modem/router boxen running linux 2.6 …) dhcp authentication artifact based on md5 will make the whole thing somehow secure?
I assume you meant to be funny and to make a joke with us.

Btw, nothing, bloody nothing will make our systems secure as long as there are dozens of MCUs and processors in it which most of us don’t even know live in our systems and as long as 99,5% (give or take some promille) chose either systemd or one of the “we sell you completely out” company A or company B OS to run on them boxen, plus, of course, loads of crapware “developed” in languages that are all but guaranteed to deliver high levels of bugs per kloc.

But you know what? I don’t care cause I’m secure. For a measly 39,90$ I got myself a symersky “net guardian 4.0” and of course I chose wisely by buying only from a fine company like symersky who can offer a golden “100% secure” sticker.

Being the smart pro I am I put that sticker smack on my hell 3000XRS6 system (with dual nvidia gpus). I’m more than ready for them evil guys, hehe.

Sebastian • November 18, 2016 7:04 AM

Not Warm ‘n Fuzzy, all the OS would have to do to prevent this attack is to not immediately send traffic to a USB network device simply because it appeared. The user should have to enable it first.

You’d have to be careful with relying on 802.1X. It’s normally used by a client to authenticate to the network, not the other way around. It’s probably possible to use that way, but I’d also not be surprised if an OS saw a network demanding authentication and dumped your password into some weak scheme like NTLM. And if an OS is so promiscuous as to start sending on whatever adapters are plugged in, it’s probably not going to avoid the network simply because there’s no 802.1X.

I think socket APIs should let applications mark some sockets as “secure” (meaning the traffic will be encrypted and authenticated, resistant to MitM). Eventually, we could then reject all insecure traffic unless a network was specifically set to allow it—which one might do for the main home/work connection but not for coffee shop wifi or USB adapters that appear from nowhere.

r • November 18, 2016 11:39 AM

@Fuzzy Navel,

Paranoid or not, it’s one of the things that can help remotely describe an attack surface better. With the way things have been with these 9yo linux kernel bugs a linux 2.6 uname might calm my acid reflux.

Who? • November 18, 2016 11:43 AM

@ Wael

That’s certainly annoying and looks suspicious. In an enterprise setting, it’s none of my business as I am the owner of nothing. On my personal machine, I own everything, and I don’t welcome unadvertised “features”. Anything that happens on my device must happen with my consent.

Sure, it is the most reasonable approach to security. I am not against honest features that can be disabled and should be this way by default. Most features these days however cannot be completely disabled. It is a shame how our computers are not “our” anymore.

So I stay away from devices that have a “manageability engine”. If I power my device off, I want the LAN, WiFi and everything else to be off. The alternative is to unplug the device from power and remove all cables which is a hassle. Another method it to add hardware switches that disconnect or connect selected ports such as LANs. These hardware switches must not be susceptible to “remote attacks”. When the device is on, traffic must be funneled through an external firewall / switch / router that’s exclusively under the owner’s control.

What choices do you have? Open source hardware is either expensive or underpowered (most of times both of them). Soekris computers, PC Engines Apu/ALIX boards, Raspberry Pi computers, beaglebones… are better approaches but are not free from these dangerous features either.

Wrap the HW with controls that only you can manage. Assume all HW / FW / SW is backdoored either deliberately, or because some idiot developer decides to get “cutsie”.

How can we wrap the hardware with controls that only we can manage if we do not know exactly what is wrong?

Easy! Just put electric tape on the blinking LEDs! 😉

My first though was epoxy on the Ethernet port but your approach is better. We feel “more secure” with electric tape and we do not really lose privacy if we consider the huge amount of ways we are under surveillance right now.

Wael • November 18, 2016 1:20 PM

@who?

What choices do you have?

Currently, there Are some choices besides ARM in addition to what you listeD.

How can we wrap the hardware with controls that only we can manage if we do not know exactly what is wrong?

Good question! It’s unlikely we’ll ever know! You take us back four years to C-v-P! This protracted thread touches on this question and other related ones 🙂

Not Warm 'n Fuzzy • November 18, 2016 2:22 PM

@Sebastian:
Yeah, you are repeating me https://www.schneier.com/blog/archives/2016/11/hacking_passwor.html#c6738505 .

@ab praeceptis:
Artifact, md5… Where is this coming from. Go read about wpa_supplicant/hostapd and freeradius for a list of supported protocols. They are not all md5 based. And yes, it will make things more secure because you’ll add additional step of verifying the DHCP server.

Ofc, as Sebastian mentioned, the is must not automatically configure new network interfaces appearing out of nowhere. And I claim this is more or less is a default. For example, on my machine there are 7 interfaces, 2 real and 5 virtual for containers and VMs. Nevertheless, nothing sends dhcp requests on those, and I didn’t need to do anything special for that…

ab praeceptis • November 18, 2016 2:55 PM

Not Warm ‘n Fuzzy

That’s from the link you provided or, more precisely, from the link there to the rfc.

It’s there, in that rfc, that they talk about md5 (and vaguely of sha[unspecified] sometimes in the future). Well noted that is said in an rfc with very little take up/implementation.
They btw. also talk about a pre-shared secret. Pardon me, but that whole thingy looks like there is damn good reason for very limited take-up.

Btw, there is nothing in ones way to configure ones machines to use whatever gateway one pleases rather than blindly obeying to dhcp. More generally (albeit widely unknown) a client can clearly specify what he wishes to get from a dhcp server and it can also specify that only a specific dhcp server is asked. In case you are interested -> dhcp-options(5).

Which boils down to: That whole attack scenario is only working with stupid eat-everything clients and careless minimal auto-setups.

I tell you that Symersky is missing a billion dollar fortune by not selling “Symersky security linux”. With a golden sticker, of course.

r • November 18, 2016 3:40 PM

What you guys miss, is that every single core Linux distro that include ‘network manager’ e.g. the ‘desktop’ ones including the ‘penetration’ distros automatically configure wired interfaces.

Well, pentoo comes oob in silent mode but that’s the only one I’m aware of and I don’t own a pi to test this. Maybe it could be compiled for many n5 for otg?

It’s still a great display of cost of defence vs cost of attack, this type of autoconf is not the first time network manager has led to incursions.

Haven’t even ran slack, I’m sure coreos doesn’t do this either and I find myself wondering about qubes too.

r • November 18, 2016 3:45 PM

There’s also, an exploit within the last two years for dhclient? Boot options overrun, could be a diff client but to illustrate the problem you’ll find out that it affects android too.

Not Warm 'n Fuzzy • November 18, 2016 8:49 PM

@r:
Hmm, networkmanager in fedora 24 doesn’t doanything to a 2nd NIC on the motherboard, only puts it in UP state. I’d say even this is a bug, but a minor one. It definitely doesn’t run dhclient on it…

See, autonfiguring network even represents a usability issue because ppl might be unhappy about their ssh tunnels being suddenlt broken…

coreos is not really a general purpose distro, but some offspring of docker and systemd 🙂

@ad praeceptis:
That’s what I was telling since the beginning. This is a relatively simple and narrow-focused attack which has been advertised too much.

I really don’t like this PR approach…

Ratio • November 18, 2016 9:12 PM

@Wael,

In that case Intel is fine as well… 😉

Doesn’t make @who?’s (@whose?) list any longer for current devices, though.

Wael • November 18, 2016 9:21 PM

@Ratio,

There are some differences. I’m more comfortable with my choice 🙂
I should retract the “currently” from my statement. I was aware of this (think it was mentioned in another thread.) Not all engines have the same capabilities.

Just assume they’re all bad and operate accordingly.

Correct Me If I'm Wrong But.. • November 19, 2016 2:44 PM

@Sebastian

Not Warm ‘n Fuzzy, all the OS would have to do to prevent this attack is to not immediately send traffic to a USB network device simply because it appeared. The user should have to enable it first.

@Self

… isn’t this just a case of “autorun and plug and play are not always your friend”?

I.e. would this threat model effect a linux kernel configured with minimal hardware support? If there is no usbnet (or whatever) driver on the OS, does this attack still work?

I should have also given proper mention of network autoconfiguration, however I had already made the jump further upstream to device autoconfiguration.

If there are silver linings from the Trump Presidency era, I imagine one will be that people trust technology a lot less by default. I certainly think they were trusting it too much by default.

anonymous • November 19, 2016 5:01 PM

This is about logging plaintext and encrypted passwords in a dragnet fashion, when entered over USB tethering and any other form of connection to the Internet;
The PATRIOT Act (Persecuting Americans That Read I.T. Oriented Tabloids Act) violates 1st and 4th amendments of the Bill of rights; https://www.linuxjournal.com/content/nsa-linux-journal-extremist-forum-and-its-readers-get-flagged-extra-surveillance https://daserste.ndr.de/panorama/aktuell/NSA-targets-the-privacy-conscious,nsa230.html
Violating the Bill of Rights is insurrection, which is a form of treason. The death penalty is often advocated towards traitors. Rule 41 changes set for Dec.1 2016 are far more radical and militant than the human rights abuses of the PATRIOT Act.
Call your senator and leave a message asking him or her to support the “stop mass hacking act”.

Clickbait • November 19, 2016 6:30 PM

I was expecting something scary like that it would affect even HTTPS, by using BEAST/CRIME/POODLE/LOGJAM/etc, and that it would chain code execution flaws in pdf.js/flash/java/svg/stagefright/ffmpeg/etc with an escape from Edge/Firefox/Chrome sandbox and some new ROP privilege escalation that bypasses ASLR to get kernel access and install a ring minus 2 or ring minus 3 kit to them HDD/SSD firmware/BIOS/Intel Management Engine/AMD’s or ARM’s version of ME/etc and then connect back over wifi forever after the USB stick is removed, and although the attack would be sophisticated the rootkit it left would be so full of holes that over 50 random governments besides the one who made it woild get in within days and random joe blo hackers within a week.
Plus 1 to the guy who said QubeOS’s IOMMU should block this. QubesOS is the closest to reasonably secure while being user-friendly and easy to use.

Summary • November 19, 2016 7:17 PM

Isn’t this what can already be done with arp-spoofing+firesheep? It’s really hard to find it news-worthy.

Wael • November 20, 2016 11:49 PM

@Ratio,

I’m not holding my breath. 🙂

Good because I can’t say more. Wait until Zen is out and let’s see if it supports coreboot.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.