Blog de Seguridad de la Información de S2 Grupo
Quien más, quien menos ha leído acerca de XCodeGhost. Una reciente bomba informativa que se ha vertido a los medios de comunicación como “App Store Hackeada”, dando a entender que el servicio de compra y descarga de aplicaciones había sido hackeado.
Espera, espera, espera…
¿Han oído hablar de la nueva normativa europea sobre la protección de datos de carácter personal? Seguramente sí, pero probablemente tengan una imagen difusa sobre el estado de la misma. Al menos, esa es la impresión que yo tengo como interesado en la materia. En cierto modo es como si estuviéramos recibiendo información con cuentagotas: pequeños avances, breves fragmentos del tráiler de una superproducción Hollywodiense Europea que marcará un antes y un después. ¿Creéis que será para tanto?
Dado este escenario, hemos considerado oportuno dedicar el presente artículo a la nueva normativa europea, comentando los cambios más significativos, con la intención de establecer un punto de situación, que ayude a nuestros lectores poner en contexto las noticias que lean sobre el tema y permita aclarar algunas cuestiones al respecto.
(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).
b) SIM2 (conectada a partir del día después de autos).
Oro en lingotes como para hacerle una casita al perro. Cuesta poco obtener las siguientes conclusiones:
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)
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…
(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.)
Según lo visto en la entrada anterior (ver parte I, parte II y parte III), teníamos a nuestra disposición las siguientes evidencias digitales:
La situación es casi la misma que en el caso de R.G, solo que con un portátil de Apple en lugar de uno de HP. El tratamiento de los móviles va a ser exactamente el mismo, así que nos ponemos rápidamente al lío.
WAF (Web Application Firewall) es un elemento de protección frente a ataques que se encarga de analizar el tráfico web dirigido a los distintos portales que pueda disponer una organización. Este tipo de firewalls se diferencia del resto en que procesa el tráfico HTTP(s) a nivel de la capa 7 de la pila OSI y por lo tanto permite capacitarlo de reglas de detección directamente sobre las tecnologías con las que estén diseñados y desarrollados los sitios web. Además, podemos diferenciar este tipo de dispositivos de lo que denominamos un IPS por las características de identificación de patrones anómalos.
Normalmente pueden operar en 3 modos:
Si se emplea el modo negativo exclusivamente, éste puede provocar una cantidad mayor de falsos positivos, además de sufrir un retardo mayor en el tiempo de procesamiento y en definitiva menor protección. En el lado positivo, tiene un menor tiempo de implementación.
(La entrada de hoy corre a cargo de Mª José Montes)
Dentro de poco menos de tres semanas, se celebrará el primer congreso de Seguridad Informática de Córdoba, QurtubaCon.
Hasta ahora, en Córdoba, se venían celebrando dos eventos periódicos, que son Hack&Beer y HackLab. Dada la buena acogida de estos eventos y, con la ilusión de poder reunir a grandes figuras del sector de la seguridad, se gesta este congreso, organizado por la Comisión de Eventos de la Asociación Nacional de Profesionales del Hacking Ético (ANPhacket), lo forman Miguel Arroyo, Eduardo Sánchez, Enrique Palacios y una servidora, entre otros.
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.
Nota del editor: mañana por la mañana, nuestro compañero Antonio Sanz estará hablando sobre el malware del que trata el presente post, y la gestión del incidente asociado a la detección del mismo, en las VIII Jornadas STIC del CCN-CERT.
El pasado mes de agosto, varios empleados (bastante bien escogidos) de uno de nuestros clientes (una empresa estratégica), recibieron una serie de mensajes un tanto “sospechosos”, que referían el entonces relativamente reciente accidente del avión de Malaysia Airlines, sobre cuya investigación no paraban de llegar noticias.
Al abrir el documento, que en principio tenía extensión .doc, aparecía efectivamente una especie de “comunicado”, o similar, sobre el accidente en cuestión.
Sin embargo, un análisis básico revelaba que el fichero era en realidad un RTF (y no un DOC), y que venía con regalo: nuestro viejo amigo, el exploit CVE-2012-0158. Como los hashes del fichero todavía no tenían presencia pública en los servicios habituales (VirusTotal, Malwr.com, etc. obviamente, tampoco el AV corporativo lo detectaba), y dado el caracter de los destinatarios de los mensajes, pensamos que no vendría mal “jugar” un poco más con el artefacto, y lo pusimos a macerar en nuestra sandbox.
Tras unos 12 minutos (!) de espera, el especímen por fin intentó contactar con algo, y, para nuestra sorpresa, ese algo no era sino un proveedor público de servicios WebDAV. Así que el bicho utilizaba ese protocolo sobre HTTP (y no sobre HTTPS en principio), sea lo que fuera lo que pretendiera recibir o transmitir con ayuda del mismo…
Efectivamente, simulando en nuestro laboratorio el servidor WebDAV al cuál estaba intentando llegar, el especímen trataba en primer lugar de descargar información desde una determinada ruta del WebDAV, y a continuación, dejaba ficheros con nombres pseudoaleatorios, pero extensiones conocidas, sobre otra ruta.
Tras explotar, el adjunto RTF malicioso se sustituía a sí mismo por un documento “limpio” (el del comunicado sobre el accidente) que llevaba empotrado (de forma que si analizabas el documento droppeado por separado, no había forma de reparar en la existencia del exploit o del resto del malware), y lo abría con el Word, simulando perfectamente la apertura habitual de un fichero DOC.
Sin embargo, por debajo estaba droppeando y ejecutando un fichero .vbs, que a su vez droppeaba una DLL que llevaba empotrada en su propio código fuente, codificada en hexadecimal.
Esta DLL (droppeada directamente sobre %SystemRoot% si el usuario disponía de los privilegios necesarios, o sobre el perfil del usuario en caso contrario) se cargaba utilizando el comando de Windows regsvr32, persistiendo a través de una invocación del mismo sobre la habitual rama del registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run. En el caso de este adjunto, la clave se escribía con el nombre Barbicas.
Profundizando sobre el análisis dinámico de la DLL (el análisis estático no arrojaba mucha más información), observamos la presencia de un packer, que para unpackear a su huésped lleva a cabo gran cantidad de operaciones intensivas en CPU (durante el proceso de unpacking, que dura varios minutos, una de las CPU del equipo víctima se mantiene al 100% de utilización). El packer desofusca el código del malware sobre nuevas páginas del mapa de memoria del proceso y pasa a ejecutarlo (direcciones 0x7FF40000 y 0x7FF80000 en la captura de muestra).
En la memoria del proceso puede encontrarse la URL del servidor WebDAV, así como el nombre de usuario y contraseña para acceder al mismo, la ruta de bajada y subida desde y hacia el servidor, y las extensiones de los ficheros que se suben al mismo.
Una vez unpackeada con técnicas estándar, fue posible dumpear la DLL (reconstruyendo su Import Table) para pasar a analizar estáticamente en más profundidad el código desofuscado. Lo primero que nos llamó la atención fue la presencia de las tablas de inicialización del algoritmo AES en la sección de datos de la DLL.
En efecto, el malware utilizaría el algoritmo de cifrado AES en modo CBC.
La clave utilizada tiene una longitud de 256 bits, estando hardcodeada en el código del ejemplar.
En efecto, el tamaño de los ficheros cifrados siempre es múltiplo de 16 bytes, el tamaño de bloque del AES, y el fichero cifrado incluye el vector de inicialización del modo de cifrado en bloques (como se desprende de los parámetros utilizados en las llamadas a las rutinas de cifrado y descifrado observadas durante el análisis dinámico que llevamos a cabo), añadiendo otros 16 bytes extra al tamaño de los ficheros.
Por lo tanto, hasta el momento teníamos un malware no público, capaz de conectarse a un servidor WebDAV (un protocolo cuanto menos original en lo que respecta a campañas sobre las que se tenga constancia) de Internet utilizando una cuenta (usuario y contraseña) hardcodeada en el código, y capaz tanto de obtener información cifrada con AES (estando la clave de 256 bits también hardcodeada) desde una ruta de esta cuenta del WebDAV para recibir instrucciones (canal de comando y control), como de cifrar y almacenar información hacia otra ruta de la cuenta del servidor WebDAV (canal de exfiltración).
Pero las sorpresas aún no habían acabado; tras analizar los demás ficheros adjuntos (recordemos que varios usuarios recibieron mensajes maliciosos), resulta que cada uno era diferente:
Queda claro por lo tanto que lo que observamos fue probablemente una posible campaña, utilizando malware desconocido hasta el momento y seleccionando a las víctimas de un modo altamente dirigido.
Los atacantes emplearon alguna clase de generador de especímenes; una vez un ejemplar es generado, identifica unívocamente a la víctima, así como su información exfiltrada en el WebDAV, al utilizar cuentas, directorios, extensiones de fichero y claves AES diferentes en cada mutación. Además, queda claro que esto se trataba muy seguramente de la primera fase en lo que podría haber sido una persistencia más duradera en la organización víctima.
¿Qué habríamos encontrado tras unas cuantas semanas, o meses, de compromiso?
Actualización: en 8 de diciembre de 2014, Symantec (re)bautiza el malware del que les hemos hablado (o al menos alguna de sus mutaciones) como Infostealer.Rodagose (Number of infections: 0 – 49, Number of Sites: 0 – 2).
Seguimos prefiriendo el nombre Barbicas :-) Han pasado más de 4 meses desde que observamos por primera vez el malware y el primer producto AV lo empieza a detectar (y de momento no tenemos constancia de más presencia pública, además del sitio de esta compañía AV), reportando “pocos” sitios infectados (¿se tratará pues de una campaña que ha afectado a varias organizaciones?); esto, junto al carácter altamente dirigido de las víctimas seleccionadas en el caso de nuestro cliente mantiene el interrogante por el momento.
Trataremos de mantenerles informados a medida que vaya surgiendo más información.
Actualización 2: en 9 de diciembre de 2014, Blue Coat libera un informe, (re-re)bautizando el malware como Inception. Toda la información presente en el informe es coherente con lo observado por nuestro equipo en agosto de 2014. Confirmado: es una campaña APT :-)
Actualización 3: en 10 de diciembre de 2014, Kaspersky lo ha apodado Cloud Atlas.
Hoy os presentamos pwnConf, una conferencia de carácter 100% técnico que se realiza el día 23 de Noviembre en la ciudad de Mar del Plata y que reunirá investigaciones de profesionales de distintas partes del país.
Entre las principales temáticas que que se tratarán en el evento se encuentra la Seguridad Informática, contando también con gran cantidad de charlas orientadas con perfil de SysAdmin/DevOps y Networking. Todas las charlas incluyen un altísimo nivel de vanguardia tecnológica, que se puede vislumbrar fácilmente en charlas con temáticas tan variadas y actuales como Big Data, Privacidad en Internet, NoSQL, Cloud Computing, Clustering y Desarrollo de Librerías.
Además de su carácter de conferencia tradicional —con ponentes con charlas de 40 minutos de duración— el evento también tendrá un acentuado perfil de desconferencia, en donde los asistentes podrán anotarse libremente para dar lightning talks de 10 minutos de duración con absoluta libertad sobre las temáticas a tratar.
En el sitio oficial de pwnConf podéis encontrar el cronograma completo de charlas, así como también la lista de ponentes y el correspondiente enlace al registro, que si bien es 100% libre y gratuito, está limitado a la capacidad física del lugar.
El fin último de pwnConf es brindar un entorno en donde intercambiar conocimientos, compartiendo experiencias con amigos y colegas en un ambiente descontracturado e ideal para el aprendizaje.
La conferencia está orientada principalmente a estudiantes de carreras afines a la informática, profesionales, empresas, entusiastas e investigadores. Podéis tener toda la información disponible en pwnconf.org
Hace unos días, a propósito de la llamada de unos técnicos falsos de Microsoft, nuestro compañero Raúl advertía sobre la necesidad de concienciar a los usuarios, tanto personales como profesionales (cada uno tiene una cosa que perder) en los aspectos más de seguridad. Como este es, en general, un blog del ámbito profesional, me permitirá que abandone a los usuarios domésticos a su suerte o a la de su primo informático, y nosotros nos quedemos en el entorno corporativo, que es el que nos atañe.
La cuestión es que la entrada de Raúl me trajo a la memoria una serie de medidas que, allá por el 2007, propusimos en este blog como contrapartida a la concienciación. Es más, como le indicaba en aquel caso, puedo garantizar que con la aplicación gradual de todas ellas podemos reducir prácticamente en un 100% cualquier tipo de fuga de información o problema de seguridad, sin invertir un euro en concienciación. Eso sí, le advierto que el camino no es sencillo.
La primera medida es, como no podría ser de otra manera, inhibir cualquier medio de extracción de información mediante dispositivos o soportes de almacenamiento. Será necesario por tanto inhabilitar los puertos USB, además de desinstalar cualquier grabadora de CD o DVD. Por experiencia le diré que tendrá que lidiar con las quejas de algunos usuarios reticentes a cambiar sus hábitos, pero a la larga el beneficio compensa la molestia. Son, cómo decirlo, esas pequeñas molestias que te hacen el día diferente; pequeños contratiempos sin mayor importancia. Se acabaron al fin los virus que nos llegan por ese USB que vaya a saber usted dónde ha estado antes.
La segunda medida lógica en este proceso es cortar el correo electrónico. Así, de raíz. Porque todo el mundo sabe que no hay mayor peligro que el e-mail. Potencialmente, cualquier empleado malintencionado o un equipo controlado remotamente podría estar utilizando este sistema para mandar información confidencial a cuentas privadas, a potencias asiáticas, a la competencia o incluso a su primo el informático. Además, de esta forma acaba usted de un plumazo con las herencias africanas, las validaciones de seguridad bancaria de bancos en los que no tiene cuenta y las fotografías subidas de tono de la celebrity de moda en formato ejecutable. Así que corte el grifo. No email, no risks.
Ya nos hemos ahorrado muchos problemas, pero no podemos cejar en nuestro proceso de bastionado corporativo. La tercera medida es eliminar el acceso a Internet. No sólo evitaremos el acceso a webmails gratuitos, que son un potencial peligro, sino que evitaremos que un empleado malintencionado o un potencial atacante utilice alguna alternativa como el ftp, ssh o servicios cloud para extraer información. Esta medida también carece de complejidad: Deny ALL from ALL. O puede simplemente arrancar el cable o apagar el router de salida. Es así de simple. Se acabaron los ataques de denegación de servicio, los escaneos de red y cualquier cosa que se le ocurra. Internet ya no sabe que usted existe, ergo no le puede atacar. En este caso las quejas serán algo más enérgicas, especialmente cuando el personal de Administración no pueda conectar a la banca electrónica para realizar las transferencias de las nóminas. Sin embargo, dígales que para eso están los cibercafés. Nuestro objetivo es, ante todo, proteger la información corporativa, no las nóminas del personal.
Seguimos. Si piensa usted que cerrando los USB, el acceso a Internet y el e-mail está a salvo de la fuga de información, está muy equivocado. La cuarta medida es la eliminación de cualquier fax, teléfono, tablet, cámara y dispositivo de cualquier tipo que permita registrar, grabar, transmitir, anotar, fotografiar, enviar o extraer información interna, de cualquier manera. Sí, será necesario que confisque los teléfonos móviles de los empleados y cualquier visitante: clientes, auditores, políticos o hijos de los empleados, si se da el caso. Somos conscientes de que eso puede generar algún ligero malestar entre el personal, pero nada que la promesa de una organización más segura no pueda compensar. Al fin, ya no hemos de preocuparnos de que la información salga por vía telemática, telefónica, electrónica o cualquier otro medio. Estamos llegando (casi) al final.
La quinta medida es eliminar las impresoras y cualquier tipo de material en el que y con el que se pueda escribir, copiar, dibujar, etc.: lápices, bolígrafos, folios, libretas, etc. Nunca podemos estar seguros de que alguien no va a copiar a mano, sin ninguna mala intención, un diseño del último transatlántico que su empresa está fabricando o el listado de nombres y apellidos de los dos mil empleados, y va a acabar perdiendo la hoja con esa información en el metro. Todos sabemos que hay gente muy rara por el mundo, y como suele decirse, mejor prevenir que curar. Por supuesto, deberá cortar el correo postal. De salida, porque no tiene sentido, y de entrada, porque seguro que ha oído lo del Anthrax, ¿verdad? Pues eso.
La sexta (y penúltima) medida viene prácticamente derivada de las dos anteriores. Le hemos aconsejado que prohíba los dispositivos de grabación como los smartphones, y se deshaga de los lápices. Pero, ¿cómo estar seguro de que esa medida se cumple? Piense que un competidor disfrazado de hijo de empleado podría entrar con un móvil en el bolsillo. Pues para evitarlo, es necesario que en el acceso a nuestra organización pongamos dos guardias de seguridad para llevar a cabo cacheos exhaustivos del personal (a la entrada y a la salida, por si quedan dudas). Si además instala los sistemas de seguridad que se utilizan en los aeropuertos estadounidenses, mejor que mejor. Así, hemos llegado casi al final de nuestro recetario de seguridad.
La séptima (y última) medida está relacionada, como no podría ser de otra manera, con las personas que se mueven por su organización. De nuevo, empleados, visitantes, clientes, etc. Si no estaba al tanto, debe saber que cualquiera de ellos está capacitado para memorizar información en su propia cabeza (sí, está demostrado), que luego podría difundir. Por razones que no vienen al caso, no podemos aconsejarle que impida la salida de las personas de su empresa una vez han entrado, ni que tome acciones más “expeditivas”, así que dado que esa no es una opción, debe impedir bajo cualquier concepto que cualquier persona tenga cualquier tipo de acceso a la información. Ya sabe: cualquier persona a cualquier tipo de información. Es decir, no deje que nadie, nunca, de ningún modo, acceda a su organización.
Con estas sencillas y útiles medidas comprobará que, sin invertir lo más mínimo en concienciación, su empresa está totalmente a salvo de cualquier problema de seguridad de la información y por extensión, de cualquier otro tipo.
