Silly Security Scans

One of my pet peeves is users running “Security Scanners” against their servers and treating the resulting report as Gospel…


Oh my gosh, I have to fix all of these vulnerabilities in IIS6 that this report lists! Such an insecure piece of software, this IIS6 is!


… without understanding the basic premises of security for a server. I know, I know, most users do not “get” security because they treat it as a destination which the “Security Scanner” allows them to reach. But, I take solace in that the destination is usually more secure than the point of origin, so I guess that is good. 😉 Like any social lemming, users get a warm-fuzzy feeling of accomplishment at checking off all the check boxes, and security firms capitalize on that. Now, the goal of getting all boxes checked has been accomplished… so is the server forever secure?

Here is an illustrative situation…


During a recent security scan of our IIS 6 box, it was shown that the IIS Version, 6 in this case, and the Internal IP address of the box were being shown externally.

Why would this be and how can I fix this.

The box is natted behind a firewall.


Actually, neither the revelation of the IIS version nor the Internal IP address are security issues. They are really instances of insecurities in the the HTTP protocol itself. What, you actually think that the HTTP protocol is secure? 😉

For example, we all know that Basic Authentication passes username:password around in clear text, so why does IIS allow Basic Authentication without SSL? Because that’s what the specification allows – even though doing it is terribly insecure. We all should know that. Clearly, IIS’s only responsibility is to give you a choice to securely configure your server otherwise (i.e. suggest and conduct Basic Authentication over SSL), but the ability to have such insecure configuration is not an issue to fix.

Internal IP Revelation

If you think about it, this is really a problem introduced by the NAT but not solvable by the NAT.

HTTP Specification allows the return of Content-Location: header (in absolute and relative forms) as well as Location: header (in absolute form) for the benefit of the client and caches, telling the client where the server thinks the resource comes from or where the client should redirect to.

Normally, this is ok because the server’s Name/IP is also the public Name/IP. However, in the NAT scenario:

  1. The server only knows its Internal Name and Internal IP since it is on the Internal Private Network
  2. It is the NAT that translates access to External IP into access to Internal IP (and route the response back out)

So, what happens when the client makes a request that makes the server return Content-Location (via a static file) or Location: (via a 302 courtesy redirection)? Well, the Server only knows about its TCP bindings to the Internal Name/IP and does not know about the NAT, so it is only logical for it to return the Internal Name/IP on those response fields… which is an information disclosure when those responses are subsequently routed Externally by the NAT.

Another way to view the situation is to see that the problem is that the NAT only translates at the TCP/IP level from External to Internal and vice-versa. It fails to translate at the logical HTTP level (or any other higher level) from Internal to External when it NAT’s the request. However, I do not totally blame the NAT because it is nearly impossible for it to provide logical Internal-to-External translation correctly.

Thus, this is really just an insecurity allowed by the HTTP specification. How can the server be secure when it has to tell such information to anonymous clients? The work-around on IIS6 is provided with KB 834141. Basically, IIS gives you a metabase property that allows you to control which string to use, instead of Internal Name/IP, for those revealing Content-Location: and Location: headers. It’s a real hack around the HTTP specification and the NAT, but it is a practical solution.

Server Version Revelation

In the case of the Server: header, HTTP specification’s culpability is even clearer. The specification itself calls out the possibility:

      Note: Revealing the specific software version of the server might
allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable

Great! The HTTP designers saw this possibility and tried to warn implementers, so the fact that IIS has no configuration to not send the Server: header is just proof that Microsoft still does not get security, right?

Well, if you think that hiding the server version actually *improves* security, then think again. Security through obscurity does not work. When doing security analysis, you always assume that the adversary has infinite time, resources, and resiliancy, so even if you hide it, they will find it.

In the case of Server Version, the attacker has other ways to determine it, such as:

  • Making a series of innocuous-looking HTTP requests whose different responses “footprint” a server version
  • Making a series of subtle TCP connections whose different behaviors “footprint” the OS and server version

Ok, playing devil’s advocate… suppose you are able to hide the Server: header and eliminate all “footprints” from external detection so that you keep your server software version a complete secret. Does that make your server more secure against version-specific attacks?

Let’s suppose that you are running a version of server software with a certain known vulnerability which is under active exploitation. Hiding your server version does little good because to obtain the maximum damage, a hacker or worm will simply try the exploit against any server REGARDLESS of version – it takes longer to determine the version than to just send the payload and see if it works.

So, even though you manage through great lengths to keep your server software version a complete secret, you still get automatically exploited if you run vulnerable software. The Security Analysis view of this issue says that you deal with this threat by never allowing the outside world to see your vulnerable software system. Either take it offline, or make sure you are always patched. Running unpatched and obscuring software version is simply a ticking timebomb.

In other words, removing the Server: header does not improve security.

But, it does seem to buy users a nice warm-fuzzy feeling of accomplishment at checking off that check box, so I guess that’s a positive. 🙂 Anyways, the IIS team provides URLScan as an optional tool to do this task (and many other security-conscious tasks).


So, do you still think that:

  • Public specifications like HTTP are secure? When it allows username:password over clear text, anonymous requests, etc…
  • NAT and Firewall is somehow going to protect you when running Server Software? When NAT/Firewall just look at TCP/IP level traffic and offers no defense at the logical layers like HTTP???
  • Hiding Server Software Version helps maintain security? When most exploits simply disregard server version.

Hopefully, this helps to put things into perspective… and how Security Scans may be useful but far from Gospel.


Comments (13)

  1. Phylyp says:

    Nice explanation, especially the part about hiding the server type/version being a waste.

    IMHO, I believe this incorrect assumption stems from another security suggestion (not limited to IIS) – treating usernames as secrets.

    Some security experts suggest taking care not to unnecessarily expose usernames, since that ensures that an attacker has to guess a correct combo of a username (easier to guess) and a password (harder to guess) to break in.

    Although people might equate usernames to server types/versions, this doesn’t really carry over, since the server type/version is a constant.

    To try and use a convoluted analogy: assume I have a lock and 1000 keys. Trying to open the lock with each of the 1000 keys is like trying to crack the password for a known username.

    If I have 5 locks and 1000 keys, the number of tries increases.

    This is the premise of securing the username.

    However, an exploit is more like a hammer – if *any* lock is weak enough (i.e. vulnerable to an exploit) it can be compromised. Doesn’t matter if there are one or five locks, they can all be hammered.

  2. Seems like I&amp;rsquo;ve heard this comment from either management or security groups before&amp;hellip;

  3. David.Wang says:

    Phylyp – yup. Security is about exploiting (and protecting) the weakest link because that is all it takes for exploitation.

    And "security through obscurity" is not real security at all.


  4. Some people block pings too.  So silly.

  5. Robert Moir says:

    This is a nice little circular arguement really.

    Microsoft get beaten up for supposedly not following standards

    Microsoft resolve to follow standards strictly.

    The standards are insecure

    Microsoft get beaten up for producing ‘insecure’ products

    Fixing the "insecurity" requires breaking strict standards compliance

    In the meantime, more problems are caused by genuine bugs all over the place than are caused by the point of arguement in a debate on standards, and more sites get hacked because of idiotic systems management choices than because of incidents with such ‘faux security issues’.

  6. David.Wang says:

    Robert – yup. I just believe in "Doing the Right Thing(TM)".

    We are all human and fallible. Standards are not without flaws nor perfect. Neither is any software organization perfect. People just need to focus on doing the Right Thing (TM) and have faith in the other party.

    Unfortunately, there is a lot of distrust and lack of good will for whatever reason, so silly rules/processes creep in and make it look even more ridiculous.

    And most folks focus on screaming about the problem instead of solving it. It makes for better "journalism". Sigh.


  7. adrian says:

    Try disabling java and run it again. Aparently the internal ip can be exposed  through java even from behind a firewall. No patch as of yet.  

  8. James Ranson says:

    On recent newsgroup, David Wang wrote:

    > IIS team does not consider the Server header a

    > problem and its remove a solution, so there is no

    > built-in feature anywhere.

    I know I’m quite late on this topic, but still thought I’d throw in a few cents since David has mentioned the futility in the removal of the Server header several times here and elsewhere.

    It’s not just about security for me; I deserve to have complete control over every single bit that I’m sending down to a user. IIS inhibits this ability as if I’m not able to judge which headers are important and which aren’t. For instance, on requests to a certain ASPX page, I’d love to be able to check if it’s a HEAD request, and only reply with the Status Line and the Date header. But I can’t. And while obfuscating a header like ‘Server’ may not make me more secure (withholding disagreement here…), it really is an absolutely pointless header to send, and I’d rather not be forced to return it. Header bits are especially problematic because they can’t be gzip compressed like the http body. That problem gets multiplied when things like the Server header, aspx session cookies, etc., are sent down with every object on a page including static images. That is just plain silly. Why does my browser need to know the domain’s webserver class 50 times per page? Why do my static image requests need to receive a session cookie in the response? You can solve the session cookie issue by cnaming a different subdomain for images, but that’s really using the DNS infrastructure to work around a webserver deficiency. Take for instance an environment like mobile web, where some customers are charged by the Kilobyte; every byte counts and these headers just cost customers for useless, unrenderable data, and put money into the wireless providers’ pockets. So it is really a shame that there’s no way to natively configure IIS to not send down specific response headers at the directory or request level. While a third-party ISAPI filter works, it’s really suboptimal since it’s stripping a nuisance header that’s already been added against my will. There should be a native way to control which headers are set in the first place, and the reluctance for Microsoft to allow that is really an insult to any developer and sysadmin with a modicum of proficiency.

  9. Someone who actually works in security says:

    Well – some people would argue that given microsoft's history of security vulnerabilities in IIS and the common availability of 0-day attacks makes it much easier to construct worms which can quickly rely on server header information to propogate. Seeking server headers is much of a smaller payload on network traffic than blatemly attempting to just exploit every host regardless if it applies…so while removing the header doesn't "secure" the box, its just another step in a defense-in-depth strategy.

  10. Michael says:

    Your last point about most exploits disregarding server version is incorrect. Given the server version I can go onto sites such as and get a nice list of exploits that may be applicable to that version.

    As for the first two points.

    1: Nobody thinks HTTP is secure.

    2: That's not the purpose of NAT & a Firewall so it's not really relevant.

  11. Eric Wilson says:

    "Well, if you think that hiding the server version actually *improves* security, then think again. Security through obscurity does not work. When doing security analysis, you always assume that the adversary has infinite time, resources, and resiliancy, so even if you hide it, they will find it."

    I used to quote crap like "Security through obscurity does not work" then a security professional pointed out to me that when a serious security flaw is publicized the first things the script kiddies do is google for it and using the proper techniques it would take under an hour to build a list (powered by google) that builds a database of all sites known by google with a header of X value.  They then just feed that database to an automated routine that churns through them all.  So sure security through obscurity doesn't "secure you" but if more often than not it buys you a few extra days to apply a patch then common sense dictates you should just do it.

  12. Ian says:

    Apart from disconnecting altogether, Isn't all security ultimately a matter of obscurity?

  13. Eric says:

    While useless for accomplished hackers,  hiding unessary header info may discourage some wannabe weekend hackers from vandalizing websites.   Managing security is about knowing the risks and mitigate them and more particulary knowing how efficient a security solution is.   Taken all separetly,  each individual security solutions has become weaker thru time.   Put all togheter you can get a potentially more interresting global solution.  But quite sincerly no one should assume being out of danger at any time anyways, whatever solutions are in place.

    This subject is really a debate as 50% are for removing headers,  40% can't see why and 10% are litterally against.   While the one against can't really tell a good reason not to do it,  other than saying "it's a waste",  why not doing it then ?