What is the type of attack called by injecting malicious code in a websites form input?

Most Common Web Vulnerabilities

Our targets will all be exploited by attacking well-understood vulnerabilities. Although there are several other web-related vulnerabilities, these are the ones we are going to concentrate on as we work through the chapters.

Abstract

This chapter covers the most damaging type of web application attack—code injection. These attacks all rely on the web application accepting malicious input and processing it without realizing it may cause harm. SQL injection, operating system command injection, and injectable web shell attacks are introduced in context of how and where they can be exploited. Extensive parts of this chapter are dedicated to using Burp Suite and sqlmap to execute these attacks. The SQL injection process follows very specific steps in which the vulnerability is discovered, authentication is bypassed, data are harvested from the database, and password hashes are cracked offline for future use.

Chapter 8: “Web application firewalls and client-side filters”

WAFs are a common device used to protect Web applications from malicious attacks. Such devices typically use a list of regular expressions to detect malicious input. This makes them prime targets for bypassing and attacking using Web application obfuscation techniques. This chapter will demonstrate the ineffectiveness of many WAFs at defending against even the most basic obfuscation techniques. In addition to traditional WAFs, this chapter also discusses client-side filters built into browsers. These filters will help raise the bar an attacker must clear to perform successful attacks. We will look at the details of how these filters work and see some specific and highly obfuscated ways in which they can be bypassed.

Reviewing ZAP Results

Once the active scanning has completed, you can review the findings in the Alerts tab where a tree structure will display the discovered vulnerabilities. It’s not surprising that our DVWA application has several existing vulnerabilities (that’s the whole point!) as illustrated by the SQL injection finding here. ZAP provides a brief description of the vulnerability, what page it was discovered on (login.php in this example), and the parameter’s value that triggered the finding as shown in Figure 3.15.

We now have the exact URL to attack and we know the parameter that is vulnerable. Instead of using a benign proof-of-concept request sent to the web application, we can send in malicious input to compromise the web application. We can perform this attack in the actual HTML form field in a browser if we want to type our malicious input there, or we can use a proxy to intercept the request and edit the parameter’s value. We can even use additional tools, such as sqlmap, to exploit the application. We will be doing a little bit of each of these scenarios coming up during the actual web application hacking.

The full report of ZAP Scanner’s findings can be exported as HTML or XML via the Reports menu. As soon as you save the report file as HTML, as shown in Figure 3.16, it will open in your default browser for you to review further.

The full report details the findings for each of the discovered vulnerability in the same format as the Alerts tab view. Below is the report entry for an SQL injection vulnerability on the include.php page. The most important parts are the URL and the parameter value that triggered the vulnerability.

Alert Detail:

High (Suspicious): SQL Injection Fingerprinting

Description: SQL injection may be possible.

URL: http://127.0.0.1/vulnerabilities/fi/?page=include.php'INJECTED_PARAM

Parameter: page=include.php'INJECTED_PARAM

...

Solutions:

Do not trust client side input even if there is client side validation. In general,

If the input string is numeric, type check it.

If the application used JDBC, use PreparedStatement or CallableStatement with parameters passed by '?'

If the application used ASP, use ADO Command Objects with strong type checking and parameterized query.

If stored procedure or bind variables can be used, use it for parameter passing into query. Do not just concatenate string into query in the stored procedure!

Do not create dynamic SQL query by simple string concatentation.

Use minimum database user privilege for the application. This does not eliminate SQL injection but minimize its damage. Eg if the application require reading one table only, grant such access to the application. Avoid using 'sa' or 'db-owner'.

...

Intrusion Detection Capabilities

Lastly, WAFs should be able to monitor application behavior passively, take action in the event of suspicious behavior, and maintain a non-reputable log of events for a forensic analysis following an SQL injection incident. The logs should give you the information to determine whether your application was attacked and provide enough information for reproducing the attack string. Blocking and rejecting malicious input aside, the ability to add intrusion detection features to your application without changing a line of code is a strong argument for the use of WAFs. When performing a forensic analysis following an SQL injection incident, nothing is more frustrating than having to rely on Web server log files, which often contain only a small subset of the data sent in the request.

In summary, with ModSecurity it is possible to stop SQL injection attacks, patch a known SQL injection vulnerability, detect attack attempts, and suppress SQL error messages that often facilitate exploitation of SQL injection vulnerabilities. Now that we've discussed ModSecurity and WAFs in general, we're going to look at some solutions that could be considered a WAF but are not as robust. However, they can be just as effective depending on the scenario, and they can be potentially cheaper in cost and resource requirements to deploy.

Cross-Site Scripting (XSS) Attacks

The classic proof-of-concept for XSS is to use a JavaScript alert box that pops up when the code runs in the victim’s browser. This by itself is certainly not malicious, but it does show that inserted JavaScript is returned by the application to the user’s browser. XSS can spell absolute disaster for an application and its users if an attacker formulates a more malicious payload.

XSS attacks are a good training ground for encoding and decoding schemes as they are used heavily in URL parameters and the input validation routines deployed by application defense mechanisms. It’s not critical that you know the exact encoding scheme being used, but it is critical that you know how to encode and decode your malicious input to work around safeguards that have been put in place. There are several encoding schemes that you will come across when dealing with XSS, but some of the most popular are:

Base64

URL

HTML

ASCII Hexadecimal

UTF-8

Long UTF-8

Binary

UTF-16

UTF-7

Most of the hacking suites available today, including Burp Suite, have built-in tools with the functionality to assist with encoding and decoding parameter values.

One factor that you must understand when working with XSS is the same origin policy in a browser, which permits scripts running on pages originating from the trusted site without restriction, but prevents access to different sites. For example, the same origin policy won’t allow a script from www.l33thacker.net to execute if the user didn’t request a www.l33thacker.net page. The same origin policy provides a clear separation between trusted and untrusted sites in the browser to ensure the integrity of the browsing session on the client side. The browser must trust the site that is responding with a script. This is why, as a hacker, you must find an XSS vulnerability in the application that the user trusts in order for malicious script to be executed in the victim’s browser.

Alternate Attack Vectors

Just as Monty Python didn't expect the Spanish Inquisition, developers may not expect SQL injection vulnerabilities to arise from certain sources. Web-based applications lurk in all sorts of guises and work with data from all manner of sources. For example, consider a Web-driven kiosk that scans bar codes (UPC symbols) to provide information about the item, or a warehouse that scans Radio Frequency Identification (RFID) tags to track inventory in a Web application. Both the bar code and RFID represent user-supplied input, albeit a user in the sense of an inanimate object. Now, a DVD or a book doesn't have agency and won't spontaneously create malicious input. On the other hand, it's not too difficult to print a bar code that contains a single quote – our notorious SQL injection character. Figure 3.1 shows a bar code that contains such a quote. (The image uses Code 128. Not all bar code symbologies are able to represent a single quote or nonnumeric characters.)

You can find bar code scanners in movie theaters, concert venues, and airports. In each case, the bar code is used to encapsulate a unique identifier stored in a database. These applications require SQL injection countermeasures as much as the more familiar Web sites with readily accessible URI parameters.

Metainformation within binary files, such as images, documents, and PDFs, may also be a delivery vector for SQL injection exploits. Most modern cameras tag their digital photos with Exchangeable Image File Format (EXIF) data that can include date, time, GPS coordinates, or other textual information about the photo. If a Web site extracts and stores EXIF tags in a database, then it must treat those tags as untrusted data like any other data supplied by a user. Nothing in the EXIF specification prevents a malicious user from crafting tags that carry SQL injection payloads. The metainformation inside binary files poses other risks if not properly validated, as described in Chapter 1, “Cross-Site Scripting.”

Alternate Attack Vectors

Monty Python didn’t expect the Spanish Inquisition. Developers may not expect SQL injection vulnerabilities from certain sources. Web-based applications lurk in all sorts of guises and work with data from all manner of sources. For example, consider a web-driven kiosk that scans bar codes (UPC symbols) in order to provide information about the item or a warehouse that scans RFID tags to track inventory in a web application. Both the bar code and RFID represent user-supplied input, albeit a user in the sense of an inanimate object. Now, a DVD or a book doesn’t have agency and won’t spontaneously create malicious input. On the other hand, it’s not too difficult to print a bar code that contains an apostrophe—our notorious SQL injection character. Figure 4.2 shows a bar code that contains such a quote. (The image uses Code 128. Not all bar code symbologies are able to represent an apostrophe or non-numeric characters.)

You can find bar code scanners in movie theaters, concert venues, and airports. In each case the bar code is used to encapsulate a unique identifier stored in a database. These applications require SQL injection countermeasures as much as the more familiar web sites with readily-accessible URI parameters.

The explosive growth of mobile devices has made a bar code-like technology popular: the QR code. People have become accustomed to scanning QR codes with their mobile devices, to the point where they would make excellent Trojan images for HTML injection and CSRF attacks. (QR codes may contain links.) The codes can also contain text. So, if there were ever an application that read QR code data into a database insecurely, it could fall prey to an image like Figure 4.3:

Meta-information within binary files such as images, documents, and PDFs may also be a delivery vector for SQL injection exploits. Most modern cameras tag their digital photos with EXIF data that can include date, time, GPS coordinates or other textual information about the photo. If a web site extracts and stores EXIF tags in a database then it must treat those tags as untrusted data like any other data supplied by a user. Nothing in the EXIF specification prevents a malicious user from crafting tags that carry SQL injection payloads. The meta-information inside binary files poses other risks if not properly validated as described in Chapter 2: HTML Injection & Cross-Site Scripting.

Overview: Why Is Metasploit Here?

Metasploit came about primarily to provide a framework for penetration testers to develop exploits. The typical life cycle of a vulnerability and its exploitation is as follows:

Discovery A security researcher or the vendor discovers a critical security vulnerability in the software.

Disclosure The security researcher either adheres to a responsible disclosure policy and informs the vendor, or discloses it on a public mailing list. Either way, the vendor needs to come up with a patch for the vulnerability.

Analysis The researcher or others across the world begin analyzing the vulnerability to determine its exploitability. Can it be exploited? Remotely? Would the exploitation result in remote code execution, or would it simply crash the remote service? What is the length of the exploit code that can be injected? This phase also involves debugging the vulnerable application as malicious input is injected to the vulnerable piece of code.

Exploit Development Once the answers to the key questions are determined, the process of developing the exploit begins. This has usually been considered a bit of a black art, requiring an in-depth understanding of the processor's registers, assembly code, offsets, and payloads.

Testing This is the phase where the coder now checks the exploit code against various platforms, service pack, or patches, and possibly even for different processors (e.g., Intel, Sparc, and so on).

Release Once the exploit is tested, and the specific parameters required for its successful execution have been determined, the coder releases the exploit, either privately or on a public forum. Often, the exploit is tweaked so that it does not work right out of the box. This is usually done to dissuade script kiddies from simply downloading the exploit and running it against a vulnerable system.

All of this has undergone a bit of a paradigm shift. With Metasploit it is now quite straightforward for even an amateur coder to be able to write an exploit. The framework already comes with more than 60 exploits pre-packaged to work right out of the box. The development of new exploits is proceeding at a rapid pace, and as the popularity of the tool soars, the availability of exploits is also likely to increase. This is quite similar to the large number of plugins that Nessus now has.

But this is only part of the story. Where Metasploit really comes into its own is in the way it has been architected and developed. It is now likely to become the first free (partially open-source, since it is now distributed under its own Metasploit License) security tool, which covers the entire gamut of security testing—recon modules to determine vulnerable hosts and interface with scanners such as Nmap and Nessus, exploits and payloads to attack the specific vulnerabilities, and post-exploitation goodies to stealthily own the system, and possibly the entire network.

6.2.3 Fuzzing Approaches

Fuzzing is extensively used in vulnerability testing [137] to introduce malformed data or mutate nominal values to trigger flawed code in applications. Fuzzing techniques are usually very cheap to deploy, do not suffer from false positives, but lack an expected-result model and therefore rely on crashes and fails to assign a verdict. Two main fuzzing techniques exist: mutation based and generation based. Mutation fuzzing consists of altering a sample file or data following specific heuristics, while generation-based fuzzers take the input specification and generate test cases from it. Fuzzing may be used for crafting malicious input data [138], or crafting erroneous communication messages [139].

The approach presented by Duchene [138] consists of modeling the attacker's behavior, and driving this model by a genetic algorithm that evolves SUT input sequences. It requires a state-aware model of the SUT, either derived from an ASLan++ description or inferred from traces of valid/expected SUT execution. This model is then annotated using input taint data-flow analysis, to spot possible reflections. Concrete SUT inputs are generated with respect to an Attack Input Grammar which produces fuzzed values for reflected SUT input parameters. The fitness function depends on the obtained SUT output following the injection of a concrete SUT input. It computes the veracity of an input by looking for correlations, using the string distance between a given input parameter value and a substring of the output. Two genetic operators are used: mutation and cross-over. It is an efficient technique for detecting XSS, as it goes beyond the classical XSS evasion filters that may not be exhaustive. Such a technique also tackles multistep XSS discovery by using a more complex string matching algorithm to generate an annotated FSM, in order to inspect the SUT to find the possibilities of XSS at certain places.

A model-based behavioral fuzzing approach has been designed by Wang et al. [139] to discover vulnerabilities of Database Management Systems (DBMS). A DBMS defines a format rule that specifies packet format and a behavior rule that specifies its semantics and functionality. This approach is based on two main artifacts. The first artifact is a behavioral model, which includes fuzzing patterns and behavioral sequences. This is obtained from a behavior analysis of DBMS (protocol format analysis, attack surface analysis, etc.). A fuzzing pattern expresses the data structure of packets, the needs of security testing, and the design strategy for vulnerability discovery. A behavioral sequence defines the message transfer order between client and DBMS. The second artifact is a DBMS Fuzzer composed of a test instance (a detailed test script based on fuzzing patterns), and a finite state machine model EXT-NSFSM used for semivalid test case generation based on behavioral sequences and test instances. The authors describe a general framework for behavioral fuzzing that has been implemented and used in several experiments. It allows for the generation of thousands of fuzzing instances, and despite a few errors of analysis and script, the tool was able to discover buffer overflow vulnerabilities, 10 of which were not released yet.