What is a Malicious File Execution Vulnerability?
Malicious file execution vulnerabilities (also called File Inclusion Vulnerabilities) is a vulnerability that occurs due to user input or uploads to websites not being properly handled or poor data validation by the website/web application.
Web applications that are poorly designed or coded may automatically run or parse input that is inputted from a user. If that input is a a malicious file or pointer to a URL that will execute a malicious script or command at the server level the application has been successfully hacked.
A Simplified Example of Execution of a Malicious File
In this example, suppose there is a website that allows you to upload a picture and share it with friends.
Imagine this website is programmed using the server-side scripting language, PHP. The developer is a novice and inexperienced with many of the security principles surrounding the language but the web app is programmed to only accept popular image types like .JPG, .GIF, and .PNG.
His web app is developed to use the global variable $_Request to get the user submitted image then uses that image as part of the input to another PHP function.
The attacker concacts a simple PHP script to list all the contents of a directory on the server to gain more information and formulate another attack:
The attacker now renames the .PHP file to a .JPG file, easily skirting the rudimentary data validation implemented by the web app then uploads it to the web app to be executed.
Risks Associated with Malicious File Execution Vulnerabilities
The potential risks associated with the execution of malicious files varies greatly. Attackers can exploit these vulnerabilities with a number of different goals including but not limited to:
- Uploading a phishing page into a website
- Uploading and covertly hosting malware, illegal software and other objects.
- Storing malicious scripts or a stored Cross Site Scrip (XSS) file.
- Gaining control of a web server, modifying it’s file structure or taking it out of commission completely.
Preventing and Testing for Malicious File Execution Vulnerabilities
Preventing malicious file execution vulnerabilities starts in the design phase of the application. Java developer and security blogger John Melton wrote a great post that gives a great rundown of factors to be considered.
Common Design Issues | Description |
| Insufficient Input Validation: | Too much freedom naming files and not scrubbing names correctly for special characters could lead to directory traversal and overwriting system files. Could disrupt operation of entire web server. |
| No Virus Scanning | All uploaded files should be virus scanned. Failed scans should remove files and security incidents logged. |
| No Size Checks | Reasonable file limits should be set, determined by the type of files being uploaded (e.g. spreadsheets VS video files). |
| Invalid File Type Processing | Only accept file types relevant to what the expected upload is (e.g. don’t allow .doc files if an image file is expected). |
| Direct Object Reference (DOM) Problems | DOR is an issue where the actual filename is pointed to directly. |
| Not Authorizing Access | Once a user is authenticated, many times they can perform any function in the application. Extra attention should be given to user authorization and permissions as well. |
Considerations for the Auditor
As an auditor, you are unable to dictate how applications should (or should have been) designed and coded, but there are quite a few safeguards and best practices that the organization should have in place to secure web applications and adjacent applications and infrastructure.
- Isolate web servers either physically or by VLAN. Systems located within other VLANs and subnets should NOT be allowed to traverse the network to production web servers. Preferably, access to the web servers should utilize a bastion host or jump server.
- Verify that firewalls protecting web servers are configured with default Deny All rules for both incoming and outgoing traffic and that web servers are prevented from making new connections to both external and internal systems.
- Verify that Information Security is part of the official SDLC and that developers and PMs adhere to the SDLC.
- Verify that effective penetration testing has been performed, and identified issues have been addressed.
- Verify that an antivirus solution is implemented and kept up to date and that all appropriate software, OS and security patches have been applied.
- Review process, user and program permissions and verify that the Principle of Least Privilege in in play, meaning that the minimal amount of privilege/authority is given to each module/component of the environment.
- Review web server configuration files to verify only needed services and features are enabled/installed on the web server (with the goal being to minimize the attack surface).
PBC Requests:
- Network topology diagrams.
- Relevant firewall and router ACL rules.
- The systems development lifecycle documentation.
- Periodic penetration testing results and reports.
- Evidence of antivirus software implementation and evidence that virus software and definitions are kept up to date.
- Software security patching policy and evidence that the plan is in place and systems are regularly patched.
- System generated listings of process, user and application permissions outlining the permissions granted to each module in the system.
- Change management documentation to show that malicious file executions are a consideration during the QA/QC process Further, you could request to inspect a sliver of source code, demonstrating where an issue was addressed.
- Web server configuration settings.
Are we missing anything?
Thanks guys. Your blog is very useful for someone new to the IT Audit world. Keep up the good work.
Another great article, but I would disagree with the notion that auditors can’t dictate – or rather impact how applications are designed and developed. Our focus should be on ensuring applications are developed securely from the beginning. And that goes beyond the basic SDLC. The application development group should be following secure coding techniques that are enforced through numerous code reviews by as many people as possible. There are also Secure Code Analysis Tools that can be leveraged to further validate secure coding. Finally security scanning or penetration tests should be conducted as code is developed and migrated through lower environments. You don’t want to wait until your code is in production before you conduct your first pen test. I think you alluded to some of these points in your post, but I would be more forceful in the notion that we as auditors can influence the development process.
Steve,
Thanks for the amazing response. I may update the post with your points. Just not sure what my and my co-author’s perspective is on doing that at the moment.
I’d be interested in knowing what capacity you work as an auditor. I think I see it as I am unable to dictate how development is done because I am always an external party working for internal audit, limited to created process improvement memos after my review is complete.
I guess if I were part of the internal audit team as a full time employee, or Info Sec management, then yes I completely see your point.
@Shane @Steve –
From an internal audit perspective I think Steve makes a great point. Getting involved early and often, from a consultative and risk mitigation standpoint, is a plus.
For example, on one project a client was implementing a self service password reset option and we walked through the risks and solutions prior to development. We ultimately settled on a dual authentication (email + text) solution.
@Shane
My auditing career (11 years) has been exclusively on the Internal side. I’ve also spent a few years in IT including application development. As a side note – I highly recommend IT auditors or auditors in general spend some time in the operations to round out their perspective.
My approach in the past has been to evaluate the overall application development process to ensure a solid framework exists, including secure coding, code reviews, and testing, and it is applied to all development projects. Of course there may be some variances for external vs. internal facing applications. Then as Christian noted, I would monitor development activities as part of any high profile project. A project audit will cover a wide array of activities including project management, financials, and customer communications as well as development. Unfortunately, when projects run low on funds or long on schedule, development and testing efforts tend to be the first that are squeezed.