En la actualidad, en el mundo de la seguridad recibimos continuamente anuncios de vulnerabilidades de software y sus correspondientes actualizaciones de seguridad. Prácticamente no pasa un solo día en el que no aparezca una nueva vulnerabilidad. La gran mayoría de estas vulnerabilidades aprovechan fallos en la implementación del software para obtener por ejemplo ejecutar código, elevar privilegios, superar mecanismos de validación, obtener información, etc.
Es obvio que en el mundo de la seguridad la atención se centra las potenciales vulnerabilidades en el software, y no falta razón. No obstante, el problema radica en la creencia firme de que los dispositivos hardware que ejecutan el mismo son perfecta y completamente seguros. Nada más alejado de la realidad; el hardware está formado por multitud de bloques de circuitos interconectados que interactúan de una forma muy compleja, y es fundamental que se tenga en cuenta la seguridad en el diseño y ensamblado de los componentes.
Dentro de la cadena de fabricación de, por ejemplo, la placa base de un ordenador personal cualquiera, se emplean distintos chipset de distintos fabricantes y características, como la BIOS, los controladores de memoria, los chipset de bridge, controladores ATA, etc. Y qué decir de cuando a esa misma placa conectamos distintos dispositivos, todos ellos con sus propios componentes. Es fácil hacerse una idea de la complejidad que puede alcanzar un sistema aparentemente convencional. Por lo que, para poder “controlar” la seguridad a este nivel se deberían llevar medidas de control y verificación hasta los propios fabricantes de los dispositivos o los que los ensamblen equipos.
Adicionalmente a la propia interacción del dispositivo, en muchos casos las vulnerabilidades no son debidas a la implementación de los circuitos o componentes, sino a la propia tecnología empleada, lo que es si cabe aún más crítico.
Es importante destacar que cuando se produce un fallo de seguridad de este tipo tiene difícil solución, por lo que tienen una elevada persistencia. Algunos de los motivos que propician esta situación son:
- La detección de este tipo de problemas normalmente se tiene que realizar manualmente.
- Se trata de problemas difíciles o imposibles de parchear, muchas veces la única solución será sustituir el/los componente/s afectados.
- Una vez se ha comprometido el hardware, es muy posible que cualquier medida preventiva o correctiva de software sea completamente inútil.
Sin embargo, a pesar de que no estamos hablando de una disciplina ni mucho menos joven, estos problemas se dan más a menudo de lo que nos pensamos, y al contrario de lo que más de uno podría pensar, no siempre es necesario el acceso físico a los sistemas para atacar directamente al hardware; es posible emplear vulnerabilidades de software para acceder y vulnerabilidades de hardware para obtener persistencia.
Una vez puestos en contexto, recientemente se han publicado dos vulnerabilidades contra hardware que a mí personalmente me han llamado la atención: Row Hammer y Light Eater. Pasamos a comentarlas sin entrar en demasiado lujo de detalles.
Row Hammer (CVE-2015-0565) es una ataque publicado por Google Project Zero el 9 de Marzo de 2015 y aprovecha directamente una vulnerabilidad en la tecnología de diseño de las memorias DRAM, empleadas en prácticamente la totalidad de sistemas informáticos como memoria principal. Las memorias DRAM están formadas por una o varias matrices de celdas aisladas entre sí en las que se almacena un valor binario. Con el paso de los años y la mejora de las medidas de integración, estas memorias se han ido haciendo más y más pequeñas, por lo que para una misma unidad de medida caben muchas más celdas, esto se traduce en que cada vez existen memorias con más capacidad, mayor frecuencia de funcionamiento y menor consumo eléctrico.
El ataque Row Hammer, siendo generalistas, consigue que las celdas contiguas liberen su contenido e interactúen entre ellas, es decir, mediante dicho ataque se podría conseguir que un conjunto de celdas de memoria obtuvieran el valor almacenado en las celdas contiguas. Esto es posible debido al cada día mayor nivel de integración de las memorias, que hace que cada vez el espacio de aislamiento entre celdas sea menor. Se han realizado pruebas de concepto en las que, mediante unos patrones de acceso a memoria especialmente preparados aplicados en un conjunto de celdas o bloques de memoria, tras su aplicación los bloques de memoria contenían la misma información que sus contiguos.
A priori esto puede no parecernos preocupante, pero pensemos en la ejecución de aplicaciones en un sistema operativo, en la que se asigna un espacio de memoria para cada una de ellas. Mediante Row Hammer una aplicación podría obtener información de un espacio de memoria que no le corresponde, violando las restricciones de acceso a memoria. En la actualidad se han desarrollado pruebas de concepto que permiten escalado de privilegios empleando esta vulnerabilidad. Este es un claro ejemplo de una vulnerabilidad en la tecnología empleado, aunque en este caso sí existen medidas paliativas que evitan en la medida de lo posible que se produzca este efecto. Más información técnica sobre este ataque en el siguiente enlace de la Wikipedia.
El segundo ataque que me gustaría comentar es Light Eater, más reciente si cabe, ya que se publicó el pasado 20 de Marzo en una presentación realizada en CanSecWest 2015 [PDF] por parte de investigadores de LegbaCore. El exploit presentado aprovecha una vulnerabilidad en BIOS (VU#631788) que permite a un atacante local no autenticado modificar el firmware de la BIOS. Mostraron un exploit completamente automatizado que, basándose en patrones, era capaz de identificar de qué tipo de BIOS se trataba e infectarla. De este modo, como ellos mismos afirman, un atacante con nula experiencia podría explotar la vulnerabilidad (se puede explotar en cualquier sistema vulnerable ya que es independiente del operativo instalado).
Una vez modificada la BIOS, mostraron distintas aplicaciones para las que se podría emplear:
- Robo de claves, mensajes descifrados o contraseñas del GPG sobre Tails (sistema operativo centrado en preservar la privacidad y anonimato) en un sistema MSI.
- Uso de Intel Serial-Over-LAN para exfiltrado de información en un sistema HP.
- Instalación de un rootkit que, empleando API Hooking sobre Windows 10 Preview, obtuviera una notificación cada vez que se carga un proceso en el sistema. Esta prueba se realizó en un sistema ASUS.
No es necesario destacar lo crítica que es esta situación, teniendo en cuenta que la mayoría de los usuarios o administradores no actualizan el firmware de la BIOS durante toda la vida útil del dispositivo. La principal medida correctiva es, obviamente actualizar el firmware de la BIOS, siempre asegurando que el fabricante ha liberado actualizaciones que subsanen esta vulnerabilidad.
Como hemos visto, son obvios los riesgos de los ataques contra Hardware. Sin embargo, en mi humilde opinión no se ponen los medios necesarios para reducir el riesgo de que se produzcan fallos, ni en muchas ocasiones los propios profesionales tenemos conciencia del verdadero riesgo que implican estas vulnerabilidades, quizá en ocasiones por el conocimiento a nivel hardware que es necesario. Es de esperar que, tras problemas como los descritos, poco a poco el diseño y fabricación del hardware entre dentro de la cultura de seguridad y como se facilite a los usuarios mecanismos que permitan mantener los sistemas seguros más fácilmente.
Espero que la entrada haya sido de vuestro agrado y quedamos a la espera de vuestros comentarios. Muchas gracias por leernos.
