Message-ID: <40D313B0.1080303@egotistical.reprehensible.net>
Date: Fri, 18 Jun 2004 18:09:20 +0200
From: Gadi Evron <ge@...tistical.reprehensible.net>
To: Harlan Carvey <keydet89@...oo.com>
Cc: full-disclosure@...ts.netsys.com, bugtraq@...urityfocus.com
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@...uxbox.org.  Work: gadie@....gov.il. Backup: ge@...p.mx.dk.
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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists