Skynet
Skynet
Room link: https://tryhackme.com/room/skynet
Scanning
I started with an aggressive NMAP scan using the -A option.
ajread@aj-ubuntu:~/TryHackMe$ nmap -A [REDACTED]
Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-21 20:40 EST
Nmap scan report for [REDACTED]
Host is up (0.091s latency).
Not shown: 994 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 99:23:31:bb:b1:e9:43:b7:56:94:4c:b9:e8:21:46:c5 (RSA)
| 256 57:c0:75:02:71:2d:19:31:83:db:e4:fe:67:96:68:cf (ECDSA)
|_ 256 46:fa:4e:fc:10:a5:4f:57:57:d0:6d:54:f6:c3:4d:fe (ED25519)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Skynet
110/tcp open pop3 Dovecot pop3d
|_pop3-capabilities: TOP SASL CAPA AUTH-RESP-CODE PIPELINING UIDL RESP-CODES
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
143/tcp open imap Dovecot imapd
|_imap-capabilities: more LOGINDISABLEDA0001 have post-login IMAP4rev1 listed LOGIN-REFERRALS IDLE capabilities ID LITERAL+ Pre-login ENABLE SASL-IR OK
445/tcp open netbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)
Service Info: Host: SKYNET; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
|_clock-skew: mean: 2h00m00s, deviation: 3h27m51s, median: 0s
|_nbstat: NetBIOS name: SKYNET, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| smb-os-discovery:
| OS: Windows 6.1 (Samba 4.3.11-Ubuntu)
| Computer name: skynet
| NetBIOS computer name: SKYNET\x00
| Domain name: \x00
| FQDN: skynet
|_ System time: 2022-02-21T19:41:08-06: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: 2022-02-22T01:41:08
|_ start_date: N/A
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.19 secondsA full nmap scan with -p- also returned the same results.
It looked like the machine had some e-mail capabilities based on the pop and imap. It also appeared to be hosting some form of SMB share.
Enumeration
I checked out the http service and I found some interesting directories.
The /squirrelmail directory is most likely related to the pop3 and imap services I saw in my nmap scans. I first went after the SMB portion of the machine. I used smbmap to scan for available shares.
It looked like there is a user name milesdyson on the system. I kept that usernanme in mind. I looked at the anonymous share since it had READ ONLY access.
There was an attention.txt file and a folder of logs.
Looking at the log files, only log1.txt has data, which appeared to be passwords to use for cracking credentials. I will definitely keep these in mind. Could they be used for milesdyson user?
Remembering the enumeration I did with gobuster, I went back to the /squirrelmail directory. What if the log1.txt was a list of passwords to try as user milesdyson? The attention.txt file affirmed my suspicion.
So, I set up burpsuite intruder to use multiple payloads against the secretkey= position of the POST request to the squirrelmail service. See the POST request to log in below.
I loaded in log1.txt as the payload in intruder and ran burpsuite. There were a total of 31 possible passwords in the log1.txt file. Burpsuite took some time to run against the target but I eventually found the password based on a 302 response from the service. With the password, I logged into the mail service as user milesdyson.
There were total of 3 emails within the user milesdyons' inbox. Two of them are from serenakogan. One of the emails from her is in binary. The other appears to be song lyrics. The final email in milesdyson's inbox was from skynet@skynet and it provided smb credentials to use.
I used the credentials to log into the milesdyson share that I saw earlier using smbmap.
There were a bunch of files within the share. But, the most interesting file was the important.txt file within the notes directory.
The important.txt file pointed to a CMS on the system.
I used curl to initially investigate the CMS.
It didnt look like anything special was on the first page of the supposed CMS. I ran gobuster against the site and found some more interesting directories to investigate.
When I navigated to the /administrator page, I was presented with a login screen for Cuppa CMS. I did some googling to find that there is a remote/local file inclusion vulnerability with Cuppa CMS (https://www.exploit-db.com/exploits/25971) that I could use.
Initial Access
With the LFI/RFI vulnerability, I set up a php reverse shell using pentest monkey (https://pentestmonkey.net/tools/web-shells/php-reverse-shell), changing the IP and port as needed. Then, I started a python http server on my local machine in the directory where the reverse shell was stored.
I made sure to set up a netcat listener on my local machine.
Then, I navigated to the LFI/RFI vulnerable location for the CMS and input the location of my local machine, which executed the reverse shell.
And, it worked!
I could also see the machine call out to my local machine via the http server.
Then, I was able to find the user flag.
Privilege Escalation
Within the home directory of milesdyson, there was an interesting backup file that is executed by root.
Based on file permissions, I couldnt simply change the shell script to elevate privilege.
It looked like the shell script moved to the location of the website and compressed everything, using tar, as a method of backup. I found this website that explained an exploit for tar using checkpoints (https://swepstopia.com/wildcards-tar-and-checkpoints/). Checkpoints were originally created so that tar could conduct specific actions during its process if, for example, it is archiving a massive file/directory. According to the site, I could set up a checkpoint within tar that would be a reverse shell to my local machine.
Following the site, I first needed to create a shell script and place it in the location where the tar/backup takes place. The shell script needed to call back to my local machine at a specific port.
Then, I had to set up a checkpoint action for tar that would execute the shell script.
I set up a netcat listener to catch the reverse shell on my local machine.
Finally, I executed the checkpoint, which called the shell script.
My netcat listener picked up the call and I dropped into a shell with root privileges.
Last updated