Seminario de SEGURIDAD WEB. Pedro Villena Fernández

Transcripción

1 Seminario de SEGURIDAD WEB Pedro Villena Fernández

2 Algunas cosas antes de empezar... Este seminario NO tiene la intención de piratear otras webs. Los ataques que aprenderemos NO deben probarse en aplicaciones webs que no son nuestras. La única finalidad es aprender los fallos que se pueden dar para evitarlos.

3 INDICE 1.- Introducción Fingerprinting y exploits

4 Introduccion Qué es necesario para que un sitio sea seguro?

5 Introducción 1.-Confidencialidad. Los datos solo podrán ser modificados por aquellas personas que tengan permiso para hacerlo. 2.-Integridad. Los datos se deben mantener sin modificar, como se dejaron en su origen.

6 Introducción 3.-Disponibilidad. Los datos deben estar disponibles y accesibles cuando se requiera el acceso a ellos. 4.-Autenticidad. Los datos deben ser de la persona que los creo y no ser modificados. Va ligado a la integridad.

7 Introducción Por qué se atacan webs?

8 Introducción Robar información sensible

9 Introducción Defacement (fama)

10 Introducción Implantar Malware: sirven para infectar a victimas que visitan la web y crear botnets (redes zombies)

11 Introduccion Quién protege ante estos ataques?

12 Introducción OWASP

13 Introducción Open Web Application Application Security Project Sin fines de lucro, organización de voluntarios Promueve el desarrollo de software seguro Orientada a la prestación de servicios orientados a la Web Se centra principalmente en el "back-end" mas que en cuestiones de diseño web Un foro abierto para el debate Un recurso gratuito para cualquier equipo de desarrollo de software

14 Introducción Open Web Application Application Security Project Materiales de Educación OWASP Top 10 Guía de Desarrollo OWASP Guía de Testing OWASP Guía OWASP para aplicaciones Web Seguras Muchos mas Software WebGoat WebScarab ESAPI

15 Introducción OWASP TOP 10:

16 INDICE 1.- Introducción Fingerprinting y exploits

17 Top de fallos registrados según OWASP

18 que veremos: SQL Injection (y Blind SQL Injection) Cross-Site Scripting (XSS) Cross Site Request Forgeries (CSRF) Command Execution File inclusion File upload Brute Force

19 Para hacer las pruebas utilizaremos DVWA

20 DVWA (Damn Vulnerable Web App) es un sitio web que tiene las principales vulnerabilidades. Tiene 3 niveles de seguridad, desde LOW (lo que nunca se debe hacer), hasta HIGHT (la implementación segura del código) Existen otras alternativas como por ejemplo Webgoat (de OWASP) y Web for Pentester

21 SQL INJECTION

22 Se produce cuando se ejecutan consultas de SQL con datos recibidos del usuario, y estos no han sido procesados. sql_query= SELECT * FROM users WHERE username = '". $usuario. "' AND userpass = '". $password. "'"; El objetivo principal es obtener todos los datos posibles de la BDD, como por ejemplo contraseñas de los usuarios; o saltarse condicionales.

23 Un truco que se suele utilizar, siempre que no sea Blind SQL Injection (a ciegas), es poner el símbolo ' o en los campos, y ver si devuelve error. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''''' at line 1 Si esto sucediera, es casi seguro que hay un SQL Injection en esa consulta

24 Cosas que se suelen probar siempre: 1' OR 1=1-1' OR '1' = '1 ' '' ') or ('a'='a ") or ("a"="a or a=a-admin'-' or 0=0 -" or 0=0 -or 0=0 -' or 'x'='x " or "x"="x ') or ('x'='x SELECT * FROM users WHERE username = 'admin' -- AND userpass = 'password'

25 Con lo que obtenemos:

26 Cómo solucionar este problema? Si esperamos un entero, hacer casting hacia ese tipo. Utilizando funciones como addclashes (de php) Utilizando funciones del framework que utilicemos (los ORM también implementan la seguridad para evitar esto)

27 XSS

28 El XSS (Cross-Site Scripting) consiste en ejecutar código HTML o Javascript en la página. buscar.php?d=busqueda buscar.php?d=<script type="text/javascript">scriptaqui();</script> Desde hace poco tiempo los navegadores interceptan muchos estos ataques: Internet Explorer, Chrome o Firefox mediante No-Script.

29 Suelen existir dos tipos de XSS: XSS persistente: se guardan en BDD o archivos, como por ejemplo en un nombre de usuario o mensaje de un foro. XSS reflejado: el XSS suele estar incrustado en la URL, y normalmente si el usuario entra directamente se saltaría el XSS.

30 Qué pasa si caemos en un XSS? Robo de sesión Phising Escaneo de puertos de intranet Fallos de navegador

31 Explotando un XSS

32 Cómo solucionar este problema? Eliminando todas las etiquetas html, con funciones como strip_tags Parseando los elementos html, y pasandolos a códigos no ejecutables (con htmlentities)

33 CSRF

34 Muchos sitios webs realizan acciones mediante llamadas a URL. Aquí es donde se podría ejecutar un CSRF (Cross-Site Request Forgery) csrf/?password_new=tales&password_conf=tales&change=change Si enviamos esta URL a una víctima y hace clic en ese enlace, estará cambiando la contraseña sin ser consciente de ello.

35 Para poder realizar este ataque, tenemos que comprobar que los parámetros se puedan recibir por medio de GET. En un principio se pueden enviar por POST, pero quizás también se acepten por GET.

36 Cómo solucionar este problema? Insertando un token en el formulario, para que vaya cambiando y no sea siempre el mismo. Aceptando parámetros solo por post.

37 COMMAND EXECUTION

38 Hay veces que las páginas web tienen que acceder a comandos del sistema, y necesitan obtener algún parámetro por parte del usuario: <?php $host=$_get['host']; system("ping ".$host);?> En el ejemplo anterior vamos a hacer un ping a una IP, pero como no se ha parseado correctamente la llamada, podemos poner un && ls y nos devolverá el directorio de ficheros.

39 Con lo que obtenemos:

40 Algunas de las funciones que más posibilidades tiene de sufrir Command execution son: exec() passthru() shell_exec() system() Habría que utilizar operadores como & o para lanzar un segundo comando.

41 Cómo solucionar este problema? Validando los datos. Limitando los caracteres Restringir el uso de operadores &,, etc

42 FILE INCLUSION

43 Este ataque se da cuando incluimos ficheros ejecutables directamente por URL o por POST. Se pueden distinguir dos tipos: LFI (Local File Inclusion): Incluyendo ficheros del propio servidor. RFI (Remote File Inclusion): Incluyendo ficheros de otro servidor.

44 Cuando se realiza LFI, es normal coger archivos de configuración o el archivo htpasswd del sistema (si es UNIX).

45 Cuando se realiza RFI, lo normal es incluir alguna web shell como la C99, para así ganar control sobre el sistema.

46 Cómo solucionar este problema? Comprobando que el archivo sea local y exista en nuestro servidor. Eliminando caracteres como. y /. Eliminando cualquier carácter extraño.

47 FILE UPLOAD

48 Consiste en engañar al sistema para subir un archivo distinto al esperado, o subirlo en una ruta totalmente diferente. $target_path = DVWA_WEB_PAGE_TO_ROOT."hackable/uploads/"; $target_path = $target_path. basename( $_FILES['uploaded']['name']); move_uploaded_file($_files['uploaded']['tmp_name'], $target_path); Si se consigue la capacidad de subir ficheros, lo normal es subir una web shell como la C99.

49 Si esto se consigue, el atacante tendrá acceso directo al sistema. Si se consigue cambiar la ruta de subida de ficheros, pero no se pueden subir archivos ejecutables (por ejemplo únicamente podemos poenr imágenes), se suelen hacer DEFACES.

50 Cómo solucionar este problema? Comprobando además de la extensión del fichero, su tipo (ya que se puede saltar esa comprobación) Filtrando que el nombre de fichero no tenga.. ni /, u otros simbolos parecidos.

51 BRUTE FORCE

52 Consiste en probar millones de contraseñas hasta dar con la contraseña que buscamos. En la práctica este ataque no suele tener mucha efectividad, ya que la velocidad para realizarlo (online) es muy baja, siendo únicamente rentable utilizar un diccionario (contraseñas más utilizadas).

53 Contraseñas mas útilizadas:

54 Cómo realizar un bruteforce? Con FireForce, extensión de Firefox

55 Cómo solucionar este problema? Mostrando un captcha después de X intentos Bloqueando la IP después de fallar X veces Poniendo tokens en el formulario

56 INDICE 1.- Introducción Fingerprinting y exploits

57 Fingerprinting El fingerprinting es el primer paso que se realiza al probar un servidor web y busca recopilar la mayor cantidad de información posible.

58 Fingerprinting Buscaremos los siguientes datos: Qué aplicaciones web corren? Y en qué versiones? Hay rutas o archivos que pudieran considerarse como sensibles? Sobre qué servidor trabaja?

59 Fingerprinting Identificando el servidor web Mediante las cabeceras que devuelve (utilizando extensiones como Firefox Live HTTP Headers )

60 Fingerprinting Identificando el servidor web Mediante los errores que se devuelven. Muchas veces las páginas de error contienen la versión del servidor.

61 Fingerprinting Identificando el servidor web Cuidado! Esta información se puede engañar para mostrar resultados erróneos: Se pueden modificar las cabeceras para poner que un Apache es en realidad un IIS Se pueden cambiar las páginas de error por las de otro servidor.

62 Fingerprinting Obteniendo el tipo de aplicación: Mirando el código html. La mayoría de los CMS o aplicaciones webs suelen tener una etiqueta meta con el nombre, o un comentario indicandolo al pie de página.

63 Fingerprinting Obteniendo el tipo de aplicación: Mirando la estructura de carpetas. Teniendo un poco de conocimientos sobre plataformas comúnes, podremos identificarla por la carpeta en la que se guarden los css, imágenes o componentes.

64 Fingerprinting Obteniendo el tipo de aplicación: Probando a buscar el backend, ya que suele tener el logotipo de la plataforma: /administrator /admin /wp-admin /administrador..

65 Fingerprinting Una vez que se sepa la plataforma, hay que averiguar la versión. Podemos ir mirando el checksum (md5 de archivos) que se suelen modificar a lo largo de versiones. Se suele hacer una base de datos con estos md5 para agilizar el proceso. Ejemplo: blindelephant (python)

66 Fingerprinting

67 Introduccion Por qué ocultar la versión y la plataforma?

68 Fingerprinting Existen númerosas vulnerabilidades en las aplicaciones sin actualizar. Muchas veces, aunque la plataforma este actualizada, salen fallos y tardan varios dias en solucionarse. Siempre que sea posible lo recomendable es actualizar siempre que sea posible.

69 Fingerprinting

70 Preguntas, dudas, sugerencias?