This chapter is from the book
This chapter is from the book
This chapter is from the book
Logical Attacks
The Logical Attacks section focuses on the abuse or exploitation of a web application’s logic flow. Application logic is the expected procedural flow used in order to perform a certain action. Password recovery, account registration, auction bidding, and eCommerce purchases are all examples of application logic. A web site may require a user to correctly perform a specific multi-step process to complete a particular action. An attacker may be able to circumvent or misuse these features to harm a web site and its users.
Abuse of Functionality
Abuse of Functionality is an attack technique that uses a web site’s own features and functionality to consume, defraud, or circumvent access control mechanisms. Some functionality of a web site, possibly even security features, may be abused to cause unexpected behavior. When a piece of functionality is open to abuse, an attacker could potentially annoy other users or perhaps defraud the system entirely. The potential and level of abuse will vary from web site to web site and application to application.
Abuse of Functionality techniques are often intertwined with other categories of web application attacks, such as performing an encoding attack to introduce a query string that turns a web search function into a remote web proxy. Abuse of Functionality attacks are also commonly used as a force multiplier. For example, an attacker can inject a Cross-site Scripting snippet into a web-chat session and then use the built-in broadcast function to propagate the malicious code throughout the site.
In a broad view, all effective attacks against computer-based systems entail Abuse of Functionality issues. Specifically, this definition describes an attack that has subverted a useful web application for a malicious purpose with little or no modification to the original function.
Abuse of Functionality Examples
Examples of Abuse of Functionality include
- Using a web site’s search function to access restricted files outside of a web directory.
- Subverting a file upload subsystem to replace critical internal configuration files.
- Performing a DoS by flooding a web-login system with good usernames and bad passwords to lock out legitimate users when the allowed login retry limit is exceeded.
Other real-world examples are described in the following sections.
Matt Wright’s FormMail
The PERL-based web application "FormMail" was normally used to transmit user- supplied form data to a preprogrammed email address. The script offered an easy-to-use solution for web sites to gather feedback. For this reason, the FormMail script was one of the most popular CGI programs online. Unfortunately, this same high degree of utility and ease of use was abused by remote attackers to send email to any remote recipient. In short, this web application was transformed into a spam-relay engine with a single browser web request. An attacker merely has to craft a URL that supplied the desired email parameters and perform an HTTP GET to the CGI, such as the following:
http://example/cgi-bin/FormMail.pl?recipient=email@victim.example&message=you%20got%20spam
An email would be dutifully generated, with the web server acting as the sender, allowing the attacker to be fully proxied by the web application. Because no security mechanisms existed for this version of the script, the only viable defensive measure was to rewrite the script with a hard-coded email address. Barring that, site operators were forced to remove or replace the web application entirely.
Macromedia’s Cold Fusion
Sometimes basic administrative tools are embedded within web applications that can be easily used for unintended purposes. For example, Macromedia’s Cold Fusion by default has a built-in module for viewing source code that is universally accessible. Abuse of this module can result in critical web application information leakage. Often these types of modules are not sample files or extraneous functions, but critical system components. This makes disabling these functions problematic since they are tied to existing web application systems.
Smartwin CyberOffice Shopping Cart Price Modification
Abuse of Functionality occurs when an attacker alters data in an unanticipated way in order to modify the behavior of the web application. For example, the CyberOffice shopping cart can be abused by changing the hidden price field within the web form. The web page is downloaded normally, edited, and then resubmitted with the prices set to any desired value.
Apache Countermeasures for Abuse of Functionality
Prevention of these kinds of attacks depends largely upon designing web applications with core principles of security. Specifically this entails implementing with the least-privilege principle: web applications should only perform their intended function, on the intended data, for their intended customers, and nothing more. Furthermore, web applications should also verify all user-supplied input to ensure that proper parameters are being passed from the client.
Many web sites are vulnerable to Abuse of Functionality threats. They rely solely on security through obscurity for protection. We strongly recommended that the functionality and purpose of each web application be clearly documented. This will allow implementers and auditors to quickly identify functions that could be subject to abuse before bringing these systems online.
With specific regard to Apache, utilizing the CIS Apache Benchmark Scoring Tool will assist with locking down the web server and applying the principle of least privilege by restricting the capabilities of the Apache user account, disabling un-needed modules, and updating permissions on directories and files.
References
"FormMail Real Name/Email Address CGI Variable Spamming Vulnerability" http://www.securityfocus.com/bid/3955
"CVE-1999-0800"
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0800
"CA
Unicenter
pdmcgi.exe
View
Arbitrary
File"
http://www.osvdb.org/displayvuln.php?osvdb_id=3247
"PeopleSoft
PeopleBooks
Search
CGI
Flaw"
http://www.osvdb.org/displayvuln.php?osvdb_id=2815
"iisCART2000
Upload
Vulnerability"
http://www.secunia.com/advisories/8927/
"PROTEGO
Security
Advisory
#PSA200401"
http://www.protego.dk/advisories/200401.html
"Price modification possible in CyberOffice Shopping Cart" http://archives.neohapsis.com/archives/bugtraq/2000-10/0011.html
Denial of Service
Denial of Service (DoS) is an attack technique with the intent of preventing a web site from serving normal user activity. DoS attacks, which are normally applied to the network layer, are also possible at the application layer. These malicious attacks can succeed by starving a system of critical resources, vulnerability exploit, or abuse of functionality.
Many times, DoS attacks will attempt to consume all of a web site’s available system resources such as CPU, memory, disk space, and so on. When any one of these critical resources reaches full utilization, the web site will normally be inaccessible.
As today’s web application environments include a web server, database server, and an authentication server, DoS at the application layer may target each of these independent components. Unlike DoS at the network layer, where a large number of connection attempts are required, DoS at the application layer is a much simpler task to perform.
DoS Example
For this example, the target is a healthcare web site that generates a report with medical history. For each report request, the web site queries the database to fetch all records matching a single social security number. Given that hundreds of thousands of records are stored in the database (for all users), the user will need to wait three minutes to get his medical history report. During the three minutes of time, the database server’s CPU reaches 60 percent utilization while searching for matching records.
A common application layer DoS attack will send 10 simultaneous requests asking to generate a medical history report. These requests will most likely put the web site under a DoS-condition as the database server’s CPU will reach 100% utilization. At this point, the system will likely be inaccessible to normal user activity.
There are many different targets for a DoS attack:
- DoS targeting a specific user. An intruder will repeatedly attempt to login to a web site as some user, purposely doing so with an invalid password. This process will eventually lock out the user.
- DoS targeting the database server. An intruder will use SQL injection techniques to modify the database so that the system becomes unusable (e.g., deleting all data, deleting all usernames, and so forth).
- DoS targeting the web server. An intruder will use Buffer Overflow techniques to send a specially crafted request that will crash the web server process, causing the system to be inaccessible to normal user activity.
Apache Countermeasures for DoS Attacks
As listed previously, web-based DoS attacks may take on many forms, as the target of the attack may be focused at different components of the web server or application. In order to mitigate the effects of a DoS attack, we therefore need to implement multiple solutions.
DoS Targeting a Specific User
Apache does not have a built-in capability to lock user accounts due to failed login attempts. This process is normally handled by the authentication application; in this scenario, perhaps the user is being authenticated with credentials that are stored in a database. This means that the lockout procedures would reflect the policies of the database authentication mechanism.
The best way to approach this with Apache is to rely on the Mod_Dosevasive settings to identify when an attacker is using automated means to authenticate to numerous accounts. In this attack scenario, we have two different triggers for identification: first are the alerts generated by Mod_Dosevasive if the attacker sends data over our threshold, and the second are the 401 Unauthorized status code alerts for the failed logins that are generated by the use of CGI scripts. With either of these alerting mechanisms, we could identify the source IP of the attack and implement access control directives to deny further access.
DoS Targeting the Database Server
In order to combat this type of attack, we must implement proper input validation filtering so that an attacker is not able to successfully pass SQL statements within the URL to the back-end database. Please refer to the previous section on SQL Injection for example security filters.
DoS Targeting the Web Server
We previously discussed tuning the configuration of the HTTP connection to help mitigate the effects of a DoS attack with updated settings for KeepAlives, KeepAliveTimeouts, and so on. In addition to these Apache directives, we also rely on Mod_Dosevasive to respond to these DoS attacks. As I mentioned in the previous chapter, I have made some updates to the Mod_Dosevasive code so that I run more efficiently in my environment. An additional technique that I use to lessen the impact of a DoS attack is to change the default status code returned by Mod_Dosevasive. The default status code is 403 Forbidden. This causes resource consumption issues in my environment since I utilize CGI alerting scripts for the 403 status codes. These scripts will present the attacker with an html page and also email security personnel. The overhead associated with spawning these CGI scripts and calling up sendmail exacerbates the effects of a DoS attack against my site. How can we fix this issue?
I decided to update the Mod_Dosevasive code to change the status code, but the question was "What should I change it to?" Preferably, I needed a status code that won’t trigger a CGI script and only returns the HTTP response headers. This lack of a response message body will help to reduce the network consumption. I therefore edited the mod_dosevasive20.c file and changed all status code entries from HTTP_FORBIDDEN to HTTP_MOVED_TEMPORARILY.
Besides a resource consumption attack, an attacker may be able to take advantage of a vulnerability with the web server software to cause the web server to hang or crash. A good example of this situation was the Chunked-Encoding Vulnerability from June 2002 (http://www.cert.org/advisories/CA-2002-17.html). With this vulnerability, an attacker could send a request that included the "Transfer-Encoding: chunked" header along with payload data that could potentially crash the server or cause code execution. eEye Security released a tool that would automatically check a web server to verify if it was vulnerable: http://eeye.com/html/Research/Tools/apachechunked.html. The resulting HTTP request looked like this:
**************Begin Session**************** POST /EEYE.html HTTP/1.1 Host: www.EEYE2002.com Transfer-Encoding: chunked Content-Length: 22 4 EEYE 7FFFFFFF [DATA] **************End Session******************
Besides updating Apache with the appropriate patch, you could also implement a Mod_Security filter to block all client requests that submit the Transfer-Encoding header:
SecFilterSelective HTTP_TRANSFER_ENCODING "!^$"
Besides specific Apache mitigation options, you should monitor your web site’s resources. Isolating different critical resources and simulating DoS scenarios using stress tools is an excellent way to test overall system integrity. When "hot spots" are detected, try to review your design or add more resilient resources. Additional network architecture solutions include server fail-over and threshold-based load sharing, balancing, or redundancy.
References
"CERT Advisory CA-2002-17 Apache Web Server Chunk Handling Vulnerability" http://www.cert.org/advisories/CA-2002-17.html
"The
Attacks
on
GRC.com"
http://grc.com/dos/grcdos.htm
Insufficient Anti-Automation
Insufficient Anti-Automation occurs when a web site permits an attacker to automate a process that should only be performed manually. Certain web site functionalities should be protected against automated attacks.
Left unchecked, automated robots (programs) or attackers could repeatedly exercise web site functionality attempting to exploit or defraud the system. An automated robot could potentially execute thousands of requests a minute, causing potential loss of performance or service.
Insufficient Anti-Automation Example
An automated robot should not be able to sign up 10,000 new accounts in a few minutes. Similarly, automated robots should not be able to annoy other users with repeated message board postings. These operations should be limited only to human usage.
Apache Countermeasures for Insufficient Anti-Automation
There are a few solutions that have been used in the past to determine if a web request is from a person or a robot, but the most telling characteristic is the speed of the requests. Therefore, the best mitigation option for Apache is to leverage Mod_Dosevasive to monitor the connection thresholds.
References
"Telling
Humans
Apart
(Automatically)"
http://www.captcha.net/
"Ravaged
by
Robots!"
By
Randal
L.
Schwartz
http://www.webtechniques.com/archives/2001/12/perl/
".Net Components Make Visual Verification Easier" By JingDong (Jordan) Zhang http://go.cadwire.net/?3870,3,1
"Vorras
Antibot"
http://www.vorras.com/products/antibot/
"Inaccessibility
of
Visually-Oriented
Anti-Robot
Tests"
http://www.w3.org/TR/2003/WD-turingtest-20031105/
Insufficient Process Validation
Insufficient Process Validation occurs when a web site permits an attacker to bypass or circumvent the intended flow control of an application. If the user state through a process is not verified and enforced, the web site could be vulnerable to exploitation or fraud.
When a user performs a certain web site function, the application may expect the user to navigate through a specific order sequence. If the user performs certain steps incorrectly or out of order, a data integrity error occurs. Examples of multi-step processes include wire transfer, password recovery, purchase checkout, account signup, and so on. These processes will likely require certain steps to be performed as expected.
For multi-step processes to function properly, web sites are required to maintain user state as the user traverses the process flow. Web sites will normally track a user’s state through the use of cookies or hidden HTML form fields. However, when tracking is stored on the client side within the web browser, the integrity of the data must be verified. If not, an attacker may be able to circumvent the expected traffic flow by altering the current state.
Insufficient Process Validation Example
An online shopping cart system may offer to the user a discount if product A is purchased. The user may not want to purchase product A, but product B. By filling the shopping cart with product A and product B, and entering the checkout process, the user obtains the discount. The user then backs out of the checkout process, and removes product A, or simply alters the values before submitting to the next step. The user then reenters the checkout process, keeping the discount already given in the previous checkout process with product A in the shopping cart, and obtains a fraudulent purchase price.
Apache Countermeasures for Insufficient Process Validation
A term commonly used in these scenarios is Forceful Browsing, which is a technique used by attackers when they attempt to access URLs in an order that is unexpected by the application. These types of logical attacks are the most difficult for Apache to address, as it does not have the knowledge of the expected process flow of the application. The best way to approach this is to document the desired application flow and then implement various Mod_Security filters to verify that the client came from the correct URL when they access the current URL. For instance, say that you have a login page and then a page for resetting your account password. You could implement Mod_Security filter like this:
SecFilterSelective SCRIPT_FILENAME "/account/passwd.php" chain SecFilterSelctive HTTP_REFERER "!/account/login.php"
Another possible process flow validation would be to use Mod_Security to verify portions of a session ID or cookie. If your application sets or updates the session ID in response to certain actions, you could possibly validate portions of the cookie. For instance, say that your application sets this cookie when a client is attempting to update their account information:
Set-Cookie: Account=pCqny0PnAkGv22QSIZUIHfF5PHIvsai1W03%2BfrKhJxgyJsKalgubbMBrwkI%3D%3DG2G3%0D; path=/account/update.php; expires=Fri, 06-May-2005 09:11:43 GMT
The cookie includes the "path=" parameter. We can implement some Mod_Security filters to verify that the path parameter is reflecting the proper locations during certain application functions.
SecFilterSelective SCRIPT_FILENAME "/account/passwd.php" chain SecFilterSelective COOKIE_Account "!path\=/account/update\.php"
redirect:http://host.com/account/login.php
These directives will redirect a client back to the login process if the path parameter in the Account cookie is not set appropriately.
References
"Dos
and
Don'ts
of
Client
Authentication
on
the
Web"
By
Kevin
Fu,
Emil
Sit,
Kendra
Smith,
Nick
Feamster—MIT
Laboratory
for
Computer
Science http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf