Over the weekend a reader, Infinite, wrote to us and commented on "Bling.exe" with a pointer to TrendMicro write-ups of two new SDBot variants. Thanks Infinite! (Bling.exe is a component of these Trojan's spreading mechanism, the "TFTP server .. attempts to send this worm to other systems as the file "BLING.EXE").

Whats notable is that these SDBot variants have a sniffer with a list of strings they filter for. (Although there are two earlier bot variants, described by Sophos, that use Bling.exe, they are not reported to have a sniffer component). If the trojans described by Trend can successfully transmit the filters packet captures back to the owner they are going to cause problems well beyond typical bot infestation issues. It is my understanding that the filter will only work when it matches a string exactly.

The addition of the sniffer also brings up the question of "What are the intended targets of these particular trojans?" (my favorite malware question!). Are they after the usual SDBot stuff, ... after all ... building a SDBot variant is trivial, or is the trivial use of SDBot just camouflage for attacks on critical systems resulting from the harvest of the sniffer's filter? If you'd care to contribute to an answer to this question ("if you got bling") and care to share the sniffer's impact, privately or publically, please write us at;


http://isc.sans.org/contact.php

fwiw, if your network is vulnerable, while researching the history of the use of sniffers by Trojans and Backdoors, in "Malware: Fighting Malicious Code" by Handlers Ed Skoudis and Lenny Zeltser, there's a recommendation for finding sniffers, the book refers to;

-- the sentinel project v1.0 : by bind : copyright (c) 2000, 2001 --
The sentinel project is an implementation of effective remote promiscuous detection techniques.
http://www.packetfactory.net/Projects/sentinel/

SDBot and Bling.exe References;
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_SDBOT.UJ&VSect=T
WORM_SDBOT.UJ


http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_SDBOT.UH&VSect=T
WORM_SDBOT.UH

Filtered Strings from Trend;
"Information Theft

This worm uses carnivore network sniffer and checks for the following strings:

: auth
: login
:!auth
:!hashin
:!login
:!secure
:!syn
:$auth
:$hashin
:$login
:$syn
:%auth
:%hashin

:%login
:%syn
:&auth
:&login
:*auth
:*login
:,auth
:,login
:.auth
:.hashin
:.login
:.secure
:.syn
:/auth
:/login
:?auth
:?login
:@auth
:@login
:\auth
:\login
:~auth
:~login
:+auth
:+login
:=auth
:=login
:'auth
:-auth
:'login
:-login
login
login
paypal
PAYPAL
paypal.com
PAYPAL.COM

SSH Saga Continues

Reader Tomi Junnila offered these views and solicited feedback on the following approach to defending against recent SSH brute force attacks. Thanks Tomi!

"Using syslog-ng, I set up a new filter and destination to detect the attacks:

filter f_sshd_failed { program("sshd") and match("(Failed password for root|Illegal user (test|guest|admin|user)"); };

destination sshd_blocklist { program("/usr/local/sbin/sshd-blocklist"); };

log { source(src); filter(f_sshd_failed); destination(sshd_blocklist); };

This forwards log messages from sshd containing "Failed password for root from (host)" and "Illegal user (user) from (host)" to the program /usr/local/sbin/sshd-blocklist. This is a simple shell script:

#!/bin/sh

# Settings:
iptables="/sbin/iptables"
blockchain="blocking"
blocktarget="blocklist"

# This program will match lines:
# Illegal user (userid) from (host)
# Failed password for (userid) from (host) (...)
# and adds (host) to the iptables blocklist chain
# $blockchain.
#
#This chain is cleared regularly by a separate
# script to let entries expire after a while.

while read mm dd hms localhostname sshd word1 word2 word3 word4 host1 host2 rest; do

if [ "$word1 $word2 $word4" = "Illegal user from" ]; then

$iptables -A $blockchain -s ${host1}/32 -j $blocktarget

elif [ "$word1 $word2 $word3 $host1" = "Failed password for from" ]; then

$iptables -A $blockchain -s ${host2}/32 -j $blocktarget

fi

done

It's not perfect, but will block anyone trying to hack the machine for a while (the duration will depend on how often the chain is cleared) after their first failed attempt. If you have a separate whitelist which gets accepted before the blocklist chain is executed, you can ensure that a failed password won't cut you off from the host.

The downside is that this could theoretically be used to slow your host down if someone launched the attack from a huge number of IP addresses, causing the blocking chain to become very long. A more robust /usr/local/sbin/sshd-blocklist might help there, if it did some more checking before adding the hosts on the blocklist.

There may be better ways, and if anyone has any, I would be interested to know too."

Some initial feedback was that "key based authentication will be even better" and "the approach will not help against lucky shots that hit the right password on the first try, and against more distributed scans".

Patrick Nolan