Hacking Webs en .NET: Trucos para una auditoría
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.
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:
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.
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:
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.
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! @ Un informático en el lado del mal: Hacking Webs en .NET: Trucos para una auditoría
