| Attack Pattern ID | Pattern Abstraction: Standard 75 |
| Typical Severity | Very High |
| Description | Summary An attacker modifies the contents of configuration files that influence/control the operation of the target software. This attack exploits the ever-growing number, size and complexity of configuration files and the often lax access controls on these files. This attack exploits a program's trust in configuration files that may have weaker permissions. System configuration in distributed systems such as J2EE servers have many administration points. For example, permissions may be set on the administrative GUI, the configuration file for the server as a whole, configuration files for specific domains and applications, special jar and other class files used to load resources at runtime, and even policy specific in .war and .ear files. A mistake in permissions setting in either the file acl or the content is an opening an attacker can use to elevate privilege.
The following three examples describe how servers can be attacked using this pattern
Console output: Depending on configuration, server can put a prodigious amount of configuration information out to the console. Some servers require the server password to be input through the shell, an attacker can gather this and other data (like database connections) from system logs and echoes.
Configuration files: The configuration file acts as the dna for the server, mapping its settings to all required network, application, identity and data resources. A weak permission setting on these files represents a very large vulnerability, because the entire system as a whole can be owned by the attacker, and since logs are generally controlled from the same source file, the attacker can erase any forensic evidence.
Configuration file contents: The configuration file for an application may contain xml files that manage the application security policy, describing the allowed security authorities like directory services, token issuers, and so on. Many J2EE application server use xml files to list the ACLs allowed users, roles, and groups for an application. Generally these are manually edited files that are not in the perview of the system administrators, any ability on the attacker's behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.
|
| Attack Prerequisites |
Configuration files must be modifiable by the attacker
|
| Typical Likelihood of Exploit |
High
|
| Methods of Attack | - Modification of Resources
|
| Examples-Instances | Description The BEA Weblogic server uses a config.xml file to store configuration data. If this file is not properly protected by the system access control, an attacker can write configuration information to redirect server output through system logs, database connections, malicious URLs and so on. Access to the Weblogic server may be from a so-called Custom realm which manages authentication and authorization privileges on behalf of user principals. Given write access, the attacker can insert a pointer to a custom realm jar file in the config.xml < CustomRealm ConfigurationData="java.util.Properties" Name="CustomRealm" RealmClassName="Maliciousrealm.jar" /> The main issue with configuration files is that the attacker can leverage all the same functionality the server has, but for malicious means. Given the complexity of server configuration, these changes may be very hard for administrators to detect.
|
| Attacker Skill or Knowledge Required |
Medium → to identify vulnerable configuration files, and understand how to manipulate servers and erase forensic evidence
|
| Solutions and Mitigations |
Design: Enforce principle of least privilege
Design: Backup copies of all configuration files
Implementation: Integrity monitoring for configuration files
Implementation: Enforce audit logging on code and configuration promotion procedures.
Implementation: Load configuration from separate process and memory space, for example a separate physical device like a CD
|
| Attack Motivation-Consequences | |
| Context Description | “Attack Pattern: Use a User-Supplied Configuration File to Run Commands That Elevate Privilege A setuid utility program accepts command-line arguments. One of these arguments allows a user to supply the path to a configuration file. The configuration file allows shell commands to be inserted. Thus, when the utility starts up, it runs the given commands. One example found in the wild is the UUCP (or UNIX-to-UNIX copy program) set of utilities. The utility program may not have root access, but that may belong to a group or user context that is more privileged than that of the attacker. In the case of UUCP, the elevation may lead to the dialer group, or the UUCP user account. Escalating privilege in steps will usually lead an attacker to a root compromise (the ultimate goal). Some programs will not allow a user-supplied configuration file, but the systemwide configuration file may have weak permissions. The number of vulnerabilities that exist because of poorly configured permissions is large. A note of caution: As an attacker, you must consider the configuration file as an obvious detection point. A security process may monitor the target file. If you make changes to a configuration file to gain privilege, then you should immediately clean the file when you are finished. You can also run certain utilities to set back the file access dates. The key is not to leave a forensic trail surrounding the file you exploited."
[Hoglund and McGraw 04]
|
| Injection Vector |
Configuration files
|
| Payload |
Commands or configuration settings
|
| Activation Zone |
Configuration file processing routines
|
| Payload Activation Impact |
Enables attacker to execute server side code with any commands that the program owner has privileges to.
|
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 349 | Acceptance of Extraneous Untrusted Data With Trusted Data | Targeted | | 99 | Insufficient Control of Resource Identifiers (aka 'Resource Injection') | Targeted | | 77 | Failure to Sanitize Data into a Control Plane (aka 'Command Injection') | Targeted | | 346 | Origin Validation Error | Targeted | | 353 | Failure to Add Integrity Check Value | Secondary | | 354 | Failure to Check Integrity Check Value | Secondary |
|
| Purpose | Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | Medium |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| All | 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 | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name and Description | | Sean Barnum | Cigital, Inc | 2007-04-16 | Modified pattern content according to review and feedback |
|