Racciatti Html Scripting Attacks

4to Seminario de Segu-Info

Protegiendo mi IdentidadSi no soy yo, ¿sos vos?

Hernán M. RacciattiSICLabs (at SICinformática)

http://[email protected]

HTML Scripting Attack


http://creativecommons.org/licenses/by-nc-sa/2.5/ar/

Ud. puede:

Copiar, distribuir, exhibir, y ejecutar la obra

Hacer obras derivadas

Bajo las siguientes condiciones:

Atribución. Debe atribuir la obra en la forma especificada por el autor

No Comercial. No puede usar esta obra con fines comerciales.

Compartir Obras Derivadas Igual. Si altera, transforma, o crea sobre esta obra, sólo podrá distribuir la obra derivada resultante bajo una licencia idéntica a ésta.

Licencia de uso: Creative Commons 2.5 Argentina

http://creativecommons.org/licenses/by-nc-sa/2.5/ar/


Temario

Antes de Comenzar…

HTML Scripting Attacks

Por qué Hablar de HTML Scripting Attacks?

Cross-Site Scripting

Reflected Cross Site Scripting (XSS)

Los POST también son explotables?

Persistent Cross Site Scripting (XSS)

Reflected Cross Site Scripting (Local Files)

Cien por ciento seguro?

Cómo identificar vulnerabilidades de XSS?

Contramedidas

Referencias y Lectura Complementaria


Antes de comenzar…

Web ServerCliente/Browser

El Browser conecta con el servidor y requiere una página

El Server responde el requerimiento enviando la página (archivo) solicitada


Antes de comenzar…

Cliente/Browser



En palabras sencillas, los ataques de HTML Scripting, tienen por propósito inyectar código (Visual Basic Script,

ActiveX, Flash, etc.) con el objeto que el mismo sea retornado como parte del output de una aplicación,

modificando de este modo su normal comportamiento.


HTML no solamente es utilizado en la web

Mails - Help Files - GUIs

HTML rendering engines ricas en funcionalidades:

Running Scripts - Plug-ins – Applets

Ventajas para el desarrollador a la hora de crear aplicaciones más atractivas -> Nuevas posibilidades de explotación para el atacante.

Por qué hablar de HTML Scripting Attacks?


Por qué hablar de HTML Scripting Attacks?

Del mismo modo en que HTML no se encuentra restringido a la web, los ataques de HTML Scripting

tampoco.

A pesar de que este tipo de ataques son extremadamente comunes en aplicaciones web,

aplicaciones cliente que no realicen rendering HTML de tipo server-side, pueden también ser vulnerables.



Cross-site scripting (XSS)

Reflected Cross-Site Scripting (Non-persistent)

Persisted Cross-Site Scripting (Script Injection)


Cross-Site Scripting

El script HTML que suele devolverse a un navegador web desde un servidor, normalmente fue colocado allí por alguien que tiene la capacidad de autoría de páginas HTML en dicho servidor (Ej. Webmaster)

Un ataque de Cross-Site Scripting (XSS), se produce cuando un atacante logra hacer que el servidor web devuelva un Script HTML, sin contar con el nivel de permisos en el servidor para realizar dicha acción. De hecho, el atacante NO modifica nada en el servidor.

El ataque ocurre cuando el código del servidor (server side-code) toma el input suplido por el usuario y repite el mismo de modo tal que los datos sean ejecutados como Script HMTL en la máquina cliente.

En otras palabras, mediante este tipo de ataques se busca forzar a un sitio web a repetir el código ejecutable suministrado por un atacante, de modo tal que el mismo sea cargado en el navegador del usuario y por ende ejecutado en dicho contexto.


En pocas plabras

Ataque del lado del cliente

Técnica por medio de la cual se fuerza a un sitio web a repetir el código ejecutable suministrado por un atacante, el cual se carga en el navegador del usuario.

El código normalmente está escrito en HTML o JavaScript, pero también puede extenderse a VBScript, ActiveX, Java, Flash, o cualquier otra tecnología soportada por el navegador.

Objetivos probablemente Vulnerables a XSS

Web bulletin boards, Weblogs, Chat rooms, Libros de Visita, Clientes de Web Mail, Formularios de Confirmación en diferentes aplicaciones.

“Cualquier aplicación que refleje el input del usuario sin validar su contenido (Input/Output).”

Cross-Site Scripting (Cont.)


Reflected Cross-Site Scripting

Se produce cuando datos provistos por un cliente web, son usados inmediatamente por el server-side script a efectos de generar una página de resultados para el usuario.

Si los datos suplidos por el usuario, terminan formando parte de la página de resultado mostrada al cliente, sin que los mismos hayan sido correctamente validados/encodeados, podría resultar que dicho código sea inyectado dentro de la pagina generada dinámicamente.

Ejemplos básicos:

<script> document.documentElement.innerHTML="Owned by My"; </script>

<script>alert(document.cookie)</script>

<script>while(1)alert(“DoS Exploit");</script>

<EMBED SRC=http://www.pedofilia.com/movies/video.mov>

<iframe src=http://mipagina.com/pagina.htm>


Reflected Cross-Site Scripting

Demo #1


Reflected Cross-Site Scripting (Cont.)

Que tan serio es el problema?

El verdadero problema, es que el browser termina viendo un script que le es enviado a través del propio webserver, originado en el website al cual el propio browser envió su requerimiento!!!

Los navegadores web y otros clientes web, a menudo se basan en un modelo de seguridad el cual permite que sólo el sitio web que emitió ciertos datos al cliente obtenga datos del mismo.

Por ejemplo, si www.greatsecure.com emite una cookie a un navegador, greatsecure.com puede leer esta cookie, pero microsoft.com no.

Ahora.. Suponiendo que www.greatsecure.com se encuentra hosteando una página de búsqueda que presenta un bug de XSS. Si el script es presentado a través de http://www.greatsecure.com/search.aspx y el mismo intenta acceder a la cookie generada por www.greatsecure.com ,podrá hacerlo. Esto se debe a que el navegador del cliente interpreta que el script fue originado por www.greatsecure.com.

http://www.greatsecure.com/


http://www.greatsecure.com/search.aspx





Que tan serio es el problema? (Cont.)

Básicamente XSS habilita acciones que son normalmente prohibidas.

Cookie Access

Object Model Access

User Data Access

Bypassing SiteLock restrictions

Zone Elevation

Etc.


Website Vulnerable

Servidor que el Atacante Controla

Atacante

Víctima

Click me!!

Script

SendCookieToAttacker{}

/Script



Los POST también son explotables?


Los POST también son explotables? (Cont.)


Persistent Cross-Site Scripting

Variante a menudo referida como script injection, html injection, stored o second-order injection.

Casi idéntico en cuanto a su funcionalidad a los ataques de tipo Reflected Cross-Site Scripting, excepto que en este caso, los datos suplidos por el atacante son almacenados por el servidor (Ej: Database, File System, etc.)

En este caso, en lugar de obligar a la víctima a realizar una petición que contiene la carga de datos maliciosa (script), el atacante almacena dicho script , para luego simplemente esperar que la víctima visite la URL en donde finalmente se mostrará el script almacenado en el servidor.

Si los datos suplidos por el usuario, son almacenados por la aplicación sin que los mismos hayan sido correctamente validados/encodeados y terminan formando parte de una página ha ser mostrada cada vez que sea requerida, sin validar/encodear correctamente el output, podría resultar que dicho código sea ejecutado con cada nueva visualización.


Persistent Cross-Site Scripting

Demo #2


Reflected Cross-Site Scripting (Local Files)

Con frecuencia, tanto aplicaciones como sistemas operativos, instalan varios archivos HTML , adicionalmente a otros tantos archivos temporales usados por el propio navegador web.

Archivos de Ayuda, templates usados para generar interfaces de usuario en forma dinámica dentro de una aplicación, etc.

Estos archivos no se limitan a aquellos con extensión .htm o .html, de hecho archivos HTML también pueden ser encontrados “dentro” de otros archivos como por ejemplo:

Archivo Binario de Windows (“HTML Resources”)

res://D:/HTMLResExample.dll/102#<SCRIPT>alert("Hi!")</SCRIPT>.

Archivos CHM (Compiled Help Module)

ms-its:c:\xss\CHMDemo.chm::/searchResults.htm#<SCRIPT>alert('Hi!');</SCRIPT>

Estos tres tipos de archivos pueden contener bugs de XSS.



Pero… los archivos locales, no son ejecutados a través de un interprete del lado del servidor tal como sucede con lenguajes tales como Perl, ASP o PHP. Como puede entonces un archivo HTML local contener un bug de tipo reflected XSS??

Los archivos HTML pueden contener scripts que “re-escriban” su propio contenido y reproduzcan los datos suplidos por el usuario.

El envío de datos a un archivo HTML local, usualmente es llevado a la práctica agregando un signo numeral (#) al nombre del archivo, seguido por los datos que este se encuentra preparado para recibir como parámetro.



Demo #3



El nombre ingresado no se observa en el HTML resultante…

La variable conteniendo el nombre, ha sido seteada con el valor hash del browser

(location.hash)El nuevo contenido es escrito en el HTML mostrado en pantalla (A través de DOM) usando

el método document.write

El bwowser muestra el contenido HTML modificado permitiéndonos visualizar el nombre

ingresado (Hernan)

Datos No confiables están siendo mostrados sin ser filtrados y/o encodeados


Ciento por ciento seguro?

Cuando de prevenir ataques XSS se trata, a menudo suele ser aplicado un enfoque del tipo “encodear y filtrar”, lo cual toma lugar sobre el servidor, antes de que este retorne los datos ingresados al browser del cliente.

Uno de los desafíos respecto de construir un filtro efectivo del lado del servidor, radica en habilitar al servidor para que reconozca los datos de la misma forma que el cliente (browser) lo haría.

Una manera de bypasear algunos filtros del lado del servidor, es enviar datos al mismo, usando un tipo de “encoding/character set” diferente al utilizado por el servidor.


Ciento por ciento seguro? (Cont.)

Unicode Transformation Format 7 (UTF-7)


Ciento por ciento seguro? (Cont.)


Cómo Identificar vulnerabilidades de XSS?

Identifique todos los lugares donde datos provistos por el usuario, pueden ser enviados a la aplicación.

Envíe datos validos a la aplicación y observe su comportamiento.

Identifique cualquier punto donde los datos enviados sean retornados al navegador o almacenados para ser mostrados en otra instancia.

Lleve adelante una auditoría de código fuente.


Contramedidas

Asuma que todo INPUT es malicioso

Valide todo INPUT (Todo es TODO…)

Establezca Validaciones Efectivas (Tipo, Largo, Formato y Rango)

Codifique (Encode) el OUTPUT


Referencias y Lectura Complementaria

Hunting Security Bugs – Microsoft Press - by Tom Gallagher, Bryan Jeffries and Lawrence Landauer - ISBN:073562187X

http://ha.ckers.org/xss.html

http://www.webappsec.org/projects/articles/071105.shtml

http://www.microsoft.com/downloads/details.aspx?FamilyId=EFB9C819-53FF-4F82-BFAF-E11625130C25&displaylang=en

http://msdn2.microsoft.com/en-us/library/ms998274.aspx

http://www.bindshell.net/tools/beef/

http://www.gnucitizen.org/backframe

http://xssworm.com/

http://blogged-on.de/xss/

http://ferruh.mavituna.com/xss-tunnelling-paper-and-xss-tunnel-tool-oku/

http://xss-proxy.sourceforge.net/

http://www.hernanracciatti.com.ar - http://www.sicinformatica.com.ar

http://www.cert.org/tech_tips/malicious_code_mitigation


Hernán M. Racciattimailto:[email protected]

http://www.sicinformatica.com.arhttp://www.hernanracciatti.com.ar

¡Gracias por su Atención!

Racciatti Html Scripting Attacks

Technology

Transcript of Racciatti Html Scripting Attacks