Dadas las revelaciones desde The Equation Group fue descubierto. Además, es posible no garantizar eliminación de un rootkit incluso con una bomba nuclear de órbita alta .
¿Qué propiedades de un disco duro se pueden agregar para evitar que estos rootkits tomen el control / reemplazo del firmware?
Una solución es requerir que todo el firmware esté firmado y que el dispositivo verifique la firma antes de escribir esa imagen de firmware en su memoria; mi computadora portátil actual tiene una opción para habilitar esto en su BIOS (la opción es permanente; si la habilito ahora ya no puedo deshabilitarla, es por eso que no la habilité).
Sin embargo, hay muchos inconvenientes:
induce una falsa sensación de seguridad, ya que no sabemos cómo el fabricante protege la clave privada utilizada para firmar y no espero que admitan su falla y envíen un mensaje agradable "Disculpe, la clave del firmware se filtró "correo electrónico a cada cliente; también, incluso si la llave no se filtró, la NSA y otras agencias malvadas pueden haberla robado y nadie lo sabría.
hacer firmware personalizado es imposible, aunque estoy de acuerdo con el hecho de que son compañías con fines de lucro y su firmware es de código cerrado, definitivamente no estoy bien que me impidan instalar lo que quiera en Mis propios dispositivos por los que pagué, por la llamada "seguridad", aunque la NSA ya les robó la clave (recuerdo haber instalado una BIOS personalizada en mi viejo Thinkpad porque la original tenía una tarjeta blanca de ID de tarjeta blanca que me impedía de cambiar sus 802.11g obsoletos por un modelo 11n, algo imposible con las comprobaciones de firmas de firmware implementadas).
Otra solución mejor es requerir una intervención física (presionar un botón de hardware en el propio dispositivo) para permitir la instalación del firmware, que no tiene los inconvenientes anteriores; El usuario debe realizar la comprobación de la autenticidad del firmware y él es libre de instalar lo que quiera. Si el usuario desea instalar el firmware, presiona el botón y el dispositivo permite que se instale un firmware antes de que se vuelva a bloquear (o se agote el tiempo después de un minuto si no se ha instalado nada).
El único inconveniente de esta opción es que cada dispositivo tendría su propio botón de hardware, en una computadora de escritorio típica está el BIOS / EFI (que a menudo actualizará todo lo demás integrado en la placa: NIC, controlador RAID "falso", etc. ), posiblemente la ROM opcional de la tarjeta de video de terceros (también llamada BIOS de video), el controlador RAID o NIC de terceros, unidades de almacenamiento, etc.
Si bien todo lo que hay en la placa podría estar conectado a un solo botón, todo el hardware de terceros tendría su propio botón, a veces difícil de presionar debido a que el hardware está dentro de la caja de la computadora. Esto no es demasiado problemático ya que los usuarios incapaces de abrir una caja de la computadora por lo general no actualizan el firmware de todos modos debido al "riesgo" (es mínimo, pero la creación de discos DOS de arranque da miedo) y la complejidad.
Una solución teórica sería requerir que todos los puertos utilizados comúnmente (SATA, PCIe, etc.) incluyan una línea dedicada de "flash de firmware" que esté conectada por cable al botón principal de flash del firmware de la placa.
La única forma de evitarlo por completo es no tener ningún tipo de memoria no volátil grabable en el dispositivo. El problema con esto es que evitaría que el firmware se modifique, lo que podría complicar las cosas.
El problema en estos días, según tengo entendido, es que debe haber comandos de lectura / escritura de bajo nivel para acceder a los espacios en la memoria que contiene el firmware. Incluso cuando no se hacen públicos, estos comandos se pueden encontrar a través de fuerza bruta si es necesario (si no se detecta una interfaz al actualizar). Así que creo que la pregunta sería mejor planteada: "¿Es posible evitar completamente la lectura / escritura en las ubicaciones donde se encuentra el firmware?" Lo que me lleva de vuelta a mi primera oración.
Una opción podría ser implementar certificados firmados y mantener un certificado del fabricante en la ROM. El firmware se puede firmar y verificar a través del certificado al momento del encendido. Esto agregaría MUCHA sobrecarga que no existe hoy en día y no deja de tener sus propios problemas. Si se compromete un certificado, ¿cómo revocarlo en una situación como esta? ¿Qué pasaría si expirara? ¿Podría expirar? Además, deberá agregar capacidades (procesamiento y memoria) para usar cualquier función de cifrado en el dispositivo y no se podrá acceder a él a través de la E / S normal. Es probable que todo esto agregue un aumento de costos significativo (tanto en diseño como en fabricación).
Como comentario final, diría que es probable que sea mucho más difícil, pero que probablemente no valga la pena el aumento de costos para el usuario final. Basar mi opinión en esto sería muy costoso hacer contramedidas y que se necesita una pieza de malware muy específicamente diseñada (para el modelo y la versión de firmware probable) para explotar, yo diría que probablemente no sea factible para casi cualquier aplicación. Esto podría excluir a cualquier persona con bolsillos extremadamente profundos (o bolsillos que se extiendan a los contribuyentes).
Me gusta la respuesta de André de tener un interruptor o botón para programar el firmware. Algunos dispositivos ya tienen esto, muchas placas base, por ejemplo, tienen un puente para proteger la BIOS contra escritura.
Forzar el dispositivo para que no funcione correctamente en el modo de programa de firmware permitiría a un usuario ver si algo era dudoso. Como un dispositivo de audio que no emite audio, o una tarjeta de video que solo permite el modo de video básico. Combinar un puente de protección contra escritura con un botón de programa puede ser excesivo, pero sería más seguro.
Otra opción es tener un código de escritura impreso en el exterior de una placa de circuito o IC, y tener el mismo código grabado permanentemente en las entrañas de IC. Un flash de firmware solo tendrá éxito si ingresa este código durante la programación. El dispositivo no puede leer el código, solo se puede verificar si es correcto o no. Esto requeriría acceso a la placa de circuito para obtener el código, y no es un obstáculo para un ataque dirigido. Un fabricante de dispositivos también puede coludir y proporcionar una lista de los números de serie del dispositivo y sus códigos. Sin embargo, cuando se combina con firmware firmado y un puente de bloqueo de escritura, hará que la programación de firmware malicioso sea mucho más difícil.
Un esfuerzo a más largo plazo para crear un estándar para la cadena de custodia para dispositivos de hardware también puede ayudar, lo que incluiría solo permitir el envío de firmware a un dispositivo PCI (e) o USB si el controlador en el que estaba conectado lo permitía. y haga que la cadena llegue hasta el firmware principal del sistema. La contraseña del BIOS protegería a todos los dispositivos de los cambios de firmware, a menos que hubiera una vulnerabilidad que permitiera una omisión.
Creo que es igual de importante que exista una manera de verificar que el firmware no se vea comprometido, lo que significa que un dispositivo debe reportar una suma de comprobación criptográfica de su firmware a su dispositivo de control de una manera que no pueda ser manipulada por un firmware malicioso. . La estandarización de esto sería una excelente manera de infundir confianza cuando se utiliza hardware en situaciones sensibles.