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!

FOSDEM 09

Matteo Meucci was invited to talk about the new OWASP Testing Guide and Secure Software Development at FOSDEM 09.
FOSDEM
Presentation
Here you can download the video of the presentation:
Testing Guide video


The following is the interview that Christophe Vandeplas gives to Matteo and Paulo Coimbra (OWASP Project Manager):

Hi, thank you for the interview. I have been working in Information Security for some years, starting with a thesis in PKI and Attribute Certificates. I worked for many consultancy firms, then in 2007 with Stefano Di Paola and Giorgio Fedon we decided to create Minded Security, a company totally focused on Application Security Consultancy. I have been contributing to OWASP for many years and in 2005 I founded the Italian Chapter and from 2006 I lead the OWASP Testing Guide Project.

What will your talk be about, exactly?

The goal is to show the OWASP testing methodology and how you can implement a software development lifecycle that permits to develop more secure applications.
What do you hope to accomplish by giving this talk? What do you expect?

I’d like to promote the OWASP guidelines and find more people interested in OWASP and contributing to improve our projects.

What's the target audience for the OWASP Testing Guide?

We make this guide available in a completely free and open way because we believe sharing knowledge could contribute to develop more secure applications. The target audience here is not only the Application Tester, but everyone involved in the Software Development Life Cycle. So the Security Managers, the Internal Audit, the Developer Team, the Testers, are all interested to adopt a common and open source methodology to test the security of the application.

How would you describe the OWASP Testing Guide in a few sentences?

An open and standard methodology to perform Web Application Penetration Testing.

What are the biggest differences between v2 and v3 of the OWASP Testing Guide?

That's a good point. OWASP started in 2005 with the first testing guide version. We collected the set of test to perform and a short methodology. In 2006 we did a great job creating version 2 that collects 8 categories of tests for a total amount of 48 controls. The guide describes each single control to test.

Now v3 collects 10 categories of tests for a total amount of 66 controls and we have created a shared methodology in a 347 pages book.

How successful was the OWASP Summer of Code 2008? How many participants were there? What were the most important accomplishments during this period? What are the differences with the OWASP Spring of Code 2007 and OWASP Autumn of Code 2006?

Paulo Coimbra (OWASP Project Manager): OWASP Foundation is a voluntary, not-for-profit entity and open community. By responding so significantly to the Summer of Code’s challenge, this community has showed its vitality and true passion in improving application security.

We have invested roundly 275,000 dollars to fund the entire Summer of Code initiative. We have used slightly less than half of this amount to symbolically reward the work of one hundred project leaders, contributors and reviewers.

The remaining budget has been used to support the inter-linked OWASP Summit, a thrilling event set up to identify, coordinate, and prioritize OWASP efforts to create a more secure Internet in which the Summer of Code deliveries were publicly presented.

As it was said by OWASP Chair Jeff Williams, "Our community is growing and organizing into a powerful movement that will affect software development worldwide" and so the Summit, being the Summer of Code 2008 its central piece, has marked a major milestone in our efforts to improve application security.

Apart from launching more than two dozen of new or updated documents and tools, as for the most important accomplishments during this period, we would like to point out the reinforcement of an amazing knowledge sharing culture plenty of comradeship, curiosity and freedom.

Given OWASP´s worldwide scope characteristic, several of its contributors from all earth corners had been collaborating to develop application security for several years often without personally meeting each other. By gathering the majority of the most active of them in a friendly and productive environment, both events the OWASP Summer of Code 2008 and the OWASP Summit have created the conditions for enhanced future achievements. This circumstance and an improved organizational support should have been the major differences relatively to the past seasons of code.

What can we expect from the OWASP Winter of Code 2009?

Paulo Coimbra (OWASP Project Manager): Although the OWASP Winter of Code 2009 design is not finished yet and so its final frame can yet be modified by the expected OWASP community inputs, I believe the new season of code to be very similar to the previous one.

Likely by the next month the call for applications will be sent and we will be accepting proposals in three distinct spheres, namely, Innovation/Start-ups, Integration/Development and Quality Improvement.

The entire cycle from launching to completion should last nearly six months and we will be expecting all the approved proposals to be executed in time to be presented in our next Summit which will be probably held next November.

Even if we are expecting applications from the majority of the former season of code participants, we certainly welcome new ones. In addition, to review the approved projects, several positions will also be open.

We are counting on involving no less than hundred people in the OWASP Winter of Code 2009 and we hope you can be one of them. Please check our main page for updates.

You have more than 8 years of experience in information security. What have you seen changing in this period with respect to web application security? Are most types of vulnerabilities still the same or are there any genuinely new developments?

The research on Application Security is a very active field. We are finding new vulnerabilities and new types of attack every week. That's why we have to verify continuously the security of a web application also if the application is not changed during that time.

What do you consider the most underestimated risk for web applications in the near future?

Every application is completely different from the others. Web Application Security is dynamic, it changes every day. The risk for the Companies is to think statically: If you think statically to your application probably you will expose that to some security trouble in the future. That’s why keeping up-to-date is a key factor for the Companies: the OWASP Community could contribute giving state of the art open guidelines and tools.

OWASP-Italy Day III - Next 23rd February

OWASP Day III - "Web Application Security: research meets industry"

Background:

Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. OWASP mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks.
Everyone is free to participate to the OWASP community and all the produced materials are available under a free and open software license.

The OWASP Day 3 follows the success of the past OWASP Italy Day and, in particular, the OWASP-Day II that received 250 subscriptions of attendees come from widespread business area: Telecommunication, Finance, Banking, Assurance, Government Companies.

Goals and Topics:

The OWASP Days have always offered a forum for discussion and exchange of ideas among researchers and practitioners who present their experiences and discuss issues related to Web Application Security from a higher level to a technical point of view.

Conference topics include, but are not limited to:
* The evolution of attacks and countermeasures for the security in the Web Application
* Case studies of how the Companies have adopted the OWASP Guidelines in their SDLC.
* Application Security Assessment Model
* Data Privacy Enabling Technology
* Experience report in applying OWASP guidelines to industries

Agenda

The detailed agenda of the conference is available here:
OWASP-Italy Day III

Registration and fee:

The conference is open to all attendees for free (coffee break and business lunch are included) but it requires (mandatory) registration at the following URL:
http://www.daisy-net.com/owasp

In order to guaranty a well organized event, the unregistered attendees will not be allowed to access the conference.

Location:

The OWASP-Italy Day III will be hosted by:

Centro di Competenza ICT SUD - Puglia
Department of Informatics
University of Bari
Via E. Orabona n.4.
70125 - Bari
Italy

Details and Location

Official site
Location

Shields up against Domain Escalation Worms

Internal networks are the core of the business activity. Resources should be available, shares must be reachable, and servers should expose a wide number of services that are used every day by employees. Enterprise officers usually agree that security components are easier to manage if they are centralized and that password rotation is also better achieved Single Sign On architectures are used. Active Directory is one of the most deployed and pervasive Single Sign On solutions with 40% Market Share in large organizations (Microsoft Custom Research Market Study, May 2004). Active Directory “using the same database, for use primarily in Windows environments, allows administrators to assign policies, deploy software, and apply critical updates to an organization” (Wikipedia).

Unfortunately Enterprise networks are still very vulnerable to attacks performed from the inside of the network. Skilled attackers leveraging multiple types of attacks can easily obtain access to most of the systems. Some of the techniques include: exploiting unpatched systems (more the services exposed, more the breaches), exploiting unpatched applications, performing layer 2 attacks and riding trust between systems. Things get worse if we consider that most of the previous attacks can be pursued by an automated program and not by a physical attacker. Worms are able to spread across networks in very subtle ways and can easily spread from the inside when a laptop gets infected. From such privileged position, it’s easier to further spread by exploiting vulnerabilities on unpatched systems as shown by the recent Downadup Worm (W32.Downadup Symantec Security Response).

Since Active Directory is fundamentally a centralized Single Sign On architecture that authenticates and authorizes resources using Kerberos, Active Directory creates implicit trusts between systems. Authenticated clients in possession of privileged access grants are able to access or to delegate their grants to other systems. Once a user is authenticated, he receives a session token signed by AD authority and he does not need to enter his credentials again.

Can Worms spread faster by exploiting the Active Directory trust model? Could a Worm impersonate other users to escalate privileges in an Active Directory environment?

A Domain Escalation attack takes places when a malicious user is able to extend his privileges on the Active Directory Domain. One of the most ingenious ways to accomplish this task is to impersonate another user that has a higher set of privileges by stealing his Active Directory token (or session). Luke Jennings from MWR Infosecurity in his brilliant paper describes all the details of this particular attack (MWR Infosecurity Delegation Token Security Explained).

Any task with Local Administrative privileges is able to grab the token from any process that has previously obtained a delegation. It’s easier to say that if your machine gets infected by a malicious piece of software, this software can get domain privileges by waiting that a remote system will use delegation remotely to perform any kind of operation. How long should it wait? Not, so long, considering that also WSUS service may use delegation while pushing updates and Remote Desktop uses it as well.

Example of Internal Spreading process:

• CEO’s Laptop get Infected by a Worm at the Airport;
• CEO’s after a week gets back to the headquarter and authenticates to Active Directory Domain;
• The worm start spreading on a limited number of systems using MS08-067 or 06-040 or similar publicly known exploits
• The worm reveals to be a Domain Escalation Worm and start monitoring the properties of the local processes on the compromised machines;
• When a new local process is created with a Delegation token of a domain user, the worm is able to steal that token and to impersonate the remote user
• The worm start spreading with the new obtained privileges

As it’s possible to see the combined usage of other spreading vectors increase the number of monitored systems and the chance to impersonate a highly privileged user (e.g. users that belongs to “Domain Administrator”, “Enterprise Administrator”, “Workstation Administrators” groups ).

Conclusions
Worms may use this technique to spread faster. The process could be easily automated, for targeting only privileged users of the Active Directory domain . If a Worm can then impersonate a Domain Administrator, via a Policy Deploy rule it can infect any machine in the network.