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: We'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).

Discretionary controls may lead to social engineering attacks against banking dongles

New social engineering attack strategies will deal with the fact that some details entered in banking transactions are checked discretionally by the receiving institute. Any bank has a different database for user details and a different policy: that’s good because user details are kept very confidentially. However any single institute has very proprietary controls; some do well, some do not.

The bad news is that one misbehaving entity is enough for lowering the security of the network. Attacker could choose the only bank in the country that has very weak controls, since the goal is to receive banking transfers from other people.

Let's assume that the bank where Mallory has his account will accept bank transfers if the the recipient is wrong and the amount transferred is lower than 5k. We could have a situation like the following one:
What If your bank will receive the correct account number with a wrong name on it? Well, the correct Beneficiary Name is not mandatory for issuing a bank transfer, but your bank (the receiving party) could accept it or not.

Usually the attacker has still 3 additional days to phone the receiving bank and try to persuade one employee to finalize the transaction before the transfer gets blocked.

We did some tests about sending money in our country to correct IBAN account numbers, but to wrong recipients.

Some results:

• For amounts lower to 100 euros: 2 out of 7 banks confirmed and accepted the transfer.
• For and amount of 3000 euros: 1 out of 3 banks confirmed and accepted the transfer after a phone call.

Phone call was made to the Office that handled the incorrect transfers. We just said that we meant to perform a banking transaction to another recipient, but we entered the wrong details. The operator said that she was expecting another bank operator, and not a customer but she said that was just fine.

Attackers may take advantage of these issues to perform social-engineering attacks directly on antimalware devices.

Effective attack strategy could be once again luring the user into confirming the wrong transaction, by preserving those fields that are actually remembered by the user. So which fields can be easily remembered?

• Amount? easily
• Recipient? easily
• Country? easily
• IBAN? Not easily. Personally I would just check for the name in the recipient field if it is available on the screen.
  

External device screens may look similar to the one below. Details include also IBAN, Account number, and any other detail is directly displayed on the external screen:


The main challenge in designing Antimalware solutions is to “Authenticate the Transactions to the user”. The most common way to meet this requirement is to provide an out of band channel that displays the transaction details in a secure manner. In this way the user can spot if “something” between him and the bank has interfered within the transmission.

Typical attacks against banking security solutions are impersonation attacks that need a malware already installed on the user system. The following is an example of a very common MITM (Man in the Middle Attack) performed on the local user machine:


By giving a clarifying example, let’s assume that the user (Bob) is doing a banking transfer to his friend (Alice). The details displayed out of band on the external devices will be:

Amount of Transaction: 300
Recipient: Alice
Country: Wonderland
IBAN: WL04292039280100000000918292

If an attacker using a malware capable of “Local Man in the Middle Attack” changes some of the details, the external devices will prompt for confirmation. At this point the transaction will look very different from the original one:

Amount of Transaction: 10000
Recipient: Mallory
Country: Wonderland
The IBAN: WL053510393501200000003523491

This fraud attempt is easy to spot, even if the attacker is using a mule in the same country as the victim: Transaction Amount and Recipient Details are very different from the original ones.


But if the attacker uses the social engineering attack mentioned at the beginning he could succeed by simply modifying the IBAN details (instead of the Amount and the Name of the Recipient):
Can you spot the difference? Maybe yes (the IBAN visibly changed), but many details are unchanged from the original transaction. This fact will probably fool many users.

The main reason is that additional details, such as the Recipient are considered trusted by the user and can have influence upon his choices. The details provided to the user should be the lowest as possible; any further detail which is not completely trusted by the bank itself may lead to confusion and leading to considerably increase the attack surface.

For banking network security reasons, be sure to threat correctly banking transfers with incongruent details, on both online banking and phone banking operators' side.

Are you sure you are doing it correctly? Please check it, for the health of next generation security solutions.

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 is:

%26action=delete

It becomes:

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

so even if the user sees View, the action will be 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.
For instance:

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.
In fact trying 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=aaaa

Every link to listed emails, within 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 any email subject he will trigger the execution of a different action, as it usually happens for CSRF.

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.

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

On May 14th @ OWASP Appsec Poland 2009, 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 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!