netcat

All posts tagged netcat

Walkthrough of a Linux machine exploitation attacking WordPress then privilege escalation via abuse of Jenkins.

Deployment and preparation

As per the pre-engagement briefing to avoid any hiccups during the testing the IP-address allocated for us should be added to the host file of our attacker machine. This way we eliminate the domain name translation having our machine directly reaching out to the victim machine.

Initial enumeration

Our usual Nmap scan shows only 2 open ports, 22 and 80. 

HTTP enumeration

Let’s take a closer look of this service on port 80 with another Nmap scan which shows us that there might be some interesting directories available.

This has been confirmed by the Ffuf tool as well.

If we navigate to the link we could not only confirm that it is indeed a WordPress site but there is a user called admin who posted an entry and he is probably an administrator.

Let us try to find the password of that admin with a WPScan bruteforce attack. Success. 

HTTP exploitation

We manage to login to WordPress with the credentials gathered.

During the WPScan attack above, the tool provided us with a spin-off info namely that the TwentySeventeen WP theme is out of date. This might help us to get a shell on the machine. Let’s get a copy of a php-reverse-shell from our Kali shared folder, modify the IP-address to ours and copy-paste it into the 404.php template in the WordPress editor.

Then after saving the modified 404 template all we need to do is just go to the URL on which the template is accessible.

We should receive a low-level non-interactive “sh” reverse-shell on our Netcat listener. Let us upgrade it straightaway with spawning an interactive “bash” pty shell just to make our life a bit easier.

Lateral movement

First of all let’s check the users on the machine. We can see that there is a user called “aubreanna”, let’s check all the files which have this name in them. Yes, there is a text file called “wp-save” in which his/her password is mentioned.

Now all we need to do is just taking over the shell for the user aubreanna and find the user flag. Let’s do that.

What is the user.txt flag?

Privilege escalation

Now we should go for the root flag, but we do not have the rights for that. Luckily there is another text file in the same directory in which the user flag was. It says there is an internal Jenkins service on 172.17.0.2 port 8080. This is confirmed, we can see a /16 range for a Docker container.

The easiest way to reach the Jenkins server considering what is available on the machine is to setup a local SSH port forward. The reason for this is that it is only for internal use and as such not available remotely, but if we tunnel out its port 8080 to an arbitrary port of our attacker machine it will be reachable for us. So, essentially what happens in this case is that we login to the machine via port 22 (SSH), then using the SSH service of the victim computer we mirror the internally available Jenkins service on 172.17.0.2:8080 onto port 5000.

We are able to get to the login page in this way using the same port number on 127.0.0.1.

Now we need some credentials to the server. Let’s fire up BurpSuite to catch its post request first.

Let’s feed the post request obtained into Hydra and bruteforce the login password using the user “admin” as it’s been in use for WordPress as well. Success.

Let’s login using the credentials gathered and then navigate to the Script Console in Jenkins (Nodes-> Master). There are several reverse shells available against Jenkins, I have decided to try out one from the Pentesteracademy blog. All we have to do with it is just changing the IP-address to our attacker machine and obviously the preferred port number to be added too.

Upon saving the script in the console, we should get back a non-interactive reverse shell on our Netcat listener which we update with our python pty script as usual. Next let’s check the “opt” directory again in which we found the wp-save.txt note above. We are lucky, fortunately admins stick to their habits nowadays, lol.. 🙂

Ok, nice one, we’ve got the root password. Let’s check it out via SSH and try to find the root flag.

What is the root.txt flag?

Thanks for reading and as always, any feedback is most welcome.

Walkthrough of a Windows machine exploitation attacking the Microsoft Eternal Blue vulnerability.

Deploying the vulnerable machine and initial enumeration

From our usual Nmap scan we can see that 7 TCP ports are open (135, 139, 445, 3389,  49663, 49667, 49668) on the machine. So the higlights are the IIS 2016 Windows Server and the vulnerable SMB service which lacks enforced signing.

SMB enumeration

A more specific Nmap scan against port 445 gives us some more hints to go on. We can see that it not only brings up some shares but also shows an existing remote code execution (RCE) vulnerability.

Let us try to connect to the listed shares. We manage to get “nt4wrksv” to work, downloading the password text document and figuring out the coding and the passwords eventually.

HTTP enumeration and exploit

As the gathered credentials via the SMB service do not look like being useful for the time being we try to move forward having a bit closer look of the HTTP ports particularly 49663. The earlier found passwords.txt is accessible which gives us some hope that a reverse shell exploit might be uploadable.

Let’s create an ASPX payload with Msfvenom as IIS webservers usually execute ASP or ASPX thanks to the open source web framework  .NET. After creating the payload we shall upload it to the earlier discovered SMB folder and call it with Curl.

We should get back a low-level shell on our Netcat listener.

What is the user flag?

Privilege escalation

This is to be achieved by exploiting an existing impersonation vulnerability using the PrintSpoofer tool from GitHub. First let’s get the executable, then upload it via SMB to our working directory on the server.

Then let us go to our low level shell and just run it from the same directory.

What is the root flag?

Thanks for reading and as always, any feedback is most welcome.

Walkthrough of a Linux machine exploitation attacking a blind SQL injection vulnerability in a Joomla CMS account then privilege escalation by taking advantage of Yum package manager.

Deploying the vulnerable machine and initial enumeration

From our usual Nmap scan we can see that 3 TCP ports are open (22, 80, 3306) on a CentOS Linux machine.  A Joomla content manager runs on the Apache webserver and MySQL MariaDB database there is in the backend.

Another more specific Nmap scan comes back with some even more interesting info with regards to port 80 and Joomla.

What is the Joomla version?

Let’s find some exploits for the vulnerability spotted by Nmap.

Exploiting CVE-2017-8917

We are going to use Sqlmap as suggested in the exploit description with some slight modifications. Most importantly I have taken out the “–level” switch entirely as the Nmap scan classified the vulnerability as critical (CVSS 9.8) meaning that the exploitation could be easier. We can save some time in this way as it would not need that many payloads to be run against the weaknesses. As we can see below a user with it’s password hash is successfully carved out from the database table.

After saving the hash into a text file let us crack it with John.

What is Jonah’s cracked password?

Now we have the Jonah’s password, so let us login to Joomla via the admin URL which was found by an earlier Nmap scan above. The plan is to get a reverse shell by modifying a PHP Joomla template with embedding suitable reverse TCP exploit code into it. Let’s navigate to our proposed nest template which is the “index.php” in the “Protostar” theme. We can take out all the comments from the beginning of the exploit code to save some space. Also do not forget to modify the IP-address of your machine and the desired port number which should match with the port number of your Netcat listener. After inserting the exploit code at the top of the index.php, let’s save it.

Then upon navigating to the corresponding URL of the website we should receive a reverse shell on our listener.

Privilege Escalation

Let us spawn an interactive pty shell quick, then we have to raise our privileges from the webserver user to root. We might poke around for some credentials and found some in the webserver directory.

Luckily that works with the only user found on the machine, so we are fortunate enough to answer to another question.

What is the user flag?

Now let us login with SSH as we know a user and his password as well and check his privileges. 

What we can see is that he is able to run the Yum package manager which can be forced to spawn a root shell by loading a custom plugin according to GTFOBins.

All we have to do is just copy-paste the lines into the terminal one by one.

What is the root flag?

Thanks for reading and as always, any feedback is most welcome.