Re: Preventing exploitation with rebasing

["Deus, Attonbitus" <Thor () HammerofGod com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 03:38 AM 2/4/2003, Charlie Root wrote:

> With all the respect... I think your ideea is a BAD one ! Why ? Well... It 
> might be verry efective if one to... mhm... 100 persons would aply this 
> technique. That's because hackers/worms wouldn't mind loosing a few 
> servers if they got the rest of the world. But if this technique would 
> became a standard then the worm-industry (if there is such a thing) would 
> also evolve... making it brute-force the addreses. I admit that 
> brute-forcing would slow down the worm/hacker/whatever... but this is no 
> way of looking at the security. This is like protecting a house/store by 
> putting 15 doors that all could be easily broken... Of course there is a 
> chance that a thief trying to break in would get bored breaking door after 
> door... but if he's really determined... Well... I guess I made my point.

A couple of things- one, David did not say "Stopping Worm Propagation with 
Rebasing,"  he said "Preventing exploitation..."  If only 100 people do it 
where one has the capability to reloc, then right on.  Let the other 74,900 
people lick their wounds while I sip on a White Russian and giggle.

He never said it was a silver bullet, never said it would be a panacea, 
never said it would apply to all applications.  He offered the information 
as an additional strategy one could use, where applicable, to mitigate 
exploitation of your typical worm.

I completely disagree with the statement that worm writers would evolve to 
brute-forcing addresses.  Not only from a stability standpoint (if they 
were lucky enough NOT to trash the service) but from a practical 
standpoint...  A worm's primary goal is to propagate to infect-able systems 
before the jig is up.   They will not go through the trouble of trying to 
BF a jmp address when they might draw attention and prematurely alert the 
target population to the attempt.   They will go for the low hanging fruit 
every time.  Hell, that is why they jacked David's vector code in the first 
place; they did not want to go through the trouble of doing it themselves.

Could Halvar do it?  Sure- in a nanosecond.  But I'm not building security 
in depth measures against people like Halvar and David (there's really no 
point in that.) I'm building up security in depth against the architecture 
and vector of your typical worm.


> Why was slammer so successfull... Well... Here's my oppinion: Sysadmins 
> experienced in windows usually have little firewalling skills. That's 
> probably because there is no powerfull firewalling tool like ipfw or 
> ipchains on windows. If all the SQL ports would have been firewalled the 
> worm would probably wouldn't have caused any harm.

I believe this point needs to be corrected- Shipped since Win2k, the IPSec 
policy manager can be used as a powerful firewall tool if you so 
desire.  It is highly configurable, can be set up via command line like 
ipchains or gui like the firewall config on Linux, can be set remotely via 
the MMC plug in, or deployed in the Enterprise via group policy and 
organizational units.  And that is just part of the power of the tools 
aside from their primary purpose of maintaining IPSec tunnelling 
policies.   It also supports a more expanded protocol list than ipchains 
(just tcp, udp, and icmp) with additional protocols like RDP, HMP, RAW, etc.

I don't know your criteria for suggesting Windows folks "usually" have 
little firewalling skills, but if that is indeed true, it is not because of 
Windows. All my peeps use IPSec extensively.

Besides, SQL Server is not an application where one would normally 
implement host-based port firewalling; not without breaking other things, 
anyway.  Localized host-based hardening is fine for net-facing web servers 
and DNS boxes, but SQL Server should not be directly on the net in the 
first place.  It was more of an infrastructure issue where these boxes 
could be reached on UDP 1434; host-based firewalling was not the answer: 
strong border -> DMZ firewalling policy was the answer (in addition to 
patch management.)

T





-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQA/AwUBPkGzlohsmyD15h5gEQLtGACfbIK5quvBDn/A0X5hz3/o3a4//hoAoNz8
Bd/++Ep/uRekp9WkHI6BYyWx
=J8fv
-----END PGP SIGNATURE-----