l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2004 Nov 18 16:54

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Recover from Attack on Linux and Windows Systems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Recover from Attack on Linux and Windows Systems

Quoting Edward Elliott (ed_elliott@email.com):

> Read a great article written by folks at the Univ of Wisconsin about
> their work to recover from an attack on their Linux and Windows
> servers. Thought this would be of interest to others.
> http://www.nwc.com/showitem.jhtml?articleID=51201852&pgno=1

(I'm making no comment on the MS-Windows part of that article.)

The article suffers flaws typical of many I see about Linux security:

1.  There's nothing about how the intruders got in.  This is a crucial
omission:  If you don't have at least a good theory about how they got 
in, you have poor prospects for keeping them out.  Instead, at the point
where the article would naturally discuss that, it launches into an
extended discussion of _post-attack_ tools: rootkits, key loggers,
backdoors, etc.  It's because of articles like this one that people keep
mistakenly believing that rootkits, etc. are attack tools.

2.  In fact, the author even speaks outright about "black-hat attacker
tools like SuckIT and Wolff".  Wrong.  Those are things attackers use 
to hide themselves and attack further systems _after_ breaking in.

3.  Author says "a rootkit called SuckIT was surreptitiously installed
to gain root access".  Per my recollection and the Phrack article
covering it[1], SuckIt has _no root-exploit code_.  My recollection is that
it includes a backdoor and a number of trojaned replacements for system
utilities (to hide the intruder's presence).  

I would suspect that the intruder escalated to root using an exploit
against the old do_brk() and mremap() kernel exploits, or something
similar.  But one would want to take a good, long look at the
compromised system to determine what the likely means of intrusion and
of escalation were.  Here's an article that does it right, just for the
sake of comparison:


4.  Article's section "Trouble in Unix and Linux Land" includes nothing
at all about how to determine _how the intruder got in_.  Again, this is 
_the_ crucial datum.

5.  Article has nothing about post-rebuild measures to prevent

In summary:  One suspects that the authors emerged with no clear idea
how the bad guys got in, _nor_ how they escalated to root -- and one
wonders if they have a workable plan to avert recurrence.  That's sad.

[1] http://www.phrack.org/phrack/58/p58-0x07
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!