Security Art Work

(N.d.E. Hoy tenemos una entrada de Vicente Dominguez, un viejo amigo que hace algún tiempo que decidió comenzar una aventura por su cuenta, que esperamos que le vaya muy bien :)

Después de dar con la entrada de Nacho del mes pasado me fue inevitable eludir mi desviación profesional después de años y años trabajando en un centro de datos y recordé el sobre-esfuerzo que requiere la adaptación a la version 6 de IP para una mente humana que viene de la version 4.

Además de los magníficos problemas que en recursos requiere los 128 bits por cada dirección en su enrutado, las complicaciones para los IDS en recursos y firmas y el mal manejo de algunas utilidades de toda la vida, están los que yo sufrí: los de la mente humana. Éstos lo dejo para el final.

[Read more…]

Recuerdo cuando en el primer día de rebajas decidí salir con mi mujer de compras por el centro; sí, lo sé, es de locos, pero qué queréis que os diga, me gusta el riesgo, pero esa no es la cuestión, así que intentaré no desviarme del tema.

Cuando me disponía a realizar el pago de mi primera compra, la tarjeta falló; no leía el chip. La dependienta volvió a pasarla un par de veces más por el datafono sin éxito, hasta que por fin consiguió leerlo. Esto me sucedió en alguna ocasión más, incluso en una tienda el terminal no fue capaz de leer ni el chip ni la banda magnética de la tarjeta. Me tomé un momento en inspeccionarla detenidamente y vi que estaba demasiado rayada y en mal estado, dicho en otras palabras, mi tarjeta estaba pidiendo a gritos la jubilación.

Aunque no estaba muy lejos de caducar (aproximadamente 8 meses) lo mejor era cambiarla, así que una tarde al salir del trabajo decidí acercarme a mi sucursal bancaria con la intención de solicitar una nueva.

Cuando entré, me fui directo a una de las mesas para comentarles el problema que había tenido para que los terminales de las tiendas leyeran el chip de mi tarjeta y que era necesario que me la cambiaran. La persona que me atendió, muy amablemente me dijo:

-“¿Quieres una Contactless? Es muy cómoda y segura, además se conservan muy bien, no se te rayará tanto y no te dará problemas al ir a pagar.”

En ese momento se me escapó una sonrisa, quizá no debí hacerlo, pero no pude evitarlo. Es cierto que las tarjetas contactless tienen sus ventajas:

• Mayor comodidad. Al no tener que sacarlas de la cartera, resultan más cómodas para realizar pagos.
• Menos desgaste de la tarjeta. No hace falta pasarlas por el datafono por lo que el plástico se mantiene intacto.
• Mayor rapidez para realizar las compras. Si el importe es menor de 20€ no hace falta introducir el PIN.

Con que le hubiera dicho que no me interesaba la tarjeta, habría sido suficiente y ahí habría acabado todo, pero ya que me habló de sus ventajas como algo extraordinario, quise ahondar en la herida y preguntar un poco más acerca de la seguridad de una de sus “ventajas”.

Pagos por importe inferior a 20€ sin necesidad de introducir el PIN.

Esta forma de pago ha despertado mucho recelo entre sus usuarios y presenta ciertas dudas, ya que si perdemos la tarjeta o somos víctimas de un robo, podrían utilizarla sin ningún impedimento siempre que no pasaran de 20€.

Sobre esta cuestión me respondió que el banco disponía de controles que permitían saber si una tarjeta está realizando operaciones de forma irregular sabiendo el comportamiento normal del cliente.

Vale, de acuerdo, entonces si alguien me roba la tarjeta y empieza a comprar como un loco, el banco tarde o temprano se dará cuenta y en teoría me devolverá el dinero, pero ahora pongamos otro caso totalmente distinto.

¿Y si alguien con un datáfono contactless portátil preparado para realizar un cargo de 19,95€ se fuera a una gran superficie como por ejemplo el corte inglés?

Es verdad que para que la tecnología contactless funcione, la tarjeta debe estar como máximo a 3 cm del terminal y se ha mantener durante un segundo frente a él. Pero escondido en un chaquetón y pasándolo disimuladamente a través de los bolsos, solo sería cuestión de tiempo que cazara alguna tarjeta y pudiera realizar el cargo sin que la persona se diera cuenta.

Un solo cargo de 19.95€ en nuestra cuenta puede que pase en la mayoría de los casos desapercibido, sobre todo si no hemos perdido la cartera ni hemos sido víctima de un robo.

Ante esta situación la persona del banco ya no supo qué responderme, no se le había ocurrido poner ese escenario encima de la mesa. Que seas víctima de un fraude sin que te hayan robado, ni clonado la tarjeta es cuanto menos para ser cauteloso y tomar todo tipo de precauciones.

Supongo que los bancos se habrán puesto manos a la obra para garantizar que esto no ocurra, pero por el momento sigo teniendo ciertas reticencias a la hora de utilizar esta tecnología para realizar pagos.

De cara a conocer los cambios que sufre nuestro sistema Windows, especialmente cuando no somos conscientes de dichos cambios como sucede con el caso del Malware, voy a proponer el uso de ARM (Active Registry Monitor). De sobra es sabido que el malware realiza cambios en el registro de los sistemas Windows y ARM sirve concretamente para identificar los cambios que haya sufrir el mismo. Esta aplicación no analiza el registro en tiempo real sino que estudia los cambios entre copias del registro realizadas en distintos momentos.

Con la finalidad de aprender a utilizar ARM vamos a realizar este ejercicio práctico:

Para comenzar a trabajar, lo primero que hay que tener es una copia del registro de nuestro sistema Windows (En este caso será Windos XP SP3 64b). Como ARM se encarga muy bien de esta tarea, ejecutaremos la herramienta y estableceremos la primera copia haciendo clic el botón scan del menú de herramientas:

[Read more…]

Post escrito en colaboración con Manuel Bermúdez Casado.

El tercer y último día de la Rooted empezó con una interesante charla de Manu Quintans (@Groove) y Frank Ruiz (@francruar) “50 shades of crimeware” que trataba sobre las nuevas técnicas de robo de tarjetas. Contaron cómo los criminales se organizan, venden malware y números de tarjetas. Profundizaron en los nuevos tipos de malware especializados en TPV y como este malware es capaz de infectar un TPV de cualquier establecimiento y enviar directamente los datos de las tarjetas a Internet.

Seguidamente, la ponencia “Profundizando en la seguridad de la aviación” nos mostró las nuevas investigaciones de Hugo Teso (@hteso) sobre la seguridad en la aviación. Hugo Teso lleva unos años investigando sobre la seguridad en aviones comerciales. Nos explicó que los aviones disponen de diferentes ordenadores y nos mostró cómo éstos se actualizan en ocasiones por medios inseguros como redes Wi-Fi o 3g. Esta charla dejó de manifiesto la poca atención que se presta en temas de seguridad informática en la aviación. Aunque sus investigaciones no han sido probadas en entornos reales por los peligros que esto conlleva, sí que se han realizado pruebas con drones, simulando casi a la perfección entornos reales.

Tras un pequeño descanso los ponentes José Pico y David Pérez, cofundadores de la empresa layakk, (@layakk) exponen un tema desconocido para muchos: “atacando 3G”. A través de una meticulosa investigación y una gran explicación con muchos detalles técnicos relatan las inseguridades de la comunicación por UMTS, o tecnología 3G. A pesar de que esta tecnología es mucho más segura que la tecnología 2G anterior, sigue heredando las deficiencias de GSM, por lo tanto forzando a que el usuario solo use 2G, se puede volver a conseguir efectuar diversos ataques como denegación de servicio o la localización de un dispositivo (si el atacante se encuentra en un radio no mayor a 3 km) o la interceptación de la comunicación.

En la siguiente charla “Handware hacking: Si hay un ‘input’ hay peligro” Borja Berástegui (@Bberastegui) nos muestra cómo acceder a los sistemas operativos de los paneles de información que se encuentran expuestos al público. Estos paneles son cada vez más populares y están localizados en multitud de lugares públicos como aeropuertos y oficinas de turismo. Los paneles disponen de una pantalla táctil y una aplicación que corre a pantalla completa impidiendo así que cualquier usuario pueda acceder al sistema operativo. Las técnicas de Borja Berástegui consisten en provocar excepciones en la aplicación para acceder al sistema.

Después de comer Juan Vázquez(@_juan_vazquez_) y Julián Vilas (@julianvilas) con su ponencia “Tú a Boston Barcelona y yo a California Tejas. A patadas con mi SCADA!”, explican las deficiencias en la seguridad de sistemas críticos SCADA y PLCs. Muchos de estos sistemas de carácter industrial se implantan en zonas de vital importancia como el sector energético, por ejemplo. En este caso la demostración se hace emulando el modelo del fabricante yokogawaCETUM CS 3000 R3. Sistemas donde se usan versiones del sistema operativo Windows XP SP2 o en algunos casos incluso Windows 2000, con fallos en las configuraciones como directorios compartidos con todos los permisos, firewalls desactivados, vulnerables a varios tipos de exploit. Para terminar se hace una demostración usando metaexploit sobre uno de estos sistemas.

Seguidamente Aladdin Gurbanov, en su ponencia “Magnetic Road” nos enseña la facilidad para clonar tarjetas con banda magnética. Lo hace de una manera divertida y amena y además su acento ruso y los vídeos que expone grabados con su propio móvil, en situaciones cotidianas (pagando el desayuno o el parking con una tarjeta clonada), consiguen hacer sonreír a todos los asistentes. Aladdin explica la facilidad que existe para comprar un clonador de tarjetas ya que se puede conseguir en ebay por unos 50 euros. Incluso las pegatinas holográficas de las tarjetas bancarias se pueden pedir a China por un precio muy barato. En conclusión la falsificación de tarjetas es un juego de niños.

Tras un pequeño descanso Raúl Siles (@dinosec) continúa deleitándonos con los fallos de seguridad de los sistemas IOS, este año con la ponencia “iOS: Regreso al futuro”. Raúl pone en entredicho el sentido de las actualizaciones obligatorias en un sistema IOS, donde explica la manera de evadir esas actualizaciones. Referenciando la película “Regreso al futuro”, hace un símil con la manera de engañar a un dispositivo, y hacerle creer que ya está actualizado cuando en realidad no lo está. Esto plantea inseguridades tan relevantes como, por ejemplo, el poder aprovechar un fallo de seguridad en un dispositivo por no estar actualizado desde hace mucho tiempo; y el usuario ni siquiera lo sabe porque su propio dispositivo le indica que si lo está. Para ello Raúl usa un script hecho en python llamado Iproxy con dos técnicas, una temporal y otra persistente, llamadas “StarWars” y ”Matrix”. A pesar de que estos fallos han sido reportados a Apple, no hay confirmación de su solución a día de hoy.

La última ponencia del día fue a cargo de Jaime Sánchez (@segofensiva) y Pablo San Emeterio (@psaneme), la charla “WhatsApp: mentiras y cintas de video” trataba sobre las inseguridades de WhatsApp, Snapchat y Viber. Sobre WhatsApp cabe destacar la inseguridad en sus comunicaciones y lo fácil que es suplantar la identidad en diferentes mensajes. Snapchat es una aplicación muy usada en EEUU y consiste en compartir imágenes con otros usuarios. En la investigación de esta aplicación Jaime Sánchez y Pablo San Emeterio demostraron cómo se podía suplantar la identidad de los usuarios, llegando incluso a suplantar la identidad del propio CEO de Snapchat.

Por último y ya que se cumplía el quinto aniversario de la Rooted se repartieron premios a los ponentes mejor valorados:

1º NighterMan (muy recomendable su charla Live Free or Die Hacking de la Rooted de 2012).
2º David Pérez y José Picó
3º Raúl Siles
4º Juan Antonio Calles y Pablo González
5º Roberto Baratta

Para poder realizar una gestión adecuada de la seguridad de una empresa u organización, es imprescindible disponer de un inventario detallado de los activos conectados a la red así como de todos los servicios que éstos ofrecen. De este modo, en caso de detectar un activo o servicio desconocido, se debe averiguar su origen y evaluar si supone una amenaza para la organización.

Es recomendable habilitar sólo aquellos servicios que sean estrictamente necesarios para el funcionamiento de los sistemas y aplicaciones. En caso de equipamiento que esté expuesto en zonas DMZ o que deban ser accedidos desde Internet, se deben tomar medidas adicionales de protección asegurando previamente un bastionado de los equipos y limitando el acceso desde la red origen concertada.

Muchos troyanos utilizan habitualmente los mismos puertos, lo cual no significa que se tenga una infección de malware si se encuentra alguno de esos puertos abiertos, pero si ese puerto no es habitual que se use en una organización y de repente se detecta abierto nos debería generar una alerta para revisarlo cuanto antes. Una revisión periódica de los servicios ofrecidos al exterior podría ayudarnos a la hora de detectar un posible ataque, sea a través de un intento de explotación de una determinada vulnerabilidad, conexiones remotas no autorizadas, malware, exfiltración de datos o similar.

Como ya se publicó en el informe “Detección de APTs” (páginas 122 y siguientes), existen diferentes técnicas que una organización puede utilizar para llevar a cabo esa revisión periódica de servicios/puertos abiertos que se encuentren accesibles desde redes externas. Algunas de ellas son las siguientes:

• Preprocesador para Snort: Passive Port Discovery: Es posible desarrollar un preprocesador para un IDS basado en Snort que nos permita alertarnos de nuevos equipos y nuevos servicios, tras analizar el tráfico de una red previamente conocida.
• Monitorización de servicios sospechosos utilizando la herramienta Nessus: Como se explica en el informe “Detección de APTs” se puede configurar Nessus para que de manera diaria, semanal, mensual, etc. nos escanee nuestra red en busca solo de equipos levantados/puertos abiertos -se puede configurar para que no lance ningún plugin de forma que sea lo menos intrusivo- nos busque las diferencias entre un informe y otro y nos alerte al correo, por ejemplo. La opción de pago de Nessus permite la opción “Compare (Diff Results)” que nos compara entre dos informes de resultados y nos muestra las diferencias, sin embargo, también podemos ingeniárnoslas para comprobar la diferencia entre dos informes sin necesidad de tener la versión “pro” de esta herramienta.
• Detección de servicios sospechosos con Nmap: Tal y como indicamos también en el informe mencionado anteriormente, también podemos ver que con Nmap y Ndiff podemos analizar de manera periódica nuestras redes y que nos alerten de posibles servicios sospechosos detectados o de servicios que inicialmente estaban disponibles pero han dejado de estar levantados.

Pero, ¿qué ocurre cuando, usando las técnicas de escaneo descritas anteriormente, somos incapaces de detectar un puerto a la escucha cuando realmente sí que lo está? Me hice esta pregunta tras leer recientemente un post en “Shell is coming…”, en el que Borja Merino publicaba una versión modificada de la bind shell “shell_bind_tcp” (incorporada en Metasploit), que él ha denominado “Hidden Bind Shell”. Dicho esto payload es una versión mejorada sobre otro payload que Borja también publicó anteriormente denominado ACL Bind Shell y que únicamente supone un incremento de unos 30 bytes.

El objetivo de la “hidden bind shell”, tal y como se describe en el blog, es crear una bind shell que responda paquetes RST ante cualquier intento de conexión originado desde una IP diferente a la embebida en el propio payload. De esta forma, cualquier herramienta que trate de escanear el equipo comprometido mostrará como CLOSED el puerto asociado al shellcode.

Para probar el funcionamiento de esta bind shell me he bajado el payload del pull request lanzado a Metasploit y me he creado una “hidden bind shell” que he denominado “backdoor_oculto.exe” y que solo será visible/accesible a través de la IP 192.168.1.2 en el puerto 1024:

Tras ello, en mi entorno de laboratorio voy a comprometer la máquina 192.168.1.46 ejecutando mi “backdoor_oculto.exe” en la misma. Si, como vemos a continuación, intento escanear vía Nmap mi máquina comprometida desde una IP diferente a la 192.168.1.2, en este caso me he puesto la IP 192.168.1.11, el resultado que me da en el puerto 1024 es que está cerrado (CLOSED). Cambiando mi IP a la del ‘atacante’ (192.168.1.2) comprobamos, tras hacer la misma operación, que en este caso el puerto 1024 aparecen como OPEN a ojos del atacante y el mismo puede obtener una shell en dicho equipo comprometido:

Un IDS bien configurado con las firmas adecuadas detectaría probablemente cuándo ha habido una conexión a esa bind shell por parte del atacante, sin embargo, no se me ocurre, utilizando las tradicionales técnicas de escaneos preventivas expuestas anteriormente (nessus, nmap, etc.) cómo detectar que ese puerto está a la escucha en mi equipo (si se os ocurre alguna por favor compartidla :) ). De hecho, he probado diversos escaneos con Nmap, con diferentes opciones de escaneo [1] y los resultados siempre han sido los mismos, como se muestra a continuación:

Una forma que podría ser viable para detectar los puertos “sospechosos” que están a la escucha sería de forma LOCAL en mis máquinas, ejecutando de manera periódica “netstat” en cada una de las máquinas de nuestra red, almacenando los resultados y comparando los mismos de un escaneo a otro para que nos alerte cuándo aparece un nuevo puerto a la escucha y que antes no lo estaba, para que podamos investigar el motivo por el que ahora se encuentra de esta forma. Este proceso puede ser muy lento si tenemos que ir equipo por equipo ejecutando netstat así que, dependiendo de la infraestructura que exista o diseño de la red podemos pensar en automatizar este proceso.

Por ejemplo, si nuestras máquinas forman parte de un Active Directory (AD) por el que podemos administrar de manera centralizada los equipos, inicios de sesión, establecer políticas a determinadas unidades organizativas (ou), grupos de usuarios, desplegar programas en muchos equipos a la vez, etc. Tal y cómo se explicó en el post “Recolección distribuida de IOCs”, podemos valernos de diversos métodos que podemos implementar con dicho AD para automatizar el proceso de ejecución de un script en varias máquinas a la vez de manera periódica. Powershell podría ayudarnos a elaborar un script de estas características, por ejemplo podríamos apoyarnos para realizarlo en la función Get-NeworkStatistics desarrollada por Shay Levi. La idea más simple por ejemplo -grosso modo- sería partir de un fichero origen en el que estuvieran todos los puertos que se supone que una determinada máquina debe tener a la escucha, ejecutar nuestro script por el que se obtengan vía netstat todos los puertos en LISTENING, y cuyo resultado sea volcado en un fichero. Este fichero se compararía con el original y en el caso de que se detecte un puerto nuevo a la escucha que nos notifique de la forma que le indiquemos. Finalmente, tras acabar el proceso de notificación, que se elimine el nuevo fichero creado. Comentar que, en caso de que aparezca un nuevo puerto cuyo estado no sea LISTENING sino que tiene establecida una conexión, no nos alertaría, pero en ese caso, si tenemos un IDS con las firmas adecuadas nos alertaría probablemente.

[1] Recordatorio:

-sS: SYN Stealth. Envía un SYN. Técnica usada por defecto. Si Closed: Recibe RST, Open: Recibe SYN/ACK, Filtered: ICMP unreachable o expira el timeout.
-sT: Connect. Envía un SYN, luego un RST para cerrar conexión. Si Closed: Recibe RST, Open: Recibe SYN/ACK, Filtered: ICMP unreachable o expira el timeout.
-sA: TCP ACK. Envía ACK vacío. Sólo determina si los puertos están o no filtrados. Si Unfiltered: Recibe RST, Filtered: ICMP error; expira el timeout.
-sN: TCP NULL. Envía TCP con todos los flags a 0. Closed: Recibe RST. Filtered: Recibe ICMP unreachable. Open|Filtered: expira el timeout.
-sF: TCP FIN. Envía TCP con el flag FIN a 1. Closed: Recibe RST. Filtered: Recibe ICMP unreachable. Open|Filtered: expira el timeout.
-sX: XMas Scan. Envía TCP con los flags FIN, PSH y URG a 1. Closed: Recibe RST. Filtered: Recibe ICMP unreachable. Open|Filtered: expira el timeout.

El segundo día de este congreso comenzó de la mano de Jose Luis Verdeguer (@pepeluxx) y Victor Seva (@linuxmaniac), que en su charla “Secure Communications System” concienciaron a los presentes de que en un sistema de comunicación, aunque las transmisiones se cifren de extremo a extremo siempre pueden haber mecanismos que permitan realizar técnicas de tipo “man-in-the-middle”, por lo que no es recomendable confiar en infraestructuras de terceros si la privacidad es crucial. Como colofón, presentaron un sistema de comunicaciones libre, basado en VOIP, en el que prima la seguridad, y que estará disponible para su descarga en breve.

A continuación, Joaquín Moreno (@MoxilO), ex-compañero de Security Art Work, realizó una densa charla sobre forense en Mac OS X titulada “Forense a bajo nivel en Mac OS X”. El trabajo realizado por Joaquín es parte de su tesis de máster, y además, prometió publicarlo en cuanto lo presentase, por lo que los interesados podremos asimilar de manera más tranquila todos los conceptos presentados en el breve tiempo del que dispuso. Además, Joaquín está implementando su trabajo a modo de complementos para Plaso, una herramienta para generar líneas temporales cuando se realizan análisis forenses.

Tras un breve descanso en el que pudimos disfrutar de las ya tradicionales conchas Codan, Jorge Ramió (con el que tuvimos una entrevista en Security Art Work), reconocido criptógrafo y profesor de la UPM, realizó una charla denominada “RSA cumple 36 años y se le ha caducado el carné joven” donde tras una breve introducción al algoritmo de cifrado RSA, explicó cómo éste ha sido capaz de afrontar sus 36 años de existencia mediante el aumento de la cantidad de bits necesarios para generar las claves criptográficas. No obstante, Ramió también mostró técnicas de “crackeo” independientes de la longitud de clave y del algoritmo. Estas técnicas, conocidas como ataques de canal lateral consisten, por ejemplo, en escuchar el sonido que emiten los sistemas al realizar los cálculos, o medir la potencia eléctrica que consumen para así poder recuperar la clave criptográfica y poder descifrar los datos.

En la siguiente charla, José Luís Quintero y Félix Estrada, Centro de Operaciones de Seguridad de la Información del Ministerio de Defensa (COSDEF), dieron una charla sobre ciberguerra titulada “Ciberguerra. De Juegos de Guerra a La Jungla 4”, que como su título indica, fue amenizada con referencias a clásicos del cine como Juegos de Guerra.

A continuación, Jeremy Brown y David Seidman, de Microsoft, iban a presentar su charla “Microsoft Vulnerability Research: How to be a finder as a vendor”. No obstante, al no poder asistir David Seidman, fue Jeremy Brown quien finalmente dio un repaso a los programas de compensación para los investigadores de seguridad que deciden colaborar con Microsoft.

Antes del descanso, Chema Alonso (@chemaalonso) habló sobre su ojito derecho, Latch, en una charla titulada “Playing and Hacking with Digital Latches”. Como muchos ya sabréis, esta herramienta permite definir a los usuarios si pueden acceder, o no, a sus redes sociales. De este modo, se garantiza que si un usuario no requiere acceder a un recurso, nadie más puede hacerlo empleando su cuenta.

Tras un breve descanso, Miguel Tarasco presentó AcrylicWifi en su charla “Análisis WiFi de forma nativa en Windows”. AcrylicWifi es una herramienta de análisis de seguridad y monitorización de redes inalámbricas para sistemas Windows desarrollada por Tarlogic. A su vez, Andrés Tarasco presentó en “Ataques dirigidos con APTs Wi-Fi” el protocolo WXP (Wireless exfiltration Protocol), cuyo fin es el de comunicar los sistemas afectados por un APT con su Command & Control a través de los probe request y probe response de la tecnología WiFi.

Roberto Baratta (@RoberBaratta), dio consejos sobre cómo mejorar la seguridad informática con un presupuesto casi nulo en su charla “Monetización de la seguridad”. La última charla del día vino de la mano de César Lorenzana y Javier Rodríguez (@javiover) del Grupo de Delitos Telemáticos de la Guardia Civil (@GDTGuardiaCivil), exponiendo un caso de éxito en su ponencia “Por qué los llaman APT cuando lo que quieren decir es dinero” detallaron un caso que resolvieron sobre APTs.

Un año más hemos estado en uno de los principales congresos de seguridad celebrados en España, Rooted CON, que este año celebraba su V edición y daba cabida a más de 1000 asistentes y más de una veintena de ponentes.

Comenzar destacando que días previos a la Rooted CON tuvieron lugar los tradicionales Rooted Labs, muy esperados, y como novedad este año, también tuvo lugar un training impartido por Corelan; Win32 Exploit Development Bootcamp. Dos días intensos en los que los asistentes y Peter Van Eeckhoutte acabaron exhaustos pero muy satisfechos por los resultados obtenidos. También tuvo lugar el Rooted Arena, en el que las primeras posiciones fueron para, respectivamente: w0pr, dcua, pADAwan y los mejores Write-Ups para w3b0n3s y SkU.

Tras la inauguración del congreso, en el que se anunció la sorpresa de una propuesta de una ¡Rooted CON Valencia! (estaremos atentos…), el día 1 comenzó con una ponencia por parte de Francisco Jesús Gómez y Carlos Juan Díaz que nos hablaron de “Sinfonier: Storm Builder for Security Investigations” una herramienta OSINT modular, evolucionada de Yahoo Pipes, muy interesante y para la que buscaban beta-testers, así que si os interesa para más información no dudéis en visitar la Web del proyecto y su cuenta de Twitter.

La siguiente charla fue a cargo de Alfonso Muñoz, “Ocultación de comunicaciones en el lenguaje natural”, que nos presentaba su proyecto JANO, por el que nos explicaba diferentes formas de ocultar información dentro de textos. El objetivo es ocultar la mayor cantidad de bits posibles en una palabra de lenguaje natural. El problema viene con palabras con varios significados. Alfonso nos contó que utilizaba diccionarios de sinónimos a modo de establecer covert channels como forma de esteganografía en el lenguaje natural.

Pau Oliva nos presentaba una app para Android que nos permite cómodamente bypassear portales cautivos Wifi (“Bypassing wifi pay-walls with Android”) recorriendo todas las IPs posibles que pudieran estar conectadas a una Wifi y cuando encontrara una, spoofear su MAC e IP para conectarse haciéndose pasar por él. Habló de contramedidas también para evitar este tipo de acciones. Las slides ya están disponibles y la app puede descargarse directamente de Google Play.

Tras el primer descanso del día, Antonio Ramos nos hablaba de “Agilidad. La vía a la seguridad”; cómo afrontar un análisis de riesgos de una manera lo más realista posible, incluyendo al cliente en las metodologías, llevando a cabo planes a corto plazo y no teniendo miedo al concepto prueba-error.

La tarde comenzaba con “The Kill Chain: A day in the life of an APT”, en la que Raj Shah nos habló sobre que los ataques dirigidos, a su modo de ver están más cercanos al ciberespionaje que a la ciberguerra, nos recordó el ciclo de vida de una APT y que no se nos debe olvidar que también los humanos somos “APTs”. (Hacer un inciso aquí para recordaros que se publicó no hace mucho un extenso informe sobre ataques dirigidos, historia, implicación en la seguridad nacional y técnicas de detección que podéis descargar, por si os interesa ampliar la información acerca de las APTs).

Pablo Gonzalez y Juan Antonio Calles, nos traían “Ciberwar: Looking for …touchdown!”, una charla en la que nos hablaban de un hipotético caso en el que los estados pudieran aprovechar la tecnología móvil para convertir a los ciudadanos en cibersoldados, haciendo de nuestros smartphones ciberarmas, creando una botnet. Pusieron como ejemplo una app infectada que cualquiera pudiera descargarse en su smartphone y que permitiera -entre otras cosas- grabar sonido, imágenes, pivotar a redes Wifis, realizar llamadas de manera coordinada contra un mismo terminal de forma que se le haga un DDoS sobre el mismo o geolocalizarte. Todo desde el punto de vista del mínimo coste posible.

Alberto Cita nos traía “Skype sin Levita. Un análisis de seguridad y privacidad”. Nos contó que era posible realizar ataques MiTM sobre Skype de forma que pudiéramos interceptar las conversaciones a través del chat y leerlas en texto plano, obtener la contraseña hasheada e ID del usuario, e incluso recuperación y reconstrucción de ficheros enviados.

La última ponencia del día fue a cargo del fiscal Jorge Bermúdez, especializado en delitos telemáticos, “Los hackers son de Marte, los jueces son de Venus”, una interesante charla en la que el fiscal nos puso al día de lo difícil que es a veces aplicar leyes tan antiguas a delitos ‘más recientes’ como son los telemáticos y cómo él consigue aplicarlas de manera que los delincuentes sean condenados.

El día se cerró con un RootedPanel sobre ciberarmas, en el que estuvieron presentes diversos representantes de las fuerzas y cuerpos de seguridad del estado (CCN, MCD, CNPIC) e investigadores de seguridad y debatieron sobre el estado actual del desarrollo de ciberarmas y su uso.

Si nos paramos a contar las veces que a lo largo de un año hacemos uso de nuestras tarjetas de crédito, posiblemente nos saldría como resultado un número muy alto; puede que cientos o quizá miles, aunque esto varía mucho en función de cada uno, claro está. Pero podemos decir que se ha convertido en una herramienta cotidiana que usamos casi a diario.

Utilizamos nuestra tarjeta para realizar compras en un supermercado, en una tienda de ropa, un restaurante, o simplemente la usamos para sacar dinero de un cajero. La acción es siempre la misma, insertamos nuestra tarjeta, tecleamos nuestro código PIN (evitando que nadie lo vea), y ya está, se efectúa la operación.

Sin embargo, ¿nos hemos parado a pensar alguna vez qué medidas de seguridad hay alrededor de esta acción? Es decir, nosotros somos los que nos preocupamos de que nadie mire cuando estamos tecleando nuestro PIN en el cajero o en el supermercado pero, ¿y una vez le damos al Ok? ¿Qué pasa? ¿Mi PIN está seguro? ¿Cómo se transmite? ¿Va en claro o cifrado? ¿Qué medidas de seguridad hay implementadas? ¿Quién es el que establece las medidas que se han de implantar?

Como ya comentó mi compañera Elena Borso en su post “Normas de Seguridad PCI DSS, PA DSS y PCI PTS”, el órgano PCI Security Standards Council, es el encargado de establecer las normas y requisitos que garanticen la seguridad de los datos en la industria de las tarjetas de pago. Como ya adelantó en su post, existe entre otras, una norma llamada PCI-PTS que define los requisitos que se han de seguir en el diseño, fabricación y transporte de los dispositivos de pagos, sin embargo, no dice nada de la seguridad en las transacciones de PIN.

PCI PIN Security Requirements, conocida coloquialmente como PCI-PIN, es la normativa que cubre la seguridad del PIN en las transacciones. Ésta establece los requisitos a cumplir para la gestión, el procesamiento y la transmisión segura del Número de Identificación Personal (PIN) durante las transacciones de pago online y offline con tarjetas en cajeros automáticos (ATM) y en terminales de punto de venta (POS).

La norma fue creada en Septiembre de 2011, y en ella se establecen, divididos en 7 objetivos de control, 32 requisitos de seguridad que las instituciones adquirentes y los responsables del procesamiento de las transacciones con PIN de tarjetas de pago han de cumplir; éstos básicamente son las entidades financieras y las organizaciones que prestan servicios de medios de pago.

Las 7 secciones en las que se divide y se establecen los requisitos de seguridad de la norma PCI-PIN son:

1. Cifrado del PIN (PIN Encryption). Los PINes utilizados en las operaciones reguladas por estos requisitos se procesan utilizando equipos y metodologías que garanticen que se mantienen seguros.
2. Creación de Claves (Key Creation). Las claves criptográficas utilizadas para el cifrado /descifrado del PIN y la gestión de las claves relacionadas, se crean mediante procesos que aseguran que no es posible predecir o averiguar cualquier clave.
3. Transmisión de Claves (Key Transmission). Las claves se transmiten y se transportan de una manera segura.
4. Carga de Claves (Key Loading). La carga de claves a los hosts y a los dispositivos donde se introduce el PIN, se realiza de una manera segura.
5. Uso de las Claves (Key Usage). Las claves son usadas de manera que se previene o detecta su uso no autorizado.
6. Administración de las Claves (Key Administration). Las claves son administradas y gestionadas de forma segura.
7. Equipamiento de seguridad y control (Equipment Security And Control). Los equipos utilizados para procesar los PINes y las claves se gestionan de una manera segura.

Además de los 32 requisitos de seguridad, esta norma también recoge 3 anexos en los que se detalla información, requisitos y técnicas específicas a aplicar en casos concretos.

Anexo A: “Distribución de claves simétricas utilizando técnicas Asimétricas” (Symmetric Key Distribution using Asymmetric Techniques). Este anexo contiene requisitos detallados que se aplican en la creación y distribución remota de claves y en la gestión de los equipos críticos indicados en PCI-PIN.

Anexo B: “Instalación de Claves”. (Key-injection Facilities). Requisitos específicos que se aplican en la carga de claves; además incluye la forma de realizarlo dando cumplimiento a todos los requisitos.

Anexo C: “Tamaño y Fortaleza mínima de las claves para los algoritmos aprobados” (Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms).

En éste se especifican los tamaños mínimos que han de tener las claves y los parámetros de los algoritmos que se van a utilizar. Por ejemplo, en la siguiente tabla se muestran los tamaños y los parámetros del algoritmo que debe ser usado para el transporte, el intercambio y la creación de claves:

Hay que reseñar que, cuando hablamos de claves en PCI-PIN, nos estamos refiriendo a las claves criptográficas que son necesarias para garantizar la seguridad de todas las transacciones de PIN.
Pero… ¿De qué forman manejan las claves criptográficas este tipo de entidades? Esto es ya otra historia que, si un día puedo, os contaré con más detalle.

Volvemos a la carga con uno de nuestros temas preferidos: los honeypots.

En este caso vamos a ver que nos ofrece HoneyDrive, una distribución Linux orientada a la seguridad TI y, en particular, al despliegue y control de herramientas de tipo Honeypot.

HoneyDrive ha sido creada por Ioannis “Ion” Koniaris de Bruteforce Lab, desarrollador de otras aplicaciones relacionadas con el mundo de los Honeypots como Kippo-Graph o Honeyd-Viz, que también analizaremos en profundidad más adelante.

La distribución se basa en una máquina virtual Xubuntu Desktop 12.04 en formato OVA (Open Virtual Appliance) que puede descargarse desde SourceForge.

Instalación

Vamos a desplegar la máquina virtual en nuestro entorno de virtualización. En este caso, usaremos el entorno recomendado por el propio Ion: VirtualBox-4.3 y la forma de desplegar es mediante la opción de “Importar servicios virtualizados” y seleccionando el fichero .ova (este proceso tarda un rato. Paciencia). No hay que definir los parámetros de la máquina virtual. Estos vienen predefinidos en la appliance. Tras el despliegue, procedemos a arrancarla. Accedemos con el usuario HoneyDrive y la contraseña “honeydrive”.

Pasos previos

Antes de ponernos a analizar que tenemos por delante, se deben configurar algunos aspectos como:

• La interfaz de red. Por ahora la he configurado con una interfaz de tipo “Adaptador sólo-anfitrión” asociada a la interfaz vboxnet0 que he creado previamente en el menú Archivo-> Preferencias-> Red-> Red solo-anfitrión-> Añadir
• Para que Honeydrive tenga Internet, deberemos configurar como Gateway nuestro equipo mediante:

sudo route add default gw < ip_vboxnet0 >

• Además, se debe configurar el reenvío de tramas en el equipo físico mediante:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

• Cambiamos el teclado del Anglosajón al nuestro ejecutando:

sudo dpkg-reconfigure keyboard-configuration

• Cambiamos el password del usuario honeydrive por otro mediante el comando "passwd"
• Es importante echar un vistazo al fichero README.txt alojado en el escritorio de nuestro Honeydrive. En él se encuentra información esencial y útil sobre las aplicaciones instaladas como pueden ser: ficheros de configuración, credenciales de acceso, scripts de arranque, etc.

Nuestro primer honeypot: Kippo

Como primera tarea, vamos a probar el honeypot Kippo. Se trata de un honeypot que emula un servicio SSH con el objetivo de obtener las credenciales usadas por los atacantes contra este tipo de servicios. En el fichero README.txt se muestran varios directorios y ficheros relacionados Kippo: script de arranque, directorio de descargas y de logs, fichero de credenciales “válidas”, de accesos a la base de datos, etc. Además, existe el fichero /opt/kippo/kippo.cfg donde se pueden configurar varios parámetros como puerto, IP, hostname, banner a mostrar, etc.

Vamos a probar Kippo:

En el sistema Honeydrive, arrancamos el honeypot desde el directorio /opt/kippo mediante el comando ./start.sh



Desde nuestro equipo, lanzamos un nmap simple y vemos que hay un servidor SSH a la escucha en el puerto 22/tcp (de los otros servicios ya hablaremos).



Nos conectamos a él.



En el primer intento hemos introducido la contraseña 1234 y no ha funcionado. En el segundo, hemos probado con 123456 y hemos podido acceder. Además, ha sido posible ejecutar comandos sobre el sistema supuestamente comprometido.

En el fichero /opt/kippo/log/kippo.log podemos ver con detalle todas las acciones llevadas a cabo. Incluidas las credenciales introducidas anteriormente.

En el fichero /opt/kippo/data/userdb.txt podemos comprobar las credenciales permitidas. En este caso root/123456

En el siguiente post de la serie, probaremos una forma más amigable de comprobar la actividad sobre nuestro Kippo y seguiremos indagando sobre HoneyDrive.

La semana pasada asistimos a la High Level Conference on EU Cibersecurity Strategy (Bruselas, 28 de Febrero) Una muy interesante conferencia, a un nivel más estratégico que técnico, aunque el conocimiento de los ponentes no estaba nada mal. La aprobación de la Directiva sobre NIS (Network and Information Security) propone la coordinación a nivel europeo y reconoce la naturaleza global de la ciberseguridad. La transposición de esta legislación a las nacionales de los estados miembros sentará una política común europea en el tratamiento de las amenazas, la protección de infraestructuras críticas y, probablemente, ayude a mantener una postura común ante incidentes de “presunto” espionaje —no solo por parte de países hostiles— como los recientemente ocurridos.

En la presentación de apertura la Vicepresidenta de la Comisión y encargada de la Agenda Digital Europea, Neelie Kroes, hizo mucho hincapié en la importancia de la ciberseguridad, como condición necesaria para el desarrollo económico asociado a la economía digital.

Como política que es —en el buen sentido de la palabra—, estuvo muy pendiente de las implicaciones de la tecnología. Su argumento fue que si los ciudadanos europeos no confían en las tecnologías de información y en el manejo que se hace de sus datos, desde el punto de vista de la privacidad, el mercado no se desarrollará, lo que tendrá efectos muy negativos en la economía del futuro.

Para ello abogó por mantener, en la medida de lo posible, los datos europeos en Europa o, al menos, no tener la enorme dependencia de otros países en cuanto a aplicaciones y alojamiento de la información. Hay que proteger la privacidad, pero dejando espacio para la actividad de las empresas: “’No’ to data protectionism, but ‘yes’ to data protection”.

En sus palabras, si no somos capaces de sacar adelante una directiva fuerte, significará que la democracia no es capaz de manejar la tecnología. Hay que plantear las preguntas adecuadas. Por ejemplo, no se trata de saber por qué los estadounidenses han pinchado nuestros teléfonos, sino cómo y por qué han tenido éxito.

Un muy interesante discurso, que se puede consultar aquí.

—

Aprovechamos para dar la bienvenida a este mundillo al Cyber Security Blog del ISMS Fórum Spain, impulsado por el Instituto Español de Ciberseguridad. Aunque acaba de nacer, estamos seguros de que no tardará en hacerse un hueco y darnos información de primera mano en el ámbito de la ciberseguridad. De momento, aun lo podemos tratar como a un hermano pequeño ;)