Thursday, May 30, 2013

Another story of Unix Trojan: Tsunami (IRC/Bot) w/ Flooder, Backdoor at a hacked xBSD via Web Panel Attack

*) I dedicate this writing to fellow UNIX admins who dedicate an hourless hard effort for making sure our internet services up and running. #RESPECT!
Snapshot:

Summary

Sadly, some strong waves of malware attacks on UNIX systems has started early this year. We still remember the rush from the Darkleech Rogue Apache Module, goes to Linux cDorked Rogue httpd, to the implementation of rogue web server binaries on other popular web servers like NGNIX and other web servers.

Today I was asked to help fellow unixmen who maintain services based on a generic xBSD which detected some strange activities on IRC port access from several online machines. I was not hoping to see the cDorked or Darkleech new samples or common Linux threat on this one, as a FreeBSD users & fan I know how good the security is, but I guess I was wrong.

This case is actually a same old flaw's story: looks like the system was exploited via web admin panel abuse by HTTP access (sorry, can not tell you which web panel right now) using the tools that can send rapid packet fetch/wget requests (later on we know that the malware discussed here also have that function), the root privilege was gained via crontab UID (root, indeed), and practically overall server's security was compromised from that hole. And the bad guys was compiling nasty downloader/IRC Bot backdoor (known previously named as TSUNAMI) with deleting all source traces+logs related, thus run & hide its service using the fake bash process (ever see a BSD system with bash shell process before? *smile*).

First Handle Analysis

I think is important to share this experience on what to do at the time like this, so I dare myself to write it, with hoping not to step on other's toes. The rule is simple, if they took the root & we take the service offline, no matter what.
OK, shortly, went to the system to find the strange "-bash" process was running:

USER    PID  %CPU %MEM    VSZ    RSS  TT  STAT STARTED    TIME COMMAND
root   96606   0.0  0.2   95939   1096 ??  Ss   28Feb13    0:19.87 -bash
I quickly listen (netstat) to the outbounds to find that the irc ports was trying to be connected:
Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
----------------------------------------------------------------------------
// for IRC....

tcp4       0      0 x.x.x.x.59314     188.190.124.81.ircd    SYN_SENT
tcp4       0      0 x.x.x.x.60606     188.190.124.81.ircd    SYN_SENT
tcp4       0      0 x.x.x.x.46914     188.190.124.81.ircd    SYN_SENT
tcp4       0      0 x.x.x.x.53001     188.190.124.81.ircd    SYN_SENT
tcp4       0      0 x.x.x.x.50123     188.190.124.81.ircd    SYN_SENT
tcp4       0      0 x.x.x.x.36833     188.190.124.81.ircd    SYN_SENT
[...]
And all of the sudden, frequently the FTP access was coming up:
Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
----------------------------------------------------------------------------
// for FTP....
tcp4       0      0 x.x.x.x.64873     wf.networksoluti.ftp   SYN_SENT
tcp4       0      0 x.x.x.x.64873     wf.networksoluti.ftp   SYN_SENT
[...]
Just to be sure, firing lsof on other compromised machine for confirming, and found the same condition:
-bash 95939  root  cwd     VDIR       0,99       1024  869616 /{Directory of the malware}
-bash 95939  root  rtd     VDIR       0,99       1024       2 /
-bash 95939  root  txt     VREG       0,99      18902  870081 {Directory of the malware}/-bash
-bash 95939  root  txt     VREG       0,99     229192   94984 /libexec/ld-elf.so.1
-bash 95939  root  txt     VREG       0,99    1172708  615898 /lib/libc.so.7
-bash 95939  root    0u    VCHR      0,105    0t31989     105 /dev/pts/0
-bash 95939  root    1u    VCHR      0,105    0t31989     105 /dev/pts/0
-bash 95939  root    2u    VCHR      0,105    0t31989     105 /dev/pts/0
-bash 95939  root    3u    VREG       0,99          0  539122 "/tmp/tan.pid"
-bash 95939  root    4u    IPv4 0xc38b4560        0t0     "TCP x.x.x.x:65114->188.190.124.81:ircd (SYN_SENT)"
[...]
This is never be good since all of the requests coming fromthe PID of that "-bash". So I took procedure to take machine offline and continue the analysis.

This is the binary responsible to this disaster, saved in the $TMP:

$ ls -alF
-rwxr-xr-x   1 xxx xxx  18902 May 02 15:11 -bash*
Comparing the dates of process and file time-stamp will lead you to /dev/null so just ignore those and stick to the logs and dumps that might occurred for any traces(if we lucky).
In most machines we got no infection trace on this binary, but one machine which has snapshots leaving a compile trails in logs at a mirror backup storage:
k.c:91: warning: conflicting types for built-in function 'pow'
k.c:586:2: warning: no newline at end of file
Aha, it seems that someone compiled this, you see that the source was in C/C++..
(Seek the source everywhere but couldn't find it.. must be deleted..)

At that point I got no other options but to tear it. apart.. So here we go;

Binary Analysis

Binary structure, is an ELF:

file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08048d20
The ELF header:
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - FreeBSD
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048d20
  Start of program headers:          52 (bytes into file)
  Start of section headers:          13864 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         8
  Size of section headers:           40 (bytes)
  Number of section headers:         28
  Section header string table index: 25
Hex:
0000   7F 45 4C 46 01 01 01 09 00 00 00 00 00 00 00 00    .ELF............
0010   02 00 03 00 01 00 00 00 20 8D 04 08 34 00 00 00    ........ ...4...
0020   28 36 00 00 00 00 00 00 34 00 20 00 08 00 28 00    (6......4. ...(.
0030   1C 00 19 00 06 00 00 00 34 00 00 00 34 80 04 08    ........4...4...
0040   34 80 04 08 00 01 00 00 00 01 00 00 05 00 00 00    4...............
0050   04 00 00 00 03 00 00 00 34 01 00 00 34 81 04 08    ........4...4...
0060   34 81 04 08 15 00 00 00 15 00 00 00 04 00 00 00    4...............
0070   01 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08    ................
0080   00 80 04 08 94 30 00 00 94 30 00 00 05 00 00 00    .....0...0......
0090   00 10 00 00 01 00 00 00 94 30 00 00 94 C0 04 08    .........0......
00A0   94 C0 04 08 6C 02 00 00 10 09 00 00 06 00 00 00    ....l...........
00B0   00 10 00 00 02 00 00 00 A8 30 00 00 A8 C0 04 08    .........0......
00C0   A8 C0 04 08 C8 00 00 00 C8 00 00 00 06 00 00 00    ................
00D0   04 00 00 00 04 00 00 00 4C 01 00 00 4C 81 04 08    ........L...L...
00E0   4C 81 04 08 18 00 00 00 18 00 00 00 04 00 00 00    L...............
00F0   04 00 00 00 50 E5 74 64 48 30 00 00 48 B0 04 08    ....P.tdH0..H...
0100   48 B0 04 08 14 00 00 00 14 00 00 00 04 00 00 00    H...............
0110   04 00 00 00 51 E5 74 64 00 00 00 00 00 00 00 00    ....Q.td........
0120   00 00 00 00 00 00 00 00 00 00 00 00 06 00 00 00    ................
0130   04 00 00 00 2F 6C 69 62 65 78 65 63 2F 6C 64 2D    ..../libexec/ld-
0140   65 6C 66 2E 73 6F 2E 31 00 00 00 00 08 00 00 00    elf.so.1........
I'd say the attacker are not preparing to aim FreeBSD but they just lucky to get the ones with the good Linux compatibility.

Dynamic Section:

(Why I always seek this section? because:
the dependent binaries and functions for the linker are here)
  NEEDED      libc.so.7
  INIT        0x8048a00
  FINI        0x804a97c
  HASH        0x8048164
  STRTAB      0x804864c
  SYMTAB      0x80482dc
  STRSZ       0x196
  SYMENT      0x10
  DEBUG       0x0
  PLTGOT      0x804c170
  PLTRELSZ    0x178
  PLTREL      0x11
  JMPREL      0x8048888
  REL         0x8048870
  RELSZ       0x18
  RELENT      0x8
  VERNEED     0x8048850
  VERNEEDNUM  0x1
  VERSYM      0x80487e2
[...]
Let's check the sections:
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        08048134 000134 000015 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            0804814c 00014c 000018 00   A  0   0  4
  [ 3] .hash             HASH            08048164 000164 000178 04   A  4   0  4
  [ 4] .dynsym           DYNSYM          080482dc 0002dc 000370 10   A  5   1  4
  [ 5] .dynstr           STRTAB          0804864c 00064c 000196 00   A  0   0  1
  [ 6] .gnu.version      VERSYM          080487e2 0007e2 00006e 02   A  4   0  2
  [ 7] .gnu.version_r    VERNEED         08048850 000850 000020 00   A  5   1  4
  [ 8] .rel.dyn          REL             08048870 000870 000018 08   A  4   0  4
  [ 9] .rel.plt          REL             08048888 000888 000178 08   A  4  11  4
  [10] .init             PROGBITS        08048a00 000a00 000011 00  AX  0   0  4
  [11] .plt              PROGBITS        08048a14 000a14 000300 04  AX  0   0  4
  [12] .text             PROGBITS        08048d20 000d20 001c5c 00  AX  0   0 16
  [13] .fini             PROGBITS        0804a97c 00297c 00000c 00  AX  0   0  4
  [14] .rodata           PROGBITS        0804a988 002988 0006bf 00   A  0   0  4
  [15] .eh_frame_hdr     PROGBITS        0804b048 003048 000014 00   A  0   0  4
  [16] .eh_frame         PROGBITS        0804b05c 00305c 000038 00   A  0   0  4
  [17] .ctors            PROGBITS        0804c094 003094 000008 00  WA  0   0  4
  [18] .dtors            PROGBITS        0804c09c 00309c 000008 00  WA  0   0  4
  [19] .jcr              PROGBITS        0804c0a4 0030a4 000004 00  WA  0   0  4
  [20] .dynamic          DYNAMIC         0804c0a8 0030a8 0000c8 08  WA  5   0  4
  [21] .got.plt          PROGBITS        0804c170 003170 0000c8 04  WA  0   0  4
  [22] .data             PROGBITS        0804c240 003240 0000c0 00  WA  0   0 32
  [23] .bss              NOBITS          0804c300 003300 0006a4 00  WA  0   0 32
  [24] .comment          PROGBITS        00000000 003300 000248 00      0   0  1
  [25] .shstrtab         STRTAB          00000000 003548 0000e0 00      0   0  1
  [26] .symtab           SYMTAB          00000000 003a88 000950 10     27  48  4
  [27] .strtab           STRTAB          00000000 0043d8 0005fe 00      0   0  1
Tips for the unknown system: Is important to see the comments, to be sure it was compiled in the victim's environment (I did this to all infected m/c samples)
// Contents of section .comment:
 0000 00244672 65654253 443a2072 656c656e  .$FreeBSD: relen
 0010 672f392e 302f6c69 622f6373 752f6933  g/9.0/lib/csu/i3
 0020 38362d65 6c662f63 7274315f 732e5320  86-elf/crt1_s.S
 0030 32313733 38332032 3031312d 30312d31  217383 2011-01-1
 0040 33203233 3a30303a 32325a20 6b696220  3 23:00:22Z kib
 0050 24000024 46726565 4253443a 2072656c  $..$FreeBSD: rel
By firing rabin I got the imports symbol:
[Imports]
48 imports /* <======== noted */
_Jv_RegisterClasses
__error
__inet_addr
_init_tls
atexit
bcopy
close
[...]
And these are malicious command activities used:
gethostbyname connect
sleep         setsockopt
fopen         vsprintf
time          __isthreaded
strtok        write
environ       flock
socket        fork
free          srand
popen         strdup
strcpy        [...]
[...]
Got some traces on HTTP connectivity:
http://
cvv4you.ru         // hosts...
188.190.124.120
GET /%s HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686)
Host: %s:80
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
IRC Messages:
PRIVMSG %s :GET  
PRIVMSG %s :Unable to create socket.
PRIVMSG %s :Unable to resolve address.
PRIVMSG %s :Unable to connect to http.
IRC Commands:
PRIVMSG %s :Receiving file.
PRIVMSG %s :Saved as %s
PRIVMSG %s :NICK <nick>
PRIVMSG %s :Nick cannot be larger than 9 characters.
NICK %s
PRIVMSG %s :Unable to resolve %s
PRIVMSG %s :MOVE <server>
NOTICE %s :NICK <nick>                    = Changes the nick of the client
NOTICE %s :SERVER <server>                = Changes servers
NOTICE %s :KILL                           = Kills the client
NOTICE %s :GET <http address> <save as>   = Downloads a file off the web and saves it onto the hd
NOTICE %s :HELP                           = Displays this
NOTICE %s :IRC <command>                  = send_msgs this command to the server
NOTICE %s :SH <command>                   = Executes a command
NICK
SERVER
KILL
HELP
IRC
PRIVMSG %s :%s
MODE %s -ix
NICK %s
JOIN %s :%s
WHO %s
PONG %s
PRIVMSG %s :I'm having a problem resolving my host, someone will have to SPOOFS me manually.
PRIVMSG
PING
Traces of read/write strings manipulation in C/Unix:
fputc
fgets
At this point also I saw the PID control traces:
// PID hooks:
waitpid
/tmp/tan.pid
Lockfile found. Exiting.
- bash // malware process..
I confirmed the the admins that infected xBSD systems wasn't affected but on linux the below system commands will exactly bring a chaos:
export PATH=/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin;%s
But these commands does:
gethostbyname
kill
environ

A quick Reversing

Practically, if you do up to the above steps then you can make a very good report about this incident, is just to my curiosity I reversed it to find the important functions used below:

Messaging..

// ref: unix socket programming
// send_msg uses a global variable buffer 
# 08048fc0 <send_msg>:
08048fc0: push   %ebp
08048fc1: mov    %esp,%ebp
08048fc3: sub    $0x28,%esp
08048fc6: lea    0x10(%ebp),%eax
08048fc9: mov    %eax,-0x4(%ebp)
08048fcc: mov    -0x4(%ebp),%eax
08048fcf: mov    %eax,0x8(%esp)
08048fd3: mov    0xc(%ebp),%eax
08048fd6: mov    %eax,0x4(%esp)
08048fda: movl   $0x804c340,(%esp)
08048fe1: call   0x08048c74 <vsprintf@plt>
08048fe6: movl   $0x804c340,(%esp)
08048fed: call   0x08048b84 <strlen@plt>
08048ff2: mov    %eax,0x8(%esp)
08048ff6: movl   $0x804c340,0x4(%esp)
08048ffe: mov    0x8(%ebp),%eax
08049001: mov    %eax,(%esp)
08049004: call   0x08048cf4 <write@plt>
08049009: leave  
0804900a: ret    
0804900b: nop    
A self-lookups...
# 08049730 <host2ip>:
08049730: push   %ebp
08049731: mov    %esp,%ebp
08049733: sub    $0x28,%esp
08049736: mov    0xc(%ebp),%eax
08049739: mov    %eax,(%esp)
0804973c: call   0x08048a94 <__inet_addr@plt>
08049741: mov    %eax,0x804c740
08049746: mov    0x804c740,%eax
0804974b: cmp    $0xffffffff,%eax
0804974e: jne    0x080497b7 <host2ip+0x87>
08049750: mov    0xc(%ebp),%eax
08049753: mov    %eax,(%esp)
08049756: call   0x08048c14 <gethostbyname@plt>
0804975b: mov    %eax,-0x4(%ebp)
0804975e: cmpl   $0x0,-0x4(%ebp)
08049762: jne    0x08049793 <host2ip+0x63>
08049764: mov    0x804c760,%eax
08049769: mov    0xc(%ebp),%edx
0804976c: mov    %edx,0xc(%esp)
08049770: mov    0x8(%ebp),%edx
08049773: mov    %edx,0x8(%esp)
08049777: movl   $0x804abf8,0x4(%esp)
0804977f: mov    %eax,(%esp)
08049782: call   0x08048fc0 <send_msg>
08049787: movl   $0x0,(%esp)
0804978e: call   0x08048cb4 <exit@plt>
08049793: mov    -0x4(%ebp),%eax
08049796: mov    0xc(%eax),%eax
08049799: mov    %eax,%edx
0804979b: mov    -0x4(%ebp),%eax
0804979e: mov    0x10(%eax),%eax
080497a1: mov    (%eax),%eax
080497a3: mov    %edx,0x8(%esp)
080497a7: movl   $0x804c740,0x4(%esp)
080497af: mov    %eax,(%esp)
080497b2: call   0x08048c44 <bcopy@plt>
080497b7: mov    0x804c740,%eax
080497bc: leave  
080497bd: ret    
080497be: xchg   %ax,%ax
This is how it grab stuff from "mother" remote host:
# 080492a0 <get>:
080492a0: push   %ebp
080492a1: mov    %esp,%ebp
080492a3: push   %ebx
080492a4: sub    $0x1454,%esp
080492aa: mov    0xc(%ebp),%eax
080492ad: mov    %eax,(%esp)
080492b0: call   0x08049010 <mfork>
080492b5: test   %eax,%eax
080492b7: jne    0x0804969e <get+0x3fe>
080492bd: cmpl   $0x1,0x10(%ebp)
080492c1: jg     0x080492e9 <get+0x49>
080492c3: mov    0xc(%ebp),%eax
080492c6: mov    %eax,0x8(%esp)
080492ca: movl   $0x804a9a8,0x4(%esp)
080492d2: mov    0x8(%ebp),%eax
080492d5: mov    %eax,(%esp)
080492d8: call   0x08048fc0 <send_msg>
080492dd: movl   $0x0,(%esp)
080492e4: call   0x08048cb4 <exit@plt>
080492e9: movl   $0x0,0x8(%esp)
080492f1: movl   $0x1,0x4(%esp)
080492f9: movl   $0x2,(%esp)
08049300: call   0x08048ae4 <socket@plt>
08049305: mov    %eax,-0x28(%ebp)
08049308: cmpl   $0xffffffff,-0x28(%ebp)
0804930c: jne    0x08049334 <get+0x94>
[...]
Checksum of the grabs...
# 08049210 <in_cksum>:
08049210: push   %ebp
08049211: mov    %esp,%ebp
08049213: sub    $0x1c,%esp
08049216: mov    0xc(%ebp),%eax
08049219: mov    %eax,-0x1c(%ebp)
0804921c: mov    0x8(%ebp),%edx
0804921f: mov    %edx,-0x18(%ebp)
08049222: movl   $0x0,-0x14(%ebp)
08049229: movw   $0x0,-0x2(%ebp)
0804922f: jmp    0x08049245 <in_cksum+0x35>
08049231: mov    -0x18(%ebp),%edx
08049234: movzwl (%edx),%eax
08049237: movzwl %ax,%eax
0804923a: add    %eax,-0x14(%ebp)
0804923d: addl   $0x2,-0x18(%ebp)
08049241: subl   $0x2,-0x1c(%ebp)
08049245: cmpl   $0x1,-0x1c(%ebp)
08049249: jg     0x08049231 <in_cksum+0x21>
0804924b: cmpl   $0x1,-0x1c(%ebp)
0804924f: jne    0x08049266 <in_cksum+0x56>
08049251: lea    -0x2(%ebp),%edx
08049254: mov    -0x18(%ebp),%eax
[...]
move stuff to somewhere else...
# 080497c0 <move>:
080497c0: push   %ebp
080497c1: mov    %esp,%ebp
080497c3: sub    $0x18,%esp
080497c6: cmpl   $0x0,0x10(%ebp)
080497ca: jg     0x080497f2 <move+0x32>
080497cc: mov    0xc(%ebp),%eax
080497cf: mov    %eax,0x8(%esp)
080497d3: movl   $0x804ac1a,0x4(%esp)
080497db: mov    0x8(%ebp),%eax
080497de: mov    %eax,(%esp)
080497e1: call   0x08048fc0 <send_msg>
080497e6: movl   $0x1,(%esp)
080497ed: call   0x08048cb4 <exit@plt>
080497f2: mov    0x14(%ebp),%eax
080497f5: add    $0x4,%eax
080497f8: mov    (%eax),%eax
080497fa: mov    %eax,(%esp)
080497fd: call   0x08048b34 <strdup@plt>
08049802: mov    %eax,0x804c888
08049807: movl   $0x1,0x804c320
08049811: mov    0x8(%ebp),%eax
08049814: mov    %eax,(%esp)
08049817: call   0x08048b54 <close@plt>
0804981c: leave  
0804981d: ret    
0804981e: xchg   %ax,%ax
Termination of self created process (hooked at IRC/FTP timeout retries access)
# 08049820 <killd>:
08049820: push   %ebp
08049821: mov    %esp,%ebp
08049823: sub    $0x8,%esp
08049826: movl   $0x9,0x4(%esp)
0804982e: movl   $0x0,(%esp)
08049835: call   0x08048cc4 <kill@plt>
0804983a: leave  
0804983b: ret    
0804983c: lea    0x0(%esi),%esi
The below are functions related to the (strongly suspected) flood operation:
# 08049010 <mfork>:
08049010: push   %ebp
08049011: mov    %esp,%ebp
08049013: sub    $0x18,%esp
08049016: call   0x08048a84 <fork@plt>
0804901b: mov    %eax,-0xc(%ebp)
0804901e: cmpl   $0x0,-0xc(%ebp)
08049022: jne    0x0804902f <mfork+0x1f>
08049024: mov    -0xc(%ebp),%eax
08049027: mov    %eax,-0x14(%ebp)
0804902a: jmp    0x080490bb <mfork+0xab>
[...]

# 08049120 <makestring>:
08049120: push   %ebp
08049121: mov    %esp,%ebp
08049123: push   %esi
08049124: push   %ebx
08049125: sub    $0x30,%esp
08049128: movl   $0x9,-0x10(%ebp)
0804912f: mov    -0x10(%ebp),%eax
08049132: add    $0x1,%eax
08049135: mov    %eax,(%esp)
08049138: call   0x08048a24 <malloc@plt>
0804913d: mov    %eax,-0x14(%ebp)
08049140: mov    -0x10(%ebp),%eax
08049143: add    $0x1,%eax
08049146: mov    %eax,0x8(%esp)
0804914a: movl   $0x0,0x4(%esp)
08049152: mov    -0x14(%ebp),%eax
08049155: mov    %eax,(%esp)
08049158: call   0x08048c94 <memset@plt>
0804915d: movl   $0x0,-0xc(%ebp)
08049164: jmp    0x080491a8 <makestring+0x88>
08049166: mov    -0xc(%ebp),%eax
[...]

# 080491c0 <pow>: // we saw the compilation warning on this one.. :-)
080491c0: push   %ebp
080491c1: mov    %esp,%ebp
080491c3: sub    $0xc,%esp
080491c6: cmpl   $0x0,0xc(%ebp)
080491ca: jne    0x080491d5 <pow+0x15>
080491cc: movl   $0x1,-0x4(%ebp)
080491d3: jmp    0x08049201 <pow+0x41>
080491d5: cmpl   $0x1,0xc(%ebp)
080491d9: jne    0x080491e3 <pow+0x23>
080491db: mov    0x8(%ebp),%eax
080491de: mov    %eax,-0x4(%ebp)
080491e1: jmp    0x08049201 <pow+0x41>
080491e3: mov    0xc(%ebp),%eax
080491e6: sub    $0x1,%eax
[...]
And there are so many more...
** For a complete reverse note you'll find it here-->>[Pastebin] **

What does it do?

Below are the malware functions that I gathered:

Usage the INET socket to make internet connection via IRC, HTTP or FTP
Locking itself in specific PID to avoid double starts/killed.
Forking functionalities.
Remote control Bot-IRC functions like:
 a. Remote FTP access for infecting further
 b. Commands like:  NICK, SERVER, KILL, GET, HELP, ETC, SH; are the basic commmands used
 c. Custom commands like; _352, _376, _433 for botnet comm purpose.
  d. IMPORTANT! Flooding Operation is implemented in the program, w/ below HTTP header:
......GET /%s HTTP/1.0\
......Connection: Keep-Alive
......User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686)
......Host: %s:80\
......Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
......Accept-Encoding: gzip\r\nAccept-Language: en
......Accept-Charset: iso-8859-1,*,utf-8
......(Following by long characters assembled via IRC command instructions)
Practically, upon started it tries to connect to IRC at below host:
cvv4you.ru     
188.190.124.120
188.190.124.81
It then wait for the boss to connect, to perform some malicious acts.
All of the further hack was implemented via FTP and HTTP used for flood.
For the FTP, it tries to get some stuff in the below host:
Hostname: wf.networksolution.com
Address:  205.178.189.131
↑There should be some bad stuffs in there.

Sample! Sample!

Yes, since I know how hard it feels for not being shared samples, I am currently waiting for permission to share some samples for research purpose, so please hold on. But right now we're allowed to scan it in Virus Total :-) here's the url >>>Link
Here's the details:

SHA256: 6e4586e5ddf44da412e05543c275e466b9da0faa0cc20ee8a9cb2b2dfd48114e
SHA1: 13aa008b0f3c9e92450979ee52cb46accf49aff3
MD5: 6547b92156b39cb3bb5371b17d2488f2
File size: 18.5 KB ( 18902 bytes )
File name: -bash
File type: ELF
Tags: elf
Detection ratio: 7 / 47
Analysis date: 2013-05-30 11:37:36 UTC ( 4 minutes ago )
F-Secure                 : Generic.Malware.IFg.985D9435
GData                    : ELF:Tsunami-L
MicroWorld-eScan         : Generic.Malware.IFg.985D9435
Avast                    : ELF:Tsunami-L [Trj]
Kaspersky                : Backdoor.Linux.Tsunami.gen
BitDefender              : Generic.Malware.IFg.985D9435
Emsisoft                 : Generic.Malware.IFg.985D9435 (B)

Additional:

(1) After some research, I found this malware is known by its self compiled method on a hacked machine. Well known as Kaiten a Linux/Unix DDOS IRC Bot←thank's for the @exitthematrix of KM. (2) The similar attack was also found in the site with the Ruby on Rails Web Admin Panel vulnerability posted by Mr. Jeff Jarmoc in his site jarmoc.com, he detected the traces of source code used during compilation of the malware and posted it in his blog here -->>[JARMOC.COM]. After some comparison I found the strong possibility that the same malware code and same bad actor was used in both case. Since the both findings was detected in so near time, I bet there are other servers also under attack with the similar pattern and malware so please check your system regularly.

MalwareMustDie!!

6 comments:

  1. Once again, Good stuff! Thanks!

    One old lesson learned though: we do not need compilers(or other unnecessary SW) on production systems.

    Keep it up!

    regards

    @malforsec

    ReplyDelete
  2. Just in case you probably don't know, allow me to explain: principles of packages on xxxBSD are distributed via "ports" system which actually required to compile the every upated/new package. Is different w/Linux which most distribution providing specific precompiled binaries. So the built environment are mostly in there, in this case is rare since the systems were supported elf compatibility for the system purpose which in not included in most of default xxxBSD (we need to set those up), so the malware was compiled w/bugs during compilation (like I saw that the pow function wasn't run well during reversing). rgds @unixfreaxjp

    ReplyDelete
  3. very good analysis. I got a box infected by this code. You made a very clean scenario of what the uploaded files does, but i can't find the way the came inside.. i mean, in Rubyonrail exploit was used the same payload and we know the exploit technique.. did you got more info about the exploit technique used on the boxes you was looking at?
    Thanks and nice article!

    ReplyDelete
  4. Hello there, i've maybe posted twice (soryy about that). I want to say this is very informative article and you made a good analysis of the payload infection.
    As stated above, the same payloads were used with a ruby vuln on a close timespan. I had a box exploited and i found the same botnet running on it.. i just wonder if you got more infoes about the exploit technique used on the box, because i can't find any useful log/traces and nothing on google talking about an exploit used in this scenario.
    Anyway, very good blog!

    ReplyDelete