#offensivesec

It’s been a while with life stuff getting it the way and whatnot; over last night and today I have rooted Stapler 1

(https://www.vulnhub.com/entry/stapler-1,150/) :)

I actually learned a few things from this- it was my first experience with enum4linux and SMB file shares; I’ve also identified my main areas of weakness with hacking (seems to be more web app based challenges and also lacking the needed organization and thoroughness.)

Enum4linux is now 1000000000% a part of my arsenal, actually think I’ll be going back to some machines I hit a roadblock on and running that against them.

Anyway, on with my solution.

Scans

I executed my custom enum script to begin, resulting in the feedback of a nice amount of open ports:

So, we have two web servers (NOTE: Must made amendments to my enum script to account for multi web servers!), VSFTPD, dnsmasq (DHCP and DNS server), Samba (a filesharing service), a listener on p666 that Nmap cannot identify and a MySQL server.

After running Nikto scans against the two websites, there were a few interesting points; I’ll confess- web apps are not my favorite thing. Thus I decided to look at the other running services before focusing my full attention on the web servers.

Enum4Linux

While researching Samba (after only noticing the open port a couple of hours after beginning the machine *frustrated sigh*), I read and saw the output for Enum4Linux and immediately knew it was a good idea to run this.

I will say: this script is great. It showed me existing users on the machine in addition to a considerable amount of information about the service of interest- SMB.

With the information discovered, I proceeded to harvest available files.

The share Kathy held some useful information about the in-use FTP server: the config file for the server was present which revealed the feature of anonymous login.

Obviously I then checked what was available to the anonymous user; there was merely a note instructing Elly to save ‘payload information’ to her FTP account.

There was also an SMB share named ‘tmp’ in which there was a file called ‘ls’ with the following output:

.: total 12.0K drwxrwxrwt  2 root root 4.0K Jun  5 16:32 . drwxr-xr-x 16 root root 4.0K Jun  3 22:06 .. -rw-r--r--  1 root root    0 Jun  5 16:32 ls drwx------  3 root root 4.0K Jun  5 15:32 systemd-private-df2bff9b90164a2eadc490c0b8f76087-systemd-timesyncd.service-vFKox

After this, I looked further at the output of the enum4linux script in order to identify users for brute force attacks against FTP, SSH and MySQL:

With users identified, I saved these names to a text file and utilized Nmap NSE scripts for the brute force of FTP and MySQL.

Results for FTP. :) logging on with either credentials reveals a whole list of files; in all honesty this is where my exploration of FTP ended as I tried the same credentials in SSH and found success.

So, now we have a stable connection to the system... Just one trick away from root privileges.

I ran my custom privesc script and -to my annoyance- this didn’t reveal the specific sh file; it did refer to cronjobs which gave me the idea to try that. I tried to exploit this without research and upon failure I moved on until hours after playing around with the use of exploits (goes without saying I’ve now amended my enum script to avoid that happening again!)

After several crashes from attempting Dirtyc0w, I began to get the feeling that I was approaching things wrong- I’d done it again, hadn’t I?

I’d jumped head first into the same rabbit hole I encountered when rooting Mr Robot... There’s usually ALWAYS a simpler way, Courtney... XD

I took a moment to look through my notes again and I focused on my first observation- the use of cron jobs to escalate privileges. In my defence I have never escalated privileges like this; in hindsight I gave up on that method far too quickly and I should have first researched privesc via cron jobs before moving onto researching exploits.

The echo command that failed shows what I added to the file cron-logrotate.sh. The file also initially has a note directed at a user that hints it could be used for malicious purposes (something like ‘something needs doing about this’)

This is why my initial attempt failed: I originally tried to append to logrotate and manually execute it before then creating a cronjob (thought this would be created under root but either I didn’t create the job correctly or I was wrong!)

As cron-logrotate is executed automatically depending on config and owned by root,  the script executes, changing the permissions and owner of our created file- it’s now owned by root and -when run- it will execute with root privileges due to the setting the uid bit.

Conclusion

Genuinely have learned alot from this machine-I have a few changes I’m going to make to my enum script (both to accomodate multi web servers and to point out running services) in addition to the amendments I’ve already made to my privesc script.

What frustrates me is that my slowness is more down to rushing ahead and being to eager to complete things rather than inability: I actually only noticed the presence of dnsmasq when writing this walkthrough (but this can be helped by amending my enum script.)

After massively failing at Brainpan 2 for a few weeks, I thought I’d take a breather and collect the 3 possible keys from Mr. Robot. It’s frequently referred to as an ‘OSCP-like’ VM though it’s rating is only beginner-intermediate.

So, the usual: download the VM (https://www.vulnhub.com/entry/mr-robot-1,151/), import into Oracle VM VirtualBox and perform an nmap port scan of your network:

As .17 is the local IP of my Kali Linux instance, it’s obvious that our target is .19 (NOTE: if the VM does not appear, scan every port using ‘-p-’.)

Before commencing with further tests, I added .19 to /etc/hosts and executed a more thorough scan on Mr. Robot (nmap -sV -T5 mr-robot -p-); while this revealed the web servers listening on port 80 and 443 were Apache, there were no open ports beyond these.

Fair enough, time for some nikto and dirb!

Nikto has revealed that responses from the web servers indicate the presence of PHP 5.5.29 and WordPress, in addition to WordPress login portals. It has also flagged the presence of a directory named ‘admin’; upon attempting access, the request is simply looped and no useful data can be found.

I also took the opportunity to test out WPScan- a WordPress vulnerability scanner that comes preinstalled with Kali Linux. While this does show the presence of the XML-RPC API and confirms some of Nikto’s findings, it’s definitely not required.

Dirb continued to run and revealed the presence of robots.txt, in addition to various other pages leading to redirects or lacking any sort of data.

Upon visiting robots.txt, you receive indication of the presence of key 1 and a file of dic format.

For any person with experience in boot2root challenges, they’ll probably have already guessed the obvious path forward- head to the wp-login page found earlier and investigate fsocity.dic.

To remove duplicate lines, I piped the contents of fsocity.dic to sort -u and stored the results in a new file (cat fsocity.dic | sort -u > unique.txt)

I looked through the file briefly for anything resembling a username firstly and by trial and error I received confirmation of the existence of Elliot.

There we go, so now we just need a password; like I’m going to sit and manually try each possibility myself!

Here comes Bash to save the day (yes, I could have used this for users too but I wanted to see the change in error message for myself.)

Not the sexiest but who cares about appearance when  the result’s the same? We still know that the password is ER28-0652.

Surely enough, this password grants us access to the wp-admin dashboard. Although my first time infiltrating a system running WordPress on their web servers, it only took me a couple of minutes before I discovered the themes editor would allow me to alter PHP files… So, also my first experience with a PHP reverse shell!

I originally attempted to alter a php file on the active twentyfifteen theme but executing this in my browser yielded no reverse shell, thus I editted a PHP file of theme twentyfourteen (honestly any should work but I used 404.php)

Surely enough, we receive a stable connection from mr-robot through netcat from user Daemon; further investigation reveals the presence of /home/robot.

Hmm, I’ve never watched Mr Robot but for an alleged hacker- this is pretty laughable… He hashes his password with 1) a crackable hashing algorithm and 2) saves it into a file revealing the algorithm in use… Yeah if real companies are really this stupid then God help our data!

Anyway, let’s give it a run through Johnny with /usr/share/wordlists/rockyou.txt:

Wow, the alphabet… Isn’t he smart? Into Robot we go.

After making my usual mistake and jumping to the more complex methods of privilege escalation first (exploit delivery… ALWAYS run basic checks thoroughly first, https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/ is a really good checklist to follow and refer to if you’ve fell down a rabbit hole,) I discovered that the nmap binary was not only present on the machine; it’s permissions also meant that the program executed under the privileges of the owner, not the user responsible for execution.

From this point, you can simply execute ‘nmap –interactive’ and then ‘!sh’, giving you root access to the system- go ahead and grab key-3-of-3 from /root.

Points to take from Mr. Robot:

You should always look for the most simple forms of entry and test simple vulnerabilities first and thoroughly before looking further into a service (this is my main issue- I jump to investigating further too soon!)

Only give web servers a brief manual check until scans finish- if scans don’t reveal any interesting directories or vulnerabilities, this is the time to begin looking into the site’s content (and other services if present.)

If you’ve tried something with a script that you strongly believed was going to grant you access to a specific area of the web server, check your syntax before moving on: I pretty much wasted Saturday looking more in-depth into Mr. Robot just to discover my original brute force script was only executing grep in the event of curl failing (yeah I know, what a noob!)