OWASP TOP 10
Last updated
Last updated
Contenido
SEVERITY 1 3
EJERCICIO 1 4
EJERCICIO 2 4
EJERCICIO 3 5
EJERCICIO 4 5
EJERCICIO 5 6
EJERCICIO 6 6
SEVERITY 2 7
EJERCICIO 1 y 2 7
SEVERITY 3 8
EJERCICIO 1 8
EJERCICIO 2 9
EJERCICIO 3 y 4 9
EJERCICIO 5 10
SEVERITY 4 11
EJERCICIO 1 13
EJERCICIO 2 y 3 13
SEVERITY 5 13
EJERCICIO 1 14
SEVERITY 6 14
EJERCICIO 1 14
SEVERITY 7 15
EJERCICIO 1 16
EJERCICIO 2 16
EJERCICIO 3 16
EJERCICIO 4 17
EJERCICIO 5 17
SEVERITY 8 19
EJERCICIO 1 19
EJERCICIO 2 20
EJERCICIO 3 20
SEVERITY 9 23
SEVERITY 10 25
EJERCICIO 1 25
EJERCICIO 2 25
En este primer caso tenemos un servidor que tiene el siguiente código ejecutándose:
En este código lo que introducimos en el campo input va a la variable commandString , acto seguido pasa al try y se ejecuta la función passthru que en php lo que hace es pasar directamente el comando introducido , lo ejecuta y te muestra la respuesta en el navegador.
Por lo que cualquier comando que ejecutemos en el campo de entrada nos devolverá la respuesta como si fuese una ventana de cmd.
Lo primero que nos preguntan es el nombre del archivo extraño en el directorio root , para esta respuesta simplemente ejecutamos un ls
R: drpepper.txt
Luego nos preguntan por el numero de non-users/non-services/non-daemons para ello ejecutaremos el siguiente comando:
cat /etc/passwd | cut -d: -f1
Este comando nos muestra el contenido el archivo passwd y lo corta por el primer campo delimitado por : y nos muestra lo siguiente:
Como podemos ver no hay nada que no sea usuario , servicio o demonio
R: 0
Ahora nos preguntan por el usuario que estamos utilizando , si hacemos un:
Whoami
R: www-data
Ahora preguntan por como esta el Shell nombrado , para ello volvemos al archivo /etc/passwd pero esta vez lo filtramos con grep por el nombre del usuario:
Cat /etc/passwd | grep www-data
R: /usr/sbin/nologin
Para el siguiente apartado nos piden la versión de Ubuntu que esta corriendo , para ello ejecutaremos el siguiente comando:
Lsb_release –a
R: 18.04.4
Por ultimo nos piden la bebida que aparece en el mensaje de MOTD (message of the day). Para ello debemos hacer un cat a la ubicación donde el archivo motd se encuentre , aunque antes se ubicaba en /etc/motd ahora su ubicación es /etc/update-motd.d :
Tras hacer un ls vemos diferentes script , vamos a printear el primero el 00-header ya que los dos primeros números indican el orden y lo que le sigue es la descripción del script.
cat /etc/update-motd.d/00-header
R: DR PEPPER
En este apartado simplemente se habla de la importancia de la authentificacion. El tema del usuario y la contraseña, para mitigar este tipo de ataques :
Tener buena política de contraseñas seguras
Utilizar la doble autentificación
Y para evitar ataques de fuerza bruta , cada cierto numero de intentos de logear que se bloquee la webapp
Simplemente hay que registrarse como el usuario que te dice pero con un espacio delante del nombre , asi la web se cree que es el mismo usuario , y al acceder ves la flag.
En este apartado se habla de la importancia de tener bien protegida tu base de datos. En este caso no habla de tener tu base de datos instalada en un servidor sino directamente en un archivo. Ej: database.db
Para acceder al contenido de dicho archivo en kalo se utiliza el paquete sqlite3
EJ: sqlite3 database.db
Y ya una vez dentro puedes ejecutar cualquier consulta sql.
Luego te dice como romper hashes md5 con crackstation nada nuevo.
Hay que encontrar un directorio oculto en el login para ello vamos a mirar el código fuente:
R: /assets
Vamos a ese directorio y nos preguntan que archivo parece que tiene información sensible
R: webapp.db
Para este ejercicio nos piden el hash md5 del usuario admin , para ello primero nos descargamos la base de datos y la ejecutamos con sqlite3:
Primero hacemos un .tables para ver las tablas y luego un SELECT * de esa tabla. Como podemos ver la contraseña es el 3º campo.
R:
Nos logueamos como el admin y vemos la flag
R:
Un ataque XML External Entity (XXE) es un típico de ataque que se aprovecha del XML parser y te permite interectuar con dispositivos del backend u otra parte de la red. Esto te permite acceder a cierta información que la aplicación web tiene acceso ,también puedes provocar denegación de servicio DOS o SSRF (ataque de petición en el lado del servidor).
Hay dos tipos de ataques :
In-band: recibes respuesta inmediata del payload
Out-of-band: debes guardar la respuesta del servidor en por ejemplo un archivo
De xml estaría bien decir que es un tipo de lenguaje diseñado para que tanto persona como maquina puedan entenderlo.
Ademas es independiente de la plataforma y del lenguaje utilizado en la plataforma.
Un documento xml suele empezar asi:
Y luego todo archivo xml debe tener un root:
En este caso es el mail. Comentar también que xml es case sensitive , es decir cuidado con las mayusculas.Y como html también tiene atributos en sus etiquetas.
Las siglas de xml
R: extensible markup language
Para entender xml también hay que hablar de DTD (document type definition) en un tipo de documento que establece la estructura y los atributos de un archivo xml.
Suele tener esta estructura:
Con !doctype determinas el elemento ROOT
Con !element añades un elemento al archivo
Con !entity añades una nueva entidad
Luego suele añadirse al xml de esta manera:
En cuanto al payload tiene esta pinta:
Aquí estamos creando una nueva entidad con el nombre read que lo que hace es mediante el atributo system ir a buscar la ruta que le hemos especificado dándote el archivo.
Si lo ejecutamos en la maquina objetivo:
Nos piden el usuario que se muestra en etc/passwd como los usuarios no genéricos están al final nos fijamos en la captura anterior y vemos que es falcon
R: falcon
Nos piden donde esta almacenada la clave ssh privada de falcon , normalmente las claves ssh suelen estar en /home/usuario/.ssh/id_rsa asi que lo añadimos a nuestro payload y :
Y sus primeros 18 digitos:
Aquí estaría bien hablar del tema del IDOR (Insecure Direct Object Reference) que es el hecho de poder acceder a recursos que no deberías poder acceder sin ciertos privilegios. Como por ejemplo al acceder a tu banco mediante la siguiente url :
Y cambiar el 1234 por otro numero y acceder a la cuenta bancaria de otra persona.
Nos piden la flag de la maquina objetivo , accedemos con las credenciales que nos indican :
Si seguimos el consejo de antes vamos a cambiar el note=1 por otro valor como por ejemplo el 0:
R: flag{fivefourthree}´
Esto se suele dar cuando hacen una configuración de seguridad errónea cuando se pudo configurar de forma correcta.
Te piden que hackees la maquina , al acceder vemos esto:
Si buscamos las credenciales por defecto en internet de pensive notes:
Si utilizamos estas credenciales:
Aquí hablamos de XSS (cross site scripting) que es ejecutar scripts (código malicioso) en la maquina de la victima. Para ejecutar XSS se puede utilizar Javascript , css , flash y VBScript.
Hay 3 tipos de XSS:
Stored XSS: Es el mas peligroso , esto se da cuando el input no esta sanitizado y ejecuta strings en la base de datos directamente
Reflected XSS: El payload es parte del request a la web , se suele dar cuando clickas en una url maliciosa.
DOM-based XSS: Es decir ejecutar código dentro del archivo dom que puede camiar la estructura de la base de datos. Hace de link entre xml y http.
Accede a la maquina y logra logearte ejecutando un payload. Vamos a ejecutar el típico payload de <script>alert(“Hello”)</script>:
R: ThereIsMoreXSSThanYouThink
Averigua la ip de la maquina , para ello nos serviremos del siguiente comando
<script>alert(window.location.hostname)</script>
Ya que el window.location.hostname usualmente el nombre de dominio , pero en este caso coincide con la ip
R: ReflectiveXss4TheWin
Ahora tenemos unos ejercicios de stored XSS , en este ejercicio nos piden que intentemos colar código html en el blog:
Simplemente hacemos un <h1> Hola </h1>
R: HTML_T4gs
Para este ejercicio nos piden que hagamos un alert que nos diga las cookies del sitio:
<script> alert(document.cookie)</script>
El document.cookie de javascript nos imprime las cookies del sitio directamente.
R: W3LL_D0N3_LVL2
Ahora tenemos que cambiar el titulo de la web por la de “im a hacker” usando js. Para ello utilizaremos el siguiente comando:
<script>document.querySelector('#thm-title').textContent = 'I am a hacker'</script>
Vamos a explicar un poco este comando:
Document.querySelector(‘#thm-title’) = Esta parte selecciona de la web un elemento con el id thm-title que en este caso es en el que esta ubicado el titulo de la web como vemos en la siguiente imagen:
.textContent = ‘I am a hacker’ 🡪 Esta parte coge el texto seleccionado y lo cambia en este caso por “I am a hacker”
R: websites_can_be_easily_defaced_with_xss
En este primer ejercicio nos piden que una vez nos registremos en la maquina miremos las cookies:
Hacemos click derecho en la web 🡪 inspect – storage
En la web de tryhackme nos dicen que todas las campos de la cookie están en texto plano , y que nuestra primera flag esta en base 64. Asi que cojemos el texto que aparece en el campo sessionid y lo pasamos por el cyberchef:
R: THM{good_old_base64_huh}
R: THM{heres_the_admin_flag}
En este ultimo ejercicio de este apartado pondremos junto lo que hemos aprendido. Primero miraremos el código de la cookie de cuando en nuestro perfil clickamos en refresh vim:
En la primera línea que dice replaceme meteremos nuestro código malicioso , y luego lo codificara mediante base64.
Una vez que hemos codificado nuestro código , cuando accedemos al formulario de feedback , nuestra cookie es descodificada y ejecutada. Asi que podremos hacer lo que queramos. Este proceso de desceliarizacion es hecho por el modulo pickle.load de Python.
Lo siguiente será descargar el archivo Python con el script proporcionado por tryhackme y modificarlo añadiendo la IP de nuestra vpn de tryhackme:
Una vez hecho esto lo ejecutamos:
Y nos aseguramos de copiar solo lo que esta entre comillas simples.
Luego una vez en el formulario de feedback vamos a cambiar el valor de encodedpayload por el que nos dio el script:
Recargamos :
Y ya tenemos nuestro reverse Shell:
R: 4a69a7ff9fd68
Para este apartado vamos a explotar una maquina utilizando exploit-db , vamos primero a acceder a ella:
Parece que tenemos una bookstore creada con php y mysql. Vamos a ir a exploitdb y buscar “unauthenticated bookstore rce (reverse comand execution)”
Nos vamos al segundo script , lo descargamos y vemos que tiene:
Si lo ejecutamos tal cual en consola con el argumento –h podemos ver la ayuda para ver como ejecutar el script:
Como podemos ver nos falta la url al final :
Asi que ya estaríamos dentro de la maquina , ahora solo nos faltaría saber el numero de caracteres que hay en el archivo /etc/passwd:
R: 1611
En esta ultima severidad vamos a analizar un archivo log para identificar al hacker:
Cual es la ip del atacante ? , pues como podemos ver seguramente sea la ip que ha intentado entrar 4 veces en 20 segundos con diferentes nombres de usuarios siendo rechazados por la app.
R: 49.99.13.16
En este caso se esta haciendo un ataque de fuerza bruta
R: brute force
Para ello simplemente vamos a escribir
Para este segundo ejercicio nos piden que cambiemos el valor del campo “usertype” por admin , lo hacemos , acutalizamos y
