IIS exploits in Windows Server and how you can fix them

I believe it's safe to say that a common goal of Windows server administrators is to have reasonably resilient systems. There's a lot going on in the world of online security threats. The last thing you need is someone on the other side of the world, or internal to your organization, exploit something in IIS or Windows server that could've been prevented.

Your hands may be tied in terms of application-specific flaws but there's plenty you can do at the server level to make your IIS-based systems more secure. In reviewing my Web security assessment projects over the past year, here are the top IIS vulnerabilities afflicting Windows servers:

Unhandled exceptions (HTTP 500 errors) are generated.
This can disclose sensitive configuration information and facilitate SQL injection. The server-side fix is to disable detailed error messages via the following in the server's web.config file:

<customErrors mode="RemoteOnly" defaultRedirect="AppErrors.aspx">

<error statusCode="404" redirect="NoSuchPage.aspx"/>

<error statusCode="403" redirect="NoAccessAllowed.aspx"/>

<error statusCode="500" redirect="RequestNotAllowed.aspx"/>

</customErrors>

Viewstate parameter encryption and MAC are disabled.
This can allow an attack to manipulate sensitive parameters and gain unauthorized access. The server-side fix is to enable viewstate hashing and MAC on all pages of the application via the following to the server's web.config file:

<system.web>

<pages viewStateEncryptionMode="Always">

<pages enableViewStateMac="true"/>

               <machineKey validation="3DES"/>

</system.web>

Unencrypted HTTP connections can be made.
This can lead to the exposure of login credentials and other sensitive information because everything to and from the Web server is transmitted plaintext communications. The server-side fix is to require TLS version 1.1+ encryption across the entire website/application.

SSL versions 2 and 3 and weak encryption ciphers are enabled.
This can facilitate man-in-the-middle attacks and lead to the compromise of sensitive information. The server-side fix is to require TLS version 1.1+ and disable weak ciphers such as RC4.

Cross-frame scripting is possible.
This can facilitate clickjacking and trick users into clicking on something different from what they perceive they are clicking on. The server-side fix is to set the X-Frame-Options header to DENY, SAMEORIGIN or ALLOW-FROM based on your specific needs.

Sensitive server directories and files are publicly-accessible.
This can expose system configuration, code or sensitive data. The server-side fix is to ensure that only the necessary permissions are enabled for public access.

Windows patches are missing.
This can lead to anything from denial of service to full remote access to the Web server using a tool such as Metasploit. The server-side fix is to patch your servers. It's that simple. Even if you're concerned about taking production serverspatching needs to be performed consistently across th board if you're going to have a secure Web environment.

Most of these vulnerabilities may not be considered "critical" but they can certainly be problematic long term. As you can see, they're relatively easily to resolve. In fact, the only thing it will cost you to fix them is your time. Find and fix these issues -- they're easy security wins for your business and will help keep your vulnerability scan and security assessment reports as clean as possible.

Once you tackle these website security server fundamentals you can more on to bigger -- often more complex -- security flaws within your Web applications themselves. This includes everything from cross-site scripting (an all too common vulnerability) to SQL injection (a less common yet lethal flaw) to weak user authentication and session management. That's where the real fun begins.