lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BY2PR03MB0112077DDCFA0B53626EECCE27B0@BY2PR03MB011.namprd03.prod.outlook.com>
Date: Wed, 3 Dec 2014 17:52:28 +0000
From: Barry Dorrans <Barry.Dorrans@...rosoft.com>
To: A Z <kryptos.gnostikos@...il.com>, James Hooker
	<seidrhrafn@...glemail.com>,
	"marksteward@...il.com" <marksteward@...il.com>
Cc: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: Re: [FD] XSS (in 20 chars) in Microsoft IIS 7.5 error message

I believe that's the asp.net error page you're seeing (Was it yellow?) 

That exception is from Request Validation (which we don't consider a security boundary any more, and we advise folks to validate themselves, as validation is context specific).

You're seeing the dev error page, which by default is only shown if you're accessing via //localhost. Developers can override that setting to always show the default detailed errors to any client - we advise folks to not release with that enabled, but of course people don't always take that advice. The default "safe" error page wouldn't have any details of the exception thrown. (http://msdn.microsoft.com/en-us/library/vstudio/h0hfz6fc%28v=vs.100%29.aspx)

The Yellow Screen of Death should be encoding the exception message regardless. If you find it's not then I'll be very interested :)

-----Original Message-----
From: Fulldisclosure [mailto:fulldisclosure-bounces@...lists.org] On Behalf Of A Z
Sent: Monday, December 1, 2014 02:44
To: James Hooker; marksteward@...il.com
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] XSS (in 20 chars) in Microsoft IIS 7.5 error message

Thank you all for the replies,

Unfortunately, I can no longer really test this (it was on some internal network, so for example link shortening wouldn't work), but I wanted to know if anyone had encountered this stuff before. I should try on a clean install as suggested - if it works I'll let you know.

For some unknown reason there was no HTML encoding in this error response, however the payload was truncated to 20 chars. I googled it and all I found was some discussion about the validateRequest attribute in web.config, however I didn't have the configuration of the server to check this.

This was also part of some commercial app that uses IIS, but I think it's more related to IIS itself.

Thanks all

On Sat, Nov 29, 2014 at 7:37 AM, James Hooker <seidrhrafn@...glemail.com>
wrote:

> You could skip the schema on any includes, and just use '//'. That 
> will then use the schema provided in the original URL. That will save 
> you 4 characters at least. You can also skip most quotes in tags - 
> that will save you a few more characters. Link shortening services 
> might also be of use, however one that generates links short enough 
> might be hard to come by - more likely, you'll need a 3 character 
> domain, with a 2 character extension (such as UK, or IN).
>
> You might be able a squeeze a script tag into that saved space.. 
> *might* Hello everyone,
>
>
> I found some weird HTML code injection in an IIS error message. IIS 
> spits out some part of the user input that generated the error 
> message, but will only display 20 characters at most.
> My question is: is it possible to actually exploit an XSS with this ?
>
> Here is an example:
>
> HTTP Request: mypage?search=%3cb%20onclick%3dalert(1)>%3e
> HTTP Response (real):
>
> <p>An error has occured.</p>
>     <p>Exception HttpRequestValidationException occurred while 
> attempting <b>mypage</b></p>
>     <p>Exception message is: <b>A potentially dangerous 
> Request.QueryString value was detected from the client (search="<b 
> onclick=alert(1)>...").</b></p>
>     <p>Stack trace:</p>
>     <pre>
> Server stack trace:
> [..]
>
> My payload was: <b onclick=alert(1)>> and it works (after clicking).
> However, can this actually be exploited in real life ? I tried stuff 
> in 20 characters like: <embed src=http://x> or <img src=http://x/z> but no luck.
> Has anyone ever tried this before ?
>
> Thanks,
>
> P.S. This might be a silly question with an obvious answer. If so, I'd 
> be grateful to have some extra information (links, docs etc.).
>
> _______________________________________________
> Sent through the Full Disclosure mailing list 
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>

_______________________________________________
Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ