[Dailydave] Hammerhead repost for Halvar

[Dave Aitel]

From:
https://web.archive.org/web/20040131120103/http://www.immunitysec.com:8010/29/2002
- Fishing for Obscurity

Some sharks and fish have a unique sixth sense – they can generate and
detect electrical fields, even minute ones. According to the font of all
natural knowledge, the Discovery channel (as opposed to Dawson's Creek, the
font for all social knowledge), a hammer head shark's funny looking head is
actually a voltmeter of astounding sensitivity. Apparantly it can detect a
small fish's electrical field from eight inches away. It swings its head
back and forth as it swims over the ocean floor looking for buried fishes
that other predators can't find.

So much of what we view as security depends on secrets. Every company, mine
included, must take huge risks to do business. For example, last weekend I
installed a new version of Apache, and put a Zope server behind it to serve
the actual content. Anyone who's looked at the C code for Zope would
understand that this is a “huge risk to do business.” However, like many
businesses, I've made the decision to absorb that risk in order to have
actual active content. Hence, my site is now protected only by the relative
obscurity of the many Zope bugs out there. In other words, I'm a fish
buried in the sand, waiting for a shark to pass overhead.

In general, this strategy is a poor one, since there are many sharks, and
they are aggressive eaters. Undoubtably when I next read full-disclosure
I'll see a remote root against Zope. The question is what to do next? Do I
reinstall every machine on my network? Do I just patch up Zope and start
the wait again? Or something in between?

Unlike most choices, this choice is dictacted by what you don't know. You
don't know if you've been hacked. No matter what IDS you use, your level of
assurance that given a new vulnerability against your machine, you would
have detected an attacker never raises above ten percent. You basically
have to get lucky. In cryptography, once you break a key, you can go back
and break every message that ever used that key. With a vulnerability this
is not true – the attacker could have spent hours cleaning your system up,
penetrated deep enough to render any subsequent information worthless. That
is, they could have, if the attack even left logs to begin with, which is
unlikely. So what do you do?

Let's look at it from another perspective. Every time you go out to hack a
machine, to go forage for food, if you will, you are putting yourself at
risk. Let's say you are using a completely non-public tool chain. From the
0day exploit to the 0day shellcode to the 0day trojans. Everything is new
and unique. So the pattern matching IDS's won't see you, and you won't be
leaving any sorts of traces that someone could be looking for. How secure
are you that you aren't going to detected?

Well, for starters, that 0day exploit, isn't. It's good odds that whoever
you are, there is someone just as good, and they may have given their
version of your 0day exploit to someone who knows someone who knows someone
who will be looking at your traffic. So when they see you hitting port 1433
they know you are hitting a port that has a remote root on it. Now they
have your version of the exploit, and your shellcode, your IP, your trojan
and if you are dumb enough not to encrypt your traffic, your session data.

>From that, can they search their IDS's database of all the traffic on their
network for where you've been? Can they quietly monitor the rest of their
network for where you go? Unfortunately, the answer is yes. So again, you
are in the position of a small fish, in a world full of sharks, protected
only because they haven't happened to float over you.

The “CISSP Information security professional” is at this point saying,
“looks like the only way to win, is not to play” and giving a geeky
chortle. But he's probably also running Netscape Enterprise Server version
3.6 because it happens to work with the version of Oracle the DBA team
needs to use. We'll pause a second now for them to go checksum their
/usr/sbin/ directories, fruitlessly.

One solution then, for both parties, is to increase the level of obscurity
they use to protect themselves, while decreasing the level of obscurity the
opponent has.

As an attacker, I necessarally need to implement more than one separate arm
of attack. Hence, even if my entire method of attack, toolkit, and target
list is compromised and a special filter is put in place on your network
sniffer to detect me, you will miss the other versions of me elsewhere on
your network, still accomplishing their goals. Perhaps I will develop
several different “groups” of people ,each responsible for their own
development. Let's call them YELLOW and GREEN. If the information shared
between YELLOW and GREEN is smaller than the level of corrolation my
detection engine is able to put together, even if I've caught GREEN hacking
my machines, I will still miss YELLOW. Perhaps the only information you
would share is “targets hacked” and “vulnerabilities.” Maybe not even that.
I think the answer for attackers is to be a school of fish. It's easy to
catch one, but catching them all is a huge pain.

As a defender, your best bet is to simplify your defenses. If the attackers
know more about your defenses than you do, then you lose, every time. Do
not pass GO, do not collect your 0day. For example, how many of you truly
know how NT's security model works? How does DCOM work? The main advantage
of Unix's security model over NT is that a great many people understand it,
as it is dirt simple. You want to trust your computing platform? The answer
is never to make things more complicated.

So the defender's best bet is to simplify the network their machine is on
down to a minimal set. Then add something the attacker cannot know going
in. For example, add a quick trojan to your own machine that watches every
file open to a particular directory, and lights up if it sees anyone open
() it. Then put a file in that directory named cisco_passwds.txt. Sounds
cheesy, but it's the obscurity that makes it work. A honeypot itself is
stupid – how many 0days has the honeynet project released? None. But what
if every machine in your enterprise has a honeypot somewhere on it? Kernel
programming is really easy to learn for this sort of simple game. Bodyguard
<https://web.archive.org/web/20040211051337/http://www.immunitysec.com/bodyguard.html>
is
one example of this, but a dozen other quick, but effective examples could
be done next week by your intern. So the solution for defenders is to be a
pufferfish – include something on your machines hard for attackers to
stomach – a real possibility of detection, through unpredictable defenses.

That way you can watch your Dawson's Creek in peace.

Copyright © 2002 - Immunity, Inc.
All Rights Reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.immunityinc.com/pipermail/dailydave/attachments/20180813/de3d0fef/attachment.html>