Saturday, July 23, 2016

RCE in Ubiquiti Networks AirController 1.4.2

On March 31st, 2016, I found and reported a remote code execution in Ubiquiti networks Aircontroller version 1.4.2 which was downloadable from http://community.ubnt.com/. The AirController version was pretty old, so there wasn't any significant risk as users were already using updated version.

After I configured AirController 1.4.2 on my Ubuntu machine, I started playing around with the web app. The UI was very old and unimpressive. I thought of running nmap service banner grabbing on target where AirController is installed, and found JBoss Seam running on port 9080, I Googled immediately for existing exploits in JBoss Seam.

JBoss Seam was vulnerable to RCE and CVE-2010-1871 was assigned to it. I landed up on this blog which had clear instructions of which function was vulnerable and how to exploit the vulnerability. To execute the OS commands one has to find indexes for java.lang.Process and public static java.lang.Runtime java.lang.Runtime.getRuntime() methods. I had no idea where to start with finding an index, I tried finding if there is a metasploit module to do so and yet again metasploit came to rescue. 


I ran metasploit on target, found indexes and then I could exploit the vulnerability successfully after sending the below crafted request to server;


/seam-booking/home.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[19].invoke(expressions.getClass().forName('java.lang.R
untime').getDeclaredMethods()[7].invoke(null), 'mkdir /tmp/PWNED')}



I made a POC video of the attack.


Timeline:
March 31st, 2016 - Report Sent
March 31st, 2016 - Bug triaged
April 1st, 2016 - Resolved and Bounty Rewarded

Bounty was fairly low as the bug was in old version. Thanks for reading! Comments and suggestions are welcome.

Friday, July 22, 2016

Delete Project Owner's Account Google Pixate

I don't have any idea how Google calculates ranking in their VRP, but this was the only bug which I reported to Google ever and secured #74 on https://bughunter.withgoogle.com/.

Pixate was acquired by Google back in July 2015, it is a next-generation mobile interaction design service aimed at helping designers create complex animations and interactions without writing code. The platform generates 100% native mobile prototypes as they’re being designed, enabling you to refine unique experiences and communicate interactive ideas to stakeholders and team members. (Copied from http://help.pixate.com/knowledgebase/articles/461798-1-introduction)



On one bright day of June I was browsing Facebook and I saw people posting status of invitation they got for BountyCraft 2016 at Defcon. BountyCraft is an event co-sponsored by Google, Microsoft & Facebook, where they meet Bug Hunters from different countries, socialize, eat and have drinks. I had seen similar posts last year on my Facebook wall and wanted to be there, but I was lazy enough to not try and find a bug. And even if I had found one, I could not have been able to sponsor my trip to Vegas. Now as I had planned to attend Blackhat as well as Defcon this year, I wanted to attend this event. So here is the story explaining how I found that issue in Pixate. 



As it is tough to find bugs on main domain I started looking at Google acquisitions list. It is fairly easy to find bugs on acquisitions as it is developed by whole different team. I started to look for CSRF, XSS & session related flaws and wasted almost 3 hours as application was pretty secure. I stopped and thought why don't I start working with application's logic. Here is what I analyzed and did;


"A low privileged admin user can delete project owner's account"

Steps to reproduce:
1. Login to your account on app.pixate.com in chrome
2. Create a cloud project and invite a user on his email to collaborate
3. User accepts invitation, and creates account in firefox
4. Now project owner can see that the collaborator has joined the team
5. Project owner makes the collaborator admin of project in chrome
6. The collaborator can be removed from team only if a) owner removes him or b) the collaborator leave team by himself
7. Collaborator can see the userId of owner by clicking on the owner's name on team page
8. Collaborator clicks on remove account button and intercepts the request on proxy, changes the userId in query string to that of project owner's
9. As soon as all the requests and responses are forwarded from collaborator, owner's account gets deleted
10. Owner can no longer login to his account

I created a video proof of concept which can be seen below.


Timeline:
June 15th, 2016 - Report sent, automated response received
June 15th, 2016 - Bug Triaged
June 15th, 2016 - Bug Filed
July 12th, 2016 - Fixed and Bounty rewarded

Finally I got invitation from Google Security team for BountyCraft 2016. Thanks for reading, comments and suggestions are welcome. 


Stored XSS in Zengine

I was working on Zengine's bug bounty program on Cobalt.io back in July 2015. As this was an an old program, most of the low hanging fruits were already reported. I didn't expect to find a XSS when I saw Shashank on top of the list 

Zengine is a cloud-based platform that empowers a non-technical person to quickly build custom business applications, while also allowing developers to extend the application by adding integrations and complex functionality.

It all started with creating a test account on Zengine and writing an XSS payload in new plugin name. After you create a plugin it gets listed on marketplace. I was not sure if I'll find something in the application as data validation protection was intact. After navigating to all pages manually, I was kind of bored and I clicked browse plugins in the marketplace (don't remember exactly how I reached there as I lost the POC video from dropbox). To my surprise I saw a cute little prompt from payload which I wrote earlier in my new plugin. Zengine Security team patched the issue in less than 24 hours.


Zengine rewarded me $1200 for the finding with appreciation.


Timeline:
July 9th, 2015 - Report Sent
July 10th, 2015 - Bug Patched, Bounty Rewarded

Thanks for Reading! Comments and suggestions are welcome.


      

Thursday, July 21, 2016

Setting up filesystem on Amazon EBS Volume

Setting up a filesystem on Amazon EBS volume and verifying the persistance of files created on filesystem after instance is terminated using CLI

In order to complete the desired task, I have chosen to create two instances of Amazon-linux and two instances of NetBSD using AWS CLI on my linux machine. A complete step-by-step guide to create an instance can be found on my previous blog. [After creating instances, follow the steps written below in similar order.] 


1.Create a 1GB volume using AWS CLI

aws ec2 create-volume --size 1 --availability-zone us-west-2b --volume-type gp2 

The availability zone can be found from "aws ec2 describe-instances" command.

2.Now, we can check the available volumes by using below command, the newly created volume will be shown as "available"


aws ec2 describe-volumes

3.Now, attach the newly created volume to desired OS instance by using below command

aws ec2 attach-volume --volume-id vol-1234abcd --instance-id i-abcd1234 --device /dev/sdf

Where /dev is directory containing special device files and /dev/sdf indicates SCSI drive exposed to instance


4.Now Login to your desired OS instance using SSH and run command "dmesg" to obtain information about the hardwares on system in NetBSD, and "cat /proc/partitions" to obtain information about newly added partition in Amazon-linux. These command will show the recently attached volumes with device location

5.Now create a filesystem on newly attached partition, commands to create filesystem on NetBSD and Amazon-Linux are shown below,


newfs /dev/xbd2a 
(Creates a default bsd filesystem on the given volume. It is optional to lable disk using disklabel(8))

mkfs -t ext4 /dev/xvdf
(Creates ext4 filesystem on the given disk block on Amazon linux)

6.Mounting is the process by which we make filesystem available to system. In every linux system "/mnt" is the generic mount point under which we can mount our filesystem or devices. Create a directory (optional) in "/mnt" and mount the newly created filesystem on the created directory. The commands to mount filesystem is as follows;


mount /dev/xbd2a /mnt/example (NetBSD)
mount /dev/xvdf /mnt/example (Amazon-linux) 


7.Now create a text file in the mounted directory so that when we detach the volume and attach it to other instance, we get to verify whether the volume attached is the same or not;


vi test.txt

8.Now unmount the filesystem using commands shown below;

umount /dev/xbd2a /mnt/example (NetBSD)
umount /dev/xvdf /mnt/example (Amazon-linux)

9.Exit from the instance and detach the volume using below command;


aws ec2 detach-volume --volume-id vol-1234abcd

10.Now attach the volume to other instance of same OS, if you have detached volume from NetBSD then attach it to other NetBSD instance using command shown below;


aws ec2 attach-volume --volume-id vol-1234abcd --instance-id i-abcd1234 --device /dev/sdf

11.Now login to your instance where you attached the volume through ssh and mount the volume as shown in step 6 as per your OS.

12.You can verify if the volume is same by listing files under mounted directory through "ls" command.

This blog helps in learning how we can attach a new volume to a linux machine, create a filesystem on it and how we can use the mounted filesystem as regular directory in OS.

References: 

1.http://docs.aws.amazon.com/cli/latest/reference/ec2/
2.http://www.tldp.org/