Common Attack Pattern Enumeration and Classification

Common Attack Pattern Enumeration and Classification

69

Very High

The targeted program runs with elevated OS privileges.

The targeted program accepts input data from the user or from another program.

The targeted program does not perform input validation properly.

The targeted program does not fail safely. For instance when a program fails it may authorize restricted access to anyone.

The targeted program has a vulnerability such as buffer overflow which may be exploited if a malicious user can inject unvalidated data. For instance a buffer overflow interrupts the program as it executes, and makes it run additional code supplied by the attacker. If the program under attack has elevated privileges to the OS, the attacker can elevate its privileges (such as having root level access).

The targeted program is giving away information about itself. Before performing such attack, an eventual attacker may need to gather information about the services running on the host target. The more the host target is verbose about the services that are running (version number of application, etc.) the more information can be gather by an attacker.

This attack often requires communicating with the host target services directly. For instance Telnet may be enough to communicate with the host target.

Very High

• Injection
• API Abuse
• Protocol Manipulation
• Flooding

Low: An attacker can use a tool to scan and automatically launch an attack against known issues. A tool can also repeat a sequence of instructions and try to brute force the service on the host target, an example of that would be the flooding technique. Medium to High: More advanced attack may require knowledge of the protocol spoken by the host service.

Probing technique include fuzzing (sending random data in order to fail the service on the host target), brute forcing (with automated tools), network scanning to determine which services are available and running on the target host.

There are freely available tools to probe and gather information from host target. For instance, the attacker can find out that a host target has not been patched by collecting such information.

The log can have a trace of abnormal activity. Also if abnormal activity is detected on the host target. For instance flooding should be seen as abnormal activity and the target host may decide to take appropriate action in order to mitigate the attack (data filtering or blocking). Resource exhaustion is also a sign of abnormal activity.

The attacker may try to hide her attack by forging the host's logs. The attacker has interest in mimicing a legitimate call to the program or service under threat.

Apply the principle of least privilege.

Validate all untrusted data.

Apply the latest patches.

Scan your services and disable the ones which are not needed and are exposed unnecessarily. Exposing programs increases the attack surface. Only expose the services which are needed and have security mechanisms such as authentication built around them.

Avoid revealing information about your system (e.g., version of the program) to anonymous users.

Make sure that your program or service fail safely. What happen if the communication protocol is interrupted suddenly? What happen if a parameter is missing? Does your system have resistance and resiliance to attack? Fail safely when a resource exhaustion occurs.

If possible use a sandbox model which limits the actions that programs can take. A sandbox restricts a program to a set of privileges and commands that make it difficult or impossible for the program to cause any damage.

Check your program for buffer overflow and format String vulnerabilities which can lead to execution of malicious code.

Monitor traffic and resource usage and pay attention if resource exhaustion occurs.

Protect your log file from unauthorized modification and log forging.

• Run Arbitrary Code
• Privilege Escalation
• Denial of Service

Secure programming guides are full of references to the principle of least privilege (see Building Secure Software [Viega and McGraw, 2001], for example). The problem is that most code is not designed to work with least privilege. Often times the code will fail to operate properly if access restrictions are placed on it. The sad thing is that many such programs could very likely be written without requiring Administrator or root access, but they aren’t. As a result, today’s software runs with way too much system wide privilege.

Thinking about privilege requires adjusting your viewpoint to a panoramic, systemwide view. (This is an excellent attacker trick that you should internalize.) Often the OS is the essential service providing privilege and access control checks, but many programs do not properly adhere to the least-privilege concept, so they abuse the OS and request too much privilege (often without being told “no”). Furthermore, the user of the program may or may not notice this issue, but you can be assured that an attacker will. One very interesting technique is to run a target program in a sandbox and examine the security context of each call and operation (something that is made easier in advanced platforms like Java 2). Privilege problems are very likely to surface during this exercise, and thus provide one of the richest forms of attack.

A user must be authenticated if she invokes a privileged program.

• Reluctance to Trust
• Least Privilege
• Fail Securely
• Defense in Depth

• Any guideline related to the buffer overflow and format String vulnerability.
• Patch programs with the latest patches from Vendors.
• Ensure log integrity
• Validate all untrusted input

Exploitation

G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.

CWE : Failure to protect stored data from modification

CWE : Setting manipulation

CWE : Often Misused: Privilege Management

CWE : Permissions, Privileges, and Access Controls