Security Art Work

Hoy martes traemos una entrada de Salvador Silvestre, de la firma Rocabert & Grau Abogados, bufete que ya ha colaborado anteriormente en Security Art Work.

Entre otras cosas, Salvador es postgrado en el Programa Superior en Derecho de las Telecomunicaciones, Sistemas Audiovisuales y Nuevas Tecnologías del Instituto de Empresa y experto en servicios de e-Administración acreditado por el Consejo General de la Abogacía Española. Asimismo, es Director del Departamento de Derecho Tecnológico, donde imparte cursos y conferencias sobre la materia en foros de relevancia como la Fundación de Estudios Bursátiles y Financieros, Puertos del Estado, universidades públicas, e importantes empresas multinacionales. Esperemos que les guste la entrada.

Cada vez utilizamos menos los documentos en soporte papel, de hecho, la mayoría de documentos en papel que utilizamos “nacen” primero en formato electrónico y luego los imprimimos y firmamos. Me pregunto si le daríamos validez a un documento en soporte papel que no estuviera firmado…

Vayamos ahora a un entorno electrónico. La validez de un documento electrónico, en general, dependerá de si va firmado con firma electrónica avanzada basada en certificado reconocido cumpliéndose los requisitos de la Ley de Firma Electrónica, de forma que no puedan impugnar su validez. Es decir, que sea auténtico, íntegro y esté disponible. Y ello porque con los documentos lo que se pretende es proporcionar pruebas de su contenido para exigir responsabilidades o cumplir con derechos.

[Read more…]

Como todos ustedes sabrán, recientemente tuvimos que trabajar sobre un incidente de seguridad relacionado con un ataque por denegación de servicio distribuido o DDoS. Los atacantes emplearon distintas versiones de la herramienta Low Orbit Ion Cannon, LOIC en adelante, para intentar sobrecargar el tráfico de la web.

Lógicamente tanto en S2Grupo como en el centro de seguridad TIC de la Generalitat Valenciana (CSIRT-cv) preparamos un entorno que nos permitiera disminuir el ataque lo máximo posible para intentar que la web estuviera disponible para los ciudadanos, que al fin y al cabo, son los usuarios de la página web y a los que se les daña con este ataque. Para ello se realizo un estudio de las distintas versiones del LOIC, de su funcionamiento y de los posibles patrones de reconocimiento de los ataques con dos objetivos: frenar e identificar al atacante. Por motivos de seguridad no se suministrarán los patrones empleados.

Durante el estudio pudimos apreciar que existían principalmente tres plataformas: Windows (v1.1.1.23 y 24 principalmente), Linux (loiq-0.3a) y Web JS.

La primera sorpresa fue que dependiendo de las fuentes desde donde se descargara el programa para Windows, su suma SHA era diferente pese a que aparentemente el origen de la descarga indicaba que se trataba de la misma versión. ¿Raro, verdad? Señores, ¿que están ustedes instalando realmente en sus ordenadores?

La otra sorpresa fue al buscar distintos enlaces que tuvieran la versión Web programada mediante JavaScript. Dentro de los muchos enlaces que analizamos, incluidos el LOIC JS versión Sinde, me llamo la atención este (http://loic.megabyet.net/). En este caso, los autores de la web crearon un falso LOIC JS en el cual lo que realmente hacían era registrar desde qué IP, con qué navegador y a qué objetivo quería el atacante producir la DDoS. Por si hay dudas, no enviaba ningún paquete a la víctima.

Después del análisis preliminar obtuvimos varias conclusiones. La primera que algunos binarios del LOIC están modificados para que aparte del LOIC instalé algún tipo de software extra. Recordar que para instalar el LOIC se requiere deshabilitar el antivirus.

La segunda que las versiones Web en JS no son lo que parecen, sin ir más lejos, la versión mostrada con anterioridad era un honeypot. Otro día será un BeEF, MSF o cualquier otra variante.

La tercera, y última, que los ataques LOIC son identificables, y por tanto no son anónimos, por lo que recomendaciones como cambiarse la MAC (leído de algunos foros y canales de IRCs) muestra claramente el desconocimiento del funcionamiento de este tipo de herramientas. Sin ir más lejos, el CSIRT-cv dispone de cada IP que atacó la Web, la duración del ataque y la procedencia de esta.

Tengan cuidado con lo que hacen. El anonimato no es tan sencillo de conseguir. Low Orbit Ion Cannon, bienvenidos a la jungla

Fruto de los últimos tests de penetración que hemos realizado me gustaría compartir con nuestros lectores una herramienta que he desarrollado “Quick-and-dirty” en Python para entornos donde un cortafuegos está bloqueando el tráfico de inicio de conexión TCP de salida a Internet, pero no el UDP. El escenario propuesto se trata de un clásico caso de post explotación donde hemos conseguido ejecutar código como root en una máquina Linux del segmento de usuarios o de DMZ. El problema es que no podemos iniciar conexión de un terminal (telnet, ssh, vnc…) hacia nuestra máquina remota, ni tampoco dado que no hay NAT, desde el atacante al servidor comprometido. Pero gracias al “hábil” administrador del Firewall el tráfico UDP está permitido de salida.

En este momento es donde entra en acción nuestra herramienta, la cual ejecutada en el entorno conquistado, mapeará todos sus puertos TCP al interfaz localhost de la máquina del atacante. Es decir, para conectar a un servicio TCP de la víctima protegido por el Cortafuegos, el atacante tan solo tendrá que conectar a un determinado puerto de su propia interfaz localhost. Toda la comunicación entre el equipo comprometido y el de la víctima, se realizará mediante paquetes UDP, obteniendo un resultado de transformación TCP2UDP. Al comenzar a remitir paquetes de este tipo desde la red interna de la víctima hacia el atacante, el Firewall actualizará su registro interno de “conexiones” UDP abiertas, dejando pasar el paquete de inicio de comunicación hacia el entorno comprometido, debido a la capacidad “conectionless” del protocolo UDP.

La herramienta hace uso de las aplicaciones “packit”, para mantener la comunicación cliente-servidor abierta y la gran “socat”, para la redirección de puertos sin utilizar “fifos”. La gran desventaja de esta herramienta tcp2udp es que todavía no trabaja en entornos Windows (próxima versión en curso). Ésta nos puede ser útil si por ejemplo la ejecución de código remota se ha realizado a través de una vulnerabilidad en una web, o necesitamos mapear servicios internos de la máquina al exterior. Espero os sea útil como lo fue para mí, happy hacking!

Pueden descargar la herramienta desde este enlace: tcp2udp.tar.gz

Quizá con ese descriptivo título sepan ustedes de qué va esta entrada, a tenor de la popularidad que el dichoso fotomontaje ha adquirido en las últimas horas, pero si no es así, se lo resumo. Al parecer, la web diseñada para la campaña de reelección de Gallardón a la alcaldía de Madrid está encabezada por un fotomontaje, que pueden ver debajo, y que presenta varios problemas, algunos de ellos bastante obvios.

El primero y principal es que es una imagen tomada de un banco de imágenes (fotolia, en este caso) y que se encuentra en la cabecera del portal de impuestos de la Generalitat de Catalunya y en la portada del libro ‘Doing Well And Good: The Human Face of the New Capitalism‘. Aunque elmundo.es se empeñe en llamar a eso plagio e incluso citar una posible violación de la Ley Sinde por violación de derechos de autor, a decir por la ausencia de marcas de agua, todo parece indicar que la imagen fue comprada y por tanto ambas acusaciones carecen de todo fundamento y están más basadas en animadversión política del periódico hacia Gallardón que en una violación real de derechos de autor.

[Read more…]

Cuando mis antiguas compañeras de colegio decidieron organizar una reunión (tantos años sin verse hacen olvidar las viejas rencillas) les propuse montar un grupo de Google. Así lo hicimos y llevamos casi dos años con él, conmigo de administradora. En ese tiempo he podido descubrir cuan cándidas son estas mujeres, que, aunque con honrosas excepciones, dan crédito a todo tipo de ofertas y anuncios de soluciones milagrosas, premios inesperados y recompensas sin mayor esfuerzo que el de reenviar un correo a un número determinado de destinatarios. A lo mejor no picarán en el timo de Nigeria, pero sí en bulos como el de Mercadona ofreciendo un vale de 100 euros, o Microsoft un ordenador gratis, o el feng shui diciendo que el mes pasado tenía 5 lunes y por tanto vamos a ser todos más ricos… siempre que reenviemos el correo (dado que el feng shui tiene sus orígenes en la China imperial, no sé yo qué relación tendrá con el correo electrónico, pero en fin… si lo dice la internet)

Claro, estas señoras ya peinan canas y no son ni mucho menos lo que ahora se ha dado en llamar “nativas digitales”, pero hay dos cosas que me parecen aterradoras en todo esto. Por una parte, el pensar que en su mayor parte estas personas tienen hijos, ¿estarán educándolos en la misma credulidad? Por otra, da igual que uno transite por los callejones de la vida o los del ciberespacio, hay ciertas leyes que son universales, como por ejemplo que nadie da los duros a cuatro pesetas (¿o los euros a 20 céntimos?) y esto ellas lo deberían saber.

Sin embargo, lo verdaderamente aterrador es cuando estos ataques de credulidad aparecen en personas de las que, por su formación o profesión, uno esperaba otra cosa. Hace poco leí en el IEEE Spectrum (una revista nada sospechosa de marujeo) una columna escrita por uno de sus articulistas más veteranos, Robert Lucky, en la que confesaba abiertamente haber sido víctima de phishing. Lo sorprendente no es que timos de este tipo, u otros como el timo de Nigeria lleven circulando desde los años noventa, sino que la gente siga picando. Y que lo haga gente de este nivel me deja sin palabras. Que lo hagan los periodistas ya no me sorprende tanto: hace poco leímos un artículo en varios periódicos digitales “serios” que se hacía eco de un estudio supuestamente científico, según el cual mirar un par de tetas durante 10 minutos al día alarga en 5 años la vida de los hombres… De ilusión también se vive, supongo, porque el bulo lleva años circulando. Otros bulos no son tan inocuos, como el que casi le arruina la carrera a Mariah Carey.

Quisiera concluir diciendo que no se puede abdicar del uso de las facultades mentales en ninguna circunstancia. Tampoco cuando algo viene en un correo electrónico, o de internet. Da igual las medidas de protección que pongamos, el eslabón más débil siempre seremos nosotros mismos.

Tras la entrada introductoria y preparatoria del otro día, hoy vamos a empezar con el reto. Lo primero que suelo hacer una vez obtenido los datos iniciales (vistos en la anterior entrada) es crearme una línea de tiempo a nivel de sistemas de ficheros y luego le sumo los datos obtenidos con la lógica que contiene el sistema de ficheros… Seguramente se estarán preguntando que es eso de la lógica que contiene el sistema de ficheros. Es lo que normalmente se denomina “artifacts“. Por ejemplo un fichero ejecutable cuyo dueño ya no existe en el sistema pero el fichero sigue existiendo, un usuario creado con permisos de administración, shellbags, históricos, logs, etc.

Comencemos obteniendo la línea de tiempos del sistema de ficheros. Para ello nos crearemos un directorio, volcaremos la línea de tiempo a un fichero con la herramienta “fls”, unificaremos los datos con un “cat” puesto que el reto presenta distintas imágenes, para finalizar traduciendo y ordenando con “mactime”. Es importante recordar que se nos indicó que la hora del sistema era GMT+6 y este dato deberá ser introducido a la herramienta mactime. Por ello debemos obtener el timezone correspondiente a GMT+6, por ejemplo de esta web. Con el timezone ya podemos ejecutar las ordenes necesarias para obtener la línea de tiempo:

# mkdir /reto/carving/timeline
# for i in `ls honeypot.hda*`; do fls -rp -m / $i > /reto/carving/timeline/$i; done
# cd /reto/carving/timeline
# cat * >> timeline
# mactime -z CST -b timeline >> lineaTiempo

Una vez obtenida, tenemos que estudiar el fichero lineaTiempo muy a fondo. Es importante recordar la fecha del incidente y buscar ficheros cuyos metadatos y datos hayan sido modificados. Pese a que el atacante haya usado herramientas como wipe, srm, touch para borrar sin rastro o cambiar la fecha, es muy complicado que modifique todos los ficheros y directorios a los que ha tenido acceso. Recordemos que el incidente fue a las 23:11 del 7 de noviembre de 2000.

Para analizar la línea de tiempo es necesario entender un poco que se muestra en el fichero lineaTiempo. Cada línea indica un fichero y están ordenadas por fecha, de más antiguas a menos. La línea tiene una serie de columnas que identifican de izquierda a derecha la fecha, el tamaño, MACB, permisos, UID, GID, número de inodo (importantísimo) y nombre del fichero.

Teniendo en cuenta que el ataque fue realizado el 7 de noviembre por la noche, tenemos que buscar modificaciones realizadas por esa fecha. Analizando la línea de tiempo vemos que el 8 de noviembre, unas horas después de detectar el exploit, se han hecho modificaciones algo sospechosas sobre algunos ficheros. Principalmente me llama la atención lo siguiente:

Wed Nov 08 2000 14:25:53 2836    .a.. r/rr-xr-xr-x 0 0 17088 /bin/uptime
Wed Nov 08 2000 14:26:15 0       m.c. r/rrw-r--r-- 0 0 26217 /etc/hosts.deny
Wed Nov 08 2000 14:26:51 1024    .a.. d/drwxr-xr-x 0 0 62497 /etc/rc.d/init.d
Wed Nov 08 2000 14:29:27 63728   .a.. r/rrwxr-xr-x 0 0 16125 /bin/ftp
Wed Nov 08 2000 14:33:42 1024    .a.. d/drwx------ 2 2 58465 /spool/at
Wed Nov 08 2000 14:45:18 161     .a.. r/rrw-r--r-- 0 0 26216 /etc/hosts.allow
                         0       .a.. r/rrw-r--r-- 0 0 26217 /etc/hosts.deny
                         31376   .a.. -/rrwxr-xr-x 0 0 93839 /$OrphanFiles/
                                                             OrphanFile-93839 (deleted)
Wed Nov 08 2000 14:45:19 63      .a.. r/rrw-r--r-- 0 0 26573 /etc/issue.net
Wed Nov 08 2000 14:45:24 1504    .a.. r/rrw-r--r-- 0 0 18147 /etc/security/console.perms
Wed Nov 08 2000 14:51:37 2129920 m... -/rrw-r--r-- 500 500 8133 /$OrphanFiles/
                                                                OrphanFile-8133 (deleted)
                         5324    .a.. r/rrwxr-xr-x 1010 100 109808 /man/.Ci/sp.pl
                         132785  .a.. r/rrwxr-xr-x 1010 100 109809 /man/.Ci/qs
                         350996  .a.. r/rrwxr-xr-x 1010 100 109812 /man/.Ci/syslogd

...

Wed Nov 08 2000 14:52:09 9        m.c. l/lrwxrwxrwx 0 0 23 /.bash_history -> /dev/null
                         9        m.c. l/lrwxrwxrwx 0 0 46636 /root/.bash_history -> 
						              /dev/null

(Y un ejército de ficheros huérfanos...)

¿Os acordáis de las tablas realizadas en la primera entrada? Si las consultamos obtenemos que m-c corresponde a la modificación del contenido del fichero. Si analizamos que ficheros han sido modificados obtenemos que “/etc/hosts.deny” y los history han sido modificados. Por un lado tenemos el típico enlace dinámico del bash_history al /dev/null para evitar que registre (¿porque no usar unset HISTFILE que canta menos? El atacante sabrá…), por otro lado tenemos que el hosts.deny ha sido modificado, con lo que probablemente se habrá eliminado alguna restricción de conexión con otros hosts (estaría bien tener acceso a las copias de seguridad previas al incidente para ver la configuración del fichero). También llama la atención el directorio “/man/.Ci”, apuntamos para repasar.

A su vez, vemos que existe un fichero huérfano (fichero eliminado cuyo padre también ha sido eliminado), que indica que el propietario es el usuario 500. Apuntamos; es importante revisar si el usuario existe en /etc/passwd. Por otro lado hay que destacar que el enlace dinámico a /dev/null ha sido realizado después de eliminar el fichero, por lo que es posible que obtengamos las órdenes ejecutadas en el bash_history a partir de los bloques libres (tras la eliminación, el bloque ha quedado asignado como libre, pero la información no ha sido eliminada).

Vamos a obtener los bloques, en crudo o raw, no asignados a ningún inodo, y por tanto, los bloques libres con el objetivo de buscar en ellos órdenes, firmas de malware u otro tipo de documentos. Para ello primeramente nos crearemos el directorio “/reto/carving/unallocated”, y estando en el directorio “/reto/dd” volcaremos los bloques sin asignar en el directorio unallocated:

# mkdir /reto/carving/unallocated
# for i in `ls honeypot.hda*`; do blkls -f ext2 $i > ../carving/unallocated/$i; done

Ahora ya tenemos los bloques libres, veamos a ver si encontramos alguna orden referente a los bash_history o host.deny. Para ello nos creamos un fichero en /reto/etc/ficheros que contenga ficheros que vamos a ir necesitando para el caso:

# echo "bash_history" > /reto/etc/ficheros
# echo "hosts.deny" >> /reto/etc/ficheros
# cd /reto/carving/unallocated
# srch_strings -a -td -5 * | grep -i -f /reto/etc/ficheros

  723938826 rm -rf /root/.bash_history
  723938853 ln -s /dev/null /root/.bash_history
  723938889 rm -rf /.bash_history
  723938911 ln -s /dev/null /.bash_history
  723938942 rm -rf ~games/.bash_history

...

  32494603 chmod a-w ~/.bash_history
  92321290 rm -rf /root/.bash_history
  92321317 ln -s /dev/null /root/.bash_history

...

  92321564 ln -s /dev/null /usr/games/.bash_history
  211349515 chmod a-w ~/.bash_history

...

  160623032 rm -rf /etc/hosts.deny
  160623055 touch /etc/hosts.deny
  212043412 @@contents /etc/hosts.deny 8

A partir de los resultados anteriores, vemos claramente la orden de eliminación del fichero hosts.deny, así como la creación con posterioridad. Lo mismo para los bash_history. Con lo anterior sacamos la conclusión de que a las 14:26:15 del miércoles 8 de noviembre el fichero hosts.deny fue modificado y a las Wed Nov 08 2000 14:52:09 se borraron las huellas del history. Se podría intentar sacar el contenido antiguo del fichero hosts.deny intentando pensar qué texto podría contener. Si pensamos detenidamente un tag típico sería el ALL por lo que con la orden

# srch_strings -a -td -3 * | grep "ALL:"

se podría obtener la línea del bloque donde se encuentra la información, pero en este caso, no da resultados. Ahora nos toca analizar más detenidamente la línea donde se ilustra la eliminación del fichero hosts.deny: “160623032 rm -rf /etc/hosts.deny”. Ese valor 160623032 identifica el byte donde la cadena fue encontrada. Como sabemos el tamaño del bloque es 1024 por tanto dividímos los 160623032 entre 1024 y nos quedamos con la parte entera, es decir, 156858. Ahora pensemos: estamos analizando los bloques libres de una imagen raw, por tanto necesitamos saber qué bloque real ocupa el bloque libre 156858 en la imagen completa, para ello usamos blkcalc:

# blkcalc /reto/dd/honeypot.hda8.dd -u 156858 
188701

Ahora ya sabemos que en el bloque de la imagen completa está la orden “rm -rf /etc/hosts.deny”. Veamos ahora el contenido del bloque, el cual debería corresponder con la parte del fichero “bash_history” que intentó ocultar el atacante:

# blkcat /reto/dd/honeypot.hda8.dd 188701

...

exit
uptime
rm -rf /etc/hosts.deny
touch /etc/hosts.deny
rm -rf /var/log/wtmp
touch /var/log/wtmp
killall -9 klogd
killall -9 syslogd
rm -rf /etc/rc.d/init.d/*log*
echo own:x:0:0::/root:/bin/bash >> /etc/passwd
echo adm1:x:5000:5000:Tech Admin:/tmp:/bin/bash >> /etc/passwd
echo own::10865:0:99999:7:-1:-1:134538460 >> /etc/shadow
echo adm1:Yi2yCGHo0wOwg:10884:0:99999:7:-1:-1:134538412 >> /etc/shadow
cat /etc/inetd.conf | grep tel
exit

Efectivamente, vemos que se trata del bash_history real, donde por un lado se ha hecho una purga de los logs y de los demonios que lo generan. Por otro lado se han creado dos usuarios, “own” y “adm1”. El primero con privilegios de root y el segundo con uid 5000. Con esto queda demostrado que el equipo ha sido comprometido.

El siguiente paso es comprobar que acciones adicionales han sido llevadas a cabo por el atacante y que utilidad estaba obteniendo éste del servidor. Para ello vamos a montar el entorno en forma de solo lectura y comenzar a comprobar las huellas obtenidas con anterioridad del sistema de ficheros:

• ¿Initd sigue teniendo la puerta trasera?
• Usuario 500, ¿quien es?
• ¿Usuario own existe?
• ¿Usuario adm1 (5000) existe?
• ¿Que hay en el directorio /man/.Ci”

Para montar el sistema de ficheros he creado una script de forma que ejecutándolo monte o desmonte el sistema. Lo he creado en el directorio “/reto/dd” con nombre montar.sh y posteriormente le he asignado permisos de ejecución:

# touch /reto/dd/montar.sh
# chmod u+x /reto/dd/montar.sh
# vim /reto/dd/montar.sh

#!/bin/bash --
if [ "$1" == "1" ];
then
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda8.dd /reto/mnt/
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda1.dd /reto/mnt/boot/
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda6.dd /reto/mnt/home/
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda5.dd /reto/mnt/usr/
 /bin/mount -o loop,ro,noatime,noexec /reto/dd/honeypot.hda7.dd /reto/mnt/var/
else
 /bin/umount /reto/mnt/boot/
 /bin/umount /reto/mnt/usr/
 /bin/umount /reto/mnt/var/
 /bin/umount /reto/mnt/home/
 /bin/umount /reto/mnt/
fi

De esta forma, ejecutando “/reto/dd/montar.sh 1” monto el entorno y con “/reto/dd/montar.sh 0” lo desmonto. Así que ya sabéis, a montar el entorno toca:

# /reto/dd/montar.sh 1

Una vez montado comprobamos las consultas anteriores:

• Las modificaciones en el servicio inetd durante el ataque no existe.
• El usuario 500 es Drosen y existía antes del ataque.
• El usuario own y adm1 no existen.
• El directorio /man/.Ci existe:

  # find /reto/mnt/ -type d -name ".Ci"
  /reto/mnt/usr/man/.Ci

El siguiente paso consistirá en analizar el directorio “/reto/mnt/usr/man/.Ci” para revisar que hay dentro y ya les adelanto que nos encontramos una jungla:

# ls /reto/mnt/usr/man/.Ci
addn  backup  chmod-it  do  fix  killall  paki  q  rmS  snap  sniff.pid  syslogd
a.sh  addps  bx  clean  find  inetd  needz  pstree  qs  scan  snif  sp.pl  tcp.log

Empleemos con los ficheros anteriores la herramienta “file” que me permite clasificar los ficheros:

# file * | grep -v ELF | grep -v directory
a.sh: ASCII text
addps: POSIX shell script text executable
chmod-it: ASCII text
clean: ASCII text
do: ASCII text
needz: POSIX shell script text executable
rmS: POSIX shell script text executable
snap: POSIX shell script text executable
sniff.pid: ASCII text
sp.pl: a /usr/bin/perl script text executable
tcp.log: empty

Veamos que contienen los ficheros:

• El fichero “a.sh” contiene la eliminación de binarios y parada de los servicios de esos binarios, todo apunta a que esto es el paso previo a la implantación de un RootKit a nivel de aplicación (porque como sea a nivel de núcleo difícil lo tenemos).
• El fichero “addps” introduce en el fichero “/dev/ptyp” procesos, que según indica la propia documentación, son aquellos procesos que se quieren ocultar. Al mostrar el contenido del fichero vemos lo siguiente:

  ...
  2 snif
  2 pscan
  2 slice2
  2 snif
  2 pscan
  2 telnet
  2 x
  2 xscan
  2 ssh
  ...

• El fichero “needz” muestra la dirección web de las herramientas pico y screen.
• El fichero “rmS” elimina paquetes de software “ssh”, “wuftpd” y “nfs”.
• El fichero “sp.pl” es un script en perl que levanta el sniffer “LinSniffer”, que escucha en una serie de puertos donde los password se transmiten en claro. Existe también un fichero Sniff.pid que contiene un número, que todo apunta a que se trata del PID del proceso, y por tanto, podemos creer que el sniffer llegó a ejecutarse…
• El fichero “tcp.log” está vacío.
• El fichero “do” contiene la eliminación de los usuarios “own” y “adm1” que encontramos al recuperar el bash_history real del usuario. Por tanto ya sabemos a ciencia cierta que el atacante creó dos usuarios, uno de ellos root, y que posteriormente los eliminó, por lo que todo indica que ha conseguido acceso a la máquina sin necesitar usuarios en el entorno.
• El fichero “chmod” cambia permisos a varios binarios, volviéndolos igual o más restrictivos que los de serie en la distribución. Esto huele cada vez más a rootkit a nivel de aplicación.
• El fichero “clean” ejecuta el fichero “snap” introduciéndole varias opciones. Ahora veremos que contiene “snap”.
• El fichero “snap” es una shell en bash que dado una palabra quita todo rastro de esa palabra en los logs.

En cuanto a los directorios tenemos “backup”, “paki” y “scan”:

• El directorio “backup” contiene los binarios de archivos importantes como ifconfig, ps o ls. He realizado una simple comprobación para ver si los binarios que están en backup son los mismos que los que tiene instalados el servidor, pero no, difieren:

  # md5sum backup/ls ../../../bin/ls
  5ec59b9c05706b4ce65adf44d0d3ab24 backup/ls
  06be0dbe8e41a0266eeeeeb1c1b4c818 ../../../bin/ls

• El directorio “paki” contiene dos herramientas. La primera es el código del stream y la segunda es slice2 cuya finalidad es la denegación de servicio (DoS).
• El directorio “scan” contiene un gran número de ficheros cuyo objetivo es escanear host de la red e intentar ejecutar exploits sobre la máquina y crear puertas traseras. Si analizamos el código del “amd” vemos que intenta explotar vulnerabilidades en el RPC. Curiosamente es la misma vulnerabilidad con que ha sido comprometido el servidor.

En definitiva se trata de un RootKit a nivel de aplicación que permite mantener el control de la máquina, sniffar el tráfico de esta, atacar otras máquinas, ocultar huellas, ocultar procesos, etc. Buscando un poco por internet por si fuera un RootKit conocido he encontrado esta entrada que detalla bastante bien el RootKit.

El último paso a llevar a cabo es comprobar cómo consigue el atacante conectar a la máquina. Acordaos que hemos visto ficheros que borraban los instaladores de varios servicios. A su vez un par de cuentas que luego fueron eliminadas. Algo raro, ¿verdad? Podría tratarse de una escalada de privilegios mediante ficheros suid, pero para ello necesitaría un usuario no privilegiado en el sistema, pero también lo ha borrado. Lo más recomendado es volver a la línea de tiempo por si pudiera proporcionarlos un poco más de información.

Si analizamos detenidamente la fecha de implantación del RootKit veremos las siguientes entradas:

Wed Nov 08 2000 14:53:12 343586 mac. r/rrwxr-xr-x 0 0 110004 /local/bin/ssh-agent1
                         10     mac. l/lrwxrwxrwx 0 0 110005 /local/bin/ssh-agent -> 
                                                             ssh-agent1
                         337617 mac. r/rrwxr-xr-x 0 0 110006 /local/bin/ssh-add1
                         8      mac. l/lrwxrwxrwx 0 0 110007 /local/bin/ssh-add -> ssh-add1
                         90424  mac. r/rrwxr-xr-x 0 0 110008 /local/bin/scp1
                         4      mac. l/lrwxrwxrwx 0 0 110009 /local/bin/scp -> scp1
                         21228  mac. r/rrwxr-xr-x 0 0 110010 /local/bin/
                                                             make-ssh-known-hosts1
                         21     mac. l/lrwxrwxrwx 0 0 110011 /local/bin/
                                                             make-ssh-known-hosts ->
                                                             make-ssh-known-hosts1
                         643674 m.c. r/rrwxr-xr-x 0 0 33115 /local/sbin/sshd1
                         5      m.c. l/lrwxrwxrwx 0 0 33116 /local/sbin/sshd -> sshd1

Ya con esto nos sobra para despejar dudas. Es lógico que si el atacante requiere un servicio que no está disponible en el sistema lo instale, pero que existiendo el servicio instale uno nuevo y adicionalmente añada al nombre del servicio un 1 y que los binarios del servicio original sean ahora simples enlaces dinámicos al servicio añadido por el atacante, nos indica una cosa: el servidor sobreescrito está modificado para permitir la autenticación directa del atacante sin pasar por los métodos tradicionales.

Accedamos al directorio “/reto/mnt/usr/local/bin” y analicemos los ficheros modificados por el atacante. Lo que primero nos llama la atención es el SUID del fichero ssh1. Pero más que eso nos interesa ver el servicio que se arranca el SSH (“sshd1”) que se encuentra en el “/reto/mnt/usr/local/sbin”. Una forma sencilla de poder analizar el binario sshd1 es usar de nuevo un srch_strings, aunque lógicamente lo mejor sería usar el gdb, pero esto requeriría varias entradas en el blog dedicadas únicamente al gdb. Bien veamos qué strings nos muestra esto:

# srch_strings -a -td sshd1
...
146880 d33e8f1a6397c6d2efd9a2aae748eb02
...
148316 /usr/tmp/nap
148352 +-[ User Login ]-------------------- --- --- - -
148416 | username: %s password: %s hostname: %s
148480 +----------------------------------- ----- --- -- -- -
...
543582 md5.h
...
550891 md5passwd:(0,30)=ar(0,1);0;32;(0,2)
550927 md:(126,2)
550938 md5buffer:(0,31)=ar(0,1);0;31;(0,11)
...

Me llaman la atención dos cosas: por un lado la primera entrada ya que esa forma de cadena me recuerda mucho al hash de un MD5, y la segunda el “/usr/tmp/nap” y el trozo de código a continuación. Veamos primero que hay en “/reto/mnt/usr/tmp/nap”:

# cat /reto/mnt/usr/tmp/nap
+-[ User Login ]-------------------- --- --- - -
| username: root password: tw1Lightz0ne hostname: c871553-b.jffsn1.mo.home.com
+----------------------------------- ----- --- -- -- -

Lo que pensaba: el SSH aparte de supuestamente permitir al atacante autenticarse sin necesidad de tener usuario en el sistema, está registrando los usuarios y contraseñas que acceden al SSH. Apuntamos el usuario y la contraseña. Revisamos la contraseña del usuario root del entorno y vemos que se trata de un MD5 ($1$), con semilla “eJ2yI2DF” y hash “0cXQKjrEYcYHM/qJu2X6Z”. Vamos a usar el John the Ripper para comprobar si el usuario de root identificado en el fichero es el mismo que el del sistema:

# apt-get install john
# cd /reto/aux/
# echo "tw1Lightz0ne" > passwd
# unshadow /reto/mnt/etc/passwd /reto/mnt/etc/shadow >> patata
# john --wordlist=passwd patata

Loaded 2 password hashes with 2 different salts (FreeBSD MD5 [32/32])
guesses: 0  time: 0:00:00:00 100%  c/s: 200  trying: tw1Lightz0ne

Curiosamente la contraseña guardada no pertenece al usuario root del sistema… Bueno dejemos esto apartado y recordemos el MD5 visto con anterioridad en el binario ssh1. Lo que vamos a ver es qué contraseña ha podido generar ese MD5. Se me ocurre una cosa bárbara y es que la contraseña guardada en el fichero sea la contraseña del atacante y el registro de contraseña no tenga una comprobación para evitar que la propia contraseña del atacante se registre… veamos a ver:

# echo "tw1Lightz0ne" | md5sum -
367d375770a5775c4a63d1862e2fceaf  -

No hay suerte. Algo se escapa… mmm claro, el salto de línea que añade el echo:

# echo -n "tw1Lightz0ne" | md5sum
d33e8f1a6397c6d2efd9a2aae748eb02

Bueno, pues al final el hash que hay en el servicio corresponde con el MD5 que está guardado en el fichero, y por tanto, el propio atacante ha dejado el registro de su acceso en el log de usuarios y contraseñas. Podemos apuntar el hostname “c871553-b.jffsn1.mo.home.com” como posible origen del atacante.

Para finalizar con el SSH vamos a comprobar si el servicio se inicia en caso de que el sistema se reinicie, para ello buscaremos en los scripts de arranque:

# grep ":initdefault" /reto/mnt/etc/inittab
id:3:initdefault:
# ls -l /reto/mnt/etc/rc.d/rc3.d/
...
lrwxrwxrwx 1 root root 11 Nov  5  2000 S99local -> ../rc.local

No vemos ningún enlace que identifique al SSH, pero si analizamos todos los enlaces del directorio anterior encontramos que al final el enlace dinámico “S99local”, el cual apunta al fichero “rc.local”, es el encargado de arrancarlo:

# grep -i ssh /reto/mnt/etc/rc.d/rc.local
/usr/local/sbin/sshd1

Una vez finalizado la manera que tiene el atacante de acceder al servidor, vamos a seguir analizando la línea de tiempo:

314    ..c. r/rrw-r--r-- 0 0 16195 /etc/pam.d/ftp
314    ..c. r/rrw-r--r-- 0 0 16195 /etc/pam.d/ftp-RPMDELETE (deleted-realloc)
8928   ..c. r/rrwxr-xr-x 1 1 17487 /bin/ftpcount
8928   ..c. r/rrwxr-xr-x 1 1 17488 /bin/ftpwho
8928   ..c. r/rrwxr-xr-x 1 1 17488 /bin/ftpwho-RPMDELETE (deleted-realloc)
484    ..c. r/rrw------- 0 0 26548 /etc/ftpaccess
456    ..c. r/rrw------- 0 0 26549 /etc/ftpconversions
39     ..c. r/rrw------- 0 0 26550 /etc/ftpgroups 1
04     ..c. r/rrw------- 0 0 26551 /etc/ftphosts
79     ..c. r/rrw------- 0 0 26552 /etc/ftpusers
180703 ..c. r/rrw-r--r-- 1010 100 109865 /man/.Ci/nfs-utils-0.1.9.1-1.i386.rpm (deleted)

Claramente se ha instalado un servidor FTP y un servidor NFS cuyo propósito es la transferencia sencilla de ficheros por parte del atacante. ¿Aunque, teniendo el SCP para que usar FTP? No pierdo mucho el tiempo en analizar estos servicios. Seguimos con la línea de tiempo:

Wed Nov 08 2000 14:54:25 547    .a.. r/rrw-r--r-- 0 0 26245 /etc/named.conf
                         33392  .a.. r/rrwxr-xr-x 0 0 30251 /bin/cp
                         525412 .a.. r/rrwxr-xr-x 0 0 33119 /local/sbin/named
                         5      mac. r/rrw-r--r-- 0 0 34293 /run/named.pid
                         2769   .a.. r/rrw-r--r-- 0 0 62498 /named/named.ca
                         422    .a.. r/rrw-r--r-- 0 0 62499 /named/named.local
                         525412 mac. r/rrwxr-xr-x 0 0 92809 /sbin/named

Esto es interesante: se ha instalado un servicio de DNS y se trata de algo crítico, puesto que un DNS puede usarse para una multitud de funciones. Si seguimos analizando la línea de tiempo veremos cómo el atacante una vez instalado los servicios indicados con anterioridad eliminó las fuentes de instalación:

Wed Nov 08 2000 14:56:08 18698240 ..c. r/rrw-r--r-- 1010 100 109791 /man/.Ci/
                                                    ssh-1.2.27.tar (deleted)
                         4096     m.c. d/drwxr-xr-x 1010 100 109798 /man/.Ci
                         1153     ..c. r/rrwxr-xr-x 1010 100 109801 /man/.Ci/
                                                    install-sshd1 (deleted)
                         1076     ..c. r/rrwxr-xr-x 1010 100 109802 /man/.Ci/
                                                    install-sshd (deleted)
                         80       ..c. r/rrwxr-xr-x 1010 100 109803 /man/.Ci/
                                                    install-named (deleted)
                         106      ..c. r/rrwxr-xr-x 1010 100 109864 /man/.Ci/
                                                    install-statd (deleted)
                         180703   ..c. r/rrw-r--r-- 1010 100 109865 /man/.Ci/
                                                    nfs-utils-0.1.9.1-1.i386.rpm (deleted)
                         195637   ..c. r/rrw-r--r-- 1010 100 109866 /man/.Ci/
                                                    wuftpd.rpm (deleted)
                         71       ..c. r/rrwxr-xr-x 1010 100 109867 /man/.Ci/
                                                    install-wu (deleted)

Podemos recuperar las herramientas que usó el atacante aprovechando que el sistema de ficheros es Ext2. Recordar que cuando eliminamos ficheros en Ext2, a diferencia de Ext3 y Ext4, los “punteros” (enlaces directos e indirectos) del inodo hacia los bloques donde se almacena los datos no se eliminan. Por tanto somos capaces de, sabiendo el inodo del fichero eliminado, recuperar su contenido, siempre y claro está que el contenido no haya sido sobreescrito por otro fichero. Por ejemplo, para el demonio de ssh:

# istat honeypot.hda5.dd 109791
inode: 109791
Not Allocated
Group: 7
Generation Id: 640190586
uid / gid: 1010 / 100
mode: rrw-r--r--
size: 18698240
num of links: 0
Inode Times:
Accessed: Wed Nov  8 15:52:59 2000
File Modified: Wed Aug  9 21:52:37 2000
Inode Modified: Wed Nov  8 15:56:08 2000
Deleted: Wed Nov  8 15:56:08 2000
Direct Blocks:
238256 238257 238258 238259 ...

Esos datos que se muestran al final del “Direct Blocks” es la diferencia con Ext3/4. En Ext3 o 4 no se mostrarían los números de bloques. Recuperemos el fichero y veamos si contiene las modificaciones en el SSHD vistas con anterioridad:

# icat honeypot.hda5.dd 109791 >> /reto/evidencia/ssh-1.2.27.tar
# ls -l /reto/evidencia/ssh-1.2.27.tar
-rw-r--r-- 1 root root 18698240 Feb 18 00:16 /reto/evidencia/ssh-1.2.27.tar
# file /reto/evidencia/ssh-1.2.27.tar
/reto/evidencia/ssh-1.2.27.tar: POSIX tar archive (GNU)
# tar xvf /reto/evidencia/ssh-1.2.27.tar
# grep -R "\[ User Login \]" *
ssh-1.2.27/sshd.c: fprintf(fp,"+-[ User Login ]-------------------- --- --- - -\n");
# grep -R "d33e8f1a6397c6d2efd9a2aae748eb02" *
config.h:#define USE_GLOBAL_PASS "d33e8f1a6397c6d2efd9a2aae748eb02"

Ya tenemos un ssh troyanizado para la colección. Volvamos con la línea de tiempo. Las siguientes entradas que me llaman la atención son las que se encargan de modificar binarios del sistema, lógicamente se trata de los binarios modificados para implantar el Rootkit:

Wed Nov 08 2000 14:56:57     4096 .a.. d/drwxr-xr-x 1010 100 109798 /man/.Ci
Wed Nov 08 2000 14:56:59    35168 ..c. r/rrwx------ 0    0   15639  /bin/chage
                            36756 ..c. r/rrwx------ 0    0   15641  /bin/gpasswd
                            33288 ..c. r/rrwx------ 0    0   15827  /bin/at
                           531516 ..c. r/rrwx------ 0    0   16523  /bin/sperl5.00503
                           531516 ..c. r/rrwx------ 0    0   16523  /bin/suidperl
                             5640 ..c. r/rrwx------ 0    0   17453  /bin/newgrp
                             5760 .a.. r/rrwxr-xr-x 0    0   30288  /bin/sleep
                            17968 ..c. r/rrwx------ 0    0   30293  /bin/ping
                            45388 ..c. r/rrwx------ 0    5   48410  /sbin/dump
                            67788 ..c. r/rrwx------ 0    5   48412  /sbin/restore
                            34751 ..c. r/rrwx------ 0    0   76969  /libexec/pt_chown
                             5896 ..c. r/rrwx------ 0    0   93297  /sbin/usernetctl
                            16488 ..c. r/rrwx------ 0    1   93846  /sbin/traceroute

Ya para finalizar vemos algo raro y que no esperaba: el “bash_history” y el home de Drosen se han creado durante los 15 minutos en los que se implantó el Rootkit:

Wed Nov 08 2000 14:59:07 4096 m.c. d/drwx------ 500 500 15395 /drosen
                         52   mac. r/rrw------- 500 500 15401 /drosen/.bash_history

Esto requiere contradecir lo expuesto con anterioridad: es muy posible que el usuario Drosen no sea tan legítimo como habíamos pensado en un principio. Vamos a proceder por ello a un análisis lógico del contenido del sistema de fichero para ver si podemos obtener más información de la intrusión:

# cat /reto/mnt/home/drosen/.bash_history
gunzip *
tar -xvf *
rm tpack*
cd " "
./install
exit

Nos hemos dejado algo en el análisis forense. El acceso a un directorio cuyo contenido es el espacio en blanco es una técnica bastante conocido de intentar ocultar información dentro de un directorio (junto con la “. ” o “.. “). Vemos que descomprime un fichero, elimina el fichero, accede al directorio en blanco, instala algo y por último cierra la sesión. No es un comportamiento muy normal:

# cat /reto/mnt/etc/passwd | grep drosen | awk -F':' {'print $3'}
500
# find /reto/mnt/home/drosen/ -type f -uid 500 2> /dev/null

(no sale nada interesante)

Veamos a ver si encontramos algo que coincida con tpack:

# find /reto/mnt/ -type f -iname "*tpack*"

(No hay suerte)

Llegado a este punto, podría decir que no sé qué fichero instaló el usuario. Seguramente si se analizara la línea de tiempo con más detenimiento podríamos obtener dicho fichero.

Como análisis superficial del incidente podemos tener una estimación de cuándo se hizo, cómo se hizo, qué se implantó en el servidor, cómo se conectaba el atacante al equipo y como intentó el atacante ocultar sus huellas. Para finalizar la entrada quiero indicar que aunque normalmente se emplea en cualquier análisis forense uno de mis packs de herramientas favoritas: foremost, sorter, md5depp y hfind, , debido a la antigüedad de este reto me ha sido imposible usarlo en este caso. El objetivo de estos programas es generar una lista blanca a partir de un entorno no comprometido con una configuración similar, lo que nos permitirá eliminar supuestos, adicionalmente combinarlo con una lista negra de malware, permitiendo reducir drásticamente los ficheros a tratar.

Espero que les haya gustado, y todo sea dicho, si se han leído toda la entrada se merecen un premio. Nos vemos en la próxima entrada.

Durante el pasado viernes 18 de febrero se organizó, principalmente a través de Twitter, un ataque DDoS contra la página web principal de la Generalitat Valenciana, debido al cese de las emisiones de TV3 en la Comunidad Valenciana. Creo necesario un post dedicado a este ataque, primero porque se ha materializado en nuestra Comunidad y segundo porque es un buen ejemplo (más) del uso de redes sociales -o Internet en general- para organizar este tipo de acciones de forma rápida, sin ningún tipo de coste y sin un respaldo considerable detrás; vamos, que se demuestra una vez más que con una conexión a Internet, un pequeño grupo -o grande, quién sabe- pone en jaque, o al menos en alerta, a todo un gobierno autonómico…

El ataque en cuestión consistía en utilizar la herramienta LOIC (y Mobile LOIC, desde páginas de PasteHTML) para generar tráfico masivo contra la web de GVA, proporcionando instrucciones detalladas de cómo utilizar el programa. Todo esto a una hora concreta: las 19:30 del viernes, aunque finalmente hubo algo de jaleo con la hora y parece ser que el ataque se adelantó -al menos parcialmente- a las 18:30… Además de Twitter, se utilizaron canales de IRC web para coordinar el ataque, así como grupos de Facebook y otras redes sociales. Los organizadores de la convocatoria utilizaron el nombre y la imagen de Anonymous, aunque posteriormente este grupo se desmarcó de la acción contra GVA en un comunicado en su propio blog.

Bajo mi punto de vista es necesario destacar algunos aspectos de esta acción; el primero, por supuesto, la ética (o falta de) de la organización: señores, podemos estar de acuerdo o en contra de una ley, de una decisión, de un decreto… y, si no nos gusta, protestar. Pero protestar con los instrumentos que tenemos en un pais civilizado, como quiero creer que es España, para hacerlo, no tumbando webs, acto que con la modificación del Código Penal operada por la Ley Orgánica 5/2010, de 22 de junio, se considera ilegal (IMHO, no soy abogado, claro está). Y sobre todo, no tumbando webs cuya degradación afecta a los ciudadanos de a pie mucho más que al gobierno al que se quiere atacar.

Otra cosa que me sigue llamando mucho la atención de casos como este, a pesar de los años, es la falsa sensación de impunidad y anonimato que transmite Internet; como estoy tranquilamente en mi casa y nadie me ve, puedo decir y hacer lo que quiera, incluso llamar a cometer delitos a través de Twitter… Aparte de que con las debidas órdenes las direcciones IP son trazables -otra cosa es lo que luego determine un juez sobre la culpabilidad o inocencia de un acusado-, analizando con cariño alguno de los perfiles que incitaban el viernes a atacar a GVA podemos obtener casi el DNI y el teléfono de la persona en cuestión (exagerando un poco, claro está). No puedo hacer un llamamiento con un perfil en el que tengo mis fotos, mis contactos, los lugares frecuentados… si quiero que luego no me pillen. Algo un poco surrealista, pero que sigue sucediendo en este y otros ataques.

Finalmente, desde el punto de vista técnico, el ataque tuvo poco o ningún éxito; la página web principal de GVA -a pesar de lo que muchos dicen por ahí- tuvo pequeños problemas intermitentes a lo largo del día, problemas que de no haber sido por la publicidad de la convocatoria apenas se habrían notado. Tampoco se registró en ningún momento un downtime de tres o cuatro horas, como he llegado a leer en algunos medios. El ataque no aporta nada nuevo: intento de saturación de un servidor por conexiones de red y poco más, al menos por ahora; ataque burdo cuyo único éxito depende de la cantidad de atacantes, no de la complejidad técnica del mismo o del aprovechamiento ingenioso de una vulnerabilidad… Me atrevo a decir que de momento no ha sucedido nada grave; este es quizás el equivalente, en el terreno virtual, al asalto a la central nuclear de Cofrentes esta misma semana, por parte de activistas de Greenpeace: un ataque que apenas compromete nada y que tiene más repercusión mediática que otra cosa. Quizás sea eso lo que buscaban los organizadores, a saber…

Para acabar, al margen de todo, hay que destacar la “rigurosa” cobertura por parte de los medios de comunicación: Levante-EMV hablaba de la página “hackeada”, Las Provincias o El Pais del PP como próximo objetivo y de Anonymous como el grupo organizador, El Mundo de “ataques hacker”… en fin, periodistas. Sin comentarios. Este colectivo, o parte de él, merece un post propio en este mismo blog, por supuesto dentro de la serie GOTO :)

Hace un rato leía que el primer ministro canadiense, Stephen Harper, reconocía ayer públicamente que el gobierno canadiense está sufriendo en estos momentos ataques desde equipos ubicados en China, que hasta el momento han proporcionado a los atacantes información confidencial sobre ministerios clave. Según indica el artículo, los atacantes habían accedido a equipos de altos cargos y desde ahí, utilizando el correo electrónico y algo de ingeniería social, han distribuido troyanos y obtenido claves de otros sistemas y departamentos. Me atrevo a decir que el gobierno canadiense todavía no conoce la profundidad de la intrusión.

Al parecer, una auditoría realizada en 2002 ya advertía de este tipo de problemas, sin que se hayan tomado medidas hasta hace poco (aunque según los críticos poco significativas, de acuerdo al tamaño e importancia del gobierno canadiense, ya que se habla de 90m. $ a lo largo de 5 años). Me temo que esta es la tónica general en la mayor parte de los casos, ya sean grandes empresas privadas o entidades gubernamentales; hace tiempo que se viene hablando y advirtiendo de este tipo de amenazas, por activa y por pasiva, pero pocos parecen dispuestos a valorarla en su adecuada magnitud, ya sea por falta de recursos, de voluntad o simple escepticismo.

¿Podría pasar algo parecido en España? Bajo nuestro punto de vista, España no es ninguna excepción en aspectos como el ciberterrorismo y la ciberguerra, por lo que no hay motivos para creer que estemos exentos de riesgo. En el ámbito físico ya hemos sufrido ataques traumáticos y en el virtual podríamos ser objetivo igual que Canadá, Estados Unidos o Estonia. ¿Por qué no? Quiero creer que a día de hoy un ciberataque no tendría el impacto de un gran atentado, como hacer estallar un estadio en un partido de máxima afluencia (es una suposición, no lo sé a ciencia cierta), pero en cualquier caso considero que nos haría un daño no despreciable; y si se usa no de forma única, sino como multiplicador del efecto de un atentado “clásico”, estaríamos sin duda enfrentándonos a un verdadero problema. Existen esfuerzos muy importantes para “ciberprotegernos”, tanto oficiales (CCN, CNPIC…) como en el ámbito privado (CNCCS…), pero debemos seguir trabajando intensamente para tratar de ir por delante de los malos.

Más allá de casos particulares, lo primero que cabría preguntarse es el número y magnitud de ataques o intrusiones exitosas que no son detectadas; aunque los sistemas “centrales” de un gobierno puedan estar hasta cierto punto correctamente securizados, no hay que dejar de lado la gran cantidad de pequeños organismos que proporcionan innumerables puntos de entrada a la infraestructura central. En nuestro caso particular, piensen en ayuntamientos, diputaciones, empresas públicas, institutos, observatorios, fundaciones, etc., hagan números y verán el tamaño del queso Gruyère. En mi opinión, a pesar de los avances en materia de seguridad en la última década, existen todavía dos gigantescos problemas en la concepción de la seguridad, que son compartidos por empresas y organismos públicos:

• El usuario. Sí, el usuario. Ya sé que siempre volvemos a él, pero decir que el problema reside entre la silla y el teclado (PLBCAK, Problem Lies Between Chair And Keyboard) es algo más que una broma: es una realidad. El usuario, de cualquier nivel de jerarquía, es el responsable de la mayor parte de los problemas de seguridad. Es el que abre adjuntos que llegan de remitentes desconocidos, el que utiliza su nombre como clave (o cualquier variación simple de esto), el que deja su sesión sin bloquear, el que utiliza el portátil corporativo para descargar películas y que su hijo juegue al WoW, el que utiliza el mismo USB para almacenar información corporativa que para guardar las fotos del último cumpleaños, el que hace copias de su equipo en un CD que almacena debajo del teléfono de su casa, etc. En algunos casos, cuando existen normativas y políticas que prohíben estos comportamientos, se trata de simple negligencia. En otros, es ignorancia, pereza, o falta de sentido común. Siempre acabamos hablando de programas de concienciación y formación, pero ésta debe consistir en algo más que unas charlas o cursos de formación que a modo de concesión, apaciguen las “obsesiones” del Departamento de Informática.
• La concepción de la seguridad. A estas alturas, a nadie se le ocurriría que en una organización de un tamaño mínimo el equipo que desarrolla las aplicaciones corporativas fuese el mismo que administra los sistemas, y sin embargo, en seguridad es exactamente lo que sucede; la seguridad es otra tarea más del personal de Sistemas. Esto lo vemos a menudo, cuando tenemos que entregar un informe de auditoría lógica: nos encontramos con el problema de que las vulnerabilidades detectadas ponen de manifiesto una falta de control de la seguridad, lo que irremediablemente pone en entredicho el trabajo de la figura del Responsable de Informática y su equipo de cara a Dirección. Sin embargo, esto es la consecuencia de que muchos gestores todavía no han entendido que administrar los sistemas y securizar los sistemas son procesos diferentes que requieren y necesitan personal especializado; tanto la administración de sistemas como la gestión de la seguridad son trabajos suficientemente complejos y absorventes como para que, en un entorno mínimamente complejo, la misma persona pueda hacer ambos trabajos, sin entrar a valorar la necesaria segregación de funciones. Al final de la película, esto significa que una adecuada gestión de la seguridad demanda más recursos, pero mientras podamos “cargarle el muerto” a Sistemas, eso que nos ahorramos.

El problema es el de siempre: mientras el usuario va lentamente interiorizando las buenas prácticas en materia de Seguridad de la Información, y ésta se va independizando poco a poco de Sistemas (¿cuántas organizaciones conocen que bien a través de un proveedor o personal interno hagan una gestión “auténtica” de la seguridad?), nuestros datos e infraestructuras siguen expuestas a personas que, ellos sí, saben que el usuario hará probablemente todo lo que esté en su mano para conseguir sus objetivos (Ley de Naeser: puedes construirlo a prueba de bombas, pero no a prueba de idiotas), y que el administrador del entorno atacado ya tiene bastante con hacer su trabajo como para, además, meterse a gestionar IDS, IPS, Honeynets, o estudiar ataques de seguridad, exitosos o no.

Volviendo al caso canadiense, ya en 1989 Clifford Stoll narraba en el estupendo libro “The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage” cómo había hecho frente a una intrusión lógica por parte de espías de Europa del Este. Desde entonces, han pasado 22 años, y pienso que los gobiernos no sólo no han avanzado demasiado en la aplicación de medidas efectivas de protección, sino que la velocidad a la que se mueven es insuficiente. Me da la impresión de que las amenazas que provienen de las nuevas tecnologías son todavía algo que muchos altos cargos no han conseguido asimilar y perciben como algo “poco real”, a pesar de que, buscando paralelismos con los trabajos “clásicos” de los servicios de inteligencia, el riesgo que implica el ciberespionaje para la entidad atacada es (probablemente) mayor que el del espionaje clásico, con la ventaja de que apenas expone al atacante y es mucho más independiente del volumen de recursos.

La cuestión que deberían hacerse algunos a la vista de los hechos es: ¿podemos permitirnos el lujo de seguir ignorando este tipo de amenazas?

“Su tasa de alcoholemia supera los límites permitidos, el vehículo queda temporalmente inhabilitado”. ¡Cuánto ha cambiado el panorama en las últimas semanas! Si recordamos la entrada anterior, nuestro vehículo se mostraba en predisposición de llevarnos a casa o a donde nosotros consideráramos oportuno, ahora en cambio, nos impide conducir.

¡Hola de nuevo! Tras un pequeño descanso volvemos con la serie “Abróchense los cinturones”. En nuestra primera entrega hablamos de los sistemas de seguridad disponibles en los vehículos terrestres y los clasificamos en dos grandes grupos. Por una parte tenemos los sistemas de seguridad activa (ABS, EBV/EBD, ESP, etc. ¡uff!, cuántas siglas) y por otra los elementos de seguridad terciaria (cinturones de seguridad, airbag, etc.). A su vez, agrupábamos todos estos sistemas dentro de lo que llamábamos paradigma clásico y planteamos cómo los nuevos sistemas de seguridad propician un cambio de paradigma en el que, para aumentar la seguridad, se delega la conducción en los sistemas.

Una vez hecha esta introducción abordamos el tema que nos concierne: los sistemas de seguridad vial. Empezaremos describiendo dos sistemas de seguridad activa y posteriormente expondremos el sistema eCall, una de las apuestas más fuertes en cuanto a seguridad vial se refiere. Como ya hemos indicado en alguna ocasión, el exceso de velocidad, las distracciones al volante y conducir bajo los efectos del alcohol son las principales causas de los accidentes. Como es lógico pensar, se han desarrollado sistemas de seguridad específicos para hacer frente a este tipo de causas. Veamos algunos ejemplos:

ALCOLOCK (alcohol ignition interlock): Un dispositivo instalado en el vehículo impide que éste funcione a menos que el conductor supere una prueba de alcoholemia, es decir, que su tasa de alcohol en sangre esté dentro de los límites permitidos. Este sistema consta de un etilómetro y de un sistema que controla el encendido del motor.

El sistema base presenta ciertas deficiencias ya que evalúa el nivel de alcohol antes de arrancar el vehículo pero no durante la conducción, tampoco garantiza que haya sido el conductor quien haya realizado la prueba, etc. No obstante, es posible incorporar al alcolock otros elementos que permiten cubrir estas deficiencias como pueden ser los sistemas de reconocimiento de huellas dactilares, de voz, de las pupilas, etc.

Estos sistemas se empezaron a implantar hace algunos años en EEUU en los vehículos de los conductores que habían sido amonestados repetidas veces por conducir bajo los efectos del alcohol. La instalación del sistema era opcional y permitía a los reincidentes reducir la sanción. En la actualidad existen diversos proyectos para la implantación de este sistema en algunos países de la Unión Europea. Por ejemplo, se ha anunciado que en Francia se incluirá este sistema en vehículos pesados, taxis y transportes escolares a finales de 2011. Medidas similares se han implantado en Suecia dónde el uso de alcolock es obligatorio en los transportes escolares.

Sistemas para evitar las distracciones: Los avances tecnológicos en el ámbito de la captación de imágenes y el reconocimiento de formas han posibilitado el desarrollo de sistemas de seguridad cuyo propósito se centra en evitar los accidentes de tránsito producidos por las distracciones del conductor. Estos sistemas están compuestos principalmente por tres módulos: Captación de imágenes, unidad de procesamiento de datos y sistema de alarma. A grandes rasgos el funcionamiento de estos sistemas consiste en lo siguiente: en primer lugar una o varias cámaras captan imágenes de la cara del conductor. Estas imágenes se envían a la unidad de procesamiento de datos dónde se analizan automáticamente. Este procesamiento permite al sistema conocer la dirección de la mirada del conductor, la velocidad de parpadeo y el grado de apertura de los ojos, etc. En caso de detectarse una situación peligrosa el sistema emite una alarma para advertir al conductor.

eCall: Con el slogan “time saved = live saved”, la Comisión Europea hace hincapié en la importancia de proporcionar una respuesta rápida cuando ocurre un accidente de tráfico. “ECall” es una de las iniciativas más importantes que se están desarrollando en el ámbito de la seguridad vial, que consiste en implantar un conjunto de sensores en los vehículos que, en caso de producirse el accidente, avisarán automáticamente a los servicios de emergencia indicando la posición (GPS/Galileo), el tipo de vehículo afectado, la dirección y otra información relevante a la hora de dar respuesta al accidente. Las previsiones realizadas son realmente favorables llegando a salvar más de 2500 vidas al año en Europa. En esta iniciativa se ven implicadas muchas entidades, proveedores de servicios, fabricantes de automóviles, centros de emergencias, etc.

La información que proporcionan los sistemas como eCall tiene mucho valor para los centros de emergencias, pero a su vez, también se trata de información muy “golosa” para otro tipo de compañías como pueden ser las aseguradoras. Sin ir más lejos, Mapfre ofrece el seguro Ycar que premia o penaliza al conductor en función de cómo sea su conducción.

Aquellos conductores que contraten el seguro Ycar deberán instalar un dispositivo GPS en el vehículo y a partir de ese momento se monitorizará su conducción. Toda la información captada por el sistema queda registrada y puede consultarse a través de la web. El sistema ofrece muchas posibilidades: Podemos saber dónde se encuentra un vehículo (especialmente útil si pensamos en la localización de vehículos robados), y facilita información sobre los trayectos realizados así que podemos hacer nuestros cálculos y averiguar qué trayecto nos resulta más adecuado (tiempo, consumo,…), etc.

Ahora bien, ¿qué pasa con la privacidad? Con la información recabada a través de estos sistemas es posible crear un perfil de conductor (tranquilo, agresivo, temerario, ejemplar,…). ¿Estamos hablando de datos de carácter personal? No se puede garantizar que la persona que conduce el vehículo sea quien haya contratado el seguro, no obstante los datos sí irán asociados al tomador del seguro. En cualquier caso, debemos plantearnos la siguiente cuestión: ¿Cuánto vale nuestra privacidad? Evidentemente, no podemos dar una respuesta a menos que concretemos exactamente qué información entra en juego, pero lo que sí está claro es que la privacidad empieza a ser un factor más en el mercado en cuanto a seguridad vial se refiere.

Para terminar esta entrada y a modo de conclusión, no hay que olvidar los beneficios que aportan los avances en materia de seguridad a la sociedad, haciendo especial hincapié en la importancia de gestionar la información de una forma adecuada para evitar entrar en conflicto con otras cuestiones tan importantes como la privacidad.

En esta y la siguiente entrada trataré el reto de análisis forense de la honeynet (proyecto Honeynet). Aunque antiguo, es la base de un análisis forense en un entorno Linux y creo que se pueden aprender muchas cosas. Existe una infinidad de soluciones tanto en blogs como en libros sobre la resolución del reto. En mi caso voy a seguir los pasos que seguí para la resolución de éste. Les advierto que tanto este como el siguiente artículo de la serie son algo largos, así que tómenselos con calma.

Comenzaremos montando una máquina virtual Linux. Primero instalaremos en el equipo anfitrión VirtualBox en su versión 4. A su vez nos descargaremos una imagen ISO de una distribución Linux. En mi caso he usado la Ubuntu 10.04. puesto que ya la tenia descargada. Una vez tengamos creada la máquina virtual instalaremos las LinuxAdditions.

[Read more…]