Uno de los principales objetivos de los autores de malware es que sus códigos maliciosos se activen tan pronto como sea posible, para que puedan realizar modificaciones claves (como instalar conexiones) en el código del sistema operativo y en las unidades del sistema, antes de que los componentes de la solución antivirus se inicien. Como resultado, los programas maliciosos y las soluciones antimalware juegan al gato y al ratón ya que operan al mismo nivel: el sistema operativo, las unidades del sistema y los paquetes raíz operan en modo kernel.
Los paquetes de arranque, o bootkits, representan hoy la tecnología más avanzada que poseen los ciberdelincuentes, y que permite que sus códigos maliciosos arranquen antes de que lo haga el sistema operativo. Esta tecnología está implementada en numerosos programas maliciosos.
Ya hemos escrito sobre bootkits como XPAJ y TDSS (TDL4). La última publicación sobre bootkits describe escenarios de ataques selectivos en base a tecnologías bootkit como la utilizada en la campaña de Careto/La Máscara. Sin embargo, estas investigaciones no se publican frecuentemente, por lo que algunos expertos pueden tener la impresión de que los bootkits, como los archivos de virus, están ‘muertos’, que Trusted Boot ha hecho su trabajo y que la amenaza ha dejado de ser relevante.
Pero los bootkits existen, tienen demanda en el mercado negro y los ciberdelincuentes los usan ampliamente con propósitos que incluyen ataques selectivos.
Fragmento del código cargador TDSS en MBR
Datos estadísticos
Primero, veamos las estadísticas de KSN. La siguiente tabla muestra la clasificación de los programas maliciosos que hemos detectado como Rootkit.Boot.*, entre el 19 de mayo de 2013 y el 19 de mayo de 2014.
| Familia | Usuarios | Notificaciones |
| Rootkit.Boot.Cidox | 45797 | 60787 |
| Rootkit.Boot.Pihar | 25490 | 75320 |
| Rootkit.Boot.Harbinger | 19856 | 34427 |
| Rootkit.Boot.Sinowal | 18762 | 420549 |
| Rootkit.Boot.SST | 8590 | 73079 |
| Rootkit.Boot.Tdss | 5388 | 19071 |
| Rootkit.Boot.Backboot | 4344 | 9148 |
| Rootkit.Boot.Wistler | 4230 | 13014 |
| Rootkit.Boot.Qvod | 1189 | 1727 |
| Rootkit.Boot.Xpaj | 690 | 2483 |
| Rootkit.Boot.Mybios | 442 | 5073 |
| Rootkit.Boot.Plite | 422 | 648 |
| Rootkit.Boot.Trup | 300 | 7395 |
| Rootkit.Boot.Prothean | 217 | 1407 |
| Rootkit.Boot.Phanta | 167 | 5475 |
| Rootkit.Boot.GoodKit | 120 | 131 |
| Rootkit.Boot.Smitnyl | 100 | 3934 |
| Rootkit.Boot.Stoned | 69 | 96 |
| Rootkit.Boot.Geth | 60 | 166 |
| Rootkit.Boot.Nimnul | 53 | 84 |
| Rootkit.Boot.Niwa | 37 | 121 |
| Rootkit.Boot.Fisp | 35 | 344 |
| Rootkit.Boot.CPD | 25 | 39 |
| Rootkit.Boot.Lapka | 19 | 21 |
| Rootkit.Boot.Yurn | 8 | 18 |
| Rootkit.Boot.Aeon | 6 | 6 |
| Rootkit.Boot.Mebusta | 5 | 5 |
| Rootkit.Boot.Khnorr | 4 | 4 |
| Rootkit.Boot.Sawlam | 4 | 7 |
| Rootkit.Boot.Xkit | 4 | 20 |
| Rootkit.Boot.Clones | 1 | 1 |
| Rootkit.Boot.Finfish | 1 | 1 |
| Total | 136435 | 734601 |
La tecnología de comportamiento detecta proactivamente la mayoría de los bootkits apenas se han instalado en el sistema. También pueden detectarse por primera vez cuando la solución antivirus realiza un análisis automático después del arranque del sistema, que inicia el proceso de eliminación de infecciones activas. Las estadísticas mencionadas incluyen sólo las detecciones de infecciones en el Registro de Arranque Principal (MBR). Las cifras también incluyen los datos recibidos de equipos infectados con anterioridad y en los cuales se instaló nuestra solución antivirus después de que se infectaron.
Podemos ver en la tabla anterior que los derivados de TDSS, Pihar y SST, se encuentran en el Top 5 de los bootkits detectados. El bootkit Harbinger, que ‘cubre’ el adware, se encuentra en la tercera posición y Sinowal en la cuarta. La primera plaza le corresponde, con diferencia, a Rootkit.Boot.Cidox. Puesto que Cidox tiene un rol especial en la evolución de los bootkits, nos referiremos a su historia en detalle.
Cidox: código abierto al público
Cidox se ofrece como complemento a otros programas maliciosos y se usa para proteger los programas maliciosos junto a los cuales se distribuye. Esto significa que este bootkit no se usa para construir su propia red de robots, o botnet, tipo TDSS.
Las versiones iniciales de este programa malicioso estaban incluidas en las bases de datos antivirus de Kaspersky Lab hace tres años, el 28 de junio de 2011. En ese entonces, Cidox era un hito en la tecnología maliciosa porque fue el primero en infectar el VBR en lugar del MBR.
Cidox se usaba para proteger el troyano banquero Carberp, además de otros programas maliciosos. Cuando se publicó el código fuente de Carberp, también 'se filtró’ el código fuente del bootkit. Como resultado, Cidox volvió a personificar la historia del famoso troyano ZeuS (Zbot). La ‘fuga’ del código fuente de ZeuS facilitó en gran medida el robo de dinero desde los sistemas bancarios online, y la publicación del código fuente de Cidox hizo que cualquier programador medianamente experto pueda escribir programas maliciosos capaces de funcionar en los niveles más bajos, antes de que el sistema operativo arranque.
Fragmento del código fuente de Cidox
Cidox se usa hoy para cargar y proteger una variedad de programas maliciosos, incluyendo crimeware, bloqueadores y malware diseñado para robar dinero desde sistemas bancarios online.
Таргетированные атаки
La campaña de Careto/La Máscara que mencionamos antes, no fue un caso aislado de bootkits utilizados en ataques selectivos. Hace poco escribimos sobre Hacking Team, una compañía cuyos programas (incluyendo bootkits) se usan para realizar operaciones policiales en varios países del mundo. Otra compañía, FinFisher, ofrece servicios similares, y entre los programas que desarrolla también se encuentra un bootkit, Rootkit.Boot.Finfish, que se encuentra en el último lugar de nuestra clasificación.
Lista de productos y servicios de la página oficial de FinFisher
Kaspersky Lab presentó un análisis de los productos de FinFisher en una conferencia de Virus Bulletin. La presentación se encuentra en el sitio web de VB.
BIOS. La búsqueda de nuevos puntos de inicio.
La incesante lucha entre las soluciones antivirus y los códigos maliciosos está llevando a ambos a la próxima fase de su evolución. Los autores de programas maliciosos tienen que buscar nuevos puntos de inicio, y el BIOS puede ser uno de ellos. Sin embargo, apenas se ha pasado de la etapa de pruebas de investigación, debido a que la modificación masiva del BIOS es una operación ‘inconveniente’ para los autores de programas maliciosos, pues exige considerables esfuerzos y por lo tanto sólo puede hacerse en el caso de ataques altamente selectivos.
¿En qué se convertirán los sueños?
El sistema BIOS clásico es una verdadera reliquia difícil de usar y con numerosas limitaciones. Es por esto que el consorcio UEFI Forum ha desarrollado una interfaz modular unificada completamente nueva, UEFI, en base a especificaciones provistas originalmente por Intel.
¿Qué ofrece UEFI?
- Compatibilidad con equipos modernos.
- Arquitectura modular.
- Código EFI Byte: arquitectura y controladores independientes del tipo de CPU (x86, x86-64, ARM/ARMv8).
- Varios complementos para UEFI, que se descargan para diferentes dispositivos, incluyendo los portátiles.
- Desarrollo en base a un lenguaje de programación de alto nivel (un dialecto de C).
- Arranque seguro (Secure Boot).
- Arranque de red.
También recomendamos leer las 10 confusiones más comunes sobre UEFI.
Los siguientes sistemas operativos son compatibles con UEFI:
- Linux con Lilo o una versión especial del gestor de arranque GRUB.
- FreeBSD.
- Apple Mac OS X para sistemas compatibles con Intel (v10.4 y v10.5 son parcialmente compatibles; 10.8 es completamente compatible).
- Microsoft Windows, desde Windows Server 2008 y Windows Vista SP1 x86-64. Microsoft Windows 8 es compatible con UEFI, incluyendo UEFI 32 bit, y un arranque seguro.
En resumen, ¿qué ofrece UEFI? Un método conveniente, unificado, bien documentado y fácil de entender para desarrollar sin recurrir al lenguaje ensamblador 16-bit.
Desde el punto de vista de una solución antimalware, UEFI es un lugar muy bueno para implementar un disco de rescate. Primero, el código del disco de rescate se ejecuta antes que arranquen el sistema operativo y el gestor de arranque. Segundo, UEFI ofrece un fácil acceso al disco duro, y un acceso relativamente fácil a la red. Tercero, se puede crear un GUI sencillo y fácil de entender. Es exactamente la receta para tratar amenazas sofisticadas y altamente resistentes, como los bootkits.
Desde el punto de vista de los autores de códigos maliciosos, todo lo dicho es también una ventaja para un bootkit, pues proporciona una protección confiable a los programas maliciosos. Por lo menos hasta que los desarrolladores de firmware se preocupen por implementar una protección adecuada.
Sin embargo, antes de pasar a la funcionalidad de la protección, nos gustaría tocar un tema importante. Los fabricantes de equipos desarrollan su propio firmware y toman sus propias decisiones sobre el soporte para características opcionales que ofrece la especificación UEFI. Estas características incluyen, antes que nada, firmware de seguridad en SPI Flash contra modificaciones yarranque seguro. En el caso de UEFI, tenemos el problema clásico de conveniencia versus seguridad.
Amenazas y mecanismos de protección
No es sorprendente que, a medida que UEFI se hizo más universal, atrajera el interés de investigadores independientes como un potencial vector de ataque (uno, dos, tres). La lista de los posibles puntos de penetración es bastante amplia e incluye gestores de arranque del sistema operativo y EFI comprometidos (inyectando, remplazando o infectando), controladores UEFI comprometidos, acceso directo a SPI Flash desde el sistema operativo, y otros. En el caso del arranque en el modo UEFI+Legacy (CSM), siguen siendo efectivos los viejos métodos que usaban los desarrolladores de bookits para infectar el sistema. También es muy obvio que si se compromete el ambiente de ejecución en pre-arranque, todos los mecanismos de seguridad de Windows, como Patch Guard, la verificación de firmas de controladores, etc., quedarán inutilizados.
La especificación UEFI versión 2.2 incluía un nuevo protocolo de arranque seguro que tenía que proporcionar un ambiente seguro de ejecución en pre-arranque, así como protección contra códigos maliciosos ejecutados desde puntos potencialmente vulnerables.
El protocolo de arranque seguro define el proceso usado para verificar los módulos que se están cargando, como los controladores, el gestor de arranque del sistema operativo y aplicaciones. Estos módulos deben estar firmados con una llave especial y la firma digital debe verificarse antes de cargar el módulo. Las llaves que se usan para verificar los módulos deben guardarse en una base de datos dedicada y protegida contra penetraciones, como una TPM. Las llaves pueden añadirse o modificarse con otras llaves, lo que proporciona un método seguro para modificar la misma base de datos.
En base a lo anterior, la implementación de los siguientes mecanismos de seguridad de parte de los desarrolladores de firmware y de sistemas operativos puede considerarse óptima desde el punto de vista de la seguridad:
- Proteger SPI Flash contra modificaciones maliciosas. Soporte de desactivación para la actualización de firmas desde el sistema operativo.
- Bloquear el acceso a secciones críticas del UEFI, incluyendo la mayoría de la variables del ambiente.
- Abandonar por completo el uso de CSM.
- Proteger contra modificaciones maliciosas el volumen del sistema que contiene los controladores UEFI, el gestor de arranque y aplicaciones.
- Los desarrolladores de firmware y de sistemas operativos deben implementar y activar el Arranque Seguro (así como el mecanismo Trusted Boot implementado en el sistema operativo Windows).
- Proteger el almacenamiento de las llaves contra modificaciones.
- Proteger el mecanismo usado para duplicar la base de datos en la que se guardan las llaves contra ataques tipo spoofing y otros.
- Implementar una protección contra los ataques “Evil Maid” que incluyen el acceso físico al equipo.
- Usar la experiencia acumulada de las compañías antimalware e implementar tecnologías antimalware a nivel del firmware.
Sin embargo, hay que tener en cuenta que cuanto más avanzados sean los mecanismos de protección que se implementen, los ciberdelincuentes sacarán de la galera ataques más avanzados contra el UEFI. Los métodos que hoy se usan están basados en el remplazo del gestor de arranque UEFI para el sistema operativo Windows 8. Durante su inicialización, el gestor malicioso del sistema operativo carga en la memoria un gestor remplazado en la memoria, desactiva los mecanismos de seguridad Patch Guard y la verificación de firmas del controlador con un método u otro, establece las conexiones necesarias y le otorga el control al código del gestor original.
En el caso del sistema operativo Mac con cifrado completo del disco, se utiliza un enfoque original basado en la implementación de un sencillo capturador de teclado, o keylogger, UEFI para obtener la contraseña secreta que introduce el usuario mediante el teclado para descifrar los contenidos del disco duro en el arranque del sistema. En los demás aspectos, el método basado en el remplazo o la infección del gestor de arranque del sistema también se aplica en este caso.
Conclusiones
Los bootkits han evolucionado desde el desarrollo de la Prueba de concepto hasta su propagación masiva, llegando a convertirse hoy en software de código abierto. El lanzamiento del código malicioso desde el Registro de Arranque Principal (MBR) o el Registro de Arranque del Volumen (VBR) les permite a los ciberdelincuentes controlar todas las etapas del inicio del sistema de arranque. Este tipo de infección se ha convertido en un estándar entre los autores de programas maliciosos. Su implementación se basa en tecnologías probadas y de profunda investigación. Lo importante es que estas tecnologías están disponibles, en la forma de un código fuente, en una variedad de recursos. En el futuro, esto puede conducir a un significativo aumento en la cantidad de programas maliciosos basados en estas tecnologías, con apenas pequeñas modificaciones en la lógica de operación de los programas individuales. Prevemos que aparezcan nuevas modificaciones de TDSS y Cridex, que ya son comunes entre los ciberdelincuentes. También nos preocupa que los ciberdelincuentes usen estos programas maliciosos para lanzar ataques contra sistemas que usan tecnologías Default Deny.
Es crucial remarcar que las tecnologías de punta antimalware implementadas en nuestros productos anulan exitosamente estas infecciones. Puesto que resulta difícil predecir en este momento qué métodos específicos de enmascaramiento, bloqueo o de resistencia contra las soluciones antimalware llegarán a inventar los ciberdelincuentes en un futuro cercano,la implementación de las tecnologías antimalware a nivel del firmware, en combinación con los mecanismos de protección arriba descritos, permitirá que las soluciones de seguridad neutralicen los rootkits y bootkits antes de que los códigos maliciosos tomen el control. Asimismo, la incorporación de un módulo antimalware en UEFI simplificará el proceso de eliminación de infecciones y el desarrollo de nuevos métodos para detectar bootkits recién desarrollados que usan tecnologías nuevas y avanzadas de enmascaramiento, y rootkits que interfieren con el funcionamiento del sistema o de la solución antimalware.
P.D. Los autores agradecen especialmente a Vasily Berdnikov por su ayuda en el material de investigación para este análisis
Saludos.
Lexer Pars.
No hay comentarios:
Publicar un comentario