Saturday, September 15, 2007

File Intrusion

Threat description: An intruder file is introduced into the hosted web site through an invasive file submission. This threat can be executed very simply through a short HTML form (3lines!). This is a less common but highly impacting attack. Any file of any type can be introduced in this fashion, and unless you have takes specific measures to prevent this specific type of an attack, your web site can be easily breached.

This threat is a multistage attack, with each subsequent step driving the attack further into the web site.

Stage 1: upload the intruder file via the short form

Stage 2: activate the file

Stage 3: retrieve any stolen data (password, client files etc…)

Threat impact if not remedied: Depending on the file type uploaded different impacts can be felt. The file types can range from executables delivering viruses or destroying data through to simple text files with scripts that can further compromise security through password discovery. The damages of this type of an intrusion are limited only by the intentions and creativity of the attacker.

Countermeasure approach: The countermeasures for this type of attack cannot be effectively deployed at the network or host layer. Firewalls and host intrusion detection tools cannot detect this type of an attack as the channel for the attack is a legitimate channel for data flow into the application. The file would flow right through the open ports on the firewall and would march right past host intrusion detection software. The only way to use these tools to protect you would be the blunt approach of screening out all uploaded data and/or files. This would likely constrain the application in question. However if the below described approach is taken then these tools can play a small part in the ongoing remediation.

Instead the countermeasure must be deployed at the application level. This threat is remedied by building a filter on uploaded data. Many websites have pages that allow for data to be legitimately uploaded, so files must be screened. The filter has a predefined sequence of steps is takes to assess the data. The filter will vary by the application and environment it is protecting. It can assess a variety of things from the file source (legitimate server?) though to the content.

As expressed the filters will vary greatly by application but a simple example of the sequence could be;

File acceptance steps:
Step 1) Server source of file inspected – valid server? yes/no

Step 2) Page source is inspected – valid page for file upload? – yes/no

Etc…

Once the file itself is accepted a secondary validation phase can be executed to validate the file type and content;

Content acceptance steps

Step 8) File type acceptable – valid file type? Yes/no

Step 9) File content check – safe content? Yes/no

Etc…

This sequence is one designed to look for reasons to reject the data. Each step is logged and capable of an alert so that immediate severe threats can be addressed, and the logs can later be inspected to ensure no legitimate data is being rejected. The logs are also a useful data source to learn about any ongoing or continued attacks. Tip: If you see a repeated attack from a consistent IP then the firewall can be made more useful by adding the IP address to the blocked traffic list that can be enforced by the firewall.

Lior Izik CEH