Microsoft Techdays 2010 - Day 2

A big surprise at Techdays 2010 was Microsoft promoting Terminal Server as part of their virtualisation strategy. The technology was most prominent towards the end of the 1990s with Citrix leading the way. The idea is to have a thin client on your PC to access applications that run on a powerful central server, more or less like a mainframe and a terminal. Although terminal server never went away, indeed is has been integrated into Windows Server since the 2000 edition, it was never quite as successful as expected. A variant of course is used as the principle remote administration method for Windows Server products.

Back in the 90s using Citrix or Terminal Server would normally have been for performance reasons allowing low specification clients to access resource hungry applications even over poor network links. It of course makes perfect sense to use this technology for security as you can run applications that pose a risk to the PC, (e.g. anything that requires IE6) in an isolated locked down session. The reverse is true as well. For example, you could run a sensitive application in a terminal session and reduce the risk of damage if the end PC is infected with malware.

After a couple of sessions on IIS 7, I do wonder if Microsoft have made a mistake here. On the surface, it looks great, but even a couple of the experienced Microsoft IIS7 support team seemed to have trouble getting it do what they wanted. Their frequent use of IISRESET after an unexpected error did not inspire confidence.

To Bug or not to Bug

An IIS bug reported towards the end of last year brought an abrupt response from Microsoft. According to the Register, Microsoft acknowledge that the bug exists in IIS 6 but claim that it doesn’t present a risk as you would need to be running your Web Server in an insecure configuration for it to be exploited. Umm, that’s alright then as we all know that everyone runs their applications in a secure config.

The vulnerability arises because of the way IIS6 parses semi-colons. If you had a file called badcode.asp;.jpg, everything after the semi-colon would be ignored and the web server would process the file as if it were called badcode.asp. The end result in this case would be that the file is processed on the server and not the client.

How could this be exploited in the real world? Consider that many sites allow anonymous users to upload documents to a webserver. This could be in the form of a photo or a CV. In order to stop malicious users uploading harmful content there would normally be a filtering process in place that would block files of type .exe, .asp etc. However, if the user were to append ;.jpg or ;.doc to their file the filtering process would be bypassed and the file uploaded to the server. If the file resides in an accessible web directory with script execute permissions, any user can execute the file.

Microsoft rightly point out that you would be foolish to allow uploaded content to be available from the web especially in a directory with execute permissions. Best practise would also not allow the end user to choose their own file names. Personal experience however suggests that best practise is not always followed. Given that IIS may occupy 21% of the entire web server market, I would be confident that some fairly high profile sites could be vulnerable. The worst case scenario would be something like a bank being exposed to the bug. It could lead to the ultimate phishing scam as malicious code would be authenticated and encrypted by a valid SSL certificate.