Debe seleccionar solo un ejercicio a desarrollar

Transcripción

1 GUÍA DE ACTIVIDADES (PARA SUPLETORIO) Seguridad en aplicaciones web_ La siguiente guía contiene una serie de ejercicios que les ejercitan en el uso de herramientas y la aplicación de procedimientos cuando se trata de detectar y evaluar seguridad en aplicaciones web y sus incidencias. Esos ejercicios deben ser documentados desde el punto de vista objetivo de la ingeniería aplicada al hacking ético por lo que sus comentarios, desarrollos, caracterización de procedimientos y conclusiones deben ser de su autoría. Se pueden apoyar en la documentación web, libros, blogs, comunidades de software libre, repositorios, wikis, listas de correo, etc, pero siempre teniendo en cuenta en referenciar las fuentes de donde se apoyan. Cuando se le soliciten soluciones o propuestas para mitigar esas vulnerabilidades, antes que enunciar IDS o firewalls de manera general (que no es válido para estos ejercicios académicos inicialmente), debe proponer las soluciones a nivel de programación y configuración de funciones PHP, shells, scripts o configuración de directivas de apache, SQL o de diseño web propios de esas aplicaciones Se plantean nueve (9) ejercicios que si bien no cubren la totalidad de modalidades (inseguridad) o vulnerabilidades típicas a las que están expuestas las aplicaciones web (ya que son muchísimas) y que incluso no abarcan las del ranking del proyecto OWASP TOP 10, se ha pretendido abarcar las más comunes y frecuentes. Uds como especialistas en Seguridad informática, deben conocer la menos como se consolidan estos riesgos y cómo actúan. Debe seleccionar solo un ejercicio a desarrollar PROYECTOS A DESARROLLAR (SOLO DEBE SELECCIONAR UNO) PARA EL DESARROLLO (El que mejor apique o se le facilite): CONVENCIONES: Los textos que vea con los siguientes colores tienen el objetivo de: COLOR NEGRO: Documentación e indicaciones (procedimientos) de apoyo para esta guía y para el desarrollo de la actividad. COLOR AZUL: Procedimientos que debe hacer para lograr la instalación o el desarrollo de los ejercicios. COLOR ROJO: Los ejercicios que debe solucionar o desarrollar y que debe ubicar en el informe a presentar La documentación que justifique a las preguntas que se le hagan, debe estar asociada al ejercicio, ser objetiva y específica y no cargar documentación o definiciones generales. Deben ser análisis de su autoría o en otro caso tener referencias de autor. Las respuestas deben se concretas y no extensas. Para esta actividad si ve que es necesario capturar una pantalla para mostrar resultados (que no se puedan evidenciar por extracción de datos o informes por consola) lo puede hacer. Use siempre y cuando se puedan los informes por consola.

2 Ejercicios a desarrollar: EJERCICIO 1: COMMAND EXECUTION VULNERABILITY. La característica de esta vulnerabilidad es la de permitir ejecutar comandos de consola desde la web, pudiendo así ver, modificar y eliminar archivos y directorios del servidor donde se aloja la administración del sitio. El alcance de esta vulnerabilidad, está dado por los permisos que tenga un usuario legítimo logueado en el sitio. Así este usuario podrá ejecutar comandos Apache acorde a su nivel de administración. Los comandos usados suelen ser concatenados y son enviados a través de formularios del sitio web a través del campo input. Ejemplos de concatenación de comandos son entre otros: Con (barra sencilla) Con & (ampersand) Con (doble barra u operador OR ) Con && (doble ampersand) Con ; (punto y coma) hace que la salida del primero se convierta en la entrada del segundo hará que los dos (o más) comandos se ejecuten de manera simultánea. El segundo comando se ejecutará si el primero termina sin éxito. El segundo comando se ejecutará solo si el primero termina con éxito El segundo comando se ejecutará sin importar el resultado del primero. [root@server ~]# cmd1 cmd2 [root@server ~]# cmd1 & cmd2 [root@server ~]# cmd1 cmd2 [root@server ~]# cmd1 && cmd2 [root@server ~]# cmd1 ; cmd2 El procedimiento que se va a realizar para comprobar esta vulnerabilidad haciendo uso de DVWA es el siguiente: DVWA cuando se carga sin la opción de dvwa-nologin, (es decir sin ingresar credenciales de acceso), muestra las diferentes vulnerabilidades con las que se pude practicar: brute, exec, aqli, uplad, xss, csrf, fi. Para la vulnerabilidad que se está trabajando, (exec) (ejecución de comandos o command execution), se carga el directorio que muestra el archivo index.php. Para esta vulnerabilidad, dvwa la puede cargar en tres niveles de seguridad: (low, médium, high)

3 La estructura de estos niveles está dispuesta en el directorio source : Cada nivel está configurado con script en php así: (el del nivel bajo low)

4 Este script permite al visitante realizar ping a una IP (o host) a través de un formulario y a simple vista podría parecer bastante inocuo. Sin embargo, la información enviada a través del campo input del formulario no es tratada antes de llevar a cabo su ejecución por parte del servidor, por lo que un usuario malintencionado podría aprovecharse para ejecutar otros comandos diferentes usando la concatenación de comandos. En el nivel low ejecute: 1. ;pwd 2. ls-l / (cambie la IP por la del localhost de su máquina) && cat /proc/cpuinfo (cambie la IP por la del localhost de su máquina) 5. & cat /etc/password 6. ; ls l../ (Encuentre un directorio que tenga todos los permisos de usuario y cargue un archivo local, luego muestre que al directorio le fue cargado el archivo) cat /etc/passwd tee /tmp/passwd & dir 9. Adicione un Nuevo usuario administrador al sistema, posterior a ello evidencie el login de usuario creado en DVWA. 10. Ejecutar un comando remoto Para cada comando (ítem a realizar) ejecutado, muestre la captura y: Documente o explique lo encontrado. A nivel de seguridad, como podría explotarse lo encontrado. Cuando usa la IP, en un entorno real, cuál IP sería? El script que se implementa en el nivel de seguridad médium es el siguiente:

5 11. Explique que diferencia hay con el nivel de seguridad low y que funciones se implementan con sus objetivos. Que seguridad se incrementa. 12. Por qué esta medida sigue siendo ineficaz para el uso de ciertos comandos u operadores (demuéstrelo con un ejemplo) El script que se implementa en el nivel de seguridad high es el siguiente: 13. Explique qué diferencia hay con el nivel de seguridad low y médium y que funciones se implementan con sus objetivos. Que seguridad se incrementa. Ahora que ya pudo evidenciar como trabaja la ejecución de comandos en un formulario de un sitio web, se va a usar otra modalidad de este tipo de ataque: Webgoat es otra de las aplicaciones que nos permite hacer prácticas con este tipo de vulnerabilidad. (Command Injection) (es decir inyectando comandos). La misma suite webgat nos muestra todas las soluciones a cada ejercicio. Para este caso realice el ejercicio que se muestra en la solución suministrada por webgoat: Visualización: Descarga: Ingreso a webgoat (user: guest ; password : guest)

6 14. Evidencie la inyección del código 15. Explique qué tipo de código se inyectó y la función del mismo 16. Que afectación podría tener en el sitio web 17. Por qué se tiene que codificar el comando a inyectar. 18. Qué tipo de codificación se usó en el código a inyectar. 19. Que prevención Ud usaría o implementaría para este tipo de vulnerabilidad COMMAND EXECUTION. Explíquela en que consiste. EJERCICIO 2: CSFR (CROSS-SITE REQUEST FORGERY) Ó XSRF (le suelen llamar: Enlace hostil, ataque de un clic, captura de sesión) Falsificación de petición de sitios cruzados es otra de las vulnerabilidades típicas de las aplicaciones web que está enmarcada dentro del TOP 10 de OWASP. Es un tipo de exploit en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía. Esta vulnerabilidad se hace efectiva cuando un sitio web permite a un usuario autenticado realizar acciones consideradas como sensibles sin comprobar que realmente es el usuario quien las está invocando conscientemente. En su lugar, la aplicación simplemente comprueba que la petición proviene del navegador autorizado de dicho usuario. De este modo, y dado que los navegadores ejecutan simultáneamente código enviado por múltiples sitios web, existe el riesgo de que un sitio web (sin el conocimiento del usuario) envíe una solicitud a un segundo sitio web y éste interprete que la acción ha sido autorizada por el propio usuario. HERRAMIENTAS QUE SE VA A USAR: Firebug FoxyProxy OWASP CSRFTester index.php/file:csrfte ster-1.0.zip Es una extensión de Firefox creada y diseñada especialmente para desarrolladores y programadores web. Es un paquete de utilidades con el que se puede analizar (revisar velocidad de carga, estructura DOM), editar, monitorizar y depurar el código fuente, CSS, HTML y JavaScript de una página web de manera instantánea y online. Se usará para poder mostrar como es debido un ejemplo de este tipo de ataque, y que sean legibles las contraseñas de la víctima antes y después del mismo. Si va a usar Samurai Linux, este addons ya viene en Firefox. Herramienta de administración avanzada de proxies, que reemplaza totalmente la limitada funcionalidad de proxies nativa de los exploradores web Firefox, Chrome e Internet Explorer. Si realiza el ejercicio con Samurai Linux, esta viene ya por defecto disponible. En Kali Linux, también ya encuentra otros proxys que le sirven ya que lo que se requiere es que se puedan interceptar las conversaciones que se puedan genera la interactuar con el sitio web. Herramienta gratuita (distribuida bajo licencia LGPL) para desarrolladores con la que poder comprobar si los formularios web son vulnerables a este tipo de ataque. O puede usar WebScarab ( ). Viene también por defecto en las herramientas de Samurai Linux. La primera parte de este ejercicio se desarrollará haciendo uso de la aplicación para pruebas y ejercicios DVWA. Ingrese a DVWA identificándose con el usuario admin y la contraseña password (en un nivel de seguridad

7 low ) para acceder al sistema. Hasta ahí se ha conseguido loguear y autenticar correctamente y aún no es víctima de CSRF. El usuario ya es confiable para el sitio web mientras la cookie almacenada en su navegador web con la ID de inicio de sesión no caduque o el usuario cierre la sesión (con lo que ésta sería eliminada). (evidencie los siguientes procesos) 1. Se va a proceder a realizar un cambio de contraseña en ese formulario. Pero para ello, configure su navegador con FoxProxy para que capture todo el tráfico web en un puerto determinado, el mismo en que estará escuchando la aplicación OWASP CSRFTester ó WebScarab. En este caso el puerto es el 8008 OWASP CSRFTester va a capturar lo que se envíe por ese formulario 2. Para cada petición se muestran detalles como el método de envío empleado por el formulario (GET o POST) (identifique esas peticiones y los métodos de envío) y los parámetros transmitidos por URL. Modifique los parámetros para que la víctima realice un cambio de contraseña (por otra que desconozca) sin su consentimiento. 3. Genere el HTML realizará la petición de cambio de contraseña basada en la confianza que el sitio web tiene en el usuario autenticado en el sistema. 4. Utilice el método de forzar cambio de contraseña usando CSRFTester insertando, por ejemplo, una imagen. Obviamente esta imagen no será mostrada al usuario (puesto que el origen no es una imagen) y lo que producirá precisamente es que se genere la solicitud de cambio de contraseña 5. Evidencia la acción cunado al dar clic sobre la imagen o el link falseado a través del navegador web le ha redirigido a la página de cambio de contraseña y que no se muestra ningún mensaje referente al cambio de la misma. 6. Como la cookie de navegador ha caducado, al iniciar sesión con la contraseña antigua, generará error Login failed. 7. Use la herramienta Firebug para modificar el campo de contraseña y transformarla en un campo de tipo texto para que ésta sea legible. 8. Compruebe que, efectivamente, la contraseña fue cambiada llevando a cabo una autenticación en el sistema con el usuario admin y la nueva contraseña. Ahora que se ha dado cuenta y evidenciado como actúa esa vulnerabilidad, se va hacer uso de Webgoat para identificar algunas extensiones y alcances adicionales de CSRF, Para ello se va apoyar en el desarrollo y solución que ofrece webgoat para el ejercicio CSRF: Visualización del ejercicio online: Url para descarga del video: El encabezado de la lección dice: El objetivo es enviar un correo electrónico a un grupo de noticias que contiene una imagen cuya URL está apuntando a una petición maliciosa. Las condiciones es que la imagen tenga un tamaño de 1x1 pixeles y que la URL debe apuntar a la lección CSFR con un parámetro adicional Fondos de transferencia = Es un ejercicio que muestra como se puede robar una autenticación para transferir fondos no autorizados.

8 9. Evidencie la codificación UTF a enviar. Justifique por que se deben codificar y por qué con UTF Muestre cuál fue el mensaje que envió 11. Muestre la captura de la cabecera GET (con las opción de interceptar solicitudes) 12. Formule una solución justificada a este tipo de vulerabilidad. Finalmente creará un sitio web que le permita en un entorno real verificar lo aprendido en las plataformas de prueba. Para ello, proceda: Instale y administre su propio servidor CMS Joomla, entonces pude registrarse en un servicio gratuito que le ofrezca el CMS listo para que Ud cargue una web: Puede usar el que prefiera o si ya tiene uno que le permita realizar la práctica, lo puede hacer. Uno de ellos es: (registro y creación de cuenta en;): Una vez haya registrado su cuenta, le solicita crear un nombre de dominio. Para le ejercicio si Ud por ejemplo pertenece al grupo 5: entonces el nombre a crear es 5seguridadweb. Esta cuenta le servirá después para crear otros dominios o borrar el que creó después de realizada la práctica. Una vez creado, en el panel de administración del dominio, ubique el auto installer: para acceder al instalador del CMS Joomla.

9 Puede crear su sitio en cualquiera de los CMS que le da el servicio web gratuito, (el que desee, si quiere experimentar con otro tipo de CMS) como se muestra en la figura: Evidencie los siguientes procedimientos

10 13. Realice el login como administrador al sitio. Y ubíquese en el bloque de administración de usuarios (para crear un usuario nuevo). 14. Lance CSRFTester para capturar las peticiones del sitio 15. Genere el HTML que va a modificar las credenciales del usuario creado. Muestre los cambios en el código 16. Evidencie la falsificación de credenciales (acceso al sitio) y en el panel de administración de usuarios. EJERCICIO 3: FILE INCLUSION (LFI) & (RFI) LFI = Local File Inclusion RFI= Remote File Inclusion Esta vulnerabilidad es la que permite la ejecución de archivos locales o desde otros sitios (remotos) en el servidor web. La vulnerabilidad se presenta en páginas web PHP y se producen a causa de una mala programación haciendo uso de las funciones include, include_once, require, require_once y fopen (en el caso particular de RFI) con parámetros procedentes del usuario. 1. Explique concretamente a nivel de seguridad, que objetivo o que característica tienen estas funciones. De un ejemplo sencillo. Para demostrar inicialmente esta vulnerabilidad, se va cargar DVWA en el nivel de seguridad low. Ese nivel se implementa pr ejemplo este código altamente vulnerable 2. En el nivel médium solo permite el ataque LFI. Identifique el código de nivel médium y explique cuál es la diferencia para que permita solo este ataque. 3. En el nivel high no permite LFI ni RFI. Identifique el código y explique cuál es la diferencia para que no permita estos ataques. Con este código un usuario cualquiera podría cambiar en la URL de la página web el fichero a incluir en la página, pudiendo, por ejemplo, incluir en la página un fichero cualquiera del servidor local (LFI) y tener acceso al mismo o un script alojado en un servidor externo y que éste se ejecutase en el servidor web (RFI). Que es en realidad lo que vamos hacer en este ejercicio. Primero evidenciemos algunas intrusiones en DVWA: En primer lugar se llevará a cabo una sencilla comprobación para confirmar que la aplicación PHP es vulnerable a este tipo de ataque cambiando en la URL el fichero que se incluirá en la página web mediante la función include() remplazando el valor del parámetro page por una barra invertida (/). 4. En la barra URL de DVWA para esta vulnerabilidad, se carga:

11 Cámbielo por Evidencie y documente el resultado explicando siempre a nivel de seguridad porque eso es un riesgo 5. Inclusión de un fichero: Evidencie y documente el resultado explicando siempre a nivel de seguridad porque eso es un riesgo 6. Inclusión RFI: Evidencie y documente el resultado explicando siempre a nivel de seguridad porque eso es un riesgo Con RFI a cambio de incluir una dirección URL externa, se va a incluir un Shell script que se ejecute en el servidor web. Pare ello, vamos a bajar las siguientes Shell ya creadas del sitio (Hay muchos script Shell allí, solo vamos a usar dos. Queda para que después Ud ensaye y documente los demás) Descargue: R57shell y C99shell Descomprímalos y alójelos localmente en la máquina que está ejecutando DVWA o en un sitio externo accesible (puede ser otra máquina o una dirección web). Estos Shell script son detectados en ambientes Windows como virus. Por ello tenga cuidado con la descarga. Se supone que no hay problema ya que Ud está haciendo la práctica en un ambiente Linux. 7. En DVWA cargue el script Shell R57.php y evidencie el proceso: 8. Identifique de manera general que función haría ese script en el sitio cargado. 9. Identifique en el código del script, una función específica y explique su funcionamiento. 10. Ejecute esa función y evidencie el resultado en la página DVWA Otro script Shell es el C99shell. Este script tiene muchas características entre ellas: permite listar ficheros y sus atributos, cargar upload archivos, renombrar archivos, etc (como ven muy peligroso para un servidor web). Estos Shell script en PHP son herramientas tan completas como un webmin (es decir una interfaz completa para realizar muchas operaciones de forma administrativa y ordenada) Esta ruta fue la que usé para cargarlo en DVWA Y acá se muestra como dentro de las tantas funciones que tiene se cargó otro script php. es decir con upload permite cargar archivos al servidor web.

12 11. Evidencie el cargue del script y documente o explique una de las tantas funciones que tiene. Que incidencias a nivel de riesgo o seguridad tiene. 12. Use una de las funciones del Shell script y aplíquela, Evidencie lo realizado. (que no sea la de upload) 13. Finalmente cree un Shell script PHP (muestre su código), cuya función sea la de mostrar la versión del sistema operativo en el que está el servidor web y listar los archivos del directorio donde se ubica 14. Cargue el Shell script creado y muestre su ejecución. 15. Proponga y documente de manera concreta y clara que solución implementaría en un servidor web real para evitar tanto LFI y RFI EJERCICIO 4: MALICIOUS FILE EXECUTION (LFI) & (RFI) WEBGOAT Esta vulnerabilidad permite que se ejecuten códigos archivos maliciosos en diferentes formatos. (shells scrits) como hjava, css, perl, php, asp, etc; en el servidor de la aplicación. Esos códigos se ejecutan usando los formularios de la aplicación para el cargue o subida de archivos como los qu se encuentran a menudo en los foros de discusión basados en web y sitios de redes sociales En el ejercicio siguiente se hará uso de la aplicación webgoat, específicamente en la lección Malicious File Execution). Que básicamente trata de que mediante el uso del formulario le ermita subir supuestamente una imagen, pero en realidad se va a subir un archivo deliberadamente malicioso La lección se termina, es decir se cumple con el objetivo de cargarle al servidor un archivo malicios, cuando logre crear en su equipo un otro archivo llamado: / var / lib / tomcat6 / webapps / webgoat / MFE objetivo / guest.txt

13 Procedimiento: Vaya a la página de este proyecto: : fuzzdb es la mayor base de datos de código abierto de entradas maliciosas, nombres de recursos predecibles, cabeceras predecibles para los mensajes de respuesta del servidor y otros recursos como scripts web. Descargue la colección de scripts shell malware para realizar diferentes pruebas de vulnerabilidad: (tenga en cuenta que en ambientes Windows, estos scripts los antivirus los detectan como virus), por lo que debe hacer estos procedimientos en ambientes Linux Identifique brevemente que categorías de vulnerabilidad (y que significan cada una de ellas) y tipos de

14 archivos que encuentra allí y que advertencias hay al respecto de su uso. 2. Se va a usar el código malicioso dentro de la categoría de Badoors: cd.jsp. Debe describir que hace el código o que función tiene.

15 3. Cargue el código malicioso en el formulario. Con el debug frefox analice el código html generado 4. Evidencie el src o que se haya cargado el código como imagen: <img border="0" vspace="0" hspace="0" src="uploads/cmd.jsp"> Explique por qué se carga supuestamente una imagen pero se está cargando un.jsp (en donde está la vulnerabilidad) (que hacen esos archivos jsp) 5. Abra una nueva pestaña en el navegador y paste: (es la ruta de su webgoat o sea del sitio web víctima) adicionándole la ruta del código malicioso Explique lo que se muestra en esa nueva URL y el origen del formulario cargado. Evidencie lo que ha cargado 6. Regrese a la pantalla de la práctica DE WEBGOAT: copie este texto que en realidad es la ruta donde va a generar el archivo o subir e archivo al servidor local: /var/lib/tomcat6/webapps/webgoat/mfe_target/guest.txt Vaya al campo del formulario (punto 5) y cree el documento txt touch /var/lib/tomcat6/webapps/webgoat/mfe_target/guest.txt La lección se termina, es decir se cumple con el objetivo de cargarle al servidor un archivo malicios, cuando logre crear en su equipo un otro archivo llamado: / var / lib / tomcat6 / webapps / webgoat / MFE objetivo /

16 guest.txt. Finalmente evidencie que se ha generado el archivo 7. Proponga y caracterice una solución para esta vulnerabilidad. Para una nueva prueba de esa lección, es decir reiniciar la lección, solo debe borrar o renombrar el archivo cargado / var / lib / tomcat6 / webapps / webgoat / MFE objetivo / guest.txt y posterormente en webgoat reinicar sa lección. Finalmente realice los anteriores siete (7) items usando otro código malicioso de la colección que ha descargado. EJERCICIO 5: SQL INJECTION SQL Injection es una vulnerabilidad que permite a un atacante realizar consultas a una base de datos, se vale de un incorrecto filtrado de la información que se pasa a través de los campos y/o variables que usa un sitio web, es por lo general usada para extraer credenciales y realizar accesos ilegítimos, práctica un tanto neófita, ya que un fallo de este tipo puede llegar a permitir ejecución de comandos en el servidor, subida y lectura de archivos, o peor aún, la alteración total de los datos almacenados. Una vulnerabilidad de tipo SQL Injection puede ser explotada de diferentes formas. Una de ellas es manipulando cabeceras tanto a través del método GET como del método POST. La práctica más común es hacerlo a través del primero, sin embargo hacerlo a través del método POST puede llegar a devolver los mismos resultados. La intrusión se puede llevar a cabo al ejecutar un programa vulnerable, ya sea, en ordenadores de escritorio (es decir de foma local) o bien en sitios Web. El objetivo más común del código intruso es extraer toda la información posible de la base de datos, aunque tienen más usos como puede ser el iniciar sesión con la cuenta otro usuario, subir una shell al servidor, etc. Para este ejercicio, inicialmente vamos a trabajar con DVWA para evidenciar de forma práctica y sencilla como funciona este tipo de inyección de código SQL. Para ello, lance VWA en el nivel de seguridad low y sin login o credenciales de acceso. En el nivel de seguridad low el código fuente (en PHP) vulnerable es el que se muestra a continuación:

17 1. Explique en donde está la vulnerabilidad inmersa en el código: Una forma rápida y sencilla de ver si la página tiene una vulnerabilidad del tipo SQL Injection es introducir una comilla simple, en el caso de tener este tipo de vulnerabilidad va a devolver un error de SQL. Y así con muchos otros comandos de inyección. Para la siguiente lista de comandos de inyección: 1 OR 1=1-- 1 OR 1 = 1 OR = OR 1=1-- OR 0=0-- OR x = x EXEC XP_ AND 1=1 1 AND 1=(SELECT COUNT(*) FROM tablenames);-- 1 AND USER_NAME() = dbo UNI/**/ON SELECT ALL FROM WHERE OR 1=1/* 2. En el campo User ID typee 1 por ejemplo. Ejecute cada uno de los anteriores códigos y evidencie el resultado con el respectivo análisis de lo encontrado. 3. Inyecte el código necesario para: (evidencie el resultado) Mostrar la versión de la base de datos Mostrar el nombre de la base de datos que ad ministra o almacena los datos del formulario Mostrar el nombre de usuario Mostrar el nombre del host Mostrar el directorio de la base de datos Mostrar la lista de tablas de la base de datos Obtener la contraseña de cada uno de los usuarios de la base de datos. Seguramente estará encriptada en md5. Utilice algún servicio en línea o aplicación para desencriptarlas El nivel de seguridad médium de DVWA implementa el siguiente código PHP

18 4. Identifique la diferencia con el código en PHP del nivel low y justifíquela. 5. Ejecute en ese nivel los códigos de inyección del ítem 1 y 3. Indique cuáles se permitieron ejecutar y cuáles no. Evidencie lo arrojado luego de la inyección del código en caso de obtener resultados diferentes. Documente por que la inyección tuvo éxito y por qué no. 6. Muestre el código PHP del nivel de seguridad high y analice las diferencias con los demás niveles en cuanto a funciones y directivas y el papel que juegan en aspectos de vulnerabilidades. 7. Caracterice el tipo de directivas PHP son usadas para evitar los ataques SQL Injection. Finalmente describa los aspectos a considerar básicos para proteger aplicaciones de un SQL Injection EJERCICIO 6: SQL INJECTION (BLIND) Este tipo de ataque es similar al SQL Injection. Para esta práctica haremos uso de Mutillidae. Procedimiento: El siguiente sitio web está diseñado deliberadamente vulnerable con fines académicos y de formación en el área de seguridad. Aplicaciones web diseñadas específicamente para enseñar las nociones básicas sobre seguridad web, cubriendo XSS, CSRF, RFI y LFI, fuerza bruta en autenticación, path traversal, ejecución de comandos e inyección SQL: Mutillidae ( Mutillidae viene instalada o disponible dentro de las aplicaciones de SAMURAI LINUX, Viene con la versión 1.3. Pero para poder realizar la práctica deberá actualizarla a la versión Aunque si logra evidenciar el SQL Injection Blind con la versión 1.3 estaría correcto.

19 Puede realizar el proceso de actualización a la versión solamente descargando el paquete y reemplazándolo en el directorio donde apache carga los paths para los servicios web. O si o prefiere puede realizar la instalación en un entorno Microsoft Windows. Para ello, debe descargar XAMPP en su versión actualizada: El paquete mutillidae lo descomprima dentro de la carpeta /var/htdocs/mutillidae (en Windows). Al cargar la aplicación le solicitará que actualice la base de datos de la aplicación. Finalmente la aplicación cargará en la versión actualizada.

20 Dentro de las lecciones que trae Mutillidae, (ingrese sin registro ni login de usuario en la aplicación) en la sección A1- SQL Injection, encuentra otra Blind SQL vía Timing. Específicamente va a usar el de formularios para login. En el formulario de User Lookup en el campo de name inyecte una comilla simple o un código que le permita identificar el SELECT de usuario y o contraseña (pruebe con: or 1=1 -- ) 1. Identifique las salidas obtenidas o si es el caso enfóquese en el campo SELECT (lo arrojado). 2. A través de este tipo de inyección, (A1- SQL Injection, encuentra otra Blind SQL vía Timing. Específicamente va a usar el de formularios para login.) consiga loguearse como administrador en mutillidae. Evidencie el proceso. O en el Home de Mutillidae, de clic en login/register como si fuera a registrarse dentro de la aplicación (verá en la parte superior del menú de la aplicación no register ). En el campo name inyecte una comilla simple o or 1=1 -- y evidencie o justifique el resultado. 3. Consiga el login a multillidade de algún usuario ya creado que no sea administrador (para ello descubra primero usuarios para saber que cuentas existen). El login a multilidae hágalo inyectando código o modificando parámetros como: <input type= input size= 100 maxlenght= 500 name= password > 4. Pruebe la inyección de este código para la categoría SQL Injection Blind en Mutillidae y justifique lo encontrado. Use alguno de estos códigos o alguno que le pueda arrojar la vulnerabilidad. Or 1=1 haviing 1=1 OR ''x''=''x

21 5. Analizando los desarrollos anteriores, documente en que cosiste el ataque SQL Injection Blind. Que diferencias hay con un ataque SQL Injection y muestre en que ejercicio encontró esa diferencia. Que significa que a pesar de estar presente la vulnerabilidad SQL Injection Blind, al inyectar ciertos códigos no se arrojen mensajes de error. 6. Muestre una inyección de código SQL en Mutillidae que arroje mensajes correctos de validación. 7. Caracterice y justifique una solución para este tipo de inyección. 8. Escoja una de estas tres prácticas adicionales de SQL Injection que implementa Mutillidae: SQLi Extra Data SQLi Insert Injection SQLMAP Practice Evidencie la práctica, muestre el proceso realizado y caracterícela, documentando lo encontrado y las incidencias que esta vulnerabilidad tendría en un entorno real. EJERCICIO 7: FILE UPLOAD La vulnerabilidad que se tratará en esta práctica, es evidente cuando en los sitios web se presentan formularos para el cargue o subida de archivos (de cualquier tipo ya sea multimedia, imágenes, texto, etc) (muy típico en plataformas educativas y redes sociales) pudiendo llegar a convertirse en una puerta abierta a todo el sistema donde esté alojada la página web. Solo que aprovechando este recurso del cargue de archivos, un atacante podría subir código malicioso, como por ejemplo una shell PHP, alojar archivos que se auto ejecuten en el servidor o inundar el servidor con tamaño de archivos y peticiones gigantes, modificando parámetros que restringen el cargue de archivos como: tamaño, dimensiones, extensiones entre otros.

22 Inicialmente evidenciaremos el comportamiento de esta vulnerabilidad haciendo uso de DVWA en su nivel low cuyo el código fuente vulnerable es el que se muestra a continuación: 1. Suba una imagen de prueba.jpg y verifique el cargue de la misma y el resultado (mensaje que arroja la aplicación). Identifique que vulnerabilidad encuentra en el código. Cree esta Shell escrita en PHP que ejecutará comandos en el sistema a través de la función system(): 2. Suba ese shell script (nómbrelo como php). Evidencie el proceso, la ruta donde lo cargó. Luego en otra pestaña del navegador realice consultas al sistema indicando el objetivo de la consulta realizada. El nivel médium de seguridad de DVWA ya no permitirá subir archivos que no sean imágenes y con ciertas restricciones. Sin embargo se va a subir el mismo Shell creado anteriormente usando la extensión Tamper Data de Firefox ( Cuando suba nuevamente la Shell en el formulario que solo es para cargue de imágenes.jpg, le solicitará sobrescribir o modificar el archivo. 3. Antes de enviar el formulario debe modificar la petición HTTP POST que será enviada al servidor:

23 Como los ficheros PHP no son aceptados por el script de carga de imágenes, se modifica el encabezado Content-Type con el tipo de fichero aceptado por el servidor, esto es, se sustituirá application/xphp por image/jpeg: Que hacen esos encabezados en el código PHP?. Que otros tipos de peticiones diferentes a POST podrían utilizarse 4. Realice el cambio y cargue la Shell evidenciando el mensaje obtenido. Que función hace Tamper Data en el proceso. Con que otra aplicación podría modificar los encabezados Content-Type. 5. Luego en otra pestaña del navegador realice consultas al sistema indicando el objetivo de la consulta. OWASP Mutillidae II permite evidenciar este tipo de vulnerabilidad, implementado shells script maliciosos ya creados y que muestran el poder y alcance que tiene esta vulnerabilidad. Selecciones un Shell script malicioso de los que tiene Mutillidae en el menú de Owasp 2007

24 6. Explique el código PHP que lo implementa y el tipo de acción que ejecuta el Shell. O si prefiere seleccione alguno del sitio : O en su defecto diseñe uno. 7. Cargue el Shell creado al servidor (Upload en Mutillidae) y evidencie el proceso. Identifique que respuestas da el servidor cuando se carga el archivo 8. Ejecute alguna función del Shell script escogido y evidencie el resultado de la vulnerabilidad perpetrada 9. Formule y caracterice una solución a este tipo de vulnerabilidad EJERCICIO 8: XSS REFLECTED La vulnerabilidad que se tratará en esta práctica, compromete la seguridad del usuario y no la del servidor. Procedimiento: Se hará uso de las configuraciones de DVWA para la práctica de XSS y de Webgoat 1. Caracterice la vulnerabilidad. Apoyado en las configuraciones de los niveles de seguridad de DVWA (low, médium, high), identifique las configuraciones PHP de esos niveles para Cross-site scripting (XSS). Identifique en cada nivel en que parte del código PHP está reflejada la vulnerabilidad. Para ejemplificar este tipo de vulnerabilidad DVWA presenta una página en la que se solicita un nombre a través de un formulario. Una vez enviado, el script muestra la cadena de texto Hello nombre_enviado. El siguiente script al ser envido desde el formulario arrojará para la salida de usuario el mensaje ubicado dentro de Código 1 <script>alert("pagina vulnerable por XSS")</script> También introduciendo código HTML se puede mostrar una imagen en lugar de una cadena de texto como sería de esperar: Código 2 <img src= de la imagen.jpg alt="descripcion" /> Muchos delincuentes informáticos, hackers o simplemente personas dedicadas al robo o manipulación de datos suelen usar imágenes alusivas a su trabajo de hackeo (que inundan sitios o que las usan para mostrar su intrusión), Imágenes típicas como la de anonymous entre otros son:

25 Es obvio que el alojamiento de esas imágenes estará de forma anónima o en servicios que no requieran un registro o identificación de acceso. El delincuente informático lo hace para que no sea rastreado. Por ejemplo revise esta URL: 2. Diseñe una imagen alusiva a una intrusión o hackeo (De su autoría y al gusto suyo). Para ello, asuma que Ud es un delincuente informático y quiere mostrar en imagen su venganza. (Esto se hace con fines educativos, y en su ejercicio profesional nunca deje de lado su cultura ética de hacking) Alójela en un sitio que no requiera registro de acceso o que no requiera credenciales de acceso para el cargue de la imagen, Recuerde que esto para un delincuente informático no sería viable. Uso uno diferente a este, que suele ser muy usado pero permite rastreo: O se podría mostrar al usuario un enlace a un sitio externo Código 3 <a href=" NACIONAL ABIERTA Y A DISTANCIAUNAD</a> 3. En Webgoat, ejecute los anteriores códigos (1,2 y 3) y evidencie el resultado. El código que le carga la imagen al sitio vulnerado por XSS debe contener la imagen que ha diseñado. 4. El desarrollo de la lección que trae Webgoat para un básico Reflected XSS Attacks la puede descargar o visualizar en: Visualizar: Descarga: Desarrolle la lección, evidencie el proceso 5. Justifique la estructura del código inyectado y del por qué su codificación 6. Realice una práctica de XSS de la que le ofrece Mutillidae en la sección A3. Evidencie el proceso y caracterice la vulnerabilidad. 7. Formule y caracterice una solución para esta vulnerabilidad

26 EJERCICIO 9: XSS STORED Al igual que en el caso de XSS reflejcted, esta vulnerabilidad compromete la seguridad del usuario y no la del servidor. XSS stored, también llamado XSS directo o persistente, consiste en embeber código HTML o Javascript en una aplicación web pudiendo llegar incluso a modificar la propia interfaz de un sitio web (defacement). 1. Justifique porque se le llama persistente y de un ejemplo de cómo actuaría en un sitio web (caracterice la vulnerabilidad) Procedimiento: Esta vulnerabilidad suele aplicarse en logs, por ejemplo en formularios que contengan dos campos usados por ejemplo para enviar comentarios, solicitudes, libros de visitas entre otros.: Uno para introducir el nombre y otro para escribir le mensaje o comentario. Debe usar las tres aplicaciones que le ofrecen lecciones de XSS Stores (Mutillidae, DVWA y Webgoat). En la que pueda evidenciar o realizar lo siguiente: 2. Identifíquese con su nombre e introduzca un comentario en el campo destinado para ello (Deben ser los nombres de los 5 integrantes del grupo). Evidencie que eso se guardó en la base de datos (así funciona XSS stored) o muestre la salida de los comentarios cada vez que cargue la página nuevamente. 3. Compruebe en la aplicación (práctica o ejercicio) si es vulnerable a XSS. Para ello puede introducir el siguiente tag HTML en el campo del comentario para que se lance una ventana de alerta Javascript: De tal manera que quede guardado ese comentario en la BD y cada vez que se cargue de la página, se visualice esa ventana emergente de alerta. <script> alert("es vulnerable a XSS Stored")</script> Desde Mutillidae:

27 4. En el campo del mensaje, escriba Tags o etiquetas HTML que hagan un Deface al sitio. Justifique el código escrito y lo que significa un Deface. Tags HTMl pueden ser: <div> <table> <br> (Hay muchos que pueden darle formato auna página web y por ende destruirle su diseño) 5. En el campo del autor del mensaje, escriba el siguiente código <SCRIPT language="javascript">window.location=" Evidencie que en la base de datos se ha escrito el código. Justifique lo realizado o caracterice el resultado. 6. Realice la práctica (laboratorio) que implementa Webgoat: Stored XSS Attacks Visualización: Descarga: Evidencie el proceso y la explicación de los pasos realizados y caracterice lo realizado, explique el objetivo de la práctica y los resultaos obtenidos. 7. Realice la práctica (laboratorio) que implementa Webgoat: Stored XSS Attacks Stage1 Visualización: Descarga: Evidencie el proceso y la explicación de los pasos realizados y caracterice lo realizado, explique el objetivo de la práctica y los resultaos obtenidos. 8. Realice la práctica (laboratorio) que implementa Webgoat: Stored XSS Revisited Visualización: Descarga: Evidencie el proceso y la explicación de los pasos realizados y caracterice lo realizado, explique el objetivo de la práctica y los resultaos obtenidos. 9. Realice la práctica (laboratorio) que implementa Webgoat: Block Stored XSS using Output Encoding Visualización: Descarga: Evidencie el proceso y la explicación de los pasos realizados y caracterice lo realizado, explique el objetivo de

28 la práctica y los resultaos obtenidos. 10. Formule y caracterice una solución para estas vulnerabilidades XSS Stored. Recomendaciones Recuerde que el grupo debe hacer la selección del ejercicio a realizar (uno solo) Para ello debe diligenciar el documento compartido e informar en el foro de construcción de la actividad, el ejercicio a realizar : Leer cuidadosamente las indicaciones registradas en los foros (noticias del curso, foro general, foro del trabajo colaborativo), por parte del director, para el adecuado desarrollo de los diferentes ejercicios propuestos Consultar con su tutor, cada vez que lo requiera, para aclarar dudas e inquietudes que se presenten en el proceso. Avanzar con el desarrollo de las actividades solicitadas en cada uno de los momentos de acuerdo a las fechas registradas en la agenda. Asistir a las sesiones web conference síncronas acorde a la agenda de acompañamiento plasmada en el aula Cordialmente Ing. (msc). Carlos Alberto Amaya Tarazona Director aula Lo importante no es el tiempo, lo importante es lo que se hace con él