Injecting Code
The topic of code injection is a huge one, encompassing dozens of different languages and environments, and a wide variety of different attacks. It would be possible to write an entire book on any one of these areas, exploring all of the theoretical subtleties of how vulnerabilities can arise and be exploited. Because this is a practical handbook, we will focus fairly ruthlessly on the knowledge and techniques that you will need in order to exploit the code injection flaws that exist in real-world applications.
SQL injection is the elder statesman of code injection attacks, being still one of the more prevalent vulnerabilities in the wild, and frequently one of the most devastating. It is also a highly fertile area of current research, and we will explore in detail all of the latest attack techniques, including filter bypasses, inference-based attacks, and fully blind exploitation.
We will also examine a host of other common code injection vulnerabilities, including injection into web scripting languages, SOAP, XPath, email, LDAP, and the server operating system. In each case, we will describe the practical steps that you can take to identify and exploit these defects. There is a conceptual synergy in the process of understanding each new type of injection. Having grasped the essentials of exploiting these half-dozen manifestations of the flaw, you should be confident that you can draw on this understanding when you encounter a new category of injection, and indeed devise additional means of attacking those that others have already studied.
Injecting into Interpreted Languages
An interpreted language is one whose execution involves a runtime component that interprets the code of the language and carries out the instructions that it contains. In contrast to this, a compiled language is one whose code is converted into machine instructions at the time of generation; at runtime, these instructions are then executed directly by the processor of the computer that is running it.
In principle, any language can be implemented using either an interpreter or a compiler, and the distinction is not an inherent property of the language itself. Nevertheless, most languages are normally implemented in only one of these two ways, and many of the core languages used in the development of web applications are implemented using an interpreter, including SQL, LDAP, Perl, and PHP.
Because of the way that interpreted languages are executed, there arises a family of vulnerabilities known as code injection. In any useful application, user-supplied data will be received, manipulated, and acted upon. The code that is processed by the interpreter will, therefore, comprise a mix of the instructions written by the programmer and the data supplied by the user. In some situations, an attacker can supply crafted input that breaks out of the data context, usually by supplying some syntax that has a special significance within the grammar of the interpreted language being used. The result is that part of this input gets interpreted as program instructions, which are executed
in the same way as if they had been written by the original programmer. Often, therefore, a successful attack will fully compromise the component of the application that is being targeted.
In compiled languages, on the other hand, attacks designed to execute arbitrary commands are usually very different. The method for injecting code does not normally leverage any syntactic feature of the language used to develop the target program, and the injected payload normally contains machine code rather than instructions written in that language.
Consider the following very simple example. Helloworld is a shell script that prints out a message supplied by the user:
#!/bin/bash
echo $1
When used in the way the programmer intended, this script simply takes the input supplied by the user and passes this to the echo command, for example:
[manicsprout@localhost ~]$ ./helloworld.sh “hello there”
hello there
However, the shell scripting environment in which Helloworld is interpreted supports the use of backticks to insert the output of a different command within an item of data. Hence, an attacker can inject arbitrary script commands, and retrieve their output, as follows:
[manicsprout@localhost ~]$ ./helloworld.sh “`ls -la`”
total 28 drwxr-xr-x 2 manicsprout manicsprout 4096 Dec 4 00:22 .
drwxr-xr-x 3 root root 4096 Dec 4 00:19 .. -rw-r–r– 1 manicsprout
manicsprout 24 Dec 4 00:19 .bash_logout -rw-r–r– 1 manicsprout
manicsprout 191 Dec 4 00:19 .bash_profile -rw-r–r– 1 manicsprout
manicsprout 124 Dec 4 00:19 .bashrc -rw——- 1 manicsprout manicsprout
706 Dec 4 00:22 .viminfo -rw-rw-r– 1 manicsprout manicsprout 8 Dec 4
00:22 helloworld.sh
Although this example is somewhat trivial, if the vulnerable script were executing as root, an attacker could leverage it to escalate privileges and execute commands in the context of the root user. As you will see, this exact vulnerability is still often found in web applications that interface with the operating system command shell.
NEXT is..Injecting into SQL……..,.,.,.,.,.,.,.
