Hackers pierce network with jerry-rigged mouse When hackers from penetration testing firm Netragard were hired to pierce the firewall of a customer, they knew they had their work cut out. The client specifically ruled out the use of social networks, telephones, and other social-engineering vectors, and gaining unauthorized physical access to computers was also off limits. …
It is not just USB peripherals. Another standard one is plug which goes instead of the keyboard connector into the KBD socket on a laptop motherboard and does MIM to the kbd signals at the lowest (scan) level. While it is more convoluted, having a set of Apple, Dell, Lenovo and HP is usually sufficient to make sure you have everything you need at a conference. Most transmit/receive data so the guy from a well known competitor in one particularly well known country a couple of rows behind you is quite likely to be getting a full dump of everything you are typing stored on his laptop.
So - never leave a laptop unattended and carry a prehistoric beast which nobody has any "ready baked" backdoors for. An Apple Mac G4 or some more esoteric chipset intel/AMD laptop (early HP NC40x0 series) can do the job quite nicely. The more esoteric - the better. That's why I keep my G4 and NC4000 and always use them on the road. From a security perspective both of them are becoming priceless.
There is nothing wrong with it if it is not the only thing you rely on.
First of all, adding a bit of "security through obscurity" to a properly set-up defense in depth has never hurt anyone.
Second, the guys who plug the MIM dongles onto the keyboard cable do not have that much time to do that. It is enough to hinder them sufficiently to get the job done. From that perspective, a blob of epoxy on the keyboard retention bolt of a "conference" laptop can go a very long way. Ditto for a bit of superglue (or even better - epoxy) in the correct places on the laptop keyboard, pad, etc ribbon cables couples with marking the keyboard. And so on. I know quite a few companies that do the epoxy routine on any equipment taken by their employees to that particular country (and they dispose of them upon return anyway too).
Security through obscurity is just as useless as engaging in the standard technology war.
It's more interesting if you can detect an event and then pollute the dataset it transmits - from what I've seen so far, most of the sophistication tends to lie in the trojans, not in the back end (that's also why they get hacked so quickly, which I find amusingly ironic.
Pollution isn't just fun, it also devalues the data and so damages the financial basis on which these people operate - you cause a strategic hit on root causes instead of fighting a tactical battle with symptoms.
Strategic approaches are much more entertaining and effective.
"As with all these "new device" attacks it could be stopped by locking or closing all the external ports, which hardly ever seems to happen."
Not yet, no, but will do soon. In fact it surprises me that larger corporations still let users plug anything into their PCs at all.
The device used in this attack reported itself as a standard Logitech mouse. This is what I get for an HP Mouse on my machine:
root@whitestar:~# lsusb | grep -i mouse
Bus 002 Device 003: ID 046d:c001 Logitech, Inc. N48/M-BB48 [FirstMouse Plus]
Surprise, surprise, it is actually Logitech.
So they actually chose the right device to emulate. It would have probably gotten past a reasonably tight group policy on Windows or a udev filter on Linux.
In fact, anything short of strict matching of keyboard, mouse, etc serial numbers to a machine would have failed to stop this attack. Both Windows and Linux possess the means to implement such matching. I really would not want to be on the helldesk in a shop which uses it though. It is a nightmare to maintain and a nightmare to set up too because not all USB device drivers return serial numbers. In fact HID does not at least on Linux (probably same on Windows).
That is exactly why large corporations cannot implement it. The larger the shop, the more dependent on helldesk throughput. Add to that the fact that most shops have implemented the whole ITIL shebang for anything going through the helldesk even if it is as small as changing a mouse. As a result, bolting the policy down to serial numbers will create a tsunami of change control schmutz which will wash away both the helldesk and whoever had the smart idea in the first place.
In order to emulate a keyboard *and* a mouse, one would have thought that you'd need a USB hub chip in there too, at which point you have a policy that could deny the use of hubs, probably.
I may be wrong of course, there could be a way to have mouse hardware + teensy pretend to be a logitech composite input device. But either way, to be able to send keypresses I have a feeling the system needs to recognise it as slightly more than a mouse.
Unfortunatly a lot of PC's now days have USB hubs built inside of them, that is how you often get ports on the front and back of a machine or get multiple ports. One controller, then a hub into which you can plug devices. You could probably setup each machine type to reject any new hub though...
Amazing story, but now the Net has become yet an even scarier place!
I hope they were well rewarded for their success for this assignment, but it opens up another box of nastiness.
Fortunately it isn't yet possible to download such a mouse through a drive-by attack..
(though a real drive-by attack throwing these mice at people might have some success!)
"...the device would still need to be able to run privileged code"
All the clever stuff is run on the device itself - on the target system, it only needs to use standard applications to which the user would normally have access - but it would need to "know" the OS and what applications are available.
The objective here is not to modify the system in any way, it is to steal information from the user and his/her organisation. All that is needed is to use a standard application to upload interesting files to some site on the Internet - maybe using a minimised browser window to upload files to a hacker's account on Google Docs (using ssl), for example.
And it's not as if your average bofh doesn't receive a free mouse once in a while.
Plug it in to your Linux desktop and let it work normally.
Then just wait.
Very soon, your bofh will su as root to perform some admin task
BOOM!
There are only degrees of safety, and anyone who relies on their own smugness will suffer, probably sooner rather than later
Something pretending to be a USB mouse won't be able to intercept the keystrokes on the keyboard that your BOFH is using to su root. So it won't know when to launch its attack code.
Of course, a similar attack with a "promotional" Logitech keyboard is trivial.
Perhaps all BOFH's should restrict themselves to remote system administration in fuure, ie never su on the local keyboard, and instead from their administrator ultra-secure PC do
# ssh root@targetpc
where targetpc has appropriate firewall rules and sshd_config entries to make this possible only from the authentic BOFH mission control console. Then we're OK provided the BOFH knows better than to use promotional items for mission control....
Until the attacker bribes a cleaner to put a hardware keylogger in the rats-nest behind the BOFH's mission control station, that is.
Linux has a unified HID driver which is same for Keyboard, Mouse, UPS and anything short of washing dishes.
I have not read the code of that particular driver, but I would not expect it to filter keyboard events coming from a mouse or vice versa.
On top of that Linux does not query serial numbers in HID so you are least likely to be able to bolt down your computer to work only with "your" mouse and "your" keyboard.
Presumably it's a question of the code embedded and it seems highly probable that this could be programmed to detect the OS and other aspects of the system on which it is run and tailor the attack appropriately. The user not being root doesn't seem a big problem either if it contains a zero day privilege escalation attack, or can run its intended malicious payload within the user login context. After all, the target is more likely to be the network than compromising just one machine on the network.
At my last contract, the guy at the very top of this international NGO demanded that policies were altered for his email and network accounts such that he could "use the same 4 letter password that he always uses". After a very short but valiant fight, the IT manager complied, for fear of damage to his career.
Most of us have probably heard of this, but
Quoth Mike Sphar on 1999/10/05 in the Scary Devil Monastery,
(Is it really 12 years old? The more things change, the more they stay the same)
I think that we should officially make this the sysadmins credo. We'll
call it "The Abigail Oath" and require all new sysadmins to swear it.
Well, without the layoff part, maybe something like this:
I am hired because I know what I am doing, not because I will do whatever I
am told is a good idea. This might cost me bonuses, raises, promotions,
and may even label me as "undesirable" by places I don't want to work at
anyway, but I don't care. I will not compromise my own principles and
judgement without putting up a fight. Of course, I won't always win, and I
will sometimes be forced to do things I don't agree with, but if I am my
objections will be known, and if I am shown to be right and problems later
develop, I will shout "I told you so!" repeatedly, laugh hysterically, and
do a small dance or jig as appropriate to my heritage.
http://groups.google.com/group/alt.sysadmin.recovery/msg/1d05c6aa3681e609?output=gplain
Must take my (red?) hat off to these guys, as they have upped the ante by a big amount. The same trick could be used with *any* USB device given a bit of engineering effort to have a hub & rogering-mouse included.
Mouse/keyboard (obviously!)
USB pen-drive/external drive.
Phone with USB "charger".
Printer with USB connection.
You get the idea...
I wonder how national security folk around the world are now eyeing the equipment they got from USA-based companies, made in China, handled by unknown agents, with suspicion?
How about just a USB extension/phone charger/etc cable? The plastic on the back of them's big enough to hold a flash drive- and you get whole Bluetooth adaptors that aren't much bigger than just the USB connector itself.
The Teensy board is surprisingly large for something called a 'teensy' (over an inch!), so you'd need to just wire directly to the microcontroller chip itself. But that looks far from impossible on that board and mechanical strength could be maintained by potting the back bit.
So... basically, you shouldn't even allow staff to bring in CABLES from home, much less devices, if you're paranoid about security. Or if they do bring in cables, stick a megger across the data lines to fry anything connected to them...
Sheesh, too much soldering, thanks. Just use a wifi-capable phone. Much more computing power, and it can be given as a gift (how many IT bods would turn down an iPhone4 or an HTC Desire S as a gift?) but with only the USB charging cable in the box rather than a wall-charger. Guaranteed, if it doesn't get you onto their wifi network, at some point some plank will plug it into a "secure" desktop/laptop in order to charge it. With the storage space on most modern smartphones you can run multiple hacking toolsets to cover all flavours of OS and still have plenty of space for downloading data that can later be beamed out via a surreptitious 3G call or an email. For a small(ish) fee I'll even let you in on the measures we take to guard against hax-by-phone.
You could block the cell phone installation by requiring signed drivers. My guess is the device wouldn't properly install. The user would then call IT.. they'd wipe the PC assuming its an issue with Windows, and then when the signed drivers still don't install the device properly IT would say it's the device that is defective and tell the user to take it up with the company that provided it... or turn off requiring signed drivers on that PC. Then you're screwed! lol
"Much more computing power, and it can be given as a gift (how many IT bods would turn down an iPhone4 or an HTC Desire S as a gift?) "
Get to a trade show, get business cards in return for entry to a competition, make sure your targets win the phone. I can feel a new career coming on.
Wouldn't have helped in this case, though, since phones weren't allowed.
This just proves a theory off mine, the so called "legacy free" computers with no PS2 style mouse and keyboard connectors are a dumb idea. Not to say this exploit couldn't have happened over a PS2 connection (given the microcontroller aspect) but its certainly a lot easier via USB. I've steered away from a number of recent motherboards for their lack of PS2 ports.
2 basic security rules would have prevented this attack, always be suspicious of "free" gifts and never allow users access to USB ports. This reminds me of the viruses spread by free thumb drives given away at trade shows.
wouldn't you need some way of transferring the data over PS2? I don't think I've ever seen a PS2 flash drive so you'd be looking at a more advanced version.
I guess you could do a slightly different version to take advantage of that- but this time your device would be a keyboard. Log all traffic and get the user's password that way (just pick up whatever's typed after ctrl-alt-del and before the long wait for the desktop to load, I guess).
Then wait for no keyboard activity for 5 minutes (in a corporate environment, that's probably a sign of it being on a password-protected screen saver). You can then 'type' in the user's password and gain access to their system. Just run a simple set of commands that downloads an innocuous file to the user's PC (as, say, a .pdf), navigate to it and then run it. You can then have that client software 'phone home' and get whatever malware you want from some server or other.
It can be defeated with 2-factor identification (say, smartcards), a longer screensaver time or your target using his laptop keyboard rather than the external one, but you'd presumably have clocked if they were using smartcards during the meeting where they hired you to perform penetration tests and the rest's just luck...
Alternatively, go to the toilet after the meeting and drop a USB flash drive behind the toilet. Label it "if found, please return to [smudge]. Someone'll find it and plug it in to see who it belonged to.
I've got into PS2 systems before by plugging in a device that enters "copy con: filename" then you transfer the code you want. Really it needs to be something very small and simple like a bootloader; mine then transfered the rest by RS232 because it was much easier to program a small micro to talk a standard bootloader over PS2, and transfer the real payload by RS232 from a small laptop (in this case a Zenit datasystems 8086 with built-in CGA mono screen!)
This was in the headays of PS2, when most computers still had the old style DIN connectors, maybe about '94.
The rule of lore is if you can touch it, you can (normally) own it. The VAXs however were harder...
"The VAXs however were harder..."
I seem to remember the concept of placing something in the serial connection between a user terminal and the terminal server. The device would intercept both user input and system replies. The additional feature was to use the "copy to attached printer" function to transfer files to the interception device.
Hmmm... that brings me back to the days of using an RS232 cable to transfer files between (PC) computers. Back before network cards (ether or token ring) were commonplace. I can't remember the name of the program that was used but it used a very similar method to what's described in the article. The sending side would run the transfer software and on the receiving side you'd start by typing in "copy com1 con" which basically copies input (ascii) from the serial port to the keyboard. The sending side would then "type" in a small bootstrap program which would be saved on the target computer. That bootstrap program would then copy over the rest of the program so you could get a nicer interface to show files in progress, transfer checksums so that you could detect transmission errors and the like.
The best part of the scheme was that you'd end up with a working copy of the transfer program on the target computer, so you could start the transfer from that machine to another machine later. Looking back, I suppose it's kind of funny that we were all using a kind of worm program for a useful purpose. I'd love to remember what it was called. Might have been something generic like "PC Link"?
Of course, this custom mouse does away with the need for the user to type "copy com1 con" on the receiving side, since it already is the keyboard.
This post has been deleted by its author
Neatly demonstrates the USB renegotiation function built into the newish Atmel ATMega*u2/4/6 line.
It's not really doing anything you couldn't do with an attack on a wireless keyboard though and stands a higher risk of being detected. e.g. by the anti-virus software throwing a warning when a new device is connected. I have been on sites where the leads are glued into the USB ports and any spares pasted over to mitigate this type of attack.
Its not running code on the system as such, so no this wouldnt work. Its basically sending keypresses as I read this, so the code is something like:
<wait for 60 seconds on idle time after being plugged in for [n] minutes>
<send keypress ctrl-esc>
<send keypress up arrow>
<send keypresses "cmd">
<send keypresses "[some command string]" to dos window>
<etc.>
So its relying on applications already on the machine to do its dirty work
(Well obviously trying to be quick to stop windows popping up etc., but if you time it right on delays before activating you should be good and avoid screenlocks etc. I'm sure there is also a way in the USB negotiation to work out what OS you are running on to, so you can send the right keypresses for Win vs. Linux vs. Mac)
Which basically says the default level is "disallowed" and C:/program files is "allowed". (disabled for local admins, obviously. We need to be able to install stuff)
If that is how it works, then the machine would just display an SRP error when you tried to execute the external code and the attack would fail.
I think. Probably. In theory.
I don't suppose you can get a copy of this attack code from anywhere?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
