No RCE? Then SSH to the box!

This blog post is about my first RCE shell (or whatever you want to call it) that I got in a bug bounty program back in summer 2017. There’s absolutely nothing special about it and you might not even learn anything new, but if you do, I’m glad I was able to help! I just felt that it was a different way of getting access to a box, especially in bug bounty.

The always fun recon

After having done regular recon on a domain with a scope of *.domain.com using tools like Sublist3r, Aquatone, Nmap and so on, I ended up with a list of hundreds of subdomains. I didn’t know where to start so I decided to use EyeWitness to take screenshots of the web pages so I get an idea of what targets look vulnerable so I could start off with those. In the EyeWitness report, there was an application that was running on port 8080 that had a default home page of a CMS I had never heard of so I decided to look into that one first. By browsing to the target, I quickly found a login page which fortunately for me had default credentials of admin:admin. However, there was absolutely nothing in the admin panel, no juicy information, nothing, it was empty. I still decided to report it to the bug bounty program as “Default credentials in admin panel” and luckily for me they rewarded it as a critical bug even though I didn’t gain access to any sensitive information.

Quote from Jobert

Just by the look of the default home page and what it looked like in the admin panel, I felt that there was more to it. As Jobert once said, If it looks old and vulnerable, then it probably is! I decided to look into the CMS’ website to see if I could gain more information on it. It was an open-source software so I figured I’d spin up an EC2 instance on AWS and install it on there so that I can play with it myself. I noticed that the service had to run with sudo privileges which is obviously not a best practice (keep this in mind for later). Once that was done, I did a quick Google search to see if I could find any existing CVEs for that software and interestingly enough, there was again absolutely nothing. So this meant that it was quite possible that no one ever made a security audit or penetration test of this software. This was my time to shine!

Quick and easy findings

I browsed around for about 30 minutes to an hour just to get a good understanding of how it worked. While doing that, I quickly found 2 XSS; one stored and one reflected. Then after checking all of the requests in Burp Suite, I ended up finding an LFD and 2 XXEs. There were a lot of API endpoints so I took a look at their API documentation and quickly realized that every single possible action on that CMS had improper access controls. Meaning that an unauthenticated remote attacker could exploit the stored XSS, the LFD and both XXEs by themselves without even being logged in to the admin panel. On top of that, there was also no CSRF protection at all so if the attacker didn’t want to exploit the vulnerabilities, they could’ve easily created a few CSRF exploits and try to have the admin do it for them!

LFD/Directory traversal to the rescue!

At this point I knew, it was a matter of time before I ended up with an RCE on this CMS. I just had to continue poking around and I’d end up finding one. One of the interesting endpoints I had identified earlier, is that I could update template files. What was interesting about it was the parameter being used to update the template. This is what it looked like. All sensitive information has been redacted. alt txt

On a successful update, the response would look like this. alt txt

The next logical thing I had to try was changing the path to something else to see if I could upload files elsewhere than in the /config folder. So I gave it the path /../../../../../../../../../../../../tmp/test.txt and replaced the body of the POST with This is a test.. I got the same response as the previous request… awesome! But, how do I confirm that the file has really been uploaded? Don’t forget that this testing was done on my own server so I could’ve just checked to see if the file was there, but I wanted to go the black-box route and find another way. Here comes the LFD to the rescue! Using the LFD/directory traversal I had already found, I checked to confirm if the file had just been uploaded. And there it was! alt txt

No RCE, what now?

Great! Now I knew I could upload files and not just in certain locations on the server, I could upload them anywhere I wanted since the service was running as root.

Of course, the next step would be to try to execute my uploaded files right? Well, it turns out that actually was a problem for me. The service was deployed as a war file in Tomcat so there wasn’t really a specific path where I could’ve uploaded and executed files. Maybe with the help of someone else, I could’ve figured out a way how to do this but since I wasn’t too familiar with that I couldn’t do anything at that point, unfortunately. So that got me thinking back to the days where I was working on the OSCP. I still had my notes so I looked them up and got a few ideas. I first uploaded a bash script in the cron.hourly folder but with the default OS configuration, it never worked. Assuming the bug bounty program had the same default settings, it would’ve probably not worked either. Then I told myself, well I have root access, why not just SSH directly to the box?

To do this, I had to upload my SSH key to the server. This was simple enough, I just had to configure the path parameter accordingly and put my SSH key in the body of the POST request. alt txt

The last thing left was to try to login with my newly uploaded SSH key. There you go, it worked!

alt txt

Now that I had accomplished my goal, I decided it was time to report these bugs. I contacted the CMS’ dev team to let them know about these vulnerabilities and they replied right away asking if I would like to join their Slack team so we could discuss my reports a bit more. We ended up having a few calls to clarify a few points and they asked me to test their new version before they released it.

I also reported these bugs to the bug bounty program who used that CMS. I obviously did not test anything on their site since it would’ve not been ethical but I did provide a clear PoC for all of my findings asking them to test on their end. All of my reports were validated and accepted, including the file upload of the SSH key which was the confirmation of my very first “RCE” in a bug bounty program!!

Please don’t hesitate to post questions, comments and feedback below or you can DM me on Twitter if you’d like :D



comments powered by Disqus