Práctica con WebGoat: HTTP Splitting, DoS, Ma-licious Execution e Injection Flaws

6
Por: Héctor Garduño Real Máster en Dirección e Ingeniería de Sitios Web Seguridad en la web 03 de mayo de 2015 Página 1 de 6 Práctica con WebGoat: HTTP Splitting, DoS, Mali- cious Execution e Injection Flaws Introducción WebGoat el servidor tipo HoneyPot pero con fines educativos resulta bastante útil para realmente entender cómo funcionan los ataques en la web. Para esta práctica, la cual inicialmente me había centrado en la Lección Injection Flaws, se me complicaron un par de ejercicios, le que me obligo a ver los videos en dos ocaciones, por esa razón opte por realizar algunas lecciones más. A continuación detallo cada una de ellas. 1. HTTP Splitting Para resolver esta simplelección de la cual no conocía, comencé a investigar qué eran los caracteres %0d y %0a, y pronto di que tienen relación con las cabeceras HTTP (de ahí su nombre), ya que cada lí- nea o mensaje de la cabecera HTTP se separa con /r/n, es decir, es el delimitador para indicar una nueva línea, de- pendiendo la codifica- ción/lenguaje a usar serán como se tendrán que escribir el retorno y salto de línea, que para este caso es %0d y %0a respectivamente. Al hacer esto en una web, uno de los posibles ataques que se pueden hacer es se forzá al navegador a entregar solo una parte del mensaje (split o separar), con ello el servidor solo responderá con un mensaje 200, que significa que la petición del cliente fue correcta. Así pues, para resolver éste ejercicio solo bastó con escribir %0d%0a%0d%0a<h1>hec- tor</h1>. Esta es solo es una prueba básica, pero las posibilidades van más allá, y es posible realizar diversos tipos de ataques al sobrescribir las cabeceras. Con el ejercicio de la práctica aparentemente no hay problema en ello, sin embargo si un atacante lo hace en una red donde hay un proxy y además sobres- cribe la cabecera para cargar un script malicioso, lo que sucederá es que el proxy cacheará la página para luego producir un ataque de cache poisingel cual haría que el resto de los usuarios que solici- tarán dicha página, el proxy al tenerla en caché la entregaría, con lo cual los usuarios cargarían un script malicioso.

Transcript of Práctica con WebGoat: HTTP Splitting, DoS, Ma-licious Execution e Injection Flaws

Page 1: Práctica con WebGoat: HTTP Splitting, DoS, Ma-licious Execution e Injection Flaws

Por: Héctor Garduño Real

Máster en Dirección e Ingeniería de Sitios Web Seguridad en la web

03 de mayo de 2015 Página 1 de 6

Práctica con WebGoat: HTTP Splitting, DoS, Mali-

cious Execution e Injection Flaws

Introducción

WebGoat el servidor tipo HoneyPot pero con fines educativos resulta bastante útil para realmente

entender cómo funcionan los ataques en la web. Para esta práctica, la cual inicialmente me había

centrado en la Lección “Injection Flaws”, se me complicaron un par de ejercicios, le que me obligo a

ver los videos en dos ocaciones, por esa razón opte por realizar algunas lecciones más. A continuación

detallo cada una de ellas.

1. HTTP Splitting

Para resolver esta “simple”

lección de la cual no conocía,

comencé a investigar qué eran

los caracteres %0d y %0a, y

pronto di que tienen relación

con las cabeceras HTTP (de

ahí su nombre), ya que cada lí-

nea o mensaje de la cabecera

HTTP se separa con /r/n, es

decir, es el delimitador para

indicar una nueva línea, de-

pendiendo la codifica-

ción/lenguaje a usar serán

como se tendrán que escribir

el retorno y salto de línea, que

para este caso es %0d y %0a respectivamente. Al hacer esto en una web, uno de los posibles ataques

que se pueden hacer es se forzá al navegador a entregar solo una parte del mensaje (split o separar),

con ello el servidor solo responderá con un mensaje 200, que significa que la petición del cliente fue

correcta. Así pues, para resolver éste ejercicio solo bastó con escribir %0d%0a%0d%0a<h1>hec-

tor</h1>.

Esta es solo es una prueba básica, pero las posibilidades van más allá, y es posible realizar diversos

tipos de ataques al sobrescribir las cabeceras. Con el ejercicio de la práctica aparentemente no hay

problema en ello, sin embargo si un atacante lo hace en una red donde hay un proxy y además sobres-

cribe la cabecera para cargar un script malicioso, lo que sucederá es que el proxy cacheará la página

para luego producir un ataque de “cache poising” el cual haría que el resto de los usuarios que solici-

tarán dicha página, el proxy al tenerla en caché la entregaría, con lo cual los usuarios cargarían un

script malicioso.

Page 2: Práctica con WebGoat: HTTP Splitting, DoS, Ma-licious Execution e Injection Flaws

Por: Héctor Garduño Real

Máster en Dirección e Ingeniería de Sitios Web Seguridad en la web

03 de mayo de 2015 Página 2 de 6

La siguiente fase de esta práctica

pide hacer el splitting, es decir, se-

parar con los caracteres /r/n para

escribir una nueva cabecera mani-

pulada, en este caso se resolvió

con %0d%0d%0a%0a

HTTP/1.1%20304%20Re-

ply%0d%0a que quitando los ca-

racteres codificados (/r, /n, espa-

cio) quedaría un HTTP/1.1 304

Reply.

2. Denial of Service (DoS)

Este ataque resultó bastante

sencillo, ya que simple-

mente hubo que inyectar

primero código SQL para

obtener la lista de usuarios,

posteriormente se hicieron

los inicios de sesión nece-

sarios para lograr el ataque

DoS. La primera instruc-

ción introducida fue ' or

'1'='1 y posteriormente se

emplearon los datos de los

usuarios legítimos para ini-

ciar múltiples sesiones.

3. Malicious File Execution

También fue una práctica muy fácil de resolver, ya que cualquier desarrollador web con un poco de

experiencia debe conocer este tipo de amenazas, en lo personal, cuando en proyectos hago carga de

archivos verifico el MIMEType con el fin de evitar la ejecución de código no deseado. Esta práctica

se resolvía tan solo creando un archivo que simulara un ejecutable (exe, php, asp, etc.).

Page 3: Práctica con WebGoat: HTTP Splitting, DoS, Ma-licious Execution e Injection Flaws

Por: Héctor Garduño Real

Máster en Dirección e Ingeniería de Sitios Web Seguridad en la web

03 de mayo de 2015 Página 3 de 6

4. Injection Flaws

La principal de las amenazas del top ten de OSWAP son precisamente las inyecciones en sus diferen-

tes variantes, por lo que está Lección abarca varios ejercicios de los cuales algunos están restringidos

para la versión de desarrolladores de WebGoat, por lo que no fueron hechos. Adicionalmente también

fue requerida una herramienta para capturar y reenviar las peticiones HTTP, para lo cual se empleó

Tamper Data.

El primer ejercicio, bas-

tante simple, consistió

en reescribir y reenviar

las cabeceras HTTP,

para introducir la inyec-

ción SQL, ello debido a

que la página no contaba

con una caja de texto,

sino con un option select

desde el cual no se puede

escribir.

El segundo ejercicio consistía en loguearse como administrador, sin embargo al intentar varias formas

de inyección SQL pero al no lograrlo opte por pedir pistas (hits) y rápidamente entendí que debía

crear nuevas líneas, por lo que la solución era usar %0d y %0a. La solución fue ingresar ad-

min%0d%0a.

El siguiente ejercicio también me costó varias pruebas, y requerí de las pistas para ayudarme a resol-

verlo pues nunca había hecho inyección para XPath, de hecho no sabía que eso se podía, después de

investigar en internet un poco di con la solución que era ' or 1=1 or '1'='1.

Page 4: Práctica con WebGoat: HTTP Splitting, DoS, Ma-licious Execution e Injection Flaws

Por: Héctor Garduño Real

Máster en Dirección e Ingeniería de Sitios Web Seguridad en la web

03 de mayo de 2015 Página 4 de 6

El siguiente ejercicio fue una sencilla inyec-

ción de SQL, cuya respuesta era smit' or

'1'='1.

Sin embargo, el siguiente ejercicio, aunque era

bastante simple también, comencé a desespe-

rarme porque no quedaba, hasta que me di

cuenta que el campo de password tenía un

maxlength que limitaba los caracteres, por lo

que la solución fue simple, reescribiendo y re-

enviando las cabeceras HTTP usando como

password smit' or '1'='1.

La fase 2 de este ejercicio no se pudo

realizar debido a su restricción para

desarrolladores.

El siguiente ejercicio fue el que no pude resolver, por lo que tuve que recurrir a ver la respuesta, y lo

que sucedia es que no era difícil, sino que el primer paso era iniciar sesión con un usuario normal y

posteriormente ejecutar la inyección para ver la información del administrador, mientras que todos

mis intentos se inyección los hice para intentar iniciar sesión. Analizandolo después, pensé, ¡tiene

lógica! este formulario es para iniciar sesión, no para mostrar datos consultados.

Así pues, una vez que se iniciaba sesión bastaba con ordenar los cantidades de salarios, ya que solo

se muestra un resultado, entoces el que mostrará será el más alto, es decir el del jefe.

Page 5: Práctica con WebGoat: HTTP Splitting, DoS, Ma-licious Execution e Injection Flaws

Por: Héctor Garduño Real

Máster en Dirección e Ingeniería de Sitios Web Seguridad en la web

03 de mayo de 2015 Página 5 de 6

La fase 4 también estaba restringida a desarrolladores por lo que no se resolvió

Finalmente las siguientes in-

yecciones resultaron relati-

vamente fáciles, pues impli-

caban ejecutar dos senten-

cias SQL, tanto para modifi-

car datos como para insertar,

por ejemplo el siguiente im-

plicó hacer un simple update

para cambiar el salario de

jsmith, lo cual implicaba se-

parar la nueva sentencia

usando punto y coma.

jsmith'; update salaries set salary=5 where userid='jsmith

Posteriormente se necesitó inserter un

nuevo registro, y de igual manera debía

separarse la nueva instrucción con punto

y coma, sin embargo el primer intento

dio error porque estaban mal cerradas las

comillas, por lo que se añadieron al final

dos guiones, los cuales indican que se fi-

nalice la sentencia. La instrucción em-

pleada fue jsmith'; insert into salaries

values('hector',999999)--

Page 6: Práctica con WebGoat: HTTP Splitting, DoS, Ma-licious Execution e Injection Flaws

Por: Héctor Garduño Real

Máster en Dirección e Ingeniería de Sitios Web Seguridad en la web

03 de mayo de 2015 Página 6 de 6

Los dos ultimos ejercicios re-

sultaron también fáciles, sin

embargo el último en el cual

se empleaba un lanzador, me

resultó algo confuso, pensé

que no debía usar triggers,

pero después de un par de fa-

llos intente con el trigger, y

ello fue correcto, y la adver-

tencia que se mostraba era

solo para indicar que

WebGoat no usa triggers en su

SGBD.

Así pues las sentencias y resultados para cada caso son los siguientes

101';update employee set salary=999999 where userid=101

101’;CREATE TRIGGER

myBackDoor BEFORE IN-

SERT ON employee FOR

EACH ROW BEGIN UPDATE

employee SET email =

'[email protected]' WHERE

userid = NEW.userid