When security improvements backfire

Published: 2008-02-06. Last Updated: 2008-02-06 22:26:09 UTC
by Daniel Wesemann (Version: 2)
0 comment(s)

Recently, when conducting an (authorized) security review at a small web hosting provider, I ended up as "root" on all their Unix systems within a matter of hours, and did not even need any l33t buffer overflow or the like. Well-meaning system administrators had tried to improve security of their servers, and had unwittingly ended up making life much easier for the bad guys.

Aware of the constant barrages of SSH password guessing attacks that are plaguing the Internet, they had switched to public key (RSA) authentication. This in itself is a good thing. That their system maintenance script user had a password-less SSH-key to allow for automated logins is a less good thing. The key itself was well protected with file system permissions, but somebody someday had also created a TAR archive to back up the maintenance user's environment. Unlike most of the other files, the TAR had permissions set to rw-r--r--, and contained the .ssh folder as well. The RSA key was mine.

Their second security improvement was to introduce "sudo", so that none of their staff had to log in as "root" in the daily course of operations. This again in itself is a good idea. Until I went and checked if any "sudo" privileges had been granted to the "monitor" user whose SSH key I had just filched

monitor@gamlumi:/home/monitor$ sudo -l
User monitor may run the following commands on this host:
    (root) NOPASSWD: /home/monitor/dnsrefresh

Some of you are probably already thinking "Ouch!" now. Yes: The above says that user "monitor" can run the command "/home/monitor/dnsrefresh" with root privileges. In itself nothing to cause sleepless nights, but the "dnsrefresh" file sits in monitor's very own home directory, which means that user "monitor" can replace it. A quick copy of /usr/bin/bash netted the expected root privileges.

Even if you now think "this won't happen to me", maybe it is still a good time to

  • check if you have any "automation" or "technial" users configured that use password-less SSH RSA keys .. and if yes, to make doubly sure that the keys are SAFE. Changing the key and revoking the old one from the "authorized keys" just in case probably won't hurt.
  • investigate if automation users that use password-less SSH keys can be restricted to the particular command needed. SSH supports the "command=" syntax within the authorized_keys file to solve exactly this problem. Had they used this feature, I would not have been able to log in as "monitor" user
  • review your sudoers file to verify that sudo rights are granted only on programs that are owned by root and sit in a directory owned by root

If you have other good tips on how detect security problems with "sudo" or "SSH" configurations as a system administrator before the bad guy do, please send them in and we'll update this diary with a summary of the best.

Update: ISC reader Jim wrote in to recommend the "sudo judo" write-up at ethicalhacker.net, which covers quite a few of the most common sudo security pitfalls.

Keywords:
0 comment(s)

Does your anti-virus detect old keyloggers?

Published: 2008-02-06. Last Updated: 2008-02-06 16:13:55 UTC
by Jason Lam (Version: 1)
1 comment(s)

I was playing around with the Tiny keylogger 2.0 last night, this is a keylogger written by Tony Segreto. Compare to other hostile malwares that come thru ISC, the intention and purpose of this keylogger is very clear and it didn't seem to trigger download of other malware. The special thing about this keylogger? It can be downloaded from download.com.

As I was playing, I noticed this keylogger didn't trigger any sort of AV alerts, not exactly what I would expect from a known keylogger. I would personally like my AV to tell me about the existence of a keylogger file on my computer even though this keylogger might not have the most advanced features to semi-automatically getting itself installed on my box.

While it is fair that AV companies need time to come up with signature and defenses for the latest malware coming up the horizon, this keylogger has been sitting on download.com for years (file date shows Aug 2005), maybe the AV engine somehow forgotten about it? What really worries me is when I do a search on download.com for "keylogger", there're 248 hits, makes me wonder how many of those keyloggers are caught by different anti-virus and anti-apyware engines.

The overall coverage by AV vendors on this specific keylogger is very low. Here is the output of Virustotal.

File tkey.exe received on 02.06.2008 15:44:10 (CET)
Antivirus Version Last Update Result
AhnLab-V3 2008.2.6.10 2008.02.05 -
AntiVir 7.6.0.62 2008.02.06 -
Authentium 4.93.8 2008.02.05 -
Avast 4.7.1098.0 2008.02.05 -
AVG 7.5.0.516 2008.02.06 -
BitDefender 7.2 2008.02.06 -
CAT-QuickHeal 9.00 2008.02.04 -
ClamAV 0.92 2008.02.06 -
DrWeb 4.44.0.09170 2008.02.06 -
eSafe 7.0.15.0 2008.01.28 Spyware.Gen
eTrust-Vet 31.3.5512 2008.02.05 -
Ewido 4.0 2008.02.06 -
FileAdvisor 1 2008.02.06 -
Fortinet 3.14.0.0 2008.02.06 -
F-Prot 4.4.2.54 2008.02.05 -
F-Secure 6.70.13260.0 2008.02.06 -
Ikarus T3.1.1.20 2008.02.06 -
Kaspersky 7.0.0.125 2008.02.06 -
McAfee 5223 2008.02.05 -
Microsoft 1.3204 2008.02.05 -
NOD32v2 2853 2008.02.06 -
Norman 5.80.02 2008.02.06 -
Panda 9.0.0.4 2008.02.05 -
Prevx1 V2 2008.02.06 -
Rising 20.29.22.00 2008.01.30 -
Sophos 4.26.0 2008.02.06 -
Sunbelt 2.2.907.0 2008.02.05 Tiny KeyLogger (Segreto)
Symantec 10 2008.02.06 Spyware.TinyKeylogger
TheHacker 6.2.9.210 2008.02.06 -
VBA32 3.12.6.0 2008.02.05 -
VirusBuster 4.3.26:9 2008.02.05 -
Webwasher-Gateway 6.6.2 2008.02.06 Riskware.KeyLogger.AS
 

------------------------------

Jason Lam

 

Keywords:
1 comment(s)

Comments


Diary Archives