Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
Weekly Edition
Return to the Security page
| |||||||||||||
Attack of the killer iPods
Apparently, the latest security threat to the enterprise is Pod
slurping. Gartner recommended banning portable storage devices,
including iPods, last
year, but Abe Usher has taken it a step farther by providing a
proof-of-concept application called slurp
that could run off of an iPod or other portable storage device. Usher
paints a scary scenario to put the fear of iPods in all of us:
An unauthorized visitor shows up after work hours disguised as a janitor
and carrying an iPod (or similar portable storage device). He walks from
computer to computer and "slurps" up all of the Microsoft Office files from
each system. Within an hour he has acquired 20,000 files from over a dozen
workstations. He returns home and uploads the files from his iPod to his
PC. Using his handy desktop search program, he quickly finds the
proprietary information that he was looking for.
A scary scenario indeed. We put slurp to the test, to see if it is indeed
that quick and easy. Usher's slurp.exe runs off of the portable storage
device and copies documents (including *.doc, *.xml, *.xls, *.txt and
others) from the " Indeed, slurp.exe works as advertised, searching the target computer (a Windows XP machine) and copying all Office documents from the target directory to the USB drive in less than a minute. (Admittedly, there were only a dozen or so, so target computers with hundreds of documents may take more time.) While testing, it also occurred to us that slurp could also provide a valuable legitimate use by allowing users to back up their Office documents to work on them at home. Note that Usher's slurp.exe is "crippled" to only allow a user that's logged in to copy documents, and maxes out at 200 files. Usher calls for organizations to put several technology- and policy-based countermeasures in place to reduce the risk of data theft with portable devices. We agree with Usher that organizations with sensitive data should have strong physical security to prevent intruders from gaining access to systems. Usher's scenario - an unauthorized visitor snooping through the office unsupervised - shouldn't be allowed in any workplace that needs to enforce data security. Restricting removable storage devices, however, may be much more difficult -- and ultimately futile, since they're easy to conceal and users with physical access to machines also probably have access to other means for sending sensitive information off-site: e-mail or uploading files to web-based storage, for example. Keeping unauthorized users away from systems is one thing, preventing a disgruntled employee from removing documents is another. Usher's technical suggestions are also interesting. He suggests disabling USB connections in the system's BIOS, using encryption, keeping corporate data on protected network shares and using third-party applications like DeviceLock to lock down access to USB and other removable devices. Administrators who wish to disable USB connections in the system bios will also need to password-protect the BIOS to prevent a user from simply re-enabling it. Use of encryption for sensitive data is certainly recommended, though training average PC users to actually utilize encryption may be more easier said than done. Keeping data on network shares only works if there's a way to prevent the user from copying the data to the local PC or sending it off-site via the network. Third party apps like DeviceLock are only useful while a PC is running -- so a user who reboots the PC and uses a live CD of some kind is going to be able to bypass DeviceLock rather easily. The possible abuses of portable storage devices like the iPod should be taken seriously. The ability to copy tens of gigabytes of data onto a pocket-sized device is certainly a threat to organizations with sensitive data to protect. However, it wouldn't pay to focus on portable storage devices alone. There are many, many ways that someone with physical access would be able to compromise an organization's security. Banning iPods and other storage devices, without a comprehensive security policy that covers other possible attacks, is likely to do nothing more than annoy employees. (Log in to post comments)
Attack of the killer iPods Posted Jun 23, 2005 3:14 UTC (Thu) by dmarti (subscriber, #11625) [Link] Software doesn't fear getting fired or sued and computer processing time is cheap.
People do fear getting fired or sued, and their processing time is expensive.
The kind of "defense in depth" models that work great to minimize damage from compromised software are less appropriate to apply to people.
Attack of the killer iPods Posted Jun 23, 2005 3:27 UTC (Thu) by mrshiny (subscriber, #4266) [Link] So, the problem is that people can attach removable storage devices and copy data to them?
Seems to me like a simple solution would be:
Then it wouldn't matter if a thief took the whole machine, there's nothing on it and no way to get it without breaking some other, supposedly secure, component.
If an attacker can run an arbitrary program on your desktop, you are already toast.
You can also make it harder to compromise the local machine by only allowing hard-drive boots and setting a bios password. On some machines bios passwords are stored in NVRAM (IBM thinkpads) so even taking out the bios battery won't clear the password. For the truly paranoid, install case-open detecting hardware.
This is just the same old physical security problem we've always had, except that iPods can hold as much as Johnny Mnemonic now. But in the old days, copying files to floppies, or network-transferring them to another computer, or installing keyloggers... all these things are old news, really.
Attack of the killer iPods Posted Jun 23, 2005 9:56 UTC (Thu) by ayeomans (subscriber, #1848) [Link] Simple in Linux maybe. But LWN readers are spoiled, try doing it in Windows!
Personally I prefer a thin client approach, since if the dataset is that valuable, you never want it to appear in its entirety at the client. There are many theft routes, even a passive network sniffer will do the job. Instead, let the application run on the server, providing screen views of only the data that is authorised to be accessed. You can't easily stop the digital camera or photographic memory, so don't provide all the data in the first place. And don't forget the printer or email routes to get the data out.
Again, quite easy in Linux, but rather harder to plug all the holes in Windows.
Attack of the killer iPods Posted Jun 23, 2005 12:06 UTC (Thu) by mrshiny (subscriber, #4266) [Link] Actually, I'd say it's fairly easy to set policies in Windows to prevent users from storing data on local machines. One place where I worked tried to apply this policy to developers, who are among the few that need to use local storage and need to install softare locally. Needless to say that policy was not well received, but my point is that Windows provides the tools. As for digital cameras and email and such, those will only help if the workstation in question is logged in; since most workstations that run Windows use some flavour of NT, it's trivial to lock the workstation and require a password on login. Microsoft may not ship XP with the most secure settings out of the box, but it's easy to turn them on; much easier than trying to disable USB devices.
Attack of the killer iPods Posted Jun 27, 2005 13:05 UTC (Mon) by thompsot (guest, #12368) [Link] Agree 100%. Thin clients make more sense in more ways than I can count, and a well thought out set-up makes having light-duty-server class, power wasting, incredibly insecure, virus/spyware magnets on each desk seem ridiculous (not that it doesn't seem ridiculous already).
Example in recent news Posted Jun 23, 2005 3:57 UTC (Thu) by pengo (guest, #7787) [Link] Hao Feng Jun who abandoned his post in China, where he worked for the branch of a security service known as 6-10, set up specifically to wipe out the Falun Gong spiritual movement, defected to Australia with government documents stored on his mp3 player.
If authentic, the documents appear to back claims made by former Chinese diplomat Chen Yonglin, who says China has a network of 1000 spies operating in Australia.
Would any of the measures in this article have helped the Chinese govt to repress Jun and these documents? It seems doubtful.
Chen's application for asylum in Australia was rejected and he was advised to apply for the protection visa, which is being considered.
Attack of the killer iPods Posted Jun 23, 2005 6:21 UTC (Thu) by euvitudo (guest, #98) [Link] I'm not (as you'll readily see) knowledgeable with respect to how USB devices operate, hence the following question, and scenario:
Is the USB device anything like the CDROM, where when you pop in the cdrom, Windows runs the autorun (or whatever the name is) executable?
If so, then all you would have to do is to rename slurp.exe to autorun.exe (again, whatever the name is), and have Windows automatically run the program, which subsequently searches and copies all relevant files to the device. In that case, you wouldn't even have to have login access to the computer (maybe?).
Again, this shows my total ignorance wrt USB devices and how they work in Windows.
Yes Posted Jun 23, 2005 7:26 UTC (Thu) by pengo (guest, #7787) [Link] Yes, USB devices work exactly like CDROMs in Windows. You connect the USB device and it will run autorun.inf. e.g.
[autorun]
You can also boot from a USB device, if the BIOS is configured correctly.
Yes Posted Jun 23, 2005 14:57 UTC (Thu) by Ross (guest, #4065) [Link] That's just amazingly bad design. They should have learned from the autorunproblems with CDs, and the auto-exec problems with Word and Excel macros. Does Microsoft just not care or is there some kind of benefit to doing it this way?
USB/CDROM autorun Posted Jun 23, 2005 19:39 UTC (Thu) by giraffedata (subscriber, #1954) [Link] How can that be? System designers go to the trouble of having power on passwords, disk drive passwords, Windows logon passwords, and screen saver locks, not to mention physical locks on the box, and you can put in any CDROM or USB device and the system will happily run any program on it? Surely it's harder than that.
USB/CDROM autorun Posted Jun 24, 2005 10:15 UTC (Fri) by bronson (subscriber, #4806) [Link] Well, you can turn autorun off. But most people don't, and it's on by default. Yes it truly is this easy.
Wow Posted Jun 27, 2005 5:46 UTC (Mon) by mbp (guest, #2737) [Link] Are these people completely insane? Or just nostalgic for the days of floppy bootsector viruses?
Perhaps they want a return on their antivirus acquisitions.
Attack of the killer iPods Posted Jun 23, 2005 9:21 UTC (Thu) by armcc (guest, #5827) [Link] s/more easier said than done/more easily said than done/
Attack of the killer iPods Posted Jun 23, 2005 19:46 UTC (Thu) by mmarsh (subscriber, #17029) [Link] These typos get fixed a lot faster when you mail them to lwn@lwn.net instead of posting them in the comments.
Attack of the killer iPods Posted Jun 23, 2005 10:12 UTC (Thu) by pilif (guest, #3857) [Link] Hi,
what I don't get is: To get that slurp.exe to work - in fact to execute any program on a computer - you have to be authorized.
So that disguised janitor may well come into the building and plug that iPod, but he will not be able to copy over any data - as he cannot login and thus cannot start that program.
The exception of course are publically accessable machines, but those should not have any sensitive data on them - and neither should they have access to them via network.
So the only way to really get to those documents is by hardware-modification (ie. take out the harddrive and hope data's on it and not only on servers), but this works as well with an ipod as without.
What do I overlook?
Philip
Attack of the killer iPods Posted Jun 23, 2005 10:56 UTC (Thu) by NAR (subscriber, #1313) [Link] What do I overlook?The possibility of rebooting the computer with a Live CD. The the janitor can bypass every security measure that is set up by the running operating system: password-protected screensavers, etc. However, if the data disk is encrypted, the janitor won't be able to access the data on it. As more and more companies replace their desktop systems to laptop, the encryption gets installed by default anyway.
Attack of the killer iPods Posted Jun 23, 2005 14:58 UTC (Thu) by Ross (guest, #4065) [Link] Or if you have a BIOS password...
RE: Attack of the killer iPods Posted Jun 28, 2005 14:49 UTC (Tue) by dvlmsd (guest, #932) [Link] I *believe* the attack works as follows:
In windows there an "autorun" feature. If a CDROM or (USB) device has a "autorun.inf" file specifing an executale, that exec will be run, whether your logged in or not, when the disk/device is mounted. In this case the executable simply searches the disk for word files and copies them to the device.
Security vs. Pissing people off Posted Jun 23, 2005 11:23 UTC (Thu) by brother_rat (subscriber, #1895) [Link] One thing I've never understood is the desire of IT people to "lock down" systems in ways that don't actually make the system any more secure, but do actually cripple useful features.
The number of windows machines where pressing "winkey+E" gives a messages saying "You can't do that due to restrictions placed by the system administrator" (or words to that effect) but you can just right-click "My computer" and choose explore.
or computers where you can't change the refresh rate of the screen, and it's set to 60Hz or less :-s
There's almost always ways around those kind of restrictions for a determined user, so why get in people's way.
Attack of the killer iPods Posted Jun 23, 2005 13:10 UTC (Thu) by davecb (subscriber, #1574) [Link] You don't need ane excutable to slurp up all files matching a pattern from Windows onto a memory stick: a teacher friend (Hi, Ken!) does so daily with a script which runs xcopy.--dave
Linux Secure Autorun.sh.pgp? Posted Jul 2, 2005 2:47 UTC (Sat) by AnswerGuy (guest, #1256) [Link] I find myself pondering the notion of a Linux hotplug script that could do something like run a GPG signature check on a detached autorun.sh (or autorun-linux.sh) signature against a specific key ring; and then run said script if (and only if) that signature was valid.So I have /etc/autorun-linux/keyring.gpg and plugging in a USB drive (or other removable media) invokes hotplug (or some autofs behavior) which runs my script; which checks for an executable of the right name *and a detached signature* and, if the signature check is good, runs it (as root or, optionally, as some other user --- subject to some settings --- perhaps in an /etc/autorun-linux/conf file).
Seems like it gives one all the convenience of autorun files (I could even have a conf setting that allows me to run unsigned autorun files as a specific 'noboby" user; perhaps even allowing that to pop up an xnest window which, in turn, can run any GUI stuff it wants in its (nested) X server while limiting the access of the xnest client to the user's own X server. (That last might require some specially limited Xnest --- perhaps some sort of Xnest-secure or Xnest-untrusted program).
At the same time it seems reasonably secure.
Thoughts?
I must be missing something; it seems too easy.
The simple case seems like it could be implemented as a simple shell script.
Jim
|
|||||||||||||