En los anteriores artículos explicaba que son las APT’s o Amenazas Persistentes Avanzadas y los anillos de protección de la arquitectura x86. Teniendo en cuenta esto, os voy a contar algo que pasó en el año 2013.
¿Qué pasaría si un amigo nos contara que su PC ha sido infectado con un malware que es muy difícil de detectar y se comporta de una manera muy extraña? Lo primero que pensaríamos es que ha sido victima de una APT, pero ¿por qué iba a atacarle una APT? Si las APT’s atacan a objetivos muy específicos como empresas o personas de las que se puede obtener información significativa, ¿por qué iban a utilizar un software tan avanzado contra un amigo nuestro? ¿Qué clase de secretos guarda para emplear algo tan sofisticado? Tendría que tratarse de un súper espía internacional con información Top Secret. Pero, y ¿si no lo fuera? ¿Qué sentido tendría?
Vamos a complicarlo un poco más. ¿Y si el comportamiento que describe del malware es tan sofisticado que no podríamos creer que es real? ¿Y si las pruebas que aporta no son concluyentes? Llegaríamos a pensar que, o nos está mintiendo o está loco.
Esto es lo que sucedió en el año 2013 con el experto en ciberseguridad Dragos Ruiu (@dragosr) y BadBios.
¿Quién es Dragos Ruiu?
Es el fundador de la competición Pwn2Own, organizador de las conferencias CanSecWest y PacSec. Tiene un amplio y largo currículum en ciberseguridad. En otras palabras, es alguien de quien puedes fiarte.
¿Qué es BadBios?
BadBios es un supuesto malware con unas propiedades bastante avanzadas. Salto a todos los canales de ciberseguridad en el año 2013, levantando una gran polémica porque las características de este malware rozaban la ciencia ficción, sino fuera porque para todas las característica que se le atribuye a BadBios, existe una prueba de concepto verificable pero no tan compleja como reportaba Ruiu.
Lo que ocurrió
Todo comenzó después de que Ruiu realizara una instalación de OS X en un MacBook Air. Notó que la secuencia de arranque del ordenador se modificó por arte de magia, resultándole imposible “arrancar” el MacBook Air desde un CD-ROM. Por lo que concluyó que el computador estaba infectado de un malware y este tenía la capacidad de modificar el firmware de arranque del equipo, es decir, la BIOS.
Más tarde notó que algunos archivos eran eliminados y que el MacBook Air borraba algunos datos y hacia cambios de configuración.
Meses después, volvió a observar este comportamiento entre otros equipos de su red interna, incluyendo algunos equipos con Open BSD y otros con Windows. Lo que significaba que el malware era independiente del sistema operativo.
Otro de los reportes que aportaba era que comenzó a observar en su red paquetes del protocolo IPv6 que procedían de su equipo e incluso de otros equipos de la misma red que no tenían habilitada el protocolo IPv6.
Estuvo cerca de 3 años con estos problemas, por lo que probó de todo, desde reinstalar el sistema operativo en discos duros nuevos, hasta privar a los equipos de toda conexión externa. Corto las conexiones de red deshabilitando tarjetas WIFI y Bluetooth, aisló los equipos cortando las conexiones con la red eléctrica y trabajando sólo con baterías.
Como él mismo narraba:"Teníamos un ordenador aislado (air-gapped) sobre el que acabábamos de reflashear el BIOS, un disco duro nuevo recién instalado, y cero datos en él y el Sistema Operativo Windows recién instalado desde un CD", "En un momento, estábamos editando algunos componentes (del registro de Windows) y nuestro editor de registro (regedit) se deshabilitó. Fue como: espera un minuto, ¿cómo pudo ocurrir? ¿Cómo pudo la máquina reaccionar y atacar el software que estamos usando para atacarla? Esta es una máquina asilada y, de repente, la función de búsqueda en el editor de registro dejó de funcionar cuando la usábamos para buscar sus claves".
No fue hasta que deshabilitó el controlador de sonido y desconectó los altavoces y el micrófono que los equipos dejaron de mostrar comportamiento anómalo, llegando a la conclusión de que el virus se transmitía a través del sonido y más concretamente desde una frecuencia inaudible para el ser humano, lo que se conoce como ultrasonidos.
Defendía que los equipos comprometidos, infectaban a los dispositivos USB que se enchufaban a él, siendo estos dispositivos USB un vector de infección para otros PC’s. Además de que el malware no le permitía acceder a las webs donde podía encontrar herramientas para flashear y restablecer el firmware de las memorias USB (todas ellas eran “.ru”). Recordemos que en 2010 se descubrió la APT Stuxnet, y que este infectaba a las máquinas centrifugadoras mediante un USB malicioso.
Después de esos tres años Ruiu decidió contar su experiencia y así saltó la polémica a blogs y foros especializados en ciberseguridad. El especialista en ciberseguridad Arrigo Triulzi le dijo al medio Arstechnica que: "Dragos es definitivamente uno de los tipos buenos y confiables, y nunca, ni remotamente, pensé que fuera deshonesto". "Nada de lo que describe es ciencia ficción tomado individualmente, pero nunca lo hemos visto en la naturaleza". Asegurando, en un primer momento, que el comportamiento de BadBIOS era posible. Pero más tarde rectificó mostrándose más escéptico debido a la falta de pruebas. Triulzi es conocido porque modificó el firmware de la tarjeta de red Ethernet de su PC, pudiendo conectarse a ella mediante conexión ssh y creando una puerta trasera indetectable.
Ruiu aportó como pruebas imágenes del disco duro e imágenes de la BIOS. A lo que Triulzi comentó que "las imágenes del disco duro eran perfectamente normales sin nada sospechoso en ellos", al igual que en las imágenes de la BIOS o los datos de monitorización.
Otro analista en seguridad, Tavis Ormandy, mostraba abiertamente su escepticismo. Decía haber echado un vistazo al volcado de la BIOS, a los logs de monitorización de procesos, a los archivos de fuentes y a las imágenes del disco y no ver nada que sugiriera que hubiera algo sospechoso.
Viendo BadBios desde otra perspectiva
Volviendo al principio del artículo, analicemos el comportamiento de BadBIOS desde la perspectiva de los anillos de seguridad de la arquitectura x86. Este supuesto malware no podría ejecutarse en el anillo 3 de aplicaciones de usuario, pues desde ese anillo no tendría acceso al hardware. Tampoco desde el anillo 0 (el kernel), pues sería detectado desde el propio Sistema Operativo y con una simple reinstalación del Sistema Operativo acabaríamos con el problema. El malware tendría que estar ejecutándose en un modo más privilegiado.
Considerando el anillo -1 como el hipervisor, aún sería fácil de detectar y deshabilitar. Simplemente desactivando el hardware de virtualización desactivaría la ejecución paralela de otro posible Sistema Operativo.
Por lo que nos quedaría solamente dos anillos en los que podría ser ejecutado, el anillo -2 ó Modo de Gerencia de Sistema (SMM), o el anillo -3 el Intel Management Engine (IME).
Pensando paralelamente, si el malware se propaga por ultrasonidos, podríamos ver la hoja de características del chipset de los equipos y comprobar si este hardware es capaz de reproducir ultrasonidos. En general los altavoces de los equipos junto con los micrófonos trabajan en un espectro de frecuencia optimizado para el intervalo de 20 a 24 KHz. El oído humano capta sonidos desde los 40 Hz hasta los 20 Khz, por lo que sólo nos dejaría un ancho de banda de 4 KHz para trasmitir datos. Esto es un ancho de banda muy bajo para trasmitir datos.
Hubo un equipo en el MIT que trabajó en el campo de las comunicaciones inalámbricas empleando ultrasonidos. El instituto alemán de comunicaciones Fraunhofer también publicó un artículo acerca de este tipo de comunicaciones encubiertas. Es real que los ultrasonidos pueden usarse para trasmitir datos. Existen pruebas de concepto en GNU Radio que funcionan como un antiguo Modem por tonos, se pueden encontrar en Github, o en el siguiente blog o en artículos científicos como el siguiente: “Speaker-to-speaker covert ultrasonic communication”
BadBios es un mito
Han pasado ya más de 10 años desde que Dragos Ruiu supuestamente se infectara de este malware y de haber sido real se hubiera desensamblado, inspeccionado y mostrado pruebas concluyentes incluso se habría realizado ingeniería inversa de los firmware de los Dispositivos USB con los que se propagaba. Todos los expertos que analizaron las pruebas llegaron a la misma conclusión de que se trataba de pruebas perfectamente normales. Probablemente todas las experiencias que aportó se debieran al sesgo que conduce a errores en la causalidad.
Se podría concluir que algo parecido se podría crear en el anillo -2 o en el anillo -3, usando ultrasonidos para comunicarse pero con un ancho de banda muy limitado, lo que significaría que no serviría para exfiltrar datos.
