III. Exploitation on Code Injection
/* The following article is extracted from the "Information Security Newsletter" published by the JUCC IS Task Force. */
Code injection attacks typically occur when inputs has not been adequately validated before execution. The basic principle is to provide some form of input with additional malicious scripts for exploitation. There are numerous types of injection attacks which have different features and attributes. Major type of attacks included:
- SQL Injection
- LDAP Injection
- OS Command Injection (also known as Shell Injection)
- Cross-Site Scripting ("XSS")
1. SQL Injection
SQL injection attack consists of injection of malicious SQL commands via input data from the client to the application that are later passed to an instance of a database for execution and aim to affect the execution of predefined SQL commands.
The primary form of SQL injection consists of direct insertion of code into user-input variables which are concatenated with SQL commands and executed. A less direct attack injects malicious code into strings that are destined for storage in a table or as metadata. When the stored strings are subsequently concatenated into a dynamic SQL commands, the malicious code is then executed.
A successful SQL injection exploit can access sensitive data in the database, modify database data, execute administrative operations within the database (e.g. shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.
Examples for the SQL injection
Reference:
http://www.owasp.org/index.php/Interpreter_Injection
http://msdn.microsoft.com/en-us/library/ms161953.aspx
http://www.beyondsecurity.com/about-sql-injection.html
|
2. LDAP Injection Lightweight Directory Access Protocol (LDAP) is an open-standard protocol for both querying and manipulating X.500 directory services. The LDAP protocol runs over Internet transport protocols, such as TCP. Web applications may leverage user-supplied input to create custom LDAP statements for dynamic web page requests. LDAP injection is an attack technique of exploiting web applications that use client-supplied data in LDAP statements without first stripping potentially harmful characters from the request. When a web application fails to properly sanitise user-supplied input, it is possible for an attacker to alter the construction of an LDAP statement. Once an attacker is able to modify an LDAP statement, the process will run with the same permissions as the component that executed the command. (e.g. Database server, Web application server, Web server, etc.). This can cause serious security problems where the permissions grant the rights to query, modify or remove anything inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can also be similarly applied in LDAP Injection. Examples for the LDAP injection
|
|
Reference:
https://www.hackinthebox.org/misc/HITB-Ezine-Issue-001.pdf
http://cwe.mitre.org/data/definitions/89.html http://ebook.security-portal.cz/book/hacking_method/LDAP/LDAPinjection.pdf 3. OS Command Injection ("Shell Injection")
OS command injection is also known as Improper Sanitisation of Special Elements used in an OS Command and is a technique used via a web interface in order to execute OS commands on a web server.
The user supplies all or part of malformed OS command through a web interface. If the web interface that is not properly sanitised the input is vulnerable to this exploit. With the ability to execute OS commands, the user can inject unexpected and dangerous commands, upload malicious programs or even obtain passwords directly from the operating system. The problem is exacerbated if the compromised process fails to follow the principle of least privilege, because the attacker-controlled commands may run with special system privileges that increase the amount of damage.
Examples for the OS Command injection
 Reference:
http://cwe.mitre.org/data/definitions/78.html http://capec.mitre.org/data/definitions/88.html http://blogs.sans.org/appsecstreetfighter/2010/02/24/top-25-series-rank-9-os-command-injection/ 4. Cross-site Scripting ("XSS")
Cross-site Scripting ("XSS") is a type of injection attack, in which malicious scripts are introduced into the trusted websites. This exploitation would occur when a web application uses user-supplied inputs as an output without validating or encoding it. The malicious content sent to the web browser can takes several forms including JavaScript, VBScript, ActiveX, HTML, Flash or any other type of code that the browser may execute. XSS attacks can generally be categorised into three types: Stored, Reflected and Document Object Mode based ("DOM-Based").
Stored XSS (Persistent) - Stored XSS attacks means that the injected malicious code is permanently stored on a target server such as a bulletin board, a visitor log, or a comment field. When interacting with the target server, an end-user inadvertently retrieves and executes the malicious code from the server. 
 Reference:
http://projects.webappsec.org/Cross-Site+Scripting http://www.owasp.org/index.php/Cross-site_Scripting_(XSS) http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/XSS-Injection DOM (Document Object Model) Based XSS - Unlike the previous two, DOM based XSS does not require the web server to receive the malicious XSS payload. Instead, in a DOM-based XSS, the attack payload is embedded in the DOM object in the victim's browser used by the original client side script, so that the client side code runs in an "unexpected" manner. That is, the page itself (HTTP response) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the local DOM environment. This attack is usually achieved by sending malicious URL to the users.
The above techniques may allow an attacker to hijack private data like cookies or other session information, redirect the victim to web content controlled by the attacker, or perform other malicious operations on the user's machine under the banner of the vulnerable site.
|
