Categorías
Explotación de Software Hacking Networking Services - Software

Atacando el sistema de Event Logging en Windows con Phant0m

Demostración en vídeo del post

Phant0m es un proyecto que se encuentra disponible en Github que se encarga de «matar» los procesos de un sistema Windows que están vinculados con el Event Log. El objetivo de esto evidentemente es el de ocultar las actividades del atacante e impedir que quede registro de cualquier evento en el Event Log del sistema.
Una de las cosas que hay que saber para entender su funcionamiento es el funcionamiento de los procesos compartidos y el proceso Service Host (srvhost.exe) el cual es el encargado de agrupar uno o más servicios con el objetivo de reducir el consumo de recursos. Por ese motivo es tan habitual ver múltiples servicios del tipo «srvhost.exe» ejecutándose en un sistema Windows y de hecho, es una buena práctica que se viene implementando desde Windows 2000 y simplemente funciona, mejora el rendimiento ya que la creación de servicios en Windows es mucho más costosa que en sistemas basados en Unix. No obstante, esto ha traído consigo algunos otros problemas relacionados con la depuración y resolución de problemas, ya que si un proceso de este tipo «crashea» será más difícil saber la causa del error, dado que cualquiera de los procesos que están agrupados podría ser el responsable. Probablemente, este ha sido uno de los motivos por los que en sistemas Windows 10 este comportamiento ha cambiado y cada proceso se ejecuta en de forma separada (sin agrupación) lo que significa que habrá un mayor consumo de recursos pero será más fácil analizar lo que pasa en un proceso. No obstante hay que tener en cuenta que esto solo funciona si el entorno en el que se ejecuta Windows tiene más de 3,5 GB de RAM, de lo contrario se implementa el sistema de agrupación de servicios clásica.
Una vez entendido esto, se puede comprender mejor el objetivo de Phant0m y sus limitaciones.  A grandes rasgos, Phant0m accede al Event Log y procede a encontrar el proceso responsable de dicho servicio,  a continuación detecta y «mata» los hilos vinculados a dicho servicio. Por lo tanto, aunque el Event Log se sigue ejecutando en el sistema ya que no se ha matado el proceso principal, no hará su función principal que es la de recolectar los logs puesto que los hilos que hacen esa tarea no se encuentran en ejecución. Es una forma sutil de evitar la detección por medio del análisis de eventos en un sistema comprometido, sin embargo requiere privilegios elevados para poder realizar dicha operación, lo que significa que es una herramienta pensada para post-explotación en una campaña de Red Team que se encuentra en un estado avanzado.

Uso de Phant0m.

Llegados a este punto, merece la pena mencionar que es una herramienta que se puede personalizar hasta cierto punto. Permite definir la técnica utilizada para detectar el proceso que ejecuta el servicio de Event Log (utilizando SCM o WMI) y posteriormente matar los hilos vinculados. En la primera técnica (usando SCM) se utiliza la función NtQueryInformationThread para obtener la dirección TEB del proceso, leer el campo SubProcessTag y finalmente, matar todos los hilos relacionados con el Event Log. En la segunda técnica la herramienta se encarga simplemente de detectar las DLLs que están asociadas con los hilos filtrando por «wevtsvc.dll», que es precisamente la DLL utilizada por el Event Log y a continuación, los hilos que cumplen con dicho filtro se interrumpen. Como se puede ver es una herramienta que no es para nada compleja, sin embargo es necesario descargar el proyecto (solución) y compilar con Visual Studio .NET, de esta manera se podrá generar un EXE o DLL que luego se podrá transferir y ejecutar el sistema comprometido.

Como se comentaba anteriormente, en el fichero main.cpp se puede definir la técnica de detección que la herramienta utilizará. A continuación, se debe compilar y se generará el binario correspondiente (EXE o DLL).  Es una herramienta orientada a procesos de post-explotación en donde ya se cuenta con un nivel de acceso con privilegios elevados en el sistema, evidentemente esto es requerido para poder acceder y manipular un proceso tan importante como el Event Log.  Si se ejecuta desde una shell sin privilegios suficientes aparecerá un mensaje indicando que no es posible realizar la acción.

Esta herramienta no recibe ningún tipo de argumento por línea de comandos, de hecho, tal como se puede apreciar en el código solamente consta del fichero «main.cpp» desde donde se realiza todo el trabajo aplicando las técnicas descritas anteriormente. No es una herramienta compleja pero la idea que se implementa es muy útil en procesos de post-explotación para evitar dejar rastros en el sistema comprometido.

Tal como se aprecia en la imagen anterior, detecta el PID del servicio Event Log y posteriormente, aplica la técnica seleccionada para interrumpir los threads que están relacionados con dicho servicio.
Por último, en Empire Framework hay un módulo para post-explotación que ejecuta Phant0m en el sistema comprometido sin necesidad de compilar el proyecto ni subir nada, otra de las «maravillas» que hace Empire Framework 🙂

Un saludo y Happy Hack!
Adastra.

 

Categorías
Hacking

Descuentos por Black Friday en Securízame

Ya familiarizados con el trabajo y la formación telemática tras la pandemia del Covid19, cada vez más particulares y empresas optan por continuar y mejorar su formación profesional a través de plataformas digitales; y si dicha formación está especializada en ciberseguridad, Securízame es una apuesta segura con su increíble descuento del 25% en todo su catálogo de cursos online. Securízame, una de las empresas españolas más reconocidas a nivel nacional e internacional en materia de ciberseguridad, de la mano de su CEO, Lorenzo Martínez Rodríguez, su gran plantilla de profesores y colaboradores, y la gran calidad de sus cursos, lleva casi 10 años ocupándose de la formación de profesionales, quienes encuentran en ella los medios y las oportunidades ideales para complementar, mejorar y ampliar sus conocimientos.
La empresa cuenta con una gran variedad de cursos, que imparten tanto de manera presencial como online, que cubren las necesidades más fundamentales en diversas áreas de este sector, como el hacking ético para los equipos de seguridad
ofensiva, o los de hardening, análisis forense y respuesta ante incidentes (DFIR) para los de seguridad defensiva, además de varios cursos específicos sobre otros tópicos que cubren las necesidades de las empresas que buscan bases sólidas en la seguridad de su información.

En 2020 lanzaron al mercado la modalidad de cursos Online++; formación mucho más personalizada y con material actualizado, que además incluye sesiones de tutoría y ejercicios prácticos con el profesorado ¡Todo de manera 100% online, sin necesidad de salir de casa y realizables desde cualquier parte del mundo, en las fechas y horarios que mejor se adapten al alumno que los realiza! Este tipo de formación ha tenido una gran aceptación y se han convertido en los cursos clave de la empresa, por lo que cada año continúan añadiendo nuevos cursos en esta modalidad. Lo mejor de todo es que pueden adquirirse con un 25% de descuento en este Black Friday 2021.
A la hora de comprar el acceso a cualquiera de los cursos online desde la página de Securízame se verá el precio normal del curso. Una vez se lleva a cabo el registro en el mismo, se aplicará automáticamente el 25% de descuento en el precio, por lo que lo único que hay que hacer al momento del registro, es especificar en el campo de comentarios para cuándo se quiere iniciar el curso. Así, Securízame preparará el material para la fecha que el alumno haya indicado.
Esto permite que se puedan comprar los cursos ahora para aprovechar el descuento especial aunque se quiera comenzar el curso más adelante, pudiendo elegir las fechas, ritmo, orden y así planificar que no interfiera con el resto de actividades del estudiante.
Para empresas que buscan formar a toda su plantilla en un área específica, Securízame también ofrece formación a medida para instituciones de forma privada, ya sea online, online en directo, o bien, de manera presencial.
Además de esta gran oferta formativa, Securízame también brinda atención especializada a empresas y particulares con diversos servicios, como Reborn (una eficiente solución de copias de seguridad a prueba de ransomware), Remote (un
sistema modular de teletrabajo seguro para empresas), desarrollo de herramientas e implantación de soluciones de seguridad a medida, consultoría y asesoría de seguridad, peritaje informático forense y respuesta ante incidentes de ciberseguridad e incluso formaciones privadas para organizaciones públicas y privadas. ¡Todo adaptándose al presupuesto y necesidades de cada empresa, brindando una atención muy especializada!
Estos descuentos Black Friday sólo son válidos a partir del Viernes 26 de noviembre de 2021 a las 00:00 hasta el Lunes 29 de noviembre de 2021 a las 23:59 en horario peninsular de España.  Para completar el fin de semana de Black Friday, Securízame ha decidido regalar el acceso a uno de sus cursos online++: «Aplicación del modelo Zero Trust en AWS» a un agraciado entre todos aquellos que participen en la dinámica preparada en Twitter, además de que al comprar cualquiera de sus cursos, se obtiene una participación extra. Se podrá tener más información sobre cómo ganar este obsequio en el blog de la página web y en sus redes sociales.
Para más información u orientación sobre los cursos y servicios de Securízame, se puede contactar con la empresa a través del formulario de su página web https://www.securizame.com/contacto/ o bien en el mail contacto@securizame.com, donde incluso se orienta a aquellos que no saben qué tipo de formación es la que mejor se adapta a sus necesidades. Esta es la mejor oportunidad para continuar la formación en ciberseguridad de cualquier profesional que lleve tiempo o este empezando en esta área, con cursos online y online++ de excelente calidad, con profesores de gran experiencia y a un precio irrepetible.

Categorías
automatizacion Hacking Hacking Python Networking Services - Software

Docker Stack: Cómo desplegar servicios de Docker Compose en Docker Swarm

Demostración en vídeo de este post

Docker Stack es una tecnología que se encuentra integrada en cualquier instalación de Docker y permite desplegar un conjunto de servicios definidos en un compose directamente en un Swarm previamente inicializado. Es importante tener en cuenta que para ello se utiliza el comando “docker stack deploy” y que hay dos restricciones que se deben cumplir:
1. La máquina desde donde se ejecuta «docker stack» debe estar unida a un Swarm y tener los permisos necesarios para crear servicios, es decir, debe tener el rol de «manager»
2. El fichero Compose debe tener una versión “3.0” o superior.

Para poder probar su funcionamiento lo mejor es crear un compose. A continuación se describen los pasos para crear una API Rest muy básica utilizando Flask y Redis, la cual se declarará en un fichero YAML con la sintaxis soportada por Docker-Compose.

Creación el fichero Dockerfile y la aplicación con Flask

El primer paso consiste en crear una aplicación con Flask, que será algo tan simple como una API Rest con un único endpoint y que se conectará con un servidor de Redis para contar el número de veces que los usuarios acceden. El código fuente del fichero app.py se lista a continuación

Como se puede ver, son necesarias las dependencias de Flask y Redis, por lo tanto se debe crear un fichero «requirements.txt» que va a contener ambas librerías, las cuáles se instalarán de forma automática utilizando PIP. Dicho fichero de texto simplemente contendrá el texto «flask» y «redis» en líneas separadas y con eso es suficiente. Finalmente, es el momento de crear el fichero Dockerfile que servirá para declarar la forma en la que se debe construir una imagen que permita instalar las dependencias descritas anteriormente y ejecutar el programa «app.py» en cualquier contenedor que utilice dicha imagen.


Ahora se puede tener un servicio web básico, es el momento de trasladar esto a un compose.

Creación de los servicios con Docker Compose.

En este punto hay que crear un fichero YAML que contenga los servicios necesarios para que la aplicación funcione correctamente, dichos servicios serán los dos: Uno que utilizará la imagen creada en el paso anterior y otro para el servidor de Redis. El fichero «compose.yml» se lista a continuación.

El compose es muy sencillo, define los dos servicios de la API Rest utilizando Flask y Redis. No obstante, como se puede observar la construcción de la imagen para el servicio «web» está configurada para utilizar un registro de Docker que está ubicado en localhost, en el puerto 5000. Será en dicho registro donde Docker Compose guardará la imagen después de construirla gracias a la opción «build» declarada en el fichero. Por lo tanto, antes de continuar es necesario crear el registro, para ello se puede crear un servicio en el Swarm con el comando «docker service».


Una vez se ha creado el registro de Docker, se puede ejecutar un comando como docker-compose up y ver que todo ha funcionado correctamente.

Desplegar el Stack

Ahora que está todo preparado, lo único que queda haciendo falta es desplegar el Stack en Docker Swarm. Para ello se puede ejecutar el comando «docker stack deploy» tal como se enseña en la siguiente imagen.

El stack se despliega en el Swarm, que como se puede ver aparece como un servicio más ejecutado por el cluster pero además, se aprecia que el nombre es «NOMBRESTACK_SERVICIOCOMPOSE». De esta manera es fácil de identificar un servicio que ha sido desplegado previamente utilizando Docker Stack. A partir de este punto, se trata de servicios que se pueden gestionar con el comando docker service como ocurre con cualquier otro, es decir, se pueden escalar, aplicar rolling updates o eliminar sin ningún problema, solamente que ahora se puede hacer o bien utilizando «docker service» o «docker stack».
Como puedes ver el uso de «docker stack» es simplemente la alternativa que ofrece Docker para que puedas desplegar los servicios que tienes en Compose directamente en un Swarm, su gestión es sencilla y muy intuitiva por lo que te recomiendo que lo pruebes para aprender cómo funciona. Por último, recuerda que tienes el vídeo en YouTube que se encuentra al inicio de este post y que seguramente te ayudará a aclarar dudas que te pueden surgir en el procedimiento que he explicado aquí.

Un saludo y Happy Hack!
Adastra.

Categorías
Explotación de Software Hacking Networking Services - Software

Movimientos laterales con Empire Framework y Chisel

Demostración en vídeo de este post

 

Empire Framework y Chisel se pueden integrar gracias a los componentes disponibles en Empire Framework.  Es posible aprovechar las funcionalidades de Chisel en Empire Framework, sin embargo antes de continuar, es conveniente repasar el uso básico de Chisel y para ello se encuentra disponible el post titulado «Pivoting y movimientos laterales con Chisel y SSHL» en donde se describe el uso de la herramienta y cómo puede ayudar en las labores de evasión de firewalls o restricciones de red gracias al establecimiento de túneles.

Entorno de pruebas con Empire Framework y Chisel

Se empezará por lo básico, hay que montar un entorno que permita realizar las pruebas para saber hasta donde se puede llegar con la herramienta y luego, ver las opciones que tiene disponibles el módulo powershell/management/invoke_sharpchisel de Empire Framework.
En este caso la configuración planteada es la siguiente:

  • Máquina del atacante: Kali con Empire Framework instalado y actualizado. Tiene conectividad con la máquina comprometida pero no con la máquina objetivo. Con Empire Framework se pretende usar la máquina comprometida como un pivote para llegar al objetivo.
  • Máquina comprometida (pivote): Windows 8.1 conectado a dos redes, la primera de ellas conecta con la máquina del atacante y la segunda con la máquina objetivo.
  • Máquina objetivo: Ubuntu (metasploitable 2 por simplicidad y para evitar consumo de RAM innecesario con varias VMs levantadas). Máquina conectada a una única red, solamente tiene conexión con la máquina comprometida y no llega a la máquina del atacante.

Con el entorno explicado, procede ver qué opciones admite el módulo de invoke_sharpchisel, las cuales se pueden ver en la siguiente imagen.

Las opciones son simples, hace falta indicar un agente que será donde se ejecute el módulo, la especificación del túnel  para el acceder al objetivo y la ubicación donde el servidor de Chisel se encuentra en ejecución. Hay un detalle importante y es que tal como indica en la descripción del módulo, éste se ha probado sobre la versión 1.7.2 y a la fecha de redactar este post la última versión es la 1.7.6. No obstante, las pruebas se han hecho con la última versión de la herramienta y como se verá a continuación, han funcionado correctamente, lo único es que en el servidor aparecerá un mensaje en el que se indica que el cliente y el servidor de Chisel no están usando la misma versión pero no afecta al comportamiento de ninguno de los dos componentes.

Ahora bien, para que se pueda pivotar es necesario ejecutar el componente servidor en la máquina comprometida, que es precisamente la que permitirá el acceso a la máquina objetivo. Como se ha mencionado en el post de «Pivoting y movimientos laterales con Chisel y SSHL«, el componente servidor es el que habitualmente debe proporcionar las rutas para poder pivotar. En el repositorio de Chisel se encuentra el ejecutable para Windows, por lo tanto es tan simple con subir dicho binario a la máquina comprometida y lanzarlo con las opciones adecuadas.

Ahora es el momento de utilizar el módulo de Empire Framework que simplemente ejecutará el componente cliente para establecer la conexión con el servidor.

Como se puede ver en la imagen anterior resulta muy simple, se establece la conexión con el servidor de Chisel, el cual se ha tenido que establecer en la opción Server y a continuación, con la opción Remote se indica cómo debe crearse el túnel. En este caso concreto, el puerto «7890» se abrirá en la máquina comprometida y posteriormente, todo el tráfico entrante por dicho puerto será enrutado a la IP 10.10.1.113 en puerto 8180, que es precisamente el servicio de Tomcat que se encuentra disponible en Metasploitable 2.
Hay que tener en cuenta que la apertura del puerto «7890» no es inmediata, es prudente esperar entre 30 segundos y un minuto antes de intentar conectarse, a veces puede tardar un poco más.
A partir de este punto es posible utilizar el módulo de Chisel en Empire Framework para crear tantos túneles como sea necesario y pivotar a los diferentes servicios que se encuentran disponibles en el objetivo, es decir, no hay ningún problema a la hora de crear múltiples túneles contra diferentes IPs o servicios a los que el atacante no puede acceder directamente pero sí la máquina comprometida.

Como se puede ver en la imagen anterior, basta simplemente con modificar la opción Remote con la especificación del túnel adecuada y ejecutar el módulo. No ha sido necesario establecer otras opciones como Server o Agent ya que éstas se habían establecido previamente.
En un próximo post hablaremos un poco más de otro componente interesante en Empire Framework que permite levantar un servidor Chisel y automatizar aún más el trabajo.

Un saludo y Happy Hack!
Adastra.

 

Categorías
automatizacion Hacking

Cómo crear un cluster de contenedores con Docker Swarm

Demostración en vídeo de este post.

 

Kubernetes no es la única alternativa que se encuentra disponible a la hora de crear clusters de contenedores y gestonionar cuestiones tan importantes como el escalado y la disponibilidad, una alternativa sencilla pero muy potente es Docker Swarm. Se trata de un orquestador de contenedores Docker que viene integrado en cualquier instalación de Docker. Además de no tener que instalar ningún componente adicional, Swarm se caracteriza por permitir la gestión completa del enjambre desde línea de comandos utilizando instrucciones sencillas y fáciles de memorizar, siguiendo la misma dinámica del cliente de Docker para la gestión de otros componentes básicos como redes, volúmenes, imágenes, etc.
Algunas de las características que hacen que sea una solución interesante se listan a continuación:

  • Gestión del enjambre descentralizada: Cualquier nodo con el rol de «manager» puede realizar las operaciones administrativas sobre el cluster y dichas acciones se sincronizarán en todos los nodos y otros managers. Tiene gestión automática de conflictos por medio de bloqueos en las operaciones lo que impide que dos managers ejecuten operaciones sobre los mismos objetos del cluster al tiempo, esto a efectos prácticos significa que los objetos del cluster no se corromperán debido a la concurrencia.
  • Diseño basado en el estado deseado: Igual que ocurre con Kubernetes, Docker Swarm permite la definición de un «estado deseado» para declarar el número de replicas adecuado que se deben ejecutar en los nodos y es capaz de escalar de forma automática para conseguir dicho estado deseado.
  • Balanceo de carga: Cuenta con mecanismos para el balanceo de carga y «routing mesh». Si un cliente realiza una petición a un nodo y éste no tiene un contenedor en ejecución, uno de los managers se encarga de realizar el enrutamiento adecuado a otro nodo que sí será capaz de atender a la petición del cliente.
  • Seguro por defecto: Todas las conexiones entre managers y nodos (workers) se realizan utilizando mTLS. El cifrado se realiza utilizando una CA compartida en todos los nodos y que se genera de forma automática en el momento en el que se crea el enjambre. El administrador también tiene la posibilidad de indicar su propia CA si hace falta.
  • Rolling Updates: Es posible cambiar la imagen de un servicio en caliente. Si por el motivo que sea se quiere actualizar la imagen base de uno de los servicios en ejecución, es posible hacerlo sin tirar el servicio en todos los nodos, en su lugar dicha actualización se realiza nodo a nodo, garantizando la disponibilidad del servicio.

Hay otras características que puedes leer aquí si te interesa.

Creación y configuración de un cluster con Docker Swarm

En primer lugar, la creación del enjambre se llevará a cabo en un sistema que será un manager para el cluster, es decir, que tendrá la posibilidad de ejecutar labores administrativas. Una vez creado, las otras máquinas tendrán la posibilidad de unirse como nodos «worker», es decir, instancias de Docker que lo único que harán será levantar los contenedores que los managers establecen en forma de «servicios».

A partir de este punto, cualquier instancia de Docker se podrá unir al cluster con el rol de «worker» o «manager» en función del token utilizado tal como se indica en el mensaje que aparece después de crear el cluster.

Desde cualquiera de los nodos «manager» se realizará la gestión del cluster, por ejemplo se pueden crear servicios, generar tokens para que otros nodos manager se puedan unir, se pueden gestionar los nodos «worker», entre otras cosas.

En la imagen anterior se pueden apreciar algunas de las operaciones típicas que se suelen ejecutar desde un manager, como se puede ver son comandos sencillos y directos, fáciles aprender y que están integrados en el cliente de Docker por lo que resulta especialmente interesante para aprender sobre cómo funciona un orquestador antes de entrar en las complejidades de Kubernetes.

Para que veas con un poco más de detalle el funcionamiento de Docker Swarm te recomiendo que le eches un vistazo al vídeo que aparece al inicio de este post.

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Services - Software Web Applications

Pentesting sobre APIS Rest: OWASP API Security Project

Las APIs Rest son componentes habituales en las aplicaciones web modernas y en las infraestructuras basadas en microservicios, se caracterizan por su simplicidad gracias al uso del protocolo HTTP, algo que sin duda representa una ventaja considerable frente a los servicios web tradicionales basados en SOAP. Como ocurre con cualquier aplicación web, si se desea realizar pruebas de pentesting lo primero que se debe hacer es entender para qué se ha diseñado, el «protocolo» que se debe cumplir para invocar a cada endpoint y las restricciones definidas a la hora de acceder a información. No hay que olvidar que al basarse en protocolo HTTP, pueden ser consultadas utilizando cualquier cliente compatible, desde un navegador web hasta una herramienta orientada a este tipo de aplicaciones como PostMan. En cualquier caso, aplican las mismas reglas que se siguen cuando se prueba una aplicación web estándar, aunque hay algunas diferencias y cuestiones que no son tan comunes en las aplicaciones web y precisamente por ese motivo, ha surgido el proyecto OWASP API Security Project. Se trata de un proyecto de la comunidad OWASP reciente (data del 2019) y es muy similar al proyecto OWASP Top 10 ya que define los 10 defectos más peligrosos para la seguridad de este tipo de componentes.
En este post te explicaré en que consiste cada uno de los elementos de la guía, sin embargo recuerda que en la plataforma de THW tienes una formación completa sobre Hacking en APIs Rest en el que se explora en detalle y con un enfoque 100% práctico cómo realizar pruebas de pentesting contra estos componentes tan comunes en infraestructuras web.

API1:2019 Broken Object Level Authorization

Este tipo de vulnerabilidades no son nuevas y de hecho, se encuentran presentes en el OWASP Top 10 desde hace ya varios años adoptando diferentes nombres, probablemente el más conocido y extendido es IDOR (Insecure Direct Object Reference). Se trata de un tipo de vulnerabilidad muy habitual en APIs Rest debido a la falta de validaciones a la hora de acceder a información partiendo de parámetros enviados por el usuario. Normalmente este tipo de problemas generan fugas de información sensible y acceso no autorizado a recursos protegidos. Como en cualquier aplicación web, su solución parte de la buena definición de roles y perfiles, declarando exactamente a qué recursos puede acceder cada usuario autenticado y no autenticado, así como la forma en la que debe  hacerlo.

API2:2019 Broken User Authentication

En la posición 2 se encuentra una de las vulnerabilidades más comunes en aplicaciones web, se trata de mecanismos de autenticación inseguros o poco efectivos. En esta categoría es común encontrarse con mecanismos de autenticación débiles basados en información del usuario, algoritmos criptograficos rotos u obsoletos, tokens de autenticación y/o cookies de sesión predecibles, entre otras cosas. En las APIs Rest es especialmente habitual el uso de tokens JWT y tecnologías similares, las cuales en ocasiones son difíciles de securizar, algo que se suele analizar en detalle cuando se ejecuta un pentest web.

API3:2019 Excessive Data Exposure

Es posible que la API exponga endpoints que revelan demasiada información sobre los usuarios o el sistema, algo que un atacante puede utilizar para perfilar la aplicación y buscar el mejor vector de ataque. En esta categoría se encuentra la información que se puede extraer de cabeceras HTTP, tokens JWT, información en las estructuras JSON de las respuestas, entre otras cosas.

API4:2019 Lack of Resources & Rate Limiting

Es muy común encontrar APIs Rest que no establecen mecanismos de control sobre el número de peticiones que puede realizar un usuario y el tiempo que debe existir entre cada una de ellas. Esta situación en ocasiones pueden afectar el rendimiento general de la aplicación o dar lugar a condiciones de denegación del servicio.

API5:2019 Broken Function Level Authorization

Es una vulnerabilidad muy similar a la API1:2019 pero con la diferencia de que en este caso el atacante cuenta con un nivel de acceso o autorización determinado en la aplicación. Ocurre cuando no se definen y/o implementan adecuadamente las reglas que gobiernan el acceso a recursos. La solución consiste en declarar una matriz de roles y permisos con las reglas que debe seguir la API Rest para impedir que un usuario sin el rol adecuado o con privilegios insuficientes pueda acceder a recursos que no están asignados a su nivel de acceso.

API6:2019 Mass Assignment

Ocurre cuando en las peticiones HTTP se envía una estructura JSON que corresponde fielmente con el modelo/objeto en el lado del servidor y en dicha petición, es posible especificar atributos que posteriormente y sin ningún tipo de validación por parte del servidor, se asignan a un objeto en el backend. Esto es un problema cuando se utilizan librerías de parseo de estructuras JSON y dicha estructura se convierte a un objeto en el servidor con todos y cada uno de los valores que vengan en la petición. Se trata de una vulnerabilidad muy concreta en APIs Rest y que en ocasiones es difícil de detectar ya que el atacante debe conocer el modelo de datos que hay en el servidor y esto no siempre está a su alcance. Para ello, el atacante puede leer la documentación disponible o analizar cada endpoint y sus respuestas para descubrir cómo se encuentra definido el modelo de datos en el lado del servidor.

API7:2019 Security Misconfiguration

Otra de las vulnerabilidades que también se encuentra descrita en el OWASP Top 10, en este caso se refiere principalmente a problemas que se pueden presentar en configuraciones por defecto en los frameworks y librerías utilizados para crear la infraestructura Rest, así como otros problemas relacionados con cabeceras mal configuradas, métodos HTTP que se encuentran habilitados y son innecesarios, una política CORS demasiado permisiva, etc.

API8:2019 Injection

Se trata de las vulnerabilidades de inyección clásicas que se encuentran descritas en todas las versiones del OWASP Top 10.  En este caso está prácticamente en la última posición debido a su bajo nivel de incidencia en las aplicaciones modernas.

API9:2019 Improper Assets Management

Una API Rest normalmente suele exponer más puntos de acceso que una aplicación web tradicional, por ese motivo la gestión adecuada de cada uno de esos activos es vital. Este tipo de problema se produce precisamente cuando se pierde el control «de lo que hay», de los endpoints que se encuentran expuestos en entornos de desarrollo, staging o producción. Cuando se crean demasiados endpoints que luego no se van a utilizar porque eran para hacer pruebas y exponen vulnerabilidades que puede explotar un atacante. Aunque está en prácticamente la última posición, es un problema que puede ser critico en una API Rest, especialmente en la medida en la que va evolucionando y su tamaño aumenta.

API10:2019 Insufficient Logging & Monitoring

Finalmente, este punto hace referencia al mismo problema descrito en el OWASP Top 10, el cual en su versión del 2017 también ocupa esta misma posición. Se refiere a la falta de mecanismos de monitorización o la ausencia de un control y seguimiento de los eventos reportados por dichos mecanismos, haciendo que un ataque activo se lleve a cabo sin ser detectado.

Como se puede ver, el enfoque es diferente al empleado en las aplicaciones web tradicionales, por ese motivo merece la pena aprender a llevar a cabo estas pruebas de la forma más completa y profesional posible ya que si eres pentester web es algo que tarde o temprano tendrás que hacer (o casi seguro ya haces con frecuencia).

Un saludo y Happy Hack!
Adastra.

 

Categorías
Hacking Services - Software

Evil-WinRM: Shell sobre WinRM para pentesting en sistemas Windows – Parte 1 de 2

Demostración en vídeo de este post


WinRM es la implementación de Microsoft para el protocolo WS-Management
, el cual es habitual en sistemas Windows y muy especialmente en sus versiones Server. Ha sido diseñado con el objetivo de permitir la administración remota del sistema y si bien, no viene habilitado por defecto en las estaciones de trabajo basadas en Windows (7, 8, 8.1 o 10), en los sistemas Windows Server es un servicio que suele estar disponible por defecto en el puerto 5985.
Si se cuenta con acceso al sistema, ya sea teniendo el usuario y la contraseña, el usuario y el hash NTLM de su contraseña o un ticket TGT de Kerberos, es posible realizar una conexión contra dicho servicio y obtener una shell en el sistema. Evidentemente, esto significa que puede ser útil en la etapa de post-explotación cuando ya se ha conseguido acceso al sistema y se tiene cierto control sobre él. Esto nos lleva a una de las utilidades más interesantes que se encuentran disponibles actualmente para poder establecer conexiones contra el servicio de WinRM y llevar a cabo pruebas de post-explotación, se trata de Evil-WinRM

Instalación de Evil-WinRM.

Hay 4 métodos de instalación que se encuentran disponibles en la documentación del repositorio, no obstante considero que la instalación partiendo del código fuente es muy sencilla y permite tener el código actualizado en cualquier momento simplemente ejecutando un «git pull», en este caso el único requisito es instalar las gemas de Ruby que son dependencias obligatorias y que también se indican en la documentación. Una vez se realiza la instalación del programa, basta con ejecutar el script «evil-winrm.rb» y ver las opciones que admite.

A partir de este punto es posible realizar conexiones a sistemas Windows que tengan habilitado WinRM. Evidentemente, para llevar a cabo el proceso de autenticación es necesario tener una cuenta de usuario o ticket TGT que sean validos en el objetivo, por ese motivo se trata de una herramienta que está orientada a procesos de post-explotación. A continuación, se describe cómo utilizar Evil-WinRM con los diferentes escenarios en los que nos podemos encontrar durante un proceso de post-explotación en sistemas Windows.

Autenticación con usuario y contraseña.

En el caso de que se cuente con un usuario y contraseña validos es tan simple como indicar esos detalles mediante las opciones «-u» y «-p». Con la opción «-u» hay que indicar el usuario con el que se pretende realizar la conexión y es obligatoria cuando no se realiza el proceso de autenticación usando Kerberos. Por otro lado, en la opción «-p» hay que indicar la contraseña y es opcional, en el caso de no querer introducirla durante la ejecución del comando, la herramienta la pedirá posteriormente para realizar la autenticación. Evidentemente puede ser una buena práctica no indicar la opción «-p» ya que de esa manera no hay que introducir la contraseña del sistema remoto en plano y tampoco queda registro de ella en el historial de comandos ejecutados.

Como se puede apreciar el procedimiento no puede ser más simple. La herramienta se encarga de realizar una conexión con la IP/hostname indicado en la opción «-i» y dado que no se ha indicado una contraseña con la opción «-p», se pide luego que se introduzca. A continuación, genera una shell semi-interactiva que permite ejecutar instrucciones en el sistema remoto.

Autenticación con usuario y hash.

No siempre se contará con el usuario y la contraseña y es posible que durante el proceso de post-explotación se haya conseguido un listado de hashes para todos o algunos de los usuarios disponibles en el sistema comprometido. Si se ha obtenido un hash para una cuenta de usuario, éste se puede utilizar para llevar a cabo el proceso de autenticación sin necesidad de conocer la contraseña (Pass The Hash).

La opción «-H» es precisamente la que permite indicar el hash de la contraseña asociada al usuario que se especifica con «-u». Como se puede ver en la imagen anterior resulta muy sencillo, aunque evidentemente se ha tenido que obtener el hash de alguna manera durante la post-explotación (usando Mimikatz, Empire Framework, Nishang, PowerSploit, ntdsutil, DiskShadow, VSSAdmin, Metasploit Framework y un largo etcétera).

Autenticación mediante Kerberos.

El mecanismo de autenticación que queda por explicar es el de Kerberos, el cual en realidad es muy simple. Se debe tener un ticket TGT, el cual permitirá autenticarse en el sistema remoto utilizando la cuenta de usuario asociada a dicho ticket. Hay que tener en cuenta que en este mecanismo ya no se utilizan las opciones «-u» y «-p», en su lugar se debe indicar el dominio del directorio activo (en donde estará el KDC de Kerberos preparado para llevar a cabo el proceso de autenticación) con la opción «-r».

Aunque en la imagen anterior se puede ver que se ha llevado a cabo el proceso de autenticación sin ningún problema, hay que tener en cuenta 4 detalles importantes:

  1.  Se ha tenido que generar previamente un ticket TGT valido.
  2. Dicho ticket debe estar definido en la variable de entorno KRB5CCNAME.
  3. El sistema tiene que tener instalado el paquete krb5-user.
  4. La configuración del fichero /etc/krb5.conf debe incluir el REALM donde se encuentran los detalles del dominio y el KDC.

En el vídeo que está anclado a este post explico en detalle cada uno de estos puntos para que se pueda llevar a cabo el proceso de autenticación correctamente. No es muy complicado, pero en ocasiones puede dar problemas si alguno de los puntos anteriores no se ha hecho bien.

Aunque en este post solamente se han mencionado las alternativas a la hora de autenticarse en un sistema Windows utilizando Evil-WinRM, hay otras opciones que se encuentran disponibles en la herramienta una vez estás autenticado en el sistemas y eso es precisamente de lo que se hablará en el siguiente post.

Un saludo y Happy Hack!
Adastra.