Security Art Work

Hace unas semanas se conoció que Google había dejado de desarrollar actualizaciones de seguridad para los sistemas Android cuya versión sea anterior a 4.4 (también denominada Kit Kat). Esto ha causado bastante revuelo ya que se trata de una decisión que afecta a la seguridad de más 900 millones de dispositivos, casi nada.

Es importante tener en cuenta que las versiones 4.3, 4.2 y 4.1, si nos fiamos de la Wikipedia, son de julio de 2013, noviembre de 2012 y julio de 2012, respectivamente. Es decir, que la versión 4.1 no tiene ni siquiera tres años. No parece un tiempo excesivo como para dejar de dar soporte en materia de seguridad, ¿cierto?

Es evidente que sin soporte por parte del fabricante para corregir los problemas de seguridad del sistema el dispositivo queda vulnerable y, por consiguiente, también el usuario. En cierto modo, no disponer de las actualizaciones para la corrección de vulnerabilidades produce una obsolescencia del dispositivo, no por cuestiones de rendimiento como venía ocurriendo hasta el momento en los dispositivos tecnológicos, si no por cuestiones de seguridad. No podemos olvidar que no estamos hablando de lavadoras que se quedan obsoletas, sino de dispositivos que acumulan un volumen muy importante de información personal: fotografías, correo electrónico, accesos a redes sociales, banca electrónica, etc., y que van a ser uno de los principales objetivos del cibercrimen.

[Read more…]

En los artículos anteriores de la serie (I, II y III) habíamos desgranado prácticamente todo el incidente de seguridad de la Empresa. Tan solo quedaba una pregunta por responder: ¿cómo demonios había llegado el malware a ejecutarse al equipo del director de marketing?

Tenemos una fecha clave: la primera descarga de logo.jpg, realizada el 6 de Octubre. La infección debería haberse producido sobre esas fechas. Los sospechosos habituales suelen ser la navegación web y el correo, aprovechando alguna vulnerabilidad del equipo al navegar por alguna página o abriendo un documento malicioso. Poco probable debido a la excelente política de actualizaciones de la Empresa, pero hay que comprobar si lo que se dice sobre el papel se cumple en la realidad.

Descargamos todos los logs de navegación y de correo, intentando buscar ese ítem malicioso, esa entrada en los registros que señala la descarga de un binario… sin éxito. Varias horas tiradas a la basura. ¿Puede ser que hayan empleado un 0-day contra la Empresa? No sería descabellado, pero aún no hemos descartado todas las posibilidades.

Queda una vía de entrada muy sencilla y desgraciadamente muy efectiva: los USB. Es posible que alguien haya pinchado un USB con el malware en el equipo del director de marketing. O puede que simplemente se lo hayan regalado y que lo haya instalado sin saberlo. Los ecos de BadUSB nos vienen a la mente: ¿ya están empezando a golpearnos con eso?

Hay una forma de saberlo: Windows tiene un listado de todos los dispositivos que se han pinchado en el equipo, así como la última fecha en la que fueron pinchados. Recuperamos de la imagen el SYSTEM desde C:\Windows\System32\config, y corremos USBDeview sobre él.

Varias memorias USB, un disco duro externo, una webcam, un dispositivo HID Logitech, un dispositivo HID Teensy++… Espera. ¿Un Teensy? !!!WTF!!! Sin palabras, llamo a mi jefe, que boquiabierto exclama: ¡Pero qué coj…!

Un Teensy es un pequeño dispositivo hardware del tamaño de una memoria USB que viene con su conector listo para conectarse a cualquier puerto USB. Cuando se conecta a un equipo se identifica como un USB HID (Human Interaction Device), en este caso un teclado. Y cuando tiene conexión, abre una ventana de comandos y lanza de un chorro todas las pulsaciones de teclado que han sido programadas. Es como un Rubber Ducky pero sin forma de USB. Un Teensy es como una mini placa base desnuda. ¿Cómo alguien en su sano juicio iba a pinchar eso en su equipo?

Llega el momento de tener un cara a cara con el director de marketing. Nos reunimos en su despacho con María y él. Las noticias vuelan, porque la tensión en el ambiente se corta con cuchillos. Empezamos a hacer una reconstrucción de los hechos, y a mitad de la segunda pregunta me quedo paralizado, casi no creyendo lo que ven mis ojos:

Como decía Sherlock Holmes: “Una vez descartado lo imposible, lo que queda, por improbable que parezca, debe ser la verdad”. Un jodido acuario USB. Como también decía Ford Fairlane: “Un-be-lie-va-ble”. Sin mediar palabra, saco un destornillador de mi maletín del portátil (hay que estar siempre preparado), le doy la vuelta al mini acuario y empiezo a desatornillarlo ante las protestas del director de marketing y el asombro del resto.

No lleva mucho encontrar el arma del delito. Cuesta creer que algo tan pequeño pueda causar tantos dolores de cabeza:

La última pieza clave del puzzle cae en su sitio. Como Rusia en la Guerra Fría con el Gran Sello, los atacantes habían entrado hasta la cocina usando un método tan simple como elegante: regalando al director de marketing un mini acuario USB.

Los atacantes al parecer conocían el gusto del director de marketing por los acuarios, así que se hicieron pasar por una empresa de acuarios y le enviaron por correo el mini acuario como detalle. El director de marketing hizo el resto.

Poco quedaba por hacer de la investigación. Los nombres de dominio habían sido comprados con una tarjeta de crédito robada, y estaban a nombre de un ciudadano tailandés que no había visto un ordenador en su vida. De la VPN poco íbamos a poder sacar (en este tipo de empresas se valora en extremo la privacidad de los usuarios, y si además no estás dentro de la Unión Europea poco podemos hacer). La información exfiltrada a estas alturas estaba ya guardada a buen recaudo por los atacantes, que a bien seguro habían conseguido su objetivo.

Nuestro trabajo había terminado, pero aún pudimos hacer un balance de lecciones aprendidas por la Empresa:

• Los malos hacen sus deberes. El director de marketing tenía una importante presencia en redes sociales, y debió ser estudiado concienzudamente por los atacantes y designado como el blanco más fácil de la Empresa.
• Si un atacante tiene acceso físico a un equipo, deja de ser tu equipo. Y no tiene que estar delante para tener acceso. Es necesario imponer controles y restricciones sobre los USB, y no solo a nivel de dispositivos de almacenamiento.
• La correlación es tu amiga. Un sistema de correlación de eventos habría sido capaz de detectar la “ubicuidad” del director de marketing y haber generado una alerta que habría prevenido una mayor fuga de información.
• La detección de anomalías es poderosa. En un buen sistema de detección de comportamientos anómalos, un dominio del estilo de www.period1co.es o una petición POST sin GET previos deberían generar una alerta de nivel alto inmediatamente.

El resto del incidente es historia: rodaron algunas cabezas, la empresa decidió (sabiamente) que necesitaba un CISO y se tomó buena nota de las lecciones aprendidas para que un incidente así no volviera a suceder.

Y nosotros aún nos seguimos maravillando de las cosas que se le ocurren a la gente … :)

En la actualidad, el uso de smartphones y tablets se ha convertido en una parte fundamental de nuestras vidas. El rápido crecimiento de las aplicaciones de mensajería instantánea ha hecho que servicios como llamadas telefónicas o SMS queden desplazados por los mensajes enviados desde aplicaciones en terminales móviles. Es por esto que este tipo de mensajes puedan tener cabida en un tribunal como prueba ante un delito.

En este post comentaré lo que fue mi Trabajo Fin de Grado en la Universidad de Alcalá el cual fue dirigido por el IUICP (Instituto Universitario de Investigación en Ciencias Policiales) y por lo tanto, imaginaréis que quienes lo usarán serán las FFCCSSEE en caso de que sea necesario para llevar algún tipo de investigación forense donde sea preciso recuperar conversaciones mantenida desde LINE.

¿Por qué LINE y no otro? Para chatear con una persona usando LINE no es necesario que ninguna de las partes tenga el teléfono móvil de la otra, únicamente dando el ID de usuario ya puedes mantener una conversación. El anonimato que esto ofrece, junto con las conversaciones secretas (sus mensajes se autodestruyen “permanentemente”), abre un campo muy amplio que dejo a vuestra imaginación.

Aunque no puedo dar mucha información sobre aspectos técnicos de la investigación (una pena ya que todo esto es propiedad del IUICP), sí puedo comentar el proceso que realicé, que puede dar una orientación a otras personas interesadas en este tipo de investigaciones.

Lo primero que analicé fue el protocolo usado por LINE para envío y recepción de mensajes. Debajo se puede ver una imagen con el esquema del protocolo de mensajes.

Resumiendo:

En un segundo bloque, separado por Android o iOS, llevé a cabo el análisis de:

Por último, en un tercer bloque describo las aplicaciones desarrolladas a partir de las que se demuestra que es posible recuperar conversaciones desde una base de datos de LINE:

• Lector de mensajes: Obtiene las mensajes de la base de datos y los maqueta en una interfaz HTML.
• Recuperación de mensajes eliminados: Mediante técnicas de data-carving en busca de datos como server_id, quedando al descubierto que sí es posible recuperar mensajes eliminados de la base de datos, tanto de conversaciones normales como secretas.

Comparto a continuación la presentación que utilicé en las II Jornadas de Seguridad y Ciberdefensa de la Universidad de Alcalá, que contiene algunos detalles más del funcionamiento de LINE de los indicados arriba. Seguiré con el proyecto que llevan a cabo las Fuerzas y Cuerpos de Seguridad del Estado, analizando otras aplicaciones de mensajería instantánea y publicando en Security Art Work los avances que haga.

¡Buenos días amigos! Vuestro sysadmin favorito al teclado hoy. Vamos a la materia.

En el mercado existen multitud de herramientas para pentesting. Todas ellas incorporan sistemas de evasión tanto de IDS, como WAF etc.; nmap incorpora fragmentación, cloak, decoys, spoof, custom data packet; sqlmap lleva check-waf y un montón de tampers, y así casi-todas. Echadle un vistazo porque la lista de aplicaciones que usáis todos los días para vuestros pentest favoritos que incorporan estos extras es considerable. Además tienen cierto éxito con los habituales sistemas de protección/detección. Ya sabéis de lo que hablo. En detección: snort, suricata…; en protección-waf: modsecurity, naxsi… y todos estos requieren algunos esfuerzos “extras” para detectar todas las posibilidades existentes. Bien. Fantástico.

Y luego de todo esto, tenemos CloudFlare.

[Read more…]

El capítulo anterior había quedado en un cierto impasse mientras esperábamos que nuestro experto en reversing destripara el malware encontrado. Afortunadamente, en unas pocas horas obtuvimos unos resultados preliminares la mar de interesantes:

• El malware realiza múltiples llamadas a la librería Schannel.dll.
• Se observan varias ocurrencias de la cadena AKCMDDC4-B2132 justo antes de dichas llamadas.
• Muy cerca de esas llamadas el malware obtiene el nombre del equipo.

Una táctica interesante del malware que emplea cifrado es generar al vuelo una clave usando un patrón fijo y datos del equipo infectado, para así dificultar su descifrado, por lo que AKCMDDC4-B2132 podría ser una buena candidata como clave. Y la librería Schannel.dll es la que guarda todos los algoritmos de cifrado nativos de Windows, por lo que la teoría del uso de cifrado parece ser acertada.

Sabemos que si usa Schannel.dll no está empleando un método de cifrado casero, por lo que tan solo nos queda adivinar el tipo exacto que está empleando nuestro malware. Mi jefe es muy paranoico y opta por AES, mientras que yo pienso que no se han complicado la vida y tiro por RC4 (mucho menos costoso de implementar y más ligero computacionalmente).

Un mini script en Python con pycrypto, y al jefe le toca pagar el café: el tráfico está cifrado en RC4, y aplicando la clave AKCMDDC4-B2132 se descifra a la perfección.

El tráfico de las peticiones POST queda abierto ante nosotros y hiela la sangre: Lo primero que vemos son las credenciales de acceso al OWA (Outlook Web Access), el webmail de la Empresa. Lo siguiente, el contenido de lo que parece un fichero .pcf de un cliente de VPN Cisco (la configuración de una VPN Cisco). Con la contraseña incluida.

El malware no está exfiltrando documentos confidenciales: está enviando todas las llaves del reino con esas peticiones POST, obteniéndolas posiblemente mediante alguna funcionalidad de keylogger o accediendo a las contraseñas en claro guardadas a lo ancho y largo del sistema.

Ya hemos encontrado la causa de la brecha, por lo que podemos empezar la fase de contención. Llamamos a María para que revoquen todos los accesos del director de marketing mientras seguimos analizando el tráfico cifrado, en este caso el existente en la imagen logo.jpg.

Como sospechábamos, el contenido está cifrado, usando RC4 y la misma clave que en la comunicación HTTP. Una vez descifrado, el contenido es claro:

SendPass

Interesante a la par que sibilino. Al parecer el malware no funciona de forma periódica, sino cuando es invocado a través de comandos, que suceden de forma completamente asíncrona. El funcionamiento parece ser el siguiente:

• En horario laboral, y de forma aleatoria, el malware descarga logo.jpg y descifra el comando.
• Un tiempo aleatorio más tarde (pero también dentro de horario laboral), se realiza la comunicación POST con el resultado del comando.

El objetivo del malware es muy claro: hacer que las comunicaciones sean aperiódicas y parezcan tráfico normal para pasar desapercibidas ante los controles de seguridad.

Ya conocemos el objetivo del malware y cómo lo hace. Quedan varias preguntas muy importantes por resolver: qué se han llevado, desde cuándo lleva la Empresa comprometida y cómo han podido entrar en el equipo del director de marketing.

Para ver qué datos han podido ser exfiltrados, repasamos todas las conexiones realizadas con las credenciales del director de marketing tanto desde la VPN como desde el OWA. Al ser un equipo portátil con 3G, las conexiones vienen desde multitud de sitios. Sin embargo, tras un poco de trabajo de limpieza, una dirección se repite con cierta frecuencia, tanto en VPN como en OWA.

Examinando la dirección, encontramos que corresponde con la salida de un conocido proveedor de VPN ruso. Si ya tienes una VPN, ¿qué sentido tiene el pasar tu tráfico por otra? Extremadamente sospechoso.
Hablando con María obtenemos los eventos de inicio de sesión del director de marketing de los últimos tres meses, e intentamos buscar inconsistencias. Sabiendo lo que tenemos que buscar no tardamos en encontrar varios puntos, todos ellos dentro de horario laboral, en los que el director de marras está a la vez dentro de la Empresa y conectado por la (doble) VPN. Ya tenemos los datos de conexión del atacante y conocemos su modus operandi (bastante cuidadoso, por cierto).

Saber qué se ha podido llevar es mucho más complicado. Dado que ha podido entrar como si fuera el director de marketing, su nivel de acceso es muy elevado. Vamos a centrarnos en dos puntos de fuga principales: su cuenta de correo y el servidor corporativo.

Revisando su buzón de OWA no encontramos nada sospechoso. Todo está perfectamente en orden, ordenado y pulcro en extremo. Sin embargo, los logs de Exchange cuentan una historia totalmente diferente: hay docenas de correos electrónicos enviados a cuentas de Gmail con nombres muy similares a personal de la Empresa y otras empresas colaboradoras. Los atacantes siguen intentando mantener un perfil bajo, borrando del OWA los correos enviados para no dejar rastro.

La información exfiltrada es… complicada. Correos con información sensible, documentos de la estrategia de ventas de la Empresa, hasta lo que parece ser un indicio de que el director de marketing está teniendo un “asunto” con alguien de Finanzas. Un completo desastre.

Obtener un registro de qué información ha podido ser exfiltrada del servidor corporativo va a ser un poco más complicado. Afortunadamente tenemos algo de suerte en este aspecto: en la Empresa han apostado por una estrategia de gestión documental férrea basada en Sharepoint, por lo que todo está bastante bien organizado y pasa obligatoriamente por el CMS.

Además, algún administrador de sistemas lo suficientemente paranoico había activado la trazabilidad, por lo que tenemos un listado de quién ha accedido a qué documentos en los últimos seis meses. El problema es que no sabemos qué documentos han sido accedidos por el director de marketing o por los atacantes.

Correlar las fechas de conexión por la VPN no sería del todo efectivo ya que hay momentos de solapamiento. La solución por la que optamos es obtener un listado de los documentos accedidos durante esos solapes, y cruzarlos con los accedidos por el director de marketing. Saber qué documentos han sido accedidos por el director de marketing es algo laborioso pero realizable.

Tenemos una imagen de disco. ¿No os acordáis de ella? Pues nos va a venir de maravilla, porque Windows guarda un listado de los documentos accedidos más recientemente (MRU, Most Recently Used) para cada usuario (en versiones modernas de Windows hasta por programa). Volcamos del disco el NTUSER.DAT y lo pasamos por RegRipper para obtener el listado de ficheros sobre el que trabajar.

Aquí no tenemos tampoco buenas noticias. Entre los documentos que sabemos han sido accedidos desde la VPN y el despiece hecho con RegRipper toda la estrategia corporativa ha sido exfiltrada.

El siguiente paso es saber cuánto tiempo lleva la Empresa comprometida (trufada, como solemos usar en nuestra jerga). Para ello podemos componer una línea temporal con toda la información de la que disponemos, a saber:

• Primera descarga de logo.jpg
• Primera comunicación POST contra www.period1co.es
• Accesos desde la VPN al OWA
• Accesos desde la VPN al Sharepoint

Las piezas van encajando como un puzzle. La primera descarga de logo.jpg se produjo el 6 de Octubre, la primera comunicación POST dos días más tarde, y en ese mismo día ya se estaban descargando documentos tanto del OWA como del Sharepoint. Dos meses trufados sin que nadie se diera cuenta. Como diría Pazos de Airbag: Profesional, muy profesional.

Mientras comunicamos todo lo hallado a María para que la Empresa pueda realizar sus trabajos de contención a nivel de relaciones públicas, solo queda una pregunta por responder: ¿cómo lograron los atacantes entrar en la Empresa?

La respuesta la tendremos en el siguiente y último artículo de la serie…

Estimados lectores, esta mañana me encontraba en la máquina de café de la oficina hablando con varios compañeros sobre la filmografía del bueno de Christopher Nolan (por si no lo conocen, es el director de películas como Memento o la más reciente Interstellar). Pues bien, dentro de su filmografía podemos encontrar una que juega con el concepto de la recursividad. Se llama Origen y en mi humilde opinión es una gran película, con un reparto de lujo (Leonardo Dicaprio, Marion Cotillard, Ellen Page, etc.)

Y ustedes se preguntarán ¿y todo esto a qué viene? Algo tan sencillo como que la recursividad me ha sugerido la idea de escribir un post sobre un reciente proyecto en el que he participado y que finalmente ha terminado con la obtención de un certificado ISO 27001.

Este proyecto tenía numerosas particularidades que lo hacían especialmente complejo. Por ponerles en contexto, el proyecto consistía en la implantación de un SGSI para ciertos procesos de una plataforma online de una importante multinacional.

La primera particularidad era su reducido alcance. La segunda era que la sede española ya disponía de un SGSI certificado. La tercera era que se trataba de un proyecto que pertenecía a la matriz internacional, con un equipo de personal dedicado, y no a la sede española. La cuarta era que los servicios que prestaban departamentos transversales de la sede española (TI, RRHH, etc.) para nosotros eran parcialmente opacos. La quinta era que los sistemas de información estaban ubicados en un proveedor certificado por la ISO 27001. La sexta era que el SGSI debía ser en inglés (pero bueno esto no es especialmente relevante)…

Así pues, voy a tratar de exponerles ciertas situaciones que se me plantearon como cuestiones durante el proyecto. Espero que mi experiencia les pueda ser útil.

¿Se puede certificar por la ISO 27001 un proyecto y no una empresa? Sí, la norma no necesariamente requiere certificar una empresa es más, por norma general se certifican procesos de negocio de la misma. Pero también se puede certificar, por ejemplo, proyectos realizados en una UTE (Unión Temporal de Empresas). No obstante, siempre deberá haber un CIF detrás.

Si quiero certificar un proyecto dentro de mi empresa, la cual ya está certificada, ¿es necesario definir otro SGSI? No, tan solo bastará con ampliar el alcance del mismo. Siempre y cuando lo hagamos con la misma entidad de certificación. Si quieren hacerlo con otra entidad entonces deberán definir un SGSI nuevo o ampliar el alcance y someter el SGSI a otra auditoría. En este caso, por requerimiento de la matriz, la entidad certificadora debía ser otra distinta y partir de un SGSI nuevo.

¿Existe algún problema en seleccionar un alcance muy limitado? No, siempre y cuando tenga sentido. No obstante, un alcance limitado no nos eximirá de implantar gran parte de controles, como podemos pensar en un primer momento. Por ejemplo los controles relacionados con Recursos Humanos o con la seguridad física, casi al 100% nos serán de aplicación.

¿Puedo utilizar el comodín del SGSI existente para alegar que un control está implantado en el nuevo SGSI? Sí, pero ojo que el auditor puede auditar ese control, es decir por estar certificado no hará un dogma de fe y lo dará por válido. Puede darse el caso de que un proceso que sea idéntico para los dos SGSIs, por ejemplo el CV Screening, un auditor lo de por válido y otro no. Por eso, podemos referenciar en nuestra declaración de aplicabilidad cómo está implantado el control en el otro SGSI, pero siempre debemos revisar que en efecto se está cumpliendo.

¿Cómo tratamos a los servicios transversales (TI, RRHH, etc.) que nos prestan desde una sede concreta, pero sobre los que no tenemos control directo? Mi recomendación, y dada la casuística en este caso, es la definición y suscripción de OLAs (Operation Level Agreements) que reflejen: Los servicios prestados, los niveles de servicio asociados y aspectos de seguridad requeridos por el proyecto. Sin embargo, aquí deberemos tener cuidado en las formas de proceder y en las “exigencias que impondremos”, puesto que podemos encontrarnos con reticencias por parte de nuestros proveedores internos.

Si mis sistemas de información están en un proveedor de housing/hosting certificado por la ISO 27001, ¿el auditor verificará las medidas de seguridad de mi proveedor in situ? Pues depende, pero en más de una ocasión puedo confirmarles que durante la auditoría el auditor ha solicitado visitar las instalaciones del proveedor y revisar las medidas de seguridad existentes. A pesar de que el proveedor esté certificado por la ISO 27001, la ISO 20000, o este acreditado como Tier III.

Finalmente, otra de las lecciones aprendidas de este proyecto, es que no siempre un alcance acotado o la existencia de un SGSI previo puede disminuir la complejidad del proyecto de implantación de ISO 27001. Así que como siempre les decía a mis alumnos de taekwondo nunca subestimes a tu rival.

En cualquier caso, le doy mi más sincera enhorabuena a este proyecto por la obtención de la certificación ISO 27001.

P.D. Y por si se lo estaban preguntando, Dicaprio tampoco consiguió el Oscar con esta película.

Recientemente he estado revisando documentación de controles de red a nivel 2 y justo vino a mi memoria el post de Borja Merino de hace algún tiempo.

En el post, Borja hablaba de cómo hacer frente a ataques DHCP mediante la funcionalidad DHCP Snooping de Cisco, hablando de puertos confiables y no confiables, y de la tabla de asociación IP-MAC usada. También hace referencia a DAI (Dynamic ARP Inspection) como funcionalidad de seguridad para poder evitar posibles ataques MitM como ARP poisoning; es justo esta funcionalidad en la que nos centraremos en la entrada de hoy.

DAI es una medida de seguridad disponible en switches Cisco que nos permite validar los paquetes ARP de la red; al igual que en el post de Borja, DAI utiliza la tabla de asociaciones IP-MAC generada por DHCP Snooping, aunque esto es opcional. Para este post, daremos de alta las entradas de forma manual, algo poco eficaz en entornos grandes.

DAI intercepta las peticiones y respuestas de los puertos no confiables (untrusted) y las valida contra la tabla antes de actualizar su cache y permitir el tráfico. Puesto que el comportamiento por defecto es definir todos los puertos como untrusted, deberemos especificar los puertos confiables (trusted) mediante el comando ip arp inspection trust para evitar el bloqueo de puertos, por ejemplo de puertos de conexión con servidores o enlaces troncales entre switches.

Nuestra arquitectura de red es similar a la vista en el post de Borja, disponemos de un switch, en este caso un Cisco 3750, dos equipos de usuarios y un servidor DHCP aunque éste último, no vamos a usarlo ya que se configurarán manuales.

Lo primero que hacemos es comprobar que existe conectividad entre ambos equipos (¡cuántas veces hemos asumido que todo funciona antes de modificar algo y luego, cuando no va y tenemos que ir deshaciendo lo realizado, vemos que antes tampoco funcionaba como tocaba!). Una vez aseguramos la conectividad, procedemos a activar DAI.

Por defecto, DAI inspecciona todos los paquetes ARP enviados desde los puertos no confiables para asegurar la presencia de una correspondencia IP-MAC en la tabla de asociaciones. Aunque pueden activarse validaciones de seguridad adicionales mediante el comando ip arp inspection validate, nosotros usaremos las funcionalidades por defecto.

Switch(config)# ip arp inspection vlan 1

La activación, como hemos comentado anteriormente, define todos los puertos como no confiables:

Switch# show ip arp inspection interfaces 

 Interface        Trust State     Rate (pps)    Burst Interval
 ---------------  -----------     ----------    --------------
…
 Gi1/0/20         Untrusted               15                 1
…
 Gi1/0/24         Untrusted               15                 1

Por lo que se comprobaría la presencia en la tabla de asociaciones de una entrada, algo que hemos dicho que realizaríamos de forma manual, y al no encontrar ninguna, bloqueará el tráfico. Esto podemos verlo claramente en el log que muestra la consola, y donde se especifica MAC origen, IPs origen, destino e interfaz.

Aunque ya hemos visto que funciona, podremos validar que la funcionalidad se encuentra activada y se está bloqueando el tráfico:

Switch# show ip arp inspection vlan 1

Source Mac Validation      : Disabled
Destination Mac Validation : Disabled
IP Address Validation      : Disabled

 Vlan     Configuration    Operation   ACL Match          Static ACL
 ----     -------------    ---------   ---------          ----------
    1     Enabled          Active                         

 Vlan     ACL Logging      DHCP Logging      Probe Logging
 ----     -----------      ------------      -------------
    1     Deny             Deny              Off          

Switch#  show ip arp inspection statistics

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
 ----      ---------        -------     ----------      ---------
    1            0            971            971              0

El siguiente paso será añadir manualmente, las asociaciones IP-MAC de cada uno de los equipos en la tabla, especificando la interfaz donde están conectados:

Switch(config)# ip source binding 0024.beec.2526 vlan 1 172.18.0.222 interface gigabitEthernet 1/0/20                                                                                               
Switch(config)# ip source binding 0050.5b00.0dff vlan 1 172.18.0.111 interface gigabitEthernet 1/0/24

Y ver que se han almacenado correctamente:

Switch# show  ip source binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:50:5B:00:0D:FF   172.18.0.111     infinite    static          1     GigabitEthernet1/0/24
00:24:BE:EC:25:26   172.18.0.222     infinite    static          1     GigabitEthernet1/0/20

Esta asociación también podría hacerse definiendo una ACL.

Llegados a este punto, volveríamos a tener conectividad, por lo que si volvemos a comprobar las estadísticas, vemos que ya aparece tráfico reenviado:

Switch#  show ip arp inspection statistics 

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops                                                                                                                                           
 ----      ---------        -------     ----------      ---------                                                                                                                                           
    1            120            316            316              0      

Hasta aquí, solo hemos visto el comportamiento normal del sistema, pero ahora, vamos a enviar tráfico con una dirección MAC (o IP) distinta de las introducidas en la tabla anterior; esto puede hacerse de forma manual cambiando la configuración del adaptador de red, o con herramientas de manipulación de tráfico como scapy.

Al cambiar la dirección MAC perdemos la conexión con el equipo remoto, y volvemos a ver avisos en el log donde se indica la nueva dirección MAC, la cual no aparece en la tabla de asociaciones:

Y vemos cómo el número de paquetes dropeados aumenta:

Switch#  show ip arp inspection statistics 

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
 ----      ---------        -------     ----------      ---------
    1            135            380            380              0

Esta configuración mostrará un aviso en el log, pero es más interesante configurar el equipo para que, en caso de detectar que el número de paquetes ARP que no tienen presencia en la tabla, supere un umbral definido, por ejemplo un paquete por segundo, bloquee el puerto (err-disabled) durante un periodo de tiempo (y lo notifique por SNMP).

Switch(config)# errdisable recovery cause arp-inspection   
Switch(config)#  interface gigabitEthernet 1/0/24
Switch(config-if)# ip arp inspection limit 1 

Puesto que el equipo sigue intentando conectarse, el puerto se bloquea automáticamente:

Y así lo veremos el estado de la interfaz sospechosa:

Switch# show  interfaces gigabitEthernet 1/0/24 status 

Port      Name               Status       Vlan       Duplex  Speed Type
Gi1/0/24                     err-disabled 1            auto   auto 10/100/1000BaseTX

También podríamos verlo si tenemos activado el log de violaciones detectadas por DAI mediante el comando show ip arp inspection log.

Dado que no hemos modificado el tiempo, el puerto estará 5 minutos bloqueado, pudiendo ver cuanto tiempo queda hasta la próxima comprobación:

Switch# show  errdisable  recovery                     
ErrDisable Reason    Timer Status
-----------------    --------------
arp-inspection       Enabled
…

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

Interface    Errdisable reason    Time left(sec)    Errdisabled vlans
---------    -----------------    --------------    -----------------
Gi1/0/24     arp-inspection            118  

Si mientras el puerto esta bloqueado, volvemos a dejar la dirección MAC correcta, una vez venza el timeout, el puerto volverá a levantar correctamente y recuperaremos la conectividad:

Como comentaba Borja en su entrada, existen distintas funcionalidades de seguridad a este nivel que debemos tener en cuenta a la hora de comprar nuevos equipos. No obstante, es habitual que este tipo de medidas vengan desactivadas por defecto y queden sin configurar salvo para casos puntuales.

Como reflexión final para los lectores, ¿disponen de medidas de seguridad a nivel 2 en sus organizaciones?

En el capítulo anterior habíamos dejado la investigación en un punto candente: teníamos pendiente un análisis forense del equipo del director de marketing, ya que todo apuntaba a que podía ser la fuente de la filtración de la información.

Hablando con María, la CIO de la Empresa, tomamos la decisión de ser extremadamente cautos a la hora de hacer una imagen forense del portátil del director de marketing, ya que la paranoia campa a sus anchas por la Empresa y no es posible fiarse de nadie.

Esperamos a que salga a una reunión en otra empresa para entrar en su oficina y abalanzarnos con nuestro bloqueador de escritura de discos para obtener una copia bit a bit (las únicas válidas ya que capturan el estado del disco tal y como está, copiando tanto ficheros borrados como espacio libre del disco duro).

[Read more…]

Hace unos días Google anunció que no va a desarrollar más parches de seguridad para versiones inferiores a la 4.4 (Kitkat), en respuesta al último reporte de un grupo de investigadores independientes, quienes encontraron una vulnerabilidad en el módulo “WebView” que afectaba a versiones de Android inferiores a 4.4.

Al leer esta noticia me entró “el afán del investigador” y casualmente encontré algo muy curioso en los emoticonos de nuestra querida aplicación para Android, Whatsapp. Para explicar ese ”algo” tan curioso recurriré a diversas capturas de pantalla donde podréis observar de lo que os hablo. Al parecer existen ciertos caracteres que Android no interpreta y que por lo tanto no los puede renderizar en la pantalla.

Todo empezó cuando me dispuse a enviar unas cuantas banderas (emoticonos) al Whatsapp de un amigo:

Como podemos observar, no hay un comportamiento extraño de la aplicación Whassap para Android, simplemente lo que vemos: varios emoticonos de banderas. No obstante trasteando un poco y al realizar un “backspace” en la primera bandera, obtuve lo siguiente:

¿Interesante, verdad? Como podemos ver al realizar dicho “backspace” los restantes emoticonos de banderas cambiaron, representándose ahora como caracteres unicode. Este hecho me llevo a seguir realizando pruebas en busca de algo más… Así que continué con la búsqueda del carácter no representable, como podemos ver a continuación:

Tal y como vimos en la imagen anterior añadí emoticonos de banderas justo antes del último emoticono representado como una bandera. Posteriormente realicé un “backspace” en el segundo emoticono de bandera añadido en el paso anterior y obtuve lo siguiente:

Posteriormente a esto, probé a escribir cualquier texto delante de la única bandera que quedaba con vida (XD), y para mi sorpresa, los caracteres empezaron a desaparecer como por arte de magia. En realidad, lo que sucedía es que la aplicación Whatsapp era y es incapaz de representarlos, así que copie esa parte y me dispuse a enviarla. Estos fueron los resultados:

Digamos que ahora podía enviar mensajes a cualquier contacto sin que Whatsapp pudiese representar dichos caracteres en mi pantalla, algo que podría ser muy útil en determinadas situaciones. Sorprendido por ese hecho decidí ver qué caracteres se almacenaban en mi historial de conversaciones:

Como podemos observar, mandamos en primer lugar un “hola”, en segundo lugar “que tal” y por último “yo estoy genial”. Además añade el signo de interrogación como la representación del carácter “desconocido”.
El mensaje se guarda correctamente en el historial de la aplicación de Whatsapp, además el contacto recibe el mensaje correctamente, no obstante no se renderiza en nuestro terminal, es decir el mensaje no aparece en la pantalla de nuestro terminal.

Para averiguar qué carácter es el que Android es incapaz de representar, tiramos de un programa muy conocido: “hexadump”, para analizar el contenido en hexadecimal del historial de la conversación de Whatsapp.

Ahora procederemos a analizar cada par de caracteres hexadecimales para encontrar cuál es ese carácter “desconocido”:

Como vemos, no pude obtener qué carácter era el “desconocido”, ya que directamente la aplicación Whatsapp no pudo ni puede interpretar dicho carácter, y por lo tanto no lo guardó en el historial de conversaciones de la aplicación. Probé a hacerlo de otra forma, aprovechando que los caracteres Unicode tienen un tamaño de 1 a 4 bytes; existía la posibilidad de que el teclado de virtual de Android tuviese algún tipo de “bug” que permitiese el borrado parcial y no total de ciertos caracteres.

Efectivamente así fue :). Al parecer, existen ciertos emoticonos en la aplicación de Whatsapp para Android, que cuando realizas un “backspace” para intentar borrarlos, no lo haces por completo. Si a esto le sumamos que añadimos un nuevo carácter o emoticono, obtenemos cosas tan curiosas como las que vimos en la imagen anterior: caracteres Unicode que representan una ficha de dominó en este caso.

Ya solo me quedaba ver el código hexadecimal de dichos caracteres:

Con lo que concluí que 1F0 es el código hexadecimal (incompleto, pares de 2 números) que la aplicación para Android no puede representar :), y que automáticamente genera cuando sobre determinados emoticonos se le aplica un “backspace”:

Después de este análisis, me di cuenta de que esto sucedía en todas las aplicaciones para Android por lo que deduje (o intuyo) que se trata de un bug/problema/feature no documentada en el teclado virtual de Android, que permite no borrar por completo ciertos emoticonos cuando se dispone a eliminarlos (backspace), formando una secuencia que codificada en hexadecimal es 1F0, imposible de representar (renderizar) en la pantalla del usuario que lo envía.

Comienza un día nuevo en la oficina. Todos los sistemas están funcionando correctamente, el generador de cafeína está a toda máquina y los comerciales están fuera haciendo visitas. Es un momento perfecto para revisar algunos artículos de investigación, o hasta para invertir un poco de tiempo en un par de scripts en Python a los que les llevo dando vueltas un rato… hasta que suena el teléfono.

El jefe ha recibido una llamada de la CIO de una empresa del IBEX 35 (a partir de ahora, la empresa será Empresa, y la directiva María). Según sus palabras, se ha producido una fuga de datos. Una fuga muy grave. Al parecer, parte de lo que se ha filtrado es el plan estratégico de la empresa para los próximos cinco años. Información a la que tiene acceso un grupo muy reducido de personas, entre las que se encuentra el consejo de dirección de la empresa.

Como todavía no sabemos a lo que nos enfrentamos, cogemos tanto la mochila de respuesta ante incidentes como la de informática forense y nos dirigimos a la sede de la empresa en Madrid para una primera toma de contacto.

La Empresa se toma la seguridad muy en serio: registran ambas mochilas, toman fotografías de todos los dispositivos y nos dan una tarjeta de identidad que por la pinta seguro que es capaz de hacer más de lo que parece. Cámaras de seguridad en todos los pasillos, y un ambiente totalmente profesional hasta que subimos a la planta noble, donde nos reunimos con María. Está visiblemente nerviosa, y viendo su traje parece que lleva más de un día en pie.

Dentro de las fases de la respuesta ante incidentes estaríamos todavía de la detección (sabemos que hay algo, pero todavía no conocemos el alcance de lo que está sucediendo). María nos cuenta que alguien está obteniendo información confidencial de la empresa, tan reservada que solo puede venir de los más altos cargos de la empresa: el director general, el director de operaciones, el director financiero, el director de ventas… o ella misma.

Tras firmar varios acuerdos de confidencialidad especialmente virulentos, empezamos nuestro trabajo con la aproximación más simple: un inside job, el clásico empleado descontento que ha robado la información. Pero al parecer todos los directivos son fanáticamente leales a la empresa e incluso su personal administrativo es de la mayor confianza, por lo que a priori podemos descartar esta teoría (en realidad no la descartamos, solo la guardamos para más tarde).

El espionaje clásico también queda excluido: la información robada no es algo que se pueda obtener poniendo un micrófono o “pinchando” un teléfono. Ha sido extraída de un ordenador.

La Empresa también se toma muy en serio la seguridad informática: seguridad en profundidad en toda la arquitectura, varios niveles de cortafuegos, antivirus actualizados, sistemas parcheados hasta la obsesión, acceso remoto por VPN, detectores de intrusos, contraseñas robustas cambiadas cada mes, etc. Uno de esos sitios en los que nunca se esperaría que sucediera nada, pero en el que aquí estamos trabajando.

Lo primero que hacemos es recoger información, toda la que seamos capaces de recopilar para proceder a su análisis y entender qué ha podido suceder. La Empresa tiene todo bien organizado, por lo que podemos hacernos con un paquete de datos completo: logs del proxy, de la pasarela de correo, de los antivirus, eventos de servidores y de las estaciones de trabajo y hasta de la VPN. El problema es que todos esos logs, si tomamos el acumulado de los últimos tres meses (el mínimo con el que empezamos), suman 200Gb de información. Comprimida.

Cogemos tres meses porque estamos empezando a sospechar que una APT (Advanced Persistent Threat) puede estar detrás de esto. Vamos, que alguien puede haber entrado hasta la cocina en la Empresa y se esté comiendo hasta los yogures caducados. El disponer de un histórico de datos nos permite detectar patrones y descartar falsos positivos, haciendo más eficaz nuestro trabajo.

Lo primero que hacemos es realizar un filtro inicial de la información, quedándonos con los equipos tanto de los directivos como de su personal de administración (diez en total), lo que reduce los registros a un poco menos de 20Gb de datos descomprimidos. A través de una serie de scripts normalizamos e importamos la información a una base de datos que nos permita realizar búsquedas y aplicar otros scripts que tenemos desarrollados.

Las primeras comprobaciones son casi rutinarias, pero hay que realizarlas: visitas a dominios infectados, eventos de la consola de antivirus, múltiples envíos de correos a direcciones no conocidas… serían signos que nos permitirían detectar rápidamente el equipo comprometido, pudiendo aislar la infección lo antes posible.

No hay suerte esta vez, aunque en realidad no esperábamos sacar nada en claro. Este incidente huele a algo avanzado desde el primer momento. Tenemos que pasar a la segunda fase: la detección de anomalías. Todos los sistemas (incluidos sus usuarios) siguen unos patrones de comportamiento, un conjunto de acciones y conexiones que pueden ser analizados para conformar un baseline o valor de referencia.

Ese baseline puede ser obtenido de los logs recuperados para hacer emerger todo lo raro, todo lo que no encaja: las anomalías. Es un trabajo complicado, porque la creación del baseline nunca es exacta, y abundan los falsos positivos (y además, nunca sabes si los “malos” han sido tan buenos como para esconder sus acciones tan bien como para que se hagan parte del baseline).

Al final es un trabajo minucioso, costoso y metódico que tiene que hacerse con sumo cuidado y atención al detalle para no dejarse nada. Es como buscar una aguja en un pajar, pero cuando el pajar es del tamaño de un campo de fútbol y no sabes siquiera que lo que quieres encontrar es una aguja.

Menos mal que, si llevas tiempo en el negocio, puedes tomar algunos atajos. Sabiendo cómo se comportan muchas amenazas es posible realizar una serie de modelos de ataque, conociendo qué tipo de anomalías generan en un sistema. De esta forma podemos buscar por esas miguitas de pan, esos indicios que nos permitan averiguar qué es lo que está sucediendo.

La cantidad de datos no es pequeña, así que tenemos algo de tiempo mientras nuestros programas trabajan. Un poco más de cafeína, una docena de correos y dos llamadas telefónicas más tarde, tenemos un listado de unas 30 anomalías.

Casi todas son falsos positivos, pero una de ellas salta a la vista: una petición POST a un nombre de dominio muy similar a un conocido periódico de tirada nacional (a partir de ahora www.period1co.es), tan similar que tan solo han cambiado una letra por otra casi idéntica. La petición en sí es bastante anodina, pareciendo la URL a primera vista el posteo de un comentario en una noticia.

Anomalía por partida doble. En primer lugar, ¿por qué tenemos un POST sin haber tenido antes ninguna comunicación con esa página web? Dentro de una comunicación HTTP el método POST es empleado para enviar datos a una página web, pero lo lógico es que antes hayamos descargado esa web, lo que suele conllevar un cierto trasiego de peticiones GET, que aquí a priori no existen.

En segundo lugar: ¿www.period1co.es? Lo buscamos en diversas páginas de reputación online y ninguna lo marca como malicioso, pero está claro que huele a chamusquina. Nos morimos de ganas por abrirlo en un navegador, pero no sabemos si los atacantes están vigilando los logs y los ponemos sobre aviso.

Mirando el lado positivo, tenemos ya dos hilos de los que tirar: el dominio supuestamente malicioso, y la IP origen de la petición, que resulta ser la del director de marketing de la Empresa.

Ahora podemos empezar a trabajar alrededor de estos indicios, lo que en la jerga conocemos como pivotar. Lo primero es ver más ocurrencias de ese dominio malicioso en todos los logs que tenemos recogidos, sean o no anómalos. Y el segundo paso sería analizar en detalle todo el tráfico de la IP 192.168.39.134, que parece ser a todas luces el equipo infectado.

La emoción de la caza es casi como una droga, así que mi jefe y yo miramos hipnotizados la pantalla mientras las herramientas hacen su trabajo. Diez angustiosamente largos minutos más tarde, tenemos resultados jugosos. Muy jugosos.

El equipo 192.168.39.134 ha realizado en los últimos dos meses 18 conexiones POST como la anterior a la URL www.period1co.es. Todas ellas en horario laboral, con unos tamaños bastante discretos (que hacen pensar a priori que la exfiltración de datos no se ha producido por esa vía) y a subpáginas del dominio con una estructura común (que podrían ser respondidas por un único script en el servidor y que ayudarían a que las URL variaran, haciendo más complicada su detección).

Y de forma adicional, tenemos 5 conexiones más al dominio desde dicha IP: