En la actualidad se está hablando mucho de algo llamado ciberguerra. Esto implica que, para que exista una ciberguerra, deben existir ciberarmas. Lo primero que se deberá hacer es una definición de las mismas. ¿Qué se considera ciberarma? ¿Deben regularse? ¿Se deben publicar las mismas?
Primero, veamos qué entendemos por ciberarma. Un ciberarma es una pieza de software o dispositivo, que se utiliza para realizar un ataque a un sistema. Esta definición es demasiado genérica e incluiría a todo aquello que pueda usarse para realizar un ataque, incluso si no fue desarrollado inicialmente para realizar esa acción. Sería el equivalente a utilizar un coche para asesinar a alguien deliberadamente. Por supuesto, existen otras herramientas que se han desarrollado con el fin de realizar ataques. Éste sería el caso de botnets, por ejemplo, la botnet Mirai, tan en boca de todos.
«Se suele denominar como ciberarma como una pieza de software que se utiliza para realizar un ataque a un sistema. Pero Esta definición es demasiado genérica e incluiría a todo aquello que pueda usarse para realizar un ataque»
Ejemplos de ciberarmas creadas para tal fin:
Stuxnet. Esta ciberarma fue la primera desarrollada para atacar sistemas SCADA (Supervisor Control and Data Acquisition ) iraníes de la marca Siemens . Es de una sofisticación inusual. Estaba diseñada para atacar centrales nucleares, pasando desapercibida. Se distribuyó mediante memorias USB. Por el grado de complejidad de la herramienta, la eficacia de la misma y el desarrollo, es más que probable que, detrás de ella, estuviesen gobiernos. Se cree que es EEUU e Israel quienes estaban detrás del mismo. Estaba desarrollada en C y C++, aprovechaba vulnerabilidades 0-day del S.O. Windows, así como del sistema SCADA. Tenía la capacidad de hacer un ataque MiTM, de manera que no se detectase y se reiniciara el sistema atacado. Además, utilizaba un controlador firmado digitalmente, que le permitía instalarse como un Rootkit a nivel del Kernel. Era un gusano y su función no era llegar a “romper” el sistema por completo, para evitar que se realizase un estudio más profundo y llegase a ser detectado. Grababa durante 21 segundos los datos de los sensores, bajo un funcionamiento normal y los reproducía en bucle durante su activación, para evitar ser detectado. Hay fuentes que afirman que, en el caso de haberse descontrolado, podría haber provocado un desastre nuclear de proporciones similares a las de Chernóbil.
Duku. Este malware también está desarrollado para atacar sistemas SCADA. Se cree que está relacionado con Stuxnet. Sin embargo, en este caso, su tarea es recopilar información. Al igual que el anterior, se aprovecha de vulnerabilidades 0-Day y también utiliza certificados robados. El anterior se detectó en junio del 2010 y, éste, en septiembre del 2011, aunque se sospecha que llevaba al menos un año operando. Se ejecuta durante 36 días y, después, se elimina automáticamente. Parece que se desarrolló con Objetive C. Al igual que el anterior, parece que su origen es EEUU.
Flame. Este malware tenía como objetivo espiar los sistemas comprometidos, como llamadas de Skype, actividad del teclado, descarga vía BlueTouth, etc. Aunque se detectó en mayo de 2011, se cree que empezó sus operaciones alrededor de 2007. Entre los países en los que se detectó se encuentran Irán, Sudán, Siria, Líbano, Arabia Saudita y Egipto. Utiliza cinco cifrados distintos para almacenar la información que obtiene. Se cree que los desarrolladores de Stuxnet también están detrás de este malware. Utiliza dos vulnerabilidades que también empleaba Stuxnet y empleó una nueva técnica de colisiones para MD5, haciéndose pasar por un programa legítimo de Microsoft. Su despliegue se realizó vía memorias USB, actualizaciones falsas de Microsoft y aprovechando vulnerabilidades del sistema.
Wiper. Este malware se caracteriza por eliminar la información de los discos duros de sistemas Windows. Se utilizó para atacar sistemas informáticos del oeste de Asia en abril de 2012. Utiliza ficheros que empezaban con ~D, al igual que Flame, Duku y Stuxnet. La limpieza de los discos la realizaba siguiendo un patrón que permitía eliminar el contenido y, además, borrar también las huellas del propio malware.
Equation Group. Además de las anteriores, Kaspersky Labs, dio a conocer esta ciberarma. Es todavía más sofisticada que las anteriores, pues lleva activa un par de décadas. Utiliza un potente arsenal de troyanos, como EquationLaser, EquationDrug, DoubleFantasy, TripleFantasy, Fanny o GrayFish. Su persistencia e invisibilidad es lo que la hacen única. Este malware es capaz de reprogramar el firmware del disco duro de diferentes fabricantes, lo que le permite “sobrevivir” al formateo y reinstalación. Esta ciberarma se utiliza para realizar espionaje y posee una infraestructura vasta, con más de 300 dominios y más de 100 servidores alojados en diferentes países. Por la complejidad y potencia, se piensa que detrás de ella debe estar algún Estado.
Careto/The Mask Kaspersky lo descubrió en 2014. Es un malware con alto grado de sofisticación y, además, su origen apunta que podría ser español. Se distribuía mediante correos electrónicos, en los que se incluía URLs a sitios que parecían diarios españoles (phishing). Una vez la víctima visitaba el sitio falso, se aprovechaban exploits para Java, Flash y plugins de Chrome y Firefox (lo que lo hace multiplataforma), para comprometer el sistema. Se descargaba dos paquetes: Careto y SGH. El primero, con permisos de usuario y, el segundo, un Rootkit, para ejecutarse en el núcleo de sistema. Ambos firmados con un certificado de una compañía falsa. La misión de este malware era recopilar información sensible de la víctima, como claves de cifrado, configuración de VPN, etc. Se comunicaba con sus servidores C&C vía HTTPS. Según la revisión que realizó Kaspersky de los registros de estos servidores, es posible que haya versiones para Android e iOS, aunque no se han encontrado muestras. Parece que lleva operativo desde 2007.
Hackers y la disyuntiva de difundir conocimiento y aprender, frente a la autocensura
Ante todo esto nos encontramos con un problema claro: Qué hacer con una ciberarma. En el caso de Mirai, el código se publicó poco después del ataque que dejó a medio Internet inoperativo tras un ataque DDOS. Esto podría llevarnos a pensar que publicar el código es mala idea, ya que es accesible para muchas más personas, que podrán utilizarla para realizar aún más ataques. Sin embargo, gracias a la publicación del código, se ha podido estudiar y esto permite que pueda detectarse un ataque de la misma y pueda frenarse.
Además de esto, nos encontramos con los exploits, que se desarrollan cuando se encuentra una vulnerabilidad en un determinado software, para comprobar si efectivamente puede explotarse la misma. En este caso, nos encontramos con un problema similar al anterior. Por un lado, si se publica la vulnerabilidad y el exploit antes de que dé tiempo a corregir el problema, la vulnerabilidad será aprovechada por cibercriminales. Por otro, si no se publica y se espera a que el fabricante corrija el software, puede que ocurra que el mismo, bien por el coste que supone, bien por priorizar otras cosas, nunca se corrija.
A todo esto, debemos añadir que, si una persona ha encontrado una vulnerabilidad en un determinado software, tarde o temprano, otra podrá encontrarla, si es que no es conocida todavía. El problema viene en que, si ya era conocida y no se había publicado, es muy probable que forme parte de algún software malicioso que la esté aprovechando y, además, los usuarios y fabricantes, desconozcan que esto existe.
«Si una persona ha encontrado una vulnerabilidad en un determinado software, tarde o temprano, otra podrá encontrarla, si es que no es conocida todavía»
Podemos ver la actitud de algunos gigantes, como Google, que publica vulnerabilidades de otros, dando un margen escaso para reaccionar, lo que, a priori dejaría a miles de usuarios a merced de los ciberdelincuentes, hasta que se desarrolle.
El sentido común y, pensando en un mundo idílico, lo correcto sería reportar primero el bug al fabricante. Una vez corregido, publicarse para que la responsabilidad de disponer un sistema vulnerable no sea del fabricante ni del investigador, sino de aquellos que lo están utilizando y deben aplicar los parches a sus sistemas. Sin embargo, esto es una utopía. En la actualidad hay dispositivos vulnerables en el mercado (sobre todo cuando miramos el IoT). Los fabricantes no proveen una forma fácil y accesible para que sus dispositivos puedan ser parcheados. Además, en muchas ocasiones, ni siquiera desarrollan las mismas. A esto añadimos que, en muchos casos, el investigador que ha informado de la vulnerabilidad, se le considera un cibercriminal y se le denuncia.
Esto hace que, lejos de proteger un sistema y a sus usuarios, éstos queden expuestos por desconocimiento y, además, por falta de mecanismos para protegerse. ¿Por qué? Pues porque el cibercrimen es un negocio. Cuando existen vulnerabilidades de tipo 0-Day, hay un mercado para venderlas al mejor postor. Cuánto más tiempo se tarde en corregir ese problema, más dinero harán los cibercriminales explotándolo. Por supuesto, esto dependerá del tipo de vulnerabilidad. Por ejemplo, si es en dispositivos que permitan ser comprometidos por una botnet para hacer ataques DDOS, quien posea esos exploits podrá utilizarlos para vender servicios de tipo DDOS. Si es para, por ejemplo, comprometer un sistema y robar datos sensibles, se utilizarán para comercializar los datos de las víctimas.
Debemos tener claro que, para los cibercriminales, es un negocio. En el momento en que su exploit no es vendible porque ya es de acceso público, se acabó el negocio. Además, el fabricante, tiene una presión aún mayor para corregir el problema. El usuario tiene la información para dejar de utilizar el dispositivo/software vulnerable mientras se soluciona el problema.
En el caso de fabricantes que ignoren los avisos que hayan podido tener, esto puede ser muy útil. Sin embargo, en fabricantes que, sencillamente, no han tenido el tiempo suficiente para corregirlo, puede ser un problema grave. No es porque estén ignorando los reportes, es porque no les ha dado tiempo a corregirlos.
Con todo esto, nos encontramos -además- con las herramientas de «Botón Gordo». Aquellas que están diseñadas para hacer ataques sin prácticamente ningún conocimiento técnico. Solo instalar y darle a «Atacar».
Legislación. ¿Cómo se puede solucionar todo esto?
Es muy posible que, de entrada, pensemos que se debe prohibir la publicación de ciberarmas simple y llanamente. En todo su conjunto. Sin embargo, esto dejará que solo ciertas élites tengan acceso a las mismas y, dado que los cibercriminales se mueven con el mercadeo, no se acabará y, probablemente, no se frenarán los ataques.
Además, para poder poner en práctica una legislación así se necesitaría una infraestructura inmensa para poder controlar qué se está publicando.
Por otro lado, publicar sin más los exploits deja vulnerables a los usuarios y, en algunos casos, sin margen de maniobra para el fabricante.
Teniendo en cuenta todo esto, lo ideal sería legislar de manera que se fuerce a los fabricantes a realizar auditorías serias. Además de éstas, se les puede obligar a no poder comercializar productos que son vulnerables y que se conoce que lo son. Podemos añadir que deban proporcionar una solución para aquellos productos que ya están distribuidos. Es lo que ocurre con cantidad de productos, no necesariamente tecnológicos. Por ejemplo, cuando en un vehículo se detecta un determinado problema, el fabricante avisa a los propietarios para que pasen con sus vehículos al concesionario y pueda repararse.
Si la legislación se centra en frenar a los hackers y no en frenar a los cibercriminales y, a su vez, en conseguir que se fabriquen productos de calidad controlados al igual que ocurre en el resto de sectores, la traducción será que costará mucho investigar, descubrir y poder construir herramientas para poder evitar a los daños provocados por los cibercriminales.
