lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: full-disclosure at ifokr.org (Brian Hatch)
Subject: *Including* Security through obscurity measures is good.



> > [1] *Relying* on security through obscurity is bad.
> >      However *adding* security through obscurity is good.
> >      This distinction is too often overlooked.  Why say "I'm
> >      running Apache 1.2.26 with mod_perl and mod_ssl version
> >      BLAH" when you can just say "Apache"?  It only makes it
> >      easier for crackers to mark you down on their well-
> >      tailored lists.
> 
> There is no security through security.  ServerTokens Prod is a false sense
> of security, and when you think about it offers no real security at all.
> Script kiddies will still try the short list of apache exploits.


Say they have an exploit for some daemon that will either

	a) work, or
	b) crash the server

and they have exploits tailored for 5 different versions of the
daemon.  If you don't tell them which you're running, then they
have one shot to get it right, or the daemon dies and they can't
try again.  Would you not argue that withholding the version number
helped out in this case?

Is it 100% reliable?  Hell no.  Should it be your only line of
defense?  Hell no.  Did it hurt to include this in your setup?
No.  Could it possibly help?  Yes.

So why not utilize it?

> To me, "Apache" instead of the "Apache/1.3.27 (Unix) mod_ssl/2.8.11
> OpenSSL/0.9.6g PHP/4.2.3" means "this admin is:
> 
> 1.) Lazy and doesn't patch when needed.

The lazy administrator probably has no idea how to configure it
to not withhold version info in the first place.

> 2.) Gullible, and thinks they can somehow magically prevent an automated
> worm or a determined script kiddie from compromising their server.
> 
> P.S.
> The slapper worm variants don't go to netcraft and ask "what's that site
> running" before they use root you.

Nor did I say it did.  However there have been vulnerabilities that
needed to be tailored for a specific version.  If they need to blindly
try several exploits (and I admit they will) they might try the wrong
ones first.  Perhaps those wrong exploits will result in log entries
indicating something is wrong, and they admin will check into it,
whereas if the attacker tries the correct one and gets in without a trace
that's one less thing to help the admin know something is amiss.

Tell my why *including* security through obscurity is bad.  I already
know why *relying* on security through obscurity is bad.


Using version numbers as our example, where could it be bad?
Take ssh: the server exclaims it's version number, and this
allows the client to work around known bugs in the server
version.  (OpenSSH has lots of workarounds for server bugs
per version number.)

Take a web server, on the other hand, do clients need to work
around bugs in specific versions?  No.  What do we gain by
having the server announce it?  Nothing.  What do we loose by
having the server announce it?  Nothing, except a small addition
of obscurity that *may* help some day down the road.




--
Brian Hatch                  "I am a Ranger. We walk in the dark places
   Systems and                no others will enter. We stand on the
   Security Engineer          bridge and no one may pass.
http://www.ifokr.org/bri/     We live for the One, we die for the One."

Every message PGP signed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20021208/11e5e591/attachment.bin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ