Cita

"Those who are willing to pay a penny of security for a penny of usability will eventually have neither"

14 diciembre 2014

#8JornadasCCN_CERT Crónica (I)


Enlace permanente de imagen incrustada
Queridos lectores,

Un año más hemos tenido el placer de asistir a las Jornadas STIC, organizadas por el Centro Criptológico Nacional. Os recomiendo descargar la documentación cuando esté disponible en la web. Mientras tanto, haré lo mejor que pueda por resumíroslas, para que tengáis un adelanto.

En esta edición, el CCN-CERT nos ha sorprendido con dos novedades: la primera es ¡su salida a Twitter! (algunos ya lo estábamos deseando). Como se deduce del nombre (Jornadas CCN-CERT), el propósito de la cuenta es dar información sobre las mencionadas Jornadas; y así lo han ido haciendo antes y durante el evento. El tiempo dirá si la siguen usando para más cosas relacionadas con el organismo.

La otra ha sido la división del programa en tres módulos simultáneos, a elegir, que complementaban la sesión plenaria, cada uno centrado en un tema diferente: 1- Ciberespionaje / APTs. 2 - Nuevas amenazas, herramientas y tecnologías. 3 - Estrategia de ciberseguridad. ENS y cumplimiento normativo. La elección era difícil porque todo parecía muy interesante, pero me decanté por el 2.

Enlace permanente de imagen incrustadaMás de mil personas nos hallábamos reunidas en el Gran Anfiteatro del Ilustre Colegio Oficial de Médicos de Madrid, para la inauguración del acto por el SED del CNI-CCN, Félix Sanz.


Tras lo cual, se presentaron las principales novedades del CCN-CERT y se hizo un repaso de la gestión de incidentes en 2014: habrá nuevas guías, nuevos cursos y un nuevo diseño del portal. ¿Recordáis hace poco la noticia sobre los estragos que estaba causando TorrentLocker? Pues, desgraciadamente, también quince organismos públicos se han visto afectados. Otro que ha causado muchos dolores de cabeza ha sido el "Snake / Uroboros / Turla", que han perseguido con la herramienta Carmen, de la que os hablaré posteriormente.

A continuación, David Barroso nos habló de la persistencia en BIOS: dónde pueden esconderse los "bichos". Para mi gusto, hizo un estupendo resumen sobre el funcionamiento de la BIOS y, desde que apareciera en el 2000, la EFI y las distintas capas de ejecución donde puede esconder el malware. El problema de los bootkits es que no dejan trazas en disco, sobreviven a la reinstalación del S.O. y casi ningún AV mira en la BIOS/UEFI. Hablando de AV, ojo: porque algunos AV chinos instalaban drivers maliciosos en el bios.sys para acceder a esa zona de memoria.



Enlace permanente de imagen incrustada
El tipo de ataque va a depender del modelo del fabricante, aprovechándose, muchas veces, de fallos en el diseño; dándose también el caso de que algunos equipos venían infectados de fábrica (¿verdad que no nos sorprende?). Muchos de los ataques se realizan al módulo SMM, infectándolo con tablas ACPI maliciosas.

Otra posibilidad es infectar la PCI expansion ROM, en vez de a la propia BIOS y que el bootkit se cargue cuando ésta lo arranque. Como protección contra los bootkits, que se ejecutan después del arranque de la BIOS, el sistema UEFI implementa el Secure Boot, que comprueba que el código de arranque no haya sido modificado, sirviéndose de la firma digital.

¿Es entonces la UEFI la panacea para los problemas de seguridad de la BIOS? Llegados a este punto, me permitiréis que de un salto a la última ponencia del día en el módulo dos, en la que un miembro del CCN ofreció más explicaciones sobre el funcionamiento de la UEFI. Así guardamos la coherencia lógica, aunque no cronológica:

¿Por qué es la UEFI un arma de doble filo? porque ofrece ventajas al defensor (implementa mecanismos adicionales de seguridad, la estandarización favorece un buen conocimiento del sistema y control del soft instalado...), pero que pueden ser también aprovechadas por un atacante: es más fácil meterse en el código (los punteros a funciones facilitan la labor del atacante), se puede hacer en C, es más fácil añadir un driver DXE malicioso en el módulo NTFS que hacerlo en el MBR/VBR, el formato es PE, hay una mayor superficie de ataque porque se complementa la ACPI con distintos módulos de código según el tipo de arranque.


La firma digital utilizada por Secure Boot no es de tipo PKI. La NVRAM se puede flashear a disco con la herramienta fptw64 o copiándola por hardware, modificar y firmar con las claves que vienen por defecto de fábrica. Se recomienda usar TPM para almacenar la claves y mejorar así la implementación del SecureBoot. También, utilizar la herramienta Copernicus para gestionar la UEFI de un parque informático.

Ya hay ataques especificamente diseñados para UEFI, pero su complejidad y la necesidad de acceso físico a la máquina hace que sean más de temer los propios insiders contra un objetivo escogido, que un "bicho" venido de fuera que se propague por la red.

Espero que os haya parecido tan interesante como a mí todo lo hasta aquí expuesto. Para no cansaros mucho, voy a continuar con el resto del resumen de las jornadas en próximas entregas.


No hay comentarios:

Publicar un comentario

A penny for your thoughts