Hi, On 21-Nov-01 Annette Jaekel wrote:

Hi, In september we had an incident on old SuSE 6.3 stations with the root kit tool duarawkz (well known irc DoS tool: http://lists.insecure.org/incidents/2001/Mar/0141.html) We updated all 6.3 stations to SuSE 7.2.

We supposed that the hacker came trough the security hole within rpc.statd, rpc.kstatd from NFS, which is announced for SuSE 6.x in august 2000. The Security announcement told SuSE 7.x isnt vulnerable.

Now we had another incident with duarawkz on an SuSE 7.0 station - so my questions are:

1) Is SuSE 7.x really not vulnerable regarding to the NFS hole of rpc.statd? 2) Does anyone know incidents with duarawkz a bit in detail and can tell me one or more popular entry ports used by the tool?

we had two incidents including the dua rootkit. "dua" is short for "digital underground army". The duarawkz rootkit contains trojanized binutils (ls, grep, etc.), the well-known mirkforce tool (dua.mf), a udp backdoor, some DDoS tools like Stacheldraht (yawn...) and a couple of pre-compiled exploits for several vulns. It's usually found in /usr/bin/dua or /usr/bin/duarawkz for easy accessibility. The trojanized "ls" of the rootkit comes with a config file which contains any name and file the bugged "ls" should not display. There's also a script called "sauber" which cleans up some of the intruders' traces, a backdoored portmapper which loads up other trojans of the kit, and a trojanized login, telnetd, and ps. Also, there are some "target" files in the exploits directory (called "sploits", shitty would-be 3l33t I say). The presence of the rootkit and the trojans/backdoors can be easily veryfied with a simple lsof | grep dua; the author(s) of the rootkit utils (thankfully) didn't do a proper job. The ppl who use this rootkit do not necessarily have to be the dua dudes themselves; the rootkit is available for download on quite some ftp sites. The first version of the rootkit opened up a backdoor, which usually has been visited via Dutch networks, but again, this does not insinuate anything. Since the majority of tools of the rootkit contain DDoS/IRC-bombing stuff, it's most likely that the attacker(s) tried to create a willing bot/zombie and integrate it into their tribe flood network. On the two occasions we had with the kit, we conducted intensive post-mortem analyses and forensics, but could not find any evidence for destroyed/altered files, except for the trojanized binutils of course.

Until now I dont know the vulnerability duarawkz came trough into the 7.0 station - and maybe I have to reinstall all machines every week. Thats not an acceptable alternative solution.

My first guess too was a vulnerable rpc.stad/portmapper, because the network segment one of the cracked machines resided in received (and receives) a shitload of portmapper and ftp scans, but after some more research and several talks we had with admins of other affected systems, we came to the conclusion that a flaw in the SSH1 protocol has been used to break into the two said systems.

From the CERT.org vulnerability note VU#945216:

- - - Overview There is a remote integer overflow vulnerability in several implementations of the SSH1 protocol that allows an attacker to execute arbitrary code with the privileges of the SSH daemon, typically root. I. Description There is a remote integer overflow vulnerability in several implementations of the SSH1 protocol. This vulnerability is located in a segment of code that was introduced to defend against exploitation of CRC32 weaknesses in the SSH1 protocol (see VU#13877). The attack detection function (detect_attack, located in deattack.c) makes use of a dynamically allocated hash table to store connection information that is then examined to detect and respond to CRC32 attacks. By sending a crafted SSH1 packet to an affected host, an attacker can cause the SSH daemon to create a hash table with a size of zero. When the detection function then attempts to hash values into the null-sized hash table, these values can be used to modify the return address of the function call, thus causing the program to execute arbitrary code with the privileges of the SSH daemon, typically root. II. Impact This vulnerability allows a remote attacker to execute arbitrary code with the privileges of the SSH daemon, typically root. III. Solution Apply a patch from your vendor Several vendors of SSH1 implementations have released patches to address this vulnerability; please see the Systems Affected section of this document for further details. Disable support for SSH protocol version 1 On vulnerable SSH1 servers where patches are either unavailable or cannot be installed, the CERT/CC recommends that system administrators disable SSH1 service until a more permanent solution can be found. To determine whether a given SSH server is vulnerable, please consult the Systems Affected section of this document. Systems Affected Vendor - Status - Date - Updated SSH Communications Security - Vulnerable - 6-Nov-2001 OpenSSH - Vulnerable - 2-Nov-2001 FreeBSD - Vulnerable - 2-Nov-2001 CORE SDI - Vulnerable - 6-Nov-2001 Debian - Vulnerable - 14-Nov-2001 - - - On both said systems, SSH1 was running, in a vulnerable version. Another system in the networking neighbourhood received another attack, but the attacker(s) forgot (or didn't manage) to clean the log files. A typical syslog entry for this SSH1 crc compensation attack would read: Feb 03 10:02:33 host sshd[3423]: fatal: Local: crc32 compensation attack: network attack detected If you still *have* to use SSH1, at least update to 1.2.32 (ssh.com). The same goes for OpenSSH (I don't know the latest non-vuln version tho). There are many older systems running a vulnerable SSH1 demon, even if it's not needed. Some admins think that SSH for itself means security, but even the best tool can be a threat if it's vulnerable by remote attacks.

Thanks for help, Bye, Annette Sysadmin IfM Technical University Berlin Germany

Good luck, and happy hunting! Boris Lorenz ---