Common Attack Pattern Enumeration and Classification

Common Attack Pattern Enumeration and Classification

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.

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.