start > 2006-05-20 > 1

Computer Security: What is an exploit?

Created by pabrantes. Last edited by pabrantes, 2 years and 91 days ago. Viewed 1,308 times. #3

[diff] [history] [edit] [rdf]

labels

attachments

Computer Security: What is an exploit?

I've already spoken about exploits in some of my posts, but never took the time to actually explain what it is. I know that most of you that read this blog - not to say all - might already know what an exploit is. But I'm in the mood to write an educative post.

Exploit is a piece of software or a certain procedure that takes advantage (that's why it's called exploit) of a vulnerability in another piece of software in order to make the vulnerable software do something that wasn't design to do.

This actions can go from a Deny of Service, to gaining access to restrict services and/or information locally or even remotely.

There are different categories of exploits, each category consists in attacking certain kind of services or programs using different techniques. Here's a list of some of the most known exploits (also featuring some not so common):

Buffer Overflows
Cross Site Scripting (XSS)
Format Strings
SQL Injections
Race Condition

The ones present in bold are the ones I consider more common, although be aware that I'm doing such statement just using my common sense.

Let's get into a brief description in each one of them.

1. Buffer Overflow
As the name says you have a buffer and you have an overflow! This has probably been the most common exploit until XSS and SQL Injections started gaining a bigger "share". And for the people that still program in C language, this is definately the top security problem they might have to concern when writing code.

Anyway the idea of a buffer overflow exploit is to take advantage of non-protected buffers. By non-protected buffer you should understand buffers who store uncontrolled input and may write into the buffer inputs bigger than the buffers size, overlapping with the data of program loaded into memory. When overlapping such memory, the exploit deploys a certain special code that can be executed by the computer, normally called shellcode , or just pure garbage that will make the program crash.

Below you have a simple example of a C program that contains a vulnerability that allows a buffer overflow exploit to take advantage.

#include <stdio.h>

main(int argc, char **argv) { char buf[10]; if(argc!=2) { printf("Syntax: %s name", argv[0]); exit(-1); } strcpy(buf, argv[1]); /* If argv[1] is bigger than 10 chars it will overflow buf */ printf("Hello %s", buf); }

In this case it was a stack overflow, although there are other kind of overflows like heap overflow, integer overflow, etc.
To fix the previous example, you should replace the strcpyfunction by the strnpy function with length 10 (length of buf).

Preventing buffer overflows starts with validation practices when getting input from untrusted sources, which can be a user, another computer, a database, etc. Although there are other measures it can be taken, like for example, making the stack non-executable to render stack buffer overflows useless.

References about buffer overflows:

2. Cross Site Scripting (XSS)

Probably one of the most common vulnerabilities nowadays, although it's severity might not be as big as the one of buffer overflows it still can be used to do damage. There are 3 types of XSS attacks, the Type 0, Type 1 and Type 3. I'll not discuss them here, but you can find an excellent explanation of them at the wikipedia reference I give below.

If you have been reading my blog you probably already read about all the XSS problems I've been reporting about hi5.com. Mainly XSS consists once again in bad validation of data input that allows a malicious user to input code that will be executed in someone else's computer.

Sadly this is a very common vulnerability nowadays and even if sometimes it not represents a real issue other times it does.

Below you can find a vulnerable php script. The idea of the script it to receive from a POST a name and print it:

$name = $_POST['name'] echo $name;

If you pass as name a javascript, it will be executed. For further examples in XSS, you can read my post, Smashing hi5 for fun and profit. To fix the previous example, you would have escape the possible '<' and '>' from $name and just after that display it.

References about XSS exploits:

3. Format Strings

Format String is a not so common exploit and it's a particular vulnerability of the C language (which is not type-safe). The idea of the format string exploit is to take advantage of a simple bug, which is instead of having:

printf("%sn", userInputString);

having:

printf(userInputString);

userInputString is then seen has a format string and will be interpreted as one, so all the formaters present in the string will be interpreted.

References about Format Strings:

* Format Strings Attack (pdf)

4. SQL Injections

SQL Injection is another common vulnerability that has the objective of gaining access to the website backend database or just delete data from it. Once again the great problem is the lack of input validation. When present allows a malicious user to send extra commands to the SQL server.

Here's an example of a vulnerable php script that receives the username from a POST.

$username = $_POST['username'];

$query = "SELECT * FROM USERNAME WHERE USERNAME='" . username . '";

$result = mysql_query($query);

// Code to display result here ?>

If you would supply for username the following string:

' UNION SELECT * FROM USERNAME;

This would create two queries, one with quering for a blank username '' and another one that would dump all the username table, then would unite both tables and show the result on screen. To fix this injection problem, once again you would just have to escape the chars in the $username variable. By the way, you can use mysql_real_escape_string function for this purpose.

References about SQL Injections:

5. Race Conditions

This is not a so common vulnerability and it's caused by synchronization problems. It can be synchronization within the applications, such as problems that might arise from thread usage without correct sync, or synchronization between an application and the exterior environment, such as another application or even the operating system.

Here's the typical example of a race condition between application and Operating System calls:

#include <sdtio.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>

main(int argc, char **argv) {

char buf[1024]; int fd; if(argc!=2) { printf("Syntax: %s filename", argv[0]); exit(-1); } if (access(argv[1], R_OK) != 0) { exit(-1); }

fd = open(argv[1], O_RDONLY); while(read(fd,buf,1024)>0) { printf("%s", buf); } }

Imagine that the following program is owned by root and it's SUID.
Supposedly you can only read files with this program that you actually have permission to read, since it uses access function. Although that's not true! You can do the following:

Create a file that you have access
Start the program giving that file
Replace it by a symlink to the /etc/shadow file just after it did the access call and before it opens the file descriptor.

It needs to correct timing but you'll be able to exploit the program and get the content of shadow file.

References about race conditions:

Final notes

In most of the exploits presented there was a common factor, the lack of input validation was the origin of the vulnerabilities that they took advantage of. So next time you start programming, please remember that!

I hope you have found this article useful and even if you already knew what I've been explaining at least enjoyed the references I pointed. Any other type of exploit you want to discuss, or even something related to the ones presented, please just post.

Please login to www.pabrantes.net.