Threat Level: green Handler on Duty: Jan Kopriva

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

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, which covers quite a few of the most common sudo security pitfalls.

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

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 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 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 2008.02.06 -
Authentium 4.93.8 2008.02.05 -
Avast 4.7.1098.0 2008.02.05 -
AVG 2008.02.06 -
BitDefender 7.2 2008.02.06 -
CAT-QuickHeal 9.00 2008.02.04 -
ClamAV 0.92 2008.02.06 -
DrWeb 2008.02.06 -
eSafe 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 2008.02.06 -
F-Prot 2008.02.05 -
F-Secure 6.70.13260.0 2008.02.06 -
Ikarus T3.1.1.20 2008.02.06 -
Kaspersky 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 2008.02.05 -
Prevx1 V2 2008.02.06 -
Rising 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 2008.02.06 -
VBA32 2008.02.05 -
VirusBuster 4.3.26:9 2008.02.05 -
Webwasher-Gateway 6.6.2 2008.02.06 Riskware.KeyLogger.AS


Jason Lam


1 comment(s)
Diary Archives