Advent of Cyber 2023 — Day 12 Writeup

Learning Objectives

• Defence in Depth

• Basic Endpoint Hardening

• Simple Boot2Root Methodology

---

As discussed earlier, we're dealing with a server that is vulnerable by design. It contains misconfigurations and has been implemented with poor or simply nonexistent security practices. This part of the task will walk you through one of the many ways we can get elevated privileges on the server.

Skipping the enumeration part, we can access Jenkins via Firefox on its default port: http://10.10.174.112:8080. You should be greeted by a page that looks something like this:

What is the default port for Jenkins?

Answer: 8080

Getting a Web Shell

We instantly gain access to the general workings of Jenkins. Explore the features that we can play with, and you'll see that there's a way to Execute arbitrary scripts for administration/troubleshooting/diagnostics on the machine. On checking this further, you'll see this can be used to spawn a web shell.

Click on the Manage Jenkins button on the left side of the page. Scroll to the bottom, and you'll see the option we want: Script Console.

Script Console is a feature that accepts Groovy, a type of programming language for the Java platform. Let's jump straight in and try to establish a reverse shell using this feature! The example below is using an edited version of this script.

Copy the script above and paste it into the Script Console text box. Remember to change the host value to your attacking machine's IP. Open a new terminal and set up a netcat listener using this command: nc -nvlp 6996

What is the password of the user tracy?

Answer: 13_1n_33

Once both the reverse shell script and the netcat listener are ready, you can press the Run button at the bottom. You should see an established connection in your attacking terminal, and you can test the shell by sending some typical Linux commands such as id and whoami. A successful connection would look something like this:

Getting the tracy User and Root

Now that we have a web shell with the Jenkins user, we can explore the server's contents for things that we can use to improve our shell and perhaps elevate our privileges.

Check the usual folders, and you'll be able to find an interesting bash script file in the /opt/scripts folder named backup.sh. Check the contents of the file. You'll find a simple implementation of backing up the essential components of Jenkins and then sending it to the folder /home/tracy/backups via scp. The file also contains the credentials of the user tracy.

The scp command is a clue that SSH may be used on the server. If so, we can use it to upgrade our user and shell. Open a new terminal and log in via SSH using the command: ssh tracy@10.10.174.112. Enter the password when prompted, and you will be logged in to the tracy account!

Finally, we can use sudo -l to find out what commands the user is permitted to perform using sudo.

To remove tracy from the sudo group, we use the following command: sudo deluser tracy sudo. To confirm removal from the sudo group, use sudo -l -U tracy.

Hardening SSH

The path to root has been made more complicated for the attacker, but that doesn't mean we should stop here. Attackers can be very creative in finding all sorts of ways to accomplish privilege escalation. Any additional layers will make it a lot harder for the bad actors to achieve their objectives.

Remember that as attackers, we were able to use SSH in this server to move laterally from a lower-level user. In light of this, we can disable password-based SSH logins so we can thwart the possibility of an SSH login via compromised plaintext credentials that are just lying around.

In the admin shell, go to the /etc/ssh/sshd_config file and edit it using your favourite text editor (remember to use sudo). Find the line that says #PasswordAuthentication yes and change it to PasswordAuthentication no (remove the # sign and change yes to no). Next, find the line that says Include /etc/ssh/sshd_config.d/*.conf and change it to #Include /etc/ssh/sshd_config.d/*.conf (add a # sign at the beginning). Save the file, then enter the command sudo systemctl restart ssh.

Promoting Zero Trust

Once we've applied all of the hardening steps discussed, you'll notice that we're able to patch many of the vulnerabilities that we initially exploited to get to root (in terms of the attack methodology discussed earlier, at least).

We're back in the web shell that served as our initial foothold in the system, and it's accessible as a result of a Jenkins implementation that assumes full trust within the environment. As such, it's fitting that the last hardening step we'll apply in the server is one that promotes zero trust.

Instead of opening up the workings of the platform to everyone in the environment, this change will allow just those who have access to the platform. In the admin terminal, proceed to Jenkins' home directory using the command: cd /var/lib/jenkins

Here, you will see two versions of the Jenkins config file: config.xml and config.xml.bak. Fortunately for us, the administrator kept a backup of the original configuration file before implementing the current one. As such, it would be more straightforward for us to revert it back to the original by removing the comments in the XML file. For reference, the comment syntax is signified by "!--" right after the opening bracket and "--" right before the closing bracket. Anything in between is commented out.

What's the root flag?

Answer: ezRo0tW1thoutDiD

What is the error message when you login as tracy again and try sudo -l after its removal from the sudoers group?

sudo deluser tracy sudo

this command will delete user tracy from sudoer group and then you can get answer of this question.

tracy@jenkins:~$ sudo -l
[sudo] password for tracy: 
Sorry, user tracy may not run sudo on jenkins.

Answer: Sorry, user tracy may not run sudo on jenkins.

What's the SSH flag?

Answer: Ne3d2SecureTh1sSecureSh31l

What's the Jenkins flag?

Answer: FullTrust_has_n0_Place1nS3cur1ty

thanks for reading!!