| Attack Pattern ID | Pattern Abstraction: Standard 81 |
| Typical Severity | High |
| Description | Summary Protection services in security are vulnerable so they are backstopped by detection in the so-called protect-detect-respond model. A key element in detection is log files, to identify a threat impact, for audit purposes, or simply responding to a crash. While penetrating a system requires a set of skills, more advanced attackers will cover their tracks by manipulating log files to either erase entries or input false entries to throw the system administrators off their trail. Since most requests to web servers are logged (at least header request response data) the attacker literally has the ability to generate log data in every request. Of course this is not the same as always being able to delete otherwise tamper with log data. Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern.
|
| Attack Prerequisites |
Target server software must be a HTTP server that performs web logging.
|
| Typical Likelihood of Exploit |
Medium
|
| Methods of Attack | - Modification of Resources
- Time and State
|
| Examples-Instances | Description Most web servers have a public interface, even if the majority of the site is password protected, there is usually at least a login site and brochureware that is publicly available. HTTP requests to the site are also generally logged to a Web log. From an attacker point of view, standard HTTP requests containing a malicious payload can be sent to the public website (with no other access required), when those requests appear in the log (such as http://victimsite/index.html?< malicious script> if they are followed by an administrator this may be sufficient to probe the administrator's host or local network.
|
| Attacker Skill or Knowledge Required |
Low → To input faked entries into Web logs
|
| Resources Required |
Ability to send specially formatted HTTP request to web server
|
| Solutions and Mitigations |
Design: Use input validation before writing to web log
Design: Validate all log data before it is output
|
| Attack Motivation-Consequences | |
| Context Description | “Attack Pattern: Web Logs Escape characters are often translated before being printed to the log file. For example, under IIS the string /index%2Easp is recorded in the log file as /index.asp. A more complicated string can be used to record fake entries in the logfile. For example:
/index.asp%FF200%FFHTTP/1.1%0A00:51:11%FF[192.168.10.10]%FFGET%FF/cgi-bin/phf
This string will force a carriage return in the log file and forge a fake entry showing the address 192.168.10.10 getting the cgi-bin/phf file" [Hoglund and McGraw 04]
|
| Injection Vector |
Forged log entry delivered through HTTP Request.
|
| Payload |
HTTP request
|
| Activation Zone |
Web log, log reporting systems
|
| Payload Activation Impact |
Log data contains data designed to trick administrators and auditors as to chain of events. Limit ability to conduct forensics and other investigations/responses.
|
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 117 | Incorrect Output Sanitization for Logs | Targeted | | 93 | Failure to Sanitize CRLF Sequences (aka 'CRLF Injection') | Targeted | | 92 | Custom Special Character Injection | Targeted | | 221 | Information Loss or Omission | Targeted | | 96 | Insufficient Control of Directives in Statically Saved Code (Static Code Injection) | Secondary | | 20 | Insufficient Input Validation | Secondary | | 150 | Failure to Sanitize Escape, Meta, or Control Sequences | Secondary | | 276 | Insecure Default Permissions | Targeted | | 279 | Insecure Execution-assigned Permissions | Secondary | | 116 | Incorrect Output Sanitization | Secondary |
|
| Purpose | Obfuscation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| Medium | High | Medium |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| Client-Server | All | All | All |
|
| References |
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
|
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. | Cigital, Inc | 2007-01-01 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Gunnar Peterson | Cigital, Inc | 2007-02-28 | Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" | | Sean Barnum | Cigital, Inc | 2007-03-09 | Review and revise |
|