[WEB SECURITY] (XSS via file extension) XSS-Phishing on Financial Sites

Matt Fisher mfisher at spidynamics.com
Tue Jun 27 13:50:41 EDT 2006


[context: I don't know a thing about image file formats ] 

I was able to actually put a block script into a jpeg right at the
beginning, and it executed.  Unfortunately, the rest of the jpeg didn't
render as an image (which was my hope), it merely displayed as hex which
was pretty ugly.  Of course, you don't have to actually have it inside a
JPEG but this may facilitate filter evasion on apps that actually do
look for the header but don't care where it is (if the jpg format works
like that).  This also has the advantage of appearing to be a proper
image to the casual observer on the server, since accessing the file
directly will still display the actual JPEG.  I thought that was pretty
cool, but an actual stego guy would probably laugh at it ;) 


Unfortunately, I could only get it to work with an actual block script.
I haven't been able to get it to work with an event (though I haven't
been trying very hard) so if I site blacklists script tags you may not
be able to submit this. 


Arian, what I have NOT been able to do is just display the images in an
HTML file ie < Img src= script . jpg > and have it work... again, I
haven't been putting a lot into this though, just glancing at it in my
copious spare time.  


-----Original Message-----
From: arian.evans [mailto:arian.evans at anachronic.com] 
Sent: Tuesday, June 27, 2006 10:56 AM
To: 'Web Security'
Subject: RE: [WEB SECURITY] (XSS via file extension) XSS-Phishing on
Financial Sites

 
> -----Original Message-----
> From: RSnake [mailto:rsnake at shocking.com] 
> 
>  	Sure, it's being treated as an HTML document because the MIME
> type is being ignored since the JPEG header is missing.

Right, that's what I was saying, for things that IE is natively
set to handle in Windows shell extensions (and only those things)
IE does it's magic byte header detection, then treats as a doc.
Else IE/windows launches the mapped application to handle the extension.

> But that's not really much of an exploit since it requires the user
> to click on it first.

*Nah, not at all.*

There are tons of functions in applications, from thumbnail previews
to avatars to folder icons, that web-based apps like Document
Management Systems (DMSes) use. In the case of thumbnail views,
this is automatic, in the case of avatars/folder icons, whatever,
it's still user supplied but not *ONE* windows based system I've
ever tested validates file type (and only one unix system I've
tested does this). One windows-based system had a client-side
activeX control for validating file type, but a proxy fixed that
pretty easily.

Now, again, in the case of a DMS system (or web-based fax system
where users click on bmps and pngs all day) there is no social
engineering required for the click, or perhaps more precisely the
behavior is already patterned, but below I was referring to completely
transparent execution of the script in a page.

1) Embed full script

-or-

2) Directive:payload if already being rendered in a script (e.g.
moving custom avatar)



> >
> > http://www.anachronic.com/xss/scriptalert.jpg
> >
> > Anywhere you can embed/reference an image, IE will execute
> > script types it understands for image (any) extensions it has
> > native shell extension handling configured to use itself for.
> >
> > If you can get the image to 'render' inline of an existing script,
> > you may be able to get away with a simple directive as such:
> >
> > http://www.anachronic.com/xss/shortalert.jpg
> >
> > It's quite fun, and most web-based DMSes are vulnerable to
> > this type of abuse, say *nothing* of the zillions of sites
> > that allow custom avatars.
> >
> > This is definitely something the browser could kabosh
> > short-term, though long term you'd think DMS systems would
> > want to validate all user supplied data, including the
> > /documents/ themselves.
> >

-ae




------------------------------------------------------------------------
----
The Web Security Mailing List: 
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]


----------------------------------------------------------------------------
The Web Security Mailing List: 
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]



More information about the websecurity mailing list