Brains
The city forgot to close its gate. - by Dex01, strategos and l000g1c
Last updated
Was this helpful?
Upgrade Simple Shells to Fully Interactive TTYsThe city forgot to close its gate. - by Dex01, strategos and l000g1c
Last updated
Was this helpful?
The following post by 0xb0b is licensed under CC BY 4.0
This challenge is a purple challenge in which we first compromise the target and then investigate the actions taken by an adversary abusing the specific CVE found.
We start by compromising the server.
We start with an Nmap scan and find three open ports. Port 22, where we have SSH, and ports 80 and 50000, where a web server is running.
On the standard port 80 we find only one page, which is under maintenance.
Unfortunately, the directory scan does not find anything conspicuous either.
We continue with the website on port 50000. Here we are greeted with a login to TeamCity. TeamCity is a continuous integration and continuous deployment (CI/CD) server developed by JetBrains. It is used to automate the process of building, testing, and deploying software. We can see that version 2023.11.3 is in use.
A further Gobuster scan on port 50000 is optional, but not necessary. The information about the version used is sufficient.
As mentioned before, the version 2023.11.3 is in use.
After a quick research, two corresponding CVEs could be found. CVE-2024-27198 and CVE-2024-27199. Both provide an authentication bypass, which then allows arbitrary plugins to be uploaded with the gained access to gain remote code execution.
A detailed explanation could also be found here:
To add a user with the administrator role manually, the following payload could be used, but it still needs to be adapted for our use.
What is happening here?
To leverage this vulnerability to successfully call the authenticated endpoint
/app/rest/server, an unauthenticated attacker must satisfy the following three requirements during an HTTP(S) request:
Request an unauthenticated resource that generates a 404 response. This can be achieved by requesting a non existent resource, e.g.:
/haxPass an HTTP query parameter named jsp containing the value of an authenticated URI path. This can be achieved by appending an HTTP query string, e.g.:
?jsp=/app/rest/serverEnsure the arbitrary URI path ends with .jsp. This can be achieved by appending an HTTP path parameter segment, e.g.:
;.jspCombining the above requirements, the attacker’s URI path becomes:
By using the authentication bypass vulnerability, we can successfully call this authenticated endpoint with no authentication.
We then adapt the payload and add our user 0xb0b.
We should now should be able to log in as 0xb0b.
And we have access to the dashboard as admin.
From here we could take the following steps to get a reverse shell. But unfortunately there is no agent installed that we could use for this:
Login as admin user.
Create a new project in admin dashboard.
Click "Manual" tab and fill required fields.
A new project is created.
In the project home, create a Build Configurations.
In the build configuration page, click "Build Steps" on the left menus.
Add build step.
Select "Command Line" in Runner type.
Put a Python reverse shell script in the "Custom script".
Start listener in local machine.
Click "Run" button in the build page.
We should get a shell in terminal.
We could now craft and upload a plugin ourselves. Or use a script that does all this automatically: Create an admin user, upload a plugin and run it for remote code execution. We can find the following:
We install its requirements.
And run the script on the target. We receive a web shell. Which we want to upgrade to a more interactive shell.
To generate a payload, we use revshell.com and choose our favorite one using busybox.
We set up a listener on our desired port on our attacker machine and run the payload in the web shell.
We receive a connection back and upgrade the shell. We are the user ubuntu, and find the flag in the home directory of the user.
We switch off the machine and move on to task two with a new machine. Here we examine the steps of the attacker who carried out this exploit using Splunk and look at the various logs on the machine to understand what happened.
To see which user was added after the exploit was executed, we can check the /var/log/auth.log. In this, we only have to look for the entries new user. One in particular stands out here, which was created on 04 July 2024.
The next question is about subsequently installed packages on the machine. Here we must first limit our time period. We select the time period in which the user was created. We find out which packages were installed in /var/log/dpkg.log. After we have applied the time period, we find two entries, both of which are conspicuous.
The last question is about the plugin that was installed. This is the plugin that previously gave us RCE. So we are talking about the TeamCity plugin. We can trace this in the log /opt/teamcity/TeamCity/logs/teamcity-activities.log. We restrict the time period again.
