CAPEC-177: Create files with the same name as files protected with a higher classification |
Description An attacker exploits file location algorithms in an operating system or application by creating a file with the same name as a protected or privileged file. The attacker could manipulate the system if the attacker-created file is trusted by the operating system or an application component that attempts to load the original file. Applications often load or include external files, such as libraries or configuration files. These files should be protected against malicious manipulation. However, if the application only uses the name of the file when locating it, an attacker may be able to create a file with the same name and place it in a directory that the application will search before the directory with the legitimate file is searched. Because the attackers' file is discovered first, it would be used by the target application. This attack can be extremely destructive if the referenced file is executable and/or is granted special privileges based solely on having a particular name. Typical Severity Prerequisites
| The target application must include external files. Most non-trivial applications meet this criterion. |
| The target application does not verify that a located file is the one it was looking for through means other than the name. Many applications fail to perform checks of this type. |
| The directories the target application searches to find the included file include directories writable by the attacker which are searched before the protected directory containing the actual files. It is much less common for applications to meet this criterion, but if an attacker can manipulate the application's search path (possibly by controlling environmental variables) then they can force this criterion to be met. |
Resources Required
| The attacker must have sufficient access to place an arbitrarily named file somewhere early in the application's search path. |
Taxonomy Mappings CAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.Relevant to the ATT&CK taxonomy mapping (also see parent) | Entry ID | Entry Name |
|---|
| 1036 | Masquerading |
Content History | Submissions |
|---|
| Submission Date | Submitter | Organization |
|---|
| 2014-06-23 (Version 2.6) | CAPEC Content Team | The MITRE Corporation | | | Modifications |
|---|
| Modification Date | Modifier | Organization |
|---|
| 2015-11-09 (Version 2.7) | CAPEC Content Team | The MITRE Corporation | | Updated References | | 2018-07-31 (Version 2.12) | CAPEC Content Team | The MITRE Corporation | | Updated Attack_Prerequisites, References, Related_Attack_Patterns, Related_Weaknesses |
More information is available — Please select a different filter.
|