III Foro Interdisciplinario de criptolog

Tamaño: px

Comenzar la demostración a partir de la página:

Download "III Foro Interdisciplinario de criptolog"

Tomás Río Reyes
hace 8 años
Vistas:

1 CORE SECURITY TECHNOLOGIES 2006 Ataques a web applications y contramedidas III Foro Interdisciplinario de criptolog Escuela Técnica Superior - 27 de Febrero, 2006 Ezequiel Gutesman Ariel Waissbein

2 Agenda 1. Introducción 2. Descripción de Ataques 3. Contramedidas

3 Que es una web application Una web application reune un conjunto de servicios o funcionalidades que se utilizan remotamente desde browsers. Típicamente el acceso es a travéz de redes como Internet, la red telefónica, et cetera. Entre otras, las web applications se usan para compras, participar en remates, realizar transacciones bancarias, pagos de servicios,.

Típicamente el acceso es a travéz de redes como Internet, la red telefónica, et cetera.

4 Motivación: los problemas de seguridad de web applications En el caso de web applications, la aplicación tiene esencialmente dos tipos de usuarios: Los dueños de la webapp, que mantienen las aplicaciones y el contenido en ella. Los clientes de la webapp que utilizan las aplicaciones y el contenido. Amenazas: Para los dueños el riesgo es perder sus bases de datos, la disponibilidad de los servicios, los ataques que se valen de su webapp para vulnerar a terceros, defacement, pivoting, Para los usuarios temen perder sus credenciales o información confidencial propia.

Los clientes de la webapp que utilizan las aplicaciones y el contenido.

5 Motivación: Seguridad para web applications La seguridad informática es una disciplina; pero no una ciencia. Más precisamente, no hay modelos formales que permitan definir y resolver problemas. Tenemos soluciones a (ciertos) problemas bien especificados y recetas, que llamamos best practices, para los otros problemas. Los lenguajes y APIs usadas para web applications han crecido de manera que hoy es trivial desarrollar páginas complejas (e inseguras). El número de ataques aumenta con el número de nuevas aplicaciones, y así su impacto en la población (e.g., incidentes con tarjetas de crédito, bancos, foros, )

Tenemos soluciones a (ciertos) problemas bien especificados y recetas, que llamamos best practices, para los otros problemas.

6 El estado del arte El Open web application security project (OWASP) tiene mantiene varios proyectos relacionados con la seguridad de web applications. OWASP Top Ten Webapp Security Vulns: This ten-most-waned list accuately scratches at the tip of an enormous iceberg. The underlying reality is shameful: most we application software is written oblivious to security principles, software engineering, operational implications, and indeed common sense. Dr. Peter Neumann (Científico ppal. De SRI Intl. Comp Sec. Lab.) Desde las primeras webapps, los lenguajes de scripting, las vulnerabilidad aparecen ininterrumpidamente. Para entender este top ten en detalle, hace falta repasar algunos conceptos

The underlying reality is shameful: most we application software is written oblivious to security principles, software engineering, operational implications, and indeed

8 En lo que se refiere a web applications Actores: Usuarios (e.g., internautas) Dueños de la página Atacantes Desarrolladores (gráfica y lógica) (contratados y open source) Sysadmins Editores de Contenido Usuario ws inet Web server Problemas asociados: Las webapps manejan info. crítica de los usuarios No hay garantias de seguridad y privacidad sobre esa info. Los usuarios corren código en sus browsers. No hay garantías sobre la integridad de ese código (e.g., no puedo distinguir código malicioso de código benigno).

Contenido Usuario ws inet Web server Problemas asociados: Las webapps manejan info.

9 Entendiendo al problema Componentes: Usuario Atacante Browser ws ws Web Server Database Server Content Editor inet Aplicación Seguridad: network IDS, network firewall, webapp firewall, ws Sysadmin ws firewall ids [Web service] web Web service db Las aplicaciones admiten distintos roles y son dinámicas.

IDS, network firewall, webapp firewall, ws Sysadmin ws firewall ids [Web

10 Infraestructura Protocolos http/https html http xml/soap sql IDS Browser http / https Firewall http / https Platformas PHP, Perl, Python ASP, ASP.net Java C/C++ WebServer VM Application soap WebServer VM Application sql sql Database Server Arquitectura de 2 o 3 capas

11 OWASP to 5 vulnerabilities 1. Ejecución remota de código: le permite a un atacante inyecte código que se ejecuta en la webapp. 2. Cross-site scripting: un atacante puede escribir links que, si alguien los clickea, ejecutan código elegido por él en la página del URL. 3. SQL injection: un atacante puede hacer queries arbitrarios en una webapp que no controla. 4. PHP Configuration 5. File System Attacks Vamos a ver ejemplos de 2 y 3 Estadísticas: Más de 3/4 partes de las páginas son susceptibles a los ataques 2 y 3. Implicancias directas: Robo/modif de datos Ataque a 3ros. Implicancias indirectas: Los datos personales ingresados a webapps no están protegidos Los atacantes pueden hacerme ejecutar código elegido por ellos en mi servicio de e-banking, u otra webapp.

SQL injection: un atacante puede hacer queries arbitrarios en una webapp que no controla. 4. PHP Configuration 5.

12 Una aplicación vulnerable: sql-injection attacks 1. Para acceder a la siguiente web application hace falta entrar un par usuario, clave correcto. WebApplication Login: Password: coco ******* OK 2. Al ingresarlo, la función de autenticación en la webapp hace el query en gris a la base de datos. select * from users where uid = coco ; uid 3. Si el par ya existe, entonces el login es exitoso. <html>login successful</html>

com/main WebApplication Login: Password: coco ******* OK 2.

13 Ataque de inyección de código (SQL-injection attack) Ingresando el usuario: ; comandosql; -- se logra que el motor de la base de datos corra este comando. WebApplication Login: Password: ; drop table users;-- ******* OK En una aplicación segura, esto no debería pasar. select * from users where uid = ; drop table users;-- ; uid Ataque Exitoso!

com/main WebApplication Login: Password: ; drop table users;-- ******* OK En una aplicación segura, esto no

14 Otra aplicación vulnerable: cross-site scripting Una aplicación similar a la anterior. Ahora, sanitizan comandos SQL. Tipeando en User: <SCRIPT>alert( hello world )</SCRIPT> se genera el URL request: hello world )</SCRIPT> La página es vulnerable a XSS! Porque en esta webapp no se validan los campos! En el peor escenario, la URL está en un mail, y en vez de usar el comando ALERT el atacante roba las credenciales de e- banking del receptor.

user=<script>alert( hello world )</SCRIPT> La página es vulnerable a XSS! Porque en esta webapp no se validan los campos!

15 Inyección en resumen Las dos vulnerabilidades anteriores explotan que la entrada no está correctamente sanitizada. En el caso de SQL-injection el atacante puede ejecutar un query SQL arbitrario. En el caso de XSS hay distintos escenarios. En el más común el URL está en un mail o publicado en un foro. Los atacados, hacen click en el link confiando en pero ejecutan un script elegido por el atacante (quien escribió el URL).

En el caso de XSS hay distintos escenarios. En el más común el URL está en un mail o publicado en un foro.

17 Contramedidas existenes: best practices Técnicas manuales (aka, best practices): Pre-desarrollo: Mejorar la especificacion Durante el desarrollo: Filtrar entradas de usuarios. Normalizar/Escape de metacaracteres Bloquear comandos ofensivos Post-desarrollo: Auditoría de código (periódica) Pros: Es la única manera de asegurarse no cometer ciertos errores. Cons: Costos, no se puede medir el éxito de estas medidas.

Normalizar/Escape de metacaracteres Bloquear comandos ofensivos Post-desarrollo: Auditoría de código

18 Contramedidas: software Productos o soluciones gratuitas Scanners de vulnerabilideades (Web Inspect, ) Usan banners de aplicaciones vulnerables conocidas Hacen algo de fuzzing (poco inteligente) en los campos de entrada Firewalls de web applications (Airlock, Imperva, ) Son stand-alone machines que resuelven todos los problemas Signature-based recognition y statistical-training (anomaly/misuse) Pros: aseguran evitar ciertas vulnerabilidades (conocidas). Cons: tienen muchos falsos positivos y negativos, no protegen contra 0day attacks, son difíciles de instalar (fw), son costosos ($$$).

machines que resuelven todos los problemas Signature-based recognition y statistical-training (anomaly/misuse) Pros: aseguran evitar ciertas

19 Contramedidas: análisis estático de código Análisis estático: WebSSari (2004) Permite encontrar vulnerabilidades de inyección. La técnica: Seguir el flujo de la información, e identificando cuales datos son ingresados por usuarios y cuales son parte del código. Aiken-Xie (2006) Permite encontrar vulnerabilidades de inyección Usa una mezlca inteligente de análisis intra-procedural, interprocedural y intra-bloques. Pros: permite identificar vulns. antes de instalar la webapp. Cons: No capturan el modelo real y resultan en poca precisión (hay muchos falsos pos. y neg.)

Aiken-Xie (2006) Permite encontrar vulnerabilidades de inyección Usa una mezlca inteligente de análisis intra-procedural, interprocedural y

20 Contramedidas: análisis dinámico Análisis dinámico SQLrand: Boyd-Keromitis (2003), Previene SQL-injection attacks. Requiere modifs. de código. Técnica: Inserta strings aleatorios a los comandos SQL, cosa que un atacante no puede descubrir, y requiere estos strings para ejecutar commandos. GRASP: Futoransky/Guteman/Tiscornia/Waissbein (2003) Protege una webapp arbitraria sin requerir instalaciones tediosas, es determinística, no requiere modificaciones de código de la webapp. Previene que los usuarios reciban data insana (XSS & privacidad), prevenir que el web server mande mensajes malignos a las APIs (database-, shell- and LDAP- injection, dir traversal). Técnica: próximos slides. Pros: Mejora la precisión. Cons: No resuelve el problema, solo evita ataques.

GRASP: Futoransky/Guteman/Tiscornia/Waissbein (2003) Protege una webapp arbitraria sin requerir instalaciones tediosas, es determinística, no requiere modificaciones de código de la webapp.

21 GRASP: modificar el execution environment GRASP es una modificación del execution environment del lenguaje de la webapp (eg, PHP). Cada objeto tiene asigando el tag usercontrolled, usando granularidad de caracacteres. IDS Browser http Firewall http Grasp El lenguaje sigue estos tags. Las APIs que se comunican con el backend o el browser revisan los comandos/ objetos que envian. select * from users where uid = john ; WebServer VM Application soap WebServer VM Application sql sql Grasp e u i d = ' j x o x h x n x ' ; String original Tags asociados Database Server

22 Grasp en acción Protección contra SQL-injection: Antes de mandar un comando a la base de datos, la solución analiza los sql statements junto con sus respectivos tags para reconocer ataques (y tomar contramedidas). IDS Browser http Firewall http select * from users where uid = ; drop table users;-- ; xxxxxxxxxxxxxxxxxxxxxx + + select * from users where uid = ; drop table users; -- ; xxxxxxxxxxxxxxxxxxxxx Attack Blocking & Logging Grasp WebServer VM Application soap WebServer VM Application sql sql RESULTADOS: tenemos un prototipo para proteger PHP.La pérdida en performance es tolerable, y pudimos comprobar la precisión en seguridad Grasp Database Server

23 Gracias Contacto: Web:

Documentos relacionados

Aplicaciones Web, Privacidad y Vulnerabilidades

CORE SECURITY TECHNOLOGIES 2002 Aplicaciones Web, Privacidad y Vulnerabilidades Ariel Waissbein Ariel Futoransky Agenda 1. Introducción 2. Catalogo de Ataques 3. Una propuesta nueva Motivación Con la explosión