Log in

Site menu:



Site search

April 2019
« Dec    



Banners Are Poor Liars

In response to a risk assessment and security audit being performed by one of the proliferating lot of peddlers of such services, a friend recently asked my position on obscuring the banner on our application platforms. This “best-practice” of concealing the true identity of web and FTP servers, SMTP engines, et al, has been around for some time, built on the premise that the less an attacker knows about a target, the less specific and effective the resulting mounted assault.

This logic is certainly true in the event of targets with known, exploitable vulnerabilities. For example, advertising “220 ESMTP Sendmail 8.6.1/8.5.0” (unless it’s a honeypot) is probably inviting trouble. But if the server is well-maintained and fortified by both the producer (vendor, author) and employer (implementer, admin), then the attack surface is minimal. One might even go so far as to argue that advertising up-to-date versions of platforms with relatively unblemished reputations might even serve as a deterrent to less ambitious attackers.

Responsible and diligent maintenance and hardening of publicly accessible interfaces will always provide more legitimate security than dissemblance, both against large sweeping recon scans, and particularly against targeted probing. After all, criminals tend to be an untrusting lot, so why would they believe what a banner tells them, especially when fingerprinting tools like HTTPrint and SMTPScan are so readily available?

Rather than relying solely on the information provided in a banner, application fingerprinting tools try to induce predictable responses, behaviors and patterns in their targets so as to make an educated guess about the engine. At first this might seem a lot like the OS detection feature of NMAP, which relies on certain platform specific TCP behaviors. The difference, however, is that most TCP/IP stack authors got wise to the way this predictability was being exploited, and began to introduce elements of randomness within TCP’s tolerance, largely neutering the effectiveness of TCP-based OS detection. Unlike the sort of flexibility afforded to TCP stack authors to add randomness, application authors are generally strongly bound by parameters, syntax, and behaviors.

A few examples of the ineffectiveness of obscuring HTTP banners:

The web server advertises itself as “KONICHIWA/1.0”, but HTTPrint rather confidently detects it as “Netscape-Enterprise/6.0”:

C:\temp\httprint_win32_301>httprint.exe -P0 -h -s signatures.txt
httprint v0.301 (beta) – web server fingerprinting tool
(c) 2003-2005 net-square solutions pvt. ltd. – see readme.txt

Finger Printing on
Host Redirected to https//
Finger Printing Completed on
Derived Signature:

Banner Reported: KONICHIWA/1.0
Banner Deduced: Netscape-Enterprise/6.0
Score: 105
Confidence: 63.25

My Qwest provided DSL router advertises its web server as “-“, but HTTPrint claims it is “thttpd”, and telnetting into busybox on the device confirms that:

C:\httprint_win32_301>httprint.exe -h -s signatures.txt
httprint v0.301 (beta) – web server fingerprinting tool
(c) 2003-2005 net-square solutions pvt. ltd. – see readme.txt

Finger Printing on
Finger Printing Completed on
Derived Signature:

Banner Reported: –
Banner Deduced: thttpd
Score: 83
Confidence: 50.00


BusyBox on (none) login: admin
BusyBox v0.61.pre (2006.07.03-16:17+0000) Built-in shell (ash)

# ps waux

PID Uid VmSize Stat Command
1 admin 1320 S init
44 admin 1228 S /usr/sbin/thttpd -d /usr/www -u root -p 80 -c /cgi-b…

So why don’t more application/server platform developers turn the tables on the scanners by looking for predictable scanner behaviors and modifying accordingly? There’s already evidence of this in some IPS platforms which can detect the fingerprints of well-known scanners (such as NMAP’s use of the WNMTE TCP options, or Netstumbler’s probing idiosyncrasies, etc.) But, alas, if this begins to happen widely, the better scanner-authors will just introduce their own trickery… typical arms war stuff which, on a positive note, warrants a mention of ModSecurity for its ability (among many other things) to defend against HTTPrint.

I’ve managed to avoid the use of the “security through obscurity” catchphrase to this point, but I will close with it. One instance where obscuring a banner could be useful is between that period of time when an exploit is discovered and when it is remedied. Again, if the platform’s producer and employer deserve their jobs, the window of exposure should be so small as to be virtually statistically unexploitable, particularly if additional defenses such as dynamically updated Unified Threat Management is in place. But it would still not hurt to conceal the vulnerability from the unlikely event of detection by superficial banner grabs during this short window (concealing entire login screens is a different matter). As such, we’ll provide banner configurability on our platforms in future firmware releases.

Security cannot be achieved through obscurity, but obscurity can be a piece of the bigger security picture.

Share: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Twitter
  • Reddit
  • Slashdot
  • LinkedIn
  • Facebook
  • email
  • Print


Comment from adaswani
Time: 2008-02-13, 15:56

I still don’t get the conclusion – a determined adversary would bypass superficial banner grabs anyways, and resort to other reliable means as you pointed out. Obscurity as a piece of the bigger picture might help deter the unsophisticated adversary, but not the determined one. The conclusion assumes that the underlying information is only as valuable as to be reasonably protected by obscuring a banner display.

You must be logged in to post a comment.