Attackers can read emails, contacts and other private data from the accounts of Yahoo users who visit a malicious page by abusing a feature present on Yahoo's Developer Network website, says an independent security researcher.
A limited version of the attack was presented on Sunday at the DefCamp security conference in Bucharest, Romania, by a Romanian Web application bug hunter named Sergiu Dragos Bogdan.
In his presentation, the researcher showed how the Web-based YQL (Yahoo Query Language) console, available on the developer.yahoo.com website, can be abused by attackers to execute YQL commands on behalf of authenticated Yahoo users who visit malicious websites.
YQL is a programming language similar to SQL (Structured Query Language) that was created by Yahoo. It can be used to query, filter and combine data stored in databases.
The Yahoo developer website provides access to a Web-based console that developers can use to learn and test YQL by running YQL queries against Yahoo's own databases.
Non-authenticated users can only run YQL queries against tables containing publicly visible Yahoo information, such as information from Yahoo Answers, Yahoo Weather and other services. However, when they are authenticated, users also gain access to tables containing their own Yahoo account data, including emails, contacts and private profile information.
When a query is entered in the console's "YQL statement" field and the "TEST" button is pressed, a user-session-specific authorization code called the "crumb" is also submitted along with the request. The crumb is generated when the user visits the YQL console page and is inserted into the form requests automatically.
During his presentation, Bogdan presented a proof-of-concept (PoC) attack page that loaded a specific developer.yahoo.com URL inside an iframe. When the attack page was visited by an authenticated Yahoo user -- a test account was used -- the iframe returned the visitor's crumb code.
However, security mechanisms built into browsers don't allow code running in the context of one domain name to read content from a page hosted on a different domain that was loaded inside an iframe. This means that while the visitor himself can see the crumb code on the attack page, thanks to the iframe being loaded in his browser, the attack page itself can't read the code or automatically use it to make authenticated YQL queries using the victim's Yahoo session.
In this case, the attacker needs to trick the user into giving him the secret code displayed on the page. Since the crumb is actually a string of random numbers and letters -- for example "y5XAjn1fKIQ" -- Bogdan built a fake CAPTCHA test on the attack page and made it appear as if the crumb displayed in the iframe was actually the CAPTCHA challenge string that the user had to input in order to solve the test. By solving the fake CAPTCHA, the user was actually authorizing a YQL query to be made in his name.
Using fake CAPTCHAs is not a new attack method. It has been documented as a technique to bypass cross-domain restrictions before, and there are known cases of this method being used successfully by attackers to steal security tokens. Symantec reported last year that spammers were using a very similar technique to steal anti-CSRF (cross-site request forgery) codes from Facebook users, which allowed them to post spam links on their behalf.
In his PoC attack, Bogdan used a YQL command to change the user's Yahoo profile status in Yahoo's database, but the same method can be used to run a YQL query that returns a number of emails from the user's Yahoo email account, or other private information.
In order to actually read the emails, the attacker would need to use another technique that would force the data to be returned to his server. Bogdan said he knows how to do that but didn't want to disclose the method during his presentation for ethical reasons.
However, he agreed to demonstrate it privately in the presence of one of the conference's organizers, using a test email account.
In addition, he said the whole attack can be completely automated by leveraging a yet-undisclosed vulnerability located somewhere else in the developer.yahoo.com website.
This means the attacker no longer needs to use the CAPTCHA trick, he said. The user just needs to visit a specially crafted page.
Because the attack exploits multiple security issues and uses several different techniques, Bogdan called it a "blended threat."
He said he plans to share his findings with Yahoo as soon as he has some time to put everything in a proper report.
In the meantime, Yahoo can block such attacks by preventing unauthorized third-party websites from loading pages from its developer.yahoo.com domain inside an iframe, the researcher said.
This type of defense is commonly used against clickjacking attacks that also rely on legitimate pages being loaded inside iframes and abused. It can be implemented either through a header called X-FRAME-OPTIONS that's supported by modern browsers, or by using so-called "frame busting" JavaScript code, which has the benefit of also working on legacy browsers but is known to be less reliable.
Yahoo did not respond to a request for comment regarding Bogdan's proof-of-concept attack presented at DefCamp and the solution he suggested.
Bogdan hasn't been doing Web vulnerability research for a long time. However, he recently earned a cash reward from Google and a listing in the company's Application Security Hall of Fame for finding and reporting a vulnerability in one of the company's websites.
Google, Mozilla, Facebook and PayPal run bug bounty programs through which they pay researchers who responsibly disclose vulnerabilities found in their websites. Other companies, such as Microsoft, don't hand out monetary rewards but recognize the help received from researchers by publishing their names on special thank-you pages on their websites.
