1 Computer Security: What is an exploit? {anchor: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 {link: Deny of Service|url=http://en.wikipedia.org/wiki/Denial-of-service_attack|newWindow=true}, 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): 1. __Buffer Overflows__ 1. __Cross Site Scripting__ (XSS) 1. Format Strings 1. __SQL Injections__ 1. 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 {link: shellcode |url=http://en.wikipedia.org/wiki/Shellcode|newWinndow=true}, 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. {code:C} #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); } {code} 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 ~~strcpy~~function 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: * {link: Smashing the stack for fun and profit|url=http://www.phrack.org/phrack/60/p60-0x06.txt|newWindow=true} * {link: How to write buffer overflows|url=http://www.insecure.org/stf/mudge_buffer_overflow_tutorial.html|newWindow=true} * {link: w00w00 on Heap overflows|url=http://www.w00w00.org/files/articles/heaptut.txt|newWindow=true} 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: {code} <? $name = $_POST['name'] echo $name; ?> {code} If you pass as name a javascript, it will be executed. For further examples in XSS, you can read my post, {link: Smashing hi5 for fun and profit|url=http://www.pabrantes.net/blog/space/start/2006-05-01/1}. To fix the previous example, you would have escape the possible '<' and '>' from $name and just after that display it. References about XSS exploits: * {link: Cross Site Scripting explained in Wikipedia|url=http://en.wikipedia.org/wiki/XSS|newWindow=true} * {link: XSS cheat sheet: for filter evasion |url=http://ha.ckers.org/xss.html|newWindow=true} 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: {quote} printf("%s\n", userInputString); {quote} having: {quote} printf(userInputString); {quote} ~~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: *{link: Format Strings Attack|url=http://www.lava.net/~newsham/format-string-attacks.pdf|newWindow=true} (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. {code} <? $username = $_POST['username']; $query = "SELECT * FROM USERNAME WHERE USERNAME='" . username . '"; $result = mysql_query($query); // Code to display result here ?> {code} If you would supply for username the following string: {quote} ' UNION SELECT * FROM USERNAME; {quote} 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: * {link: SQL Injections Attacks by example|url=http://www.unixwiz.net/techtips/sql-injection.html|newWindow=true} * {link: SQL Injection|url=http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf|newWindow=true} (pdf) 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: {code} #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); } } {code} 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: 1. Create a file that you have access 1. Start the program giving that file 1. 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: * {link: Fixing Races for Fun and Profit: How to abuse atime|url=http://www.cs.berkeley.edu/~nks/papers/races-usenix05.pdf|newWindow=true} * {link:Secure programmer: Prevent race conditions |url=http://www-128.ibm.com/developerworks/library-combined/l-sprace.html|newWindow=true} __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. 2006-05-21 14:46:29.472 2006-05-20 23:39:26.794