2010-09-20 17 views
6

Sé que ya hay algunas preguntas sobre SO sobre el exploit oracle padding, pero ninguna de ellas explica cómo se descarga el archivo web.config. Ejecuto un par de aplicaciones ASP .NET que ya he probado utilizando los factores de mitigación recomendados por Microsoft, pero todavía tengo miedo de que las personas puedan obtener el web.config.Oracle padding exploit: ¿cómo descarga el web.config?

¿Puede alguien explicar cómo lo hacen o incluso proporcionar un enlace a una herramienta que puedo usar para probar mi sitio? Encuentro que realmente falta la explicación oficial de esta parte del ataque.

El ataque que fue mostrado en público se basa en una característica en ASP.NET que permite que los archivos (por lo general javascript y css) para ser descargado, y que está asegurada con una llave que se envía como parte de la solicitud. Desafortunadamente, si puede forjar una clave, puede usar esta función para descargar el archivo web.config de una aplicación (pero no archivos fuera de la aplicación).

+0

bien si se hizo entrega de esa información sería un poco peligroso! – redsquare

+0

Aparentemente está en un video pero no puedo encontrarlo. La información ya está disponible para el resto del exploit de todos modos. – Alex

+0

No es necesario transmitir la información a través de un sitio público de q & a. – redsquare

Respuesta

0

Scott Guthrie tiene una publicación que lo explica hasta cierto punto.

+4

"Un oráculo en el contexto de la criptografía es un sistema que brinda pistas a medida que se formulan preguntas". No tiene nada que ver con Oracle (el fabricante de software). Oracle PR no puede estar muy contento con la nomenclatura aquí ... – Thilo

+1

Esta publicación no ayuda con los detalles sobre web.config que es lo que el solicitante quiere saber –

3

Guys - la respuesta es que una vez que han obtenido la machineKey, pueden utilizar esa clave a buscar a los archivos a través de otra de las características de ASP.NET

"En ASP.NET 3.5 Service Pack 1 y ASP.NET 4.0 hay una característica que se utiliza para servir archivos desde la aplicación. Esta característica normalmente está protegida por la clave del equipo. Sin embargo, si la clave del equipo está comprometida, esta característica se ve comprometida. Esto va directamente a ASP.NET y no a IIS, por lo que No se aplica la configuración de seguridad de IIS. Una vez que esta función se ve comprometida, el atacante puede descargar archivos de la aplicación, incluido el archivo web.config, que a menudo contiene contraseñas.

Versiones de A SP.NET anterior a ASP.NET 3.5 SP1 no tiene esta característica, pero sigue siendo vulnerable al ataque de la tecla de la máquina principal ".

(ver el mensaje en la parte inferior de aquí: http://forums.asp.net/t/1603799.aspx del equipo asp.net)

+0

Esta 'característica' parece ser proporcionada por WebResource.axd y/o archivos ScriptResource.axd. No he visto la confirmación de que deshabilitar/eliminar estos solucionará el problema de divulgación del archivo web.config, pero parece probable. Parece que el ataque puede recuperar la clave del equipo, que es el requisito previo para atacar estos archivos. – intoOrbit

+1

He intentado utilizar el enfoque WebResource.axd con los métodos 'ClientScript' y, por lo que sé, no solo los archivos que desea servir de este modo deben crearse como recursos incrustados, sino que debe agregar una declaración en el AssembilyInfo también. Si no estoy haciendo nada de esto, ¿cómo funciona este exploit? ¿Y cómo se obtiene algo tan crítico como el web.config? –

0

que yo sepa que va como este:

  • estos son golpeados: webresource.axd y scriptresource.axd, ambos utilizan una e ncrypted/signed value que asp.net intenta comprobar si es
  • válido
  • debido a las diferencias en la respuesta cuando los archivos son o no son válidos, pueden hacer el ataque de relleno.
  • una vez que el ataque tiene éxito pueden generar una solicitud de recursos como si se emite originalmente de asp.net

Ahora, por lo que yo sabía, tanto de los que se supone deben servir recursos incrustados, pero supongo que ese no es el caso (Scott Gu sí mencionó en los comentarios de su publicación cuáles eran los que se usaban en el ataque).