Security Thoughts

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.