El sábado por la tarde aproveché para leer la Hack In The Box Magazine número 9 en la que hay un artículo sobre Hacking .NET Applications. Esto, cuando estás haciendo auditoría de seguridad aplicaciones web sabes que no es lo que "más mola", ya que en la mayoría de los casos las aplicaciones en PHP o ASP
suelen tener muchos más fallos de seguridad. Sin embargo, el artículo
me enganchó desde el principio ya que decía justo eso en el título:
Hack an ASP.NET site? It is difficult, but possible!
Evidentemente, el escritor V. Kochetkov se había pegado con una auditoría ASP.NET
alguna vez, así que le di una lectura en detalle y me encantó. Así que
he decidido resumiros los puntos que cita, los que he podido probar, y
los que no me encontrado con ninguno de ellos.
1) El bug del IIS Short Name en 8:3
Este bug se ha hecho muy popular, y permite listar los archivos y directorios de un sitio web en formato 8.3 con IIS si no tiene filtrados los códigos de error. En la FOCA Pro tenéis un plug-in que implementa esta técnica
y en la siguiente actualización tendréis un nuevo fuzzer que saca mucho
más, ya que hemos estado depurando finamente esta técnica.
2) Corrupción de memoria
En teoría, una aplicación .NET con código manejado no
puede corromper la memoria, sin embargo hay varios puntos donde pueden
aparecer estas vulnerabilidades como un integer overflow en la librería gdiplus de la implementación .NET de System.Drawing (MS12-025), o el uso de mixed assemblies - que mezclan código manejado y no manejado en implementaciones que puede generarse con C++ sobre .NET - como en el uso de la implementación de SQLite en .NET.
Además, el programador siempre puede liarla con la generación de un
bloque de código inseguro con memoria no manejada, como el ejemplo
siguiente.
Figura 2: Código en .NET inseguro |
3) Turkish-I
Este fallo es muy peculiar y se produce cuando la aplicación .NET
detecta la cultura usada en la máquina cliente, haciendo la conversión
de los strings en el lado del servidor. En casos como la cultura Turca o de Azerbayán,
la transformación de strings de un idioma a otro no es siempre posible
debido a la ausencia de traducción de todos los caracteres, lo que
provoca que ciertas comparaciones queden bypasseadas. Una explicación
más detallada de este curioso caso lo tienes aquí: The case of Turkish-I
4) Colisiones de Hashes
La vulnerabilidad no es única de .NET, ya que es la que fue publicada en el CCC y afectaba prácticamente a todos los lenguajes de programación. En determinadas circunstancias es posible realizar un D.O.S. Microsoft lo solucionó en el MS11-100.
5) Trace.axd
Esta vulnerabilidad permite acceder a los datos de debugging de las
aplicaciones. Si se ha activado la traza, y no se ha bloqueado su acceso
externo, es posible acceder a mucha información del servidor. Haciendo
un poco de Google, Bing, Shodan Hacking es posible encontrar cientos de servidores con trace.axd activado, donde se puede sacar info como ésta:
Figura 3: Información (parcial) accesible desde trace.axd |
6) View State
El View State es esa cookie tan larga y cifrada que se envía entre el cliente y servidor en todas aplicaciones .NET. Como está cifrada, muchos desarrolladores confían en el View State para guardar información de la sesión en el client-side, algo que no deberían hacer. Descifrando y viendo el contenido del View State se puede acceder a información útil de la sesión de la aplicación.
Figura 4: ViewState Spy |
Algunos ejemplos de lo que se puede hacer con los datos del View State, como ataques XSS, LFI, etc... los tenéis en este documento de Timur Yinusov.
7) Vulnerabilidades LFI
Los programadores en .NET también pueden hacer una aplicación vulnerable a ataques LFI, haciendo uso de tres funciones diferentes en su aplicación:
1. Response.WriteFile(vfilename): El path es virtual y devuelve un fichero.
2. Server.Execute(vfilename): El path es virtual y llama al manejador de un fichero
3. File.ReadAllText(filename): Lee el contenido de un fichero y puede pasarse la ruta del fichero en formato relativo o absoluto.
Si el programador hace uso de esas funciones es posible encontrar LFI en la aplicación .NET.
8) Asignación Masiva
La idea es que se produzca la carga de objetos de forma masiva desde un
repositorio de datos a una aplicación .NET. Si no se controlan los
parámetros que se están asignando masivamente podrían ponerse
asignaciones de parámetros como isPrivileged o WritePermission de forma
insegura. Es un caso muy particular, pero como dice el artículo, así hackearon GitHub.
9) LinQ Injection
La última de las vulnerabilidades consiste en algo similar al SQL Injection, en este caso en construir de forma insegura las consultas de acceso a datos LinQ
cuando se construyen dinámicamente. Esto quiere decir que los
parámetros o los objetos sobre los que se lanzan las consultas cambian
dependiendo de un parámetro para lo que el programador puede construir
de forma insegura esa comparación usando un string concatenado. Algo
como esto:
Figura 5: Código vulnerable a LinQ Injection |
El resto sería trasladar SQL Injection en lenguaje LinQ para conseguir saltar validaciones de acceso, por ejemplo.
Algunas cosas más sobre SharePoint y ASP
Además de estos fallos, también os recomendaría mirar si hay alguna aplicación ASP migrada a IIS 7 en la que se hayan dejado los códigos de error 404 sin proteger y mirar si hay algún SharePoint Portal Server [Fingerprinting SharePoint] que pueda tener algún fallo [Auditar SharePoint]. Para ello, en el libro de SharePoint 2010: Seguridad, tienes más información de cómo auditar un SharePoint.
Figura 6: Error 404 en una aplicación ASP migrada a IIS 7 |
Espero que el resumen os sea útil, y aunque como dice el título auditar una aplicación .NET
es difícil, no es imposible porque siempre podemos encontrarnos un
administrador que no actualiza los parches de los bugs conocidos o un
programador que no programa de forma segura. Si quieres aprender mucho
de estas cosas, puedes apuntarte a nuestra Formación Técnica de Seguridad y Auditoría Informática.
Saludos Malignos!
Fuente: Chema Alonso
No hay comentarios:
Publicar un comentario