miércoles, 29 de marzo de 2017

Reversig II: Formato PE – Un análisis de las cabeceras

Como mencionamos en la primera entrada de esta serie de notas de reversing, donde hablamos del direccionamiento en memoria, los archivos ejecutables de Windows tienen las cabeceras “Image File Header”, “Image Optional Header”, “Image Section Header” e “Image Data Directory” que proporcionan mucha información sobre el ejecutable en sí. Ahora que ya entendemos que son las direcciones virtuales (VA) y las direcciones virtuales relativas (RVA) podemos meternos en el análisis de las cabeceras del formato PE (Portable Executable) que son los ejecutables de Windows.

La mayoría de las cabeceras PE cuentan con numerosas entradas y hasta incluso estructuras enteras con sus propias entradas dentro. En este artículo voy a mencionar las cabeceras, estructuras y entradas mas relevantes.

IMAGE FILE HEADER
Las entradas mas relevantes de esta cabecera son:

  • Machine: Indica el tipo de arquitectura en la cual se podrá ejecutar el ejecutable (válgase la redundancia xD).
  • NumberOfSections: Cantidad de secciones dentro del ejecutable (.code, .data, .rsrc son algunos nombres típicos de secciones).



IMAGE OPTIONAL HEADER
Las entradas mas relevantes de esta cabecera son:

  • Magic: Indica si el ejecutable es para x86 o x64.
  • AddressOfEntryPoint: RVA hacia la primera instrucción del programa (el Entry Point es lo que llamamos el punto de partida del código del ejecutable).
  • BaseOfCode: RVA del inicio de la sección de código (.code).
  • BaseOfData: RVA del inicio de la sección de datos (.data).
  • ImageBase: VA de preferencia donde se cargará el ejecutable. Esta entrada ya la estudiamos en el artículo anterior, el valor de preferencia suele ser 0x00400000.
  • SizeOfImage: Tamaño a reservar en memoria para cargar el ejecutable.
  • SizeOfHeaders: Tamaño de todas las cabeceras PE juntas.
  • SizeOfStackReserve: Tamaño a reservar para el stack (la pila).
  • SizeOfHeapReserve: Tamaño a reservar para el Heap.       




IMAGE SECTION HEADER
Las entradas de esta cabecera se replican por cada sección del ejecutable indicando los siguientes valores sobre cada una de ellas:
  •  Name: Contiene el nombre de la sección.
  • VirtualSize: Tamaño que ocupará la sección en memoria.
  • VirtualAddress: RVA de la primera dirección de la sección en memoria.
  • SizeOfRawData: Tamaño de la sección en disco.
  • PointerToRawData: Posición del primer byte se la sección en disco.




IMAGE DATA DIRECTORY
Esta es la cabecera más compleja, se compone por estructuras completas que tienen sus propias entradas. A continuación, mencionaré las estructuras más importantes con sus entradas más relevantes.

Export Directory
Esta estructura contiene información acerca de las funciones a las cuales, mediante enlace dinámico, pueden acceder otros archivos ejecutables y DLLs. Generalmente quienes contienen esta sección son las librerías (DLL).
  • Export Directory Table: dentro de todas sus entradas, esta tabla provee información general sobre el directorio de exportación, por ejemplo, el RVA que apunta al nombre de la primera librería exportada, el primer ordinal desde el cual se inician las exportaciones, etc.
  • Export Addres Table: RVA correspondientes a cada función exportada.
  • Name Pointer Table: RVA a las cadenas de los nombres de las funciones exportadas.
  • Ordinal Table: Contiene los índices (o números ordinales) de cada función exportada.   


 Import Directory
Generalmente los archivos ejecutables tienen importaciones, es decir, enlazan funciones de librerías propias o del sistema durante su ejecución. Estas importaciones están definidas a través de las diferentes entradas de la estructura Import Directory, que son las siguientes:
  •  Name RVA: es el RVA a la cadena del nombre de la librería a importar.
  • Ordinal Number: Contiene el ordinal (número de 2 bytes) con el cuál se hará la importación.
  • Original First Thunk y First Thunk: estas dos entradas contienen los mismos valores en disco pero en memoria no. En memoria, First Thunk se carga con una dirección de memoria que corresponde a la función que se va a importar, mientras que Original First Thunk contiene un RVA que apunta a la cadena con el nombre de la función a importar.
  • Ordinal Name Flag: Si este bit está establecido en 1 la importación se llevará a cabo por ordinales, de lo contrario (si es 0) se hará por nombres.
  • Name Table RVA: Apunta a otra estructura que detalla la importación por nombre y se utilizará solo si el flag “Ordinal Name Flag” está en cero.




Resource Directory
Su principal utilidad es dar información de los recursos que tiene el ejecutable (íconos, imágenes, etc.) esta información se encuentra en una sección nombrada “.rsrc”.






Relocation Directory
Tal como mencionamos en la nota anterior, podría pasar que la VA del ImageBase donde el ejecutable se quiere cargar esté ocupada. Entonces si el ejecutable se carga en otra base distinta, se utiliza el Relocation Directory ya que provee el mecanismo para reubicar las direcciones estáticas de manera que todo funcione bien. El desplazamiento se obtiene restando el ImageBase actual al ImageBase original, cuyo resultado se lo conoce como “delta” y a eso se le suma el VA de las direcciones a reubicar.

TLS Directory (Thread Local Storage)
Es una clase especial de almacenamiento que soporta Windows, y contiene información utilizada cada vez que se crea un nuevo hilo de ejecución.

Bound Import Directory
Cuando un ejecutable utiliza este mecanismo, lo que hace es guardar en el directorio Import Address Table las direcciones virtuales de las funciones de las librerías importadas, es decir, no guarda los RVA sino las direcciones reales.  Esto ayuda para optimizar ya que el ejecutable no necesitará volver a cargar cada función importada sino únicamente la librería y verificar que las direcciones que tiene no sean obsoletas. Si no están obsoletas, entonces se ahorra volver a cargar la función, de lo contario, cuenta con la información necesaria para volver a realizar la carga nuevamente. 




Bueno, espero que no se hayan aburrido con tanta teoría xD en la próxima entrega de estas notas sobre reversing veremos algunas cosas más prácticas sobre cómo podemos alterar esta información de las cabeceras PE para lograr modificaciones interesantes en la carga de los ejecutables.

Vuelvo a dejar el link de la nota anterior donde pueden encontrar documentos y herramientas útiles:  https://mega.nz/#F!11ljSKQB!IoZ_umxtwFUxewL1uIbAXA.

====== NOTAS DE LA SAGA DE REVERSING ======

domingo, 26 de marzo de 2017

Guía básica de reconocimiento de Malware

El universo del malware es un universo en expansión tanto en cantidad cómo en sus cualidades. Gracias a internet, buenos investigadores, comunidades y desarrolladores, tenemos a disponibilidad mucha información, muchisimos datos y formas de obtener aún más datos y así, en conjunto con el conocimiento, podremos generar información accionable, el asset más importante.

Para no perderse en este universo que día a día aumenta su complejidad, aparecen nuevas técnicas, tools, vulnerabilidades, exploits, ideas y demás, debemos analizar cuál es la mejor manera de enfrentar un problema y llegar lo antes posible a los resultados que necesitamos.


Un camino posible es el siguiente:


  1. Obtener el panorama de la situación actual y especificar las metas del análisis y la prioridad de cada una de estas metas.
  2. Realizar un análisis preliminar para entender mejor la situacion de la amenaza, utilizando tanto herramientas de OSINT (Open Source Intelligence) como herramientas automatizadas para obtener un rápido assessment permitiendo una rápida mitigación. Con este paso también podemos facilitar el trabajo de preparación para un análisis más granular (por ejemplo despackeando y desofuscando o por lo menos detectando con qué fue packeado/ofuscado)
  3. Realizar un análisis en profundidad haciendo ingeniería inversa (reversing) de las partes del malware de interés. Esta elección debe estar influenciada por los pasos anteriores, enfocándose en ciertos aspectos de nuestro interés (funcionalidad, protocolos de comunicación, etc).
  4. Obtener los resultados utilizando el conocimiento de los pasos anteriores, comprender el funcionamiento y recolectar la evidencia, lo que ayudará a realizar una correcta toma de decisiones conociendo los daños/riesgos expuestos.

Este proceso es una guía, pero no es estrictamente una receta que no pueda ni deba cambiar.

Un buen malware analyst requiere conocer cuándo se debe utilizar cuál herramienta en pos de la efectividad, es decir, obtener resultados a menor tiempo y menor costo posible.

Al igual que en cualquier profesión con un Tool Set, no siempre necesitarás todas las herramientas y muchas pueden no ser efectivas para el trabajo requerido.  Hay situaciones en las que, si hemos definido correctamente nuestro objetivo, podríamos incluso ahorrarnos algunos pasos o tareas dentro del mismo, dependiendo de la cantidad y calidad de información que vayamos consiguiendo en cada uno de ellos. De la misma manera, las herramientas a utilizar en cada uno de los pasos intermedios variarán enormemente de acuerdo a los casos específicos en los que nos encontremos trabajando.

Luego de esta larga introducción, quiero darles a conocer tres webapps gratuitas que pueden servirnos para realizar un reconocimiento inicial del malware con el que estemos trabajando. Además, algunas de estas pueden ser utilizadas para conseguir muestras de malware con las cuales practicar nuestras skills ;)

Ya sea que tu cliente haya sido víctima de malware, hayan detectado actividad sospechosa en el sistema y tenés un conjunto de archivos del cual no sabes nada, descargaste una muestra de malware de internet o la conseguiste de tu honeypot, y suponiendo que tenemos nuestras metas claras en cuanto a los resultados que queremos obtener, siempre vamos a preguntarnos ¿Con què estoy trabajando? ¿Esto es nuevo o conocido? ¿Que tanto se conoce sobre esta muestra? ¿Por donde empiezo mi análisis?

Como siempre, internet es el lugar ideal donde comenzar.


Ok ok, tengo un sample. Donde lo subo? Que tengo que tener en cuenta a la hora de subirlo?

VirusTotal

Una de las tools más utilizadas en el mundo del malware analysis es VirusTotal.
VirusTotal es una webapp gratuita (aunque también existe su versión paga) donde uno puede subir un archivo, una URL o consultar un hash en busca de detecciones de amenazas de las principales empresas de antivirus y website scanners.
Una de los grandes puntos a favor que tiene VirusTotal es su API, con la cual podemos automatizar la subida de muestras, la obtención de resultados y combinarlo con cualquier otra tarea que necesitemos armando nuestros propios scripts. También nos permite enviar muestras por email y recibir allí los resultados en un formato XML o texto plano. Es una herramienta rápida que, en caso de consultar sobre un archivo, nos da información útil sobre su análisis estático y si es posible, un poco de info de su análisis dinámico

Algunas limitaciones y otros problemas:
  • Limitación de subida de archivos de 128 MB (version gratuita).
  • Limitación de consulta de muestras a razón de 1 cada 15 segundos (versión gratuita, requiere registración).
  • Limitación para uso comercial (obviamente).
  • Privacidad: Cuando uno sube una muestra, esta de acuerdo con los terminos y condiciones de su uso. Esto implica permitir que VT almacene tu muestra, recopile informaciòn y lo comparta con quien lo solicite, incluyendo las empresas de Antivirus. Claramente un cliente que ha sido víctima no querría que cierta información (que no sabemos si es o no conocida, o si contiene información sensible hasta haberla analizado) este en la red, o un hacker no querría estar alertando a las empresas de antivirus de su última creación (aunque no todos parecen estar alertados de esto y aun se ven casos de esto). Un workaround para obtener los beneficios de VT sin tener que compartir nuestras muestras es simplemente hasheando el archivo y buscándolo en su base de datos. Una buena herramienta para hacer esto es vt-notify, que envía un mail cuando una muestra es subida a VT. Otra alternativa es NoDistribute, herramienta similar a VT en cuanto al análisis de detección de AntiVirus, pero a diferencia de este, no comparte las muestras subidas. Si se requiere analizar muchos archivos, sera necesario registrarse y adquirir un plan a la medida de las necesidades.

  • No permite descargar las muestras (versión gratuita).
  • Cómo último motivo, para quienes tienen alguna preocupación sobre el monopolio de internet, cabe mencionar que desde el 2012, VirusTotal es una de las tantas subsidiaria de Google.

Malwr

Otra herramienta interesante para obtener información y realizar análisis automatizados con mayor granularidad es malwr.com. Este sitio, a diferencia de VT, es totalmente gratuito (no tiene versión paga).


Malwr permite a los usuarios subir archivos a los cuales sandboxeará y realizará un resumen de la información extraida. Está basado en la tecnología Cuckoo Sandbox. Algo muy interesante de esta herramienta es el hecho de que, si quien lo subió lo permite, es posible descargar las muestras para analizarlas nosotros mismos donde también es opcional realizar el sandbox de manera privada (requiere registración).

DISCLAIMER: Super ultra mega warning, don’t say I didn’t warn you: Ejecutar muestras de malware dentro de tu pc es malo. Muy MUY malo. No queres hacer eso. De verdad, creeme. Guardá la muestra en un lugar seguro, donde nadie la vea, donde nadie le haga click pensando que es una foto de la prima. Si bien estos sitios tienen cierto criterio para que no ocurran accidentes, la gente suele ser propensa a los mismos por mérito propio.

Esta herramienta nos provee información a modo de resumen tanto de su análisis estático (Secciones, Imports, Strings, AV Detections (usando VT; ojo) ) cómo dinámico (screenshots, comportamiento en el host y en la red), incluyendo signatures que ayudan a detectar comportamiento sospechoso del archivo en ejecución.


Una de las características interesantes de malwr es la graficación del comportamiento del malware, donde podemos ordenar por tiempo/evento en su eje x y api/categoría en su eje al flujo de cada uno de los procesos creados durante su ejecución, además de poder usar el zoom en los sectores que consideremos interesantes. Esto facilita a entender el flujo del malware.




La información más detallada de cada llamada al sistema, argumentos, su estado y otros datos los podemos encontrar en la tab de Behaviour Analysis, coloreado por categorización.

El resto de las posibilidades se las dejo descubrir a ustedes ;)

HybridAnalysis / Reverse.IT

HybridAnalysis, al igual que malwr es un servicio web de sandbox creado por la empresa Payload Security, y lleva su nombre por el uso de ambos análisis: estático y dinámico. Su uso es gratuito y permite sandboxear muestras de hasta 180 MB. A diferencia de malwr, las muestras correran en un entorno de VxStream Sandbox v6.20 (pago). Soporta tanto archivos PDF, Office y PE cómo APKs. También tienen API pero esta limitada a la descarga de muestras (No podemos hacer subidas automáticas), pero nos permite realizar búsquedas de reportes de muestras que matcheen cierto criterio que nosotros indiquemos. Además nos permite descargar las muestras de malware compartidas por la comunidad (requiere registración).
ra.jpg



Reverse.it es muy similar a hybridanalysis, con la diferencia que permite también subir urls.
Vale aclarar que crear una cuenta en una pagina equivale a registrarse en la otra.


Reverse.jpg
Ambos sitios permiten una selección personalizada de los settings que elegimos correr (aunque siempre limitada en su versión gratuita).Untitled.jpg

Además de la limitación en el tamaño de las muestras, al usar este servicio se le otorgan los derechos a Payload Security de usar, modificar, reproducir, distribuir (y un largo etcétera) tanto la muestra cómo el reporte obtenido de la misma.

Seguramente a esta altura se estarán preguntando:
“Existiendo estas herramientas tan automágicas, cómo es que aún siguen analizando malware de manera manual?”
Con un poco de práctica se darán cuenta que muchas veces las cosas no son tan simples como parece. Si bien existen muchas herramientas para automatizar estos procesos, no siempre son efectivos y mucho menos nos dan el panorama completo. Muchas piezas de malware tienen técnicas de detección avanzadas, o requerirán de ciertos programas o DLLs presentes en el sistema para poder correr. Aquí es donde el análisis manual se convierte en algo crucial, para así solventar las diferencias y poder ejecutar correctamente el malware y, si tenemos algo de suerte, lograr desmembrarlo.
Por otro lado, muchas veces faltan piezas de información. En internet lo que siempre vamos a encontrar es una especie de resumen de la amenaza. Si la situación lo requiere, tendremos que indagar más por nuestra cuenta para poder desentrañar aun más nuestro malware.

Por ejemplo, supongamos que nos encontrásemos ante la presencia de un sample del cual no sabemos nada. Comenzamos a indagar con estas herramientas, y podemos concluir por su comportamiento que es un ransomware. Haciendo un análisis más profundo del mismo podrías incluso encontrar el código de desencripción sin poner un solo fragmento de bitcoin, simplemente mirando su codigo (si hay un decompilador) o reverseando la muestra.

También la tecnología de sandbox es muy limitada en su práctica y requiere cierta personalización de parte del usuario para obtener información útil acerca de la amenaza en muchos casos, por ejemplo, si tengo un .pdf que corre un pedazo de JavaScript para explotar util.print del CVE-2008-2992 necesito una versión de adobe flash player que sea vulnerable (adobe v3 a v8.1.2), de otra manera no seré capaz de ejecutar este tipo de amenazas.

Al mismo tiempo, al realizar este tipo de personalizaciones se debe pensar bien en lo que se está haciendo. Si el objetivo es realizar análisis en una gran cantidad de muestras dentro de un esquema automatizado (por ejemplo usando Cuckoo Sandbox), quizás personalizar puede llegar a ser contraproducente si no se hace correctamente (Si tu objetivo es que corra la mayor cantidad de muestras, se deberá buscar aquellos software con versiones vulnerables con más exploits activamente en uso) , y nunca se lograrían ejecutar la totalidad de las muestras. Debemos tener en cuenta que si queremos conocer el comportamiento real, se vuelve cada vez más importante simular un entorno real.

Bueno, estos fueron los trucos para el GTA I de playstation one y espero que les sean de utilidad (?). Recomiendo que busquen alguna muestra (incluso en los mismos sitios) y exploren todas las opciones que cada una de ellas provee para identificar familias, comportamientos, obtener indicadores y relacionar información sin la necesidad de descargar ningún programa.

Autor: Ruth Esmeralda Barbacil
Tw: @33root

viernes, 24 de marzo de 2017

Reversing I: direccionamiento en memoria


Hace casi unos 9 años, cuando tenía 13 de edad, empecé a interesarme por el área de Reversing y hasta el día de hoy me apasiona :) al iniciar uno empieza a tener contacto con analizadores de código, debuggers y si nos enfocamos en Windows: diferentes herramientas para el análisis de las cabeceras de los archivos PE (Portable Executable). Los términos “offset”, “dirección física”, “dirección virtual”, “dirección virtual relativa” se manejan constantemente en esta área. Recuerdo por aquellos tiempos haberme leído dos documentos bastante detallados sobre el formato PE, buscando en mi viejo HD ¡los encontré! así que les dejo los links de descarga al final del artículo para quienes quieran profundizar.

Entender bien la estructura del formato PE y la forma en que ocurre el direccionamiento en memoria es indispensable si nos interesa el área de reversing. Si bien el tema da para escribir manuales enteros, en este artículo pretendo dejar claro cómo es el direccionamiento en memoria al cargarse un archivo PE (o ejecutable de Windows) y repasar algunas cabeceras importantes de este formato.

Cuando abrimos un .exe con un editor hexadecimal, podemos ver en hexa los bytes del archivo en disco.



Llamamos “offset” a una posición de este archivo en disco. Por ejemplo, en la captura anterior, el byte marcado en rojo se encuentra en el offset 1805h.

En memoria, las cosas cambian, el offset 1805h no estará en la dirección de memoria 0x0040001805 por ejemplo (por si acaso nos imaginamos eso). La pregunta es: ¿Es posible llegar a la dirección de memoria de un offset y así conocer su correspondiente instrucción en ASM? Si, pero antes aclaremos algunos conceptos y luego hacemos el cálculo necesario :)

Cuando un ejecutable se carga en memoria, lo hará casi siempre tomando de base la dirección virtual 0x00400000. A menos que esa dirección virtual esté ocupada, en cuyo caso se utilizará otra -por ejemplo la 0x00800000- y se reubicará todo lo necesario para que el ejecutable funcione bien.



Las direcciones virtuales (VA - VirtualAddress) son visibles sólo por cada proceso y son convertidas por el sistema operativo a una dirección física. Por ejemplo, la VA del proceso A donde se cargó el ejecutable (0x00400000) puede estar mapeada a la dirección física 0x00500000. Mientras que la VA del proceso B (0x00400000) puede estar mapeada a la dirección física 0x00300000.

Hasta ahí queda claro la diferencia entre las direcciones físicas y virtuales, pero existen también las direcciones virtuales relativas (RVA) que son relativas a la dirección virtual donde se cargó el proceso. Esa dirección virtual donde se carga el proceso está definida por el “ImageBase” – una entrada de la cabecera PE “Image Optional Header”- cuyo valor suele ser 0x00400000, ya que como dijimos, es la dirección virtual donde el ejecutable intenta cargarse prácticamente siempre en primera instancia.

Dentro de un ejecutable podemos encontrar muchísimas VA y RVA que apunten a diferentes cosas. Las VA llevan consigo el ImageBase, por ejemplo, si dentro de un ejecutable vemos la dirección 0x00400800, se trata de una VA ya que se está indicando la dirección completa. Si fuera una dirección relativa o RVA, veríamos en su lugar: 0x00000800. El “loader” del sistema operativo será quien se encargue luego de convertir esas direcciones virtuales relativas a direcciones virtuales cuando sea necesario.

Entonces, por si quedó alguna duda:

VA = ImageBase + RVA
    Ejemplo: 0x00400000 + 0x00000800 = 0x00400800.
RVA = VA – ImageBase
    Ejemplo: 0x00400800 – 0x00400000 = 0x00000800.

La pregunta que nos quedó pendiente es ¿Cómo podemos saber la dirección virtual de un offset? Recordemos que las direcciones virtuales son las que podemos visualizar desde un debugger al cargar el ejecutable en memoria, si nos dirigimos a una VA especifica podemos conocer la instrucción ASM del programa en esa posición.

Según la teoría el cálculo es el siguiente:

Offset - Offset de la sección + Offset virtual de la sección + ImageBase 

Bien, ahí hay dos cosas de las que no hablamos: el offset de la sección y el offset virtual de la sección. Allí vamos:

Nuestro offset se encuentra dentro del espacio de una determinada sección del ejecutable que comienza en un offset específico, ese es el offset de la sección. Por ejemplo, si nuestro offset es el 7800h y tenemos la sección “code” que inicia en 7000h y tiene una longitud de 4000h bytes, entonces es obvio que esa es la sección donde nos encontramos y el offset de la sección es el 7000h. Así como está ese offset de la sección también está el offset virtual de la sección. Estos datos podemos verlos fácilmente utilizando alguna herramienta como PELord o Stud_PE.



Es más, estas mismas herramientas tienen conversores Offset <=> RVA y podemos utilizarnos para ahorrarnos el tener que hacer manualmente todo ese cálculo.



Otra utilidad de estas herramientas es poder ver detalladamente todas las cabeceras PE con sus respectivas entradas. Los archivos ejecutables tienen las cabeceras “Image File Header”, “Image Optional Header”, “Image Section Header” e “Image Data Directory” que proporcionan mucha información sobre el ejecutable con el que estamos tratando. Tenía intenciones de hablar de los principales campos/estructuras de estas cabeceras pero para que la nota no se haga muy larga ¡lo dejo para la próxima! Espero haber sido clara, estén atentos a la segunda parte.

Link de descarga de manuales y tools: https://mega.nz/#F!11ljSKQB!IoZ_umxtwFUxewL1uIbAXA.

¡Nos leemos pronto!.

Author: Sheila A. Berta.
Tw: @UnaPibaGeek
Web: www.semecayounexploit.com.

domingo, 19 de marzo de 2017

Cyber Threat Intelligence - Una introducción


El pasado 14 de Marzo en Segurinfo, presenté una charla titulada "Usando Cyber Threat Intelligence sobre amenazas" junto a Julio Ardita. Como Cyber Threat Intelligence o abreviado: CTI, no es un término con el cual mucha gente esté familiarizada aún, decidí armar este post para introducirlos en el tema.

Cyber Threat Intelligence se puede definir como el uso del conocimiento basado en evidencias, que nos permiten entender cómo se comporta una amenaza para poder predecir su comportamiento y, de esa forma, tomar decisiones preventivas o reactivas que nos permitan defendernos frente a esta amenaza.

Ese conocimiento tenemos que buscarlo (por ejemplo usando internet o alguna otra fuente como filmaciones) o producirlo (por ejemplo, analizando malware). A las fuentes les tenemos que otorgar cierto grado de confianza, no podemos suponer que son 100% infalibles ya que por lo general son incompletas, es decir, no proveen la totalidad de la información. Además, la persona que escribe no necesariamente entiende lo que está redactando o replicando (puede suceder que un periodista que no tenga ningún conocimiento técnico ni sepa nada sobre amenazas haya sido designado para escribir un artículo) por lo cual puede cometer errores, y esa información puede ser malinterpretada, llevándonos a cometer malas decisiones. Por estas razones, al hacer un trabajo de inteligencia no podemos usar solo una única fuente, tenemos que usar todas las que podamos y cuestionarnos todo lo que leamos para no caer en la desinformación.

La desinformación consiste en publicar información errónea y que su difusión se masifique para que los que la reciben, piensen que es real. Detrás de cada publicación, puede haber un interés oculto, por eso es necesario buscar varias fuentes, para tener una imagen más clara de lo que queremos investigar.

Al investigar una amenaza, se analizan distintos aspectos, por ejemplo, se busca información en internet para ver si ya había sido detectada o no, si forma parte de una campaña o no, si está atacando a una determinada industria o no. También se buscan indicadores y/o se fabrican, analizando los archivos encontrados de forma estática, de forma dinámica y/o aplicando ingeniería inversa. Por otro lado, se puede usar la información recopilada para investigar quién está detrás de la amenaza.

Es muy difícil hacer atribuciones ya que prácticamente todo se puede modificar. No nos podemos basar simplemente en una IP o en un dominio, ni siquiera en la fecha de compilación del binario del malware, porque todo se puede modificar. Antes de atrapar a alguien, los organismos como el FBI esperan años y cruzan un montón de información; esperan tener las cosas resueltas antes de atrapar a cualquier sospechoso y se valen de distintas fuentes, como pasó en el caso Silk Road. Pueden leer sobre dicho caso en los siguientes links:
https://www.wired.com/2015/04/silk-road-1/
https://www.wired.com/2015/05/silk-road-2/

Los indicadores de compromiso (IOCs) nos permiten entender mejor lo que estamos investigando, esto implica, identificar a una amenaza para poder responder ante ella. No todos los indicadores se pueden obtener de la misma manera, algunos son más complejos que otros, pero hay que usar la mayor cantidad de indicadores posibles para poder tener una imagen más clara sobre lo que estamos investigando. Para mostrar los tipos de indicadores que uno puede investigar, usamos la "Pirámide del dolor" ilustrada por David Bianco, quien trató de reflejar la relación entre los tipos de indicadores y el "dolor" que causa conseguir cada uno de ellos.





 Fuente: http://detect-respond.blogspot.com.ar/2013/03/the-pyramid-of-pain.html.


  • Hash Values: Permiten identificar los archivos que estamos analizando. Los más comunes son MD5, SHA1 y SHA2.
  • IP Addresses: Se pueden extraer de los archivos o se pueden observar durante la ejecución de un archivo.
  • Domains: Se extraen de igual manera que las IPs.
  • Network/Host artifacts: Son artefactos que permiten identificar la actividad maliciosa del atacante. Pueden ser mutex con nombres particulares, registros de Windows modificados, archivos o directorios generados por la amenaza, etc.
  • Tools: Software usado por el atacante, que puede incluir backdoors para establecer una comunicación con sus servidores, password crackers o cualquier otro utilitario que utilice el atacante.
  • TTPs: Cómo actúa el atacante para alcanzar su objetivo; a través de una campaña dirigida, en la cual utiliza archivos adjuntos que descargan la amenaza o archivos adjuntos que tienen links a lugares maliciosos.

Les dejo un artículo que está muy bueno, en el cual se hace una analogía entre la investigación de una amenaza y la paleontología. También se mencionan los pasos de una investigación de un APT (Advanced Persistent Threat), los mismos son:

  1.  Adding detection for known modules
  2.  Collecting samples
  3.  Reversing the samples
  4.  Decrypting sophisticated encryption and compression schemes
  5.  Understanding lateral movement
  6.  Outlining multiple attack stages in the correct order
  7.  Mapping C&C infrastructure
  8.  Setting up sinkholes
  9.  Analyzing collected traffic and communication protocols
  10.  Crawling other hosts that understand the same protocol
  11.  Taking down and acquiring images of C&C servers
  12.  Identifying victims, sending out notifications to victims and global CERTs
  13.  Applying forensic analysis and extracting logs, stolen files, other components
  14.  Collecting and analyzing data from KSN, C&C servers, individual victims who are willing to work with us, sinkholes, crawlers, etc.
  15.  Writing a comprehensive report

Fuente: https://securelist.com/blog/opinions/67928/the-art-of-finding-cyber-dinosaur-skeletons/.

Como ven, aplicar CTI para entender una amenaza no es fácil ni rápido, lleva mucha dedicación y paciencia, y puede llevar años. En próximos posts vamos a mencionar algunas herramientas que podemos usar para conseguir información sobre amenazas.

viernes, 17 de marzo de 2017

NoSQL INSecurity: Preview and Basic Attacks

Cuando hablamos de bases de datos NoSQL, lo primero que pensamos es en rendimiento, flexibilidad y escalabilidad, las características propias y necesarias de las bases de datos utilizadas por los gigantes de Internet como Adobe, Amazon, Ebay, Twitter, Google, Netflix...

Pero analizando los features de bases de datos NoSQL como MongoDB, Cassandra, CouchDB, Hbase, Redis o Riak podemos darnos cuenta a primera vista que las medidas de seguridad que poseen son insuficientes o están pensadas para bases de datos utilizadas en ambientes "trusted", donde la posibilidad de ataques sea ínfima y existan otras medidas de protección por fuera del nivel de base de datos. 

A continuación los 4 tipos de datos que pueden almacenar las bases NoSQL por los cuales se las clasifica:

Ahora, ¿mo podemos detectar las debilidades de seguridad de una instalación de base de datos NoSQL para explotar tales fallos, o bien, remediarlos?

PUERTOS UTILIZADOS E INFORMACIÓN DE LA BASE DE DATOS

Empecemos por lo básico: ¿Cuáles son los puertos default que utilizan las bases de datos NoSQL más conocidas?:
  • MongoDB: 27017, 28017, 2780
  • Cassandra: 9160
  • CouchDB: 5984
  • Hbase: 9000
  • Redis: 6379
  • Riak: 8098
Buscando en Shodan van a encontrar varias ;)

Una vez identificada la base NoSQL objetivo de nuestra evaluación, Nmap tiene scripts para obtener información de la infraestructura y las propias bases de datos NoSQL como por ejemplo:

  • NSE mongodb-info y mongodb-databases para MongoDB
  • NSE cassandra-info para Cassandra
  • NSE couchdb-databases y couchdb-stats para CouchDB
  • NSE hbase-master-info para Hbase/Hadoop
  • NSE redis-info para Redis
  • NSE riak-http-info para Riak


AUTENTICACION

En cuanto a la autenticación, en la mayoría de estas bases de datos la autenticación y autorización de usuarios viene deshabilitada por default:

MongoDB: Por defecto en la instalación no se configura ningún método de autenticación, se debe crear usuarios y asignarle roles adecuados para poder habilitar la autenticación de usuarios 
https://docs.mongodb.com/manual/tutorial/enable-authentication/ 

En esta base de datos tenemos dos formas fáciles de chequear si la autenticación se encuentra habilitada, con "Mongo DB Login" de Metasploit o con el NSE mongodb-brute de NMAP:


Cassandra: La autenticación interna de usuarios de Cassandra no se encuentra habilitada por defecto: 
Para validar los mecanismos de autenticación de Cassandra podemos usar el NSE de nmap cassandra-brute:

Redis: Redis no soporta mecanismos de autenticación y autorización de usuarios, lo máximo que se puede hacer al respecto es proteger la instalación con una contraseña. 

Para validar el uso de contraseña o realizar bruteforce sobre la misma se puede utilizar el script de Nmap redis-brute:

Riak : Por defecto la seguridad se encuentra deshabilitada, hay que habilitarla específicamente para poder crear usuarios y autenticarlos. 
http://docs.basho.com/riak/kv/2.2.0/using/security/basics/

CouchDB: Por defecto viene en modo "admin party" que quiere decir que cualquiera puede conectarse con privilegios administrativos, sin utilizar un nombre de usuario ni contraseña de ningún tipo. Luego pueden crearse usuarios y restringir los privilegios administrativos 

Hbase: Con la configuración por defecto, cualquiera puede leer y escribir todas las tablas disponibles en el sistema, luego pueden configurarse mecanismos de autenticación y autorización:

ENCRIPCION EN LA TRANSMISIÓN Y ALMACENAMIENTO DE CONTRASEÑAS

MongoDB: La información de autenticación se encuentra almacenada en la colección system.users de la base de datos admin. Algunas instalaciones de MongoDB permiten acceder anónimamente a esta información y descargar todos los nombres de usuario y hash de las contraseñas ya sean MONGODB-CR (algoritmo de hash MD5 sin salt) o SCRAM-SHA-1 (algoritmo de hash SHA-1 y random salt por usuario) mediante la consulta "show users" en la base de datos admin. También hay scripts JS disponibles para obtener esta información como el siguiente de Average Security Guy: https://github.com/averagesecurityguy/scripts/blob/master/creds.js


Por defecto MongoDB no utiliza encripción de las conexiones entre el cliente y el servidor de base de datos, por lo cual los usuarios y contraseñas pueden ser "sniffeados" e interceptados en la red con herramientas de sniffing como Wireshark. Soporta TLS/SSL para las conexiones de clientes a la base de datos pero esto tiene que ser específicamente habilitado y configurado.

Cassandra: Al habilitar la autenticación en Cassandra, por defecto se habilita el superuser "cassandra" con contraseña: cassandra. Todos los usernames y contraseñas (hasheadas con bcrypt) se almacenan en la tabla system_auth.credentials, una query como la siguiente traería la información de autenticación de los usuarios:

SELECT salted_hash,username FROM system_auth.credentials WHERE username=?

Por ejemplo el siguiente es el salted_hash del usuario cassandra con su default password cassandra:

También las credenciales pueden ser almacenadas en texto plano en archivos .dserc utilizados para la conexión automática de herramientas a la base de datos, asi que si tenemos acceso al file system podemos revisar estos archivos en busca de credenciales.

Por defecto Cassandra no utiliza encripción de las conexiones entre el cliente y el servidor de base de datos, por lo cual los usuarios y contraseñas pueden ser "sniffeados" e interceptados en la red con herramientas de sniffing. Soporta SSL para las conexiones de clientes a la base de datos pero esto tiene que ser específicamente habilitado y configurado.

Redis: Como explicamos en la sección anterior, Redis no posee mecanismos de autenticación de usuarios lo máximo que puede hacerse para proteger esta base de datos es asignarle una contraseña. Esta contraseña se almacena en texto plano en el archivo de configuración redis.conf del servidor en la sección "Security" parámetro requirepass.
En cuanto a la encripción de las conexiones, Redis no soporta ningún mecanismo de encripción, por lo cual la contraseña puede ser "sniffeada" e interceptada en la red con herramientas de sniffing.

CouchDB: En CouchDB los usuarios administradores y sus respectivas contraseñas (hasheadas con el algoritmo SHA-1 y salt) se almacenan en el archivo local.ini del servidor de base de datos. Pueden listarse por medio del browser con la siguiente consulta: http://<ip del equipo>:5984/_config/admins



Las contraseñas de los usuarios no administradores no se almacenan en el archivo de configuración local.ini sino en la base de datos de autenticación llamada: _users. Alli se registra cada usuario como un documento JSON. Para acceder al listado completo de usuarios y sus contraseñas (hasheadas con el algoritmo SHA-1 y salt) se debe realizar la siguiente consulta:  http://<ip del equipo>:5984/_users/_all_docs

Las contraseñas también pueden ser almacenadas en texto plano en los archivos de log si el CouchDB log level es "debug" asi que nunca está de mas revisar los logs en busca de credenciales.

En cuanto a la encripción de las conexiones, CouchDB no soporta ningún mecanismo de encripción, las mismas se realizan por medio de HTTP por lo cual los usuarios y contraseñas pueden ser "sniffeados" e interceptados en la red con herramientas de sniffing.

Riak: En Riak los usuarios y contraseñas (hasheadas con PBKDF2) son almacenados en una tabla en Riak TS. Para la interfaz administrativa Riak Control los nombres de usuario y contraseñas son almacenados en texto plano en el archivo advanced.config parámetro riak_control.auth.user.$username.password (el usuario por defecto es user y la contraseña por defecto es pass):

Por defecto Riak no utiliza encripción de las conexiones entre el cliente y el servidor de base de datos, por lo cual los usuarios y contraseñas pueden ser "sniffeados" e interceptados en la red con herramientas de sniffing. Soporta SSL para las conexiones de clientes a la base de datos pero esto tiene que ser específicamente habilitado y configurado.

Hbase: Al activar la autenticación en HBASE la misma se realiza por medio de Kerberos, que también puede ser utilizado para la encripción de las comunicaciones entre el servidor Hbase y los clientes.

ACCEDIENDO A LAS BASES DE DATOS

Una vez que obtuvimos credenciales de acceso en los pasos anteriores ya sea por medio de bruteforce, sniffing en la red o acceso a las contraseñas almacenadas (o verificamos que la base en cuestión no solicita autenticación) nos conectamos a las bases de datos de la siguiente manera:

MongoDB: La forma más fácil de conectarse es el Mongo CLI client, en Linux puede instalarse por medio de package mongodb-clients. Una vez que tenemos el cliente nos conectamos de la siguiente forma (la base de datos local tiene información del servidor y la base de datos admin es la que contiene las credenciales de los usuarios)
mongo [hostname]:[port]/[database_name]
También podemos escribir archivos javascript y hacer que se ejecuten directamente en el servidor MongoDB -muy útil y divertido por cierto XD-
mongo [hostname]:[port]/[database_name] [script_name]
Mas detalle de comandos soportados por el Mongo CLI en el siguiente enlace: 
https://docs.mongodb.com/manual/reference/mongo-shell/

Adicionalmente algunas versiones de MongoDB poseen una interfaz web para chequear el estado de la base de datos en el puerto 28017:

También existen clientes GUI para conectarse a MongoDB como por ejemplo Robomongo que además de tener una versión portable es multiplataforma. En la siguiente imagen nos conectamos con robomongo anónimamente a la base MongoDB y usamos la query "show users" para ver la información de los usuarios en la base admin: https://robomongo.org/download



Cassandra: La forma más fácil de conectarse a Cassandra es el cqlsh (un cliente en Python que viene por defecto con la instalación). También puede utilizarse herramientas de terceras partes como Helenos: https://sourceforge.net/projects/helenos-gui/



Redis: La forma más facil de interactuar con Redis es el Redis CLI client o redis-cli que puede instalarse en linux por medio del package redis-tools, se debe usar la primera forma de conectarse para Redis sin contraseña y la segunda en caso de tener una contraseña configurada:
redis-cli -h <hostname> -p <port>
redis-cli -h <host> -p <port> -a <password>

Por ejemplo se puede usar el comando info para obtener información del servidor, select (n) para seleccionar una base de datos, get (key) para obtener el valor de alguna string key en particular, a continuación una lista de todos los comandos que pueden usarse en Redis una vez conectado: http://redis.io/commands

CouchDB: En CouchDB es aún más fácil conectarse ya que no necesitamos ningún cliente en particular, se accede directamente por medio del browser en el puerto 5984 de la siguiente forma: http://<ip del equipo>:5984 
Una vez que CouchDB nos responde con el famoso "welcome" podemos entrar a /_utils/ para poder utilizar la herramienta administrativa "Futon" desde allí podemos listar, ver el contenido de las bases de datos, crear bases nuevas, eliminar las bases existentes, configurar la seguridad y muchas cosas más:




Riak: Riak posee una HTTP API que permite conectarse directamente desde el browser y realizar operaciones con Riak KV (la base de datos Riak Key Value) en el puerto 8098. Para verificar esto nos podemos conectar a http://<ip del equipo>:8098 y debería aparecer algo parecido a lo siguiente:
En el siguiente enlace la descripción y todas las operaciones que se pueden realizar por medio de la HTTP API de Riak: http://docs.basho.com/riak/kv/2.2.0/developing/api/http/
Todas las operaciones de GET, POST, PUT y DELETE también las podemos realizar con la herramienta curl que es la recomendada por Basho para Riak.

Adicionalmente hay que revisar si encuentra activa la utilidad administrativa para el management de clusters "Riak Control" a la cual se accede por medio del browser desde las siguientes direcciones: http://<ip del equipo>:8098/admin o https://<ip del equipo>:8096/admin
Si se encuentra activa y no solicita credenciales de autenticación (o pudimos obtener credenciales en los pasos anteriores) desde allí se puede administrar los clusters y los nodos de los clusters:





OTROS ATAQUES Y HERRAMIENTAS

En el próximo post veremos en detalle ataques mas sofisticados a bases de datos NoSQL y algunas herramientas para realizarlos como: