How I found the sweets inside Google servers. Local File Inclusion Write-up @ 2015

[dekeeu]

Hello there.

In this blog post I'll tell you how I've managed to read arbitrary files from the Google servers by finding/exploiting a Local-File-Inclusion vulnerability. This flaw was found in one of the Google products, Google Feedburner, and was fastly fixed by Google Security Team.

As Wikipedia says, "FeedBurner is a web feed management provider launched in 2004.[...]FeedBurner provides custom RSS feeds and management tools to bloggers, podcasters, and other web-based content publishers." . This product was in the past one of my targets and as I had already discovered a few xss-es in this domain, I realized that there could be more interesting bugs here. So, I did some research and after a while I discovered that FeedBurner had an open API, but it was officially deprecated by Google in 2012. However, even if the documentation files were deleted (https://developers.google.com/feedburner/), the "Wayback Machine" (Internet Archive: Wayback Machine) saved these pages and I was able to read them.

This is how I've discovered the link that caught my attention : http://feedburner.google.com/fb/dynamicflares/HelloVisitor.jsp?feedUrl=http://domain.tld/ff.xml (it isn't working anymore) .This script was used for retrieving the content of Dynamic FeedFlare Unit files, which are basically simple xml documents built after a certain scheme . For those who aren't familiar with the FeedFlares, it's important to know that these are more like some kind of addons, used by Feed owners in order to give their readers new methods of interacting with their content. (ex: Hello, Visitor)

At first glance, the purpose of this script was to grab the XML document submitted as value for feedUrl parameter and perform a XSL tranformation on it. The problem with this file was that it only appended the content of the provided XML in the context of the page without modifying or even encoding it.

My first attempt was only to find an XSS and I succeded by providing an URL that points to a malicious html file. But I felt that there could be a vulnerability with a major impact like reading files from the webserver, so I started my research with some classic payloads, injecting a directory traversal, a method tipically used in LFI attacks ("../../../../../../../etc/passwd"), but it didn't work. Nevertheless,by changing the method and using the file URI scheme, I was able to retrieve files from the server.

Unfortunately, not all the files were readable due to the Security policy file, but accessing some log files were enough to prove the existence of this vulnerabiliy. I've submitted this flaw to Google and it was fixed within 10 minutes after the triage.

Also, I've uploaded a short Video PoC which demonstrates this issue:

---

Articol original: http://ownsecurity.blogspot.ro/2015/08/how-i-found-sweets-inside-google.html

Vulnerabilitatea a fost reparat?

[tpad]

Let me guess? A pat on the back aka ty for reporting?

[dekeeu]

Let me guess? A pat on the back aka ty for reporting?

Nope.

[BitMap]

Destul de mare spatiul dintre "... award you" si "for this find.". Foarte bine

Anyway, nice work.

[mah_one]

Cred ca se putea face upload cu vulnerabilitatea aia, sper ca le va zice celor de la google sa reconsidere problema si sa ia in considerare un RCE....

[wildchild]

Destul de mare spatiul dintre "... award you" si "for this find.". Foarte bine

Anyway, nice work.

5 caractere, 3 digits. Sunt de p?rere c? e mai important? descoperirea în sine decât suma, e semn c? totu?i ?tie ce face ?i e pe drumul cel bun.

[tromfil]

Conform tabelului e de 10.000$. Felicit?ri!