Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

prevent disguised exe file upload

Status
Not open for further replies.

struth

Programmer
Aug 26, 2001
114
0
0
GB
I need to prevent people uploading exe files. I presently use aspupload. However there are users who are changing the extension name to for example '.doc' and then downloading it to a target computer and changing the extension back ....

Does any one know of any software or anti-virus that examines the upload to see if it is a disguised exe file and prevent it?

TIA

Struth

Away from the actual ... everything is virtual
 
They are changing the extension, uploading to server, then downloading to another computer, then renaming the extension?

Seems like a roundabout way to move files. What are you worried about? What is the vulnerability or liability to you?
 
Perhaps if there are only a few acceptable file formats then you could examine all uploaded files and reject those that do not match these formats.
 
Called into meetings all day yesterday .... so first chance to reply.....

There is no vulnerability or liability to me but within this extranet I have been asked to see if I can help prevent it.

There are only a few file formats accepted including image ones and pdfs, word docs and access dbs. The question was more how I might achieve this.

Thanks

Away from the actual ... everything is virtual
 
The question was more how I might achieve this.

From the server side uou can't really prevent someone attempting to upload a renamed file but you could examine the file after it is uploaded but BEFORE you make it available for downloading. This is only really feasible when there are a limited number of file formats acceptable.

The clean way to do it would be to find the specificiations for each format and then check all of the files.

A quick and dirty way to do it would be to dump all uploaded files into some folder on the web server that is not accessible via the web site. Then you'd have a separate process that polls this folder and attempts to open each file in the host program dictated by its extension... if an error occurs then trash the file... if it opens OK then move it to another location where it is available for downloads.
 
Sheco, can he examine the ContentType of the file to see if it matches? Would a ContentType value return the true type of the file regardless of the file extension? I am not familiar with ASPUpload but I think this should be possible, even before the file is uploaded.

I assume that ASPUpload uses a type="file" field to allow browsing to and selecting the file to upload and set's the form enctype to multipart/form-data. If so then the files object is passed in and the ContentType property can be examined even before the script transfer the file up to the server.



It's hard to think outside the box when I'm trapped in a cubicle.
 
Thanks guys...


The clean way to do it would be to find the specifications for each format and then check all of the files.

Where/how would I discover such specs and then run a matching application

I assume that ASPUpload uses a type="file" field to allow browsing to and selecting the file to upload and set's the form enctype to multipart/form-data. If so then the files object is passed in and the ContentType property can be examined even before the script transfer the file up to the server.

It does use 'file' etc but again would asp or even javascript be able to carry out such an examination?

Away from the actual ... everything is virtual
 
Look at your upload code, it should have a section where it declares all of the custom functions for dealing with the binary file and one of them should specifically look at the contenttype. If you find it then you can call that function to get the type and compare it against a list of allowed types before allowing the upload to go through.
I cannot be specific about code I have not seen but I would think the ability is there and if not, have a look at the below link as it does have a function to return the content type. When I upload files into a database I store the content type as another field in the database to make it easier to determine how to deal with the file in other applications.



It's hard to think outside the box when I'm trapped in a cubicle.
 
I believe the problem is that the user is intentially disguising the uploaded file.
 
Disguising it yes, by renaming the file. My question is, does the contenttype alter based on the filename. I suspect the contenttype is part of the binary file so no matter what the filename states the contenttype property discloses it's true type and can be used to block the upload before it copies to the server.

I can give it a test with my own upload code.


It's hard to think outside the box when I'm trapped in a cubicle.
 
OK, here are my test results.

I created a text file and saved it under the name test.txt and test.exe and uploaded both copies.

I took a .exe file (call it exetest.exe) and made a copy called exetest.txt and uploaded both.

I took a word document test.doc, copied it and renamed the copy to test.txt and uploaded both.

Here are the results:
Plain txt file with txt extension = ContentType text/plain
Plain txt file with exe extension = ContentType text/plain

Exe file with exe extension = ContentType application/octet-stream
Exe file with txt extension = ContentType application/octet-stream

DOC file with DOC extension = ContentType application/msword
DOC file with txt extension = ContentType application/octet-stream

So apparently the ContentType is primarily a function of the data inside the file. The only exception was the Word document named as TXT and it reported the txt version as if is an application file anyway so it is still a viable way to filter out unwanted file types.

If the ContentType comes out as application/octet-stream you probably do not want to allow it to upload if no applications are allowed.

Of course tests would have to be done on other types of executables like .vbs and .bat files as well.

I guess the biggest question is, why does the average joe have the ability to rename files stored on the server?


It's hard to think outside the box when I'm trapped in a cubicle.
 
no, they rename some file like HackedWarezSetup.exe to something else like instructions.doc

then they upload it to the site

then they IM their little pirate friends letting them know the fake name of the file.

 
First of all ... big thanks for your input.

I have run my own tests and found that if they rename an 'exe' to 'doc'(the most common) it is reported as msword... shame!

'The average joe' does not have the ability to rename their files on my server ... the problem arrives when they download it to their target server and rename it OR do as Sheco suggests. So far nothing tooooo malicious has been carried out but I would like to close the vulnerability.


Away from the actual ... everything is virtual
 
Some of my clients use Outlook Express. It does a great job of blocking absolutely everything I want them to receive, regardless of whether I zip it up, rename the extension, or whatnot. I can never send .mdb files, for example.

How is Outlook Express so smart to sniff out the type of file?

Could you open up a sample of allowed filetypes in a text editor and find a header key, then parse each upload looking for that key in an array of allowed keys or something?
 
The question then is how does the extension alter the reporting of the ContentType? In my tests the only time the extension played a part was when the extension was .doc it reported as msword but when changed to .txt it reported as octet-stream. Since renaming the file does not alter the content of the file the OS must somehow be re-interpreting the ContentType when it sees certain file extensions. If true then there may be a way around that.

Even if you find a way to filter by ContentType though you still have the problem with files that are compressed or otherwise encoded like with UUEncode so they come out as raw text files or even get stored as UUEncoded text stored in a .DOC file.

There are so many ways around the filtering it may not be reasonably worthwhile to try filtering. Or perhaps there is a commercial app that does a much more intensive investigation on incoming files.


It's hard to think outside the box when I'm trapped in a cubicle.
 
The contenttype is sent by the browser.

It sounds like the browser is only checking the file extension.

Theorhetically the browser could do a more exhaustive examination of files to be uploaded... but isnt that really outside the scope of what a browser is supposed to be doing?

ps: many organizations do virus scans on all email attachments... a virus scan actually examines files at the byte level and looks for known patterns... if you are going this far then it is simple to check for file formats because they also follow known patterns. you can defeat these filters by using something a little less common than ZIP for the encryption...
 
I think I may have found what I need. It is from motobit (I already use their iistracer). This may give me exactly what I need ... but I shall have to trial it first.

The file type function (adaptable for my ends):

The upload app itself.

I will report back my findings.

Thanks again.

Away from the actual ... everything is virtual
 
I just hope the uploaders don't encrypt their zip/rar files or embed the naughty file inside an MS Word document, or even into Steganography...

But the steps you are taking should deter the casual rogue user at least.

Good luck with it.

A smile is worth a thousand kind words. So smile, it's easy! :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top