Security Art Work

Hace unos días el Centro de Seguridad TIC de la Comunidad Valenciana (CSIRT-CV) publicó un informe de “Seguridad en Internet de las cosas”, en el que podemos encontrar una guía sobre el estado del arte de seguridad sobre este tipo de dispositivos cada vez más extendidos en la red.

Básicamente, el término IoT (Internet of Things) se atribuye a un conjunto muy grande de dispositivos conectados a Internet y no son ordenadores convencionales. Pero, ¿por qué llamarlo Internet de las Cosas? Éste término se acuñó cuando el número de dispositivos superó al número personas conectadas a Internet, por lo que ya no se podía asumir que Internet estaba formado por personas interconectadas a través de sus dispositivos, sino que realmente existen dispositivos “autónomos” conectados a la red. No nos alertemos; no estamos ante una rebelión de las máquinas (todo se andará), sino de dispositivos desatendidos que se conectan a Internet con alguna finalidad como puede ser compartir información, o facilitar acceso remoto al dispositivo.

Estos dispositivos comprenden relojes, neveras, hornos, coches, sistemas de control domótico, wearables, sistemas de control de tráfico, etc. Todos hemos visto u oído hablar, e incluso disponemos de dispositivos de este tipo, pero la mayoría no somos conscientes de las implicaciones de seguridad y los riesgos potenciales a los que se enfrentan estos dispositivos, y en consecuencia las personas y organizaciones que los empleen.

Los dispositivos IoT técnicamente no son tan distintos como parece en comparación con sistemas que históricamente han poblado la red de redes, sin embargo, existen diferencias sustanciales que hacen que sea necesario un análisis pormenorizado de los riesgos o ataques que les pueden afectar.

Uno de los puntos más importantes de estas diferencias es que en general los dispositivos IoT son dispositivos empotrados, que son menos complejos que por ejemplo un ordenador personal. Esto es debido a que están diseñados con una funcionalidad específica y no con un propósito general. Se trata de sistemas más heterogéneos puesto que los fabricantes implementan sus propias soluciones, descartando en muchos casos un sistema operativo global o común como sucede con los PCs o smartphones. Esto dificulta en gran medida el establecimiento de políticas de seguridad o la gestión de actualizaciones.

Otro punto fundamental es que, en la mayoría de los casos, el problema no está en las capacidades del dispositivo, sino en las decisiones tomadas por los fabricantes respecto a las configuraciones por defecto de los mismos. En general, los dispositivos IoT no disponen de interfaz de usuario o controles, por lo que tienen que facilitar acceso a sus interfaces de administración mediante otros medios menos amigables para el usuario, por lo que la gran mayoría de ellos (los usuarios) no serán capaces de modificar la configuración de su dispositivo. Este hecho, sumado a que los fabricantes no suelen establecer una configuración de seguridad por defecto adecuada, hace que los dispositivos posiblemente mantengan una configuración potencialmente insegura.

El último de los casos a tener en cuenta es su ubicación física; estos dispositivos normalmente se encuentran altamente distribuidos, por lo que es posible que sistemas “críticos” ya no estén protegidos en un centro de proceso de datos. Este hecho hace que sean más difíciles de proteger, ya que puede ser muy sencillo obtener acceso físico a ellos, lo que entraña uno de los riesgos potenciales más graves de seguridad.

A modo de resumen, el informe publicado por CSIRT-CV aborda los siguientes apartados principales:

• Alcance y objetivos del informe: Entorno y ámbito actuales, así como la finalidad del propio informe.
• Riesgos asociados: Identificación de los riesgos potenciales que afectan a estos dispositivos, distinguiéndolos claramente del resto de los que se encuentran conectados a la red.
• Vectores de ataque a las IoT: Posibles ataques o vulnerabilidades aprovechables que se podrían aprovechar para comprometer este tipo de dispositivos.
• Recopilación de incidentes: Casos reales de incidentes de seguridad relacionados con IoT.
• Prevención y salvaguardas: Listado de buenas prácticas para mejorar la seguridad en el uso de este tipo de dispositivos.

En la actualidad, el número de dispositivos IoT que empleamos va en aumento y se espera que la tendencia se acentúe los próximos años, especialmente los wearables, de los que no paran de surgir nuevos tipos y clases. Del mismo modo, algunos dispositivos de este tipo se están integrando en el ámbito corporativo. Este hecho supone un avance y a la vez un reto para las empresas ya que a pesar de la evolución y las ventajas puede que aportar, existe una elevada preocupación por las amenazas de seguridad que conlleva.

Por ello, debemos ser conscientes de la existencia de “Internet de las Cosas”, así como de la problemática y las recomendaciones de seguridad que se requieren para que su uso sea un avance global y no un retroceso en la seguridad, confidencialidad y libertad de las personas y organizaciones. Si el tema os ha resultado interesante os recomendamos encarecidamente la lectura de dicho informe, que os permitirá ampliar vuestros conocimientos en la materia.

El informe de “Seguridad en Internet de las Cosas” se encuentra disponible en este enlace [PDF], dentro del portal web de CSIRT-CV, y también desde su sección de descargas.

Si no tenéis nada que hacer, esta es una buena lectura para las navidades :)

Antonio Sanz en sus artículos “PDF deconstruído al aroma de shellcode”, hace un análisis empleando la utilidad peepdf de un PDF que explota la vulnerabilidad “CVE 2013-2729”.

A partir de estos artículos, se me ocurrió la idea de generar una regla de YARA para detectar estos PDF maliciosos.

Para ponernos en situación, recordemos que la vulnerabilidad CVE 2013-2729 explota un fallo de Adobe Reader X que no valida bien los datos de imágenes BMP incrustadas en el documento. Mediante este fallo se puede ejecutar código malicioso debido a que provoca un heap overflow.

La siguiente regla de yara nos permite localizar los ficheros que explotan dicha vulnerabilidad:

rule shellcode_cve_2013_2729
{
meta:
        author = "Manuel"
        company = "S2 Grupo"
        date = "2014-12-17"
        description = "PDF con shellcode CVE 2013_2729"
        link1 = "http://www.binamuse.com/papers/XFABMPReport.pdf"
        link2 = "https://github.com/feliam/CVE-2013-2729/blob/master/XFABMPExploit.py"
        link3 = "https://github.com/feliam/CVE-2013-2729/blob/master/E10.1.4.pdf "
        link4 = "https://www.securityartwork.es/2014/09/30/pdf-deconstruido-al-
                 aroma-de-shellcode-i/"
        md5test =  "eb9228f17568704676385428d3bbefff"
strings:
        $xfa1 = "XFA 1 0 R"
        $xfa2 = "XFA 2 0 R"
        $xfa3 = "XFA 3 0 R"
        $s0 = "AcroForm 2 0 R"
        $s1 = "/Filter [/Fl"
condition:
        1 of ($xfa*) and all of ($s*)
}

Para ejecutar la regla, utilizaremos la siguiente instrucción:

yara <fichero regla> -s <fichero pdf>

Esperamos que esta regla os sirva de ayuda para detectar y analizar estos hermosos PDFs con regalo que seguro que recibís estas navidades.

Comenzamos 2015 con un nuevo congreso de Seguridad Informática que nace en Santander como el primero en este ámbito en Cantabria, Sh3llCON: Security Hell Conference.

Se definen como un nuevo foro de divulgación sobre seguridad informática que surge con la finalidad de analizar las distintas amenazas y vulnerabilidades que rodean nuestra conexión diaria en las redes.

Sh3llCON se celebrará los días 23 y 24 de enero en el Hotel Santemar y contará con un interesante plantel de ponentes:

[Read more…]

Volvemos a la carga con la cuarta parte de nuestra serie sobre pfSense. En el anterior capítulo explicamos cómo configurar las opciones avanzadas del sistema (ver también la primera entrada y la segunda, para los despistados). En esta cuarta parte vamos a explicar cómo configurar “el corazón del firewall”, es decir las reglas de pfSense.

Lo primero, para facilitar la creación de reglas, es importante saber lo que son los “alias” y qué posibilidades brindan. Vamos a la pestaña superior, Firewall → Aliases.

Dentro podemos crear diversos alias como Hosts, subredes, puertos y URLs. Este es un ejemplo de creación de alias para los servidores que pertenecen a la red DMZ:

Así es como se vería un resumen de todos los Alias creados:

Ahora se trata de usar estos alias para configurar las reglas en el apartado Firewall → Rules. Lo más importante que debemos tener en cuenta al crear una regla es que prevalece la prioridad de la regla que se sitúa por encima de otra regla.

En nuestro ejemplo (y en general, en cualquier entorno en producción) la red DMZ no debe tener acceso a la red interna, ya que la DMZ es la que albergará los servidores que están expuestos a Internet y esta red no debe tener ningún tipo de comunicación hacia la red interna. Por otro lado, sí que nos interesa que se puedan gestionar los servidores desde la red interna hacia la DMZ, por lo que podemos crear una regla que permita el trafico por el puerto 22 (SSH) desde la red interna hacia la DMZ.

En el apartado Rules, la interfaz que pertenece a DMZ es “OPT1”, desde allí, existe un botón con el símbolo “+” para añadir reglas. Por tanto, creamos una regla que deniegue el acceso desde la DMZ a red interna, donde en “Destination” usamos el alias “Subnet_lan” creado anteriormente.

Exactamente de la misma forma pero desde la interfaz LAN (red interna) crearemos una regla que deniegue todo el tráfico desde red interna (LAN) a la subred DMZ (más adelante se superpondrán reglas que prevalezcan sobre esta). A continuación, creamos una regla por encima de la anterior que permita la comunicación SSH desde red interna (LAN) hasta los servidores en DMZ:

Ahora en las reglas del firewall de la interfaz LAN (nótese que el deny de DMZ hacia LAN está en el interfaz OPT1, por eso no se muestra) se vera así:

En la regla de más arriba (la más prioritaria) están permitidos dos puertos 10443 y 10022, que son los que se usan para administrar PFsense por HTTPS y SSH. Esta regla se crea por defecto y es importante que exista ya que en caso contrario, se estaría denegando el acceso al propio firewall.

El siguiente paso es configurar NAT (Network Address Traslation). Para ello en la sección NAT en Port Forwarding, configuraremos que nos permitan acceder al servidor web y al servidor FTP desde internet a estos dos equipos situados en la DMZ. En el caso del HTTP sería como se muestra en la imagen.

Tras aplicar ambas reglas, tendríamos una situación como la siguiente:

Es importante saber que al crear esta regla en NAT automáticamente se crean las reglas del firewall asociadas, de forma que se pueda hacer efectivo el acceso desde fuera hacia dentro. Por tanto, así quedarían las reglas del firewall en la interfaz WAN ahora:

Con estos ejemplos básicos ya podemos comenzar a “trastear” con pfSense y un mayor número de reglas. En el siguiente artículo veremos la implementación de herramientas como un IDS (Snort) o un proxy (Squid), dentro de pfSense.

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:

• El comunicado sobre el accidente aéreo droppeado (el documento “limpio”) resultó ser el mismo para todos los adjuntos
• Tanto el fichero .vbs como la DLL droppeadas eran diferentes para cada mensaje (tanto en nombre, que trataba siempre de imitar el de alguna DLL legítima de Windows, como en contenido)
• La clave del registro (Barbicas en el primer especímen analizado), variaba en cada dropper
• El tiempo de unpacking también variaba para cada adjunto, observando tiempos desde 8 minutos hasta más de 15 minutos (en cualquier caso, el proceso mantenía una de las CPU al 100%)
• El servidor WebDAV era el mismo para todos los especímenes, así como el nombre de usuario y la contraseña utilizados para iniciar sesión en el mismo (lo cuál no significa que, para otras posibles organizaciones víctima o campañas, los atacantes no puedan generar ejemplares que utilicen otras credenciales)
• Sin embargo, la clave de 256 bits para AES, así como los directorios de subida (exfiltración) y bajada (comando y control) de información, eran diferentes para cada ejemplar analizado (en todos los casos, iban hardcodeadas en el propio código)
• Las extensiones utilizadas en los ficheros subidos al WebDAV (.TAR, .TIF, .TXT, etc. en el primer adjunto) variaban en cada ejemplar

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.

Para hoy tenemos una entrada de un nuevo colaborador, Alex Casanova, administrador de Sistemas Windows, Linux y Sistemas virtualizados con VMware con más de 10 años de experiencia. Adicto a las nuevas tecnologías y las telecomunicaciones dedica gran parte de su tiempo a la investigacion de sistemas radio, OSINT y redes de comunicaciones. Actualmente está involucrado en el despliegue de una red digital de comunicaciones DMR para radioaficionados. Se le puede encontrar en su twitter @hflistener y en su blog Digimodes.

Habitualmente todas las noticias sobre seguridad están centradas en el mundo de Internet y sus amenazas; pero no siempre somos conscientes de los posibles riesgos existentes en las comunicaciones fuera del plano IP. Analizar y comprender el riesgo que suponen los sistemas de radiocomunicaciones en las organizaciones debe jugar también un papel fundamental dentro de la seguridad, cuya interrupción o destrucción podría tener un gran impacto sobre la organización.

Recientemente ha sido publicado en “Communications Support Forums” una vulnerabilidad en el sistema de comunicaciones DMR (MotoTRBO) de Motorola que permitiría a un atacante, usando un terminal de radio, transmitir en la frecuencia de salida de un repetidor DMR protegido con el sistema RAS (Restricted Access to System) sin conocer la clave.

[Read more…]

La seguridad informática es casi siempre compleja, abarcando muchas áreas distintas y haciendo muy fácil caer en el equivalente técnico de la “letra de médico”.

Quién no ha tenido algún momento del estilo de tener a dos técnicos de seguridad y que comiencen a hablar de la “APT que explotaba un CVE del kernel de XP y que exfiltraba por HTTP usando 404 modificados, y que menos mal que el IDS lo pilló y le pusimos un deny en el firewall antes de que dropeara una nueva versión de malware del C2 ”.

Si eres técnico de seguridad seguramente estés sonriendo al leer estas líneas, pero si no lo eres probablemente no hayas entendido ni una coma. El problema es obvio: la seguridad informática es complicada, y comunicar en seguridad informática es más complicado todavía.

Y en mi opinión, la comunicación es algo en lo que deberíamos de trabajar todos los expertos en seguridad informática. Es necesaria tanto para convencer a la dirección para poder invertir tiempo y recursos en mejorarla, como para convencer a los usuarios de que la seguridad es necesaria (por su propio bien en muchos casos).

Por ello, me gustaría proponer una lista de libros, escritos por técnicos, pero en los que explica de una forma clara, sencilla y hasta amena, varios conceptos principales de la seguridad informática.

[Nota: Me temo que todos los libros están en el lenguaje de la pérfida Albión. Es lo que tienen los libros muy especializados …]

”Secrets and Lies: Digital Security in a Networked World”, Bruce Schneier – Ed Wiley

Schneier es uno de los mejores divulgadores actuales de la seguridad informática. Además de su blog de seguridad informática tiene varios libros publicados en los que trata de forma sencilla conceptos como el riesgo, la protección de sistemas, la criptografía y hasta la propia confianza base de la sociedad. Todos sus libros son interesantes pero “Secrets and lies” es el mejor. Si tu jefe solo tiene tiempo para leer un libro de seguridad, que lea éste.

”The Code book”, Simon Singh – Ed. Anchor

Si hay algún campo de la seguridad informática que es especialmente complicado es la criptografía (yo tengo la teoría de “la criptografía de clave pública solo se entiende a la tercera vez que te la explican”). Sin embargo, Singh hace un trabajo maravilloso explicando de una forma cristalina los conceptos más complicados de la criptografía, todo basado en momentos históricos y lleno de anécdotas. Una delicia de libro.

“Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon”, Kim Zetter – Ed Crown

Stuxnet es considerado por muchos como el primer acto de ciberguerra con todas las letras: intención, sofisticación y complejidad son palabras que vienen a la mente cuando pensamos en un malware que, posiblemente, haya abierto la caja de Pandora y que sin duda será estudiado en tiempos venideros. Zetter es capaz de narrar cómo fue detectado, analizado y erradicado de forma amena y casi adictiva, haciendo de la historia prácticamente un tecnothriller.

“Spam Nation: The Inside Story of Organized Cybercrime-from Global Epidemic to Your Front Door” – Brian Krebs, Ed. Sourcebooks

Krebs es posiblemente el periodista especializado en seguridad informática más famoso del mundo. Desde su blog analiza todas las noticias importantes de seguridad desde un punto de vista crítico pero claro. Su libro es una guía muy completa del cibercrimen, contando con todo lujo de detalles el submundo de los delitos informáticos desde los spammers hasta cómo se blanquea el dinero que es obtenido.

“The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders and Deceivers” – Kevin Mitnick & William Simon, Ed. Wiley

Kevin Mitnick (alias “El Condor”) es uno de los hackers más conocidos de la historia, siendo especialmente famoso por su dominio de la ingeniería social (o como él lo llama, “hackear personas”). En este libro, basado en historias propias y de otros hackers de la época, cuenta cómo sobrepasar diversos sistemas de seguridad con pocos o nulos tecnicismos. Es muy interesante la aplicación del pensamiento lateral, y cómo atacan algunos problemas logrando saltarse la seguridad de formas a veces estúpidas pero muy efectivas.

“Inside cyberwarfare” – Jeffrey Carr, Ed O’Reilly

Ciberguerra, ciberespionaje, cibercrimen… Por mucho que cerremos los ojos, van a seguir estando ahí. Carr hace un listado muy completo de los problemas que podemos encontrarnos en Internet, enfocándose en las capacidades existentes de diversos países para la ciberguerra, así como en diferentes escenarios y tecnologías a emplear. Aunque Carr es analítico y claro, huyendo totalmente de intentar causar el pánico, el miedo que te entra en el cuerpo después de leerlo es … inquietante.

Hay muchos más libros “sencillos” para hablar de seguridad informática, pero estos son los que me han parecido más representativos. Y tú … ¿tienes algún libro de cabecera para enseñar seguridad informática a los no técnicos? ¡Compártelo!

Dicen que los perros viejos no aprenden trucos nuevos. Pues parece que los malos sí que son capaces de hacerlo. Desde primera hora del día de hoy nos hemos encontrado con una campaña masiva de correos maliciosos enviados desde múltiples orígenes, pero todos con un patrón común:

• Asunto con el texto “Remittance Advice for 918.97 GBP” (la cantidad varía según el correo).
• Un adjunto con el nombre BAC_XXXXXXY.xls (5-6 números y una letra).

[Read more…]

Hace ya demasiado tiempo pasé cerca de un año en el Georgia Institute of Technology de Atlanta, continuando con mis estudios universitarios. Al poco tiempo de llegar, el que debía ser el responsable de seguridad nos dio una charla en la que se congratulaba por el hecho de que Atlanta ya no fuese la ciudad más peligrosa de EEUU, sino la segunda (hablamos aproximadamente de 1999). Además advertía, haciendo énfasis en los más jóvenes, que tuviesen cuidado con las ilusiones de inmortalidad propias de la adolescencia, evitasen riesgos innecesarios y adoptasen ciertas medidas de seguridad.

Tengo la sensación de que ese tipo de fantasía se aplica de manera muy adecuada a la mayoría de empresas. En general, el pensamiento que todavía impera en muchas organizaciones es el que ya conocemos: eso no nos puede pasar a nosotros. El equivalente es el que se sube al coche pensando que los accidentes le pasan a todo el mundo menos a él y prescinde del cinturón de seguridad y de cualquier límite de velocidad “razonable”.

Sin embargo, hay dos hechos innegables. El primero es que los accidentes siguen ocurriendo. Afortunadamente, son cada vez menos y pocas veces son graves, pero ahí están las estadísticas. El segundo, que los accidentes descienden gracias a las medidas de seguridad que se van diseñando e implantando y no por intervención divina: cinturón de seguridad, airbags, control de tracción, ABS, control de estabilidad, carroceria deformable, habitáculo rígido, etc., además de las diferentes campañas de sensibilización y concienciación.

La cuestión es que muchas empresas están todavía en la adolescencia de la era digital. Esa en la que piensan que hagan lo que hagan, el peligro no existe: que el cifrado es propio de los paranoicos, que Alfredo1976 es una contraseña válida, que el comedor es un lugar tan bueno como otro para el servidor corporativo o que la destrucción de papel no es, en fin, algo tan imprescindible.

Poco a poco, algunas de éstas madurarán y entenderán que los riesgos son reales; implantarán controles de seguridad y asumirán no sólo que a veces sí pasan cosas, sino que es necesario aplicar medidas para que no pasen. Que, tal y como sucede con la conducción, están expuestos no sólo a atacantes sino a empresas que no toman esas medidas de seguridad (aspecto que nos da para otra entrada: la necesidad de entender que tu inseguridad les afecta a los demás). Otras empresas acabarán aprendiendo a base de golpes y por último —y aquí vamos a dejar de lado el símil por razones evidentes—, algunas tendrán que echar el cierre.

¿Garantiza un automóvil en buen estado, con las medidas de seguridad básicas y una conducción responsable que no tengamos accidentes? No, por desgracia. Pero sí los hace mucho menos probables y reduce significativamente sus consecuencias. Lo mismo sucede con la seguridad digital.

Quizá esta entrada les haya parecido poco útil. Si es así, piensen en las campañas de concienciación de la DGT. ¿De verdad piensan que no sirven de nada?

Hace unos meses, nuestro compañero Jose Vila ya nos habló de Logstash como alternativa a Splunk para análisis de logs, poniendo como ejemplo como se podía analizar un conjunto de logs de Apache y contándonos cómo personalizar un dashboard de Kibana para analizar alertas procedentes de Snort [1] [2]. En esta ocasión vamos a continuar hablando de Logstash, poniendo como ejemplo como buscar algunas anomalías en un fichero de log de un proxy de navegación de un Squid.

Lo primero a tener en cuenta sería definir el fichero de configuración que le pasaremos a Logstash para que nos interprete, de la manera adecuada, el log del Squid. Este fichero es el que yo me he definido (se puede descargar del siguiente repositorio: https://github.com/mmorenog/Kibana):

Una vez definido el fichero de configuración podemos cargar en Kibana el fichero de log a analizar:

En este dashboard inicial vemos el histograma con todos los eventos del log, seguido de una visualización detallada de cada línea del log interpretada como le hemos indicado en el fichero de configuración que previamente hemos diseñado. A continuación un detalle de una de las líneas:

Para ir perfilando nuestro dashboard de visualización, podemos ir añadiendo paneles con la información que nos interese, como por ejemplo el tamaño medio de las peticiones, el tiempo medio desde que se lleva a cabo una petición y se obtiene respuesta, destinos menos solicitados, content-type más anómalos, etc.

Un ejemplo de como crear un panel para que nos muestre el tamaño medio de las respuestas que seleccionemos en nuestro histograma de eventos, sería el siguiente:

Añadiendo los paneles anteriormente comentados, nuestro dashboard para el log del Squid tendría el siguiente aspecto:

Comentar en este punto, que cualquier búsqueda o filtrado que hagamos sobre nuestro histograma de eventos, afectará a todos los paneles que tenemos en el dashboard, ciñéndose los resultados a la búsqueda/filtrado que se han llevado a cabo. Por ejemplo, si hacemos una búsqueda en una determinada franja horaria de los métodos HTTP más utilizados, nuestro dashboard adoptaría el siguiente aspecto:

Como se observa, las peticiones pueden quedarse fijas en el histograma diferenciándose por colores. También es posible generar un gráfico de barras con la cuenta total de los resultados de las búsquedas que hemos realizado en el intervalo temporal solicitado, como se muestra a la derecha.

Otra búsqueda que podemos hacer sería la de obtener un Top 10 de los destinos más solicitados dejando fija esta petición del Top 10 en el panel de búsqueda:

O incluso añadiendo también las URI más solicitadas:

Una vez hemos visto las posibilidades de representación que nos permite Kibana a la hora de diseñar paneles de visualización, comentemos algunas anomalías indicativas de compromiso a tener en cuenta en un proxy de navegación:

• Identificar conexiones a servidores C&C en listas negras (importante mantener actualizadas estas listas).
• Identificar tráfico en horario no laboral (cualquier tráfico de navegación fuera del horario habitual es una anomalía a investigar, sin embargo, la mayoría del malware avanzado respeta el horario no laboral e incluso algunos, los días festivos de la región/país).
• Identificar conexiones periódicas a servidores de C&C (por ejemplo, anómalo sería que un equipo estuviera haciendo conexiones cada día entre las 8:00am y las 10:00am exactamente al mismo destino cada 3 minutos). Igual que antes, si el malware es lo suficientemente sofisticado, programará aleatoriedad en sus conexiones para no caer en ningún tipo de periodicidad que pudiera dar indicios de un patrón identificable.
• Identificación de anomalías estadísticas univariables:
  • Dominios menos solicitados.
  • Content-Type estadísticamente anómalos.
  • etc.
• Identificación de anomalías mediante análisis estadístico multivariable; es decir, campos que no son anómalos por sí mismos, pero cuya combinación si lo es:
  • Detección de exfiltraciones satelitales (extremadamente lentas). Por ejemplo conexiones de un tamaño pequeño frente a un tiempo de conexión alto.
  • Otro ejemplo podría ser una combinación anómala de Content-Type, código HTTP y tamaño de la transacción.
  • Imaginemos detectar un equipo haciendo peticiones a un dominio y que éste devuelva siempre un 404, un tamaño grande y variable, y contenido binario. Como se observa, un campo por sí solo no muestra evidencias de ser algo extraño, sin embargo la combinación de todos lo es; una página que se pide constantemente y no se encuentra, que devuelve un tamaño grande y cambiante, con formato de aplicación…cuanto menos habría que investigar el comportamiento.

Pongamos ahora en práctica con Kibana la búsqueda de algunas de las anomalías citadas.

Si nos fijamos en la [Imagen 4], en el panel de los “Content-Type” menos solicitados, nos llama la atención por ejemplo uno denominado “JPeg”, lo cual es un formato inválido, y por tanto anómalo y cuya petición que lo ha generado habría que investigar.

Partiendo de nuevo de la [Imagen 4], vemos que el tiempo de petición medio que tenemos es de 4,585 y el tamaño medio de respuesta es de 53,427. Por tanto, para acotar una zona de eventos en nuestro log que nos pueda mostrar “conexiones lentas”, se podría obtener para una consulta del tipo request_msec:>4585 and request_size:<5327. El resultado podría ser algo susceptible de ser analizado en profundidad.

Otra búsqueda interesante que podríamos hacer es la de buscar todos aquellos “gif” (que aparezcan en el uri_param), sin embargo que en el content_type no aparezca el tipo esperado para un “gif”, sino algo que pudiera identificar un ejecutable por ejemplo. Esas peticiones que aparecen en nuestro log deberíamos estudiarlas:

Otra búsqueda interesante, podría ser investigar qué peticiones nos están devolviendo 404 y un tamaño de respuesta superior a un determinado umbral que le especifiquemos o dentro de un intervalo (Ej: response_status:404 AND response_size:[1000 TO 100000]). Lo habitual quizá, es que el tamaño devuelto por un 404 no sea demasiado elevado:

También podemos querer averiguar los “exe” que se han estado descargando:

Como vemos, las posibilidades de buscar anomalías son bastante amplias, y Kibana puede ser una buena herramienta para ayudarnos a complementar los análisis de nuestros logs. Personalmente echo en falta (o yo no he sabido implementarlo) un método que me permita calcular periodicidades en las conexiones, facilidad de integración con fuentes externas -para que sea capaz de correlar algunos datos- y que incorpore su propia base de datos de inteligencia, a la cual se la permitiera ir autoaprendiendo.

En este ejemplo hemos buscado algunas de las anomalías más conocidas, pero si tratamos de investigar registros procedentes de compromisos por ataques avanzados, que implican una mayor dificultad para encontrar evidencias de compromiso, una herramienta que nos amplía las posibilidades es CARMEN (Centro de Análisis de Registros y Minería de Eventos) [PDF] , pensada para la detección de amenazas persistentes avanzadas y fruto de proyectos de I+D+i y explotación de seguridad por parte del CCN (Centro Criptológico Nacional) y S2 Grupo, la cual está dotada de inteligencia, capacidad de autoaprendizaje y facilidad de integración con diferentes fuentes.

Aprovecho para comentar que, se ofrecerá un taller sobre CARMEN en las VIII Jornadas STIC CCN-CERT, que se celebraran el próximo diciembre. Allí os esperamos y para el que no pueda asistir, no os preocupéis que os lo iremos contando por aquí :)