Security Art Work

El problema

El pasado 13 de Abril de 2015 el US-CERT publicaba una alerta informando de que “Las peticiones AXFR podrían filtrar información referente a los servidores de dominio“. La comunidad cuando menos se rascó la cabeza pensando en qué estaba pensando el US-CERT. De hecho, este comportamiento fue reportado ya en 1997 por el NIST.

Las peticiones AXFR a servidores de nombres permiten replicar bases de datos DNS entre distintos servidores DNS. Las entidades por lo general tienen al menos dos servidores DNS (un primario y un secundario) que les permiten seguir disponiendo de servicio de nombres en caso de que el primario caiga. Por esta razón es importante que todos los servidores de nombres de una organización estén sincronizados. Esta sincronización se consigue mediante las peticiones XFR. Existen dos tipos de peticiones XFR, la incremental (IXFR) y la completa (AXFR), que envía al secundario toda la información de DNS local (lo que se conoce como la zona) que tiene el servidor primario. A este proceso se le conoce como “Transferencia de Zona“.

[Read more…]

Cuando se habla de un delito informático, se tiende a pensar en una persona al otro extremo de la red con altos conocimientos técnicos que está intentando lucrarse ilícitamente. Pero lo cierto es que detrás de estos delitos no suele haber una única persona, sino organizaciones complejas con diferentes roles y actores que gestionan, administran y ejecutan sus acciones.

El fraude a través de la red ha tenido una gran evolución, lo que ha ocasionado una sofisticación mayor en la manera de cometer los ciberdelitos utilizando infraestructuras cada vez más complejas. Este aumento en el grado de complejidad implica que los propios delincuentes no pueden abarcar todo el funcionamiento y métodos de ataque sobre una infraestructura u organización.

Al igual que hay en el mundo mercantil desarrollo de software, operaciones de compra/venta, colaboraciones, rivalidades, etc., lo mismo ocurre en el mundo mercantil “negro” de forma paralela. Sin embargo, en esta ocasión hablamos de desarrollo de exploits, compra/venta de exploits y vulnerabilidades, colaboraciones entre organizaciones criminales, etc. De la misma forma, existe una segregación de tareas definida en la que podemos identificar varios roles claramente, en función de la tarea que realizan en la cadena criminal.

[Read more…]

Hace unas semanas un amigo me comentaba que, tras un incidente en el servidor en la nube que tenía contratado (servidor que utilizaba entre otras cosas como almacén para toda la documentación relacionada con su tesis doctoral), había perdido la totalidad de la información y se veía obligado a realizar el trabajo de nuevo. Mi primera frase fue “¿No tenías copia de seguridad…?”, creo que tratando de dejar a un lado la sensación de incredulidad que me había producido la noticia. No me había sorprendido que un servidor en la nube fallase, era que una vez más se cumplía el dicho, “En casa de herrero cuchillo de palo”.

Dicen que hay dos tipos de motoristas, los que se han caído y los que se van a caer. Esta frase, que he oído múltiples ocasiones, normalmente tras enterarme de algún accidente de algún conocido aficionado del motor sobre dos ruedas, es una frase que puede ser trasladada sin más a los sistemas de almacenamiento. Están aquellos sistemas que han fallado y los que van a fallar.

Haciendo memoria recordé otras ocasiones en las que amigos, o conocidos, se lamentaban de pérdidas de datos debidas, según ellos, a incidentes con los equipos o, incluso, por la falta de previsión del fabricante de los mismos.

Un caso, en el que precisamente el incidente se achacaba a la falta de previsión del fabricante del equipo, fue el de un amigo que decidió que había llegado el momento de hacer una instalación a estado de fábrica del ordenador familiar. Lamentablemente, no debió entender (ni leyó las advertencias) que ello implicaba que, tras la operación, el equipo quedaría tal como lo había adquirido y que, pese a su previsión de haber reorganizado el espacio en el disco duro para no tener los datos en la misma partición que el sistema operativo e incluso contar con una copia de seguridad de los datos realizada seis meses antes, las fotos familiares que guardaba en el mismo de la reciente celebración del primer cumpleaños de su retoño no era algo que el fabricante incluyese de serie. Todavía recuerdo su cara mientras se hacía a la idea de cómo contarle a su pareja que no había fotos. ¡Ah! En esta ocasión volvía a cumplirse el dicho de “En casa de herrero…”.

Los anteriores son dos casos en los que personas con conocimientos sobrados en cuanto a sistemas de información, han perdido datos que en teoría, les eran importantes. Y no siempre ha sido por fallos de sistema. No saquemos conclusiones demasiado temprano, no siempre se trata de herreros.

Cuando uno lleva suficiente tiempo en el negocio, tiene oportunidad de encontrar situaciones de casi cualquier índole. En cierta ocasión, un conocido de uno de los socios de la firma en la que yo desempeñaba mi labor profesional, solicitó que acudiésemos a salvar el mundo. ¿Recordamos el dicho de los motoristas? En esta ocasión, una vez más un sistema había sufrido un percance, el disco duro tenía un fallo mecánico y el directivo nos indicaba la importancia de recuperar la información almacenada en el mismo. Dejaré a un lado todo lo que supuso conseguir que el sistema quedase funcionando de nuevo. Llegado el momento de recuperar los datos, tras haber observado que disponían de un dispositivo para la realización de copias de respaldo, e incluso cintas seriadas y un documento con la planificación de rotación que le había proporcionado su anterior proveedor de servicios, resultó que no se realizaba el proceso de copias de seguridad. ¿Por qué? Pues es algo que aún no he logrado entender.

Una de las frases que uno puede escuchar cuando se encuentra en reuniones de padres es la necesidad de dejar que los hijos tropiecen, para que de esa manera aprendan por la experiencia sufrida. También está quién es de la opinión de que si se puede aprender por las vivencias de otros, no es necesario caer para aprender.

Por mi parte yo sigo intentando, en las distintas esferas de relaciones que me rodean, que las vivencias ajenas sirvan de algo más que de anécdotas. No creo que sea preciso llegar a la histeria, ni tomar las cosas por la tremenda. No es preciso que habiendo acabado de leer este artículo tengamos que hacer un pedido de dispositivos de almacenamiento que colme de alegría y beneficios a los fabricantes y distribuidores de los mismos, tan sólo dediquemos un par de minutos a considerar si hay algún dato o información que realmente consideremos importante y qué sensación nos produce saber en qué condiciones lo tenemos archivado.

Estoy seguro de que los tropiezos de los tres casos anteriores motivaron a sus protagonistas un aprendizaje, pero también está el dicho “El hombre es el único animal que tropieza dos veces con la misma piedra”. Espero que éste no se cumpla y que en mi interior no tenga que volver a pensar “No era tan importante…”.

Últimamente se están identificando numerosas campañas de correos maliciosos con ficheros adjuntos; en especial, con variantes de Cryptolocker o CTB-Locker y demás tipo de ransomware.

En la mayoría de casos se trataba de un archivo ejecutable, con extensión .EXE, directamente incluido en un archivo comprimido ZIP sin contraseña. Entre tanto ejecutable, hace unos días llegó un correo diferente que no contenía un ejecutable sino un archivo VBS. En realidad, se trataba de un archivo con doble extensión (algo muy habitual para engañar al usuario y hacerse pasar por un archivo XLS, en este caso).

El correo venía con el asunto “This is your Remittance Advice [ID:92251]” y un archivo adjunto con el nombre VW3840QVDZ.zip, que contenía un supuesto archivo de hoja de cálculo:

5104afe7f36cd6ba8d0ad13848d1b38c963fbb42ea51532c3b01e21805971c72 VW3840QVDZ.zip
f19315d0757362859022e40d7d64a46d5a50227e35d1e10f3c1c7731821ec8ac 8323241AZ#632463.xls.vbs

Evidentemente, este último archivo no se trata de un archivo de Excel, sino un script en Visual Basic con el siguiente contenido:

Se trata de código ofuscado utilizando la función chrw, que convierte números enteros en caracteres, para no mostrar el código original. Además, el entero lo representa como suma de dos números. Al final del código vemos una función que ejecuta el anterior código almacenado en la variable nt:

Desde el punto de vista de un Blue Team, debemos identificar qué realiza este código para tratar de contener el posible incidente de seguridad sin ejecutar el código. Al tratarse de código VisualBasic script, podemos modificar el código para llamar a una función que muestre el contenido de la variable nt, como imprimirla por pantalla o en un archivo, en lugar de ejecutarla. Para esto, vamos a sustituir la última línea por otro código que escriba el valor de nt en un archivo de texto de la siguiente manera:

De esa forma mostramos el código ejecutado por el código en el archivo script.txt, donde vemos que se trata de un dropper de otro archivo sospechoso descargado desde un servidor ubicado en Rusia:

Vemos que el código se trata de una llamada a powershell.exe, para descargarse el recurso casma.gif, descomprimirlo y ejecutarlo. Aquí tenemos el primer elemento de contención: bloquear la dirección IP del servidor desde el que nos descargamos este archivo sospechoso.

Tras conseguir el archivo desde un origen diferente al atacado, podemos analizar el ejecutable.

El archivo parece comunicarse con el servidor 188.120.225.17, también ubicado en Rusia, al que posiblemente le envíe información a través de peticiones POST y otros servidores repartidos por varios países, por lo que tenemos un gran número de direcciones IP a bloquear y contener el posible incidente antes de que se materialice.

Conclusiones

Entre las medidas que tomamos para la contención, hay que bloquear la dirección IP desde la que el dropper descarga el malware para evitar que los usuarios puedan verse comprometidos.
También hay que bloquear la dirección IP <188.120.225.17> para evitar que el malware se comunique con el que es supuestamente el servidor de control o donde se envía la información capturada.

Por último, entre las lecciones aprendidas para evitar que ocurra un incidente similar se encuentra la formación y concienciación al usuario final para no abrir correos sospechosos ni sus adjuntos. No obstante, a nivel técnico tiene una solución bastante sencilla, como bloquear los correos que contengan adjuntos en formato ejecutable (EXE, BAT, VBS, SCR y demás archivos ejecutables).

En octubre de 2013, hace poco más de un año y medio, se publicaba la nueva versión de la ISO/IEC 27001:2013.

Mucha era la expectación que se había creado en torno a esta nueva versión y los análisis empezaban a inundar las páginas web del sector y los grupos de LinkedIn. A los pocos días de la publicación en inglés de la norma, publicamos un exhaustivo análisis sobre los cambios que a priori se esbozaban del estándar.

La traducción al castellano, UNE-ISO/IEC 27001:2014, llegó más de un año más tarde, dejando poco margen a las organizaciones que habían estado esperando a la norma en castellano para su adaptación. Recordemos que el plazo que daban desde ISO (International Organization for Standardization) era de dos años desde su publicación en octubre de 2013. Esta situación habrá supuesto un reto para muchas organizaciones.

[Read more…]

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

En la entrega anterior (ver parte I, parte II, parte III, parte IV y parte V) teníamos el caso a punto de caramelo: habíamos relacionado (inicialmente al menos) a R.G. y a S.P.F. con dos terminales que habían estado implicados en el asesinato.

La última localización del segundo terminal lo situaba en la E-5 (una de las carreteras que conectan La Moraleja con Madrid). Desafortunadamente, en esa zona la densidad de las celdas no es tan alta como en el centro de Madrid, así que la localización es mucho menos precisa, pudiendo estar en el orden de los centenares de metros.

Nos queda el primer terminal, que parece estar perfectamente localizado. Las FFCCSSE van a casa de la hermana de S.P.F. con una orden judicial y obtienen el terminal móvil de su hija Ainara (regalo de su tía Samantha el día después de autos), y le hacen un volcado de sistema de ficheros con el Cellebrite UFED (sigue siendo un iPhone 5, por lo que no podemos hacerle un volcado físico).

Revisamos ávidamente los sospechosos habituales: SMS, llamadas, correo, Whatsapp… sin encontrar nada sospechoso. Es más, se puede apreciar que hay poco contenido en el teléfono (aunque el significado de poco es relativo para un teléfono de una quinceañera), lo que nos hace sospechar que el teléfono ha sido devuelto a los valores de fábrica.

Si nos fijamos en algunos timestamps de los ficheros podemos ver que han sido creados el día después de autos, lo que confirma que el teléfono ha sido borrado. Sin embargo, nosotros sabemos que un borrado muchas veces no es para siempre. Si pudiéramos obtener una copia física del dispositivo…

Dos minutos más tarde, nuestros deseos se hacen realidad: revisando el listado de apps instaladas encontramos una que nos alegra el día: Cydia, el market de apps de terceros para Apple. Cydia tiene una característica muy interesante: solo se puede instalar en terminales que hayan pasado por un proceso de jailbreak previo.

Ergo, si tiene Cydia tiene un jailbreak le podemos hacer un volcado físico, si tenemos una licencia de ElcomSoft iOS Forensic Toolkit). Los dioses nos sonríen y poco más tarde tenemos un precioso volcado físico del iPhone5 de marras. Lo primero que nos pide el cuerpo es verificar cuándo ha sido devuelto a valores de fábrica: para ello podemos comprobar el valor del fichero /root/.obliterated, cuyo timestamp marca la fecha del último reseteo. En nuestro caso, coincide con el día después de autos.

Una vez satisfecha nuestra curiosidad (y apuntado en el informe la intencionalidad del borrado de datos), vamos a intentar recuperar información borrada de la imagen física del iPhone. Los iPhone tienen como formato de sistema de ficheros HFS+, que es perfectamente aceptado por TestDisk.

Sin embargo, hoy no es su día así que necesitamos probar suerte con otra herramienta. Rebuscando un poco en Google encontramos HFSprescue, que parece funcionar a la perfección y en menos de media hora nos ofrece una buena cantidad de archivos borrados.

En realidad solo hace falta un fichero: el ChatStorage.sqlite para tener acceso a los mensajes de Whatsapp enviados y recibidos. Y el contenido, aparte de no ser para menores de edad, lo dice todo: conversaciones entre R.G. y S.P.F. más que subidas de tono, así como el odio manifiesto de S.P.F. hacia A.P. y el desprecio de R.G. hacia su mujer.

Con estas evidencias en la mano, las FFCCSSE tienen el caso envuelto en papel de regalo. Cuando se confronta a S.P.F. y se le enseña el listado de Whatsapp de su antiguo terminal se desmorona por completo y nos cuenta toda la verdad. Según su confesión esto es lo que sucedió:

• R.G y S.P.F. eran amantes desde hace más de un año. R.G. no podía soportar a su mujer, pero sabía que no podía divorciarse de ella (haría todo lo imposible por arrebatarle su fortuna y arruinarle la vida). Es por ello por lo que plantearon asesinarla.
• Compraron dos teléfonos móviles en efectivo, iguales que sus móviles personales para que nadie sospechara si los viese con ellos. Las SIM las adquirió S.P.F. en un locutorio de Lavapies (Madrid).
• Unos días antes, R.G. borra los portátiles de ambos y los reinstalan (en los móviles “oficiales” no hacen nada porque toda su relación está en los terceros terminales).
• El día de autos, R.G. sale con su coche de La Moraleja y va a su casa. Se asegura de ser grabado por las cámaras y hasta de dejar el coche mal aparcado para que lo multen. Una vez en su casa, se conecta a la wifi de S.P.F. y le da su contraseña de usuario para que simule de vez en cuando actividad en el portátil.
• A las 00.00h sale de casa de S.P.F. y coge la moto de S.P.F. y se dirige a La Moraleja. Esquiva las cámaras de seguridad (ha estudiado perfectamente dónde está cada una de ellas), salta la verja y entra por una ventana de la cocina que no tiene alarma.
• Va al despacho, hace ruido para despertar a su mujer y cuando ella entra la apuñala en el pecho con un cuchillo. Deja movido el cuadro de la caja fuerte y le hace unos arañazos a la cerradura para simular su intento de forzado y sale por donde ha entrado.
• Una vez camino de vuelta a Madrid destruye a pedradas el móvil, rompe la SIM y tira ambos en un descampado en un lado de la carretera. Unos cientos de metros más tarde tira el cuchillo y los guantes en una acequia.
• Vuelve a casa de S.P.F, se ducha concienzudamente para eliminar cualquier rastro de sangre y coge el coche para volver a su casa.

El plan está sin duda muy bien definido y ejecutado prácticamente a la perfección. Casi a la perfección. Sin embargo, R.G. se creyó demasiado listo, y cometió errores. El no mantener la OPSEC (seguridad operacional) a lo largo de toda la cadena de la ejecución del crimen hizo que S.P.F. regalara su iPhone 5 a su sobrina, permitiéndonos tirar del hilo y descubrir todo el pastel.

El juicio duró buena parte de un año y terminó con ambos en la cárcel, pero nosotros ya habíamos hecho nuestro trabajo y teníamos cosas mejores que hacer con nuestro tiempo (hay muchas páginas de seguridad interesantes, y no se van a aprender solas).

Moraleja: No cometas crímenes, porque no solo los de CSI son capaces de hacer maravillas…

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

La entrada anterior (ver parte I, parte II, parte III y parte IV) había dejado la investigación en un punto clave: logramos acceder a la cuenta de iCloud de S.P.F, y ahora teníamos que ver si podíamos sacar algo de sus copias de seguridad (recordemos que el MacBook había sido sospechosamente reinstalado). La pantalla de entrada es algo similar a esta:

En función de lo que S.P.F. haya habilitado tanto en su iPhone como en su MacBook podremos recuperar más o menos información. Lo primero es verificar qué dispositivos están conectados a la cuenta de iCloud, por lo que accedemos a Settings -> Devices.

Un MacBook Pro, un iPhone 5, otro iPhone 5… ¡¿qué?! Ojipláticos comprobamos que al parecer tenemos un iPhone “extra” dentro de esta cuenta de iCloud. Vamos a obtener algo más de información pulsando sobre el dispositivo (la foto siguiente es un ejemplo de lo que aparecería).

Como podemos ver tenemos tanto la última fecha de copia de seguridad (en este caso, nunca), así como el número de serie y el IMEI (International Mobile System Equipment Identity), que nos van a servir para identificar de forma unívoca ese terminal esté donde esté.

El paso siguiente es obvio: vamos a ver dónde está ese terminal vía Find my iPhone. Solo nos muestra el primer teléfono de S.P.F, ni rastro de este segundo terminal. Si accedemos al resto de opciones de iCloud no encontramos nada digno de mención aparte de una copia de seguridad de miles de fotos (Instagram es lo que tiene).

Parece ser que ese teléfono se conectó a iCloud pero luego no se ha activado ninguna funcionalidad de copia de seguridad. Y si la funcionalidad de encontrarlo no está operativa lo único que se nos ocurre es que o bien el teléfono esté apagado o que ya no esté conectado a esa cuenta de iCloud (no lo podemos confirmar pero no creemos que un mismo terminal pueda estar conectado a dos cuentas de iCloud a la vez). La información del nuevo terminal es vital para la investigación, así que se la facilitamos a las FFCCSSE para que (siempre con orden judicial) soliciten los datos de llamadas y posicionamiento del terminal, mientras esperamos mordiéndonos las uñas y tomando más café del que deberíamos (es decir, mucho).

Los resultados nos aclaran algunas dudas y nos generan otras. Por si no lo sabéis, cuando se emite una orden de obtención de datos a partir de un IMEI, la operadora facilita los datos de la SIM que está conectada al mismo… y de otras SIM que hayan estado conectadas al terminal en el plazo temporal requerido en la orden.

El terminal ha tenido dos SIM conectadas, cada una con un patrón de uso diferente:

a) SIM1 (conectada hasta el día después de autos).

• Titular: Abdul Alhazred.
• Patrón de llamadas: Varias llamadas diarias al móvil X, casi no hay llamadas a otros números.
• Patrón de localizaciones: Barrio de Chamberí, centro de Madrid, sede central de Armand & Old.

b) SIM2 (conectada a partir del día después de autos).

• Titular: Vanessa Pérez Fuencarral.
• Patrón de llamadas: Pocas llamadas a unos 20 números de teléfono.
• Patrón de localizaciones: Barrio de Salamanca, centro de Madrid, colegio privado XXX.

Oro en lingotes como para hacerle una casita al perro. Cuesta poco obtener las siguientes conclusiones:

• La SIM1, por su patrón de comportamiento, pertenece o bien a S.P.F. o a un señor árabe que está en todo momento junto a ella (y no creemos que sea tan amigo como para que lo dejen entrar en su casa y en su trabajo).
• La SIM2 tiene como titular a V.P.F, que no es más que la hermana de S.P.F. Ella es un poco mayor para ir a un colegio privado, pero es muy posible que tenga hijas que sí que puedan hacerlo (¿y qué adolescente no querría un iPhone5?)

El terminal cambió de SIM1 a SIM2 el día después del asesinato. ¿Alguien se está deshaciendo de pruebas? Y sobre todo… ¿dónde está el móvil X? Una nueva orden judicial (con el juez ya un poco calentito al respecto) deshace el entuerto y nos da información sobre el terminal X:

c) SIM3 (conectada hasta el día de autos)

• Titular: Eduardo Tobías Jiménez Mejido.
• Patrón de llamadas: Varias llamadas a la SIM1, casi no hay llamadas a otros números.
• Patrón de localizaciones: La Moraleja, centro de Madrid, sede central de Armand & Old.

Este último patrón de localizaciones concuerda a la perfección con el de R.G, pero con un añadido: A eso de las 00.00h el terminal sale de la casa de Chamberí, se desplaza hasta la casa de R.G. en La Moraleja, permanece allí como 20min, empieza a moverse hacia el centro de Madrid… y desaparece sin dejar más rastro en la operadora.

Las FFCCSSE lo tienen bastante claro: las SIM han sido adquiridas en algún locutorio (recordad que desde hace años no se puede obtener un nuevo número de teléfono sin que tenga unos datos personales asociados al mismo) y los terminales han sido comprados en el mismo lugar, o mediante efectivo para no dejar huellas. Los patrones de localización cuentan una historia bien fácil de leer, situando ese terminal en la escena del crimen y relacionándolo con S.P.F.

Las evidencias parecen bastante claras, pero dado lo mediático del caso las FFCCSSE quieren un caso sólido y sin ningún resquicio, por lo que vamos a tener que recuperar esos dos terminales. La resolución del caso, en la próxima entrega…