Claudio SalazarEstudiante Ing. Civil Informática UTFSM

Pinguinux Team

Web : Ataque y Defensa.

Temario

1. Introducción2. Cross Site Scripting (XSS)3. Inyección SQL4. Nuestro código en el servidor5. Ataques NG 6. Previniendo ..7. Medidas en el servidor

Introducción

¿ Seguridad, tanta importancia ? ● Robo de datos● Violación de privacidad● Personificación● Ejecución remota de código● Suplantación de contenido (phishing)● Cambio de contenido (deface)

Introducción● 90% de los sitios son vulnerables.● 75% de los sitios son blanco de XSS.

En Chile ..

● La mayoría de los atacantes son extranjeros.

● Script kiddies efectúan mass deface.● Linux lidera sistemas atacados.● Existen organismos fiscales que velan por políticas de seguridad.

go ?

Cross-Site Scripting (XSS)

“ En el futuro, XSS será el buffer overflow y JavaScript el shellcode “

Cross-Site Scripting (XSS)

● Tipo de ataque que aprovecha la mala validación de datos en páginas generadas dinámicamente.

● El atacante puede incluir código malicioso (JavaScript) que será ejecutado en el navegador de la víctima.

Cross-Site Scripting (XSS)

2 tipos de XSS

● Persistente: Código inyectado que luego es guardado y mostrado cada vez que se visita el sitio.

● No Persistente: Código inyectado en una url aprovechando el método GET y entregado a la víctima ocultado en enlaces, preferentemente.

Cross-Site Scripting (XSS)

Descubriendo XSS

● Cualquier sitio que devuelva datos ingresados por el usuario puede ser vulnerable (form, db, etc).

● Probando con el conocido<script>alert(“xss”);</script>

Cross-Site Scripting (XSS)

Peligros de XSS

● Fácil de encontrar● Útil para el phishing● Pérdida de cookies● Alteración de páginas hacia el cliente● Patrones cada vez más creativos● La gran mayoría de los usuarios tiene activado Javascript.

● IE más vulnerable que Mozilla Firefox.

Cross-Site Scripting (XSS)

Y ahora estamos en la Web 2.0, qué ?

● Ajax amplia el abanico de posibilidades en que un atacante pueda inyectar código.

● Ajax expone funciones internas al cliente● Puentes (Ajax Bridging) pueden ocultar ataques a sitios externos.

● Ajax y XSS como w0rm.

Cross-Site Scripting (XSS)

Muy aburrido ?

Inyección SQL

Inyección SQL

● Se inyecta código SQL en variables ingresadas por el usuario que posteriormente son parte de consultas a la base de datos●Un mal saneamiento de los datos nos lleva a ejecutar sentencias no esperadas en la DB● No es problema de la DB.

Inyección SQL

● El atacante no sabe la organización de la db, a menos que se trate de una aplicación open source.

● Mediante el ingreso de caracteres que tienen significado especial en la consulta, va recopilando información a partir de los errores.

1' OR 1 = 1; --

Inyección SQL

Ejemplo 1

$r = pg_query($conexion, "SELECT * FROM usuarios WHERE usuario='{$user}' AND

pass='{$pass}'");

$usr = pg_fetch_array($r);

if($usr[0] == $user) echo "OK";

http://sitio.com/?user=admin&pass=meechematehttp://sitio.com/?user=admin&pass=1' OR 1=1;--

Inyección SQL

● Datos importantes sobre la db en los esquemas de información.

● Oracle, MSSQL Server y Mysql están bien documentadas sus formas de explotación.

● Postgresql, la gran duda ¿ poco documentado o más seguro ?

Nuestro código en el servidor

Inclusión de archivos

● Una mala programación puede llevar a la inclusión de archivos con código tanto local como remota.● Este tipo de ataque es el más peligroso.● Permite inclusión de archivos de sistema con información relevante, si está al alcance del usuario del proceso.

Inclusión de archivos

2 tipos de inclusión

● Local : Se pueden incluir archivos de sistema u otros como los que contienen información sobre db, usuarios, etc.● Remota : Involucra la inclusión de archivos externos al servidor, probablemente programados por el atacante.

Ejecución de comandos

● Ataque producido por mal saneamiento en los datos introducidos por el usuario y que pasan a ser parte de comandos al sistema.

● No sólo referente a PHP, cualquier lenguaje web que tenga acceso al sistema y antes visto en cgi-bins.

Nuestro código en el servidor

Vamos a estirar los dedos :)

Ataques Nueva Generación

Cross-Site Request Forgery

● CSRF se aprovecha de la autenticación de la víctima en un sitio para efectuar peticiones sin conocimiento de esta.

● Estas peticiones son de acuerdo a las acciones que el usuario puede hacer en el sitio ( comprar, agregar, pagar, etc) .

http://sitio.com/vender.php?id=1000&usuario=87

Cross-Site Request Forgery

Feed Injection

Los lectores de feed también son vulnerables a ataques XSS y CSRF. Actúan de diferente manera:

● Lectores tratan '<' y '>' como literales.● Lectores cambian entidades html a sus valores reales. Ademas copian en disco.● Lectores evaden un tipo de feed, pero caen en otro.

Blind SQL Injection

● Usa la misma vulnerabilidad de SQL Injection simple.● En vez de ir recopilando información de los errores, compara la respuesta de la db frente a dos peticiones.● Útil cuando el servidor no entrega información.● Su lógica es preguntar al servidor y de acuerdo a la respuesta tomar caminos diferentes.

Otros nuevos muchachos

● Xpath Injection

● LDAP Injection

Previniendo ..

Previniendo ..Cross-Site Scripting (XSS)

● Caracteres no alfanúmericos no interpretarlos (entidades html).● Para la validación, aceptar lo que concuerda con el patrón y lo demás negarlo ( white-listing ).● Validar input y sobre todo output.● Como usuario, desactivar la carga de scripts no provenientes de la página que visitamos.● Fijarnos a lo que lleva cada link o imagen.

Previniendo ..

Inyección SQL

● Validación correcta de las variables que serán parte de la consulta.● Ocupar funciones destinadas a cada motor de base de datos.● Ser cauteloso con la salida de errores.● Privilegios mínimos del usuario que accede a la bd.●Uso de consultas parametrizadas.

Previniendo ..

Inclusión de Archivos

● No llamar archivos de sitios de terceros.● Si las páginas son llamadas por GET, hacer una contravalidación eficiente.● Preferir el uso de constantes que de variables.● Funciones como basename() previenen inclusiones locales (Divergencia entre SO).

Previniendo ..

Ejecución de comandos

● Ocupar funciones que provee PHP para prevenir comandos no deseados.● Limitar uso de recursos para no consumir al servidor.● Limitar comandos al uid de Apache( mediante PATH o permisos)

Previniendo ..

Cross-Site Request Forgery (CSRF)

● Uso de token especial● CAPTCHA● Redirección● POST sobre GET

Previniendo ..

Generalidades

● Cuidado con los errores (Path Disclosure, XSS, etc).● No confiar 100% en herramientas externas.● Estar al tanto de nuevos vectores de ataque.● Tener claro que funciones son peligrosas de usar y evitar su uso.

Medidas en el servidor

Medidas en el servidor

Apache

● Denegar acceso a archivos fuente (*.inc, *.phps, *.bak, etc).● Buena configuración de timeouts y conexiones para evitar DoS.

Medidas en el servidor

PHP

● Modo seguro (safe_mode).● No permitir páginas de terceros (allow_url_fopen).● No variables globales.● No magic_quotes_gpc.● Cuidado con llamadas a sistema.● Cuidado uploads.● Guardar información delicada en el servidor y no en archivos (db info).

Medidas en el servidor

Postgresql

● Configurar permisos claros para los usuarios.● Si no es necesario, bloquear conexión remota a la bd.

Medidas en el servidor

A tener en cuenta ..

● Restringir Google Hacking.● Usar otra capa de seguridad (mod_security, grasp core, suhosin).● Entre hosting dedicado y compartido, dedicado.● Estar al tanto de nuevas versiones del software ocupado.● Tener conciencia de seguridad.

Medidas en el servidor

A tener en cuenta ..

● Restringir Google Hacking.● Usar otra capa de seguridad (mod_security, grasp core, suhosin).● Entre hosting dedicado y compartido, dedicado.● Estar al tanto de nuevas versiones del software ocupado.● Tener conciencia de seguridad.

Links

● http://www.securityfocus.com● http://blog.php-security.org ● http://www.milw0rm.com● http://www.kriptopolis.org● http://ha.ckers.org● http://www.seguridad-informatica.cl● http://www.insecuremag.com● http://www.owasp.org● http://www.honeypot.org

Preguntas ?