illurity-logo
Log in

Site menu:

Categories

Tags

Site search

September 2018
M T W T F S S
« Dec    
 12
3456789
10111213141516
17181920212223
24252627282930

Links:

Archives

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 mail.wherearemysocks.com 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 www.wellsfargo.com 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 www.wellsfargo.com -s signatures.txt
httprint v0.301 (beta) – web server fingerprinting tool
(c) 2003-2005 net-square solutions pvt. ltd. – see readme.txt
http://net-square.com/httprint/
httprint@net-square.com

Finger Printing on http://www.wellsfargo.com:80/
Host Redirected to https//www.wellsfargo.com:443/
Finger Printing Completed on https://www.wellsfargo.com:443/
————————————————–
Host: www.wellsfargo.com
Derived Signature:
KONICHIWA/1.0
9E431BC86ED3C295811C9DC5811C9DC5811C9DC594DF1BD04276E4BBC184CB92
7FC8D095AF7A648F2A200B4C811C9DC5811C9DC5811C9DC5811C9DC52655F350
FCCC535B811C9DC5FCCC535B811C9DC568D17AAE2576B7696ED3C2959E431BC8
6ED3C295E2CE6922811C9DC5811C9DC5811C9DC56ED3C2956ED3C295E2CE6923
E2CE6923FCCC535F811C9DC568D17AAEE2CE6920

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 192.168.0.1 -s signatures.txt
httprint v0.301 (beta) – web server fingerprinting tool
(c) 2003-2005 net-square solutions pvt. ltd. – see readme.txt
http://net-square.com/httprint/
httprint@net-square.com

Finger Printing on http://192.168.0.1:80/
Finger Printing Completed on http://192.168.0.1:80/
————————————————–
Host: 192.168.0.1
Derived Signature:
811C9DC5811C9DC5811C9DC5811C9DC5811C9DC594DF1BD04276E4BB811C9DC5
0D7645B5811C9DC5811C9DC5CD37187C811C9DC5811C9DC5811C9DC5811C9DC5
811C9DC5811C9DC56ED3C295811C9DC5E2CE6927811C9DC56ED3C295811C9DC5
811C9DC5811C9DC52A200B4CE2CE6923E2CE69236ED3C2956ED3C295E2CE6923
E2CE69236ED3C295811C9DC5E2CE6927811C9DC5

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

————————————————–

BusyBox on (none) login: admin
Password:
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
[snip]
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
  • LinkedIn
  • Facebook
  • email
  • Google Bookmarks
  • del.icio.us
  • StumbleUpon
  • Reddit

Comments

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

Joe,
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.