Feliz 2015

Esta es la última entrada del año 2014 que ha estado lleno de altibajos, carreras, emociones y estrés, así como también de tranquilidad, descanso y relax. Son 365 días que dan para mucho, aunque para mi, siempre se me hace corto y quiero más y más. Voy a intentar destacar y repasar lo sucedido este año 2014 para evaluarlo y así tratar de mejorar en el 2015.

Soy Ingeniero Informático pero desde que nací llevo de serie un extra, y es que soy persona, es inevitable y aunque muchos puedan pensar que los Informáticos sólo entendemos de ceros y unos, también tenemos que relacionarnos con las personas, y eso me encanta. Para un Ingeniero la parte técnica es importante, pero más importante aún son las relaciones personales, saber escuchar, hacerse entender, compartir, trabajar en equipo y realizar críticas constructivas y razonadas es algo que no se enseña en la carrera y que uno lo va aprendiendo con el paso de los años. Por eso, procurar proporcionar confianza, no fallar y defraudar a nadie, ser confiable y estar disponible siempre que nos necesiten es muy importante a nivel personal y profesional para tener calidad de vida, así como también para proporcionar calidad a los proyectos profesionales. Mi deseo por seguir creciendo como persona me llevó este verano a Turquía para trabajar como voluntario en un campo de trabajo, esto hizo que creciese personalmente al trabajar codo con codo con un equipo de personas compuesto por más de cinco nacionalidades distintas, cada uno con sus creencias, virtudes y defectos.

A nivel formativo en este año 2014 he obtenido la certificación CISA, que valida mis aptitudes como Auditor de Sistemas de Información, lo cual me llevó a presentarme al primer Reto ISACA para jóvenes profesionales, logrando un áccesit con la propuesta ¿estamos vendidos? desde donde intenté transmitir y reflejar la dependencia tecnológica que tiene actualmente España para proteger sus infraestructuras. En paralelo he continuado mis estudios con el idioma Inglés, consiguiendo el certificado B2, estando actualmente en el primer curso del nivel C1. Técnicamente me he re-certificado en la versión 5 de FCNSA que valida mis conocimientos para la instalación, mantenimiento y configuración de equipos de seguridad perimetral del fabricante Fortinet, así como también he recibido un curso de gestión de proyectos orientado a la certificación CAPM a través de Feval. Desde esta misma institución he tenido la oportunidad de impartir dos cursos de redes orientados a la certificación CCNA de Cisco, concretamente un curso de Introducción a Redes y otro de Fundamentos de Routing y Switching. Además a principios de año impartí otro curso de balanceadores de carga del fabricante F5. Mientras tanto, sigo aprendiendo nuevos conceptos, técnicas y tecnologías haciendo Webinars online, así como también leyendo libros como por ejemplo el último sobre la primera ciberarma digital de Kim Zetter.

A nivel profesional comencé el año en un proyecto de asesoramiento, instalación, configuración y soporte de balanceadores de carga Radware. Este año he vuelto a participar en un proyecto de reconfiguración de rutas BGP para la Red Científico-Tecnológica de Extremadura, instalando además un servidor de monitorización fuera de banda para medir la disponibilidad y controlar los recursos utilizados, también he tenido la oportunidad de colaborar en pruebas de continuidad para una compañía privada que consistía en desacoplar Peers BGP de su sistema autónomo. Además he intervenido en un proyecto de instalación y mantenimiento de una red inalámbrica para ofrecer servicios de Internet a ciudadanos en espacios públicos, así como en otros proyectos de instalación, sustitución, configuración y mantenimiento de sistemas de seguridad perimetrales y antispam. No todos los proyectos en los que he participado han sido de seguridad y redes, sino también de sistemas y almacenamiento, por ejemplo he participado en un proyecto de puesta en marcha de una plataforma de Cloud Computing basada en Open Nebula con equipamiento HP y Cisco, además de haber instalado y configurado cabinas de almacenamiento Netapp. En paralelo he ayudado a prestar los servicios que Ariadnex proporciona desde Ariolo Cloud Services, instalación y mantenimiento de sondas y sistemas SIEM, elaboración de auditorías de seguridad y redes, mantenimiento de las certificaciones ISO 27001 e ISO 20000, además de contribuir en la redacción de ofertas técnicas.

Como objetivos para el 2015 voy a seguir formándome en materia de seguridad y redes, presentándome a la certificación FCNSP de Fortinet, también tengo pensado comenzar a estudiar la certificación de seguridad CISSP, así como continuar perfeccionando el idioma Inglés, y sobre todo espero seguir creciendo personal y profesionalmente conociendo más y mejor a las personas y participando en proyectos ambiciosos que supongan retos profesionales. Nada más me queda deciros …

Felices Fiestas y Próspero Año Nuevo a todos.

Stuxnet: En busca de exploits 0-days

El origen de la misteriosa bomba de 500 KB aún está por desvelar, pero esta ciberarma digital nos ha mostrado, enseñado y aterrorizado que utilizando una serie de exploits 0-days se puede controlar una central nuclear y que en manos de algún desaprensivo puede llegar a provocar una catástrofe. Tras analizar el funcionamiento de Stuxnet vamos a ver que los atacantes no escatimaron en el uso de exploits para llegar a su destino, la central nuclear de Natanz.

La organización encargada de desarrollar el malware utilizó cuatro exploits 0-days para hacerse con el control del equipo que gestiona el sistema Siemens SCADA. Concretamente aprovecharon las siguientes vulnerabilidades:

1. Vulnerabilidad en los enlaces de acceso directo de Windows, o archivos .LNK, capaces de ejecutar archivos .DLL maliciosos.
2. Vulnerabilidad en la cola de impresión de Windows para compartir impresoras.
3. Vulnerabilidad en el planificador de tareas de Windows que permitía escalar privilegios.
4. Vulnerabilidad en un archivo del teclado de Windows que permitía escalar privilegios.

Encontrar vulnerabilidades y desarrollar sus exploits para infectar el sistema operativo de la víctima saltándose los permisos de administrador sin que el usuario se percate es una tarea ardua y difícil que no está al alcance de cualquiera. Sin embargo tras la publicación de Stuxnet, Microsoft detectó que la vulnerabilidad que aprovechaba los accesos directos .LNK ya había sido utilizada antes por el troyano Zlob, así como también se conocía la vulnerabilidad que aprovechaba la cola de impresión, ya que ésta había sido publicada en el 2009 por una revista de seguridad polaca. No obstante, Microsoft publicó sus parches tras el descubrimiento de Stuxnet, mientras tanto, estaban ahí fuera para el uso y disfrute de los malos.

En la primera versión de Stuxnet del 2009 el malware utilizaba la característica de Autorun para propagarse, es decir, el malware se ejecutaba automáticamente cuando se insertaba una memoria USB infectada. Posteriormente en la versión del 2010, los atacantes habían sustituido el Autorun por la vulnerabilidad de los accesos directos .LNK, además de firmar el malware con el certificado de la compañía RealTek. Este cambio en el método de propagación provocó que el número de máquinas infectadas ascendiese a 100000, de esta manera los atacantes llegarían antes a su objetivo.

Stuxnet es muy potente por la cantidad de exploits y métodos de propagación que dispone para pasar desapercibido. De los 8 métodos de propagación podemos destacar la manera de infectar archivos de proyecto del software Step 7 de Siemens, mediante la infección del fichero de proyecto, se puede infectar la base de datos de backend que comparten todos los programadores que trabajen en el proyecto, de esta manera al estar la base de datos infectada, se pueden infectar todos los trabajadores del proyecto.

Además de derrochar en exploits y utilizar cuantiosos métodos de propagación, Stuxnet era capaz de mantenerse actualizado utilizando un componente P2P que configuraba a las máquinas en modo cliente/servidor, así como también registraba en cada máquina mediante un log la IP, nombre de dominio y timestamp de los equipos infectados. Log que ayudó a los investigadores a concluir que el foco de la infección se encontraba en Irán.

En definitiva, estamos ante un despilfarro de exploits, métodos de propagación y técnicas de actualización muy bien pensadas y probadas para conseguir sabotear las centrifugadoras nucleares de Irán.

¿Quién está detrás de todo esto? Parece ser que puede ser un problema de estados.

Un saludo amigos!

Stuxnet: Analizando su funcionamiento

La primera ciberarma digital que llegó a infectar a más de 300.000 equipos en más de 100 países distintos era una bomba de 500 KB desarrollada para ralentizar el enriquecimiento de uranio en la central nuclear de Natanz ubicada en Irán. Continuando con la serie de capítulos del libro Countdown to Zero Day de Kim Zetter veremos realmente cómo funcionaba esta obra de ingeniería.

Como cualquier otro malware, la primera ciberarma digital se puede dividir en dos partes. Por un lado, el payload que se encarga de propagar el virus por diferentes equipos, y por otro lado el payload que se encarga de robar información o hacer cualquier otra cosa, en este caso atacar sistemas PLC de Siemens.

Stuxnet, como así se llama la ciberarma, lo primero que hacía era comprobar si la máquina donde se iba a desplegar era de 32 o 64 bits, ya que este malware tan solo funcionaba sobre máquinas Windows de 32 bits. Después, comprobaba si la máquina ya estaba infectada, si era así, comprobaba si existía alguna actualización de Stuxnet para descargarse la última versión disponible. En cambio, si la máquina aún no estaba infectada procedía a determinar la mejor manera para infectarla.

Para infectar la máquina se pone en marcha un rootkit que esconde los archivos de Stuxnet al sistema operativo, de esta manera los nombres de los archivos de Stuxnet no podían ser vistos por los motores de antivirus y no eran analizados. Si un escáner de malware intentaba leer el contenido de la memoria USB que estaba infectando la máquina, el rootkit interceptaba los comandos y devolvía una lista modificada de los archivos que contenía la memoria USB, obviamente eliminando de la lista los nombres de los ficheros de Stuxnet para que no fuesen analizados. Sin embargo, Stuxnet no podía hacer un bypass de todos los motores de antivirus, así que para aquellos motores que no podía controlar la infección, Stuxnet se paraba y se terminaba la infección.

A continuación, si Stuxnet decidía proceder porque podía hacer un bypass del antivirus se activaba un segundo driver con dos tareas. La primera tarea consistía en infectar cualquier otra memoria USB que estuviera conectada. La segunda, y más importante, era descifrar y cargar la biblioteca .DLL, y varios de sus componentes, en memoria. A continuación descomprimía la DLL para obtener otras DLL más pequeñas. Una vez que todas las DLL estaban en memoria, Stuxnet buscaba otras máquinas para propagarse y después se ponía en contacto con el C&C. Obviamente, como todas las DLL estaban en memoria cada vez que el equipo se reiniciaba se borraban, así que el driver en cada reinicio tenía que volver a cargar las DLL a memoria.

Posteriormente el malware hacía un inventario del software instalado en la máquina y lo enviaba al C&C, si no encontraba ningún software de Siemens ni el WinCC, Stuxnet quedaba inactivo. Si por el contrario encontraba software de Siemens, concretamente Siemens Step 7, y/o el WinCC, buscaba las PLC S7-315 y S7-417 de Siemens. Sólo esta combinación de hardware y software hacían posible descifrar y lanzar el ataque.

A continuación podemos ver las fases del ataque:

 

Además de la manera de cómo evitar los antivirus y la forma de cargar los archivos en memoria, Stuxnet monitorizaba los recursos de la máquina infectada para comprobar si la ejecución del malware sobrecargaba la máquina. Si Stuxnet utilizaba demasiada CPU o memoria podría ser detectado. Stuxnet también eliminaba los archivos temporales que no necesitaba para pasar desapercibido.

Encontrar evidencias suficientes para conocer el origen del malware es algo muy complicado a no ser que los propios desarrolladores dejen alguna "pista". Algunos desarrolladores utilizan técnicas para que sus propios equipos no se infecten con su propio malware, para ello antes de infectar un equipo el malware realiza una serie de comprobaciones para conocer si la máquina que va a infectar pertenece al desarrollador. Stuxnet parece que tenía algo parecido, antes de infectar la máquina comprobaba un registro de Windows y si dentro de ese registro se encontraba la cadena 0x19790509, la máquina no era infectada. Inmediatamente los investigadores se pusieron a investigar qué podría significar esta cadena. Una hipótesis dice que la cadena pertenece a una fecha, concretamente el 9 de Mayo de 1979, fecha que coincide con la ejecución de Habib Elghanian, un importante hombre de negocios de la comunidad judía en Irán. Tras su muerte muchos judíos migraron hacia Israel.

Otra evidencia que se encontró en el código de Stuxnet que hace pensar que Israel está detrás de su desarrollo fue que el compilador del malware dejó rastro del path donde se encontraba el proyecto. Concretamente la cadena b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb que nos indica que el nombre de usuario de la máquina es myrtus, que coincide con el nombre hebreo de la reina judía que evitó una masacre de judíos en el imperio persa.

Otra hipótesis del significado de myrtus puede significar My RTUs, haciendo referencia a Unidades de Terminal Remoto que son componentes usados para monitorizar y operar equipamiento industrial.

Sea cual sea la verdad, la especulación de quién está detrás de este sofisticado ataque está abierta para todos los investigadores.

Stuxnet: Una bomba de 500 KB

En la anterior entrada hablé sobre el descubrimiento por parte de VirusBlockAda de la primera ciberarma digital, Stuxnet, que utiliza certificados digitales robados y aprovecha una vulnerabilidad de los ficheros .LNK en los sistemas operativos Windows. Todo ello extraído de la historia que cuenta el libro Countdown to Zero Day de Kim Zetter.

Aunque normalmente un malware ocupa entre 10 y 15 KB de memoria, Stuxnet es un arma que está muy por encima de la media con 500 KB, que tras descomprimirlo ocupa 1,18 MB. Sólo el tamaño ya nos indica la potencia de esta ciberarma por la cantidad de módulos y configuraciones que tienen cabida en algo más de 1 MB de código.

Si analizamos tan solo las primeras líneas del código del malware nos daremos cuenta enseguida que las técnicas empleadas van más allá de lo normal, utiliza técnicas de ocultación y propagación que ningún otro malware jamás ha utilizado. Es un malware muy pensado y muy trabajado, un malware profesional que no se conforma con lo mínimo para no ser detectado.

Stuxnet es un malware preparado para ser desplegado mediante una memoria USB, está compuesto por un fichero .DLL cifrado que contiene tres docenas de ficheros .DLL dentro del .DLL principal. Además incorpora ficheros de configuración listos para realizar cambios desde el C&C. Una vez infectada la máquina, el malware no guardaba las bibliotecas DLL en disco, sino que para eludir los antivirus las guardaba directamente en memoria y era capaz de controlar la API de Windows para decirle a los antivirus que allí no había nada que “mirar”.

Una memoria USB con Stuxnet tan solo podía desplegar el malware en tres equipos distintos, es decir, una vez infectadas tres máquinas, el malware se auto-destruía. Stuxnet lo primero que hacía era realizar un inventario del software instalado en la máquina infectada, posteriormente realizaba una búsqueda de software de Siemens, si la máquina víctima no tenía software Siemens se propagaba a otra máquina y el malware se apagaba, si en cambio tenía software Siemens instalado, enviaba la lista del software instalado al servidor de C&C donde los atacantes podría comprobar si se trataba de la máquina que buscaban. Además de la lista de software instalado también enviaba el nombre de la máquina, dominio, IP interna y versión de Windows.

Según los análisis realizados por Symantec, los servidores de C&C se encontraban en los dominios mypremierfutbol.com y todaysfutbol.com, registrados con nombre y tarjetas faltas en Dinamarca y Malasia. Una vez que Symantec se hizo con el control de los dos dominios del C&C detectó unas 38000 infecciones con un ratio de crecimiento de 9000 infecciones al día, aunque al final se detectaron más de 300.000 infecciones en más de 100 países, de las 38000 infecciones detectadas inicialmente, 22000 procedían de Irán y 217 tenían software Siemens instalado, por lo que estaba claro que el origen del foco de infección procedía de Oriente Medio, precisamente de Irán.

Irán nunca ha sido el principal objetivo del malware, siempre ha tenido bajas infecciones. Sin embargo, esta ciberarma digital se saltaba las estadísticas y patrones, ya que estaba claro que Stuxnet no había sido desarrollado para robar fórmulas secretas de laboratorios farmacéuticos ni de entornos industriales, sino de infraestructuras críticas procedentes de Irán.

Tan solo nos queda plantearnos algunas preguntas, ¿se han metido las compañías de antivirus en un problema de estados? ¿han saboteado los planes de algún estado?

Stuxnet: La primera ciberarma digital

Este mes de Noviembre ha sido el lanzamiento del libro Countdown to Zero Day de Kim Zetter donde se explica desde el inicio el descubrimiento de la primera ciberarma usada para ralentizar el enriquecimiento de uranio de la central nuclear de Natanz en Irán. Stuxnet, como así lo apodó Microsoft, tenía un objetivo muy claro, sabotear el enriquecimiento de uranio para prevenir que el presidente Mahmoud Ahmadinejad construyera una bomba nuclear.

Todo comenzó en Junio del 2010, cuando una pequeña compañía de Bielorrusia llamada VirusBlockAda detectó comportamientos anómalos en un equipo de uno de sus clientes ubicado en Irán. Al parecer la máquina se reiniciaba sola, la “limpiaron” y continuaba comportándose de forma irregular. Inicialmente su antivirus no detectaba ningún tipo de malware pero tras un análisis exhaustivo realizado por los expertos de la compañía pudieron detectar un ataque zero day que afectaba a todos los equipos Windows, incluso aquellos actualizados a la última versión. Se trataba de ficheros .LNK que los sistemas operativos Windows analizan para mostrar los iconos de los ejecutables. Inmediatamente, VirusBlockAda desarrolló su propia firma para que su antivirus detectara el zero day, sin embargo esta pequeña compañía ubicada en Bielorrusia no fue tenida en cuenta por los grandes fabricantes hasta que publicaron su descubrimiento en su página web y en foros de seguridad.

Una vez que el zero day estuvo en manos de Microsoft, además de otras compañías de antivirus acostumbradas a analizar códigos complejos como Kaspersky, se detectó que el malware podía vivir perfectamente en el kernel del sistema operativo junto con los principales software de antivirus sin ser detectado. Sin embargo, el malware no podía coexistir con el antivirus desarrollado por la pequeña compañía VirusBlockAda, los equipos infectados que tenían su software antivirus producían un crash del sistema operativo, y este fue el principal motivo de su detección. Conforme se siguió en la investigación del malware, el siguiente paso fue descubrir que el driver instalado por Stuxnet estaba firmado digitalmente por la compañía Taiwanesa Realtek Semiconductor y esta fue la principal causa por el cual los equipos Windows permitían instalar el driver infectado, es decir, confiaban en el driver porque estaba firmado digitalmente por una compañía confiable.

Una vez revocado el certificado digital de Realtek y desarrollada las firmas para los antivirus, el 17 de Julio la empresa de antivirus ESET detectó una variación de Stuxnet que utilizaba otro certificado digital para compilar el malware, esta vez de otra compañía Taiwanesa llamada JMicron Technology, que casualmente sus oficinas se encuentran en el mismo edificio que las de Realtek. La fecha de compilación del binario tan solo era de dos días posterior a la primera publicación oficial de Stuxnet. ¿Qué pretendían los atacantes? ¿Cómo habían robado los certificados?

En cualquier caso, estamos ante un ataque muy profesional, posiblemente desarrollado por una docena de expertos en seguridad con el apoyo de algún gobierno, ya que Stuxnet no estaba preparado para robar credenciales bancarias, sino para modificar un sistema de control industrial diseñado para trabajar con PLC de Siemens.

Animo a todos aquellos apasionados por la seguridad a leer este interesante libro, que iré recapitulando en futuras entradas.

Un saludo amigos!

¿Auditoría o Consultoría?

Suele ser habitual confundir, mezclar, equivocar estos dos términos sino estás en el mundillo de alguna de las dos. Desde que obtuve la certificación CISA para realizar auditorías de sistemas de información me he dado cuenta que a veces los clientes quieren contratar un servicio cuando realmente quieren otro. Es decir, por ejemplo contratan una auditoría de red y realmente quieren que les digas cómo dimensionar la red para incorporar nuevos servicios o contratan un curso de formación y realmente quieren que analices su arquitectura de red y le propongas puntos de mejora. Por tanto, voy a intentar definir estos dos conceptos para que quede claro cuando utilizar uno u otro:

Auditoría: Contrataremos una auditoría para que nos analicen nuestro sistema, ya sea un sistema de gestión para revisar procesos y procedimientos, analizar la red para detectar cuellos de botella, consumos de ancho de banda o flujos de conexión, o revisar la seguridad de nuestra TI para que nos digan lo bien o mal que lo estamos haciendo contrastando los resultados con las mejores prácticas del sector. Es decir, contrataremos un auditoría siempre para mirar hacia atrás en el tiempo, qué pasó y por qué.

Consultoría: Contrataremos una consultoría para obtener recomendaciones para implantar un nuevo sistema, ya sea para implantar nuevos procesos y procedimientos, instalar un nuevo sistema de seguridad perimetral o interconectar varias sedes para acceder a recursos internos. Es decir, una consultora nos puede ayudar a elegir la tecnología que mejor se adapte a nuestra organización, les contaremos qué problema queremos resolver y ellos buscarán una solución. Siempre contrataremos una consultoría para mirar hacia adelante en el tiempo, qué problema queremos resolver y cómo lo podemos hacer.

Además de auditorías y consultorías también tenemos análisis forenses y planes de formación que no debemos confundir. Es decir, un analista forense utilizará los registros de auditoría para dar un veredicto de qué pasó, mientras que la formación se utiliza para aprender nuevos conceptos y técnicas, y no debemos confundirlo con una consultoría donde queremos explicar cómo tenemos montado nuestra plataforma para que nos den recomendaciones de mejora.

En definitiva, conceptos que una vez que los tenemos claros es fácil saber qué tipo de servicio necesitamos y qué podemos esperar de cada uno de ellos.

Como siempre, cualquier aclaración o comentario será bienvenido.

Un saludo amigos.

Gestión de dispositivos (BYOD)

Dentro de la mejora continua siempre debemos ubicar la formación continua, y por este motivo la semana pasada realicé el examen de re-certificación de Fortinet FCNSA que me ha obligado a actualizar mis conocimientos a la versión 5. Esta nueva versión está cargada de mejoras que intentan controlar la problemática que muchos administradores de redes nos encontramos hoy en día en nuestras oficinas, es decir, la gestión de dispositivos móviles o el llamado BYOD donde los usuarios conectan sus dispositivos personales a la red de la organización.

En la versión 4 ya teníamos la posibilidad de realizar políticas basadas en identidad, en esta nueva versión además tenemos la posibilidad de realizar políticas basadas en dispositivos. Para ello FortiGate utiliza varias técnicas y protocolos que nos ayudan a identificar los dispositivos que están conectados a nuestra red. A continuación veremos algunos de ellos:

DHCPv6, DHCP (Dynamic Host Configuration Protocol): Es un protocolo utilizado para que los clientes puedan obtener su configuración de red automáticamente. Sin embargo, un administrador de red también puede utilizar este protocolo para obtener el nombre del equipo cliente y el sistema operativo ejecutado, analizando las opciones 12 y 60 del protocolo DHCP, que hacen referencia a “hostname” y “dhcp-class-identifier” respectivamente.

CDP (Cisco Discovery Protocol): Protocolo propietario de Cisco que ayuda al administrador de red a disponer de un mapa de la topología implantada, ya que mediante este protocolo los dispositivos intercambian información como versión del sistema operativo, nombre de equipo, dirección IP, tipo y modelo del dispositivo, etc.

LLDP (Link Layer Discovery Protocol): Protocolo de red que trabaja en la capa 2 de enlace al igual que CDP. Pertenece al estándar 802.1ab y se encarga de descubrir la topología de red mediante mensajes LLDPDU que permite al administrador de red obtener información de los dispositivos como fabricante, versión de hardware y software, nombre del sistema, IP de gestión, etc.

SSDP (Simple Service Discovery Protocol): Es un protocolo que se utiliza para buscar dispositivos UPnP mediante solicitudes unicast o multicast al puerto 1900/udp. Mediante mensajes “M-SEARCH” y “NOTIFY” podemos conocer los servicios que proporciona un determinado dispositivo, además de su IP y sistema operativo.

Microsoft Windows Browser Service: Es una característica de Microsoft Windows que nos permite localizar recursos compartidos por equipos Windows, su comunicación se realiza mediante paquetes de broadcast y por tanto no puede traspasar a otras redes, a no ser que se disponga de un controlador de dominio. Mediante esta característica podemos obtener el nombre de los equipos y su sistema operativo.

LLTP (Link Layer Topology Discovery): Es un protocolo de enlace propietario de Microsoft incluido en los sistemas operativos Windows Vista y Windows 7 que permite mostrar una representación gráfica de la LAN a la que estamos conectados. Además de la topología de red podemos saber el nombre de los demás equipos de la red, así como también su IP y dirección MAC.

Mediante los protocolos comentados anteriormente y las técnicas de TCP Fingerprinting con equipos FortiGate podemos aplicar políticas basadas en dispositivos, así como monitorizar todos los dispositivos que se conectan a nuestra red desde una consola central como la que vemos a continuación:

 

Sabemos que la seguridad no está sólo en el firewall ni en el Sistema de Gestión de Eventos SIEM, sino que deberíamos establecer políticas y procedimientos que nos ayuden a proteger la información de nuestra organización. Sin embargo mediante funcionalidades como la gestión de dispositivos, que incorpora FortiGate, nos ayudará a mantener controlada nuestra infraestructura y sus accesos estableciendo políticas de control accesos a la red basadas en dispositivos.

Como siempre cualquier comentario, adelante!!

¿Vigilancia o espionaje?

Según la RAE vigilancia es el “cuidado y atención exacta en las cosas que están a cargo de cada uno” mientras que espionaje es una “actividad secreta encaminada a obtener información sobre un país, especialmente en lo referente a su capacidad defensiva y ofensiva”. Aunque son conceptos completamente distintos, depende de con quién hablemos hará referencia a uno u otro según le interese.

En portada de varios periódicos y en muchos medios de comunicación nos hemos encontrado, desde el verano del 2013, al exanalista de la NSA Edward Snowden anunciando las herramientas de ciberespionaje desarrolladas por la Agencia de Seguridad de EEUU. Tras su publicación, el gobierno Americano ha salido a la defensiva indicando que se trata de programas de vigilancia para preservar la seguridad de sus ciudadanos. Sin embargo, todos sabemos que aunque haya alianzas entre países existe el espionaje mutuo. Recientemente hemos podido ver que Alemania ha exigido la salida de Berlin del jefe del servicio de espionaje estadounidense debido a la captura de un agente doble que trabajaba al mismo tiempo para los servicios secretos de Alemania y para los de Estados Unidos, es decir, el agente secreto alemán vendía información a Estados Unidos.

El mundo del espionaje que desde fuera se ve emocionante y fantástico con muchos lujos al estilo de James Bond nos deja escenas como la muerte del espía Gareth Williams del MI6 encontrado muerto dentro de una bolsa de equipaje o el ex jefe de los espías de Ruanda, Patrick Karegeya, quien fue estrangulado en un hotel.

¿Para qué sirve el servicio de espionaje? Como dice Sun Tzu, para ganar la batalla antes de pelearla. Debido a la importancia que tiene obtener información exhaustiva y fidedigna se emplea muchos recursos en tareas de espionaje y una vez obtenido todos los datos podremos lanzarnos al ataque para ganar la batalla. Debido a que no hay asunto más secreto que el espionaje, el presupuesto asignado para ello y los programas de inteligencia no están al alcance de los ciudadanos. Sin embargo, en las revelaciones de Edward Snowden hemos podido ver que EEUU destinó 52,600 millones de dolares en 2013 en labores de inteligencia y lucha contra el terrorismo, desarrollando proyectos como PRISM para la vigilancia electrónica, X-Keystore para analizar todo el tráfico HTTP y donde uno de los nodos está en España, Treasure Map para dibujar el mapa de Internet en tiempo real, además de apoyar proyectos para hackear dispositivos de red como routers o switches, desarrollar el programa Bullrun para descifrar las comunicaciones, hackear los dispositivos móviles de los políticos para interceptar las comunicaciones móviles como en la cumbre G8 y G20 o incluso espiar las embajadas de la Unión Europea.

Con el avance de la tecnología los métodos de espionaje están cambiando considerablemente, hoy nos podemos encontrar a ciberespías desarrollando herramientas avanzadas para aprovechar vulnerabilidades aún desconocidas por los fabricantes y así entrar en los sistemas del enemigo para robar toda la información que sea necesaria. Algunas de estas herramientas son las siguientes:

• Stuxnet: Un objetivo bastante claro, el programa nuclear Iraní, concretamente los sistemas SCADA de la central nuclear. Los atacantes consiguieron modificar los sensores de las turbinas de la central nuclear retrasando su puesta en marcha. Como posibles sospechosos están los servicios secretos estadounidenses e israelíes.


• Flame: El objetivo era el ciber espionaje en el Medio Oriente ya que es capaz de grabar conversaciones de Skype, controlar el audio y micrófonos, realizar capturas de pantalla y de teclado e incluso controlar el bluetooth. Como posibles sospechosos están el gobierno de EEUU, China e Israel.

• Gauss: Al igual que los dos anteriores, su objetivo eran los países de Medio Oriente, y concretamente las instituciones financieras y las cuentas bancarias de sus ciudadanos. Su desarrollo es muy similar al malware Flame, por lo que los autores podrían ser los mismos que los desarrolladores de Flame.


• Duqu: Variante de Stuxnet destinada a piratear, sabotear y retrasar la capacidad de Irán para fabricar bombas nucleares, además de robar información de infraestructuras críticas, tales como centrales eléctricas, refinerías y oleoductos. Se sospecha que el gobierno de EEUU e Israel puedan estar detrás de esta ciberarma.


• Careto: Malware desarrollado para captar datos como contraseñas, archivos RDP para acceso remoto, configuraciones VPN o claves SSH. Además es capaz de grabar conversaciones de Skype, ver todo lo que tecleas, sacar pantallazos, robar archivos o incluso instalar cualquier cosa en el equipo de la víctima. Entre los autores de este malware podría estar el gobierno español.


• Madi: Campaña de Spam con un documento adjunto en formato PowerPoint dirigida a Oriente Medio y más concretamente a personas que trabajan en proyectos de infraestructuras críticas iraníes e israelíes, instituciones financieras de Israel, estudiantes de ingeniería y varias agencias gubernamentales de Oriente Medio.


• Zeus: Troyano dedicado a robar credenciales de redes sociales, correo electrónico y banca online.

Aunque algunos lo llamen vigilancia para proteger sus intereses, siempre que la actividad se realice sin consentimiento de la víctima estaremos hablando de espionaje. Como hemos podido ver, el espionaje existe y existirá ya que es la fase inicial de protección de los intereses del gobierno, la diferencia, que en la actualidad con los medios de comunicación que tenemos a nuestro alcance y las tecnologías de la información, los instrumentos para realizar el espionaje están cambiando.

¿Quieres ser espía?

Caso de estudio Anti-NSA

En el reto ISACA que tuve la oportunidad de exponer este verano comenté algunas acciones que quieren llevar a cabo países como Turquía, Venezuela y Brasil, además de otros países de la Unión Europea para evitar los casos de espionaje de la NSA. Recientemente hemos conocido, mediante las revelaciones de Edward Snowden, el proyecto Tempora que lidera el GCHQ para acceder a las comunicaciones transoceánicas que son almacenadas y posteriormente compartidas con la Agencia de Seguridad Estadounidense NSA. Esta práctica, de pinchar los cables submarinos, es el principal objetivo de los servicios secretos para espiar cualquier comunicación, ya que es por estos cables por donde viaja la mayoría de las comunicaciones entre continentes.

Uno de los proyectos que comenté y que parece seguir hacia adelante es que Brasil prepara su propio cable transoceánico para evitar a la NSA. En concreto, Brasil se unirá con Portugal mediante un cable transoceánico por el Océano Atlántico a través de un proyecto de 185 millones de dolares. ¿el reto? No utilizar tecnología fabricada en EEUU.

 

Brasil que quiere moverse hacia tecnología que le proporcione confianza ha encargado a la compañía brasileña Telebrás, la cual es proveedora de Cisco, que planifique, diseñe y ejecute el proyecto aliándose con compañías nacionales, europeas y asiáticas. Telebrás ha firmado un acuerdo con la compañía madrileña IslaLink, o lo que queda de ella, ya que el 80% de ésta ha sido comprada recientemente por un fondo de inversión nórdico. Además, Telebrás se asociará con la compañía brasileña Padtec y aún está en el aire si participarán compañías como Huawei, Alcatel o Ericcson.

Este sentimiento anti-NSA está beneficiando a las pequeñas y medianas empresas brasileñas, mientras que otras compañías como Cisco ven caer su facturación tras las revelaciones de Edward Snowden, a pesar de haber propuesto una inversión de un billon de dólares en Brasil. Los altos aranceles para importar tecnología y la aprobación de un decreto que obliga a las agencias y ministerios a utilizar solo servicios y tecnologías de empresas nacionales está fomentando aún más el desarrollo tecnológico en el país brasileño.

Elaborar estrategias y políticas para evitar el espionaje, fomentar el desarrollo tecnológico y disminuir la tasa de desempleo no es una tarea sencilla. Sin embargo, llevar a cabo iniciativas y proyectos como lo está haciendo el gobierno brasileño, aunque tenga que romper algunas alianzas con compañías estadounidenses, parece ser que puede ser la dirección adecuada para no depender exclusivamente de la tecnología fabricada en EEUU. Obviamente estas políticas tan sólo deberían afectar a servicios públicos e infraestructuras críticas para mantener la seguridad del país, mientras que cualquier otra actividad privada debería poder utilizar la tecnología que más se adapte a sus necesidades independientemente de su origen, ya que si esto no fuese así estaríamos debilitando la competitividad internacional en el desarrollo empresarial.

Un saludo amigos y deja tus comentarios!!

¿Un DDoS legal?

El fútbol es un deporte que tiene muchísimos seguidores y mueve mucho dinero en España, por eso se dice que a los españoles nos pueden subir el IVA o endurecer las condiciones laborales pero no nos pueden quitar el fútbol, si fuese así, el primer domingo sin fútbol tendríamos una guerra civil. Este fin de semana mientras que los forofos veíamos el Madrid – Barça se estaba librando una batalla, o mejor dicho una ciberguerra, entre el grupo Prisa, Mediapro y la LFP contra las webs de videostreaming que enlaza rojadirecta.com. Concretamente la empresa IPRODED ha sido la encargada de lanzar un ataque DDoS contra los servidores que retransmitían el clásico Madrid – Barça.

¿Cómo se lanza una ataque DDoS de manera legal? Pues eso mismo me pregunto yo. Si leemos la directiva marco 2005/222/JAI introducida en nuestro Código Penal a través de la Ley Orgánica 5/2010, se dice “Los principales tipos de infracciones penales cubiertos por esta decisión marco son los ataques contra los sistemas de información * tales como la piratería, los virus y los ataques por denegación del servicio.” Sin embargo todos sabemos que el fútbol mueve mucho dinero y tiene mucho poder, lo podemos ver en los fichajes astronómicos, las deudas millonarias de los clubs contra la hacienda pública y ahora por qué no … realizando ciberataques a todo aquel que les moleste.

Los españoles no somos los únicos que nos saltamos la ley, según documentos revelado por Edward Snowden una división del GCHQ llamada JTRIG lanzó una operación en 2011, con nombre Rolling Thunder, que consistía en realizar ataques de DDoS contra los chats de Anonymous, además de propagar malware para identificar a los hacktivistas. Mientras tanto, hemos podido ver que varias personas pertenecientes al grupo Anonymous o LulzSec han sido llevadas a la cárcel por participar en ataques de DDoS, por ejemplo los ataques a PayPal y MasterCard cuando estas compañías decidieron dejar de dar donaciones a WikiLeaks, ataques al FBI, CIA y GCHQ al cerrar la web de megaupload, aprobar la ley SOPA para combatir la piratería o castigar al soldado Chealse Manning por filtrar miles de documentos clasificados a WikiLeaks.

No hay información sobre qué tipo de ataques de DDoS están realizando estar organizaciones contra Anonymous y rojadirecta.com, es decir, si utilizan alguna botnet o utilizan un ataque de DDoS amplificado, lo cuál sobrepasaría la ilegalidad. O si por el contrario utilizan sus propios recursos, CPU y ancho de banda, para provocar la denegación de servicio. En cualquier caso, ellos tienen el poder y parece ser que pueden actuar como quieran.

Entrar en la legalidad o ilegalidad de estas operaciones está fuera de mi alcance debido a mis limitados conocimientos en leyes, pero supongo que al igual que pueden desalojar una plaza mediante cargas policiales en una manifestación también pueden realizar este tipo de ataques contra servicios webs y no pasará nada.

Lo que está claro que tanto en el mundo real con las cargas policiales como en el mundo virtual con los ataques de DDoS, los ciudadanos y usuarios finales ajenos a la operación estamos afectados por la inutilización de las calles durante el desalojo como la inutilización de los servicios webs y líneas de comunicaciones saturadas debido al ataque. Así que creo que la mejor elección para sacar un dinerillo extra es que a partir de ahora yo también me ofrezca a realizar ataques de DDoS al igual que el chico del siguiente vídeo:

Un saludos amigos.

Vulnerabilidad POODLE SSLv3

Esta semana toca escribir sobre la vulnerabilidad de SSLv3 llamada POODLE (Padding Oracle On Downloaded Legacy Encryption). Existe muchísima información en Internet de cómo se puede llegar a descifrar una sesión SSL utilizando la vulnerabilidad del protocolo que aprovecha la manera que el cifrado por bloques CBC es implementado dentro de SSLv3.

El protocolo de cifrado SSLv3 fue diseñado hace 18 años para proporcionar comunicaciones seguras en Internet. Aunque la mayoría de aplicaciones soportan el protocolo TLS, siendo este mucho más robusto, aún muchos servicios y navegadores soportan SSLv3.

¿Qué dispositivos son vulnerables?

Todas las aplicaciones, navegadores y servidores que soporten SSLv3.

¿Cuál es exactamente la vulnerabilidad?

La vulnerabilidad está basada principalmente en dos fallos de SSLv3:

• SSLv3 genera bytes de relleno de manera aleatoria.
• El Message Authentication Code (MAC) calculado para comprobar la integridad de cada mensaje después del cifrado no incluye estos bytes de relleno.

Por lo tanto, estos bytes de relleno pueden ser modificados mediante un ataque Man In The Middle sin ser detectado por el cliente ni el servidor.

¿Es una vulnerabilidad importante?

Aunque se necesita realizar un MITM para explotar la vulnerabilidad, sí que se considera importante por la cantidad de aplicaciones y servicios que están expuestos, ya que la mayoría de navegadores (Chrome, Firefox, IE) soportan SSLv3, además de que la mayoría de sitios web HTTPS también soportan SSLv3.

¿Debería estar preocupado?

Teniendo en cuenta que para explotar la vulnerabilidad el atacante debe encontrarse en la misma red que la víctima, la ejecución satisfactoria del ataque tiene unas necesidades muy específicas que sitúan la vulnerabilidad por detrás de otras, como por ejemplo Heartbleed.

¿Cómo puedo prevenir el ataque?

Hay dos maneras para prevenir el ataque. Es suficiente con deshabilitar el soporte de SSLv3, o los modos de CBC con SSLv3, en los servidores web y en los navegadores y aplicaciones de clientes, sin embargo esto puede presentar problemas de compatibilidad. La otra alternativa es soportar TLS_FALLBACK_SCSV. Este último mecanismo resuelve el problema de los re-intentos de conexión fallidos que puede provocar un atacante para forzar a los navegadores a utilizar SSLv3. Y por tanto también previene el downgrade de TLS 1.2 a TLS 1.1, además de que puede ayudarnos a prevenir futuros ataques.

Esta última vulnerabilidad, además de hacernos trabajar a todos los ingenieros de seguridad para mitigarla lo antes posible, parece ser que puede ser la punta del iceberg tras Heartbleed para que fabricantes de software dejen de soportar el protocolo SSLv3 y trabajen exclusivamente con TLS.

Un saludos amigos!

Checksum

El checksum y el CRC son mecanismos para detectar errores en la transmisión de datos que nos ayudan a determinar la integridad de los datos transmitidos por la red. Para ello el emisor realiza una función hash de los datos a transmitir, y el valor hash lo transmite junto con los datos, de esta manera el receptor realiza la misma operación una vez recibido los datos, y compara el valor hash recibido con el valor hash calculado, si los hash son iguales, los datos no han sufrido ninguna alteración en el camino, en cambio si los hash son distintos no se puede asegurar la integridad de los datos recibidos y por tanto son descartados.

Este tipo de comprobaciones las podemos ver en varias capas del modelo TCP/IP e incluso algunas veces podemos llegar a pensar que se realiza demasiadas comprobaciones de manera redundante, entonces ¿por qué existe un checksum en cada una de las capas?

Capa 4 – Nivel de Transporte – TCP/UDP

Tanto en la cabecera de TCP como en la de UDP disponemos de un checksum de dos bytes para la detección de errores. Para calcular este checksum se utiliza el segmento completo, es decir, la cabecera TCP o UDP y los datos de la capa de aplicación. Si se detecta un error en la transmisión de los datos, el protocolo TCP puede solicitar la retransmisión del segmento.

Capa 3 – Nivel de Red – IP

En el protocolo IPv4 nos encontramos dos bytes para la detección de errores en la capa de red. Para calcular este checksum tan solo se utiliza la cabecera del paquete IP, por tanto a diferencia de las comprobaciones de la capa 4, en la capa de red no se tienen en cuenta los datos para la detección de errores. Sin embargo, en el protocolo IPv6 se prescinde del checksum y la protección de integridad se realiza en la capa superior de transporte y en la capa inferior de enlace.

Capa 2 – Nivel de enlace – Ethernet

El estándar más utilizado en redes LAN dispone de cuatro bytes al final de la trama para la detección de errores. El FCS tiene en cuenta toda la trama para realizar el cálculo del checksum, es decir, realizará el cálculo con la cabecera de la trama y los datos de las capas superiores. Si se detecta un error en la transmisión de los datos se descartará la trama sin comunicárselo al emisor.

Como hemos podido ver, cada una de las capas dispone de un checksum para la detección de errores. Sin embargo, aunque pueda parecer redundante cada una de ellas tiene sus funciones:

• IP no siempre funciona sobre Ethernet, imagina IP sobre RS-232. Por tanto es necesario realizar la detección de errores en capas superiores a la capa de nivel de enlace.
• TCP/UDP realiza la comprobación de la cabecera TCP/UDP y de los datos de la capa de aplicación pero no de las cabeceras de las capas inferiores.
• IP no realiza el checksum de los datos, tan solo de la cabecera IP. Por tanto, es necesario que esta comprobación la realice otras capas.
• Ethernet realiza la comprobación de la trama completa.
• Cada vez que una nueva cabecera es introducida hay más que comprobar y las capas superiores no ven los bits de las cabeceras de las capas inferiores.
• Ethernet realiza el checksum cada vez que la trama da un salto, es decir, se recalcula el checksum cada vez que la cabecera Ethernet cambia. Sin embargo, el checksum TCP/UDP se realiza de extremo a extremo, por tanto tan solo se recalcula en el emisor y el receptor del segmento.
• Si se detecta un error en TCP se solicitará la retransmisión del segmento, sin embargo si se detecta un error en Ethernet se descarta la trama sin comunicárselo al emisor.

Para finalizar, podemos ver que para asegurar la integridad de los datos y tener redes eficientes es necesario realizar una serie de comprobaciones en cada una de las capas del modelo TCP/IP, sin embargo estos cálculos requieren recursos de cómputo que pueden disminuir la eficiencia de la red y que normalmente son calculados por software mediante el driver de la tarjeta de red. No obstante en escenarios de alta capacidad y exigencias siempre se recomienda utilizar tarjetas de red con procesadores de red Asics dedicados para este tipo de operaciones, y estas características son las que marcan la diferencia en cuanto a precio y rendimiento en el mercado de tarjetas de red.

Un saludo amigos.