Am I correct in understanding that the device works by presenting itself as an Ethernet adapter and then poisoning the browser cache? Would the solution be as simple as an OS update that didn't use unknown network interfaces until the computer was unlocked?
If there is only one desktop user and their only session is locked, then yes. On a multi user workstation the current behavior--initiating new adapter--may be preferred.
Since no one seems to be talking about how to secure devices, I guess I'll get started...
USB devices should not accept any incoming connection when the computer is locked. The only use of USB ports when a computer is locked should be for charging devices (current out, no data in). We also need to ensure that devices that were connected before the computer was locked continue to function.
Now obviously, the issue with this would be about external devices that are connected after the device has been locked (drives, keyboards etc. - say for example, keyboard stopped working so you switched it out) but in my opinion, that's an edge case and should not cause too much inconvenience.
> The only use of USB ports when a computer is locked should be for charging devices (current out, no data in). We also need to ensure that devices that were connected before the computer was locked continue to function.
Good idea, but...
(hypothetical helpdesk ticket) Oh crap! I knocked my coffee on my keyboard and ruined it as I was sitting down at my locked computer. I connected another keyboard, but the lock screen is not accepting my password!
Allow HID class devices to be connected when locked, and that should be OK.
While I can't seem to think of a solution of the top of my head....
Sammy had an older video [0] which showed a device that was not a keyboard acting like a keyboard & mouse. While that required an unlocked computer to function, I feel like adding exceptions to a rule would just make it worse.
Another solution would be to sign USB devices (for example, Apple keyboards etc.) and only those signed devices would work when the computer was locked.
>Another solution would be to sign USB devices (for example, Apple keyboards etc.) and only those signed devices would work when the computer was locked.
Are you proposing DRM for input devices? How would this fix the problem of "Oops, messed up my keyboard, now I have to plug in a new, 'unknown' device"
At that point the measures taken by IT/helpdesk shouldn't allow for a random person to make changes to the computer security measures.
Scan your badge to helpdesk or contact local IT to do it for you. Proof of identity is required.
Social networking is another thing itself which should be guarded against in any environment, simply suggesting all you have to do is make a helpdesk ticket requires your access already be breached to be done electronically or poor protocols in IT.
Total lockdown paranoia with client security always sounds good and it is effective. But it comes at a cost. Usability in the security world lags distantly behind and gets dramatically worse the more secure you are. There's a balance that you have to strike based on risk, your capacity to detect/respond, compartmentalization and user experience.
If you have your clients locked up like Fort Knox and working in that environment makes your developers feel like they're in hell that is going to be used as a data point when you are compared and contrasted to the competition's work environment. People tell their friends from their other gigs when they find something better.
Also worth emphasizing that smart local IT people aren't universal or consistent. It's a mixed bag. Even when they are smart they are incentivized to do one thing: solve your problem as quickly as possible. Upon discovering that your friendly local IT person is meeting their SLA by cutting security corners the immediate response is to add more processes and controls with little thought to the environment that created those perverse incentives in the first place. People care about what you pressure them to care about and the pressure they get every day is their SLA/count/turnaround because there's no dashboard for how securely they do their job.
It's things like unbounded security controls, business processes and rubber-stamp approvals that take a company from a creative place to work full of smart people getting stuff done to corporate hell. It never happens overnight because it's a slow death by a thousand cuts and you realize you've finally arrived in the pit because the execs are running internal hackathons to boost innovation and creativity where the participants can't install anything on their computers or get some throwaway VMs without 9 approvals and a business justification. The things that steal our momentum and sap our creativity should have a corresponding immune system that is always trying to remove them by enforcing a justification for them, reassessing the risk, the value and whether or not they're even needed.
Requiring a reboot seems more logical and less likely to result in implementation bugs tbh. The same security measures that prevent abuse would play out as normal. (i.e. If someone physically stole the drive and put it in another computer.)
> But he has a history of intentionally withholding instructions on how to run it just to avoid script kiddies from using this not for research.
Interesting approach. Although looking at the Github it seems pretty straight forward (not being a script kiddie I can't speak for if it would be straight forward to them).
It's a vintage approach. I don't see much of this anymore, but before responsible disclosure was widely used, many exploit authors would intentionally insert small bugs (usually in the assembly payloads such as an interruption in the NOP slide) to prevent neophytes from abusing them.
Another vintage approach I see right off the bat are a few references in his code that is pointing toward Samy's own servers.... interesting he didn't obfuscate it or use a MITM server.
At the minimum, the host(victim) is establishing a websocket with Samy, so his server is aware who is being compromised or researched on.
I didn't realize PoisonTap's creator, Samy, is also the creator of the Evercookie[0], a persistent identifying cookie that remains sharded(then recombines) in your system even after clearing your cookies. While a very cool project, it has some scary implications on users not trained in their removal.
He's a prolific security researcher. Evercookie got him the fame and since then he's been researching all sorts of security vulnerabilities even on things like combination locks [1], I enjoy his video tutorials a lot.
Yeah, not sure why he was punished so harshly for something that probably didn't inconvenience users too much and was clearly intended as a prank. I do see that Myspace might've spent $20,000 or more to remediate th situation but it seems harsh to make him pay all that.
It seems that such exploit would require some kind of `network-manager` running. But if `network-manager` is disabled, and all interfaces configured in `/etc/network/interfaces`, then the new malicious interface will be just ignored. It will not come up.
Presuming you are given free access to a USB port on the computer - and as we all know once you have physical control security is somewhat out the window anyway.
>and as we all know once you have physical control security is somewhat out the window anyway.
No, just no. It's long, LONG past time to retire this bit of ancient lore, which came out of a completely different time and place in computing. These days for most users not always having physical control is by far the norm, not the exception. And there are absolutely ways to make to mitigate security issues from physical access, that is after all the entire point of technologies like full disk encryption. FDE is completely pointless if physical security can be taken for granted, it exists entirely because physical security cannot be taken for granted. I presume you don't spend your days advocating nobody bother "because it's pointless anyway."
Technologies like specific CPU/SoC/chipset level hardware security zones, HSMs, use of IOMMUs and the like to prevent DMA from ports, etc. are all there in part to help prevent or mitigate certain physical attacks. For that matter, simple locks and/or sealing of computer units aids with both making attacks more difficult, slower (another key part of threat mitigation) and, just as importantly, making them noticeable. The final fallback of a good security system is to at least try to let the owner know that it broke if all else fails. There is a certain amount of disgruntlement amongst some tech people at highly sealed devices, but they do make it significantly more challenging to perform certain physical attacks quickly or undetectably.
So yes, anything which unexpected speeds up physical attacks, renders them less/unnoticeable, or both, is a legitimate issue. Normal users of portable systems should be able to expect that, under normal circumstances, they can warm lock it (screen lock, put it to sleep), leave for a few minutes, and have a low likelihood of a low energy persistent evil maid attack being pulled off in the mean time. Treating modern security like it only needs to consider servers stashed in a secured room/data center is wrong.
This is much faster than other ways of cracking a computer though. I can see this working while someone steps away for a few minutes.
Say you go in for a job interview at a company and the interviewer leaves for a minute with their computer locked but still on their desk. Most traditional methods would require you to move to the other side of the desk or pull the computer to you which is risky, but with this you can just reach over for a few seconds.
Not to mention many traditional attacks require rebooting the computer to a bootable CD which will be suspicious if the user has an active login system and all the sudden all their apps are closed.
Or say you are at a doctor's office and there is no CD drive and rebooting the computer would be suspicious. I'm left unattended in exam rooms with computers all the time.
I also imagine it could be fairly easily modified to act like a USB hub and be inserted between the computer and a legitimate device.
Edit: Think of how less dramatic the scenes will be in Mr. Robot and the like if the "hacker" doesn't have to rush to get back to their seat just in-time for the target to get back to their desk.
Imagine this built into a USB-C power adapter you could loan to a coworker, "leave behind" or install into a co-working space or coffee shop. Don't even need physical access in that case, just need to be a "Good Samaritan".
To expand on that, you could just allow keyboards and not enable other devices but then how do you log in if your login is a network based... now you have to allow network cards. And now this hack is just as effective.
I believe there is a proof of concept evil USB device that looks like a USB key, but actually emulates a keyboard and enters all sorts of damaging keystrokes when plugged in. So allowing keyboards is dangerous anyway (although having the screen locked should help).
This is the reason why keyboard/mouse connectors should look different to USB connectors, so we can tell the difference.
Not really. By the time you make those signals provide feedback about your task rather than just whether Caps Lock is on, you'll have already accomplished your task and be into the part of the process where you're trying to download or compile some hack to use code to send something useful along Caps Lock signals. It's not a useful feedback mechanism when getting the feedback is an order of magnitude or two harder than the task you're trying to perform in the first place.
What if you're not logged in on the console, but have an SSH session open over the network? Does that count as 'logged in' or not? Imagine a server under a desk with no monitor attached. Or, a thin-client situation, where I am logged in to a virtual console over VNC or RDP or X, but have no access to the actual machine's USB ports?
> and as we all know once you have physical control security is somewhat out the window anyway.
This is such a defeatist attitude, and it has also proven to be (mostly) false by Apple and its iPhones. If we stopped saying that every time there is a hack like this, perhaps companies would actually give a damn to make sure it doesn't happen anymore, or not nearly as easily.
It's one thing to pay from tens of thousands of dollars to a million for modification of a chip in a factory or with highly-advanced equipment, and it's quite another to just insert a USB stick into a random PC and hack it.
That was an iPhone 5C. These didn't have Secure Enclave inside them, and it still wasn't an easy feat to access the device - they probably had to disassemble it and copy the flash storage straight from the chip to do it, unless they've used an unreleased 0day. If it were an iPhone 5S (3 years old) or newer, they wouldn't be able to access the data on the device at all.
As a writer who just included a plot device of providing a loaded USB flash drive as temptation for a target to pick up and plug into their computer and deliver a payload, I'm exceptionally pleased this device reaffirms the risk of malware being deployed by way of USB ports. From time to time it's hard as a writer to try and pick tech and things that hopefully won't sound dated, or if they eventually do, will at least fit within a specific story's time-place-world-setting.
I think I recall seeing that one of the pathways of Stuxnet was thought to have been a found USB stick, so yes I think your hypothesis aligns with my studies as well. Humans are so much more weak protocol wise, kind of sad and funny at the same time.
> The primary motivation is to demonstrate that even on a
> password-protected computer running off of a WPA2 Wi-Fi,
> your system and network can still be attacked quickly
> and easily.
Generally, once an attacker has physical access to your machine, you're already owned.
However, something like this would make insider threats a bit more dangerous. Leaving your laptop at your desk when you go to a meeting or to the bathroom is perfectly normal, and if a coworker can sneak in and break into your machine while you're not looking, that's a game changer.
I don't see how this device is in a more privileged position than the router your system is connected to. The way I see it, any vulnerabilities used in this attack are MITM-vulnerabilities plain and simple and need to be fixed regardless of this specific attack. Am I missing something?
If the router you are connected to is a WiFi router, then this device is indeed in a more priviledged position because as a LAN connection it will have precedence over WiFi.
Well yes, but that's not the kind of privilege I had in mind. The router could have used the very same attacks with lower risk of detection. So unless you can trust the network you're connected to (which is rare) this attack is not any more dangerous than any other MITM-attack.
I like the attack for how it combines different methods. I just had a hard time understanding the risk from that article.
There is a lot of cool hackery going on here but the most beautiful part is how it tricks the target computer into thinking that the entire internet is directly connected to the computer via the USB ethernet interface (I think, I thought the 128.0.0.0 subnet would mean half the addressable space? I've never gotten to 100% understanding of subnets). Although the deception relies on the priority in routing (LAN over outside), it's still a real beaut.
OpenVPN uses the same trick to establish a higher-priority default gateway:
def1 -- Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.
This works because routing tables prioritize "tighter" routes. I do think that 128.0.0.0/1 would only map to 1/2 of the address space. I cannot find the isc-dhcp server config files in the source code to verify. :disappointed:
Is there some way to configure network-manager to not autoconnect to new ethernet adapters that show up? I don't mind clicking the nm-applet dropdown and clicking on the device...
If you concerned about security, you should have full disk encryption (FileVault) turned on and be powered down anytime you walk away. Though you question still has value for the low percentage of times one forgets to power down.
