© 2024 El Sabueso de Linux. Todos los derechos reservados.

Hacking Para Cachorros (y perros viejos) - Las vulnerabilidades web más

impresionantes y cómo explotarlas sin experiencia

Ninguna parte de este libro puede ser reproducida, almacenada en un sistema

de recuperación o transmitida en cualquier forma o por cualquier medio, ya
sea electrónico, mecánico, fotocopia, grabación u otros, sin el permiso
previo por escrito del autor.

Este libro está protegido por las leyes de derechos de autor internacionales
y nacionales. Cualquier uso no autorizado de este material, incluyendo, pero
no limitado a la reproducción, distribución, exhibición o transmisión de
cualquier contenido de este libro sin el permiso explícito del autor, está
estrictamente prohibido y puede resultar en acciones legales.

Para obtener permisos para reproducir partes de este libro, por favor
contacta a El Sabueso de Linux a través de la información proporcionada en
la página de contacto.

El autor ha asegurar la precisión de la información proporcionada en este

libro. Sin embargo, no asume ninguna responsabilidad por errores, omisiones
o interpretaciones incorrectas de la información contenida en este libro. La
información contenida en este libro se proporciona "tal cual" y sin garantías
de ningún tipo.

Este libro está destinado únicamente con fines educativos y de información.

El uso de la información contenida en este libro para actividades ilegales
está estrictamente prohibido. El autor no se responsabiliza por el uso
indebido de la información contenida en este libro.
Contenido
PRÓLOGO...................................................... 7
“SERVER KING”................................................ 8
XSS......................................................... 13
HTML ...................................................... 13
JavaScript ................................................ 14
¿Jugamos? ................................................. 16
XSS – Nivel 1 ........................................... 17
XSS – Nivel 2 ........................................... 21
XSS – Nivel 3 ........................................... 25
Explotación real .......................................... 28
Cookies ................................................. 29
Explotación ............................................. 31
Conclusiones ............................................ 35
SQL Injection............................................... 36
SQL ....................................................... 36
SQL Injection – Entorno real .............................. 37
SQL Injection – Extra ..................................... 41
SSTI........................................................ 42
Plantillas ................................................ 42
Vulnerabilidad ............................................ 42
A practicar ............................................... 43
SSTI – Prueba 1 ......................................... 43
SSTI – Prueba 2 ......................................... 49
LFI......................................................... 62
Alternativas de explotación ............................... 66
CSRF........................................................ 67
CSRF – Robando cuentas bancarias .......................... 68
CSRF – Nuestro propio atraco .............................. 72
CSRF – Defensa ............................................ 78
SSRF........................................................ 79
 CSRF - Explotación ........................................ 82
SSRF – Extra .............................................. 85
Hashes .................................................... 86
Almacenamiento de contraseñas ............................. 87
Inicios de sesión ......................................... 87
Colisión de hash .......................................... 88
Ataque de “tablas arcoíris” ............................... 89
Ataque de fuerza bruta .................................... 91
Ataque de diccionario ..................................... 98
LECCIÓN.................................................... 100
FIN........................................................ 101
PRÓLOGO
Érase una vez, un pequeño hacker sabueso que se movía por el mundo
haciendo “cosas de esas de ordenadores”. Y un día…

A ver, que esto es un libro de hacking.

Aquí ni prólogo ni nada.

Vamos al grano.
“SERVER KING”
Es imposible entender las vulnerabilidades web que se van a tratar en
este libro sin tener unas bases claras de la arquitectura Cliente-
Servidor.

Tienes que entender cómo te comunicas con Internet, pero no solo eso,
tienes que entender por qué no es lo mismo ejecutar algo del lado del
cliente que del lado del servidor, y eso es lo que te voy a contar.

Estos son tus primeros pasos como hacker, y tienen que estar bien
dados.

Estos son los componentes de la arquitectura cliente-servidor:

Cliente

Programa que utiliza el usuario mediante el que se comunica con el

servidor remoto. Puede ser una aplicación web, un ordenador, un
teléfono o el propio navegador (Chrome, Firefox...)

Servidor

Es un ordenador remoto que proporciona el servicio que, como usuario,

estás consumiendo.

Es el ordenador donde está desplegada la página web que tú estás

viendo desde tu móvil. Donde está la base de datos, donde se manejan
los usuarios, etc...

La comunicación entre ambos funciona por llamadas.

1- El cliente realiza una llamada al servidor

2- El servidor ejecuta el código necesario para responderla
3- El servidor envía una respuesta
4- El cliente interpreta la respuesta
Esto es muy importante por muchas razones. Principalmente para que
entiendas lo siguiente: lo que ejecutes o modifiques del lado del
cliente no afecta en absolutamente nada al lado del servidor.

Y para ello, te voy a enseñar el truco que todos los niños hemos hecho
alguna vez.

Entra a la página de Google.

Ahora, haz click derecho encima de “Buscar con Google”, por ejemplo.
Y haz click en “Inspeccionar” o “Inspeccionar Elemento”:
Bien, se te habrá abierto algo como lo que veremos a continuación, y
quiero que cambies el texto de dentro de “value” por lo que te
apetezca:

Cuando le des a “Enter” sucederá la magia. Has alterado el valor del

botón de Google.

Pues no. Sin embargo, lo parece. Pero no es así, en el momento en el

que recargues la página volverá a su estado original.

Esto sucede porque has alterado el código a nivel de CLIENTE, sin

embargo, cuando recargas la página vuelves a hacer una llamada al
SERVIDOR, donde se mantienen los valores reales porque modificar eso
ya sería una obra de hacking magistral. Sobre todo, hablando de Google.
Presiona la tecla F12 (o vuelve a inspeccionar elemento). Pero ahora
quiero que accedas a la consola. Puedes encontrarla en el panel que
se te abre en el navegador, es una de las pestañas:

Quiero que escribas lo siguiente y le des a enter: ‘alert(1)’

(escríbelo sin las comillas).

¿Te esperabas eso?

Acabas de ejecutar código en la página web de Google. Has conseguido

generar un aviso que salta en la web más importante del mundo.

Pero no, ya sabes que no has hackeado nada y cuando recargues la

página esto ya no existirá. ¿Por qué?
Efectivamente, porque lo estas ejecutando del lado del CLIENTE.

Puedes suponer entonces que el verdadero peligro está en conseguir

ejecutar código del lado del SERVIDOR, esto se consigue explotando
una vulnerabilidad que permita una RCE (Remote Code Execution), es
decir, una ejecución remota de código. Este es el Santo Grial de los
hackeos, es lo PEOR que le puede pasar a cualquier servicio, que
alguien pueda ejecutar comandos en su servidor.

Repasamos:

• Cliente – Servidor
• Lo que ejecutas del lado del cliente solo te afecta a ti
• No puedes ejecutar nada del lado del servidor
• Conseguir una ejecución del lado del servidor se denomina RCE
(Remote Code Execution)
• Un RCE está cerca de ser lo PEOR que le puede pasar a un servicio
XSS
XSS significa “Cross-Site Scripting”, y es una vulnerabilidad web que
ocurre cuando un atacante tiene la posibilidad de inyectar código
malicioso en una web, de forma que este se ejecuta en el navegador de
otro usuario que acceda a ella.

Cuando entras a una web, se ejecuta código en lenguaje “JavaScript”.

Esta ejecución de código es la que hace que aparezcan “pop-ups”, como
los de aceptar cookies que, seguro ya conoces, entre otras muchas
cosas.

En resumen, JavaScript no se puede desactivar (por norma general). Es

básico para el navegador y la gran mayoría de webs lo necesitan para
funcionar adecuadamente.

HTML
Las páginas web se representan en el navegador como código HTML.

Quiero que entres a google.es.

Ahora, presiona las teclas “Ctrl” y “U” a la vez. Deberías ver algo
como esto:

Así funcionan las webs, y así se representan todas ellas. Si presionas

esa combinación de teclas en cualquiera podrás comprobarlo.

Pero no vamos a aprender así, solo quería que vieras un ejemplo real.
Vamos a utilizar una web para poder crear nuestro propio código HTML.
Entra en esta web.
Juega un poco, escribe algún título y vete dándole a “Run”, así verás
cómo carga la página web.

Esta es la base de Internet. Te animo a que investigues sobre HTML,

que aprendas las etiquetas más comunes y que estudies cómo crear una
página sencilla, pero eso queda fuera del contenido de este libro.

JavaScript

Pues bien, como ya te había dicho antes, las webs ejecutan código
JavaScript. Vamos a seguir el ejemplo del apartado anterior, revísalo
si lo habías dejado a medias.

Antes de decírtelo, te animo a que investigues, ¿qué etiqueta tienes

que utilizar para ejecutar código JavaScript?

‘script’, esa es nuestra etiqueta.

Y cuando la escribes y agregas código en su interior, pasa algo como
esto:

Vamos a hacer una prueba, copia esto:

Ahora dale a “Run”. ¿Qué pasa? ¿Por qué?

Lo que pasa es que al darle a “Run” estás cargando en el panel de la

derecha el contenido de la web que escribes a la izquierda. Y si
cargas el contenido habíamos quedado en que se ejecutaba el JavaScript
que hubieses definido.

Y efectivamente, salta un mensaje con un ‘1’:

¿Puedes hacer que aparezca tu nombre en vez de un 1? Adelante.

¿No te ha funcionado? Recuerda, cuando programamos los textos no se

pueden escribir “tal cual”, hay que ponerlos entre comillas.

Ahora ya entiendes cómo se ejecuta código JavaScript en un navegador,

así que ya tienes la mitad del camino hecho.

¿Jugamos?
La mejor forma de aprender es divirtiéndose, si no, no hay quien
aprenda.

Y es por eso por lo que vamos a jugar a un juego. Yo te voy a ayudar

en los 3 primeros niveles (son los que cubriremos en este libro), pero
te pido que intentes todos los demás para retarte a ti mismo.

Es un juego de Google, así que necesitarás una cuenta para poder

jugar.

El juego.
XSS – Nivel 1
Si ya has entrado con tu cuenta de Google, me imagino que puedes ver
la misma pantalla que yo:

Te recomiendo que presiones en “Open target page in a new tab”,

puedes encontrarla justo debajo del cuadrado principal. Así
trabajarás de una manera más sencilla (es como haré la
demostración).

¿Qué crees que es lo primero que haría un hacker?

Ya te lo digo yo, utilizar la página como un usuario normal. Si no

sabes cómo funciona la aplicación es imposible que entiendas cómo
atacarla, y esto aplica para cualquier web que jamás vayas a
enfrentar, primero hay que aprender a utilizarla.

Adelante, busca algo.

Mi búsqueda no tiene resultados, y me imagino que la tuya tampoco.
Puedes probar a buscar varias cosas.

Pero a mí ya se me ha encendido una bombilla.

Me gustaría que apretases la combinación de teclas “Ctrl” + “U”, o,

en su defecto, que des click derecho encima del texto que hayas escrito
y le des a “Inspeccionar”.

Yo lo haré como la segunda opción, la otra ya la hemos explicado

anteriormente.

¿Qué es “<b></b>”? Te dejo un segundo para que lo busques.

No parece nada importante, pero vamos a analizar lo que sucede

realmente, a ver qué está pasando.
Es decir, lo que escribes en el cuadrado, se “mete” en la página web
dentro del código HTML y se imprime en la pantalla.

Nuestro objetivo es conseguir ejecutar código JavaScript, ¿se te

ocurre algo? Puedes revisar el apartado anterior en el que hemos
explicado cómo se ejecuta una alerta.

Si no se te ha ocurrido nada, te puedo dar una solución, a ver cómo

te suena.
Efectivamente, si conseguimos introducir contenido entre las cabeceras
‘script’ estas se ejecutarán cuando cargue la página web.

Prueba tú mismo con cualquier texto que se te ocurra. Si no sabes por

donde tirar, recuerda cómo lanzaste una alerta en el apartado
anterior.

Yo ya lo he conseguido, y me voy directo al segundo nivel.

XSS – Nivel 2
Podría repetir todo el rato lo mismo y colarte un libro de 200 páginas,
pero es una tontería, y, además, va en contra de lo que yo creo que
es aprender.

En este momento no te tengo que enseñar el siguiente paso, porque ya

lo conoces, tienes que aprender cómo funciona la web. Adelante.

Intenta lanzar una alerta como habíamos hecho antes. A ver si eres
capaz.

Si has intentado exactamente lo mismo, estamos exactamente en el mismo

punto, porque no funciona:

Si abres la consola, podrás comprobar que hay dos problemas. El

primero, está considerando nuestro código como texto plano dentro de
‘message’, aunque ya te digo que vamos a hacer como si esto no
existiera.

¿El otro problema? Lo está metiendo dentro del ‘onload’ de la parte

‘loading’. Dentro de ‘startTimer’. A mí esto me parece más
interesante, y es por donde vamos a plantear nuestra vulneración.
Antes de nada, es importante que sepas que ‘onload’ ejecuta en su
interior código JavaScript cuando carga el elemento del que es
característica. En este caso, “onload” está dentro de la imagen
llamada “loading”, así que cuando esta imagen carga, el código se
ejecuta. Tiene sentido, si lo analizas, porque para crear un
temporizador es necesario ejecutarlo en algún lado.

En este momento lo mejor que podemos hacer es volver a lo sencillo,

escribir un número.

Vamos a volver a analizar dónde se está escribiendo lo que introducimos

realmente:

Y ahora toca vulnerarlo como hicimos en el nivel anterior.

Te voy a dar una serie de pistas:

• No hay caracteres prohibidos, puedes escribir lo que sea.

 • Al final de cada instrucción, tienes que escribir “;” para que
se ejecute.
• La idea es introducir una instrucción extra
• No puede haber una instrucción dentro de otra instrucción.

Te reto a que lo intentes durante 5 minutos, si lo consigues solo,

mucho mejor. Si se te atasca un poco, vamos con ello.

La idea va a ser cerrar la instrucción “startTimer” y agregar una a

su derecha. Para cerrarla es muy sencillo, basta con agregar los
caracteres con los que termina una instrucción.

El resultado es el esperado.

Pero ahora queremos agregar una llamada más, una alerta.

Piénsalo, queremos obtener esto:

Y ahora mismo tenemos esto:

Pues ya hemos hecho lo más difícil, basta con rellenar con el texto
que más te apetezca.

Y como imaginabas, nivel superado. Vamos al siguiente.

XSS – Nivel 3
Este es bastante distinto. Aquí no tenemos la posibilidad de escribir
en ningún sitio. Por mucho que intentas aprender a usar la aplicación,
no consigues gran cosa.

Aquí entra en juego un concepto nuevo, las ‘URLs’. La URL es la

dirección que aparece en la barra de búsqueda del navegador. Es la
dirección de una página web concreta.

Y puedes ver cómo, en este caso, cada vez que cambias de gato, el
número de la URL cambia a la par.

Te voy a pedir que intentes poner cualquier otro número, y a ver lo

que pasa. Porque me parece que sí que podemos escribir en la web.
Efectivamente, si pongo un 6 en la URL, ahí aparece mi 6. Entonces sí
que podemos “escribir” en la web, así que podemos intentar la
alternativa más fácil, la del nivel 1.

Demasiado bonito para ser real, no cuela.

Pero como antes, te voy a pedir que le des a click derecho -

“Inspeccionar” encima de la imagen que no carga, porque está pasando
una cosa muy interesante. Aquí:

He cambiado el texto anterior por “alert(1)” para simplificarlo, pero

sería lo mismo.
Date cuenta de dónde está agregando lo que estamos escribiendo:

La idea vuelve a ser exactamente la misma que antes, introducir código

malicioso para “escaparnos” del marco de la imagen y conseguir
ejecutar código.

Te vuelvo a dar unas pistas:

• ¿Te acuerdas del “onload” de antes? ¿Recuerdas que ejecutaba

código JavaScript cuando cargaba una imagen? Pues existe
‘onerror’, que se ejecuta cuando hay un error cargando una
imagen. Por ejemplo, si no existe.
• ‘onerror’ va dentro de la propia imagen, no tienes que cerrarla
con “>” hasta que lo hayas escrito.
• alert() vuelve a ser el método que tienes que utilizar.

Date un intento, en este punto estoy seguro de que puedes aproximarte

a la solución.

Si no, aquí está una posibilidad:

¿Entiendes cómo funciona?

1. Intenta cargar una imagen que no existe

2. Hay un error en la carga
3. Se lanza “onerrror”
4. Salta la alerta

Si no te funciona, intenta cambiar las comillas simples por dobles y

viceversa, puede ser un problema de navegador.

Con este nivel concluimos el juego, pero te animo a que intentes

terminarlo tú mismo (son un total de 6 niveles, así que ya llevas la
mitad). Con los conocimientos que has adquirido aquí, ¡te aseguro que
podrás terminarlo sin muchos problemas!
Explotación real
Esto queda muy bonito en el juego que hemos visto antes, pero eso no
tiene absolutamente ningún riesgo. Es código que se ejecuta en tu
navegador y que te imprime un “1” por la pantalla, o cualquier texto
similar.

Pues bien, esta vulnerabilidad es realmente trascendente cuando puedes

inyectar código donde alguien más lo puede ver. No solo tú mismo. Es
decir, cuando puedes ejecutarlo en el navegador de otra persona.

Por ejemplo, en un chat comunitario, o en un comentario en una página

web, o en mil ejemplos similares.

A continuación, vamos a emular que se ha conseguido explotar una

vulnerabilidad XSS en una web a la que diversas personas tienen acceso.
Y vamos a aprender una vía de explotación muy potente por este camino.

Yo lo voy a hacer en una máquina Linux. Indicaré cómo paso por paso,
y te recomiendo que intentes replicarlo conmigo.

Si te parece demasiado complejo, basta con que entiendas lo que está

pasando y la idea principal de explotación que vamos a desarrollar.

He creado una página muy básica, aquí puedes ver el “index.html”, y

he levantado un servidor local con Python.
Y si accedo a la web en la dirección ‘http://localhost:8000’ me
encuentro lo que imaginaba, mi web (con su correspondiente script).

Ahora vamos a suponer que alguien consigue inyectar código JavaScript

como nosotros mismos estábamos anteriormente. No vamos a hacer una
inyección real, simplemente vamos a escribir en el fichero
“index.html” como si alguien hubiese vulnerado nuestra web.

Esta persona (potencial delincuente) no quiere imprimir algo por la

pantalla, quiere hacer cosas malas. En nuestro ejemplo, robarme las
cookies.

Cookies
¿Qué son las cookies? Son formas de identificar al usuario desde el
propio navegador.

Son la razón por la que cuando entras a una página donde ya tienes la
sesión iniciada, no te vuelve a pedir la contraseña. Para que me
entiendas, son tu identificador dentro del navegador.
Pues bien, una XSS es una puerta clarísima para ejecutar la técnica
“Cookie Hijacking”.

¿Qué es esto? Un secuestro de la cookie de sesión.

Y me imagino que esto ya te sonará. Si el atacante consigue robarte

la cookie de sesión, la puede introducir en su navegador e iniciar
sesión como tu usuario.

De esta manera se saltaría la contraseña y el doble factor de

autenticación.

Mostrado en un dibujo sería algo así:

1. Roba la cookie de sesión

 2. La introduce en su navegador
3. Inicia sesión en la web
4. La cuenta aparece iniciada

Explotación
Me imagino que te preguntas, ¿qué tiene que ver la vulnerabilidad XSS
con secuestrar la cookie? No parece que esté muy relacionado.

Pues bien, voy a crear una cookie de mentira con la extensión Cookie
Editor para demostrártelo.

Y es necesario que sepas un detalle. En JavaScript, en el momento en

el que ejecutas “document.cookie”, se muestran como texto plano todas
las cookies que tengas guardadas en el navegador en ese instante.

Vamos a hacer una demostración alterando la página web que habíamos

creado antes:
Como te puedes imaginar, se está creando una alerta que imprimirá
por pantalla todas las cookies del navegador.

Y si recargo la web, ahí está:

Pero claro, esto no sirve para nada al atacante, al final estos datos
no están saliendo de mi navegador, me están apareciendo a mí mismo (o
al usuario que fuera).

Pero el atacante puede hacer una cosa muy inteligente. Desde mi

navegador, puede hacer una llamada a un servidor que tenga lanzado,
mandándole como mensaje mis datos privados.

No te preocupes, que lo vemos con un dibujo.

Ahora mismo está sucediendo esto:

 1. El código malicioso lee la cookie
2. El código imprime las cookies en pantalla
3. Aparece un pop-up que ve el usuario víctima
4. No pasa nada más

Pero lo que pretende el atacante es esto:

1. Que lea la cookie

2. Que se la envíe a su servidor

Te voy a dar una manera muy sencilla de enviar esta cookie.

El atacante abre un servidor ‘http’, una página web, digamos.

Entonces, desde el código malicioso, simplemente hace una llamada a
su propia página web conteniendo los datos de las cookies, y los
registra.

Voy a fingir ser mi propio atacante, así que me voy a poner a escuchar
en el puerto 1234 (recuerda que la página web estaba en el puerto
8000).
Y ahora, voy a replicar el código que introduciría un delincuente en
la página web, que sería algo similar a esto:

Te explico el código:

• <script> - ejecutar un bloque de código Javascript

• fetch - hacer una llamada “GET” a una dirección URL
• http://localhost:1234 – la dirección del servidor del atacante
• ?cookie= - parámetro llamado “cookie” a agregar en la llamada
• + document.cookie – añade a la URL el texto contenido en
“document.cookie”, es decir, las cookies del navegador

Ahora, si entro a la página web no se ve nada extraño. El usuario no

se da cuenta de absolutamente nada.

Sin embargo, mira lo que aparece en la consola del servidor atacante

(el servidor del puerto 1234 que iniciamos anteriormente y se
referencia desde el código malicioso):
Sorpresa, nos acaban de robar la cookie y no nos hemos dado ni cuenta.

Ahora al atacante le basta con copiar ese valor en su navegador y ya

tendrá la cuenta abierta.

Conclusiones
Como has visto, un XSS es un ataque “sencillo” de ejecutar, sobre todo
cuando existen cargas útiles en listas infinitas, por si la web pudiera
estar protegida: Lista de XSS

Es una vulnerabilidad muy presente en el TOP 10 OWASP (las 10

vulnerabilidades web más importantes del mundo), y está a la orden
del día. Yo mismo he explotado varias en entornos reales.

Existen muchas maneras de evitarla, por ejemplo las CSP (Content-

Security-Policy) o el “parseo” adecuado del texto introducido por el
usuario, pero esas técnicas de protección están fuera del alcance de
este libro.
SQL Injection
Una inyección SQL es un tipo de vulnerabilidad que permite a un
atacante ejecutar peticiones no autorizadas a una base de datos,
alterando el comportamiento normal de una petición legítima realizada
por la web mediante una inyección de código malicioso.

Suele suceder cuando no se manejan adecuadamente las entradas del

usuario, y se permite un acceso directo a la base de datos sin manejar
adecuadamente las entradas que realice.

SQL
SQL significa Structured Query Language y es el lenguaje que se utiliza
para comunicarse con las bases de datos relacionales tipo SQL, como
por ejemplo “MySQL” o “MariaDB”.

Este es un lenguaje complejo, y cubrir toda su sintaxis queda fuera

del contenido de este libro.

Para comprender y replicar este apartado, solo necesitarás aprender

lo siguiente:

• La instrucción SELECT solicita datos a la base de datos

Y también necesitarás saber cómo funciona una instrucción SQL, aquí

lo puedes ver:

Las partes son:

1. Instrucción (en este caso, seleccionar).

 2. La columna que quieres seleccionar, en este caso el nombre del
usuario (suponiendo que la columna se llama “name”).
3. La tabla donde quieres tomar esos datos, suponiendo que la tabla
se llama “users”.
4. La comprobación indicando que quiero el nombre del usuario con
identificador 12345, no quiero cualquier nombre.

Estas peticiones se realizan a la base de datos desde una propia

consola conectada a la base de datos, pero también se pueden hacer
desde código (por ejemplo, desde una página web). Y es ahí donde
aparecen los problemas de inyección SQL.

Vamos a verlo.

SQL Injection – Entorno real

Te voy a pedir que entres a esta página web. A continuación,
presiona el botón “RUN”.

Podrás ver una pantalla como esta:

Pero lo mejor de esta web, es que también puedes ver el código con
el que se ha generado. Lo tienes a la derecha.

Si yo tuviese acceso a este código lo primero que haría antes de

intentar nada es analizarlo. Ya te he dicho que lo primero que tiene
que hacer un hacker es entender cómo funcionan las webs.

1. Línea 4: Podemos leer “sqlite3”, así que sabemos que nos

encontramos frente a una base de datos que utiliza lenguaje SQL.
 2. Línea 16: Cuando el usuario hace una llamada (dándole al botón
de ‘login’) se están registrando datos.
3. Línea 17: Se está almacenando el “username” que introduce el
usuario.
4. Línea 18: Se está almacenando el “password” que introduce el
usuario.
5. Línea 19: Se está construyendo una petición completa utilizando
el usuario y la contraseña introducidos para hacer una petición
a la base de datos.
6. Línea 25: Con la instrucción “db.get(...)” se está realizando
la petición a la base de datos.

Vamos a entender lo que sucede cuando introducimos un usuario y una

contraseña:

1. Se introducen el usuario y la contraseña

2. Se almacenan en “username” y “password”
3. Se construye la petición completa
4. Se hace la petición a la base de datos

Y si introducimos los datos, este es nuestro resultado:

Era de esperar, pero vamos a prestar atención a la solicitud que
estamos generando.

Vamos a unir todos los textos para verlo más claro.

Más arriba en el código podemos encontrar los datos del administrador,

pero eso no tendría ninguna gracia (suelen estar muy escondidos).

Pero vamos a quedarnos con una cosa, “admin”. Admin es el MUY típico
usuario que se utiliza en todas las aplicaciones para concederle
permisos de administrador y poder manejar la web.

Entonces, ya tenemos un dato, el “username” tiene que ser “admin”.

Perfecto, ese problema ya lo tenemos solucionado, la parte de la

izquierda va a ser verdad siempre.

Pero ¿y la de la derecha? Date cuenta de que tienen que ser verdad

las dos a la vez (tenemos un “and” en medio), así que necesitamos que
coincidan exactamente el usuario y la contraseña, pero no la sabemos.

Aquí es donde viene lo interesante.

Te voy a dar unas cuantas pistas:

1- Igual que “and”, existe “or”, que significa “una o la otra”.

Basta con que uno de sus lados sea cierto para que se convierta
en verdad.
2- Las entradas de texto del usuario no se están tratando de ninguna
manera, puedes introducir cualquier cosa.
3- “--” comenta todo el texto a partir de estos guiones, es decir,
no se tiene en cuenta.

No sé si se te ocurre algo, pero a mí se me ocurre una cosa. Te voy a

dar una idea inicial:

Con esto quiero que entiendas que puedes escribir código dentro del
texto, ¿ves cómo estoy rompiendo la instrucción original? Estoy
agregando una comilla para cerrar la contraseña, estoy poniendo punto
y coma para cerrar la instrucción y estoy comentando todo lo demás,
para que ni siquiera lo tenga en cuenta.

Significa que puedo meter todo el código que quiera mediante las
instrucciones.

Y así es muy fácil saltarse los controles.

¿Por qué? Porque como te he dicho, existe “or”.

Si no te das cuenta de lo que está pasando, te lo explico punto por

punto (vete mirando la imagen de arriba para entenderlo).
 1- Las condiciones se separan por un “and”, ambas tienen que
resultar verdaderas
2- La parte de la izquierda es verdadera siempre, porque el usuario
admin existe
3- La parte de la derecha se compone por 2 partes separadas por un
“or”
4- Dentro de esta, password=”” es siempre falsa
5- Sin embargo, 1=1 es siempre verdad, y es suficiente con que una
de las dos partes sea verdad
6- Gracias a esto, la derecha del “and” pasa a ser cierta.
7- Las dos partes del “and” pasan a ser ciertas, y, por tanto, el
resultado es positivo.

Y si repites exactamente lo que he explicado (tienes que introducir

el texto de color azul en el campo “password”), el resultado es el
siguiente (acuérdate de escribir los espacios, son importantes):

Así es, has accedido a la cuenta del administrador sin conocer su

contraseña.

SQL Injection – Extra

Las SQL Injections son prácticamente infinitas. Tanto que es
imposible tratarlo en este libro (da para un libro completo mucho
más extenso que este).

Es por ello que, con este conocimiento que has adquirido, te animo a
que practiques intentando resolver estos problemas.

En caso de que alguno te resulte un poco más complicado o se te

atasque demasiado, también te dejo aquí las soluciones.
SSTI
SSTI significa “Server-Side Template Injection”. Es un tipo de
vulnerabilidad que ocurre cuando un atacante puede introducir entradas
maliciosas en las llamadas “templates” (plantillas, en castellano) de
manera que se ejecutan del lado del servidor.

Plantillas
Las aplicaciones web muy a menudo utilizan plantillas para generar
contenido dinámicamente. Por ejemplo, vamos a suponer que existe una
página web que te saluda en base a tu nombre una vez estás registrado.

Yo me llamo José (por si no lo sabías), así que la web me diría “Hola,

José!”. Pero si se mete alguien que se llame Carlos, la página sería
tal que “Hola, Carlos!”.

Puedes ver claramente cómo está utilizando una plantilla, un modelo,

sobre el que incluye tu nombre una vez entras a la página web.

Estas plantillas funcionan con diversidad de motores, los más

habituales son:

- Jinja2 : Python

- Twig : PHP

- FreeMarker : Java

Vulnerabilidad
Una vulnerabilidad SSTI ocurre cuando el código de la aplicación
permite que los datos introducidos por el usuario (el nombre, por
ejemplo) se introduzcan directamente en la plantilla sin ser
controlados de ninguna manera.

Quiero que entiendas cómo funciona a nivel de código, así que te lo

voy a enseñar en Python:
Pues bien, en vez de un nombre normal, un atacante puede introducir
un código malicioso en el campo de entrada, como por ejemplo “{{7*7}}”
(no me preguntes por qué 7*7 y no otros números, pero es la prueba
que hace todo el mundo, manías de hackers).

Si se llegase a imprimir por pantalla algo como “Hola, 49!” ya tenemos

un problema gravísimo. Eso significa que el servidor está
interpretando el código que introducimos y lo está ejecutando.

Y al igual que una multiplicación, puede ser una cosa bastante más
seria, y puede escalar a una RCE.

En caso de detectarse una vulnerabilidad de este tipo, se podrían

llegar a ejecutar comandos del estilo del siguiente:

Si no estás muy familiarizado con Python, ese comando está ejecutando

la instrucción “ls” a nivel de SERVIDOR. Lo peor que le puede pasar a
una página web. Ejecución de código remoto, RCE, ¿te acuerdas?

A practicar
Se acabó la teoría, toca ponerse a practicar. Vas a necesitar crearte
una cuenta aquí para poder trabajar conmigo: PortSwigger.

Es gratis, por supuesto.

SSTI – Prueba 1
Accede a este link. Y dale a “Access the Lab”.
Bueno, nuestro objetivo aparecía en la página anterior, que no te he
dado tiempo ni de leerlo. El objetivo es eliminar el fichero
“morale.txt” de la carpeta inicial del usuario “Carlos”.

Pues vamos allá.

A estas alturas me imagino que ya sabes lo que tienes que hacer.

Utilizar la página como un usuario normal, si no aprendes cómo funciona
la web es imposible que consigas hackearla. Así que adelante, haz
click en los detalles de algún objeto.

La mayoría cargan sin problemas, pero eso no parece lo más interesante.

Date cuenta de que en una SSTI lo ideal es poder ver una salida, para
comprobar si se están ejecutando nuestros comandos (como ese 7*7 que
estábamos hablando antes).

¿Encuentras algún caso en el que se imprima contenido por pantalla?

Me imagino que sí. Los dardos.

Los dardos “no tienen stock”:

Y ese mensaje se está emitiendo a partir del parámetro “message” que
puedes observar tú mismo en la URL de la página web.

Puedes probar a escribir cualquier otro mensaje, y verás cómo aparece

en la pantalla.

Previamente, nos decían que esta página funcionaba con “ERB”. Eso
significa que funciona con el lenguaje de programación Ruby, y está
utilizando este “ERB” para manejar las plantillas.

Aquí te voy a dar 2 minutos para que busques por ti mismo (o le

preguntes a ChatGPT) cómo se ejecuta un comando utilizando ERB para
RUBY.

Esto es una demostración de lo que está sucediendo:

Ahora te toca buscar cómo se ejecutaría un comando........

Vale, ya has tenido tiempo, te doy la solución. Se ejecuta de la

siguiente manera: ‘<%= [código] %>’

Nuestro plan entonces está bastante claro, vamos a probar a introducir

en ese código un 7*7. Por lo que tendríamos que escribir en el
‘message’:

<%= 7*7 %>

Y… han cantado bingo. Aparece un 49 en el lugar del mensaje.

Acabas de explotar una SSTI. Bueno, detectar, mejor dicho. Explotarla
la vas a explotar ahora.

Pues bien, recapitulamos: nuestro objetivo era eliminar el fichero

“morale.txt” de la carpeta inicial del usuario “Carlos”. Así que
tenemos que aprender cómo se eliminan archivos utilizando el lenguaje
en el que se está interpretando nuestro código.

¿Recuerdas cuál era? Efectivamente, Ruby.

Y si leemos detenidamente su documentación (o le preguntamos a

ChatGPT), nos vamos a encontrar con que el comando que debemos ejecutar
es ‘system(…)’.

Dentro de este comando puedes introducir una instrucción dirigida a

un sistema linux. Para eliminar un archivo en linux se hace de la
siguiente manera:

rm <dirección del archivo>

Pues te voy a dar unas pistas para que lo intentes:

• Las carpetas iniciales de cada usuario en Linux se encuentran

en “/home/<nombreUsuario>”
• Para eliminar un fichero de mi carpeta de usuario si yo fuera
el sabueso, se haría así: “rm /home/sabueso/fichero.txt”
• Los nombres de usuarios son en minúsculas.
• Tienes que introducir la instrucción de linux dentro de system,
y system en el mismo lugar donde pusiste 7*7 (no olvides lo de
alrededor)

¿Ya lo tienes? ¿No? Pues aquí va la solución:

 ?message=<%= system("rm /home/carlos/morale.txt") %>

¿Entendemos lo que sucede?

1. Ruby captura el valor de “message” y lo intenta insertar dentro

del template.
2. No revisa el contenido, y ejecuta código en Ruby
3. Ejecuto la instrucción ‘system’, que lanza una instrucción a
nivel de sistema dentro del servidor remoto.
4. Ejecuto en el SERVIDOR el comando “rm /home/carlos/morale.txt”,
ya que eliminar ese fichero era el objetivo del juego.

¡Misión completada! Acabas de conseguir una RCE (Ejecución Remota de

Código en el lado del servidor) explotando una vulnerabilidad SSTI
(Server-Side Template Injection). Entiendes lo que son ambas cosas,
entiendes su potencial peligro y entiendes la teoría detrás de la
SSTI.

¿Te imaginabas que serías capaz de tanto?

SSTI – Prueba 2

Vamos a seguir en la misma página web, en otra de sus pruebas. Pero

ahora, vamos a aprender a usar una herramienta increíble, extensamente
utilizada por expertos en ciberseguridad en todo el mundo.

Burpsuite
Esta herramienta se llama BURPSUITE. Sigue esta guía de instalación
(no te olvides de seleccionar la “community edition”, la “profesional”
no es gratuita).

Ahora, vamos a abrirlo:

• Seleccionamos “temporary Project in memory”

• Seleccionamos “Use Burp Defaults”

No te agobies, sé que parece un programa muy complicado, pero vamos a

hacerlo todo de manera muy sencilla. Paso por paso.

Burpsuite funciona como un proxy en tu propio ordenador. La idea de

esto (la parte que vamos a utilizar nosotros en este caso, porque
tiene muchas posibilidades) es capturar los paquetes que salen de
nuestro navegador antes de que “salgan” hacia internet. Así podemos
modificarlos como queramos.

¿Qué son los “paquetes”? ¿Te acuerdas de la arquitectura cliente-

servidor? Si no, repásala.

Los “paquetes” son el medio de comunicación entre el cliente y el

servidor. Por ellos se transmite la información y las peticiones de
información entre ambos. Por ejemplo, es como se envían los datos de
un usuario, por donde se reciben las páginas webs o por donde se
introduce una tarjeta de crédito:
Cuando navegamos por Internet, estos paquetes se generan desde el
navegador, es decir:

Sin embargo, cuando utilicemos Burpsuite queremos que pase lo

siguiente:
Queremos el paquete dentro de Burpsuite, y que este espere antes de
enviarlo a Internet (al servidor remoto, en este caso). ¿Con qué
intención? Poder modificarlo.

Para esto no es suficiente con abrir Burpsuite. ¿Por qué? Porque no

lo estás conectando a tu navegador (yo voy a utilizar Firefox) de
ninguna manera. Necesitas una manera de conectar este navegador a tu
nuevo proxy (recuerda, Burpsuite actúa como un proxy).

Muy sencillo. Vas a instalarte esta extensión. Y ya tienes la mitad

del trabajo hecho. Para Firefox esta es la url directa: extensión.

Ábrela, y presiona en “Options”.

Ahora, proxies. Y una vez en esta pestaña, presiona “Add”.

Copia estos valores que puedes ver en la imagen (puedes ponerle el

título que quieras, yo lo he llamado “burpsuite” para saber lo que
es).

Te explico las configuraciones que hemos modificado:

• Title: Simplemente es el nombre, elige lo que prefieras

• Hostname: la dirección IP en la que se encuentra nuestro proxy(o
su url, si fuera el caso). Recuerda que Burpsuite está corriendo
en nuestro propio ordenador, así que esa dirección se llama
“localhost” (o 127.0.0.1, es lo mismo).
• Port: Burpsuite escucha de manera predeterminada en el puerto
8080, así que tenemos que definirlo.

Ahora, presiona el botón “Save”.

De nuevo, abre la extensión y haz click sobre “burpsuite”. Se te

encenderá con una bolita azul:
Esto ya funcionaría en caso de que las webs funcionasen por HTTP, pero
la gran mayoría lo hacen por HTTPS, así que necesitamos hacer un
pequeño paso extra. Si no lo haces, ni siquiera podrás buscar en
Google, puedes comprobarlo tú mismo.

Vamos a solucionarlo.

En la barra de navegación, escribe http://burpsuite (es importante

que lo tengas seleccionado en FoxyProxy).

Después, presiona arriba a la derecha, donde dice “CA Certificate”, y

se te descargará un fichero.

Voy a indicar los pasos para Firefox a partir de ahora, te recomiendo

que tú también lo hagas; si estás utilizando Chrome, estos son los
pasos (pero recuerda, no puedes acceder a páginas webs mientras tienes
el proxy activado en FoxyProxy, tendrás que mirar los pasos en el
móvil o en otro navegador).

Vamos a entrar a los ajustes de Firefox:

En la barra de búsqueda, introduciremos “certificates”, y
presionaremos el botón “view certificates” que aparece.

Una vez se nos abre una pequeña pantalla, clickaremos en “Import”, y

es ahí donde subiremos el archivo que hace un momento nos habíamos
bajado.

Ahora sí, ya estamos listos para capturar paquetes.

Si haces una búsqueda en Google, ya debería ser interceptado.

Pero no estas interceptando nada, ¿por qué? Pues hombre, porque tienes
conectado un proxy que está “apagado”. Para encenderlo abre la
aplicación de Burpsuite y en la pantalla “Proxy” haz click el cuadrado
“Intercept is off”, que se encenderá:
Prueba a buscar de nuevo en Google. Ahora se te queda cargando
infinitamente, pero si abres la aplicación de Burpsuite, ¡voilá! Ahí
tienes el paquete.

Si no te ha salido, empieza de nuevo desde el principio. Deberías

haber interceptado un paquete sí o sí. Es necesario para seguir con
la explotación.

Para continuar, desactiva el proxy de “FoxyProxy”, te volveré a decir

cuándo lo tienes que activar.
Explotación
Después de esta clase rápida de “proxies” y certificados, ya tenemos
todo el conocimiento que necesitamos para afrontar este segundo reto.
Aquí lo tienes: Reto.

Espero no tener que decirte lo que tienes que hacer a estas alturas.
Efectivamente, aprender a usar la página web como un usuario normal.
Si no, no vas a conseguir absolutamente nada.

Recuerda, nos han dado un usuario y una contraseña (si no lo has

visto, ¡error!, antes de empezar a hacer, hay que leer todo a lo que
tenemos alcance). Estos datos son “wiener” como usuario y “peter" como
contraseña (<usuario>:<contraseña> es una forma muy habitual de
representación de credenciales).

Y entonces, iniciamos sesión:

En esta pantalla yo ya veo algo que me llama mucho la atención. ¿Ves

algo interesante?

Yo me he fijado en esto:
Está imprimiendo mis datos de usuario, me imagino que lo hará con
todos los usuarios. Es decir, lo hace con todos los usuarios, pero
varía el contenido… Es como una plantilla… Una… ¿”template”?

Por si te habías olvidado, esta vulnerabilidad se llamaba “Server-

Side Template Injection”. Parece que tenemos un hilo de donde tirar.

Hay una forma evidente de alterar el contenido de este texto, es

modificando mi correo electrónico, y eso es lo que voy a hacer:

Y efectivamente, ahora aparece el email que acabo de escribir. Ya

tenemos punto de entrada:

Para algo hemos instalado Burpsuite y hemos aprendido a utilizarlo,

es el momento de encenderlo en “FoxyProxy” y de activar el “Intercept
is on”. Ahora, escribe un nuevo correo y dale a “Update email”.
Acabamos de capturar el cambio de correo. Bien.

Ahí mismo, agrégale este texto al final = ‘}}{{7*7’ (sin las comillas).

¿Entiendes para qué sirve? Esto es lo que está sucediendo:

En el momento en el que introducimos un email, simplemente se guarda

en medio. Pero nuestra idea es la siguiente:
Me imagino que en este punto ya entiendes lo que está pasando, no es
la primera inyección de código que hacemos en este libro.

Efectivamente, la intención es cerrar la instrucción original a la

fuerza, abrir una nueva e introducir el código que queremos que se
ejecute.

Como te decía, agrega ese texto a la derecha del email en Burpsuite y

presiona el botón “Forward”:

Ahora puedes desactivar el “Intercept”.

No ha sucedido lo que te esperabas, ¿no? Es normal, te acabas de

encontrar contra tu primera protección contra SSTI. Has aprendido a
instalar y configurar Burpsuite, has estudiado la web, has aprendido
la teoría necesaria para la explotación, la has aplicado bien, has
entendido lo que estabas haciendo… y no ha funcionado.

¿Has perdido el tiempo? Tengo mis dudas. Porque ahora ya ves la

aplicación con otros ojos.

No has perdido el tiempo, has investigado en el sentido más literal

de la palabra, y puedes experimentar con otras configuraciones.

Te voy a pedir una cosa, captura en Burpsuite el paquete cuando cambias

tu nombre preferido a “First Name”, por ejemplo. Acabas de hacer algo
muy similar, así que no es necesario que te lo repita paso por paso.

“blog-post-author-display”. ¿Qué es eso…?

Quiero demostrarte que un gran hacker no es solo el que más tecnologías

sabe utilizar, es el que mejor sabe “leer” las aplicaciones, adaptarse
y entenderlas.
A mí se me ocurre que, en caso de que exista un blog, está definiendo
la forma en la que aparece mi nombre, en la que se me identifica.

Te voy a pedir que revises la aplicación, encuentres un blog, escribas

un comentario y analices qué cambia al seleccionar “Name” o “First
Name”.

Name: First Name:

Es exactamente el mismo comentario, pero he cambiado mi representación

del nombre.

Te voy a pedir otra cosa, con los conocimientos que habías obtenido
antes (y que pensabas que no habían servido para nada), ¿se te ocurre
algo?

Te voy a dar una serie de pistas:

• Recuerda cerrar la orden legítima con {{

• El código ya escribe un “}}” al final, no es necesario
• 7*7
• Tienes que capturar un paquete

Una pista extra (si no la quieres, deja de leer e inténtalo).

Este tiene que ser el resultado final:

Estoy seguro de que has sido capaz de conseguirlo. En caso de que se

te haya atascado, o si quieres comparar tu solución con la mía, aquí
la tienes:
Es oficial, acabas de explotar otra SSTI y ya puedes ejecutar código
remoto del lado del servidor.

Ahora, para ejecutar un comando en Python, simplemente tienes que

combinar esta serie de instrucciones (lo puedes ver en la
documentación oficial de “Tornado”, te recomiendo que lo busques):

{% import os %}

{{os.system('<comando linux>’)

Adelante, ejecuta el comando necesario para completar la misión (si

no te acuerdas de lo que tenías que hacer, puedes volver a apretar el
enlace del principio de este nivel 2).

Una vez recargues el blog, ya debería salirte la pantalla de que has

superado el nivel.

Si no te sale o no conoces cuál es el comando, revisa el nivel

anterior, ¡tienes que hacer casi lo mismo!
LFI
Felicidades, esta vulnerabilidad te va a resultar mucho más sencilla
de entender que las anteriores. Vamos a tomarlos un poco de relajación
después de tanto esfuerzo.

LFI significa “Local File Inclusion”, dicho en castellano, Inclusión

de Archivos Locales.

Es una vulnerabilidad web que permite al atacante visualizar archivos

de un servidor que normalmente no debería.

En una web segura, el usuario puede acceder únicamente a los archivos

de la web. Es decir, aquellos archivos del servidor que se consideran
expuestos a internet:

Pongamos un ejemplo, si el usuario quiere acceder al archivo

“pagina1.html” y después al “pagina2.html” basta con escribir las
siguientes direcciones en el navegador:

http://ejemplo.com?page=pagina1

http://ejemplo.com?page=pagina2
Pues bien, en el momento en el que se consigue explotar una LFI, el
atacante pasa a tener acceso a muchos ficheros que deberían estar
protegidos y seguros en el interior del sistema.

Vamos a volver al ejemplo que te he puesto arriba. ¿Qué está pasando

cuando introducimos en la URL el valor “page1”?

Te voy a dejar una imagen explicativa, analízala e intenta entender

lo que está sucediendo. Ahora la comentamos:
 1. Escribes en la URL la página que quieres visitar.
2. Le envías la solicitud/petición al servidor.
3. El servidor construye la dirección del fichero, agregándole el
nombre que tú has introducido, considerando la dirección base
de la página web (en este caso, la dirección base es
“/var/www/html”).
4. El servidor solicita, en el sistema de ficheros, ese archivo
concreto (pagina1).
5. El servidor devuelve el archivo al que acaba de acceder.
6. La web se muestra en el navegador.

Si ya conoces algo de manejo de sistemas de ficheros, es probable que

se te esté ocurriendo algo.

Una vez más, como suele ser habitual, la idea va a ser engañar al
sistema haciéndole creer que nuestro nombre de archivo no es un nombre,
sino una instrucción.

Para ello, basta con que sepas lo siguiente:

• Cuando en una dirección en un sistema de archivos escribes “..”

(dos puntos), significa que estas subiendo a la carpeta superior.
Por ejemplo, si estás en la carpeta “/home/jose/miscosas” y
pretendes leer el archivo localizado en
“home/carlos/carloscosas/secreto.txt” puedes hacerlo de la
siguiente manera: “cat ../../carlos/carloscosas/secreto.txt”

Si no lo sabes, en un sistema Linux el comando “cat” sirve para leer

un fichero.

Esto es lo que está sucediendo:

Me imagino que en este punto ya te imaginas por dónde van los tiros.

Vamos a suponer que la página web de antes está en el mismo servidor

que el archivo secreto de Carlos. ¿Se te ocurre algo?

Acuérdate que la dirección que utilizábamos era:

http://ejemplo.com?page=pagina1

Recuerda también que “pagina1” se encuentra en la carpeta

“/var/www/html/”

Pues efectivamente, me imagino que se te ha ocurrido algo como esto:

http://ejemplo.com?page=../../../home/carlos/carloscosas/secreto.txt

Y es exactamente la solución a nuestro problema. ¿Podrías explicar

qué está pasando?

Vamos a verlo en un dibujo, estoy seguro de que lo entenderás a la

primera:

Vamos a centrarnos en la dirección del archivo que está solicitando

el servidor al sistema de archivos. Recuerda para qué servían los
dos puntos (“../”).
Como podías imaginar, cada dos puntos que añades, “compensan” una de
las carpetas originales, hasta que llega un punto en el que te basta
con escribir la dirección completa de un archivo para obtenerlo.

En este caso, el secreto de Carlos que estaba entre sus cosas.

Esta vulnerabilidad está en el TOP 10 OWASP, es exageradamente

habitual y todas las páginas que conoces la han sufrido. TODAS, te lo
aseguro.

Alternativas de explotación
Te he explicado la vulnerabilidad y cómo se explota de la manera más
sencilla posible, pero esto no es el final.

Las vulnerabilidades LFI se pueden explotar de mil maneras, date

cuenta de que puede aplicarse este mismo concepto siempre y cuando el
servidor acceda al sistema de archivos.

Y eso pasa cuando te descargas un fichero, cuando solicitas un elemento

concreto de una web… En fin, que pasa en infinidad de casos y tiene
infinidad de usos.

Si quieres aprender más sobre esta técnica, explotaciones más

complejas quedan fuera del alcance de este libro, pero te recomiendo
que navegues por internet, los grandes hackers son grandes
investigadores, encontrarás mil alternativas.

No estarán igual de bien explicadas que aquí, pero lo bueno es que ya

tienes la base, te aseguro que lo entenderás (casi) todo por la selva
de internet.
CSRF
Nos toca hablar de la vulnerabilidad Cross-Site Request Forgery
(CSRF). Esta vulnerabilidad es una falsificación de solicitud, un tipo
de ataque que engaña al usuario para que realice acciones no
intencionadas en una aplicación web en la que ya está autenticado.

¿Recuerdas las cookies? Pues bien, habíamos quedado en que te sirven

como autenticación en las webs.

Es decir, si yo te comparto un enlace de twitter y tú haces click,

cuando entres en tu navegador tendrás la sesión iniciada. Bien, esa
es la base del ataque.

Vamos a explicar cómo sería una explotación habitual de este tipo de

vulnerabilidad:

1. El atacante crearía (en una web maliciosa) una solicitud

maliciosa que se intenta conectar a la página web real.
2. El usuario (pobre inocente) accede a la web maliciosa.
3. Sin saberlo, la solicitud maliciosa se lanza a la web real,
utilizando las credenciales del usuario (recuerda que ya tiene
la sesión iniciada).
4. Se ejecuta en la web real una solicitud en nombre del usuario
(que no ha realizado él realmente).

Y ale, esta sería exactamente la definición que podrías haber

encontrado buscando 15 minutos en Google. Todo claro, ¿cierto?

Bueno, ya me imagino que no, pero tranqui, ya sabes que yo no explico

las cosas así. Vamos allá.

El ejemplo va a ser un poco largo, pero es muy importante que entiendas

bien dos cosas.

1- La vulnerabilidad es culpa de LA WEB, el usuario no puede hacer

nada.
2- La vulnerabilidad es MUY GRAVE.
CSRF – Robando cuentas bancarias
Vamos a inventarnos una historia para entender cómo funciona esta
vulnerabilidad.

Eres un chaval/chavala joven, la vida te sonríe y ya tienes tus

primeros billetes guardados en la misma hucha que utilizabas con 13
años. Se te empieza a quedar un poco pequeña y te apetece pagar con
tarjeta.

Vas al banco, todos te quieren cobrar muchísimas comisiones, no hay

manera de encontrar nada que encaje contigo. Lo poco que tienes, te
lo quieren cobrar.

Abren un banco nuevo, no parece el mejor del mundo, pero te hace el

apaño. Además, no te cobran ninguna comisión.

Te comentan que están creando su página web y que has tenido suerte,
justo ahora acaban de lanzarla definitivamente. Y allá que vas.

¿El problema? No han querido invertir en ciberseguridad. Pero la

página no les ha quedado mal del todo. Vamos a poner una captura de
pantalla de la página principal:

Nos vamos a fijar en el punto interesante, donde un atacante se

fijaría primero. “Enviar dinero”.

Vale, como cualquier hacker lo primero que hay que hacer está claro
(te lo he dicho ya 20 veces), hay que entender cómo funciona la web.

Y lo hace de la siguiente manera:

 - Escribes una cuenta destinatario
- Escribes una cantidad de dinero
- Le das al botón verde
- Se genera una petición

¿Cómo es esa petición? Pues sería algo como esto:

Me imagino que a estas alturas ya entiendes lo que está pasando.

Pausa momentánea, ¿en el instante que empezaste este libro,

entenderías algo? Rompemos la pausa, quería que pensaras eso.

Vamos a detallarlo:

- El usuario ha presionado el botón, y se genera una petición

- La petición contiene (de arriba a abajo):
o La dirección del servidor a la que dar la orden
o La cookie de sesión del usuario actual (para confirmar que
tiene la sesión iniciada)
o La cuenta destinataria del dinero
o La cantidad de dinero a enviar
- El servidor recibe la petición

Y a partir de ahí ya no nos interesa, simplemente interpreta los datos

que recibe y hace lo que tiene que hacer.

En este caso pasar fondos de la cuenta del usuario actual (345€) a la

cuenta destinatario (123124).
Bien, hasta aquí ya hemos entendido cómo se transfiere dinero. Se
genera una petición desde nuestro navegador, con unos datos de
transferencia, que posteriormente el servidor del banco interpreta
para realizar la operación correctamente.

Ahora quiero que te imagines que existe un ciberdelincuente que

descubre este funcionamiento, y crea una página web cualquiera. Por
ejemplo, la típica de videojuegos pirateados:

Bien, ya tenemos todo el coctel preparado. ¿Recuerdas JavaScript,

cierto? Que permitía leer cookies, hacer peticiones, etc...

Y que se lanzaba en el momento en el que abrías la página web.

¿Se te ocurre por donde van a ir los tiros?

Es probable que estés muy cerca de acertar.

La web tiene un script oculto. No lo puedes ver y tampoco le vas a

prestar atención.
Si entras, ya te han pillado. El script hace lo siguiente:

- Crea una solicitud falsa:

o Con la dirección de su cuenta
o 2000 euros de cantidad
- La envía a la web del banco

Tienes que recordar 2 cosas muy importantes.

La primera es que el ciberdelincuente sabe perfectamente cómo funciona

la página web, y es por eso por lo que está haciendo una implementación
personalizada para atacarla.

La segunda es que recuerdes que JavaScript se ejecuta desde tu propio

navegador. Desde el lado del CLIENTE. ¿Y sabes qué tiene esto de
importante?

Que la llamada al banco no la está ejecutando el ciberdelincuente. Se

está ejecutando desde tu navegador. La estás ejecutando TÚ.
Exactamente igual que si pulsases el botón de la página del banco, no
existe ninguna diferencia.

Internet no entiende de botones, entiende de paquetes.

Y como la web del banco no está protegida, se lo come.

Has entrado a una web, y sin hacer nada más, han transferido 2000
euros de tu cuenta a un delincuente.

Pues yo creo que después de aprender esto... Lo mejor va a ser

practicar. Pero sin robar a nadie, que somos buenos.

CSRF – Nuestro propio atraco

Primera prueba para la que necesitas cumplir requisitos. Te doy dos
alternativas:

- Conocer la utilización de “Burpsuite” o cualquier otro editor

de paquetes aplicado a técnicas de hacking web. Además, tener
una cuenta en https://portswigger.net
- Completar el apartado “SSTI” de este mismo libro.

O la una, o la otra.

Y efectivamente, si completas la segunda automáticamente cumples la

primera.

Esta es la misión que vamos a llevar a cabo: Nuestro atraco

IMPORTANTE

Para que funcione esta misión, tienes que hacerla desde el navegador
de Burpsuite.

Ábrelo, vete a “Proxy” y dale a “Open Browser”. El resto funciona

exactamente igual.

Seguimos.

Espero no tener que decirte (una vez más) lo que tienes que hacer.
Leer y aprender a usar la web. No te diré cuáles son el usuario y la
contraseña que tienes que usar. Lo pone la descripción que te tienes
que leer.

Te recomiendo lo siguiente:

- Haz algunas tareas normales en la web con Burpsuite encendido y

activado
- Detecta algún paquete que podría ser interesante explotar
(pista: los POST son los más interesantes)
- Prueba a alterar el paquete desde Burpsuite, comprueba su
funcionamiento.
- Investiga cómo podría ser interesante explotarlo.

Última pista antes de darte la solución:

Ya está, vamos con ello.

Si no te habías dado cuenta, el paquete que es interesante capturar

es la “modificación del email”.

Obsérvala bien en Burpsuite, porque vas a tener que replicarla.

Esta sería la petición:

Ahora tienes dos alternativas

1. Utilizar el apartado “Go to exploit server” que aparece encima

de la web de PortSwigger y seguir los pasos de su solución.
2. Crear tu propia página web que explota la vulnerabilidad.

¿Cuál crees que vamos a hacer aquí? Pues hombre... Si quisiera que
siguieras los pasos te mandaba a hacer el tutorial. Aquí estamos para
aprender cómo funcionan las cosas de verdad.

Vamos a darle caña, a crear nuestra propia web atacante.

Vale, arriba tenemos el paquete que tenemos que enviar desde nuestra
web atacante.

Podemos ver que se envía a una dirección concreta que es tal que:

' https://<identificador>.web-security-academy.net/my-
account/change-email’
Te señalo la parte de <identificador> porque cada usuario tiene uno,
no puedes copiar el mío. Fíjate en el que te aparezca en Burpsuite.

Bien, ahora queremos crear una página web que, al abrirse, lance una
petición como esa, pero con un correo hackeado. Y es lo que vamos a
hacer.

Esta es la idea:

Vale, ya entendemos lo que tiene que pasar. Ahora hace falta lanzar
la página web (la vamos a lanzar en nuestro propio ordenador, como es
lógico, pero se podría lanzar en Internet para que entrase cualquiera
y el funcionamiento sería el mismo).

Te daré el código fuente de una página web que hace lo que te acabo
de decir. Pero te voy a poner una captura de pantalla porque quiero
que lo copies. No quiero que copies y pegues, quiero que entiendas lo
que está pasando (es muy corto, no quiero quejas).

Aquí está:

Fíjate que no es que la URL tenga un salto de línea, es que era tan
larga que tenía que hacer la captura así.

Ese código hace lo siguiente:

- Cuando un usuario entra a la web, crea un formulario de contenido

“email= [email protected]”
- Toma ese formulario y se lo envía mediante un POST (como el
original) a la dirección que hemos especificado en “action”

Y ya está, es lo único que hace, es muy sencillo.

Es importante que lo guardes en un archivo con nombre exacto

“index.html”.

Ahora, quiero que abras una consola en la misma carpeta que se

encuentra este archivo (recuerda que estamos en un sistema Linux,
aunque puedes buscar cómo ejecutar Python en Windows).

Y vas a ejecutar este comando en esa consola:

‘python3 -m http.server 8888’

¿Qué hace? Lanza un servidor http en el puerto 8888 de tu ordenador.

Vamos, que levanta una página web con el contenido del archivo
“index.html” que tengas en tu carpeta.
Pasará algo como esto:

Vamos a confirmar que nuestro correo sigue intacto, aquí está:

Y ya está todo listo. Ahora basta con que copies en tu navegador esta
dirección: http://localhost:8888

He hecho una captura de pantalla a la velocidad de Flash, esto pasa

muy rápido. Ahí podemos ver el formulario (aunque podría estar
oculto).
Y de repente estamos aquí. Con el correo cambiado. Menuda gracia.

CSRF – Defensa
La defensa frente a este tipo de ataques está fuera del alcance de
este libro, pero si te interesa saber cómo se paran (para quedarte
tranquilo, nadie te va a robar nada del banco por entrar a una web),
puedes buscar en Google o preguntarle a ChatGPT sobre los “CSRF
tokens”, es un tema interesante.
SSRF
Te estás acercando al final. Vamos a hablar de la última vulnerabilidad
web de todas, que se parece mucho a la anterior.

En este caso, hablaremos de Server-Side Request Forgery. Esta

vulnerabilidad ocurre cuando una página web permite que un usuario
haga solicitudes en nombre de SERVIDOR a otras direcciones no
autorizadas originalmente.

Date cuenta, en el CSRF estábamos atacando al CLIENTE, pero ahora

vamos a atacar al SERVIDOR.

¿Cuándo aparece esta vulnerabilidad? Normalmente cuando el usuario

puede introducir alguna URL.

Por ejemplo, imagínate que estás en una página web que te permite
ponerte tu imagen de perfil a través de una URL. Seguro que te suena
porque esta opción está disponible en muchos sitios.

¿Cómo funciona esta implementación? De esta manera:

 1- El usuario introduce la URL y la envía
2- El servidor la recibe y la busca en Internet
3- Internet le devuelve la imagen acorde a la URL
4- El servidor la almacena y cambia tu foto de perfil

Bien, pero ¿qué pasa si el servidor no maneja adecuadamente las

direcciones URL que se introducen? Que se pueden trampear.

¿Recuerdas cuál era la dirección URL del propio sistema que está
ejecutando un servidor? Efectivamente, “localhost”.

Entonces, qué pasaría si la url fuera algo como esto:

‘http://localhost:80/secretos/secretos.txt’
Tú desde tu navegador no tienes permiso para acceder a ese archivo,
por supuesto, es un secreto. Pero es que tú no eres el que está
haciendo la petición, la está haciendo el SERVIDOR.

1- El usuario introduce la URL con “localhost” y la envía.

2- El servidor la recibe.
3- El servidor busca en “localhost”, es decir, dentro de SI MISMO.
4- Devuelve el resultado como si fuera la foto de perfil.

Esto es lo que pasa cuando confías demasiado en los usuarios. No te

puedes fiar de los usuarios. Porque de cada 1.000 buenos, habrá uno
malo. Y te puede tocar a ti.
Pues ya sabes lo que toca, a practicar.

CSRF - Explotación
Requisitos previos (imprescindible uno/ambos):

- Conocer la utilización de “Burpsuite” o cualquier otro editor

de paquetes aplicado a técnicas de hacking web. Además, tener
una cuenta en https://portswigger.net
- Completar el apartado “SSTI” de este mismo libro.

Vamos a atacar este laboratorio.

No voy a decir ni una palabra. Ya sabes lo que tienes que hacer.

Investiga.

Pistas:

- Lee bien el enunciado.

- Utiliza Burpsuite para capturar alguna petición interesante.
- Esta vez no tienes credenciales, no te centres en el menú de
usuario, busca en el resto de las cosas que se pueden hacer en
la web.

Vamos con la solución. Pero te pediría que lo intentases un poco

primero, que ya no eres ningún novato...

La petición interesante que había que encontrar es la de “Check Stock”

dentro de los productos.
Es momento de que la captures con Burpsuite. Yo haré lo mismo.

Hombre, la parte de stockApi... Parece bastante suculenta. Eso es una

URL, y nosotros ya sabemos cómo tratar las URLs.

Pistas:

- Lee el enunciado. Hay una web escondida en alguna URL de

“localhost”.
- Por ahora no te centres en eliminar al usuario, solo en acceder
a la web escondida.

La web está clara, lo pone el enunciado. Hay que acceder a:

‘http://localhost/admin’

La solución al problema parece muy clara, vamos a pegar esa dirección

en stockApi y a ver qué pasa.

Parece que no funciona... Vamos a ver por qué.

En Burpsuite, en el apartado “Proxy”, haz el favor de entrar a “HTTP

History” y busca la llamada que acabamos de hacer. Haz click encima,
tiene una pinta como esta:
Una vez haces click, abajo te aparecen tanto la petición como la
respuesta, y nos llevamos una sorpresa.

“Blocked for security reasons”, raro...

Me parece que lo que puede estar pasando es que tienen “capados”

algunas entradas, están protegidos.

Lo más habitual es prohibir entradas como “localhost”, “127.0.0.1”

(que es lo mismo que ‘localhost’), “admin”, “private”... Todo ese tipo
de textos, vaya.

Pero el problema de hacer esta técnica, que se denomina “BlackList”,

porque haces una lista negra de los textos que no aceptas, es que se
te puede olvidar algo.

De hecho, se te pueden olvidar muchas cosas. Como por ejemplo estas

2:

- ‘http://127.1’ es lo mismo que ‘http://127.0.0.1’

- Las letras se pueden escribir como letras o encodeadas, por
ejemplo, una ‘a’ encodeada se puede escribir como ‘%2561’

Y con esos 2 olvidos, ya es suficiente para explotar la web.

Porque ahora basta con introducir esta URL:

‘http://127.1/%2561dmin’
Y ahí está, donde antes aparecía un error en la web, ahora aparece
esto:

Ya sabes lo que tienes que hacer para completar el nivel. Lo pone el

enunciado.

SSRF – Extra
He querido que hicieses directamente un ejercicio complicado. ¿Por
qué? Porque quiero que hagas los sencillos sin mi ayuda.

Te los dejo aquí, estoy más que seguro de que no te costarán mucho
esfuerzo:

Ejercicio 1

Ejercicio 2
ATAQUES DE CONTRASEÑA
Vamos a aprender cómo se crackean contraseñas débiles, y vamos a
demostrar el porqué de construir una contraseña larga, fuerte y con
todo tipo de caracteres para evitar quedarnos sin cuenta algún día.

Para aprender cómo funciona el crackeo de contraseñas, primero tienes

que entender cómo funcionan las contraseñas. Me imagino que nunca te
lo habías planteado si no has dado coletazos en esto de la
ciberseguridad.

Las contraseñas no se almacenan como texto plano (al menos, no

deberían), así que me imagino que te estás llevando la primera
sorpresa. Si tu contraseña es “seguridad1234”, eso no es lo que se
guarda en la base de datos de la web donde te estés registrando. Lo
que hará esa web es calcular un ‘hash’. Así, tu contraseña estará
segura (vamos a verlo).

Hashes
Un algoritmo de hashing es una operación matemática unidireccional
(que no tiene retorno) por el que cualquier texto o entrada se
convierte en una cadena de caracteres de un tamaño prefijado.

Que no se te haga bola la definición.

Vamos a suponer que tenemos un algoritmo de hashing de 64 bits, es

decir, que los resultados siempre tendrán 64 bits (8 caracteres).

Bien, pues introduzcamos el texto que introduzcamos va a pasar algo

como esto:
No importa el tamaño del texto original, siempre será de 64 bits.

Conocer esto es importante, ¿por qué es tan importante? Porque

significa que hay un número limitado de hashes.

Piénsalo bien, si un texto puede ser “infinito” y el hash siempre va

a tener 64 bits de tamaño… Llegará un momento en el que dos textos
diferentes tengan el mismo hash, solo hay que buscar lo suficiente.

Y efectivamente, esto puede suceder, y se llama “colisión de hash”.

Apúntatelo en la cabeza.

Almacenamiento de contraseñas
Como bien veníamos diciendo, las contraseñas se almacenan “hasheadas”
en las bases de datos de la grandísima mayoría de servicios. Esto se
hace con la finalidad de que, en caso de ser robadas, no puedan ser
recuperables.

Recuerda que no hay vuelta atrás para un algoritmo de hashing.

Es decir, se guardarían tal que así en la base de datos real:

En caso de que un delincuente consiguiese acceso a esa base de datos,

“jamás” podría recuperar la contraseña.

Inicios de sesión
Si hemos quedado en que el servicio no almacena la contraseña, ¿se
puede saber cómo sabe cuál es la correcta cuando estamos iniciando
sesión? Pues es más sencillo de lo que te imaginas.

Existen diferentes algoritmos de hashing, muchos, no nos vamos a meter

en eso. Pero el servicio conoce cuál está utilizando (en nuestro caso,
estábamos usando uno inventado de 64 bits).
En el momento en el que el usuario introduce la contraseña para iniciar
sesión, el servicio la “hashea” y la compara con la que tiene
almacenada en su base de datos. Si ambos hashes coinciden, significa
que la contraseña es exactamente la misma.

Bueno, no significa que sea la misma, significa que tiene exactamente

el mismo hash… ¿pillas por dónde voy?

Las comprobaciones que hace el servicio no conocen la contraseña real

y únicamente pueden guiarse por la contraseña hasheada.

Colisión de hash
Vamos a ponernos en la peor de las situaciones: se filtran las
contraseñas de los usuarios y se detecta el algoritmo de “hasheo” de
las contraseñas (es relativamente sencillo de detectar).

Dirás que bueno, tampoco pasa nada, si no se puede dar marcha atrás.

Y no te falta razón, pero se puede dar marcha adelante. Me explico.

Piensa en esto, el algoritmo de “hasheo” es como una máquina que traga

piedras, y existe una piedra concreta que se convierte en un diamante
(el diamante es el hash de la contraseña).

Tú tienes el diamante delante, estupendo, pero no te sirve para nada.

Lo que tú quieres es poder replicarlo (encontrar la contraseña
original).

¿Cómo vas a saber qué piedra se convierte en un diamante y no en

basura?

Pues la respuesta es evidente, y es exactamente la que te imaginas:

metiendo todas las piedras que puedas a la máquina. Todas las que se
encuentres. Alguna tendrá que ser.
Dicho en informático, probando a calcular el “hash” de todas las
contraseñas que se te ocurran. Cuando un hash coincida con el objetivo,
bingo, contraseña encontrada.

Ataque de “tablas arcoíris”

El ataque de “tablas arcoíris” es el más habitual, y tiene un enfoque
un poco diferente a lo que te acabo de explicar.

Todos sabemos que hay contraseñas que se utilizan muchísimo de manera

predeterminada (admin, password123, soyElMejor…). Todos esos hashes
ya están calculados de antes y almacenados en unas tablas que se
llaman “rainbow tables”.

Un ataque “rainbow table” significa buscar un “hash” específico en

una lista que ya está previamente creada. Si el hash existe dentro,
se devuelve la contraseña. Si no existe, no se devuelve nada.

Esto sería una tabla arcoíris con las contraseñas que te he mencionado:

Este tipo de ataques nunca averiguarán una contraseña que no tengan

registrada desde el inicio.

Te voy a enseñar a ejecutar un ataque de este estilo de la manera más

sencilla posible. Atento.

Para ello, voy a utilizar al que debería ser tu amigo de la manera

más sana del mundo, sin pasarte: ChatGPT.

Voy a preguntarle por el hash de una contraseña clásica,

“password123”. Y esta es su respuesta (no lo voy a copiar, prefiero
que tengas que seguir mis pasos).
Bien, ya podemos suponer que ese hash lo hemos obtenido de una
vulneración de una base de datos. Pero claro, solo tenemos el hash,
no tendríamos la contraseña. Es el momento de atacarla con un ataque
de tablas arcoíris.

Accede a la página web de CrackStation. Ahí puedes pegar el hash y

ver cómo sucede la magia. No le ha costado ni un segundo romperla.

De hecho, en caso de que esté contenida en la lista, no importa el

tamaño de la lista, podría tener millones de contraseñas y siempre
tardaría lo mismo, un segundo (eso ya es otro tema que no tiene que
ver con la ciberseguridad, sino con la informática). Si tienes
curiosidad, pregúntale a ChatGPT sobre “complejidad de acceso a datos
en un diccionario”, a ver si te cuenta algo interesante .

Aquí puedes ver cómo ha tumbado la contraseña:

Puedes probar con otras contraseñas y ver cómo el resultado es siempre

el mismo, es decir, que las encuentra (prueba con contraseñas en
inglés mejor que en castellano).
Ataque de fuerza bruta
Este ataque es malo, muy malo. Y lento, muy lento. Vas a entenderlo
muy rápido.

Vamos a ponernos en la situación de que tienes información interna y

sabes que las contraseñas son de 5 letras minúsculas. Una basura de
contraseña, me dirás tú (no te falta razón).

Pues bien, el abecedario castellano tiene 27 letras (sí, da igual que

tenga una ‘ñ’).

Para cada una de las 5 letras existen 27 posibles combinaciones.

Es decir (otra vez), el total de combinaciones son

27 * 27 * 27 * 27 * 27 = 14,348,907 contraseñas

Parece broma (ojalá lo fuera), pero solo con 5 letras minúsculas ya

puedes crear 14 millones de combinaciones diferentes, cada una sería
una contraseña. Estupendo, ahora pone en la situación de que la
contraseña es de 8 caracteres, con mayúsculas y caracteres especiales
(hablamos de unas 70 posibilidades por letra).

8 letras con 70 posibilidades.

Queda la cosa tal que:

70 * 70 * 70 * 70 * 70 * 70 * 70 * 70 = 576,480,100,000,000

Si en vez de contraseñas estuviésemos hablando de metros y

considerásemos ese número como una distancia, podrías ir de la Tierra
a la Luna y volver.

Bueno, para ser exactos, podrías hacerlo 1 millón de veces.

Y eso es una contraseña de simplemente 8 caracteres.

¿El ataque es una porquería y es probable que jamás tenga ninguna

utilidad? Exactamente.

¿Te voy a enseñar a hacer fuerza bruta igualmente? Exactamente.

Vas a necesitar un ordenador con Linux si quieres seguir mis pasos a

partir de aquí. Te recomiendo que busques en Youtube “cómo crear una
máquina virtual con Kali Linux”. Podría meterlo para sumar páginas y
venderte esto más caro, pero ¿qué sentido tiene no aportarte nada
nuevo? Ninguno.

Con todo lo que has hecho hasta ahora en el libro (que ya te digo que
es mucho) estoy seguro de que te apañarás. Vamos allá.

En caso de que no tengas hydra (está instalado de manera predeterminada

en Kali Linux, pero lo digo por si utilizas otra versión) necesitarás
instalarlo. Para ello, abre la consola e introduce los siguientes
comandos (perdón, ya sé que esto no es un curso de Linux, pero es
necesario):

sudo apt-get update

sudo apt-get install hydra

Para comprobar que todo está correcto, ejecuta el comando “hydra”:

Bien, ahora vamos a lanzar un servidor de apache simulando un servidor

real del que robar las contraseñas. No quiero que te líes ni que te
asustes. Lo que vamos a hacer solamente es crear un servidor web que
en vez de estar en internet está en nuestro propio ordenador. Una
página web privada, digamos.

Esto se complica un poco (pero muy poco).

Ejecuta los comandos según los voy ejecutando yo, y entiende en todo
momento lo que está sucediendo.

Instalamos los paquetes necesarios para lanzar nuestro nuevo servidor

inseguro.

‘sudo apt-get install apache2 apache2-utils’

Configuramos la contraseña para una autenticación básica en el
servidor (del usuario llamado “testuser”). Te va a pedir que
introduzcas una contraseña, es importante que sea toda en minúsculas
y (preferiblemente) de 3 letras. Esto es para que la demostración
tarde muy poco. De hecho, te reto a que introduzcas 3 letras sin
mirar, así tiene todo más gracia.

‘sudo htpasswd -c /etc/apache2/.htpasswd testuser’

Observamos cómo se ha guardado la contraseña en el archivo que acabamos

de configurar ahora mismo (por ahora no te voy a decir la contraseña
que he elegido yo):

‘cat /etc/apache2/.htpasswd testuser’

Y efectivamente, como te había explicado antes, la web lo ha almacenado

como un hash, no ha almacenado el texto plano. Y aquí es donde tú te
piensas que estás completamente seguro.

Ahora, vamos a configurar el servidor para que funcione con

autenticación básica. Esto quiere decir que cuando alguien intente
acceder (nosotros) le aparecerá una pantalla exigiéndole que
introduzca un usuario y una contraseña válidos. Una contraseña que no
se sabe.

Para ello, hay que modificar un archivo. Repite exactamente los pasos
que voy a indicarte aquí:

1- ‘sudo nano /etc/apache2/sites-available/000-default.conf’

(ejecútalo en la consola)
 2- Baja hasta abajo del todo del archivo (con la flecha del teclado
hacia abajo)
3- Copia este texto:
<Directory "/var/www/html">
AuthType Basic
AuthName "Restricted Content"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
</Directory>
4- Presiona a la vez Ctrl + Shift + V donde estabas en el fichero
5- Presiona a la vez Ctrl + X
6- Dale a la tecla ‘y’
7- Dale a la tecla ‘Enter’

Perdona por esto que es un poco más complicado, pero es que es

necesario para que funcione la autenticación.

Como último paso, hay que reiniciar Apache:

‘sudo systemctl restart apache2’ (ejecuta en la consola)

Ahora, si en el navegador buscas “http://localhost:80” te saltará la

autenticación.

Ya tenemos una página web privada en la que tenemos un usuario

“testuser”, una contraseña desconocida, y muchas ganas de hackear.
Si no te ha funcionado, repite los pasos desde el principio, debes
haberte saltado algo.

Bien, nosotros conocemos el usuario, pero no la contraseña. Aun así,

nos hemos infiltrado en la empresa y a la gente le gusta mucho
hablar, hemos escuchado “por ahí” que la contraseña solo tiene 3
letras minúsculas. Toca hacerle fuerza bruta, a por ella.

Para ello vamos a utilizar “Hydra” que básicamente va a hacer esto:

Es justo de lo que hablamos. Va a probar todas las combinaciones de

letras minúsculas de 3 letras (en la imagen aparecen 4, pero quedaba
más bonita la imagen).

Concretamente, lo que va a probar son:

26 * 26 * 26 = 17,576 contraseñas

Para 3 simples letras. Parece hasta broma. Y te puedo hacer la

estimación de que es capaz de probar unas 2,000 por minuto (por
experiencia).

Toca ejecutar el comando definitivo:

‘hydra -l testuser -x 3:3:a -s 80 -f localhost http-get -t 4’

• hydra - ejecuta la herramienta

• -l <nombre> - indica el nombre del usuario
 • -x 3:3:a – indica que el ataque se realizará sobre textos de 3
letras minúsculas.
• -s 80 – especifica el puerto del ataque (apache se lanza de
manera predeterminada en el puerto 80)
• -f – detiene la herramienta cuando encuentra el valor válido
• Localhost http-get – ejecuta peticiones de tipo GET
• -t 4 – utiliza 4 hilos en vez de mandarlas todas 1 por 1

Basta con esperar un par de minutos. Y ahí está:

El hash que estaba almacenado en la página web proviene del texto

“euc”. Si ahora accedemos a la web con esas credenciales… Pues
efectivamente, estamos dentro.

¿Se puede hacer de una manera más rápida? Pues sí, pero necesitarías
haber tenido acceso al hash, que no es lo más habitual.
Esta circunstancia se puede dar de muchas maneras (nuestro caso va a
ser que lo vamos a mirar en el propio fichero porque somos
todopoderosos):

- Filtraciones de base de datos

- LFI
- Manejo incorrecto de permisos en ficheros
- .....

No es necesario que repliques estos pasos (por supuesto, te animo a

que lo hagas), los voy a pasar un poco más por encima porque me
interesaba que conocieses el ataque web de fuerza bruta a la
contraseña. Esto es una variante diferente pero similar.

Vamos a poner el caso en el que has tenido acceso al hash por algún
acceso “no permitido” a la base de datos, y evidentemente es inviable
hacer 15.000 peticiones al servidor (te van a pillar) o ponerte a
esperar todo el tiempo que tarda en ejecutarse.

Yo me he copiado los datos obtenidos a un archivito llamado “hash”:

Ahora, voy a utilizar una herramienta llamada “crunch". Es muy útil,

sirve para crear todas las posibles combinaciones de palabras, en
nuestro caso, de 3 letras minúsculas (se pueden hacer muchas cosas
más).

Se hace de la siguiente manera:

‘crunch 3 3 abcdefghijklmnopqrstuvwxyz -o palabras’

Y se crea un archivo llamado “palabras” con todo ese contenido. Bien.

Ahora ejecutaré “hashcat”, una herramienta que es una pasada, te

recomiendo que leas sobre ella (la documentación y las aplicaciones
son ilimitadas). Su uso principal es romper hashes encontrando la
contraseña original. Es decir, va a intentar tumbar el hash que le
estoy pasando, utilizando todas las posibles palabras que también le
estoy pasando.

‘hashcat -m 1600 hash palabras’ (consola)

• hashcat – la herramienta
• -m 1600 – el tipo de hash
• hash – fichero que contiene el hash
• palabras – listado de palabras

Si no lo has ejecutado conmigo, ya te digo yo lo que ha pasado. Ha

tardado un segundo, nada de 2 minutos, 1 segundo. Mucho más rápido
que las peticiones a la web, pero como la pongas a encontrar una de
10 caracteres, bueno… mejor deja el ordenador encendido… hasta que te
mueras.

Ataque de diccionario
Es el ataque clásico para tumbar contraseñas. El día a día.

Pero ¿sabes lo mejor? Que ya has entendido el ataque anterior. Ya has

entendido por qué es tan malo, y seguro de que te había ocurrido esta
idea antes incluso de que yo te la estuviese diciendo ahora mismo.

¿Por qué no en vez de probar todas las combinaciones, simplemente

probamos contraseñas típicas? Las contraseñas se reutilizan.
“password” es una de las contraseñas más utilizadas del mundo, tanto
en el ámbito personal como empresarial.

Pues es exactamente cómo funciona. De hecho, se ataca con el mismo

comando que habíamos utilizado antes.
Con este:

‘hashcat -m 1600 hash palabras’

¿Cuál es la única diferencia? Que en vez de utilizar “palabras”, que

era un archivo de texto con absolutamente todas las combinaciones de
letras, utilizaremos un archivo de contraseñas típicas llamado
“diccionario”.

El diccionario más típico es este: Diccionario (si das click aquí te

lo descargas).

Rockyou.txt tiene 14 millones de contraseñas típicas obtenidas de

filtraciones reales de datos. No es ninguna tontería, casi todo está
ahí.

Y te lo digo yo, la mayoría de las contraseñas, caen.

LECCIÓN
Prácticamente has acabado. Quiero que mires al comienzo de este libro
y pienses si te habrías creído capaz de todo esto.

Me imagino que no, y aquí estás.

La ciberseguridad es investigación, es diversión, es reto, es lucha,

es esfuerzo, es frustración, y es SEGURIDAD.

Protege tu vida en Internet, protégete a ti, protege a tus seres

queridos, y sigue estudiando mucho.

Te aseguro que serás un gran hacker, y te pido por favor que cuando
eso pase, me lo cuentes.

No te voy a comer la cabeza, esto no es un libro de motivación (ya lo

hago a veces en la Newsletter). Pero piensa en lo que has conseguido.

Nos volveremos a ver, seguro que sí.

Y, por cierto. Pórtate bien, que con estos conocimientos puedes ser
muy malo.
FIN
Hemos llegado al final. Se ha acabado.

Ha sido muy bonito, y tengo un último reto para ti.

No te voy a ayudar, no te voy a explicar nada.

‘7fd75c68b6080fee0f384a71049661526d4a49c16b15ac158e40121b26eedb3c’

Tómatelo como quieras. Es mi mensaje final.