Google as a Cyber Weapon: New Attack Method Discovered

Monday, April 30, 2012

Pierluigi Paganini

03b2ceb73723f8b53cd533e4fba898ee

(Translated from the original Italian)

Panos Ipeirotis, a researcher at New York University, has discovered a new technique of attack against Amazon web service using Google Spreadsheets.

The method of attack is a DDoS type and the researcher has named it a "Denial of Money" attack.

It involve on line spreadsheets  based on Google Docs platform and the Amazon Web Services, the victim of the attacks. Let’s consider that similar attack can be directed against similar platforms.

All is  started from an email received by Panos sent by Amazon Web Services LLC that noted an increase in it’s monthly charges (click image to enlarge):

The researcher was stunned reading the amount of the bill was  $720, seven times greater than the ordinary charges for Amazon Web Services. Once logged into the account, he noted a bigger number: $1177.76 in usage charges!

Reading the details of the traffic revenue he noted that $1065 was paid for outgoing bandwidth transfer costs, 8.8 Terabytes of outgoing traffic! The total cost was increasing hour after hour scaring the researcher (click image to enlarge):

What was happening? Why had costs escalated like that?

Immediately, the researcher enabling logging to his S3 buckets and began analyzing the reports provided by Amazon regarding the usage of its cloud service, and he discovered that his S3 bucket was generating 250GB of outgoing traffic per hour.

He discovered that the source of the traffic was a big bucket with images that were being used for a variety of tasks on Amazon Mechanical Turk - approximately 250GB of pictures.

Considering that the size of each image was maximum of 1MB, the bucket should have been serving 250,000 images per hour with more than 100 requests per second, that is anomalous.

According the researcher:

"Somehow the S3 bucket was being "Slashdotted" but without being featured on Slashdot or in any other place that I was aware of."

Checking the Logs the researcher discovered that a Google was aggressively crawling the bucket. Here are the IP's and the User-agent of the requests:

"74.125.156.82 Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)."

Why would Google crawl this bucket? Google could not have gotten the URLs from Mechanical Turk. The images in the tasks posted to Mechanical Turk are not accessible to Google to crawl. The effect was that that an S3 bucket with 250Gb of data generated 40 times that amount of traffic. Google would just download them once the images were in the bucket, but in this case each image was being downloaded every hour.

The discovered address is not related to Google crawler, named GoogleBot for web pages and Googlebot-Image for images, but is for Feedfetcher - a Google grabber for RSS or Atom feeds added by users for their Google homepage or for Google Reader.
The agent ignores the robots.txt, file created by the webmaster to mark file or folder that they want to hide from the spider web of search engines.

Continuing in his analysis, the researcher noted that all the URLs related to the images were also stored in a Google Spreadsheet, he used the "image(url)" command to display a thumbnail of the image in a spreadsheet cell. In this way every time a spreadsheet is viewed, Google procedes downloading all the images to create the thumbnails.

But why was it downloading the same content repeatedly?

The explanation is simple, Google is using Feedfetcher as a "url fetcher" for all sorts of "personal" URLs someone adds to its services, and not only for feeds. Google doesn't store the URLs of the pictures because they are private, avoiding any caching activities. 

In this specific case, its not possible to store a robots.txt in the root directory of https://s3.amazonaws.com that is the common server for many different customers.

Working with huge domains such as s3.amazonaws.com containing terabytes of data, Google has no reason to apply a rate limit, so it is normal to open thousands of temporary connections on a set of URLs that were hosted on it.

The steps to conduct similar attacks are:

  • Collect a large number of URLs from the targeted website. Preferably big media files (jpg, pdf, mpeg and similar)
  • Put these URLs in a Google feed, or just put them in a Google Spreadsheet
  • Put the feed into a Google service, or use the image(url) command in Google spreadsheet
  • Sit back and enjoy seeing Google launching a Slashdot-style denial of service attack against your target

The lesson learned is that it is possible to use Google as a cyber weapon to lauch a powerful denial of service attacks against other platforms. In reality the service in this case hasn't been interrupted, but the attack has made it extremely expensive to run, that is the reason of the name assigned by the researcher.

The event should alert security professionals to the attacker's opportunity to adopt cloud platforms or search engine services as primary tools for the attacks. In the past we have already spoken about the of use search engines as a hacking tool.

A fundamental aspect that must be considered during the design of new service is its interaction with the existing platforms, and the analysis isn't so simple. Consider also the opportunity given by the introduction of the cloud paradigm, a concept that under the security perspective must be analyzed more in detail.

Cloud platforms could offer an incredible opportunity for hackers if used as weapons and also if we consider these infrastructure as a source of information that is still too vulnerable.

Reference:

Cross-posted from Security Affairs

Possibly Related Articles:
22304
Webappsec->General
Information Security
Denial of Service Cloud Security Attack Amazon DDoS hackers AWS Denial of Money attack Google Docs
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.