Google Spreadsheet Vuln - CSRF and JSON Hijacking allows data theft

In October of 2015 I discovered a JSON + CSRF hijacking vulnerability with a Google API related to spreadsheet graph rendering. Using this vunlerability an attacker could steal the content of a spreadsheet from a target victim without having permission to the Google Drive file.

Impact of the vulnerability:

When exploiting the vulnerability against target victim(s) from the Internet, an attacker is able to bypass the Sharing settings ACL restrictions on Google Drive native spreadsheets. To clarify, an attacker who is not authorized to access a Google Drive file, as shown in the below image, is able to exploit the vulnerability to bypass the Google security protections:

Nature of vulnerability

This is not the first time that Google has had a JSON Hijacking vulneraiblity that allowed for customer data exposure.

The nature lies in a software design flaw in Google Drive APIs that have caused an OWASP TOP 10 (2013) - A8-Cross-Site Request Forgery (CSRF) vulnerability that allows for JSON Hijacking.

The vulnerability is not difficult to exploit. One past example is Google Gmail, which has been vulnerable to CSRF+JSON hijacking before in publicly released vulnerability exploits.

• January 27, 2006 -- Advanced Web Attack Techniques using Gmail
  • http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniques-using.html
  • Gmail Contact List CSRF Vulnerability
• November 20, 2008 - Anatomy of a Subtle JSON Vulnerability
  • http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/
• October 14, 2010 - Gmail JSON Hijacking Attack Technique
  • http://seclists.org/fulldisclosure/2010/Oct/199

For the Gmail JSON hijack Google was able to remediate the issue by appending an infinite while() loop to their JSON to cause target victims' browsers to crash during exploit attempts, which stops the attacker.

However, the nature of this Google Drive vulnerability is such that Google cannot simply apply a quick fix to the JSON. The necessary fix requires complex changes to Google Drive in order to avoid breaking product functionality.

In Google's case they opted to retire the old API and replace it with a new one that required additional security permissions. This required developers who used the API to update their code.

Example Attack Scenario (one of many):

Business has a spreadsheet with confidential information in it.

Spreadsheet is only shared with authorized individuals in the company.

An employee leaves the company so their access is removed and shared passwords/pins/secrets in the spreadsheet are changed after they leave denying them access or knowledge of the data.

The new sharing settings showing the user's access removed.

The force be with you

The now removed employee desires to obtain unauthorized access to the spreadsheet. They know that Mr. [email protected] likes to frequent a website that allows anyone on the internet to publish comments with HTML markup. This is known as a watering hole attack as the attacker simply waits for their victim instead of attempting a more active attack like phishing or otherwise.

Screenshot of victim/user visiting the website.

Unknown to the target victim (who is not even the document owner) they have just sent a copy of the spreadsheet data to the attacker.

What the stolen data looks like (not seen by the victim):

The attacker sees the data as shown

How is this possible?

The API in question did not require an OAuth token from a referring application and allows other sites to make cross site requests. This allows any website to call the API and obtain the spreadsheet data of a victim who is already logged into their Google account.

Because the response returned is JSON it is possible using JavaScript to have the web browser parse the information into an object that gets submitted to an attacker's choice web server.

Simple proof of concept exploit code can be found in the following files:

• simpleCapture.php - A script for capturing the data sent from the victim's web browser
• google_drive_smuggle.html - The HTML code used against the victim to steal target data

An example of the code that parses the hijacked JSON:

		var google = new Object();
		google.visualization = new Object();
		google.visualization.Query = new Object();
		
		google.visualization.Query.setResponse = function(goods) {
			google.response = JSON.stringify(goods, undefined, 2);
			
		}

The reply from the API service returns a JavaScript object with the data in JSON encoded format. That data is available to our cross-origin page in the JSON object so we simply submit it to wherever we want.

Timeline

Fix Near

After looking at the issue for quite some time Google decided that trying to code a backwards compatability fix wasn't going to be the best route. They opted to decommission the old API and replace it with a new one instead. This made the most sense, in my opinion, at resolving the issue versus trying to catch all the corner cases that might still allow a security bypass.

An alert started to appear telling the user that use of the OLD api by the website/application would stop working soon.

Final Fix Confirmed

I confirmed the issue was finally fixed on September 15, 2016.

Finale

It took a while but keeping monthly contact with Google did see the issue fixed and spreadsheet data once again secured. At times it was difficult to get a response from Google, but I felt it was better to get the issue fixed properly rather than try to pressure them with disclosure. The complete fix was a bit involved since Google had to figure out how to minimize impact to functionality too.

I was added to Google's Hall of Fame for my finding. You can find my profile here.

• Enable TRIM/Discard on USB for Linux
• Router Forced TOR Access Point
• Python Pandas Excel Format Column Number Type
• VMConnect Hyper-V Custom Resolution Ubuntu
• Ubuntu VM with Enhanced Session Hyper-V with Sound

• Computer Problems
• Curriculum Vitae
• Free Stuff
• Games
• Misc
• Programming
• Security
• Tech Tricks