Quick Tips – Fuerza bruta a tokens JWT

Facebooktwitterlinkedinmail

El uso de JSON Web Tokens (JWT) se ha extendido mucho debído a la facilidad que nos ofrecen para identificar y asignar privilegios.

Los tokens están compuestos por 3 partes. La cabecera, el contenido y la firma.

En la cabecera veremos el algoritmo utilizado para la firma, en el contenido la identificación, los permisos y normalmente un timestamp y por último la firma que puede ser generada mediante un secreto o utilizando clave privada/pública.

jwt

En el caso de localizar un JWT durante un pentest, es importante verificar que el token es robusto. Por lo tanto, si descubrimos un token que utiliza un secreto en la firma deberemos realizar un ataque de fuera bruta para comprobar que el secreto no puede ser descubierto. De serlo, seríamos capaces de generar nuestros propios tokens, comprometiendo de este modo la seguridad del sitio que utilice estos tokens.

Para relizar fuerza bruta a tokens JWT podemos utilizar hashcat de la siguiente manera:

.\hashcat64.exe -m 16500 -a 0 .\jwt.txt .\rockyou.txt -r .\kamaji34K.rule.txt

Con el parámetro -m indicaremos que es un token JWT, con el parámetro -a indicaremos que el tipo de ataque es Straight, después en el fichero jwt.txt tendremos nuestro token JWT y utilizaremos como diccionario rockyou y las reglas kamaji34K presentadas en rootedcon.

Además de esta verificación es importante verificar que:

  • El algoritmo NONE no puede ser utilizado.
  • Los tokens no pueden ser robados.
  • Es posible para un usuario invalidar el token.
  • En el payload no se almacena información sensible.
  • El token no es guardado de forma insegura en el navegador.

OSCP – Mi experiencia y consejos

Facebooktwitterlinkedinmail

El blog ha tenido poca actividad durante esto últimos meses debido a que he estado trabajando en la certificación Offensive Security Certified Professional (OSCP) de Offensive Security.

Por lo tanto, en esta entrada explicaré mi experiencia e intentaré dejar algunos consejos para aquellos que estáis tratando de obtener esta certificación o tengáis pensado obtenerla en un futuro. De todos modos, como esta entrada podréis encontrar cientos en Internet ya que no está permitido entrar en detalle de la certificación.

Leer más

Exfiltración DNS para XSS con rascal

Facebooktwitterlinkedinmail

Hola chicos! Hoy os vamos a traer un poco de ¡exfiltración DNS para XSS con rascal!. Esta técnica nos permitirá extraer datos a partir de una vulnerabilidad XSS que nos será especialmente útil cuando nos encontramos con políticas de CSP muy restrictivas o para cuando no queremos hacer mucho ruido 🙂

Leer más

Quick Tips – Fuerza bruta con Brutespray

Facebooktwitterlinkedinmail

Uno de los pasos fundamentales al realizar un test de intrusión es verificar si los servicios protegidos con contraseña utilizan contraseñas débiles. Cuando esta prueba se debe realizar en una red grande y con muchos servicios esto puede convertirse en un trabajo complicado. Por esto queremos presentar en este post Brutespray, una herramienta que nos ayudará con esta tarea.

Brutespray es una herramienta escrita en python por  Shane Young/@x90skysn3k y Jacob Robles/@shellfail. Esta automatiza ataques de fuerza bruta a diferentes servicios utilizando medusa. Este ataque probará diferentes usuarios y contraseñas y nos indicará si alguna de las combinaciones es correcta.

Leer más

Explotar Consul para obtener una reverse shell

Facebooktwitterlinkedinmail

Durante un test de penetración, uno de los objetivos más importantes son los equipos y programas de monitorización y configuración. Tomar el control de estos normalmente implica poder tener acceso a toda la red. En esta entrada veremos como una configuración incorrecta nos puede permitir explotar Consul para ejecutar código en los equipos que estén ejecutando el agente.

Consul es una herramienta para el descubrimiento y configuración de servicios. Entre otras funcionalidades permite el descubrimiento de servicios, alertas sobre la salud de los clusters, almacenamiento de configuraciones dinámicas etc…

La funcionalidad que explotaremos en este caso es la de alertas del cluster. Los agentes de consul permiten crear checks de salud mediante la API. Estos checks pueden ser de diferentes tipos, incluso pueden permitir la ejecución de scripts.

Verificando la ejecución de comandos

Por defecto, los agentes de consul escuchan en el puerto 8500 y permiten peticiones HTTP. Durante un pentest, si descubrimos un puerto 8500 abierto será importante verificar si se trata de la API de consul. Para esto,  podemos realizar un simple: curl ip:8500 y la respuesta será Consul Agent.

Leer más

Extensión Autorize, buscando problemas de control de acceso

Facebooktwitterlinkedinmail

Cuando se analiza la seguridad de una aplicación web, uno de los puntos más importantes a revisar es como funciona la autorizacion y el control de acceso. Esto es vital para detectar problemas de autorización y autenticación también llamados problemas de pérdida de control de acceso. Vulnerabilidad que encontramos en el número 5 del TOP 10 de OWASP. En esta entrada veremos como con Burp podemos realizar esta verificación de forma sencilla con la extensión Autorize.

Instalación

Para utilizar esta extensión deberemos tener descargado el standalone de Jython que podremos descargar de: http://www.jython.org/downloads.html

Una vez descargado vamos a Extender – Options y en Python Environment seleccionamos el fichero JAR descargado.

Tras esto vamos a la pestaña BApp Store, seleccionamos Autorize y clicamos en Install para instalar la extensión:

Leer más

CIS Benchmarks para Kubernetes con kube-bench

Facebooktwitterlinkedinmail

CIS Benchmarks son estándares de seguridad para diferentes sistemas, realizadas por el Center for Internet Security, y que tienen como objetivo hardenizar nuestros Sistemas Operativos. El cumplimiento de estos estándares son comunes en entornos que tienen que cumplir PCI-DSS, GDPR o son de uso gubernamental así que si nos preocupa la seguridad, siempre acertaremos si cumplimos los  CIS Benchmarks.

Para verificar las reglas de CIS Benchmark vamos a utilizar kube-bench que es una herramienta de Aqua que nos va automatizar todo el proceso de validación de reglas CIS Benchmark para Kubernetes.

Validar Workers

Para validar los nodos podemos levantar un POD que automáticamente nos compruebe cada una de las reglas.

kubectl run --rm -i -t kube-bench-node --image=aquasec/kube-bench:latest --restart=Never --overrides="{ \"apiVersion\": \"v1\", \"spec\": { \"hostPID\": true } }" -- node --version 1.8

Donde –version es la versión de Kubernetes que utilizamos. De momento sólo está hasta la 1.8.

Como curiosidad, en la parte de –override veréis que se le pasa { \"hostPID\": true } esto lo que hace es que el container se ejecute con el PID del host para que tenga permisos para hacer los checks en el host.

Validar Master

Para validar el Master, en la documentación de Aqua se indica que debemos ejecutar un container en el nodo respectivo. Si permitimos que nuestro nodo master ejecute container, podemos utilizar kubectl.

kubectl run --rm -i -t kube-bench-master --image=aquasec/kube-bench:latest --restart=Never --overrides="{ \"apiVersion\": \"v1\", \"spec\": { \"hostPID\": true, \"nodeSelector\": { \"kubernetes.io/role\": \"master\" }, \"tolerations\": [ { \"key\": \"node-role.kubernetes.io/master\", \"operator\": \"Exists\", \"effect\": \"NoSchedule\" } ] } }" -- master --version 1.8

Si no permitimos ejecución de PODs en el nodo master, entonces podemos ejecutar directamente el container en el docker del nodo master.

docker run --pid=host -t aquasec/kube-bench:latest master

Aquí vemos el comando y las salida.

kube-bench

Más info en https://github.com/aquasecurity/kube-bench

Saludos!

¿Confías tu seguridad al XSS auditor de Chrome?

Facebooktwitterlinkedinmail

En esta entrada vamos a ver por qué no podemos confiar la seguridad de nuestra web al XSS auditor de Chrome.

Hace un tiempo ya realizamos una introducción a los ataques Cross-Site Scripting XSS. En estos el atacante utiliza las entradas de datos de un sitio web para inyectar scripts maliciosos (normalmente JavaScript) que después se ejecutarán en el navegador de otros usuarios.

Como estos ataques se basan en la entrada de datos en un sitio web, Chrome, entre otros navegadores, tiene un mecanismo de seguridad para evitarlos. El problema es que este mecanismo de seguridad tiene varios problemas según el tipo de XSS al que se enfrente.

El auditor de Chrome se ejecuta durante la fase de análisis del HTML e intenta encontrar reflejos de la solicitud en el cuerpo de la respuesta. Por lo tanto, en ningún caso podrá mitigar los ataques XSS almacenados, ya que la inyección no tiene porque producirse en la misma petición, o DOM, ya que la página en sí (la respuesta HTTP) no cambia, pero el código del lado del cliente contenido en la página se ejecuta de forma diferente debido a las modificaciones maliciosas que se han producido en el DOM.

En el caso de encontrar una posible reflexión, el auditor de Chrome puede ignorar el script malicioso, o puede bloquear la página para que esta no cargue y por el contrario aparezca una página de error ERR_BLOCKED_BY_XSS_AUDITOR.

Leer más

Quick Tips – SonarQube en Docker

Facebooktwitterlinkedinmail

En este post explicaremos una forma sencilla de realizar un análisis de código utilizando SonarQube y Docker.SonarQube con Docker

El propósito no es tener una instalación correcta de SonarQube sino usar el docker de SonarQube para analizar código de forma puntual.

Para realizar esto deberemos tener instalado Docker.

Una vez tenemos instalado docker lo iniciamos:

systemctl start docker.service Leer más