U3 TEchnology was RE: strange new virus

The U3 Hacksaw and Switchblade software are huge security
threats to
companies. I have been researching it for a while now and
cannot find
a viable way to detect or prevent these things from running.
Though
you can disable autorun from windows via registry or group
policy, if
the user inadvertently double clicks on the thumb drive in
My
Computer, it will autorun the U3 software and cause it to
get
infected. The best bet right now is Windows Vista which
allows you to
lock down USB ports.

On 12/18/06, James D. Stallard <jamesleafgrove.com> wrote:
> Harlan
>
> Firstly, no, I have no evidence of the behaviour. It
was only ever a theory
> based on the idea of a buffer overflow ocurring during
an automated process.
> My reference to the JPEG GDI+ issue was only given as
an example of the fact
> that graphics files could be used as an attack vector.
I probably do not
> have the skills necessary to write an exploit or even
to prove the concept.
>
> Incidentally, the chap that discovered the GDI+ issue
deserves our respect
> as having demonstrated a beautiful piece of lateral
thinking. After all, the
> idea that a graphics file could infect a host machine
is against everything
> we learnt in the early days.
>
> Secondly, I am interested in the file format for icon
files as I remember
> the old days of Windows 9x. As I remember, an ICO file
was simply an
> uncompressed memory map of bit values arranged in the
correct dimensions
> (originally, a 32x32 bit matrix). In other words an
icon file was a bitmap,
> with a different file extension. This still works and
you can demonstrate it
> yourself by creating a 32x32 .BMP file with your
favourite paint program and
> once saved, change the file extension to .ICO. The file
will still work, and
> it's content is now displayed as its icon.
>
> However, the newer .ICO files that ship with XP (I
tried Program
> FilesMSNMSNCoreFilesMSNMS.ICO as it's likely to
exist on your systems
> too) are no longer simply bitmaps and seem to have a
different internal
> structure - not explained by multiple versions of the
same image at
> different resolutions.
>
> Therefore, I suspected that the file format is not
standardised and there
> might be room in there for something that could be used
as an attack vector.
>
> The trouble is I am not an expert on ICO file formats
(!) and none of the
> icon files I inspected with a hex editor have any
comments associated with
> them (although a couple of animated GIFs contained all
sorts of stuff ;) )
>
> Returning to One of Thor's points about leverage a
vector in the user
> context. The risk is not really about leveraging in a
given context, it's
> about running something without user knowledge or
intervention.
>
> Interesting indeed, but very obscure!
>
> Cheers
>
> James
> James D. Stallard
>
>
>
>
> -----Original Message-----
> From: Harlan Carvey [mailto:keydet89yahoo.com]
> Sent: 18 December 2006 20:12
> To: James D. Stallard; 'Thor (Hammer of God)'
> Subject: RE: U3 TEchnology was RE: strange new virus
>
> James and Tim,
>
> > My theory is that if the Autorun.inf file is
present, then the
> > enumeration process reads it and although it
ignores the "open="
> > statement on media
> > marked as removable, it still processes the
"icon="
> > statement - on my system
> > apparently regardless of whether autoplay is
switched on or off.
>
> Understood, and agreed...I've seen this myself.
>
> > A malformed .ICO file could conceivably cause the
buffer overflow, and
> > might allow the situation to be taken advantage of
- IE run arbitrary
> > code on the USB flashdisk.
>
> Conceivably?  James, do you have anything besides that
to point to, such as
> a vulnerability to the image processing component that
handles ico files?
>
> > As the autorun "ico=" statement is also
capable of pulling icons
> > directly out of an executable, it seems plenty
possible to hijack it -
> > provided the buffer overflow is
> unchecked.
>
> While I'm not discounting the possibility...after all,
anything is
> potentially possible...I am looking at this from an
Occam's Razor
> standpoint.  Do you have anything other than "it
happened with this image
> format, it *couold* happen with another" to point
to?
> After all, I haven't been able to locate any standard
for ico files (yet)
> that mention comment fields (or any other fields) of
the sort found in the
> JPEG standard.
>
> Thanks,
>
> Harlan
>
>
> ------------------------------------------
> Harlan Carvey, CISSP
> "Windows Forensics and Incident Recovery"
> http://www.windows-ir.com
> http://windowsir.blogsp
ot.com
> ------------------------------------------
>
>
>
>
------------------------------------------------------------
---------------
>
------------------------------------------------------------
---------------
>
>

Just thinking of a possibility here-what if the software
were added to the
software restrictions GP. Or have you found that there is a
way for U3
software to get around that Ryan? 
Or does that seem unwieldy-especially if the U3 software has
a ton of
versions or updates regularly. 

-----Original Message-----
From: listbouncesecurityfocus.com [mailto:listbouncesecurityfocus.com] On
Behalf Of Ryan Buena
Sent: Wednesday, December 27, 2006 7:54 AM
To: James D. Stallard
Cc: Harlan Carvey; Thor (Hammer of God); focus-mssecurityfocus.com
Subject: Re: U3 TEchnology was RE: strange new virus

The U3 Hacksaw and Switchblade software are huge security
threats to
companies. I have been researching it for a while now and
cannot find
a viable way to detect or prevent these things from running.
Though
you can disable autorun from windows via registry or group
policy, if
the user inadvertently double clicks on the thumb drive in
My
Computer, it will autorun the U3 software and cause it to
get
infected. The best bet right now is Windows Vista which
allows you to
lock down USB ports.

On 12/18/06, James D. Stallard <jamesleafgrove.com> wrote:
> Harlan
>
> Firstly, no, I have no evidence of the behaviour. It
was only ever a
theory
> based on the idea of a buffer overflow ocurring during
an automated
process.
> My reference to the JPEG GDI+ issue was only given as
an example of the
fact
> that graphics files could be used as an attack vector.
I probably do not
> have the skills necessary to write an exploit or even
to prove the
concept.
>
> Incidentally, the chap that discovered the GDI+ issue
deserves our respect
> as having demonstrated a beautiful piece of lateral
thinking. After all,
the
> idea that a graphics file could infect a host machine
is against
everything
> we learnt in the early days.
>
> Secondly, I am interested in the file format for icon
files as I remember
> the old days of Windows 9x. As I remember, an ICO file
was simply an
> uncompressed memory map of bit values arranged in the
correct dimensions
> (originally, a 32x32 bit matrix). In other words an
icon file was a
bitmap,
> with a different file extension. This still works and
you can demonstrate
it
> yourself by creating a 32x32 .BMP file with your
favourite paint program
and
> once saved, change the file extension to .ICO. The file
will still work,
and
> it's content is now displayed as its icon.
>
> However, the newer .ICO files that ship with XP (I
tried Program
> FilesMSNMSNCoreFilesMSNMS.ICO as it's likely to
exist on your systems
> too) are no longer simply bitmaps and seem to have a
different internal
> structure - not explained by multiple versions of the
same image at
> different resolutions.
>
> Therefore, I suspected that the file format is not
standardised and there
> might be room in there for something that could be used
as an attack
vector.
>
> The trouble is I am not an expert on ICO file formats
(!) and none of the
> icon files I inspected with a hex editor have any
comments associated with
> them (although a couple of animated GIFs contained all
sorts of stuff ;) )
>
> Returning to One of Thor's points about leverage a
vector in the user
> context. The risk is not really about leveraging in a
given context, it's
> about running something without user knowledge or
intervention.
>
> Interesting indeed, but very obscure!
>
> Cheers
>
> James
> James D. Stallard
>
>
>
>
> -----Original Message-----
> From: Harlan Carvey [mailto:keydet89yahoo.com]
> Sent: 18 December 2006 20:12
> To: James D. Stallard; 'Thor (Hammer of God)'
> Subject: RE: U3 TEchnology was RE: strange new virus
>
> James and Tim,
>
> > My theory is that if the Autorun.inf file is
present, then the
> > enumeration process reads it and although it
ignores the "open="
> > statement on media
> > marked as removable, it still processes the
"icon="
> > statement - on my system
> > apparently regardless of whether autoplay is
switched on or off.
>
> Understood, and agreed...I've seen this myself.
>
> > A malformed .ICO file could conceivably cause the
buffer overflow, and
> > might allow the situation to be taken advantage of
- IE run arbitrary
> > code on the USB flashdisk.
>
> Conceivably?  James, do you have anything besides that
to point to, such
as
> a vulnerability to the image processing component that
handles ico files?
>
> > As the autorun "ico=" statement is also
capable of pulling icons
> > directly out of an executable, it seems plenty
possible to hijack it -
> > provided the buffer overflow is
> unchecked.
>
> While I'm not discounting the possibility...after all,
anything is
> potentially possible...I am looking at this from an
Occam's Razor
> standpoint.  Do you have anything other than "it
happened with this image
> format, it *couold* happen with another" to point
to?
> After all, I haven't been able to locate any standard
for ico files (yet)
> that mention comment fields (or any other fields) of
the sort found in the
> JPEG standard.
>
> Thanks,
>
> Harlan
>
>
> ------------------------------------------
> Harlan Carvey, CISSP
> "Windows Forensics and Incident Recovery"
> http://www.windows-ir.com
> http://windowsir.blogsp
ot.com
> ------------------------------------------
>
>
>
>
------------------------------------------------------------
---------------
>
------------------------------------------------------------
---------------
>
>