[unisog] Pen testers after my own heart...

Jordan Wiens numatrix at ufl.edu
Mon Jul 24 22:34:53 GMT 2006

So I'm more than a little late back to this party and for that I 
apologize.  I'm also responding to my own post since there were a number 
of other good responses and rather than reply to each, I'll just put my 
follow-ups here.  Additionally, I wanted to summarize some of the more 
useful information and links in one place.

Thanks for the comments about the U3 device[1].  I actually went and 
purchased one myself and had some fun with it.  Not only can you 
re-flash it with your own ISO image in the "read only" partition (as 
Dave Ellingsberg pointed out[2]), but you can also use the U3's own XML 
configuration file to define a new application and set it to auto start. 
  One of these days I'll get a more detailed blog post up about it.  If 
anybody's interested, drop me an email off-list.  They actually _built 
the functionality in_ so folks could do that.  How considerate.

Cosmin Stejerean's idea to restrict execution from removable devices 
(think, mounting NOEXEC in linux) is a great idea.  I imagine something 
could be done like that using a HIPS or other host policy enforcer. 
Lately I've been having fun with Core Force[3], a free HIPS that you 
could use to add a rule to disallow explorer.exe from executing from 
various locations.

Still, the users in the pentest[4] that started this whole thread were 
tricked into clicking the items on the USB sticks, no autorun necessary. 
   Why go the tricky technological solution when users will gladly run 
your malware for you?  Users continue to be the weakest link.

Is disabling USB an option[5]?  In some environments, maybe.  What about 
disabling all external media[6] (since as someone else pointed out, they 
DO autorun without any trickery, and they're cheaper than USB keys to 
boot!)?  This is a hard problem, and I'm not sure education is the 
answer.  How long have we been trying to educate users about strong 

I'm coming to the conclusion that:

1) User education doesn't work all that well (of course, Marcus Ranum 
says it's totally useless[7] -- I'm not sure that's true)

2) There's only so much we can do to prevent users from shooting 
themselves.  We have too much inertia of the way processes and systems 
work now and that way allows users to do bad things to themselves. 
It'll take a serious effort to start over and "get things right" before 
this is fixed.

Of course, the upshot is that us security folks are guaranteed jobs for 
  a while.  :-)

Jordan Wiens, CISSP
UF Network Security Engineer

[1] http://www.u3.com/
[2] http://cse.msstate.edu/~rwm8/hackingU3/
[3] http://force.coresecurity.com/
[4] http://www.darkreading.com/document.asp?doc_id=95556
[5] http://support.microsoft.com/default.aspx?scid=823732
[6] http://support.microsoft.com/default.aspx?scid=555324
[7] http://ranum.com/security/computer_security/editorials/dumb/

Jordan Wiens wrote:
> Gary Flynn wrote:
>> Here is an article about a similar test using CDs instead
>> of USB keys:
>> http://software.silicon.com/security/0,39024655,39156503,00.htm
>> And another article covering the issue in more detail:
>> http://www.csoonline.com/read/050106/ipods.html
> That second article is wrong.  It claims that:
> "But there is another important threat that portable storage poses to 
> today's information systems. Plug an iPod or USB stick into a PC running 
> Windows and the device can literally take over the machine and search 
> for confidential documents, copy them back to the iPod or USB's internal 
> storage, and hide them as "deleted" files."
> That is just plain incorrect.  From:
> http://www.microsoft.com/whdc/device/storage/usbfaq.mspx
> -----
> Q: What must I do to trigger Autorun on my USB storage device?
> The Autorun capabilities are restricted to CD-ROM drives and fixed disk 
> drives. If you need to make a USB storage device perform Autorun, the 
> device must not be marked as a removable media device and the device 
> must contain an Autorun.inf file and a startup application.
> The removable media device setting is a flag contained within the SCSI 
> Inquiry Data response to the SCSI Inquiry command. Bit 7 of byte 1 
> (indexed from 0) is the Removable Media Bit (RMB). A RMB set to zero 
> indicates that the device is not a removable media device. A RMB of one 
> indicates that the device is a removable media device. Drivers obtain 
> this information by using the StorageDeviceProperty request.
> -----
> ipods and nearly all usb sticks are all classified as removable media 
> and this you cannot enable autorun without some other program already 
> running on the PC (heck, that's why ipods require the ipodagent.exe 
> running on the host PC to detect the ipod insertion).

More information about the unisog mailing list