Pen Testing: Malicious File Execution

Written by Christian Hyatt | Jan 8, 2015, 5:00:00 AM

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?

View full post