[NCLUG] I was hacked!

[John L. Bass]

	Ahyeah... Tripwire is the ideal solution, but for some reason it isn't 
	widely used, yet.

It's annoying to setup the config file to "just" cover critical system files
and avoid lengthy reports on more dynamic systems. And that it has to be
administered more or less remotely (or a standalone boot system). Add dynamic
updating, and poof you get tripwire email for all the updated packages. Something
which integrates remote distrution checking (known clean distribution) verification
against a running system (with some intelligent config files) would work a whole
lot better. "rpm -V -a" is a half step in that direction, but relies on the
local RPM data base to do the check .... running it on an nfs mounted filesys
from a "clean" external host/dbase partially corrects that flaw.

	with "echo *", and get around a trojan'd find(1) with tar(1).  My solution 

I forgot to mention that too ... especially doing echo .* to look for the hidden
files and directories. A long time ago, "cat ." worked too, but not on newer
"user friendly" systems.

	You did your homework too! <grin> According to this article, that is 
	exactly what is going on: http://www.robertgraham.com/op-ed/magic-ddos.html

	 > Has anyone in the linux community thought about banding togather to
	 > actively hunt and kill these slobs? Effective coordination would be
	 > interestings, especially to minimize "moles" from diverting/hijacking
	 > the effort.

	The tools to support this effort already exist.

Tools do not equate to organized countermeasure teams.

	I was about to throw out my 
	anti-RedHat speech here, but you've already heard it, and didn't want to 
	hear me whining last time, either.  Let me just say that I think it would 
	surely help a little if everyone made security the first thing they thought 
	about instead of the last.  Why are so many Linux users suprised at how 
	many ports are open on their machine?  Why don't more people follow the 
	security advisories?  Why is Bastile such a secret?

First ... It's not a vendor issue, even debian machines get hacked. Open source,
while it will more than likely lead to security in the long run (open debate on
that topic), in the short term (first decade or so) makes it easier for the attackers
to find holes. The reality is that the holes will be exploited for at least several
weeks *BEFORE* the advisory/fix is available to the general public. In the mean time
a 100,000 machines have been infected with the next round of root kits. Frankly,
post-infected security advisories as just as useful as post-infection anti-virus tools,
not very useful.

	That said, it is getting better.  Auto-updating is becoming a reality.  I'm 
	particularly impressed with -- put down those sticks! -- Windows 
	Update.  It works well! (And good thing, too!) And now apparently RH7 now 
	does auto updates as well.  Excellent!

Frankly, I disable the new RH7.0 update demons ... I see it as a big brother tool,
who's primary task in life is to allow RH to claim in their next marketing round
that they have a verified N-million user base - and that they know which packages
each user has loaded/use, to profile the individual user. We were very unhappy with
Micro$oft when they pulled that trick a couple years ago, should be equally upset
with RH today.

	I think it is all about education.  I'd love to give a talk about security 
	sometime...  I considered offering it up to the CSU-LUG, in return for 
	snagging the best book at their first meeting.  <blush>

Some of us have a goal of being able to replace M$ desktops with OpenSource desktops,
which means that the person at the desktop is unskilled, and the person installing
and maintaining the network is only marginally skilled.

That means the distributions need to be clean, maintainence free, and lights out
(AKA hands free) admin'able for a reasonable period (2-3 years).

The problem with the OpenSource movement, is an explosive version of the Unix
problem ... to many idle hands with egos, pushing unnecessary (improvements)
features which contribute bugs (AKA security advisories) at an alarmingly
ever increasing rate. Rule of thumb says it takes 1-2 product years to ring
out all bugs in a major software revision ... and that is with managed product
development cycles and tight ECO/market driven restrictions on changes. The
obvious concern, is unmanaged changes keep resetting the clock back to zero.

I have sat on both sides of the fence here ... an active hacker/cracker for several
years (with full faculty support) on the 19 campus CalState timesharing system
1972-1974 ... and as a facility manager for several large UNIX timesharing
facilities and in-house workstation networks over the last 25 years. On the
CalState system, the ultimate prize was not admin (root) status, but actually
running kernel mode code ... did that twice. The ultimate linux virus today,
would not touch a single file in the filesystem, but rather patch itself into
a running kernel and remain undetectable by tripwire or other "security" tool.
It would probabably piggy back it's communications on the back of normal network
packets. And would, by most measures, remain totally undetectable until the
hacker choose to expose the machine ... with no post mortum analysis possible
once the machine was reset/powered down.

Lastly, the ultimate crack, would be to divert DNS from the RH update site to a
cracker managed server offering "updated" packages containing trojans. And without
even a thought, millions of machines would be updated overnight with the latest
exploit. And done well, not even a trace of how the initial attack was made.
It might be possible to build an auto-update scheme with crypto-authentication
trust ... but still, that just makes the ultimate prize even more valuable,
breaking the signature keys for the auth system. Instead of looking for bot
conscripts, the challenge will be looking for distributed key breaking bots,
which are much less likely to be spotted in the wild.

Two Cents worth (now almost worthless) from a very old fart in this game.

Have Fun,
John Bass