Friday, August 8, 2014

Facebook MailChimp Application OAuth 2.0 Misconfiguration

I am sharing one of my findings that I submitted to Facebook's Whitehat program earlier this year.

Facebook Ads Manager provides a sort of integration with MailChimp, to fetch data to Facebook Ads Manager.The application is a part of MailChimp website, it works on MailChimp OAuth 2.0 implementation and is purely developed by Facebook Developers. So once the MailChimp user authorises the application, it will send MailChimp data to Facebook Ads Manager.


OAuth Authorisation URL for Facebook Custom Audiences is/was:

https://login.mailchimp.com/oauth2/authorize?response_type=code&client_id=11204107077 7&redirect_uri=https%3A%2F%2Fwww.facebook.com%2Fad s%2Fmanage%2Fcontact_importer_auth%2F

I tried to play around with redirect_uri to hijack the control flow, via different techniques but failed.I moved and started fiddling around the MailChimp OAuth 2.0 specs, I discovered something interesting, the specs talks about wildcard redirect_uri.

So, I gave a second thought what-if Facebook had their redirect_uri misconfigured to *.facebook.com instead of www.facebook.com. I tried a few requests such as the following and all worked:

https://login.mailchimp.com/oauth2/authorize?response_type=token&client_id=1120410707 77&redirect_uri=https%3A%2F%2Ftest.facebook.com%2F derp%2F

https://login.mailchimp.com/oauth2/authorize?response_type=code&client_id=11204107077 7&redirect_uri=https%3A%2F%2Fderp.facebook.com%2Fb lahblah%2F

So, basically I can tamper the redirect_uri and hijack the OAuth flow to [controlled].facebook.com. Moving on, it's evident that Facebook hosts 3rd party applications under apps.facebook.com/appname, using this a redirect url can be constructed which will point to a malicious 3rd party that will steal the MailChimp access_token using this Facebook Custom Audiences Application.


Final Attacking Steps would be:

1. Attacker sends Facebook Custom Audiences OAuth link with tampered redirect_uri to the victim:

https://login.mailchimp.com/oauth2/authorize?response_type=token&client_id=1120410707 77&redirect_uri=https%3A%2F%2Fapps.facebook.com%2F attacker%2F

2. Victim Authorises the MailChimp application

3. Attacker receives access_token using his malicious app hosted at apps.facebook.com/appname


Facebook has fixed the vulnerability by restricting redirect_uri to www.facebook.com and rewarded this bug.


Proof of Concept:

Facebook FriendFeed Stored XSS

I'm writing about a stored XSS which I found on one of Facebook's Acquisition,  FriendFeed.

I started to check on FriendFeed website, for possible bugs, but failed to get anything good there. Then all of a sudden, I thought to give a shot on it's API.

FriendFeed API, allows users to fetch status updates, comments etc. from FriendFeed profiles of any user.So I changed the profile name of my test to an XSS payload, upon viewing the profile via JSON output through the API results in an XSS being triggered (Which initially worked on IE6 :(  ).




Whoa, XSS executed? but wait it's executed on friendfeed-api.com, not on friendfeed.com. I reported this to Facebook Security and they said :







So, I started to find a way through, after Googling for some time. I discovered a deprecated version of FriendFeed API, which executed on www.friendfeed.com (of course, not on friendfeed-api.com).


So, I updated my test account's status and then commented an XSS vector on it, fetching the comment will result in a non-sanitised JSON being returned and XSS being triggered via content-sniffing. (Only in IE, upto 9).


Final POC:







Thursday, March 27, 2014

Flipkart.com - Elevation of Privilege Vulnerability

 Just wanted to share a privilege escalation vulnerability affecting Flipkart, a top-notch e-commerce website in India having local Alexa Internet ranking of 10.


Let's jump to the background of the issue. Flipkart allows users to save shipping addresses for future usage. As soon as the address is saved, a deletion option along with the saved address, something similar to the one below:


So once the delete option is hit, there would be a POST request sent to the server. The request is like:

                        



There are two parameters going inside the body of POST request - __FK and address_id, __FK is the CSRF protection token used by Flipkart and address_id is a unique identifier for the saved address. So with each and every address saved in Flipkart for different users, address identifiers are saved along with them. So now comes the security issue, if one account tampers, then modifies the address_id of another user and replay the request, then server will delete saved address of another account.


For example, say there are two users - A and B. A has saved a shipping address and has an address identifier ADD123 and user B somehow knows the identifier of A, so now B saves an address in his own account then, goes ahead to the delete option, then tampers the request and changes the address_id parameter to ADD123 then forwards the request to server, server would return a JSON object like below and delete the saved address of user A.



I'm a frequent user of Flipkart and I contacted their Security Team as soon as I confirmed the vulnerability at my end, this has been patched by them completely. Although looks severe but exploitability of this vulnerability was low as the address identifier was unpredictable for an individual user.  

Tuesday, February 18, 2014

SSRF/XSPA in MailChimp

Hey!

It's been a while since I blogged about security bugs here, so let me start off once again.

About two weeks ago I found an OAuth based bug that affected Facebook, which since then got patched by their security team and I got some reward for that. This OAuth bug relied on an endpoint which was connected to MailChimp. So I was testing the OAuth2 implementation on MailChimp as the endpoint used by Facebook was connected to MailChimp, while fiddling around with redirect_uri input area provided by MailChimp I found that the web application tried to connect with the URL provided in redirect_uri. So this was something interesting based on the observations below I was able to confirm that the web application was vulnerable to SSRF/XSPA.

Relying on the scheme http://domain:port I was able to port scan Internet facing servers (eg. scanme.nmap.org) for open/closed ports.

So here's the responses I got:


Open Port (running non-HTTP aware service)

Response:
Unable to read response, or response is empty




Open Port (running HTTP aware service) 

Response:
No response/error




Closed Port

Response: Unable to Connect to tcp://domain:port. Error #101: Network is unreachable 








So observing the above request/response pairs we can conduct port scans and automate everything in a scripting language like Python to build port scanners.

MailChimp has confirmed this issue and pushed a fix for this, I was placed in their "Security Response - Thank You" list.

Tuesday, December 10, 2013

Update on Botconf'13 slides

I and Himanshu Sharma gave a talk on abuse of addons/extensions on Chrome/Firefox browsers on Botconf 2013 Conference, France.

I would like to publicly apologise for forgetting to add appropriate credits to Balázs Zoltán for his previous works on this research.

Through this post I'm publicly acknowledging him and giving credits of his part of research for over my slides.

You may find his slides here

If I missed anyone else please let me know.

Thanks and apologies again to Balázs ! Sorry!