Multiple extension vulnerability. Is this malicious file triggered during form preview or after it has been uploaded?

Question

I'm looking at one of our compromised web server logs and we found that an attacker has uploaded a file with multiple extension. Below is the IIS log. The log format are as below. I have removed the cookies and user agent values as they are a bit long and irrelevant.

#Fields: date time cs-uri-stem cs-uri-query c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) sc-status sc-substatus sc-bytes time-taken 

One of line, we found this log

2012-03-09 02:49:16 /preview.asp path=./submit/file_20120222_ext_20120309_1049.asp;_20120309_1049.jpg&width=300|17|80040035|Not_a_JPEG_file:_starts_with_0x3c_0x25 xxx.xxx.xxx.xxx HTTP/1.1 - - http://xxx.xxx.xxx.xxx/mail.asp?err=2 500 0 471 203

then on the following line, we found the following log

2012-03-09 02:51:03 /submit/fle_20120222_ext_20120309_1049.asp;_20120309_1049.jpg - xxx.xxx.xxx.xxx - - - 403 1 1918 0

Does anyone have any idea if the malicious file is triggered in line 1 of the log or line 2 of the log?

Answer 1

This attack would require two requests, one to upload the file and another to execute it. It appears as though the 2nd request is attempting to execute the uploaded payload. My guess is that the first request is generated by the normal function of your application and is likely not the request that uploaded the file.

In any case you should try replacing that uploaded file with a hello world and try replaying these requests from your log. Also make sure to manually audit the code responsible for file uploads.

Answer 2

It seems that there are several vulnerabilities in play here.
First of all, that the ASP handler is even active on your webserver! ASP is long obselete, and really considered quite insecure. I recommend you disable that ASAP.

Second, this preview.asp page. What exactly does this do? I would guess that it downloads a file for you, is that correct? If so, and there are no real restrictions on what file it can download, you have some bigger issues. Or it might just be a redirect, in which case this issue is a bit smaller....

Third, apparently someone, somehow uploaded an arbitrary file, into the a subdirectory of the web root. This is already a big hole, see also this question and this one. Seems they were even able to specify an exploitable filename....
How long is your server out of date? I dont think even current versions of the ASP handler are susceptible to this, but regardless you should not be allowing arbitrary filenames.

Lastly, was the final exploit of the already loaded attack, requesting the actual uploaded file - which of course contains arbitrary code to be run on the server.