<<< Date Index >>>     <<< Thread Index >>>

Re: USB risks (continued)



        Autorun doesn't work with USB keyfobs.  Actually, it is my
understanding that it doesn't work on any media that is deemed writable and
removable.  The distinction between USB devices and CDs is that the media is
writeable, but the drives aren't removeable on CDs.  That of course isn't true
if you have a USB drive, but I think part of the deal there is that you need to
install special drivers to even read USB CD drives.  That's kinda a weird
distinction, but I researched it quite a bit earlier this year and that's just
how they define it.  With the advent of bootable USB devices, and more USB
support, you can pretty much bet things will change, but for right now, autorun
isn't an issue.

On Fri, 18 Jun 2004, Gadi Evron wrote:

| Date: Fri, 18 Jun 2004 18:09:20 +0200
| From: Gadi Evron <ge@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
| To: Harlan Carvey <keydet89@xxxxxxxxx>
| Cc: full-disclosure@xxxxxxxxxxxxxxxx, bugtraq@xxxxxxxxxxxxxxxxx
| Subject: USB risks (continued)
|
| I'm emailing this to bugtraq as well. A discussion there might produce
| more interesting results than "MS sucks" on FD. This is rather important
| and has grown in importance over the last couple of years. There were a
| few discussions on the subject, but nothing to help formulate a plan on
| how to defend against it.
|
| Here goes...
|
| >>  This issue has been discused in pentest list. Take
| >>a look at:
|  >>http://archives.neohapsis.com/archives/sf/pentest/2004-05/0136.html
| > I don't think the issue is that it's been discussed,
| > more that it hasn't been really resolved/addressed.
|
| I already replied to Harlan off-list, but I figured I might as well
| reply about some of this here as well.
|
| First off, it has been discussed rather fully on pen-test and the
| archives would make a good resource.
|
| Auto-run certainly isn't a new issue and a factor in every hardening of
| a Windows system for a while now. It was a big "thing" 2 years ago.
|
| It should be tested further, but the risk of the USB as a mechanism for
| stealing information and/or introducing a Trojan horse/gaining access to
| a PC is what we need to be concerned about.
|
| Regular usage of a USB drive makes the cleaning crew potentially the
| richest sort on earth.
|
| What I believe issues that would have to be addressed in the future, are:
| [Please keep in mind that USB performs as a hub/client model and that
| the main driver for USB devices is built into Windows, unlike what I
| originally thought before looking further into this]
|
| 1. Better systems to track/deny usage of USB drives (all-together or of
|     particular types, negatively or positively). Several systems
|     already exist, from removing USB/gluing the plug to programs
|     that sit on a Domain.
| 2. Buffer Overflow:
|     I personally find the USB driver to be rather unstable, although
|     others disagree. A buffer overflow in the driver can be catastrophic
|     and _perhaps_ even effect very strong crypto-systems. Maybe systems
|     like eToken, although I haven't looked into it, so i can't say.
| 3. SDK's:
|     Many SDK's exist for developing USB drivers. If a backdoor is put
|     into even just one of them...
|     There is a huge market for USB coders. Any kiddie interested?
|
| On the organizational level, it should be addressed in a matter of
| policy, and enforced by different monitoring systems.
|
| This issue isn't singular to USB, but it highlights the problem rather
| nicely.
|
| Some future trends might be wireless control of remote systems via USB,
| going to a PC with a PDA and choosing what to get.change, or simply
| copying automatically using the USB autorun capability (there was a POC
| on the pen-test discussion).
|
| These are all valid threats, but the main threat of copying data to a
| USB drive covertly and disappearing is what scares me currently. Also,
| what stops a person from copying work-related material to a digital
| camera memory stick?
|
| Nothing if not your policy and enforcement+monitoring of it.
|
| Other than the pen-test discussion there was a discussion here a few
| months ago on domain USB monitor services, and a USB device (once
| wireless, once for copying data automatically) showed on these TV shows:
| Threat Matrix and Jake 2.0.
|
| The reason I think this should be discussed further is because I truly
| believe in the risk. It is "out there", known and there is even a POC..
| but no real discussion on organizational counter-measures and defensive
| strategies.
|
| Here is Harlan's post:
|
|  >> This is an interesting topic of discussion.  Like one
|  >> poster, I first saw this in the most recent issue of
|  >> 2600.  I began looking into it, and almost immediately
|  >> came up with this particular MS KB article:
|  >> http://support.microsoft.com/default.aspx?scid=kb;EN-US;136214
|
|  >> As you can see, KB136214 states pretty clearly that
|  >> *be default*, autorun.inf file processing is NOT
|  >> enabled for USB-connected thumb drives.  I haven't
|  >> tested it myself, but another poster has stated that
|  >> while items in the "open=" line may not be launched,
|  >> the "icon=" line seems to be processed.
|
|  >> I read Gadi's comments:
|  >> http://catless.ncl.ac.uk/go/risks/23/41/4
|
|  >> I had some questions for Gadi, and fired off an email
|  >> but have yet to hear back.
|
|  >> While I do agree wholeheartedly that USB-connected
|  >> devices are definitely an issue within a network
|  >> infrastructure, it's not yet clear to me that the pose
|  >> the threats that have been presented.
|
|       Gadi Evron.
|
| --
| Email: ge@xxxxxxxxxxxxx  Work: gadie@xxxxxxxxxxx Backup: ge@xxxxxxxxxxx
| Phone: +972-50-428610 (Cell).
|
| PGP key for attachments: http://vapid.reprehensible.net/~ge/Gadi_Evron.asc
| ID: 0xD9216A06 FP: 5BB0 D3E2 D3C1 19B7 2104  C0D0 A7B3 1CF7 D921 6A06
| GPG key for encrypted email:
| http://vapid.reprehensible.net/~ge/Gadi_Evron_Emails.asc
| ID: 0x06C7D450 FP: 3B88 845A DF1F 4062 E5BA  569A A87E 8DB7 06C7 D450
|

-R

The information in this email is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to
this email by anyone else is unauthorized.  If you are not the
intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it is
expressly prohibited and may be unlawful.