ChartBeat

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/

Setting up an EC2 instance on Amazon AWS using CLI

The basic requirement of doing this exercise is to have a linux environment and latest AWS CLI installed on it

Steps: Follow the steps written below in similar order. These are generalized steps for creating any instance on AWS EC2. At the end output of desired commands are pasted.
  1. Create an account on Amazon Web Services and download rootkey.csv file from Security Credentials section of your account. This is the only step where we will
    interact with GUI. Later steps are to be done from CLI of your Linux-lab.

  2. Login to your Linux-lab and type command aws configure
    Now enter Access Key ID and Secret Access Key from rootkey.csv file and keep Region NameOutput Format on default(You can change if you want)

  3. Let us create a key pair which will be used to create an instance on AWS ec2, You can use command aws ec2 create-key-pair --key-name Mykey --output text > Mykey.pem
    to generate a key pair. Alternatively we can generate a key pair using tool of our choice on host machine (Linux-lab in this case) and import it to the AWS environment

    The commands are as follows;

    I have used OpenSSL to generate a 2048 bit public key

    openssl genrsa -out my-key.pem 2048

    Now let's save this key to a local file

    openssl rsa -in my-key.pem -pubout > my-key.pub

    We can use command cat my-key.pub to find key-material which we will use in next command while import. The Key-material is in between -----BEGIN PUBLIC KEY-----
    and -----END PUBLIC KEY----- which is reasonably large, I have used first few characters of the value.

    Finally we can import the key using below command to our AWS environment

    aws ec2 import-key-pair --key-name my-key --public-key-material MIIEpAIBAAKCAQEA

    Now let's make key pair file private by executing the command below

    chmod go-rwx my-key.pem
  4. It's time to create a security group now. One can also use the default existing security group. We can check existing security groups using command

    aws ec2 describe-security-groups

    The command to create security group is as follows;

    aws ec2 create-security-group --group-name My-Security-Group --description "My-SG-NEW"

    Now we need to set permissions for the created security group so that we can access our instance from almost anywhere. The command to assign the permission is as follows;

    aws ec2 authorize-security-group-ingress --group-name My-Security-Group --protocol tcp --port 22 --cidr 0.0.0.0/0
  5. Now we need to find image-ids of OmniOS and any other linux distro which will be deployed on our instances. The two commands used to find those images are shown below;

    aws ec2 describe-images --filter "Name=virtualization-type, Values=paravirtual" | grep OmniOS
    aws ec2 describe-images --filter "Name=virtualization-type, Values=paravirtual" | grep amazon | grep 2015

    I will be creating instances of OmniOS and Amazon linux. I have used above commands to find specific versions of Images to deploy.
  6. As we have everything what we need to start an instance on our AWS ec2 environment, let's create an OmniOS and Amazon linux instances

    The commands are as follows;

    aws ec2 run-instances --image-id ami-20baa741 --count 1 --instance-type t1.micro --key-name my-key --security-groups My-Security-Group
    aws ec2 run-instances --image-id ami-d93622b8 --count 1 --instance-type t1.micro --key-name my-key --security-groups My-Security-Group
  7. We can check status of our started instances. The command to check the status of instances are as follows;

    aws ec2 describe-instances
  8. Now we can connect to our running instances by using below commands

    ssh -i my-key.pem root@publicdomain_of_OmniOS
    ssh -i my-key.pem root@publicdomain_of_amazon_linux
  9. Now to shutdown/stop instances we can use below shown commands;

    aws ec2 stop-instances --instance-ids i-OmniOSID
    aws ec2 stop-instances --instance-ids i-AmznLinuxID