[svlug] Sniff, sniff

[Rick Moen]

I will have some fair amount to say about recovering from root
compromise, but am short of time at the moment.  Suffice it to
say that the Linux machines at 744 Harrison Street (most of them)
had a fun weekend.

We had a break-in artist (I call him "Berferd, Jr.") who got in
by sniffing one of my telnet sessions into hugin.imat.com from
outside.  I might have been incautious enough to "su -" during
one of those sessions.  Either via the latter, or by running a
canned route exploit against XFree86 (a stack-smashing attack
published on rootshell.com in 2/98), he got root.  Then, he
installed rootkit, which replaces a dozen or so sysadmin utilties
with trojaned versions, to hide his activities.  Then, he installed
sniffit, a selective tcp sniffer, putting my NIC in promiscuous
mode to snarf username/password/hostname information for people's
telnet/pop/ftp sessions from my machine and The CoffeeNet's.   
Thus, he's able to get a route into lots more LANs.

On occasion, he telnetted in and picked up the sniffit logs.  I
have those and some of his tools, such as the rootkit script.

He was a weenie, by the way:  He used only canned attacks without
any particular talent, and (adding insult to injury) is a pico
user.

Among the several things we could discuss is how best to eliminate
the need for cleartext passwords -- in a real-world context that
includes clueless users who won't adopt ssh/ssh-agent easily, and
who use any old POP client, poorly.  (To clarify, the problem is:
If you assume that a hostile party might run a sniffer on your
LAN, what services do you disable on your machine, and what practices
do you implement, to prevent him from sniffing passwords for shell
accounts -- without driving your users crazy?)  Some possibilities:

1.  Make a policy that any user who's going to POP mail cannot
have a shell account.  Make such users have /usr/bin/passwd as
login shell.  Then, anyone who sniffs his password cannot
effectively use it to break in.

2.  Turn off telnetd; substitute sshd with ssh-agent.  Pain in
the neck for me, personally, since I find it convenient to 
telnet in from off-site, and don't carry a Win32 ssh client 
with me.  (Someone mentioned an open-source one.  Where is it?)

3. ftp:  Under this scenario, I (the sysadmin) can still 
get/retrieve files via _anonymous_ ftp (because I can ssh in
and su to root) and also via scp (without having to compromise
security by ftp'ing as username rick).  Ideally, I should 
enforce this by disabling all incoming ftp access by shell
users _except_ anonymous.  (Any idea how, with wu-ftpd?_ My 
non-admin shell-account users would not be able to use the 
anonymous ftp trick (lacking root access), so I'd have 
to tell them to get scp.  (Pretty BofH-ish.)

4.  Allow only IMAP; disable pop3.

5.  Allow only APOP; disable the USER/PASS authentication
mechanism.  Qualcomm's qpopper (inherited from Berkeley popper)
supports APOP:  Anybody know how to mandate that auth method
in qpopper, solely?

Correct me if I'm wrong:  There's no way to secure non-anonymous
ftp, right?  By "secure", I mean prevent disclosure of plaintext
passwords during ftp login.  Therefore, allowing shell users to
do ftp logins under their usernames will inevitably disclose 
plaintext username/password information for shell accounts to
any LAN sniffers, right?

Inbound ssh access is safe.  Inbound _anonymous_ ftp access is safe.
Inbound APOP access is safe.  Inbound IMAP access is safe.  Inbound
scp (ssh cp) access is safe.  Inbound regular POP access by non-shell
users is safe.  Inbound ftp by non-shell users is safe.  (Here, "safe"
is defined as "doesn't disclose to sniffers passwords usable to gain
shell access".)

Inbound telnet is unsafe.  Inbound ftp access by shell users is 
unsafe.  Inbound regular POP (with USER/PASS authentication) by
shell users is unsafe.

Comments invited (obviously).

-- 
Cheers,
Rick Moen                      "vi is my shepherd; I shall not font."
rick (at) hugin.imat.com                          -- Psalm 0.1 beta

--
echo "unsubscribe svlug" | mail majordomo at svlug.org
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to unsubscribe