Summary: Security through Obscurity is not a scheme to build your security plan around, but it still has its merit as a means to increase your overall security.

For decades, inexperienced programmers have tried jury-rigging security onto software by implementing simplistic tricks that rely on obscurity rather than tried-and-true security measures. The assumption is that an attacker won't know to try something, and thus would not be able to get access to the software.

For example, lets say we have some fictitious Web-enabled device with an administrative interface living at http://example.com/XXXXXXX/, where XXXXXXX is the device's serial number. The manufacturer figures that only the administrator would be able to look on the back of the device and read the serial number, and thus this should be 'secure enough'.

The Problem

An attacker could easily discover that the admin interface is based on the serial number. Perhaps she has one of these units herself, or she finds newsgroup message from someone asking a question about the device. Regardless, the attacker need only whip up a quick 3 line shell script to try all possible URLs until they stumble on the correct one, and then there's nothing stopping them from taking over.

Had the manufacturer implemented some sort of password authentication, then the URL could have been something standard, say '/admin/'. Knowing the URL would do the cracker no good as she'd still need to know the password.

Security Through Obscurity This kind of 'security' is called 'Security through Obscurity' and it is anything but. Ask any security guru and they'll constantly remind you that relying on Security through Obscurity is a vulnerability waiting to happen. To develop a solid security foundation, you must determine exactly what bits need to be secret and make sure that they are both secret and something that can be changed. In general, we're talking about passwords, keys, certificates, etc?.

So if you hang out on security lists enough, you'll often see folks trying to use obscurity as their sole security implementation. Sitting back and watching veterans sharply suggest that the newbies may be better off programming for someone who does not think security is required, such as a big corporation in Redmond, is fun.

Because of this instant negative reaction to Security through Obscurity, many folks don't ever use it. But this isn't necessarily the way to go. "Thou shalt not rely on security through obscurity" may as well be written, but there's no reason that you can't add security by adding obscurity. Just don't rely on it as your only defense.

In many cases, obscurity and misdirection can be helpful. Undoubtedly, crackers out on the 'Net have scanned large network blocks compiling a list of software installed on those machines. Should a new vulnerability be found in a particular version of software, then they have a list of hosts waiting to be attacked as soon as an exploit can be developed. For example, if you have Apache installed in the default manner, then it will show you a good bit about the configuration and modules installed:

  $ curl -i http://www.example.com 2>/dev/null | grep Server
  Server: Apache/1.3.9 (Unix) Debian/GNU PHP/4.0.3pl1

An attacker who has developed an exploit for the recent PHP bug need only consult her list of machines with PHP installed to begin hitting a number of likely targets. If you had told Apache to be minimalist in its server description by including the following directive in httpd.conf:

  ServerTokens min

Then the output would have been:

  $ curl -i http://www.example.com 2>/dev/null | grep Server
  Server: Apache/1.3.9

  ServerTokens ProductOnly

  $curl -i  http://www.example.com 2>/dev/null | grep Server
  Server: Apache

A lot less information is available here [1]. Many network daemons can be configured to be less verbose, including most mailers and ftp servers. Unless there's a good reason to keep a version number or other identification around, have fun. Personalize your daemons. Why say:

  220 example.com ESMTP Sendmail 8.12.3.Beta0/8.9.3; 12 Mar 2002 22:20:34

Thus giving out both your server and configuration versions, when it could instead read:

  220 example.com ESMTP   All Your Base Are Belong To Us

Be creative.[2] And happy obscuring.

NOTES:

[1] PHP actually includes an 'X-Powered-By' line in the HTTP header as well, so there's more Apache tweaking you'd need to do to hide the presence of PHP entirely.

[2] I wasn't.

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He sneaks references to his wife and daughter into every book he writes, and every daemon banner he obscures. The next time you connect to the "ReegenMail" server, you'll know he's been here. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 12-Mar-2002.