Monday, January 22, 2007

File Upload Dangers

Recently I wrote a little bit of ASP.net software to allow our customers to upload files. I set the program to email me a copy of everything to ensure that things are working properly and to track it's usage. Over the weekend someone uploaded a file called "titshell.aspx".

I opened the file in Microsoft Visual Web Developer 2005 Express to see if I could understand what it was trying to do. Only to see what I tought was Russian text (now I think it might be Turkish but to be honest I am not sure). I read trough the code some more and saw a link for titsecurity.com. I went to the web site but was unable to read any of the forums, except for links to screen shots, the file, and a video on how to use it.

Apparenlty (though I haven't been able to make it work) it can create a user, add a user to the Local Administrators Group, Create/Edit/Delete Files & Folders, Delete IIS Log files, Run SQL commands, Disable the Windows Firewall, Enable Remote Desktop, Get System Information (this one works), and upload more files to what ever folder they desire (allowing permissions of course) which is all scary stuff for someone to be able to do remotly.

To test the program out (how could I not?) I tested the file on a Virtual Machine so IF it did work I would have been able to revert back to a working server quickly.

So how do you guard aginst this type of attack?

Easy. NEVER UPLOAD FILES TO A WEB ACCESSABLE FOLDER!

Thankfully Microsoft has taken most of these actions and broken them becuase they rely on admin privleges on the server (Deleting the IIS logs for example). But when I wrote the upload program I told it to store the files in a non-IIS shared folder (some where else on the network). The person that uploaded the file was hoping it would be accessable from the web, which would have allowed them to do anything the program was set to do.

Tuesday, January 09, 2007

Windows Sofware Update Services 3.0 Beta 2

For those of you out there that are using the Current WSUS 2 be warned that 3.0 is coming your way. The good news is that you want this version. If you are still (god forbid) running SUS you will be happy to know that Microsoft has extended it's life until July 10th 2007. You can read more about the extension here.

The feature that I am most exited about in WSUS 3 is seperate metadata and content channels. This means that I can sync my downstream server with the master server in headquarters and download the actual patches from Microsoft. Why might I want to do this? Because we only have a T-1 line to the net in HQ but our branch office has a Cable connection with 5 mbps down. It will be way faster for the branch office to download from Microsoft than from HQ.

Also the API allows for support of "Optional Installations" so I can approve IE7 for my users and those that want it can install it and those that dont want it or cannot use it don't have to worry about it.

The single biggest change in WSUS 3 over WSUS 2 is that instead of a web interface (which also requires IIS to be installed) you can use a MMC to control the WSUS server. The MMC must also be Version 3 on the server and on the client if you want to remotly administer WSUS.

You can read more about WSUS 3.0 here or you can download it here. (After registering for the beta, which ends on January 19th 2007.) Also note that there are two prerequesets for WSUS 3. You will need to have MMC 3.0 installed on your Windows 2003 Server and Microsoft Report Viewer.