Physical Access...
...... nuf said.
How do you get a sniff of a locked computer? Tell it you're its gateway to the entire Internet IPv4 routing space. That's the basic principle behind a demo from brainiac cracker Samy Kamkar. Plugged into a victim, his Raspberry Pi Zero-based "PoisonTap" isn't just a network sniffer, it's a backdoor-digger. MacOS users can …
If it's similar to the hospital I work in, the machine will be all kind of locked, possibly including a strict "no external network access" policy, so while you could perhaps plug the attack vector, your attack timeframe would be the time you can leave the device attached to the machine without being noticed. I'd say a couple minutes at best. It COULD be enough to get credentials to the internal data management system (holding patients info etc) because almost everyone uses web interfaces for that nowadays, but hopefully you won't be able to log in from outside the local network.
I really fail to understand how this is news: this is how things are designed to work, and this is how they have always worked: The moment I can override the local DHCP server (e.g. by winning a race on the network wire, or by inserting myself between the rest of the network and the victim), every computer which blindly trusts a DHCP response is mine. This is exactly how things should work in a low-security environment, where the ease of use is given the priority.
Every system or network administrator worthy of their Christmas paper hats also knows how to avoid this behavior if it is undesirable.
Sure, this whole bit of "research" would have been a nifty contribution at a school science fair - after all it does demonstrate the basic understanding of how the things work and some creativity. But being a highlight IT security conference and getting international press coverage? What's next, a discovery that by knowing a magic 32-bit secret code of a computer I can open a remote connection to it from anywhere in the world?
I really fail to understand how this is news: this is how things are designed to work, and this is how they have always worked:
It isn't though. NT would never have been vulnerable. Linux itself (or any other Unix) still isn't, rather it is the desktop cruft too often layered on top that gets caught out. All those things dumbed-down systems do to "help" such as auto-configuring everything in sight, automounting any filesystem you come across and so on - often they are exactly what you want, sometimes they get in the way, and sometimes they increase the attack surface.
It's the old usability vs convenience thing. Yes, it's that old chestnut.
Linux itself (or any other Unix) still isn't, rather it is the desktop cruft too often layered on top that gets caught out
I can't speak about Windows in any of its forms, but regarding Linux you are wrong, wrong and wrong. IP addressing and routing is handled inside of the kernel, the desktop software does not know anything about it unless it explicitly queries it. Certainly IP packets generated by the desktop (or any other service running on a Linux system) are automatically routed by the kernel to the appropriate network interface; what we are seeing here is an example of how it is possible to manipulate the internal routing tables in order to gain unauthorised access to the network packets.
I agree with other comments however; this is the way that DHCP is designed to work, and any sysadmin worth his salt will know how to eliminate the risk to his key network devices (hint: static IP addresses and high-priority routing table entries).
@alannorthhants the thing with Linux is that there is plenty of cruft on top of the kernel, which upon appropriate notification from udev will update configuration as they seem fit, not necessarily asking the user for permission. Examples here and here. Yes of course these things only do as much as they are setup to do, but under "wrong" circumstances it can be just enough to e.g. make an ad-hoc USB device a default gateway.
"regarding Linux you are wrong, wrong and wrong"
Only up to a point. As you say it's DHCP rather than the desktop cruft but the final point of convenience vs security is the significant one. Ignore at least one of those wrongs.
I stand by every word of what I wrote. The kernel itself will enumerate the device and generate a notification. It will not activate the interface by itself and won't spawn DHCP requests.
If you have userland code running with admin privileges that does that and malconfigures the system for you automatically that is where the problem lies: this stuff doesn't happen by magic, and yes those notifications are generally intercepted by the desktop environment in the name of convenience.
>>"If you have userland code running with admin privileges that does that and malconfigures the system for you automatically that is where the problem lies"
Well, out of the box GNU/Linux systems normally would. That's the thing. Configure GNU/Linux to not accept any old DHCP server and it wont be vulnerable. But the same is true of Windows. If the criticism is that default settings are not adequate, then that applies to most GNU/Linux distros just as much as Windows. If the defence is that you can configure it more securely so this isn't an issue, then that too applies to Windows.
I think you are going about it backwards. dhclient is only in the picture if your ethernet interfaces are marked as auto or hotplug or some such. For a fixed link, you might prefer to manually configure things and fall back to "not connected" if you find yourself at one end of an unfamiliar network. But now we are back to the choice between secure and convenient.
Likewise, in the Windows world I believe that a domain-joined machine can be made to only trust the DHCP servers of that domain, but most home users don't have a DC and MS make it even harder by disabling the facility entirely in some editions of the OS.
Afterthought: quite a lot of security problems would be solved if someone produced an ADSL router that had a Joe-User-friendly firewall to protect Joe's IoT devices, some sort of net nanny or danse guardian to keep the politicians out of the loop on content filtering, and enough domain controller software to let Joe manage all his Windows clients, which themselves would have to have the domain-disabling disabled so that they weren't recklessly insecure.
Maybe if the next Raspberry Pi has an ADSL modem onboard, it could actually happen?
Talking about ADSL is like talking about obsolete tech. like ancient phone modems, CDs and even BluRay; 21st century broadband should now be at least FttC or better FttP, and 21st century media should be on Flash and/or Cloud, it is tragic that anyone still has to make do with flaky ADSL now!
A broadband connection should be handled by a dedicated router with proper security (NAT, firewall, DoS protection), something a Raspberry Pi can't do, especially with only one /slow/ Ethernet port, so can't act as an Ethernet filter!
This is the old DSL Nation modem fugly DHCP hack - in its native form it does not work on Mac.
What the guy missed is that USB is actually "shared" media - you can present TWO usb interfaces to the host. 0.0.0.1/1 and 128.0.0.1/1.
Bingo. Mac joins the other ones as pawned too. The guy should have thought a bit more in depth on what is happening instead of blindly repeating the old DSL Nation madness.
Fairly trivial to defend against too on Linux - you can (and should) configure it to reject anything larger than class A. This is a 3 liner in /etc/dhcp/dhclient-enter-hooks.d/
This post has been deleted by its author
This post has been deleted by its author
According to the article- it's mac and windows computers that are vulnerable...
Yup, via the age-old "let's make it easy to set up a new interface" - good reminder to find out how I can lock down access to USB ports for anything but authorised devices on my Mac. Not that I'm much at risk, but because I can. And thus should :).
From what I understand, a Mac with FileVault enabled will not be that keen to mount any external device when it's asleep - apparently that's part of the extra security measures you trigger when installing FileVault.
That said, when it wakes up it still may do it when you log in, so you'd have to be careful that nothing extra is plugged in when doing so but if you're already using FileVault and a boot password I suspect you're not the average, not terribly cautious end user anyway.
But it's a risk, and ought to be managed. Apple should ensure a machine can only add a device when the user is logged in and the machine is not on screen saver lock or in sleep mode - at that point the user only has to make sure the machine goes to its logon screen when leaving it and that can either be done manually or via, for instance, a Bluetooth lock (no, I don't like the Apple Watch thing - I just have a small app that detects how far away my phone is, and that require manual unlocking with a password - just how I like it).
Well you could allow and disallow USB from a central management console as many business AV/Threat management systems do, or you could just allow HID devices which are generally allowed anyway at a lower level.
However the ol' HID keylogger trick is still at risk for that one.
Everyone knows you can use a raspberry pi to turn on an LED, so we can put one in a black box, mount an LED on it and voila, the internet in a box....
Now all we need is a few orders of magnitude increase in the amount of data we can squeeze onto a micro SD card...
Adding
echo 1 > /proc/sys/kernel/modules_disabled
to a local boot script will stop any more modules being loaded. Unless the driver for the USB is the same as one used by the system (unlikely) nothing will happen when it's plugged in.
It only stops *new* modules being loaded. Load any required kernel modules (e.g. usb-storage) first , then lock down.
Perhaps not the right answer for a developer's system, but very useful for e.g. a system in a doctor's surgery, as was mentioned earlier, or a system in a PCI DSS scope.
But you're inserting it in a BOOT script. If that command gets triggered before the USB root hub is awakened, you probably can't modprobe the hub driver, which means the keyboard and mouse don't awaken, either.
And that's why many people hate SysV. There's no real dependency system in it: just timings which can go wrong.
There is no reason why you should run an DHCP client and believing its claim for a default gateway for network interfaces suddenly appearing.
I mean I can see a point for USB devices posing as a NIC in order to provide some user interface, but for gods sake, ask the user before you accept a new default gateway, particularly if you already have one. (ask if this new device provides Internet or something) Or better yet, don't automatically run DHCP clients on interfaces that are not configured.
I get the DHCP part, but how do you get the legitimate site data to display while the box is plugged in? Or is it just that you spawn the magic web frame and then pull the fake interface, so normal routing can resume? If someone hops on the computer with an extra USB dongle and no functional networking they are sure to notice...
...in the first place...
But anyway, if the computer is already running and logged onto the LAN (via a fixed IP address), why would the sudden presence of this device on the USB bus cause it to get all promiscuous and have to have a DHCP address assigned from it?
There doesn't seem to be an icon suitable for my level of lack of knowledge and confusion on this topic.
1) New device plugged in
2) "What are you"
3) I'm an Ethernet network device
4) "Oh, pleased to meet you. You seem to not have an IP address, I will request one via your link, if you please"
5) Sure go ahead
6) "Oh, here it is. You seem to be doing quite a bit of routing, too"
7) Yes, my parents always told me I was a bit of an Attila
8) "Ha, ha, you seem to be of the funny kind. All right, here is some traffic for you..."
The scenario isn't that far removed from a legitimate one: that of a VPN. That too is a new interface that appears after existing connections have been established, and that too is an interface that could reasonably be given priority for packets routed to a subset of addresses.
It's not clear to me why the vector even needs to be USB (aside from the convenience of power). Why not use the existing ethernet port on the device? Takes away any of the problems of requiring any drivers to be installed.
You'd need a USB->Ethernet dongle for the Pi to give it two sockets, but would surely be a much neater man-in-the-middle attack and could achieve all of the same exploits.
I suppose it's just a case of "because I/we can".
ARP spoofing is still a thing. If you can connect to the same network segment, you can craft packets that make other machines on the segment associate your network MAC address with the IP of the real DHCP server. From there, you just run a DHCP server giving bogus IP addresses and routing information so that you can "man in the middle" machines the next time they renew their DHCP lease.
I suppose that a USB-based attack is probably going to be quicker. If it auto-configures, then there's no waiting around for existing DHCP leases to expire. As an attacker, you still have the problem of needing to connect to the local net segment and doing traffic forwarding (masquerading as the target machine) so that the user (and any running applications) doesn't notice any discontinuity.
Given that both methods need physical access to the LAN, I think that a Breaking Bad style device (that Walter White plugged into his DEA brother-in-law's PC Ethernet port) is probably the best approach, though I'm sure that it will need some sort of power supply.
Unplugging and replugging the LAN cable (to insert the Pi) would normally have it renew a DHCP lease anyway. And connecting to the local net segment would be simple enough - the 'other end' of the Pi would be plugged into the office LAN cable.
Even more handily, you can stick a wireless card in the Pi and have it connect to van outside the office window, should it be in a locked down corporate network to offload any data you manage to nick.
I have been playing with the hack that snags user information along with the password hash using the pi zero on a locked machine and the main issue I have is the driver is usually not available by default on the pc. So a PC that has already been setup and can see the pi as a USB Ethernet gadget could have this work but I don't see it hitting a lot of machines. Get a LAN turtle and have a lot more success with man in the middle attack like it will allow. :)
Any exploit that requires physical access or using an USB connection is a lower priority problem compared to phishing, macros, malware ads, etc. which only require the user to make a mistake once. Also, an exploit requiring physical access is not one that will be used against random users; it is more likely to be used against specific targets.