sábado, marzo 16, 2013

Desenmascarando al control invisible en ASP.NET

Ayer nuestros amigos de Cyberhades, que no solo nos escriben grandes Microhistorias, sino que nos mantienen informados de lo que pasa en el mundo de las conferencias, recopilaron todas las charlas de BlackHat Europe 2013. Como tenía algo de tiempo me puse a revisarlas, y leerme las que más curiosidad me fueron generando. Algunas estaban mejor, otras peor, pero en casi todas aprendí algo nuevo.

Me llamó la atención la charla en la que utilizaban un SSID WiFi malicioso para hacer ataques XSS o CSRF a paneles de control, la charla sobre la botnet creada con HTML5 para usando el LocalStorage y WebGL llegar a ejecutar comandos en la GPU y crackear como un ninja usando los equipos zombies. También citaré la de PowerShell for Pentesting, que por algo escribimos nosotros un libro de PowerShell. Por supuesto, en esta colección de charlas hay que citar TIME, a perfect CRIME?, una evolución de los ataques BEAST y CRIME basada en mediciones de tiempo a ciegas. Pasada.

Sin embargo, la que más me gustó de toda por su organización y utilidad práctica fue la de Invisibility Purge. Esta sesión se basa en descubrir controles ASP.NET del lado del servidor que están ocultos al cliente, para conseguir acceder a funciones en test, ocultas o prohibidas a un determinado usuario.

La charla comienza con el nivel más sencillo, en la que el control ha sido comentado en el código fuente del cliente. Algo que es tan fácil de evadir como descomentarlo.

Figura 1: Control ASP.NET comentado en el código del cliente

Luego se complica un poco y pasa a los controles deshabilitados y a los ocultos desde el lado del servidor, con lo que no se puede ver nada en la página cliente. Sin embargo, utilizando un poco de Hacking con Buscadores, caché en el navegador de previas versiones de la página y errores forzados ASP.NET salen muchos de ellos.

Figura 2: Mensaje de error ASP.NET que indica que Event Validation está activo

Para terminar, la charla se lo pone complicado, y termina modificando las llamadas teniendo que manipular el ViewState y lidiar con Event Validation activado.

Figura 3: Nivel Nightmare

Dentro de esta presentación han publicado también las herramientas que han usado, que están en SCIP Project dentro de Google Code.

Figura 4: Herramienta SCIP liberada. Se integra con OWASP ZAP Proxy.

Más trucos a tener en cuenta cuando se hace una auditoría de aplicaciones .NET, que la puerta que abre el camino a la sala del trono se encuentra en el lugar menos esperado.

Saludos Malignos!

2 comentarios:

Anónimo dijo...

Buena entrada chema, la verdad es que estos tios de hacktics siempre estan ideando nuevas formas de intrusión en aplicaciones web, haber si otro dia haces un post mencionando su otra extensión llamada diviner.

Saludos!

Anónimo dijo...

Estaba leyendo, y estaba pensando: "menuda tontería, claro", con los controles comentados o inhabilitados.

Después, dije: hay que ser muy gañán o lo siguiente para no tener la evaluación de eventos y lo del viewstate activado, que por defecto ya está activado, vamos que tienes que poner a propósito esa cagada.

Lo de la caché me gustó más, sí, aunque la utilidad es muy limitada, entornos donde haya multiples usuarios compartiendo cliente, pero bueno, es está bien saberlo.

Aunque tendría que verlo, pero creo que el no-cache viene por defecto, lo que le haría perder toda la gracia.

Eleven Paths Blog

Seguridad Apple

Entradas populares