Unfortunately, <REDACTED> refused to give me permission to disclose this simple vulnerability I found on one of their web servers. So after 11 months after I found it, with zero response from them, I decided to release it but redact the name.
Have you ever wanted to break into a <REDACTED> web server, but didn’t want to become someone’s lover in prison because of it?
Great news! There’s websites like HackerOne to the rescue. HackerOne is a bug bounty website that hosts companies looking for people to pound on their applications. If you manage to find something of concern, they may even pay you! One of the programs on HackerOne happens to be the <REDACTED>…. 🙂 Let the shenanigans begin
NOTE: There are rules that apply to each individual bug bounty program. I didn’t violate the rules outlined in the <REDACTED> bug bounty program and you shouldn’t either. Have fun, but do it without earning iron bracelets.
So earlier this year I took part in the <REDACTED> The long and short of it was, any site that fell under the <REDACTED> realm was fair game. So naturally I found every domain I could find of there’s (automated obviously). Then automated trivial scans of each, looking for low hanging fruit. Within an hour I had access to a <REDACTED>, <REDACTED> (<REDACTED>) web server and I was able to upload files to it.
Sound fun? Here’s how I did it!
For the super curious you can read my actual report sent to the <REDACTED>. However, you’ll get more info by reading the article below.
Scanning for Targets:
Before you can start attacking you need to scan for targets. Recon is key. I cannot recommend enough “The Hacker Playbook 2” (THPB2). This book will walk you through some great recon steps that will turn up a ton of targets. It has much more in there but this is the main thing I use it for.
I started with recon-ng. This tool is AWESOME. Similar to Metasploit, it has modules that you can load up and use. I used recon-ng to search for hidden domains and subdomains that belonged to <REDACTED>
With this tool I was able to uncover hundreds of domains that belonged to <REDACTED> and once I had them, I could start the automated scanning. I use mainly the Google, Bing and Biadu modules. I also used the brute force module. This one turns up a bunch of great results.
For <REDACTED> there were an unsurprisingly large amount of old web servers running that had old web applications on them. Great targets.
Automating For Low Hanging Fruit:
Given that the attack surface was so large, I decided that I would automate some scanning for low hanging fruit.
A great tool for poking at web servers is nikto This tool will run some automated scans against a web server and look for common vulnerabilities. It also pumps out other useful info.
To automate this scan I used something like
for targetUrl in $(cat targetUrls); do nikto -h $targetUrl ; done
This simple one liner runs nikto against every url in our target list.
After a short while of running, I saw this run across the screen.
Default account found for 'Jackrabbit Webdav Server' at /nikto-test-xn0s4xWM.html (ID: 'admin', PW: 'admin')wha wha whhhaaaatt? Could there really be default reds on a <REDACTED> web server?
The server also allowed for PUT MOVE DELETE which are all horrible to allow anyone to do.
Connecting to a Webdav Server:
To connect to our targets server we’re going to use a tool called cadaver This tool makes connecting to Webdav servers on Kali no problem. Just simply type the command cadaver <url>
Unfortunately I can’t show you a screen shot of this without exposing who the target was. You’ll have to take my word for it that it worked 😀
Uploading a File:
I had to make a choice at this point. The rules of the bounty clearly say only exploit to the minimum amount. My minimum amount was RCE on the web server though so uploading a file seemed fair game 😀
I uploaded a simple file to the web server and took a screen shot of me calling it from the web. That was more than enough proof that I had RCE on the web server. From this point I could easily get a shell and start moving into the network. Very VERY dangerous given that it was a <REDACTED> web server.
Clean up When You’re Done:
These companies are reaching out for help. Don’t wreck their environments. Keep good notes on everything you do to their machines. Remove accounts you create and delete files you put on them. Treat it how you would want someone treating your machine if they got in.
Write a Great Report:
You should download the report I sent to the <REDACTED>. It’s far from professional but it’s a lot better than some of the shit people are sending in. Your report should include the tools needed to repeat the process. Detailed steps and screenshots. Remember that your audience likely won’t have the same skillsets as you so you need to be as clear as possible. Don’t assume any prior knowledge on their end.
If applicable, also include information on what can happen if this issue isn’t fixed. I could have easily gotten a shell on their web server or worse, embedded a payload in their landing page and shelled anyone visiting their page.
Summary:
Well that was fun! We recon’d, we scanned, we cadaver’d and we exploited. Makes for a fun afternoon. I hope that you were able to get something out of this article and give it a go yourself.
Just remember that it may take some time to get a response from some companies. I submitted my report to the <REDACTED> in MARCH! They took about 2-3 months for the initial response, another 2 months to fix it and finally another ## months to agree to let me disclose it! and never let me disclose it.
If you do find anything and need help exploiting it, feel free to reach out on twitter. I’m always happy to lend a hand.
