ColdFusion Muse

Iframe Injection Follow Up

Mark Kruger April 21, 2009 11:29 AM ColdFusion, Security Comments (5)

For those of you who have been following the Iframe injection attack saga (see Iframe Insertion on Index.* Home pages) I have an update. I would like to thank one of my readers named Kumar for referring me to this excellent article (a PDF File) on Black Hat. The article seems to pinpoint the origin and nature of the attack. The document describes an attack in depth with multiple steps (just as we had speculated). The first step was an SQLi attempt. But failing that the attacker compromised the server in a rather ingenious fashion.

  • Using an image upload capability he uploaded a file to the server that "looked" like an image but was not.
  • The file (containing executable code) was then hit with GET and POST requests.
  • The payload of the get and post requests was able to set up scheduled tasks to append the JS code to "index.*" files on a timed basis.

This file that was uploaded was a CDX file. On a properly configured IIS server this attack would fail to succeed. Here's why.

All That Useful Stuff

When you install Windows (and now days even some Linux installs have this problem) the installer wants you to feel like you have received your moneys worth. Consequently, the default install of Windows includes a boat load of features that you do not need and should remove. For example, did you know your server has a print spooler service? It's probably running right now. How often do you actually print from your server? If you don't need it, you should disable it - but make sure and turn off the errors in the print folders "server properties" area advanced tab first or your log file will fill up with silly errors (Oh Windows you mischievous thing you...).

One of the "installed by default" features in IIS are the "configuration mappings". You have probably seen these mappings if you have ever had trouble with getting your IIS web site "connected" to ColdFusion. By default IIS contains many mappings that are never used (probably by anyone). On a Windows 2000 server the screen looks like this:

On 2003 it looks like this (very similar):

In the case of our exploit the user was able to use an image uploader to put a file on the server with a CDX extension. The file header indicated that it was of the "type" gif, so the uploader accepted it as a valid image file. I'm not sure if this is unique to CDX files (I'm not sure if you could do the same thing with an "ASP" file for example). IIS has a mapping for CDX that tells it to use the ASP.dll to parse the file. So our too clever hacker uploaded a file that the uploader took to be a gif but was in actuality an ASP script. Once on the server the attacker used HTTP to send POST and GET requests to the file delivering payloads that searched for other vulnerabilities (like the ability to open a command shell for example). So once this file is on the server and able to be served by IIS from the web root, all bets are off.

2 Tips

One thing that would have prevented this attack would have been locking down IIS after install and before sites were added. When I do a new windows install I removed everything from the config tab except what I know the server will need explicitly. In particular these extensions serviced by the classic ASP technology need to be removed (cdr, cdx, htr, cer).

Secondly, if you have an application that accepts files from users you should be filtering them to insure that they are appropriate for type and extension (for example using the "accept" attribute of the cffile tag). Probably even more important however is that you not serve these particular files in a way that they can be executed on the server. For example, you can use CFCONTENT to serve the file. You could also use a separate domain ( etc) for your user content, and configure this new domain to not have permissions to execute scripts. Here's an article from security focus giving more information on the topic of securing IIS and Windows. FYI - the use of IIS Lockdown would probably have blocked this extension.

  • Share:

Related Blog Entries


  • TJ Downes's Gravatar
    Posted By
    TJ Downes | 4/21/09 12:16 PM

    Thanks for the tips! It's good to see others sharing this sort of info.

    I would suggest that the majority of security breaches occurring on IIS are due to misconfiguration of the server or the lack of a proper security audit, and not removing those things which are not needed on a production server. I think many people just assume that an OS is by default locked down, which is not the case with Windows historically. Windows 2008 is getting much better in this regard, but it is still good practice to know what is installed by default and what needs to be done to lock down the server.

    Here's what I believe: "If I know it won't be needed, it's gone. If I don't know what it is I research it to determine if it's needed or not and what sort of security issue it might represent.". Using this as a guideline I am happy to say that my IIS servers have never been compromised.

    That being said, there's a ton of knowledge required to learn how to operate an IIS server securely, and it's an aspect that you will never stop learning about if you are serious about properly operating and maintaining a secure IIS server.
  • JC's Gravatar
    Posted By
    JC | 4/21/09 1:47 PM
    "FYI - the use of IIS Lockdown would probably have blocked this extension. "

    IIS lockdown only works for IIS 4 and 5, so if this happened on 2003, it wouldn't have helped. But locking down IIS would, certainly...
  • duncan's Gravatar
    Posted By
    duncan | 4/21/09 5:25 PM
    Just to clarify, had the user uploaded the CDX file using a <cffile action="upload" accept="image/gif"> ?
  • mark kruger's Gravatar
    Posted By
    mark kruger | 4/21/09 5:33 PM

    No.. in the example given by the blackhat analysis the vulnerability was in an ASP file uploader. But having said that, I have no reason to believe that CFFILE would not simply accept the file as if it were an image based on the erroneous header information contained within the file. I suspect CFFILE would be vulnerable.

    But keep in mind that the vulnerability here is assumed anyway. IF you allow users to upload stuff to your server AND you serve whatever they upload to a browser, then you had best take steps to make sure whatever they upload is safe. The type attribute of cffile would only be one way of checking possibly malicious content.
  • Jonathan van Zuijlekom's Gravatar
    When using IIS only to serve CFML pages and static content, so no ASP(.NET), just prohibit every "Web Service Extensions" except the "Macromedia Server Entensions" in the IIS management console.