La seguridad de nuestra privacidad

Vivimos en un mundo “conectado” digitalmente, en el que se distinguen distintos tipos de habitantes, principalmente aquellos que lo vieron “nacer” y los que han nacido como “ciudadanos digitales”.

Pero bien sea en el caso de los primeros por la forma en que se han relacionado habitualmente entre ellos o, en el caso de los segundos por esa confianza infundada de ser nativos, la cuestión está en que en muchas ocasiones se expone lo privado, propio y ajeno, ante el público en general, sin ser conscientes de estar haciéndolo o, peor aún, con indiferencia por el riesgo que entraña.

En la “prehistoria digital”, la gente más abierta se juntaba en parques mientras los niños o las mascotas jugaban, en bares para tomar una copa y poder departir con otros tertulianos, en asociaciones ya fueran culturales o de otra índole y allí, en un foro controlado, compartían historias sobre hechos acaecidos propios o de la familia y amigos. Había una “exposición” pública de la privacidad, pero con un alcance, que normalmente no era un problema, más allá de que a partir de ese momento podía ponerse en marcha la maquinaria de los chismosos y cotillas y, salvo que la historia tuviese meollo, raro era que llegase a más de tres pueblos de distancia. No es que no se obviase ya la privacidad propia, o que no se estuviese faltando a la privacidad ajena sin permiso del interesado, pero digamos que los riesgos eran en cierta manera “controlados” por el propio límite físico de la comunicación.

En la actualidad y, con el auge de todo tipo de redes sociales, las cosas han cambiado y mucho. Se tiende a publicar, sin ni siquiera controlar el alcance con el que se hace, todo tipo de detalles propios. Y lo que es peor, se publica información que atañe a terceros sin una mera consulta previa para ver si el interesado está por la labor. Está claro que ese ansia de ser “reportero” de tabloide es algo innato a muchos humanos, que se afanan por crear toda una serie de noticias sociales, más o menos interesantes, sobre el resto de mortales y de aderezarlas con la correspondiente información propia para mejorar la “calidad” de sus publicaciones.

Pongamos por caso ese afable amigo que nos hace una foto en una cena del grupo de antiguos alumnos y que luego, sin más, la sube a su perfil de Facebook. Y no contento con ello, nos etiqueta en la misma para que todavía sea mayor la probabilidad de que no se pierda entre la jungla de posts que a diario se publican en la red. A ver, que sí, que uno es consciente de que le han hecho una foto. Y que posiblemente, hasta esté agradecido si la misma se la hacen llegar por correo electrónico para poder tener un recuerdo de la ocasión. Pero ¿en qué momento ha autorizado que se le exponga públicamente en la red?

Este tema de publicar fotos de ajenos para la contemplación pública es algo que, al menos yo, no había visto tan extendido como en la actualidad. Con la salvedad de aquellos casos, en que los “amigos” de una pareja se dedicaban a colgar fotos de la misma por los postes del pueblo, indicando que se casaban y otras lindezas. Sinceramente, creo que esto de “colgar” fotos ajenas parece una moda que se nos ha ido de las manos. Parece como, si con el auge de los dispositivos que incorporan una cámara digital, la facilidad de uso de la misma y el coste insignificante de obtener capturas, todo el mundo se hubiese infundido de cierto “espíritu Cartier-Bresson”.

Quizá es necesaria una nueva asignatura en las escuelas y colegios, una asignatura en donde se complemente la enseñanza del uso de las nuevas tecnologías, con la enseñanza de la responsabilidad que supone el uso de las mismas y la necesidad del respeto a uno mismos y a los demás. Quizá sea necesaria la expedición de un carnet de ciudadano digital, que nos reconozca el conocimiento de lo que tan sólo debiera de ser usar el sentido común, y que sin el cual, no se nos permita transitar por este mundo digital.

PFsense: firewall perimetral (V)

En este quinto capítulo sobre Pfsense (ver I, II, III y IV) se explicará la instalación y configuración de Snort, con el fin de incluir un NIDS en nuestro firewall.

Para instalar Snort en system > packages


Una vez instalado, en services > snort, se procede a su configuración:

-= Pestaña iface settings =-

Es donde se elige el lugar en el que Snort va a esnifar. wlan0 en caso de querer que actúe entre internet y la entrada del firewall, o ya si se quiere algo mas interno seria en opt1 para la DMZ o LAN para la red interna. En este caso para ver todo el tráfico hacia Internet lo mejor es elegir wlan0.

Respecto a la variable home_net y external_net se pueden dejar por defecto ya que home_net englobará a todas las direcciones IP internas y external_net a todas las que sean diferentes de home_net.

-= Pestaña WAN barnyard2 =-

Barnyard2 permite procesar los log de Snort e insertarlos en una base de datos externa:

En el apartado “MYSQL Database Output settings” es donde se configura el servidor MySQL externo, donde barnyard2 insertará los Log de Snort. Previamente en este servidor externo se debe crear la base de datos snort y dar permisos al usuario snort y a la dirección IP de Pfsense (192.168.1.2) para que pueda acceder a la bbdd:

mysql -u root -p

CREATE DATABASE  snort;

grant INSERT,SELECT,UPDATE,CREATE,DELETE,EXECUTE on snort.* to snort@192.168.1.2
Set password for snort@192.168.1.2=PASSWORD('snortpass');
flush privileges;

y posteriormente crear el esquema de esta base de datos (se puede descargar desde aquí):

mysql -D snort -u root -p < ./schemas/create_mysql

-= Pestaña Global Settings =-

Las reglas de detección del IDS tienen un papel importante y en este apartado es donde se configuran. Para incluir las reglas VRT se debe incluir un código, que se consigue al registrarse en la web de Snort.

Al registrarse envían un correo con el enlace para entrar logeado en la web de snort.org, luego en nuestro perfil conseguimos el oinkcode.

-= Pestaña updates =-

Por último en la pestaña updates se procede a la descarga de las reglas:


-= Pestaña Suppress =-

Al igual que en el fichero threshold.conf de Snort, es aquí donde se puede limitar las alertas, por origen, destino,o por el numero de coincidencias en un determinado tiempo. Veamos un ejemplo:

Se tiene primero que buscar el sig_id (identificador único de cada regla), para poder limitar las alertas (para el ejemplo “1852”):

  • No alertar cuando el origen sea 192.168.3.0/24.
  • No alertar cuando el destino sea 192.168.1.10 y 192.168.1.11:
    suppress gen_id 1, sig_id 1852, track by_src, ip [192.168.3.0/24] 
    suppress gen_id 1, sig_id 1852, track by_dst, ip [192.168.1.10,192.168.1.11]
  • Suprimir directamente toda la regla:
    suppress gen_id 1, sig_id 1852
  • Solo alertar de una de las alertas de la firma cada 3600 segundos:
    event_filter gen_id 1, sig_id 1852, type limit, track by_src,  count 1, seconds 3600
  • Suprimir cualquier regla para un origen concreto:
    suppress gen_id 1, sig_id 0, track by_src, ip [192.168.1.1]

Para mas información sobre las configuraciones, se puede visitar el siguiente link.

-= Pestaña Pass list y Blocked =-

En el caso de que Snort también funcione como IPS, es decir no solo alerte, sino que pueda bloquear, en estas dos pestañas se elige qué direcciones están exentas de bloqueo o cuáles bloquear. Por defecto las direcciones WAN, los gateway, servidores DNS, VPN, etc. están en la lista de no bloqueo.

Dentro de Services > snort > snort interfaces se edita (botón a la derecha con la letra “e”) en la pestaña WAN Categories:

Se pueden escoger qué reglas usar como se muestra en la imagen.

En la siguiente y última entrada de la serie sobre Pfsense veremos el tema de Squid como proxy HTTP. Espero que os haya parecido interesante.

INES: Informe Nacional del Estado de Seguridad

Desde este post quiero presentar un poco más en detalle a una de las amigas de mi compañero Toni: INES.

INES es el acrónimo de Informe Nacional del Estado de Seguridad, pero más que un informe, se trata de una plataforma telemática que proporciona a las Administraciones Públicas un conocimiento más rápido e intuitivo de su nivel de adecuación al Esquema Nacional de Seguridad. INES, junto con la Guía CCN-STIC 824, Informe del Estado de Seguridad [PDF] servirán para elaborar el Informe Nacional del Estado de Seguridad.

Tal y como se indica en el propio manual de la plataforma, el encargado de acceder a la plataforma es el “Responsable de Seguridad”, por lo que todas las Administraciones Públicas deberían tener nombrado al correspondiente Responsable de Seguridad, para poder realizar las gestiones en la plataforma. Esta frase daría para otro post: ¿tienen todas las Administraciones Públicas un Responsable de Seguridad que ejerza realmente como tal?

El objetivo de la plataforma es doble. Por un lado sirve para que cada Administración Pública tenga un “sitio” donde pueda ir albergando, validando y analizando la información de seguridad propia de su organismo y consolidada a nivel de Administración Pública. Por otro lado, la herramienta permite que el CCN tenga acceso a través de un repositorio común a toda la información que ponen a su disposición todas las Administraciones Públicas, con lo que se da cumplimiento al artículo 35 que señala: “El Comité Sectorial de Administración Electrónica articulará los procedimientos necesarios para conocer regularmente el estado de las principales variables de la seguridad en los sistemas de información a los que se refiere el presente real decreto, de forma que permita elaborar un perfil general del estado de la seguridad en las Administraciones públicas“.

En junio de 2014 el Observatorio de Administración Electrónica elaboró una nota técnica sobre el seguimiento de la adecuación a los Esquemas Nacionales de Seguridad (ENS) y de Interoperabilidad (ENI). En ésta destaca el esfuerzo notable que han hecho las AA.PP para adaptarse a dichos esquemas como suele decirse, “con la que está cayendo”. También se resalta que pese al carácter voluntario de la incorporación de los datos por parte de las AAPP, ha habido una buena respuesta, especialmente por parte de la Administración General del Estado, seguida de las Comunidades Autónomas, Diputaciones y Ayuntamientos.

Según el informe, las Administraciones Públicas que han ofrecido sus datos voluntariamente están bastante avanzados en los aspectos relacionados con protección de instalaciones e infraestructuras, la protección de datos de carácter personal, la identificación de personas, las copias de seguridad, la política de seguridad y la identificación de Responsables de Seguridad y Sistemas. A la vista de los resultados, donde más “pinchan” es en los aspectos relacionados con la concienciación y la formación. El informe insiste en que es esencial que haya un Plan de Adecuación, un Responsable de Seguridad nombrado, se haya realizado una Categorización de los Sistemas y que se realice un Análisis de Riesgos.

No podemos acabar este post sin hacer algunas referencias. La primera a CLARA, otra de las amigas de Toni. CLARA es una herramienta creada por el CCN para analizar las características de seguridad técnica definidas en el Esquema Nacional de Seguridad. Dicho análisis de cumplimiento está basado en las normas de seguridad que han sido proporcionadas a través de la aplicación de plantillas de seguridad, según las guías CCN-STIC de la serie 800: 850A, 850B, 851A y 851B. La segunda referencia es a PILAR, una vieja conocida en el sector de la seguridad, que incorpora desde hace tiempo soporte para el ENS y mediante la que es posible realizar la valoración del cumplimiento de cada medida del Anexo II del ENS.

Acabaré diciendo que espero que el proyecto de modificación del ENS, cuya admisión de comentarios se cerró el pasado lunes 9 de febrero, no contradiga mucho de lo que he escrito. Si así fuese, me comprometo a explicar los cambios en un futuro post.

RAM Scraping en TPV’s

¿Qué es el RAM Scraping?

RAM Scraping es una técnica utilizada por cierto tipo de malware que permite leer directamente de la memoria principal, consiguiendo así acceso a información potencialmente sensible. Esta técnica es actualmente empleada para realizar ataques contra los conocidos como TPV (Terminal Punto de Venta) y tiene como objetivo el robo de información de las tarjetas de crédito asociadas a las ventas que gestiona dicho TPV.

Desde las primeras detecciones en 2009, el número de ataques de este tipo ha aumentando notablemente, siendo los Estados Unidos el país que presenta el mayor número de afectados. Quizás los casos más llamativos sean los ocurridos entre 2013 y 2014 sobre las conocidas cadenas de venta norteamericanas ‘Home Depot‘ y ‘Target‘, de cuyos sistemas se estima que se extrajeron alrededor de 150 millones de números de tarjeta en total.

[Read more…]

Cómo proteger la información en tránsito

Para hoy tenemos una entrada de Toni Grimaltos, Licenciado en Informática e integrante del Servicio de seguridad de la información DGTI de la Generalitat Valenciana.

Pocas veces una organización de la envergadura de un gobierno autonómico hace un cambio de la magnitud que supone trasladar de sede a 2500 trabajadores de diferentes organismos. En este artículo vamos a abordar la problemática de trasladar los sistemas de información y el Sistema de Gestión de la Seguridad de la Información (SGSI) de uno de los organismos implicados en ese traslado, y seguir cumpliendo con los controles que la norma ISO 27002 establece, todo ello sin vulnerar ningún artículo de la Ley Orgánica de Protección de Datos (LOPD).

Lo primero que necesitamos para que esta acción tenga éxito, es la “IMPLICACIÓN DE LA DIRECCIÓN”. Ahora bien, este ideal, ¿cómo lo traducimos a una serie de acciones reales?

[Read more…]

Tómate un respiro, tómate un Kit Kat

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…]

Zen y el arte de pescar APTs (IV)

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 … :)

LINE. Android e iOS. Análisis técnico de la mensajería instantánea.

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:

1. Un Emisor escribe un mensaje y lo envía.

2. Los Servidores de LINE lo reciben y le asignan un identificador único de mensaje (server_id) y una fecha de recepción (created_time).

3. Los servidores envían a Emisor server_id y created_time.

4. Los servidores envían a Receptor el mensaje, server_id y created_time.

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

1. El sistema de archivos que utiliza LINE. En este apartado, se analiza el directorio de instalación, dónde se encuentran las bases de datos, dónde se almacenan los ficheros multimedia enviados/recibidos así como las fotos de perfil de los contactos…

2. Análisis de las bases de datos (donde se almacenan los mensajes).

  • Análisis relacional: Relación entre tablas usando sus registros.
  • Análisis de los registros: Saber qué almacena cada columna de cada tabla de la base de datos.

3. Análisis forense.

  • Ficheros de configuración: Obtención de más información, como el nombre de usuario y la foto de perfil.
  • Bases de datos: Se analiza cómo es la estructura de los mensajes una vez almacenados mediante un editor hexadecimal.

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.

Evadiendo por la via rápida el challenge de CloudFlare for-fun-and-profit

Para hoy tenemos una entrada de Vicente, un antiguo compañero de S2 Grupo, administrador de sistemas y fanático de la naturaleza. Se le puede encontrar en su twitter @vicendominguez y en su blog.

¡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…]

Zen y el arte de pescar APTs (III)

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…