The emergence of Web applications has brought in lot of evolutions in the field of business. An increase in the usage of web applications is directly related to an increase in the number of security attacks invited by them.
To list a few attacks that grabbed the attention are:
- In 2006, K2 Networks Inc, an operator of Asian games for US market claims to have lost over USD 1 million in a single year due to account compromises. The attacks that were sited were SQL Injection attacks.
- “PetCo plugs credit card leak” – Around 5 lakh credit card numbers were open to hackers with the help of SQL injection attack
This article focuses on some of the Command Execution attacks that invade a web application. It also describes about the ways to detect these attacks and methodologies to validate the security of those web applications. It also touches upon some of the free-wares that are available to detect these threats.
Command Execution Attacks
The Command Execution section covers attacks designed to execute remote commands on the web site. All web sites utilize user-supplied input to fulfill requests. Often these user-supplied data are used to create construct commands resulting in dynamic web page content. If this process is done insecurely, an attacker could alter command execution.
Some of the attacks are as follows:-
- Buffer Overflow Attack - Buffer Overflow exploits are attacks that alter the flow of an application by overwriting parts of memory.
- Format String Attack Format String Attacks alter the flow of an application by using formatting library features to access other memory space.
- LDAP Injection - LDAP Injection is an attack technique used to exploit web sites that construct LDAP statements from user-supplied input.
- OS Commanding - OS Commanding is an attack technique used to exploit web sites by executing Operating System commands through manipulation of application input.
- SQL Injection - SQL Injection is an attack technique used to exploit web sites that construct SQL statements from user-supplied input.
- SSI Injection - SSI Injection (Server-side Include) is a server-side exploit technique that allows an attacker to send code into a web application, which will later be executed locally by the web server.
- XPATH Injection - XPATH Injection is an attack technique used to exploit web sites that construct XPATH queries from user-supplied input.
The term Buffer Overflow means “generating/providing excess of data than what a buffer or variable can hold”. Since the variable size is defined and hence cannot hold more than the defined size, the excess data will be written in the next data storage area. This will in turn corrupt this storage area also.
Hackers make use of this and inject their code in the form of extra data which gets stored in the storage area. This extra data can get executed and may cause adverse effects. Some of these are Denial of Service, disclosure of confidential information and change to any personal data.
The Buffer Overflow attacks are the common ones in the web based applications. Testing for these attacks is very tricky unless the code is gone through by the tester line by line and looking for data overflow in the code. There are some free-wares available that can be used for testing buffer overflow.
One such tool is called “NTOMax”. This tool will take a text file as input and will try to catch the places where Buffer Overflow could occur. The input file should contain the host name, port, minimum buffer size and maximum limit.
Since Web applications read all types of inputs, there is a high possibility that Buffer Overflow can occur at any point when the web based applications interact and use services and dlls from other non-safe languages like C/C++.
Mitigation methods include using safe string libraries and container abstractions. The safe string functions take the size of the destination buffer as an input parameter, to ensure that the function does not write past the end of the buffer. These functions also null-terminate all output strings, to avoid problems caused by a missing null terminator.
The best way to prevent buffer overflow problems is to validate the input data before using it in the application.
There are two types of Buffer overflow: Stack based and heap based.
2. SQL Injection
This type of hacking uses SQL commands and injects these commands to retrieve the data from application. Other effects of SQL injection attacks include Add/Modify and Delete records/tables from the application.
Hackers use input that would generate invalid SQL query to hack data from the web application. There are two types of SQL injection: (1) Normal SQL injection and (2) Blind SQL Injection.
In Normal SQL Injection attacks, the hacker tries to write an invalid SQL query. On executing this invalid query, the database returns some error messages. Using these error messages, the hacker will be able to understand and determine the database structure and the fields in the tables. By repeating this method, the hacker will get more familiarized with the entire structure of the database.
In Blind SQL Injection attacks, the error messages that get generated due to invalid SQL queries are suppressed by the developers. Hence, the hackers use trial and error methods to construct a valid SQL query in order to retrieve information about the database.
Checking for SQL Injection in the web based applications can be done in the following ways:
- Analyzing the present state of security present by performing a thorough audit of your website and web applications for SQL Injection and other hacking vulnerabilities.
- Making sure that you use coding best practice sanitizing your web applications and all other components of your IT infrastructure.
- Regularly performing a web security audit after each change and addition to your web components.
An automated web vulnerability scanner scans the entire web site and checks the areas that are prone to attacks. By scanning, it will find the URLs that can be attacked by SQL Injection. One such scanner that is available as a free-ware for limited trial period is Acunetix Web Vulnerability Scanner. Provides you with an immediate and comprehensive website security audit
- Ensures your website is secure against web attacks
- Checks for SQL injection, Cross site scripting and other vulnerabilities
- Audits shopping carts, forms, and dynamic content
- Scans all your website and web applications including JavaScript / AJAX applications for security vulnerabilities.
3. XPATH Injection
Any web application that uses XML to store and retrieve data are prone to attacks by XPATH Injection .Data is stored in XML in a node tree structure. XPATH language is used for retrieving information from the nodes of an XML document. When an application has to retrieve data from the XML document based on user input, it sends an XPATH query which gets executed on the server. Some sample XPATH queries are as follows
| / | Selects the root node of the tree |
| /users | Selects all "users" child elements of the root node |
| /users/user[@admin= ‘true’ | Selects all user child elements whose “admin” attribute has the value “true” |
| /* | Selects all elements of the root |
The key to executing a Blind XPATH Injection attack is the ability to “ask” the server a series of true or false “questions” to know the about the data structure and query according to our requirements.
AJAX applications are especially vulnerable because XML fragments are sent to the client for processing. When XPATH query result fragments are processed directly on the client, attacks can be perpetrated with a script-kiddie level of simplicity. The XPATH Single Query Attack method allows an attacker to extract the backend document with a single request to the server. Single Query Attack can run quickly and are much harder to detect as an attack. And unlike blind forms of injection attacks, they are not tedious to perform. There are three properties of XPATH that make attacks against AJAX applications extremely effective: simple joins, error resilience, and easy top level document access.
The best method for preventing XPATH injection vulnerability is by properly validating user input for both type and format. All client-supplied data needs to be cleansed of any characters or strings that could possibly be used maliciously. The best method of doing this is via “white listing”. This is defined as only accepting specific data for specific fields, such as limiting user input to account numbers or account types for those relevant fields, or only accepting integers or letters of the English alphabet for others. Many developers will try to validate input by “black listing” characters, or “escaping” them. Basically, this entails rejecting known bad data, such as a single quotation mark, by placing an “escape” character in front of it so that the item that follows will be treated as a literal value. Stripping quotes or putting backslashes in front of them is not enough, and is not as effective as white listing because it is impossible to know all forms of bad data ahead of time.
A good method of filtering data is by using a default-deny regular expression.
Make it so that you include only the type of characters that you want. For instance, the following regular expression will return only letters and numbers: s/ [^0-9a-zA-Z]//\
Make your filter narrow and specific. Whenever possible, use only numbers. After that, numbers and letters only. If you need to include symbols or punctuation of any kind, make absolutely sure to convert them to HTML substitutes, such as "e; or & gt. For instance, if the user is submitting an e-mail address, allow only the “at” sign, underscore, period, and hyphen in addition to numbers and letters, and allow them only after those characters have been converted to their HTML substitutes.
Some of the freeware tools available to detect XPATH injection are as follows
Paras from SourceForge and WS Digger from Foundstone (McAfee).
Paras
Paras is a Java based HTTP/HTTPS proxy for assessing web application vulnerability. It supports editing/viewing HTTP messages on-the-fly. Other features include spiders, client certificate, and proxy-chaining, intelligent scanning for XSS and SQL injections etc. It is platform independent only requires JRE 1.4. The following are the functions of Paras tool.
Spider
Spider is used to crawl the websites and gather as many URL links as possible. This allows you to have a better understanding of the web site hierarchy tree in a short time before manual navigation. It supports cookie and proxy chaining, which is set at the
field in Option tab. Automatically add URL links to the web site hierarchy tree for later scanning.
Scanner
The scanner function is to scan the server based on the website hierarchy. It can check if there is any server mis configuration. Automatic web scanner may not be able to find out the paths and check if there exist any backup files (.bak) which could expose server information. In order to use this function, you need to navigate the website first. After you logon a website and navigate it, a website hierarchy tree will be built by Paros automatically. Then you can do the following things:
a) If you want to scan all websites on the tree, you can then click on the menu item "Tree" =>"Scan All" to trigger the scanning.
b) If you just want to scan one website on the tree, you can click on that site in the tree panel and click menu item "Tree" => "Scan selected Node" (You can also right click on the tree view and choose the options).
Paras include the following checks:
- HTTP PUT allowed − check if the PUT option is enabled at server directories
- Directory index table − check if the server directories can be browsed.
- Obsolete files existed − check if there exist obsolete files at
- Cross−site scripting − check if Cross−site scripting (XSS) is allowed on the query parameters
Note that all the above checks are based on the URLs in the website hierarchy. That means the scanner will check each URL for each vulnerability. Compared with other web scanners which just do a blink scan without website hierarchy, our scanning result is more accurate.
Filter
The use of filters is to detect and alert you the occurrence of certain predefined patterns in HTTP message. If you use filters you do not need to trap every HTTP message and seek for the pattern. You can also use filters to log information in which you are interested. Paros has the following filters:
a) LogCookie
b) LogGetQuery,
c) LogPostQuery,
d) CookieDetectFilter,
e) IfModifiedSinceFilter•
WS Digger Tool
The WS Digger tool from McAfee is more helpful in testing as it has very good features as follows:
- Built in sample attack plug-ins: SQL injection, cross site scripting, XPATH injection.
- Automated web services discovery: The tool analyzes public and or private UDDI to discover web services related to search strings.
- Automated attack vector discovery: It analyzes the web service to determine potential points of attack.
- Automated and manual exploit testing: It can be used to manually inject malicious data and generate test cases which can be automatically executed through the attack plug-ins.
- HTML reporting: It also reports of the results and test case history for further analysis.
Format String Vulnerability got familiarized only early 90’s. Format string Injection vulnerability could take advantage of the format string function to hack the system.
Format string Vulnerability occurs when a user supplied data are used directly as formatting string input for functions. Format string attacks alter the flow of an application by using string formatting library features to access memory space.
Consider a programmer who wants to print out a string or copy it to some buffer. What he means to write is something like:
Printf ("%s", str); but instead he decides that he can save time, effort and 6 bytes of source code by typing: printf (str);
The first argument to printf is a string to be printed. Instead, the string is interpreted by the printf function as a format string. It is scanned for special format characters such as "%d". As formats are encountered, a variable number of argument values are retrieved from the stack. At the least, it should be obvious that an attacker can peek into the memory of the program by printing out these values stored on the stack.
The possible use of Format string attacks are Read data from the stack, Read character strings from the Process’s memory, Write an integer to locations in the process’s memory.
Format string attacks falls in to three categories,
- Denial of Service
- Reading
- Writing
Reading : - Format String Vulnerability reading attacks attempts to read from memory that we do not normally have access to. This technique uses %x format specifies to print sections of memory.
Writing : - Format string Vulnerability writing attacks utilize the %d %u or %x format specifies to overwrite the instruction pointer and force the execution of user supplied shell code. By using %n conversion character, an attacker may write an integer value to any location in memory.
The key to testing format string vulnerabilities is supplying format type specifiers in application input.
For example: - Consider an application that processes a URL string or accepts inputs from form, http://abcd.com/html/en/index.htm, if format string vulnerability exists in one of the routines processing this information, supplying a URL like http://xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of the form fields might crash the application creating a core dump in the hosting folder.
Format string vulnerabilities is more common in web servers, application servers or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases an error reporting or logging function like syslog ( ) has been called insecurely.
When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. For example a legitimate request like http://hostname/cgi-bin/query.cgi?name=allen&code=45000 can be altered
http://hostname/cgi-bin/query.cgi?name=allen%x.%x.%x&code=45000%x.%x, if a format string vulnerability exists in the routine processing this request, the tester will be able to see stack data being printed out to browser.
There are several tools available to validate Format String Vulnerability in source code. In the case of manual testing, reviews should include more priority to several formatting functions that are specific to the development platform and those functions should be validated for absence of format strings.
ITS4 a tool for statically scanning security critical c and c++ source code for vulnerabilities. ITS4 tool along with source code is available from
http://www.rstcorp.com/its4/.
Conclusion
Apart from the Command Execution attacks discussed, Client Side Attacks also challenge the security of web based applications.
The Client-side Attacks focuses on the abuse or exploitation of a web site’s users. When a user visits a web site, trust is established between the two parties both technologically and psychologically. A user expects web sites they visit to deliver valid content. A user also expects the web site not to attack them during their stay. By leveraging these trust relationship expectations, an attacker may employ several techniques to exploit the user.
In Content Spoofing, technique used is to trick a user into believing that certain content appearing on a web site is legitimate and not from an external source.
In Cross-site Scripting (XSS), the web site is forced to echo attacker-supplied executable code, which loads in a user’s browser.
Web applications are used for variety of functions like booking tickets, shopping, banking which involves lot of money, so they should be made more robust and free from vulnerable attacks. The usage of web applications will be more if they are well secured. The approach of validating the web application should not only focus on the functionality & load testing but should also focus on validating the security of the web applications against vulnerabilities.
References
0 comments:
Post a Comment