How to Fix CWE-73? External Control of Filename, Cybersecurity Jargons

What is CWE 73

CWE or Common Weakness Enumeration 73 is when an unauthorised user gains external access to control a file in your system. CWE provides a standardised language and classification system to help identify, understand, and mitigate vulnerabilities in software and systems.

External Control of Filename or Path is a vulnerability that occurs when an application allows an external entity to influence the selection of a file or directory location within the system. In this scenario, the filename or path is determined by user input, data from external sources, or other untrusted entities.

Attackers can exploit this vulnerability by manipulating the filename or path to gain unauthorised access to sensitive files, overwrite or delete critical data, execute arbitrary code, or perform other malicious actions. This can lead to severe consequences such as unauthorised data disclosure, system compromise, or even complete system failure.

There are two reported CVEs related to CWE 73.

1. CVE-2008-5748

The BloofoxCMS 0.3.4 version has a vulnerability that allows attackers to read any file on the system by manipulating the lang, theme, and module parameters in the plugins/spaw2/dialogs/dialog.php file.

2. CVE-2008-5764

When using WorkSimple 1.2.1 with register_globals enabled, there is a vulnerability in the calendar.php file that allows attackers to execute arbitrary PHP code by providing a URL in the lang parameter.

Examples of CWE 73

Consider this example. Imagine this snippet is a part of the code for your institution’s web application. This code takes your name and loads the data that the institution’s system contains about you, for example.

<form> 
<label for="fileName">Enter Your Name:</label> 
<input type="text" id="fileName" name="fileName">
<input type="submit" value="Save">
</form>

It stores your name in ‘fileName’.
This is the backend Java code that actually accesses the system’s files to look for the data.

public class FileLoader {
    public static void main(String[] args) throws IOException {
        String fileName = fileName;
        File file = new File("I:\YourInstitution\UserData\" + fileName+”.txt”);
        BufferedReader reader = new BufferedReader(new FileReader(file));
        String line;
        while ((line = reader.readLine()) != null) {
            System.out.println(line);
        }
        reader.close();
    }
}

Here, if the user just typed in their name on the website, say Tom Cruise, the file being accessed would be
I:\YourInstitution\UserData\Tom Cruise.”txt”
And your data would simply be displayed.

But since the user input is not being validated and sanitised, a user could type in someone else’s name and access their file. Worse yet, in case a hacker finds out your institution is using a Java Script, they could enter the below snippet instead of a name at all
..\secret-files\confidential.txt

And the file name would be 
I:\YourInstitution\UserData\..\secret-files\confidential.txt

The ../ in the file name represents the parent directory, allowing the user to traverse up the directory hierarchy and potentially access files outside of the intended directory.

By combining ../ with additional directory traversal patterns, an attacker could manipulate the file path and access files in different directories that they are not authorised to access. This poses a security risk and can lead to unauthorised access or exposure of sensitive information.

Mitigation Strategies Against CWE 73

CWE-73, or External Control of Filename or Path, poses significant risks and potential impact on the security and integrity of software systems. By injecting malicious input, an attacker can traverse directories, access sensitive files, or even overwrite critical system files. This can result in unauthorised disclosure of sensitive information, system compromise, data loss, or disruption of services. It is crucial for organisations to address this vulnerability promptly and implement appropriate mitigation measures to protect their systems and data from potential exploitation. Some of the most effective remediation strategies are listed below.

• Mapping 

One effective approach is to implement a mapping system that restricts the input values for filenames to a predefined set. By creating a mapping between fixed input values, such as numeric IDs, and the corresponding filenames, organisations can ensure that only valid and authorised inputs are accepted. For instance, specific IDs can be mapped to specific filenames, such as ID 1 mapping to "Tom Cruise.txt" and ID 2 mapping to "Tom Hanks.txt".

• Sandboxing

Implementing technologies such as the Unix chroot jail or AppArmor can provide this sandboxing capability. By confining the execution environment to a restricted directory, the impact of directory traversal attacks can be limited to that specific directory. This helps mitigate the risk of unauthorised access to sensitive files outside of the designated boundaries.

Good Read: Enhancing Mobile App Security through Sandboxing & Isolation

• Input Validation

Adopting a security mindset that assumes all input is potentially malicious is crucial. Employ an "accept known good" strategy by defining a list of acceptable inputs that strictly adhere to specifications. Reject or transform any input that deviates from these specifications.

When performing input validation, consider various properties such as input length, type, range of acceptable values, consistency, syntax, and conformance to business rules. It is important to validate all relevant aspects and not solely rely on searching for explicitly malicious or malformed inputs. Utilise denylists to detect potential attacks or identify inputs that are so malformed that they should be outright rejected.

Avoid relying solely on filtering mechanisms that remove potentially dangerous characters. Such approaches, akin to deny lists, may be incomplete or prone to errors. For instance, filtering "/" may be insufficient if "\" is a valid directory separator. Additionally, be cautious of filtering techniques that still result in dangerous data. Sequential removal of "../" sequences, for example, may leave behind the "../" string in the remaining characters.

• Testing

At the end of the day, a manual analysis like Penetration Tests is the way to go. Testers look through the eyes of threat actors that could later exploit these vulnerabilities, and find out the level of risk behind them. The records and understanding of the testers after a successful ethical hack can be used to later model an effective automated sieve that only allows benign requests and safeguard your software or website against CWE 73.

Frequently Asked Questions (FAQs)

Conclusion

In conclusion, CWE-73, which involves external control of filenames or paths, poses significant risks to software applications and must be addressed with the utmost attention. Hackers can exploit this vulnerability by manipulating input data to gain unauthorised access to files or execute arbitrary code, potentially leading to data breaches, system compromise, and unauthorised activities.

The potential harm caused by CWE-73 emphasises the critical importance of implementing effective mitigation strategies. By following the recommended measures outlined, organisations can significantly reduce the risk associated with this vulnerability.

Overall, mitigating CWE-73 requires a proactive and comprehensive approach involving secure coding practices, proper input validation, access controls, and continuous monitoring. By prioritising security and following these best practices, organisations can enhance the resilience of their systems, safeguard sensitive data, and protect against external control of filenames or paths.

We know all this may sound a bit daunting, but do not worry. Appknox is the world's most powerful plug-and-play security platform, and our white hat security experts can PenTest your software for CWE 73 among hundreds of other CWEs and submit a comprehensive security report with successful remediation strategies. Book a demo with us to learn more.