LazySysAdmin is another VulnHub CTF.

The description suggests you shouldn’t overthink this. The author states that it was built out of frustration from failing the OSCP exam and that you should be looking right “in front of you” for the answers.

The description intrigued me, as my main goal this month has been to increase the speed that I solve these VMs and reduce the time wasted in rabbit holes.

NMAP Scan

root@kali:~# nmap -T4 -A -p- 192.168.1.241
Starting Nmap 7.70 ( https://nmap.org ) at 2018-09-29 19:53 EDT
Nmap scan report for LazySysAdmin.lan (192.168.1.241)
Host is up (0.014s latency).
Not shown: 65529 closed ports
PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   1024 b5:38:66:0f:a1:ee:cd:41:69:3b:82:cf:ad:a1:f7:13 (DSA)
|   2048 58:5a:63:69:d0:da:dd:51:cc:c1:6e:00:fd:7e:61:d0 (RSA)
|   256 61:30:f3:55:1a:0d:de:c8:6a:59:5b:c9:9c:b4:92:04 (ECDSA)
|_  256 1f:65:c0:dd:15:e6:e4:21:f2:c1:9b:a3:b6:55:a0:45 (ED25519)
80/tcp   open  http        Apache httpd 2.4.7 ((Ubuntu))
|_http-generator: Silex v2.2.7
| http-robots.txt: 4 disallowed entries
|_/old/ /test/ /TR2/ /Backnode_files/
|_http-server-header: Apache/2.4.7 (Ubuntu)
|_http-title: Backnode
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)
3306/tcp open  mysql       MySQL (unauthorized)
6667/tcp open  irc         InspIRCd
| irc-info:
|   server: Admin.local
|   users: 1
|   servers: 1
|   chans: 0
|   lusers: 1
|   lservers: 0
|   source ident: nmap
|   source host: 192.168.1.249
|_  error: Closing link: (nmap@192.168.1.249) [Client exited]
MAC Address: 08:00:27:51:85:32 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: Hosts: LAZYSYSADMIN, Admin.local; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: mean: -4h45m12s, deviation: 5h46m24s, median: -1h25m13s
|_nbstat: NetBIOS name: LAZYSYSADMIN, NetBIOS user: , NetBIOS MAC:  (unknown)
| smb-os-discovery:
|   OS: Windows 6.1 (Samba 4.3.11-Ubuntu)
|   Computer name: lazysysadmin
|   NetBIOS computer name: LAZYSYSADMIN\x00
|   Domain name: \x00
|   FQDN: lazysysadmin
|_  System time: 2018-09-30T08:28:58+10:00
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode:
|   2.02:
|_    Message signing enabled but not required
| smb2-time:
|   date: 2018-09-29 18:28:58
|_  start_date: N/A

Interesting Services

NMAP shows SSH, HTTP, Samba, MySQL, and an IRC server.

I’ve never seen an IRC server on one of these before, so I decided to go check that out first while I ran other scans in the background like Nikto and Go Buster.

I connected to IRC with Hex Chat and tried some things, but got nowhere with it. I reminded myself not to waste time.

Samba also looks interesting. I’ll come back to that later. But, first…

Checking Out the Website

Port 80 presents us with a basic static page. Nothing too interesting here, except some encouragement to try harder if you scroll down the page.

Checking the paths listed in robots.txt didn’t turn up anything too interesting.

Checking for Hidden Files

Next, I ran a Nikto scan as well as a directory brute force via Go Buster.

nikto -h http://192.168.1.241

Nikto and Go Buster gave me the same results, which were:

• A WordPress installation at /wordpress
• phpinfo() available at /info.php
• a phpMyAdmin installation

Checking WordPress

WordPress is known for being insecure when managed by “Lazy” Admins.

Ok, so his name is togie, got it.

That post has 2 comments, let’s view them.

The laziness continues

Here, it looks like our Lazy Sys Admin is using the default WordPress Admin account. I verified this by running wpscan and enumerating users.

I tried brute forcing the WordPress login with the Admin account (again, using wpscan) but this went nowhere.

Moving On

At this point, I hit a dead-end, so decided to revisit the enumeration in step 1. I hadn’t yet checked on the Samba stuff.

How about that Samba Share

Running enum4linux turned up some interesting things:

root@kali:~# enum4linux 192.168.1.241

 ========================================== 
|    Share Enumeration on 192.168.1.241    |
 ========================================== 

	Sharename       Type      Comment
	---------       ----      -------
	print$          Disk      Printer Drivers
	share$          Disk      Sumshare
	IPC$            IPC       IPC Service (Web server)

.....

S-1-22-1-1000 Unix User\togie (Local User)

Browsing Samba

I connected to Samba through the Kali Linux file explorer, but could have done this through the command line as well using smbclient.

The share called $share allowed anonymous connections…

This is clearly the Apache web root directory

Some things of interest here:

• deets.txt
• todolist.txt
• and the wordpress directory

Todolist had a fairly useless message, but deets.txt had the following content, supporting the “Lazy Admin” theme.

The next thing to check is wordpress/wp-config.php, which contains MySQL database credentials.

Checking for Password Re-Use

The MySQL password worked for logging into WordPress! From there, I spent some time messing with WordPress and got a reverse shell connection back very easily, but this mostly turned out to be a waste of time in the end. More on that coming up.

Using my reverse shell, I checked /etc/passwd and saw the user togie there, as expected, but nothing else useful.

togie:x:1000:1000:togie,,,:/home/togie:/bin/rbash

I tried the MySQL password on SSH with the togie user, but no dice. I also poked around in phpMyAdmin using the URL found earlier by Nikto, and it sort of worked but had some errors and seemed to be a rabbit hole. Before going any further, I decided to revise my approach.

Let’s Simplify

I thought back to the deets.txt file from earlier, which said the password is “12345”, which sort of matched what I found for the MySQL password. I thought I could apply the same theme to the SSH password. Eg: TogieSSH12345^^

Seemed plausible, and appropriately “lazy”, but this did not work.

It’s a long shot, but…

While I thought about what to do next, I figured I should at least be running a wordlist attack against the SSH login in the background.

I used hydra combined with rockyou.txt

root@kali:~# hydra 192.168.1.241 -t 4 -l togie -P /usr/share/wordlists/rockyou.txt ssh

DUH!

Haha! Oh geez.

The SSH password is literally 12345, which is the 2nd freaking line of rockyou.txt, a file that contains over 14 million passwords.

They already told me the password was 12345 back in deets.txt.

I was wasting time and over complicating things. Lesson learned, togie!

Let’s login…

Privilege Escalation

Normally, at this point I would run scripts to enumerate for privesc opportunities, and then start manually digging around the filesystem. But, the first thing I always try is sudo.

Too easy, Lazy Admin!

From here it’s a simple matter of running sudo su - to become root.

Root

And capturing the flag…

Things I wasted time on

• Hacking the WordPress site and getting a reverse shell back as www-data. This was obviously unneeded as I could have just connected by SSH using the credentials I already had from deets.txt.
• Trying various things using the words “Straya” and “yogibear” which were found on the WordPress site.
• Tooling around on the IRC server. Trying to find some channels, bots, or something. And making a half-hearted attempt to become an IRC Operator.
• Digging around in phpMyAdmin with the pilfered WordPress DB credentials.

That’s not to say these were all useless, or maybe not even dead-ends (I didn’t dig any deeper.) It’s just that there were much simpler methods available, right in front of me, as the VulnHub description said.

Thanks for this, Togie McDogie. I will keep it all in mind when I start the PWK labs in November.

Overall, though, this one was quite easy. It took way longer to write this blog post than it did to solve the VM. I’m feeling more ready for my OSCP journey with every passing day.