Search Results for: análisis forense

(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:

• Volcado lógico de un iPhone5.
• Volcado físico de un Samsung Galaxy S5.
• Imagen forense de un Apple MacBook Pro.

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.

[Read more…]

Una de las principales vías de infección de malware es a través de documentos ofimáticos. Son un vector de infección muy contundente, sobre todo en ataques dirigidos y campañas de phising.

Estos documentos son manipulados con el fin de esconder en su interior macros, objetos OLE, ejecutables, etc., los cuales, una vez abierto el documento por el usuario, realizan una serie de acciones maliciosas con el objetivo de obtener información con la que poder lucrarse o simplemente provocar daños en el sistema. Generalmente, las acciones llevadas a cabo por este tipo de malware genérico son descargar otro malware desde internet (droppers), explotar vulnerabilidades del sistema, replicarse para asegurarse la persistencia en el equipo, exfiltrar información del usuario, etc.

Una herramienta muy útil para analizar y detectar patrones anómalos en los documentos ofimáticos es la suite “OfficeMalScanner”, la cual podéis descargar desde la web de su autor, http://www.reconstructer.org/.

[Read more…]

Para este miércoles tenemos una entrada de Antonio Sanz, Ingeniero Superior de Telecomunicaciones y Master en ICT por la Universidad de Zaragoza.

Actualmente es el Responsable de Sistemas y Seguridad del I3A (Instituto de Investigación en Ingeniería de Aragón), y trabaja como perito en informática forense. Posee las certificaciones CISA, CISM, CHFI e ITILf, y sus áreas de interés actuales son la respuesta ante incidentes, la informática forense y el cibercrimen. Tuitea como @antoniosanzalc y es un imprescindible en cuestiones de ciberseguridad, cibercrimen y APTs entre otros aspectos, dándole una perspectiva geopolítica sumamente interesante.

El fin de vida de Windows XP ha traído, está trayendo (y traerá) muchos quebraderos de cabeza tanto a administradores de sistemas como a los expertos en seguridad. En este artículo se pretende ofrecer soluciones y consejos basados en nuestra experiencia en el I3A (Instituto de Investigación en Ingeniería) de la Universidad de Zaragoza.

El primer paso a seguir es definir el objetivo del proyecto y los parámetros de partida. El objetivo principal no debería ser reemplazar Windows XP por otro sistema operativo, sino apoyar los procesos de negocio (en nuestro caso la investigación realizada por nuestros miembros). Ese apoyo se traduce directamente en este caso en una gestión del riesgo, orientada a controlar y reducir el mismo hasta niveles aceptables.

Como parte de los parámetros iniciales se tiene que el proyecto debería terminar lo antes posible (de forma óptima a principios de Abril, cuando se daba por finalizado el soporte). Por razones obvias de la coyuntura económica actual, el gasto a realizar debería de ser el mínimo posible.

[Read more…]

Para este miércoles tenemos una entrada de Antonio Sanz, que después de mucho perseguirlo se ha prestado a colaborar con nosotros :)

Antonio es Ingeniero Superior de Telecomunicaciones y Master en ICT por la Universidad de Zaragoza. Actualmente es el Responsable de Sistemas y Seguridad del I3A (Instituto de Investigación en Ingeniería de Aragón), y trabaja como perito en informática forense. Posee las certificaciones CISA, CISM, CHFI e ITILf, y sus áreas de interés actuales son la respuesta ante incidentes, la informática forense y el cibercrimen. Tuitea como @antoniosanzalc y es un imprescindible en cuestiones de ciberseguridad, cibercrimen y APTs entre otros aspectos, dándole una perspectiva geopolítica sumamente interesante.

El próximo 8 de Abril Microsoft finaliza el soporte extendido para Windows XP [1], Office 2003 e Interner Explorer 8, lo que supone que ya no ofrecerá de forma oficial actualizaciones de seguridad. Esto supone un grave problema, ya que XP tiene una cuota a nivel mundial del 30-35% en función de la fuente consultada.

En España, Luis Corrons (Director Técnico de PandaLabs/Panda Security) afirmó en el 7ENISE [2] que en un estudio realizado entre grandes empresas y AAPP Windows XP suponía un 81% de las estaciones de trabajo [3]. Para hacernos una idea de la magnitud del problema, cuando Microsoft finalizó el soporte a Windows 2000 en 2010 tan solo tenía un 0.4% de la cuota de mercado [4].

Los problemas de la migración de Windows XP a un sistema operativo superior (Windows 7 o Windows 8) son variados. En primer lugar está el problema de la potencia de los equipos [5], ya que no todos los equipos tendrán hardware lo suficientemente potente como para correr 7/8 (aunque en mi experiencia, un Pentium IV con 2Gb de RAM, si se le desactiva Aero y otros servicios puede ser todavía usable).

[Read more…]

Uno de los operadores que más me gusta a la hora de definir filtros con Wireshark es “matches“. Con este operador podremos extender las limitaciones que nos ofrece el resto de filtros a la hora de localizar determinados patrones en nuestros ficheros pcap. De forma parecida a “contains”, el operador “matches” nos permite buscar por determinadas cadenas de texto así como bytes con la ventaja adicional de soportar PCRE (Perl-compatible regular expression). Este operador será realmente útil a la hora de buscar gran variedad de ataques como DDOS, fuzzing, opcodes que coincidan con ciertos patrones de malware conocido, o, como veremos a continuación, exploits que se aprovechan de un stack/heap overflow.

Aunque obviamente Wireshark no es la herramienta más apropiada para detectar BO, en ocasiones en las que no tengamos a mano un Snort o los GSoC plugins vistos en la entrada anterior de Maite y nos enfrentemos a un .pcap de gran tamaño, disponer de macros que identifiquen ataques de este tipo puede ayudarnos enormemente en nuestra labor forense.

Los siguientes ejemplos representan el esqueleto típico de un buffer overflow, bien aprovechándose del RET address o del SEH (Structured Exception Handling):

payload = junk + eip + egghunter + nops + egg + shellcode
payload = string + buffer + egg + shellcode + eip + nops + egghunter
payload = junk + egg + shellcode + eip + nops + egghunter
payload = junk + eip + nops + shellcode
payload = junk + egg + shellcode + junk1 + nseh + seh + nops + egghunter + junk2
payload = nops + shellcode + nops + eip + nops + farjump + nops
payload = junk + nseh + seh + nops + shellcode + junk1

Teniendo en cuenta estos ejemplos, podríamos definir un filtro que busque por paquetes que contengan un string largo (junk) formado por 0x4141414141, 0x9090909090 (NOPs) o similares e ir jugando con diferentes longitudes de cadena. Por ejemplo:

Podemos omitir \\1 si lo que buscamos son cadenas alfanuméricas de gran longitud comúnmente empleadas por herramientas de fuzzing o por scripts para calcular el offset del return address como la generada por pattern_create.rb (Aa0Aa1Aa2Aa3A…c1Ac2Ac3Ac4A….). Puesto que dicho filtro puede generar numerosos falsos positivos podemos ir un poco más allá:

En este caso buscaríamos un buffer superior o igual a 100 seguido de lo que sea (.*), seguido de w00tw00t (generalmente utilizado como egg para definir el comienzo del shellcode) o seguido del propio código del egghunter (12 primeros bytes). Los siguientes opcodes \xeb\.\x90\x90 y \x90\x90\xeb. suelen utilizarse cuando lo que está sobrescribiendo es algún campo nSEH dentro de la cadena SEH (chain SEH). Generalmente el registro SEH será sobrescrito por alguna instrucción que permita saltar al campo nSEH (situado justamente detrás).

Dependiendo de donde se encuentre el shellcode (bien delante o bien detrás de la estructura SEH) será necesario hacer un salto positivo o negativo, de ahí que únicamente se especifique el opcode EB (short jump) sin especificar que tipo de salto y cuantos bytes se desean saltar. Al final, también se busca por opcodes x61 (popad) consecutivos, utilizados también como recurso para desplazar el registro ESP hasta el shellcode. En el siguiente ejemplo se muestra un intento de BO contra un servidor HTTP utilizando la cabecera HEAD.

Veamos otro ejemplo. En este caso crearemos un filtro que detecte un BO que utiliza un shellcode o egghunter codificado con x86/alpha_upper. Al igual que otros encoders, alpha_upper es relocalizable en memoria. Esto significa que es capaz de obtener la dirección base absoluta de su propio código, lo que le permite ejecutarse independientemente de su posición en memoria. Para poder obtener la dirección absoluta de memoria utiliza instrucciones FPU (Floating Point) junto a FSTENV.

Cuando se emplea esta técnica como GetPC (Get Program Counter), se suele utilizar una instrucción de coma flotante al inicio del decoder junto a la instrucción FSTENV PTR SS: [ESP-C] encargada de almacenar el entorno FPU en memoria. De esta forma se consigue cargar la dirección de la primera instrucción en el stack para posteriormente descargarla en algún registro (ver figura 4). Utilizando un offset realativo a esta dirección, podrá empezar a decodificar el resto del payload. Teniendo en cuenta este comportamiento, si nos fijamos en la forma que toman los payloads generados por msfencode pueden observarse ciertos patrones comunes en los primeros opcodes:

Los opcodes d9, da, db y dd forman parte de instrucciones FPU como FXCH, FFREE, FCMOVU mientras que los opcodes \xd9\x74\x24\xf4 representan FSTENV PTR SS: [ESP-C]. En el primer caso, se usa una instrucción mov, seguido de una instrucción FPU seguido de FSTENV. Puesto que el payload generado tiende a seguir alguna de estas secuencias podríamos general el siguiente filtro:

Nota: fíjese que algunos de los opcodes del principio del decoder no son alpha uppercase, es decir, están fuera del rango [\x41-\x5A,\x30-\x39]; por este motivo se especifica [.] (cualquier byte).

En el siguiente caso se muestra la vista “Follow TCP Stream” de un paquete que ha ‘matcheado’ dicho filtro. La salida muestra un intento de explotación contra un server FTP (Filezilla) en el que se utiliza un payload codificado con alpha_upper y que trata de aprovecharse del parámetro PASS.

Si quisiéramos llevar este payload a Inmunity Debugger para una análisis más exhaustivo necesitamos eliminar espacios y añadir únicamente los opcodes.

Con este output y mediante la opción binary copy ya podemos pegar y empezar a analizar el código.

Para no tener que escribir el todas las expresiones regulares cada vez que arranquemos Wireshark, podemos guardarlas desde el menú Analyze -> Display Filters.

Obviamente las formas que puede tomar un BO son muy dispares y el uso de encoders más polimórficos como shikata_ga_nai dificultarán enormemente la localización de este tipo exploits mediante firmas estáticas. El objetivo únicamente es mostrar la flexibilidad que nos proporciona “matches” gracias a PCRE para localizar gran variedad de ataques como los vistos anteriormente siempre y cuando sigan algún patrón conocido. Por ejemplo, en el análisis llevado a cabo por McAfee sobre Aurora se indicaba como el backdoor iniciaba una conexión con el puerto 443 del C&C enviando siempre un paquete con la misma secuencia: ff ff ff ff ff ff 00 00 fe ff ff ff ff ff ff ff ff ff 88 ff. Con este dato podríamos definir un filtro en busca de paquetes que utilicen dicho payload sin necesidad de utilizar un IDS como Snort o esperar a que se actualicen sus reglas.

Para acabar, indicar que actualmente el operador “matches” presenta algunos problemas cuando se emplean metacaracteres y dígitos en hexadecimal con 2 letras. Si se necesita ‘matchear’ secuencias que contengan dichos bytes es necesario parchear epan/ftypes/ftype-pcre.c activando el flag G_REGEX_RAW. También me he encontrado con problemas a la hora de crear macros con dicho operador, algo que sería bastante útil para poder especificar como parámetro la longitud del buffer. Es decir, el filtro $buffer{200} para la macro tcp matches “([\x41-\x5A,\x30-\x39,\x90]){$1}” no funcionará cuando se empleen secuencias de bytes.

Recientemente comentábamos entre los compañeros cómo han disminuido, en general, los ataques dirigidos a servidores, aumentando especialmente, por contra, los ataques al usuario. Dichos ataques están siendo cada vez más sofisticados ya que intentan explotar vulnerabilidades muy avanzadas a nivel de cliente, sobretodo a la hora de procesar ficheros “complejos”, como DOC o PDF.

Con ello, nos encontramos ante la dificultad de realizar una detección en tiempo real de ataques dirigidos a usuarios, ya que los sistemas inline deberían simular diversos escritorios para poder detectarlos, con diferentes navegadores y sistemas operativos; por ejemplo, añadiendo el hecho de que una inspección en profundidad de cada uno de los ficheros consume mucho tiempo de proceso.

Uno de mis compañeros, Josemi (archivo de autor, @J0SM1 ), nos habló de Razorback, un proyecto que aún está en fase de desarrollo pero que precisamente tiene por objetivo proporcionar un entorno de trabajo que se adecúe justo a lo que comentaba anteriormente: al panorama cambiante de amenazas en el que nos encontramos, y que nos permita gestionar de manera avanzada incidentes en tiempo real. Decidí profundizar más acerca de éste proyecto, y como me pareció interesante, en esta entrada entraré un poco en éste, en una posterior entrada comentaré acerca de la instalación y mostraré un ejemplo práctico de su funcionamiento.

Razorback es un proyecto de código abierto que está desarrollando el equipo VRT de Sourcefire y que pretende ofrecer un único framework de gestión avanzada de incidentes, escalable y extensible enfocado sobre todo a la detección de malware, especialmente de exploits 0-day.

Básicamente, está diseñado para ser un “marco de distribución” (dispatching framework), ya que distribuye los datos que va monitorizando hacia herramientas de análisis y detección de amenazas que realizan una inspección más en profundidad de esos datos, y todo esto manteniendo una gran base de datos forense en la que se almacena toda la información procesada. Al combinar diversas herramientas bajo un mismo marco de trabajo y punto de vista se acelera la creación de las contramedidas al respecto de esas amenazas, y disponer de toda esa información en una misma base de datos es muy útil de cara a detectar tendencias de ataques, y así prevenirlas, obtener informes sobre malware, o buscar por firmas de ataques en dicha base de datos.

Este framework está formado por una serie de elementos principales que trabajan por separado pero retroalimentándose de información los unos de los otros, como vemos en la siguiente imagen:

• Dispatcher: elemento principal de nuestro framework, ya que se encarga de gestionar todas las comunicaciones entre el resto de elementos.
• Base de datos que almacena información sobre cada evento, metadatos, información de la configuración, etc.
• Nuggets: diversas herramientas que nos van a proporcionar diversas funcionalidades según el tipo que sean:
  • Collection Nugget: se encargan de capturar datos de la red y contactar con el Dispatcher para evaluar si esos datos ya han sido tratados:
    • Snort
  • Detection Nugget: analizan los datos que vienen desde los elementos de Collection Nugget. Contactan con el Dispatcher para indicarle si se genera cualquier tipo de alerta. Podemos encontrar:
    • PDF Dissector
    • JavaScript Analyzer
    • Shellcode Analyzer
    • Office Cat Nugget
    • SWF Nugget
    • ClamAV
  • Output Nugget: Reciben alertas desde el Dispatcher. Pueden enviar datos a otros sistemas, como por ejemplo a una interfaz de Maltego.
  • Intelligence Nugget: no generan alertas por sí mismos, sino que generan datos que podrían ser usados a posteriori para correlar eventos o analizar tendencias de ataques.
  • Correlation Nugget: interactúan directamente con la base de datos. Se encargan de proporcionar información sobre datos de tendencias, o hosts críticos, por ejemplo. Nos podrían ayudar a trazar, por ejemplo, un ataque a través de la red.
  • Defense update Nugget: ponen en marcha la actualización de diferentes dispositivos a petición del Dispatcher.
  • Workstation Nugget: interfaz donde se puede gestionar el resto de nuggets, consultar los eventos, alertas, etc.

El funcionamiento a grandes rasgos es el siguiente: Razorback monitoriza cierto tipo de tráfico (HTTP, Web o correo electrónico SMTP) y va enviando a diferentes nuggets datos replicados, con el fin de analizarlos en busca de vulnerabilidades 0-day o posibles códigos de explotación, registrándolo todo en la base de datos.

Básicamente estamos hablando de que al Dispatcher le llega un fichero, y escoge a qué nugget le tiene que enviar dicho fichero para que lo analice. Si por ejemplo un fichero embebe otro de diferente tipo, el fichero embebido se le devuelve al Dispatcher para que lo vuelva a redirigir al nugget apropiado. En la siguiente imagen se muestra un ejemplo del funcionamiento:

Los desarrolladores invitan a los usuarios a crear sus propios nuggets ya que en teoría es fácil integrarlos en el funcionamiento, y a probar la herramienta para hacer crecer este proyecto. Para la siguiente entrada os quiero hablar sobre la instalación de Razorbarck (que os adelanto que es un infierno) y mostraros un ejemplo práctico de su funcionamiento y cómo ver y manejar la información que nos ofrece.

Si os interesa el proyecto, no dudéis en visitar su página (http://sourceforge.net/apps/trac/razorbacktm/) y echarle un vistazo a esta presentación de Razorback en la Defcon del año pasado (y siguientes vídeos).