Obscurity

[InfoSec News <isn () C4I ORG>]

*********************************************************************
Security Through Obscurity
by Carole Fennelly

Want to *really* irritate  security architects? Just tell them their
design relies on "Security through Obscurity"
(http://www.tuxedo.org/~esr/jargon/html/entry/security-through-obscurity.html)

That accusation was leveled at me.  I had recommended that a client
have internal mail headers stripped out at the firewall before being
sent outside the company. I thought this was just good common sense. I
even provided the technical solution to do it in the MTA they were
running (sendmail). The admins balked and stated that "no one does
this". OK. So I asked the sendmail gods at sendmail.org for guidance.
To my surprise, they also felt it was unnecessary and even
inadvisable. In fact, some said I was "paranoid" and relying on
"security by obscurity".

Ouch. As a firm believer in full disclosure and Open Source systems,
this really hurt.

Bruce Perens made some good points on this in his Slashdot article:
"Why Security Through Obscurity Won't Work".
http://slashdot.org/features/980720/0819202.shtml

Sometimes, however, a little obscurity is advisable. The problem
arises when it is relied upon exclusively as a measure of defense. In
the case of my client with the bleeding headers, the internal network
was protected from intrusion from outside the company by firewalls and
other security mechanisms. I still think that it's foolhardy to
advertise internal information so promiscuously because the first step
in attacking a site is gathering as much information about the site as
possible, as demonstrated in this older Phrack article:
http://www.attrition.org/~jericho/works/security/phrack-53.html

Why make it easier than it has to be? Why advertise your internal mail
routes and internal IP addresses of firewalls that accept SMTP
traffic?  Relying on security through obscurity is foolhardy.
Blatantly advertising internal information to the outside is even more
foolhardy.

With software packages, it's a different matter entirely. End users
are at the mercy of the software vendors and are forced to rely on
them to properly test their products. I used to be in a System Test
group and, believe me, they have no status in software development
departments. I tried the tactic of going directly to a developer
before writing a bug report on their software. Many appreciated my
covering for their mistakes in this way. One developer surprised me by
telling me to write up the bug report -- even though she fixed the
problem as I was talking to her. When I questioned her on this, she
explained that the monthly bug report that was distributed to the
entire department forced developers to do a better job at debugging
their code. It also forced management to recognize that unrealistic
deadlines led to bad code.

Sadly, the System Test department of today's software is an unfunded
loosely organized group of technologists, commonly referred to as
"hackers". Many of them provide exploit code to demonstrate the bug in
question. No different from the practice when I was in System Test.
The big difference is that these hackers release the exploit to the
public at large -- not just the vendor. Some people, particularly
Marcus Ranum (of TIS fwtk fame) object to this practice and feel that
it causes more harm than good.

Ranum in the Lion's Den (Koch)
http://www.zdnet.com/intweek/stories/columns/0,4164,2630983,00.html

Others, particularly Mudge (of L0pht fame) vehemently disagree. The
Other Side of the Story (part 2 of above) (Koch)
http://www.zdnet.com/intweek/stories/columns/0,4164,2634819,00.html

Despite what Ranum would like to believe, most software manufacturers
are not self-motivated to fix bugs. Motivation is provided through the
fear of public embarrassment. Marcus seems to believe that the danger
of script kiddies using an exploit is a reason to obscure information
about vulnerabilities. Great, we'll be protected from script kiddies
who aren't bright enough to figure out that Back Orifice won't work on
a Unix system.

If you are protecting your systems from script kiddies, you are
wasting a huge amount of time and money. Script kiddies, though highly
annoying and often immature jerks, generally don't know what to do
with a system once they've broken it.  Command-line access is their
electronic equivalent of a fantasy date:  they all seek it, but none
of them know what to do once they've got it.

The real danger is from corporate spies who use an unknown exploit and
cover all signs of their intrusion. Mostly, the exploits they use are
not public knowledge -- and they don't want them to be. If the
information about the vulnerability is made public, companies can
analyze the exploit and properly evaluate their risk. If there is no
patch or work-around, they have the option (and justification!) to
take certain critical systems off the net and monitor their systems
more closely. To be fair, many corporations will not do this. They
also will not apply patches once the vendor gets around to it. Those
who truly are concerned about security should not have to suffer for
this negligence.

A Dutch hacker who recently broke into Nasdaq and several other
financial sites did not brag of his achievement in hacker chat rooms.
Instead, he emailed the administrators who gratefully patched the
holes in their systems on his advice. He claims to have a new exploit
that he wrote himself, but will not publish because "People will start
using it and that's just too dangerous". How noble of him. Of course,
no malicious hacker will *ever* figure out the same thing. This type
of "Security through Obscurity" makes the job of the corporate spying
that much easier. Why make it easier?

Hacker Puts NASDAQ on Warning
http://www.infoworld.com/articles/hn/xml/00/10/02/001002hnhacker.xml


Other Resources

Internal system security enhancements
http://www.itworld.com/jlw/unxsec_nl/lw-1999-07/lw-07-ramparts-3.html

Interview with Marcus Ranum in Information Security Magazine
http://www.itworld.com/jump/unxsec_nl/www.infosecuritymag.com/sep2000/qa.htm

Spooked: Espionage in Corporate America by Adam L. Penenberg
http://www.itworld.com/jump/unxsec_nl/www.amazon.com/exec/obidos/ISBN%3D0738202711/103-0645906-1565443

The UCITA Page (InfoWorld)
http://www.itworld.com/jump/unxsec_nl/www.infoworld.com/ucita/

Surviving UCITA
http://www.itworld.com/jump/unxsec_nl/www.troubleshooters.com/ucita/index.htm

The UCITA Car (humor)
http://www.itworld.com/jump/unxsec_nl/www.troubleshooters.com/ucita/ucitacar.htm

************************************************************************
************************************************************************

About the author
----------------
Carole Fennelly is a partner in Wizard's Keys Corporation, a company
specializing in computer security consulting. She has been a Unix
system administrator for almost 20 years on various platforms, and
provides security consultation to several financial institutions in
the New York City area. She is also a regular columnist for SunWorld
(http://www.sunworld.com). Visit her site (http://www.wkeys.com/) or
reach her at carole.fennelly () sunworld com
*********************************************************************
http://www.itworld.com

ISN is hosted by SecurityFocus.com
---
To unsubscribe email LISTSERV () SecurityFocus com with a message body of
"SIGNOFF ISN".