Linux Buffer-Overflow feat. Crossfire v1.9.0
So, today we will going to explore more about buffer overflows, this time, in 32-bit linux running Crossfire v 1.9.0 with a publicly disclosed exploit.
Let’s start off by downloading crossfire from offsec. This version has disabled memory protections.
Once we downloaded crossfire, ran it and should look like the screenshot below.
We can now attach our debugger on our application. For this hack we will going to use Evan’s Debugger or edb — https://github.com/eteran/edb-debugger/wiki/Compiling-(Debian), it has GUI that has familiar feels like the Immunity Debugger we used on Windows.
So now, since ran this on a separate VM in an isolated sub-net, let’s try to figure out the IP of our target machine by running arp-scan.
Once we got our target IP we can ran nmap against it. We can skip this part totally since we have a complete control on our target machine. However, just to simulate the attack, we can show how we can scan the IP and available ports.
Now that we have the ports available, we can now ran a more detailed scan against it.
We can see that our target machine is running Crossfire v1.9.0. Searching for available exploit, we can see that we have 1 exploit available on searchsploit, however, we will going to use a simplified version we can find on google.
Further googling the buffer overflow “Crossfire v1.9.0 buffer oveflow” we have found a script below.
We have found an exploit online, This exploit will send a 4379 bytes that starts with “setup sound “ characters, perhaps this will let the application know that someone is trying to set-up their sound on their game? (let me know). Let’s work upon on this so we can use this to gain access and totally take control of the VM machine.
First le’ts run initial script…
As we can see on screenshot below, we have flooded the EIP with 4 As (0x41414141), the next step is finding the offset so we can totally control the EIP.
In order to do that we generate unique pattern using metasploit pattern create, we specify the length -l to be 4379. We then need to copy these patterns and put it on our script.
Our script should be look something like this.
Let’s run the script again…
And we got an error which we totally expect, let’s copy the EIP register’s hex value and locate it on our generated pattern using metasploit’s pattern offset, we need to specify the length -l 4379 bytes and let’s query -q the unique pattern we got from EIP (46367046)
Let’s tweak the script again, and let’s put some Bs (0x42424242) on EIP, then 7 Cs (43) on ESP, we can easily identify the separation of each registers which is crucial on buffer overflows.
Our overflow should have the ff.
‘A’ * 4368
‘B’ * 4 and
‘C’ * 7
Let’s run it again and we should have something like the screenshot below.
Now, we need to check if we can extend the ESP Buffer, if we can, then that’s great, we can easy put our payload on ESP, then put a ‘JMP ESP’ command on our EIP which by now, we have total control.
On the screenshot below, we tried to add just 1 byte on the ESP register, so then, it becomes 8. We can now try to run this.
We have lost control of EIP, we are expecting 4 Bs on EIP, instead we got some random hexa bytes.
The EIP register has 0x004cb5e7 instead of 0x42424242 (“BBBB”) which means that we have a limited or definite space to work with.
Buffer = 4368 bytes
EIP = 4 bytes
Offset = 7 bytes
Let’s bring back the ESP overflow to 7 Cs, and run it again. We then analyze and look where we can land our payload since we can’t put a 7-byte payload on ESP.
As we can see, the EAX register receives our overflow, however, our overflow should start with “setup sound “ characters to be accepted by our target machine.
Following in Dump…
We can see that we need to overcome the first 12 bytes on EAX so the application will execute our payload. In order to do that, we can try make our ESP points to EAX with a longer length (12 bytes) then jump right into our payload to execute in.
Let’s create an EAX with 12 bytes in size then jump into it.
We use the metasploit nasm shell to create the needed assembly codes.
We then put this on our ESP variable on our script, this is after we took control of EIP, so we expect that we should see these hex bytes inside our ESP register.
Running the script again, we can we that we have 4 Bs on EIP meaning that we didn’t break the code, then let’s dump the ESP register.
Analyzing the ESP dump, we can see that is has the hex bytes that we want to have it. Meaning, it will add 12 bytes into EAX then JMP into it to execute our payload.
Now, all we need to do is to make the EIP jump to ESP. EDB Dubugger has a plugin tool that will help us find a JMP ESP command in memory.
Plugins > Opcode Searcher > Opcode Search
We choose the crossfire and ESP > EIP on the jump equivalent. We put this on our code and don’t forget the “little endian” formatting.
Our code should look something like this by now.
Let’s add a breakpoint to check if our JMP ESP is hit. Plugins > Breakpoint Manager and add the memory address.
Error Encountered:
Although we are hitting the JMP ESP register, I encountered an error that say memory could not be accessed. So, basically we cannot execute the add edx and jmp edx command we injected in ESP register.
This error brings me to a lot of reading and searching. I tried alot of things that made me exhausted, I tried to use all the JMP ESP memory found but was getting the same result.
I also tried to download different types of application, one that we can install, however I am getting same result.
This brings me to a github repo where you can check the memory protection of a binary.
Afte more googling… I figured out that my target machine has NX (noexec) enabled, this prevents us from accessing and executing of memory registers like ESP and EAX…
So in order to overcome that, we need to define a command like “noexec=off” on OS, we can do it by declaring it on OS boot up.
- Choose the OS and hit ctrl+e.
- On the cmdline, put the noexec=off command.
- ctrl+x and continue with boot.
Checking the application, it still has NX enabled since it was compiled with that parameter???
However, we got a different error now, that says, debugger can’t find the memory registry map. It is a good error for us…
Now, instead of 7 Cs, in ESP, we put back the JMP EAX command on it and execute.
Our code should look something like this by now.,,
Then running our script again, we got an error that says 4 A’s doesn’t appear to be mapped, meaning that EAX is trying to execute our A overflows.
This only means that from EIP (JMP ESP) > ESP (ESP adds 12 eax bytes and jmp into it) > EAX.
We can now put our payload like reverse shell into the beginning of As, but le’ts check for the bad characters first.
Checking for BAD Characters..
We but the complete hex characters into our script, we will then run it and analyze where EAX acted up. We then remove it from our code, and execute our code again. We will do this over and over again until we got all the bad characters.
Here we are expecting ‘20’ after ‘1f’, however, it acted up on 20, meaning that ‘20’ is a bad character.
Removing that ‘\x20’ byte from our script and running it again, made the EAX execute all our HEX characters.
Therefore, bad chars are “\x00\x20”
We then generate our payload using msfvenom. We use reverse shell as our payload.
We then put this on our script together with NOP bytes around 8 for good measure.
So our payload should be
NOP = 8 bytes
payload = 425 bytes
A overflows = 4368 -425 -8
EIP = 4 bytes
ESP = 7 bytes
Unfortunately, for some reason my payload is not working against my target machine, and I was too exhausted to troubleshoot it furthermore, google dorking led me to this site, I used the code against my target machine. My final exploit looked like this.
Running the code, shows an interesting behavior on our target.
It has accepted our payload, so let’s try to connect to our target using netcat.
AND WE GOT ROOT!
Takeaways:
Working with a limited buffer space is more challenging, and requires initial knowledge about registers and buffer overflows, however, it was more fun because you’ll not blindly putting up payload, you’ll consider the space you’re working on.
OSes and binaries have their own memory protection against buffer overflows, it would be better if you check those first before diving into exploitation. Watch out for protections like ASLR, NX or canaries.
Basically, once you’ve managed to control EIP, is only the start of your hack, you need to carefully check ESP if ‘extend-able’, check other memory register if you could be able to land your payload, watch out for memory’s math (adding, subtracting bytes).
Learn about assembly language, it will help alot about memory manipulation.
NOTE :
Since my payload didn’t work, I’ll troubleshoot it on my free time and will update this thread. I was really exhausted on this hack, I spend about 3 days (all in weekends and holiday), figuring out what went wrong. Please let me know what did I miss or something I can do to make my reverse shell payload work.
And my test machine and attack machine (Kali by Offsec) acted up again, my Kali hangs whenever I am opening text editor. Probably, will go to kali released by kali and will ditch the offsec version.
Active Directory Attacks, here we go..
