[aclug-L] FW: Security with Obscurity is Great

["Dale W Hodge" <dwh@xxxxxxxxxxxxxxxx>]

-----Original Message-----
From: Linux_Security@xxxxxxxxxxxxxxxxxxx
[mailto:Linux_Security@xxxxxxxxxxxxxxxxxxx] 
Sent: Tuesday, March 12, 2002 12:50 AM


LINUX SECURITY --- March 12, 2002
Published by ITworld.com -- changing the way you view IT
http://www.itworld.com/newsletters
___________________________________________________________________

HIGHLIGHTS

* 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.

SERVICES

* Survey: Share Your Opinion on Newsletters for a Chance to Win $500! 
____________________________________________________________________

SPONSORED LINK

FREE WEBCAST: PREPARING YOUR COMPANY FOR UNEXPECTED DISASTER

Is your company prepared to lose millions of dollars in just a few 
minutes? That's all it would take if your information systems become 
unavailable. Come learn how you can be prepared for the unexpected.

http://itw.itworld.com/GoNow/a14724a54332a76028222a3
____________________________________________________________________

Security with Obscurity is Great
By Brian Hatch

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

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.

_____________________________________________________________________

SPONSORED LINK

WE NEED YOUR OPINION ON NEWSLETTERS AND YOU COULD WIN $500

To improve the ITworld.com newsletters for our subscribers, we are 
conducting a short survey and would like to hear how you view and use 
this information. Your contribution is greatly appreciated, and as our 
thanks, you can enter a drawing for a $500 American Express gift 
certificate at the end of the survey. Please respond now!

http://itw.itworld.com/GoNow/a14724a54332a76028222a0
_____________________________________________________________________


About the author(s)
-------------------
Brian 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.  Brian can be reached at 
brian@xxxxxxxxxxxxxxxxxxxxxxx.
_____________________________________________________________________

ADDITIONAL RESOURCES

Why Security-Through-Obscurity Won't Work
http://itw.itworld.com/GoNow/a14724a54332a76028222a1

Security through obscurity never works
http://itw.itworld.com/GoNow/a14724a54332a76028222a8

The Virtues of Security Through Obscurity
http://itw.itworld.com/GoNow/a14724a54332a76028222a2

The Microsoft Way - Security Through Obscurity
http://itw.itworld.com/GoNow/a14724a54332a76028222a4

Can Security Through Obscurity Be A Good Thing?
http://itw.itworld.com/GoNow/a14724a54332a76028222a5
_____________________________________________________________________

ITWORLD.COM NEWSLETTER ARCHIVE

Index of Linux Security
http://itw.itworld.com/GoNow/a14724a54332a76028222a9

Mandatory Access Control: Silver Bullet or Kafkaesque Nightmare?, Part 1
http://itw.itworld.com/GoNow/a14724a54332a76028222a6

Mandatory Access Control: Silver Bullet or Kafkaesque Nightmare?, Part 2
http://itw.itworld.com/GoNow/a14724a54332a76028222a7
______________________________________________________________________

CUSTOMER SERVICE

SUBSCRIBE/UNSUBSCRIBE:
- Go to: http://www.itworld.com/newsletters
- Click on "View my newsletters" to log in and manage your account
- To subscribe, check the box next to the newsletter
- To unsubscribe, uncheck the box next to the newsletter 
- When finished, click submit

Questions? Please e-mail customer service at: mailto:support@xxxxxxxxxxx
______________________________________________________________________

CONTACTS

* Editorial: Andrew Santosusso, Newsletter Editor, 
  andrew_santosusso@xxxxxxxxxxx
* Advertising: Clare O'Brien, Vice President of Sales, 
  clare_obrien@xxxxxxxxxxx
* Career Corner: Janis Crowley, Vice President/General Manager, IDG 
  Recruitment Solutions, janis_crowley@xxxxxxxxxxxxx
* Other inquiries: Jodie Naze, Senior Product Marketing Manager, 
  jodie_naze@xxxxxxxxxxx

______________________________________________________________________

PRIVACY POLICY

ITworld.com has been TRUSTe certified 
http://www.itworld.com/Privacy/

Copyright 2002 ITworld.com, Inc., All Rights Reserved.
http://www.itworld.com


-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://www.complete.org/cgi-bin/listargate-aclug.cgi