Buffer Overflow Exploitation [Theory]



I figure the best place to start with this series is to explain what a buffer overflow it is and how it can lead to someone compromising your system. This is just theory, as is all of this section of the series, there is a second half to this called [Practical] but because of time restraints I may be ahead on the theory but be a little bit behind on the practical.

So lets start.What is a buffer? Well a buffer is a section of memory that can be allocated either through programming or automatically. If poor programming practices have been used there may be a way for us to go beyond that set buffer and access other memory. Once in the other memory we can write our data to it in many ways, but this will be discussed later on. Basically when we overflow the buffer we have the ability to insert our own commands and using a thing called ShellCode we can establish a connection between us and the client.


Where do buffer overflows exist? This depends on whether our attack is remote or local. Generally a buffer is set wherever user input is taken, this is where most exploits lay. So lets take a remote attack as an example, to be remote simply means that this is an application that uses the Internet in someway allowing us to connect to it and attack remotely. An example of this is Kolibri Web Server, this web server sets a buffer for the HEAD section of the HTTP Request, so we have to craft our exploit into a HTTP Header and send it over port 80. This attack will overflow the buffer and create a connection (shell) to that machine. This specific attack uses SEH Exploitation which we will cover soon.

If it is local attack the user generally has to open a file that will have the payload inside it. For instance the software AutoPlay allows users to easily create the ‘autoplay.ini’ file that is present on a lot of CD and USB devices. The vulnerability exists in opening an ‘autoplay.ini’ file that has added information (ShellCode) allowing the user to spawn a shell. Why would this be used (I am thinking this myself) I can only imagine that this kind of attack could be used on a system that is on lock down. If you have gained access to a workstation on your clients network and their OS is locked down so no shell allowed, if the user has access to this program we could still spawn a shell on that computer through this method. Another reason could be to gain access remotely by using this technique in combination with social engineering and of course local exploits are great for privilage escalation. Take the recent Adobe Reader exploits, a user could craft a special PDF file and trick someone into downloading it, when they open it they see their normal PDF content but unbeknown to them a shell has been spawned on their machine.

You are likely to see the term ‘PoC’ quite a bit when we start researching other peoples exploits, this means Proof Of Concept. Basically the user will craft the exploit that works but instead of including ShellCode to spawn a shell they will simply perform a execution task such as start ‘calc.exe’ (Windows Calculator). This is generally used to deter script kiddies from just launching the exploit without understanding it. A lot of the time people who code Buffer Overflows will also put the wrong offset in so the attack will not work without some modification by the user, testing the knowledge and again deterring script kiddies. Sometimes a Proof of Concept can also simply be a file that successfully crashes the application, the rest of the work is normally left up to someone else to create.

A buffer overflow exploit can be coded in pretty much any language but I started in Python. And I find this easier than any other language (for me), I do not have really much programming experience but I do not feel it drastically important, you should still be able to follow along. It is essential to understand the basic concepts of programming though i.e. Variables, take user input, sockets, libraries… This will all be explained in dumbed down terms in the Python section of the series.

Good websites to look at Buffer Overflow code.

http://www.exploit-db.com – Awesome resource, I believe owned by the extremely skilled hacker Muts.

http://nvd.nist.gov/ – Another great resource, one of the best ways to learn is to look at other code.

http://osvdb.org/

So I hope you now know what Buffer Overflows and what some of the results can be of the attack. We will learn a lot more when we progress into the actual attacks, but it is essential to have a firm understanding in basic concepts.

No comments:

Post a Comment