Ataques DoS como herramienta de intrusión

Normalmente cuando se habla de denegaciones de servicio (DoS, Denial of Service) se suele entender un ataque a un sistema de computadoras o red que causa que un servicio o recurso sea inaccesible a los usuarios legítimos. Una técnica habitual es la sobrecarga de conexiones o peticiones hasta que el servicio llega al límite de su capacidad. Usualmente los ataques DoS se consideran un fin en sí mismos, el objetivo es que el sistema deje de responder.

Sin embargo un ataque DoS puede ser usado como parte de un asalto más sofisticado, existen escenarios en los que deshabilitar un sistema forma parte de los requerimientos para un ataque exitoso. Un ejemplo clásico de esto son los ataques basados en IP-Spoofing , en ellos un atacante falsifica la dirección de un tercero en sus comunicaciones con un objetivo. Si se trata de un spoofing de protocolo TCP tiene el inconveniente de que las respuestas del objetivo llegan de vuelta hasta ese tercer sistema por ser suya la dirección IP de origen falsificada. Este tercer sistema al recibir un SYN+ACK fuera de secuencia responde con un RST cortando la comunicación y terminando por tanto el intento de IP-Spoofing. Por ello para que un ataque de este tipo tenga éxito es necesario primero deshabilitar al tercer sistema, por ejemplo mediante un SYN flood. (Para saber más de este tipo de ataque)

Otro contexto seria la denegación de servicio de un sistema centralizado, por ejemplo de autenticación o de logging, para así debilitar la seguridad de los sistemas que dependen de él.

Veamos un ejemplo concreto de forma practica:

Supongamos a un atacante que desea penetrar en una red comprometiendo un router A , router CISCO con IP 172.21.1.1, este router esta correctamente asegurado y dispone de la última versión de IOS. Sin embargo el atacante ha podido hacerse con acceso físico a un router B que se supone tendrá los mismos parámetros, mediante el procedimiento de recuperación local ha conseguido hacerse el fichero de configuración.

Analizado el fichero del router B descubre la siguiente configuración:

aaa new-model

aaa authentication login default tacacs+ local

tacacs-server host 10.130.1.1

tacacs-server key secreto

O lo que es lo mismo el router tiene como sistema principal de autenticación un servidor tipo TACACS+ con ip 10.130.1.1 donde se encuentran los nombres de usuario y contraseñas autorizadas, si falla la conexión con este sistema se emplean los nombres de usuario y contraseñas almacenadas en local. En este caso:

enable secret 5 $1$B8pH$PmmcMRoqfeEtQ7WxL865a0

username abc secret 5 $1$fBYK$rH5/OChyx/

Si bien las password se encuentran en formato hash MD5, un ataque de cracking determina que el acceso con nivel enable es mediante la password “password”. Mientras que el usuario “abc” tiene la password “xyz”. El problema para nuestro intruso es que no es posible usar este usuario local en el RouterA a menos que el servidor TACACS+ deje de funcionar.

Asumiendo que el atacante tiene una conexión lo suficientemente buena con el servidor TACACS+ , podría hacer un simple pero efectivo SYN flood contra el puerto 49 usado por este servicio para así dejarlo inaccesible para terceros. Para ello podría por ejemplo usar la herramienta hping.

./hping2 10.130.1.1 -p 49 -S -a 172.21.1.1 -i u1

Con esto el servidor de autenticación recibiría una avalancha de paquetes SYN con la ip de origen del routerA y se vería imposibilitado para responder las verdaderas peticiones del routerA, que pasaría a usar la autenticación local.

Así nuestro atacante solo tendría que acceder mediante telnet al router objetivo, routerA, pudiendo usar las password locales que previamente extrajo de routerB. Con ello logra acceso total a dicho router y por extensión a las redes que conecta el mismo.

Como vemos en este ejemplo mediante un DoS hemos logrado el acceso a un sistema.

Modifiquemos ahora nuestro escenario y supongamos que nuestro atacante forma parte de un Tiger Team gubernamental durante un hipotético conflicto u operación de ciberinteligencia se abrirían nuevas vías para realizar ataques DoS que serian inimaginables en un ataque informático tradicional. Nos referimos al DoS físico, es decir la inutilización o destrucción material del sistema o de sus conexiones.

Por ejemplo en caso de conflicto se podría ordenar el bombardeo sobre unas instalaciones donde se ubican los servidores que se pretende deshabilitar, o se podría enviar un equipo de fuerzas especiales para cortar un enlace terrestre de fibra óptica y obtener el mismo resultado. El objetivo puede ser la denegación en servicio en si misma, o como veíamos en el ejemplo el facilitar acceso en otros sistemas. Estaríamos ante el caso de una acción militar convencional sirve como medio o multiplicador de efectos para un ataque informático.

Achtung Hacker!

Estrategias militares en Ciberespacio I: Blitzkrieg

Poca o ninguna referencia a estrategias de ciberguerra a nivel operacional (nivel intermedio y diferente de la guerra entre la estrategia militar, que considera la guerra en general, y las tácticas, que engloban a las batallas individuales. Glantz, Soviet Military Operational Art, p.10. (En inglés)). 

Desde Areópago vamos a aportar nuestro Brainstorming a este tema en una serie de artículos. En algunos casos, como en este artículo, intentaremos la adaptación de estrategias conocidas, en otros, contaremos estrategias ya seguidas en ciberconflictos conocidos, y también aportaremos ideas que espero sean influyentes. Queridos lectores, como con todos los artículos que hemos publicado sentíos libres de comentar nuestras ideas o aportar las vuestras. 

La historia bélica, demuestra que el que entiende mejor las "armas" del momento y entiende la estrategia a usar con las mismas, normalmente prevalece en la guerra. Ejemplo de estos casos son el Capitán Nelson en la batalla de Trafalgar, Alejandro Magno en Gaugamela o Napoleón manejando, este último, eficientemente la artillería gracias a la influencia de Jean Baptiste Vaquette de Gribeauval.

Blitzkrieg

Estaba yo jugando a un wargame (de mesa, Barbarossa: Kiev to Rostov) e intentando defender Rostov del avance del Eje con el ejército rojo y me puse a pensar si la guerra Blitzkrieg (Guerra Relámpago) que tanto éxito le dieron a los alemanes durante la Segunda Guerra Mundial podría aplicarse a un escenario de ciberguerra, algunas ideas se me han ocurrido.

La guerra relámpago era un nuevo y terrorífico concepto de la guerra, un golpe frontal a todo lo que se ponía por delante, siendo el general Heinz Guderian uno de sus grandes exponentes, el mismo fue el encargado de barrer a los aliados en Francia y los echaron a patadas al Canal de la Mancha durante los primeros años de la guerra. Así mismo esta estrategia aplastó en primer término al ejército rojo en la operación Barbarossa, siendo este éxito, en parte, la razón de su posterior derrota dada la sobre extensión de las líneas de suministro dado la gran cantidad de terreno avanzado en territorio soviético.

La rutina de esta estrategia consistía en mandar un avión de reconocimiento (normalmente al alba) para  situar las posiciones enemigas.

El segundo paso es un intenso bombardeo usando todo lo posible, artillería y por oleadas de Junker 87 (el famoso Stuka) con sus bombardeos en picado. El objetivo era debilitar las posiciones defensivas en un punto muy concreto.

El tercer paso son las divisiones de tanques Panzer, rodando a toda velocidad, golpeando fuerte y pasando por encima de todo lo que se ponía por delante, generalmente por una sola carretera.

Tras si llegaban los regimientos de infantería motorizada. Esta toma posiciones tras las líneas defensivas enemigas, las cuales, debido a la velocidad de penetración, no son conscientes de que están siendo rodeados. ¡Ojo! los Panzer siguen avanzando :D

El último paso es atacar las líneas defensivas desde la línea del  frente inicial, embolsando a los enemigos y venciéndolos así.

El objetivo es crear bolsas de enemigos en diferentes puntos, algunas veces a la vez en diferentes puntos.

El ataque de los Panzers sigue por la carretera tomada y ya con menos defensas la táctica de rodearlas es más sencilla, llegando a realizar en un solo ataque varias bolsas de enemigos.

Este sistema hace avanzar la línea del frente mucho en MUY poco tiempo y destroza la estrategia defensiva del enemigo. Y todo esto porque la Wehrmacht entendió en 1938 un arma, el tanque, que ya se usaba años atrás. Por ejemplo, el primer ataque blindado francés fue el 6 de Abril de 1917 en la ofensiva de Aisne, cuando el primer tanque alemán data de este mismo año, es decir, en unos principios iban muy por detrás tecnológicamente, pero a través de los años vieron la auténtica importancia de este arma y se dedicaron a desarrollar su avance tecnológico y teórico sobre su función en el campo de batalla. La clave está en la velocidad.

CiberBlitzkrieg

Si simplificamos aún más la doctrina de la guerra relámpago, podemos definir los siguientes pasos siendo así más fácil adaptarlos, como se verá estos pasos son en algunos casos tareas paralelas:

    1- Obtención de información sobre las fuerzas y situación enemigas.

    

    2- Bombardeo/Debilitamiento de las defensas.

    

    3- Un equipo realiza un ataque. Objetivos velocidad y sobre todo profundidad.

    

    4- Otro equipo sitúa posiciones tras las líneas defensivas siguiendo el camino abierto por el ataque anterior. El primer equipo prosigue con su ataque (paso 3) buscando profundidad. 

    

   5- Atacar las posiciones enemigas rodeadas. El primer equipo prosigue con su ataque (paso 3) buscando profundidad.

    

     6- Otros equipos se encargan de otros sistemas según se va profundizando.

    

Seguro que ahora está bastante claro, para un experto en redes, como aplicar esta estrategia en un ciberconflicto. No obstante, esta estrategia no es siempre la recomendada ya que produce mucho "ruido" y puede alertar a los administradores del sistema asediado rápidamente, y recordemos que es importante, la desconexión de sistemas una vez se entiende lo que ocurre se puede realizar muy muy rápido (tirar del cable), o muy rápido añadiendo reglas al firewall.

Como ya he expresado en otros artículos, en este mundo, el tanque es la vulnerabilidad/exploit 0 day (vulnerabilidad no conocida fuera del descubridor y un grupo muy cerrado, por este motivo lo normal es que no exista parche para arreglarla). Esta es el arma nos puede permitir acceder a una red enemiga y además permitir profundizar en la misma (En una red suelen existir sistemas muy similares para facilitar la gestión de los mismos).

Pensemos una situación donde esta estrategia es recomendable:

Un Tiger Team de un país consigue un 0 day para una vulnerabilidad que aún no ha sido publicada, este exploit lo han comprado en el "grey market" y por lo tanto saben que la información de esta vulnerabilidad puede llegar rápidamente a sus enemigos y estos pueden aislar sus sistemas vulnerables y aplicar reglas a sus IPS "Intrusion Prevention Systems". Además supongamos que el exploit deja rastros muy identificables en el sistema hackeado (un servicio inestable por ejemplo o existe un sistema centralizado de log donde quedan registros del ataque), en este caso, sabe que desde que entra hasta que le detecten puede pasar poco tiempo. En este caso es altamente recomendable una CiberBlitzkrieg.

Elegir el momento es clave a la hora de elegir un ataque (¡obvio!), en estos casos, se suele decir que las noches de las fiestas y fines de semana es lo mejor, claro está es seguir el horario y las costumbres del enemigo (¡obvio! x2).

Realizando el ataque, con el exploit que tiene este TT, se logra entrar en uno o varios sistemas de la red enemiga, el TT crea un "camino" de entrada sencillo para que otro TT entre en estos sistemas. Lo normal suele ser que estos sistemas pertenezcan a una DMZ. Esta es la estructura más común de una red:

La tarea del segundo TT, la metástasis por el resto de sistemas y en la elevación de privilegios si es necesario de la DMZ, además y dado la necesidad de velocidad en cada intrusión se ejecuta un programa que se encarga de recolectar ficheros claves (identificamos estos ficheros por extensión, por palabra clave dentro de ese fichero o ciertos ficheros conocidos como los de passwords ) y enviarlos a la "base de operaciones" donde son analizados por otro TT, descifrar contraseñas, obtener información que permita mejorar la profundidad en la intrusión, el análisis de inteligencia de documentos obtenidos puede hacerse en paralelo por analistas de inteligencia.

Mientras el primer TT, siguen buscando maneras de pasar al siguiente nivel, según la arquitectura normal, la red interna. Para la realización de esta tarea es posible que sea necesario extender la intrusión junto al segundo TT, pero una vez conseguida, se centrarán en abrir un camino para que otro TT (un tercer TT si es necesario) amplíen la intrusión, la redes internas suelen tener poca protección y suelen tener muchos sistemas, para esta tarea lo ideal sería un buen número de expertos.

A partir de este momento, el primer TT busca conexiones a otras redes (muy posiblemente las interesantes), aquí entramos en el bucle de intrusión en nueva red/metástasis en la misma. Tal y como lo vemos, la ciberblitzkrieg debe pasar por alto todos los sistemas de logs, da igual generar alertas, da igual dejar servicios caídos, da igual alterar la configuración de los sistemas, se trata de alcanzar los objetivos propuestos en el menor tiempo posible. El TT principal debe de ir accediendo a sistemas lo más rápido que pueda sin preocuparse de ninguna otra cosa, va poniendo puertas traseras y pasándole el acceso a los equipos que se encargan de descargar información de los mismos o de hacer lo que tengan que hacer.

Otras opciones a tener en cuenta, es introducir un equipo para evitar la desconexión (lógica), por ejemplo cambiando las contraseñas de los administradores, cerrando servicios de administración remota o metiendo reglas de firewall contra los propios administradores.

Clave es tener diferentes equipos que se dedicarán a diferentes funciones, estos equipos han de compartir información que puede facilitar la intrusión y la identificación de los sistemas más interesantes a atacar.

Rompiendo SSL a lo pobre

Existe una forma de descifrar SSL (y TLS) sin necesidad de ser un poderoso gobierno, tener la capacidad de cálculo de la NSA o ser Bruce Schneier.


Simplemente necesitamos tener acceso a la llave privada del servidor. Algunos pensaran que es imposible, que la llave privada siempre se guarda de forma segura. Pero no, en algunos casos la llave privada del servidor SSL puede ser averiguada.


Por ejemplo cuando se utiliza un software con un certificado SSL pre-configurado. Simplemente tenemos que obtener acceso a una copia de ese software y recuperar la llave privada.

En el manual probablemente indicara que es necesario cambiar el certificado SSL de ejemplo por uno seguro, pero ¿Quién se lee los manuales?

Situaciones habituales donde se pre-configuran certificados SSL inseguros:
- Servidores web portables o de instalación fácil. Por ejemplo: XAMPP, Apache2triad, Portable Apache, etc.
- Routers o pequeños dispositivos de red domésticos.
- Versiones antiguas de servidores de aplicaciones. Por ejemplo: Weblogic, Websphere, etc.

También podemos buscar llaves SSL dejadas por descuido en: repositorios de configuraciones desprotegidos, carpetas de red públicas, equipos de administradores, etc.

Incluso podemos intentar algo de Google hacking, por ejemplo:
- filetype:key server
- filetype:key private

Una vez tengamos la llave podemos utilizarla para descifrar tráfico SSL o TLS previamente capturado.

Por ejemplo supongamos que tenemos un servidor con XAMPP 1.7.4 en una red local en la que podemos hacer sniffing. A este servidor se conecta mediante HTTPS un usuario que descarga un fichero que nos interesaría obtener.

Primeramente comprobamos si el servidor SSL utiliza el certificado instalado por defecto:

Efectivamente usa un certificado inseguro. Así que vamos a la página oficial de XAMPP y descargamos la misma versión para obtener la llave privada correspondiente a este certificado.

Luego simplemente capturaríamos con Wireshark y lo configuraríamos para que pueda descifrar el tráfico adecuadamente:

Configuración: Edit > Preferences > Protocols > SSL

En esta pantalla debemos configurar el valor de “RSA keys list”, con el siguiente formato:ip_servidor,puerto,protocolo_encapsulado,localización_llave_privada

En este caso:192.168.1.2,443,http,c:\server.key

Y listo, ya podemos obtener en claro el contenido del tráfico SSL capturado:

Como podéis ver, incluso la robustez de SSL puede ser rota con pocos recursos ante una administración descuidada del servidor.

Rompiendo SSL al estilo gubernamental.

Actualmente SSL es el protocolo utilizado cuando se quiere asegurar las comunicaciones con una web, ya que provee de dos importantes funcionalidades. La primera es el cifrado, impide que los datos que enviamos y recibimos puedan ser legibles por terceros que pudieran estar espiando nuestras comunicaciones. La segunda y no menos importante es el uso de certificados que nos garantizan que en el otro extremo de la comunicación esta quien dice ser. De poco sirve cifrar nuestras comunicaciones con pongamos por ejemplo www.mibanco.com si en realidad estamos hablando con un ciber-ladrón que se hace pasar por el nuestro banco.

Como cualquier protocolo de seguridad pueden existir muchos interesados en romperlo: los ciber-ladrones pueden estar interesados en ver nuestras claves o nuestras transacciones bancarias, un gobierno poco democrático podría querer leer las comunicaciones de los disidentes en Facebook (que ofrece la posibilidad de conectar mediante SSL), un servicio de inteligencia puede necesitar comprometer a un usuario de una VPN SSL corporativa, mientras que las fuerzas y cuerpos de seguridad de los estados pueden necesitar hacer lo equivalente con un webmail SSL utilizado por terroristas o delincuentes organizados.

A lo largo de los últimos años se han ido publicando algunas posibles vulnerabilidades en el uso de SSL, desde la posibilidad de ataque criptográfico si se emplean algoritmos débiles (como el caso de las colisiones MD5) al engaño a los usuarios simplemente eliminado SSL de la ecuación (sslstrip).

Existe un tipo de ataque particularmente eficaz y que estaría en principio solo al alcance de los servicios de inteligencia, policía, etc. lo que se llamaría nivel gubernamental. Se trata de la posibilidad de forzar a las autoridades de certificación a emitir certificados “falsos”, aunque perfectamente validos, que permitan interceptar las comunicaciones en las que sean usados.

En el núcleo de la funcionalidad de autenticación de SSL, está el uso de certificados, esto es la llave pública está firmada digitalmente por un tercero que garantiza la identidad del propietario de la llave. Los encargados de firmar los certificados son las autoridades de certificación, CA, una entidad de confianza, normalmente una empresa responsable de emitir y revocar los certificados digitales. Los navegadores solo aceptan como confiables los certificados que provienen de CA que aparecen en su lista de entidades reconocidas. Un certificado que está firmado por una entidad no reconocida produce un error en el navegador que alerta al usuario, lo que impide teóricamente la suplantación. El problema es que dependiendo del navegador que usemos la cantidad de CA aceptadas se eleva a más de 200, y están repartidas por todo el mundo.

Pongamos como ejemplo a Facebook, como muestra la captura actualmente el su certificado está garantizado por Digicert, una empresa con sede en Utah, EEUU. Pero nada impide que por ejemplo E-TUGRA una CA ubicada en Ankara, Turquía emitir un certificado que sería igual de valido y aceptado por los navegadores.

Si un servicio de inteligencia o fuerza policial de cualquiera de las decenas de países que albergan una CA se ve en la necesidad de capturar una comunicación basada en SSL tendría la opción de obtener un certificado emitido a nombre de la web que desean espiar, ya fuera mediante orden judicial, cooperación voluntaria, etc. Posteriormente solo tendrían que desviar el tráfico de los usuarios que accedieran al web objetivo y suplantarla mediante un ataque man-in-the-middle.

En cuando a la efectividad de esta técnica se puede considerar como muy alta, al fin y al cabo muy pocas personas realizan comprobaciones de seguridad en el uso de SSL más allá de verificar la presencia del famoso icono del candado o de revisar las alertas del navegador si es que este llega a presentar alguna, lo que no ocurre en este tipo de ataques. Porque por ejemplo ¿cuándo fue la última vez que comprobaste que el certificado de Gmail estaba emitido por Thawte y no por el CNNIC (China Internet Network Information Center)?

Hasta abril de 2010 un escenario como este se consideraba una vulnerabilidad teórica, porque no se tenía conocimiento de que pudiera estar empleándose en el mundo real. Fue ese mes cuando Christopher Soghoian y Sid Stammy publicaron un paper sobre el tema en el que además de describir la técnica adjuntaban un folleto de un pequeño fabricante de hardware en EEUU que estaría vendiendo una gama de dispositivos específicamente diseñados para realizar este tipo de interceptación de SSL.

Vamos a centrarnos en el dispositivo en cuestión, se trata de la serie 5 de la empresa Packet Forensics , una “solución de interceptación llave en mano” para la captura de trafico Web, VoIP, etc. que “utilizando la técnica man-in-the-middle intercepta TLS y SSL”. El aparato se oferta al mercado de fuerzas de seguridad y de inteligencia de EEUU y también del extranjero. Para usar este producto en el escenario de captura de SSL el usuario tiene la posibilidad de importar una copia del certificado obtenida legítimamente, por ejemplo mediante orden judicial, o bien cargar un certificado “de apariencia similar” como sería el caso de un falso certificado emitido por una CA confiable.

Según el folleto de Packet Forensics : "Los dispositivos están diseñados para ser insertados y retirados de las redes de los ISP sin causar ninguna interrupción perceptible”. Una vez instalado el dispositivo envía el tráfico interceptado por medio de un canal cifrado hasta sus controladores. Llama especialmente la atención que el folleto se considere al aparato tan económico que puede ser desechable, y que explica que esto supone “una reducción de riesgo para el personal”, el personal que lo instala se entiende, lo que vendría a sugerir un posible uso en operaciones clandestinas.

Y con esto terminamos por hoy, si el tema os ha parecido interesante no podéis perderos nuestra próxima entrada: “Rompiendo SSL a lo pobre”. Os explicaremos como aprovechar un fallo de configuración relativamente común para descifrar comunicaciones SSL previamente interceptadas. Se trata de una técnica sencilla al alcance de cualquiera, y lo mejor, ni siquiera es necesaria la licencia doble-cero del MI6.

Bibliografía

Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL (Christopher Soghoian and Sid Stammy)

Stuxnet, la dimensión geopolítica.

Casi siete meses después de su descubrimiento Stuxnet continua dando de qué hablar, pocos días atrás Symantec presentaba una versión actualizada de su análisis de este malware, mientras que en enero de este año el New York Times publica una información que vendría a confirmar que Israel habría sido el responsable de su creación. Sin embargo hasta el momento la mayoría de análisis sobre Stuxnet se han basado principalmente en sus características técnicas y poco sobre sus implicaciones políticas y estratégicas.

Por si acaso el lector ha pasado el último medio año aislado en una cueva de Waziristan, Pakistan, y no sabe de qué estamos hablando vamos a hacer un pequeño repaso a la historia de Stuxnet.

Stuxnet es un gusano informático que afecta a equipos Windows, fue inicialmente descubierto en junio de 2010 por VirusBlokAda, una empresa de seguridad radicada en Bielorrusia. Al principio no se le dio mucha importancia, pero conforme los investigadores de las casas de antivirus fueron estudiando sus características se dieron cuenta que se enfrentaban al malware más sofisticado nunca visto. Stuxnet se propaga usando dispositivos USB y vulnerabilidades de red hasta aquí todo normal, sin embargo para lograr sus propósitos usa hasta cuatro vulnerabilidades tipo 0-day, desconocidas previamente, un malware que use solo una ya de por si es destacable. Además para ocultarse ejecuta un rootkit a nivel de kernel firmado con certificados robados a los fabricantes de hardware JMicron y Realtek, lo que implica que previamente tuvo que realizarse un sofisticado ataque a estas empresas para sustraer dicho material criptográfico.

Lo más sorprendente vino después cuando se comprobó que Stuxnet atacaba software de control industrial Siemens WinCC, e inyecta código malicioso en un PLC , y además en una combinación exacta de dispositivos PLC y configuración que coincide con la que usarían las centrifugadoras empleadas por Iran en el enriquecimiento de uranio. Sobre dichos dispositivos realizaba cambios alterando la frecuencia de funcionamiento con el objetivo de causar daños a las citadas centrifugadoras. Entonces todas las miradas apuntaron a Israel como posible autor de la primera ciber-arma, una diseñada para atacar el programa atómico iraní.

Ahora bien para entender correctamente el cambio que supone stuxnet en cuanto al futuro de operaciones militares tenemos que asimilar las diferencias, ventajas y desventajas frente a operaciones militares que tuvieran el mismo objetivo. Para ello asumiremos la opinión más extendida respecto a stuxnet y a su origen israelí.

Iran actualmente mantiene un programa de energía atómica que afirma tiene fines únicamente civiles pero que dentro de la comunidad internacional es visto con recelo. Llama la atención que un país con abundantes reservas de petróleo necesite contar con energía atómica, y además que se empeñe en obtener una independencia completa fabricando ellos mismos el combustible nuclear.

Para obtener este combustible es necesario separar el Uranio 235 el isotopo fisible, del mucho más abundante Uranio 238, para esta tarea se pueden usar entre otros sistemas el uso del centrifugado Zippe. El hecho de que la única diferencia entre el uranio de uso civil , y el de nivel de armamento sea el grado de enriquecimiento, junto con el secretismo y la obstaculización de las tareas de control de la OIEA es lo que despierta las mayores sospechas.

Israel , un país con armas nucleares, históricamente se ha posicionado en contra de la proliferación de este tipo de armamento entre el resto de países de la región, considerando que amenaza su propia existencia como país. Por ello ha hecho todo lo que ha estado en su mano para impedir este desarrollo.

Así el día 7 de junio de 1981, Israel lanzo la Operación Opera, un ataque aéreo preventivo por sorpresa contra un reactor nuclear en construcción situado a 17 kilómetros al sureste de Bagdad, capital de Irak. Un grupo de F-16 escoltados por F-15 que recorrieron 1.110 km en su viaje de ida consiguieron dañar seriamente Osirak, el reactor de tecnología francesa que estaba próximo a ser completado. Aunque la operación fue un éxito militar, sin sufrir ninguna baja por parte israelí, fue duramente criticado y las Naciones Unidas aprobaron la Resolución 487 que condenaba enérgicamente el ataque, alegando que era una clara violación de la Carta de las Naciones Unidas y de las normas de conducta internacional, e instó a Israel a abstenerse de tales ataques en el futuro.

El 6 de septiembre de 2007 la Operación Opera tuvo su reedición en forma de la Operación Orchad, de nuevo un ataque aéreo por sorpresa destruía una instalación nuclear, en este caso en el interior de Siria. Una vez más fue un éxito militar absoluto, penetrando y saliendo del espacio aéreo Sirio con total impunidad.

Estas operaciones se unen a otros ataques aéreos de larga distancia realizados por la fuerza aérea israelí, como el bombardeo de la sede de la OLP en Túnez en 1985 (que produjo de nuevo una resolución de condena de la ONU) o los ataques en Sudan en 2009.

A la vista de este historial, y teniendo en cuenta que la fuerza aérea actualmente dispone de modernos medios como los caza-bombarderos F-16I , F-15I y la imprescindible capacidad de re-abastecimiento aéreo Israel está sin duda en capacidad de lanzar un ataque similar contra las instalaciones iraníes de Natanz, Busher, etc. Ahora bien existen varios inconvenientes que podrían afectar a una operación de este tipo.

La ruta de vuelo hasta Iran es mucho más larga que en cualquier operación anterior, y supondría el sobrevuelo de naciones neutrales. Estos sobrevuelos podrían traer importantes tiranteces diplomáticas con dichos países. Si estos países autorizan el paso de los aviones quedarían ante la opinión internacional y especialmente del mundo árabe como aliados de la agresión de Israel. Mientras que si el sobrevuelo no es autorizado supondría quejas se estos países en el mejor de los casos, en el peor sus fuerzas militares podrían interferir la operación o alertar a Iran del ataque inminente.

Irán obviamente ha aprendido de la experiencias de Iraq y Siria, sus instalaciones de enriquecimiento se encuentran bajo tierra, lo que es una dificultad para la operación ya que la fuerza aerea israelí debería usar bombas tipo bunker-buster y lanzarlas con total precisión. Iran además ha intentado adquirir en el mercado de armas internacional sistemas avanzados de misiles antiaéreos o de construir ubicaciones alternativas de enriquecimiento.

Incluso si la operación tuviera éxito militarmente existen escenarios en los que políticamente podría tener un efecto demoledor sobre la opinión pública israelí. Por ejemplo simplemente con que uno de los aviones atacantes fuera derribado o sufriera problemas técnicos y su piloto fuera capturado por los Iraníes, lo usarían como elemento propagandístico, en forma similar a los casos ocurridos en la guerra fría con pilotos derribados. Israel tampoco debería descartar un ataque de represalia, que podría venir de Hezbollah, el grupo libanes aliado de Irán y que cuenta con una abundante cantidad de cohetes y misiles de corto y medio alcance capaces de llegar a Israel.

En resumen, la operación parece por tanto factible militarmente y ofrecería grandes beneficios en términos de retrasar el desarrollo por parte de Irán de armas nucleares. Pero este beneficio puede ser que no valga la pena considerando el riesgo operativo y especialmente el coste politico.

Si atendemos en entonces a las noticias de que Stuxnet habría provocado daños en las centrifugadoras, como los propios iraníes han reconocido, es cuando comprendemos la verdadera dimensión de una ciber-arma. Esta puede utilizarse sin arriesgar a personal propio, utilizarse de una forma limpia y sin daños colaterales importantes, y en definitiva una relación riesgo/beneficio que supera cualquier operación militar clásica. (Entre los pocos que han desarrollado esta dimensión de la ciberguerra esta Ruben Santamarta en su brillante intervención en el 3rd Security Blogger Summit 2011)

Según el estudio de Symantec la creación de Stuxnet habría llevado seis meses para un equipo de unas cinco personas. Estamos hablando por tanto de unos costes bastante contenidos para los medios disponibles por un estado, y muy posiblemente únicamente el gasto de combustible para los aviones en el caso de un ataque ya supera con creces el dispendio realizado en el desarrollo de Stuxnet.

Otra ventaja de una ciber-arma es que puede alcanzar objetivos que son invulnerables por otros medios. Supongamos por ejemplo que Iran contara con instalaciones secretas que fueran replicas de la planta de Natanz y que no hubieran sido detectadas por la inteligencia Israeli, se trata de un escenario improbable pero no imposible. Pues incluso en ese caso Stuxnet con total posibilidad hubiera conseguido llegar a las mismas y afectarlas.

Por último el uso de las ciber-armas no limita el empleo simultáneo de tácticas mas convencionales, es de suponer que Israel no ha puesto todas sus opciones en Stuxnet, como demostrarían los diversos atentados con bomba en los que han muerto destacadas personalidades del programa nuclear Irani.

La conclusión por tanto es que en un futuro posiblemente asistamos al empleo de ciberarmas como alternativa a las operaciones militares clásicas, ya que políticamente y operativamente apenas implican riesgos, mientras que los efectos incluso siendo inferiores a los de una operación militar convencional se pueden lograr a unos costos relativamente reducidos.

Bibliografia recomendada

Osirak Redux? Assessing Israeli Capabilities to Destroy Iranian Nuclear Facilities

Symantec W32.Stuxnet Dossier Febrero 2011

Y especialmente importante en cuanto demuestra que nuestras fuerzas armadas no han pasado por alto la importancia de Stuxnet, tenemos este articulo del Coronel Ingenieros D. Gonzalo Pestaña.

Memorial de Ingenieros 85

Como debería de ser un Tiger Team

Aficionado un servidor a las películas de robos "bien planeados", estilo Ocean Eleven, Heat o Ronin, donde existe un grupo multidisciplinar pero donde todos saben de todo aunque cada uno destaca en alguna tarea específica, siempre me ha ilusionado aplicar esa filosofía, lo reconozco algo peliculera pero no sin sentido, a un Tiger Team.

Para que no haya confusiones, como Tiger Team no me refiero a un equipo de auditoría de seguridad, estos equipos tienen objetivos diferentes, en una auditoría buscas todos los fallos de un sistema, normalmente corporativo, para documentarlos, no siempre se explotan estos fallos para conseguir acceso. Un Tiger Team es diferente, el objetivo es conseguir 'la bandera', esto puede entenderse como simplemente entrar en un sistema y mantener acceso, conseguir datos protegidos, conseguir una denegación de servicio y un largo etc. Para esto, además generalmente se tienen fuertes obstáculos y exigencias, como puede ser la falta de información, la necesidad de velocidad, o la necesidad de pasar desapercibidos. 

A mi entender un buen equipo deberían de ser al menos cuatro personas, con los roles que ahora describiré. También, expongo mi idea sobre qué recursos necesitarán a priori y que contactos externos pueden ser requeridos:

El/La geek

Esta persona debería de tener unos muy buenos conocimientos generales de programación, debe de ser capaz desde hacer un troyano simple o modificar uno complejo de Windows/Linux/MacOSX como tener un mínimo de experiencia en JAVA, JSP, PHP, ASP, C, RUBY,BASH SHELL y PERL. Esta experiencia debe de ser la suficiente como para con un libro hacer lo que tenga que hacer rápidamente, los lenguajes que he puesto no son al azar, estos le permitirán poner backdoors en casi cualquier sistema.

El rol del programador también incluiría el programar/adaptar los exploits necesarios, por esto también se le requiere un conocimiento profundo sobre la estructura interna de MS Windows. Personalmente creo la estructura y funcionamiento a bajo nivel de los sistemas operativos *nix incluido MacOSX son más fáciles de aprender en un momento de necesidad. 

También a mi manera de verlo, esta persona será la que de inicio tendría más trabajo, pero con el paso del tiempo y de los "casos" debería de tener una biblioteca de código y unos conocimientos adquiridos bastantes fuertes que le permita hacer su trabajo de forma más veloz y llevadera.

Una persona de protocolo

Esta es una persona que debe de manejarse bien entre diferentes protocolos, desde una capa 2 hasta la más alta, y ¡ojo! esto lo digo porque no me refiero solo a  protocolos IP sino también a otros como puede ser X.25, DVB, Bluetooth, SSL,... lo dicho, todas las capas. Y como es imposible saberse todos los protocolos, debe de tener una importante capacidad de análisis para poder investigar capturas de tráfico de protocolos desconocidos y también de leer con soltura los diferentes estándares como RFCs, ETSI, IEEE (de verdad, algunos son un infierno).

Debe de ser capaz desde hacer hijackings, spoofings y sniffings hasta configurar en elementos de red una backroute. También ha de ser capaz de implementar los ataques, que han diseñado sus compañeros, usando diferentes técnicas de evasión de IDS. 

Esta persona debe de trabajar estrechamente junto con el geek.

Cables

Aquí entramos en el más bajo nivel. ¡Qué bien nos vendría alguien que nos hiciera un arduino que esnifara un teclado por HW! ¡Qué bien estaría una persona que saque el firmware de un AP y le pusiera una backdoor programándola en ensamblador de ARM! Y si esta persona extrae los datos de cualquier memoria flash de cualquier dispositivo ¡tope! XD. Puede tener que troyanizar una impresora o fotocopiadora....

Le será necesario conocimientos de ensamblador x86, MIPS y ARM, así como el manejo de herramientas de desensamblado y debugging, cross compiling y manejo ágil del soldador.

El/La guap@

Una persona que se gane a la gente fácilmente es esencial en este campo (ingeniería social), existen diferentes formas de hacer esto, por teléfono, con un email correctamente escrito, con una web simulando ser una empresa... Esto incluye incluso hacer de comunity manager, creando falsos perfiles de diferentes profesionales y empresas que pueden ser necesarias en un futuro (Linkedin, Wikipedia, facebook, tuenti, twitter...). 

 ( La comunidad de Murcia ya hizo esto es el caso de Vladimir Karabatic para engañar a la prensa [link] )

  

He expresado las tareas un poco diferenciadas, pues luego hay otras tareas comunes, como vigilancias o buscar nuevas vulnerabilidades, estas serán una de las armas más importantes. Lo he dicho muchas veces, y no me cansaré, en este mundo quien tiene un 0 day para algún tipo de tecnología de uso común (IE, Firefox, pdf, ms office,...) tiene un puto tomahawk.

También ha de quedar claro, que estos son, a mi ver, los roles principales, pero de ningún modo los únicos. Soporte externo es esencial, desarrollo de plataformas para la gestión de información, empresas y organizaciones externas que aporte información sobre nuevas vulnerabilidades (por ejemplo CERTs). Aparte  de contactos técnicos para resolver posibles dudas. El evidente OSINT es esencial (OSINT), y el usar sistemas online para crackear cifrados. 

Las necesidades técnicas también son fuertes, debemos tener nuestras propias rainbowtables NTLM y A5/1, esto es mucho espacio de disco duro. Distintas maquinas de distintas arquitecturas con diferentes sistemas operativos que no son inicialmente virtualizables es lo ideal. Imaginemos que se consigue la intrusión en un sistemas antiguo como puede ser un TRU64, este por defecto no lleva compilador de C, ¿como conseguimos un binario que explote una vulnerabilidad en el mismo? Pues o conseguimos que nos dejen uno (hace unos 6/7 años te dejaban shells gratuitas en este tipo de sistemas para probarlos  con compilador ;) o tenemos un HP donde lo podemos instalar (si es que conseguimos el software)... Otro caso posible, es nuestro nuevo troyano superdelamuertestealth, funciona en WinXP SP3 y en Windows 7 32bits, pero evidentemente habrá que probarlo en Vista, Win 7 64 bits, Win XP SP2... Y como último ejemplo, puede ser una nueva supervulnerabilidad de pdf, afecta a Adobe Reader, hacemos el exploit que necesita unas direcciones de memoria muy exactas igualmente habrá que probar en todos los Windows a ver si encontramos alguna dirección de memoria común o al menos la de cada SO, y por supuesto habrá que probar si el Adobe reader de MacOS es también vulnerable... Creo que con estos ejemplos está suficientemente explicado.

Y por último movilidad, no penséis que un Tiger Team hace todos sus ataques por internet, existen otros ataques que exigen cercanía al objetivo, como por ejemplo intentar crackear su red wifi, o fingir que un vulgar ladrón ha robado un portátil. Tampoco tenéis que pensar que los ataques son solo a ordenadores, se pueden intentar ataques a smartphones tanto de forma remota como cercana bluetooth, aplicaciones troyanas, ingeniería social e incluso sustrayéndolo por breve espacio de tiempo. 

Un posible escenario de actuación de un Tiger Team: Egipto hace 2 semanas. Una organización quiere influenciar en los recientes acontecimientos en Egipto, y para eso manda su Tiger Team allí. El/la guap@ y el/la geek se encargan de hacer un perfil en Internet de un estudiante de ciencias políticas, por ejemplo de la Universidad de Marruecos, pero de origen Egipcio. Este, impresionado por el movimiento se ha vuelto a su país, además es un activo usuario de twitter y actualiza asiduamente su Facebook. Se agrega a todos los grupos de esta red social y publica asiduamente (el texto no lo redacta nuestro TT sino unos especialistas en mundo árabe y en Egipto concretamente), además con el hastag #Egypt también hace gran cantidad de comentarios, dando importante información de los acontecimientos.  Cuando Internet es cortada, nuestra persona de protocolo y cables, montan varias conexiónes a Internet por satélite con el Eutelsat W3A que tiene cobertura en Egipto, configuran varias lineas de modem locales y puntos wifi en los principales sitios. Se extiende el rumor de que existen en ciertos puntos wifis por los que salir a Internet, se asegura además, que estos rumores llegan a las principales figuras del movimiento (por ejemplo el famoso directivo de google).  Se configura en estas redes preferencia de tráfico a facebook y twitter, también al tráfico de correo (enviar y recibir).  ¿Que le permite esto hacer al TT?  1) Tener un personaje activo en las redes sociales que tanto han influido.  2) Dando Internet proveemos accesibilidad para que la gente lea lo que este personaje 'aporte' al movimiento.   3) Por si acaso no consiguen una voz importante, podemos monitorizar las conexiones de Internet que hemos instalado en sitios estratégicos. Así un analista puede extraer inteligencia de los que por las mismas se dice. Tanto de un bando como de otro.  4) Si consigue que gente relevante use sus redes, posiblemente sean capaces de conseguir acceso a sus cuentas, controlándolas y pudiendo secuestrarlas si lo estiman necesario. Ciertos aspectos a tener en cuenta: ¿Enviar gente a una zona de conflicto? Bueno, he considerado Egipto ya que ha sido una revolución mayoritariamente pacífica, excepto algunos tristes altercados. En ningún momento se ha dado la impresión de golpe de estado o guerra civil. ¿Existe riesgo de que apresen  al Tiger Team? En este caso, al contrario que en El Aaiún, no han existido importantes restricciones al movimiento. El equipo puede dejar todo preparado y alejarse de las zonas para controlar el tráfico remotamente. Si acaso, el proceso de distribuir el rumor de donde se provee de  internet entre los diferentes grupos es lo más peligroso. ¿Por qué Eutelsat W3A y no Inmarsat? Se me ocurren varias razones, como puede ser no es muy sospechoso una parabólica apuntando al cielo, el precio y la velocidad, el teléfono de Inmarsat es bastante más pequeño y pasa desapercibido pero el precio es bastante más alto y la velocidad es menor. Pensad que esto lo puede hacer cualquiera, desde una empresa con intereses, al gobierno egipcio o uno extranjero con diferentes objetivos.

En resumen, un Tiger Team es a mi ver un pequeño grupo con recursos propios y externos, cuya función va más lejos que el meramente "entrar en ordenadores". Dado el pequeño tamaño de este grupo, se pueden tener varios de estos, los cuales compartirán algunos recursos e información.