Tratando de saltar la seguridad en el componente de upload de ficheros de una aplicaci\u00f3n ASP corriendo bajo IIS 6, me d\u00ed cuenta que IIS s\u00f3lo usa la parte de la URL antes de una \u2018\/\u2019 o \u2018\\\u2019 para determinar si un fichero ser\u00e1 ejecutado como un Active Server Page por la librer\u00eda ASP.dll. En concreto, IIS no parsea correctamente los nombres de los directorios cuando estos tienen extensiones ejecutables como 1) .asp, 2) .asa y 3) .cer. La extensi\u00f3n .aspx parece ser que no est\u00e1 afectada devolviendo un error 404, aun cuando el fichero existe en dicho path.<\/p>\n
Cuando se parsea una URL tal como \u2018maliciousfolder.asp\/code.pdf\u2019, se ejecuta una rutina que comprueba si ese fichero debe ser ejecutado por\u00a0 la ASP.dll. El car\u00e1cter \u2018\/\u2019 (o \u2018\\\u2019) rompe la cadena e IIS determina que ese fichero debe ser ejecutado como un script ASP, pero a la hora de ejecutarlo, una rutina distinta lee el fichero correcto: \u2018maliciousfolder.asp\/code.pdf\u2019 y ejecuta el c\u00f3digo contenido en \u00e9l, por lo que un atacante remoto podr\u00eda ejecutar c\u00f3digo ASP en el servidor web desde un fichero pdf o cualquier otro tipo de archivo considerado \u201cseguro\u201d para las aplicaciones de upload de ficheros.<\/p>\n
Adem\u00e1s, es posible combinar este ataque con el bug CVE-2009-4444<\/em>, permitiendo a atacantes remotos crear un directorio con una extensi\u00f3n ejecutable seguido de un car\u00e1cter \u2018;\u2019 y a continuaci\u00f3n una extensi\u00f3n considerada segura o cualquier otro sufijo, como se demuestra del uso de ASP.dll para manejar cadenas del tipo \u201c.asp;.jpg\u201d.<\/p>\n Proof of concept<\/strong><\/p>\n IIS ejecutar\u00e1 el c\u00f3digo ASP contenido en el fichero \u2018document.pdf\u2019 al acceder a las siguientes URL. Aqu\u00ed se describen algunos ejemplos:<\/p>\n http:\/\/host\/path\/folder.asp\/document.pdf<\/p>\n http:\/\/host\/path\/user.cer\/documents\/document.pdf<\/p>\n http:\/\/host\/path\/folder.asa\/other\/path\/document.pdf<\/p>\n http:\/\/host\/path\/folder.asp\\document.pdf<\/p>\n http:\/\/host\/path\/folder.cer\\document.pdf<\/p>\n http:\/\/host\/path\/folder.asa\\document.pdf<\/p><\/blockquote>\n En combinaci\u00f3n con el CVE-2009-4444<\/em> ref #1, la siguiente URL es v\u00e1lida tambi\u00e9n :<\/p>\n http:\/\/host\/path\/folder.asp;.jpg\/document.pdf<\/p><\/blockquote>\n En otros casos me he encontrado filtros backlist para el filtrado de extensiones, pero lo que normalmente se trata de transmitir a los desarrolladores es que esos filtros no funcionan, siempre hay una manera de saltarlos, la soluci\u00f3n es usar filtros whitelist y el principio de seguridad en profundidad.<\/p>\n Por ejemplo, un caso real fue una aplicaci\u00f3n que filtraba las extensiones \u201cpeligrosas\u201d tales como \u201c.asa\u201d, \u201c.asp\u201d, \u201c.php\u201d, \u201c.jsp\u201d, \u201c.cer\u201d etc etc, pero utilizaba *s\u00f3lo* los 3 caracteres siguientes despu\u00e9s del punto para comprobar si la extensi\u00f3n esta permitida o no. Pues bien, esto se podr\u00eda bypassear usando NTFS Alternate Data Streams (ADS) gracias al car\u00e1cter \u2018:\u2019\u00a0 despu\u00e9s del nombre de fichero y el stream \u201c$DATA\u201d, lo que har\u00eda que se creara el fichero \u2018file.asp\u2019 con el c\u00f3digo que elijamos y lo har\u00eda accesible v\u00eda el servidor web, por lo que, podr\u00edamos ejecutarlo.<\/p>\n Proof of concept: file.asp::$DATA<\/p>\n Incluso usando filtros whitelist existen maneras de saltar ciertas protecciones, como la presentada m\u00e1s arriba, o usando otro tipo de t\u00e9cnicas.<\/p>\n Normalmente los desarrolladores, obtendr\u00e1n los tres \u00faltimos car\u00e1cteres y comparar\u00e1n con la lista de extensiones seguras (tales como jpg, gif, png, etc). En este caso, usando ADS y el car\u00e1cter \u2018:\u2019 (CVE-2009-4445 ref. #2)<\/em> podr\u00edamos construir una cadena para el nombre del fichero del tipo \u201cfilename.asp:.jpg\u201d lo cual har\u00eda que la extensi\u00f3n sea v\u00e1lida, ya que jpg estar\u00eda en esa lista de extensiones permitidas y podr\u00edamos crear ficheros vac\u00edos con extensi\u00f3n asp. Combinando esta vulnerabilidad con otras podr\u00edamos llegar a comprometer el servidor.<\/p>\n PoC: file.asp:.jpg -> El fichero file.asp es creado en el DocumentRoot sin contenido.<\/p><\/blockquote>\n Junto a estas, existen otras t\u00e9cnicas para tratar de burlar el sistema de protecci\u00f3n, pero cada caso hay que estudiarlo por separado. Los componentes de upload de ficheros en aplicaciones web son uno de los elementos m\u00e1s delicados y hay que prestarle mucha atenci\u00f3n en todas las etapas del SDLC.<\/p>\n Si no conoces como funcionan los ADS, echale un ojo a\u00a0 al ref. #3<\/p>\n Impacto<\/strong><\/p>\n El impacto de esta vulnerabilidad es alto debido a que los atacantes pueden saltar las protecciones ante la gesti\u00f3n de las extensiones de ficheros en 3rd-party webapps subiendo ficheros con cualquier extensi\u00f3n (por ej pdf, txt) a una carpeta acabada en una extensi\u00f3n ejecutable (tal como .asp, .cer, .asa, \u2026).<\/p>\n La librer\u00eda ASP.dll tiene un comportamiento no esperado manejando este tipo de URLs y podr\u00eda permitir a atcantes remotos ejecutar c\u00f3digo si el directorio tiene permiso de ejecuci\u00f3n.<\/p>\n Sistemas afectados<\/strong><\/p>\n Probado en Microsoft Windows 2003 SP2 up to date con Internet Information Services (IIS) version 6 La respuesta<\/strong><\/p>\n La respuesta del MSRC fue una frase que a muchos os sonar\u00e1: HOYGAN! This is not a bug, it\u2019s a feature!<\/em><\/p>\n De todas maneras, me parece importante publicar la descripci\u00f3n t\u00e9cnica ya que puede ser \u00fatil en algunos pen-tests\/auditor\u00edas de seguridad, y de modo similar o m\u00e1s importante para ayudar a los sysadmin a prevenir este tipo de ataques (la soluci\u00f3n ante este problema se describe en la \u00faltima secci\u00f3n de este art\u00edculo). Gracias de todos modos al MSRC y a todos los que participaron de una u otra manera en la investigaci\u00f3n.<\/p>\n De todos modos, tambi\u00e9n puede ser argumentado (y fue la conclusi\u00f3n final) que esta vulnerabilidad no es del propio IIS, sino de la 3rd-party webapp, debido a que es su responsabilidad filtrar todo tipo de car\u00e1cteres malintencionados tanto en los nombres de los ficheros como en los nombres de las carpetas. Y el hecho es que muchas aplicaciones web aplican protecciones de seguridad ante los nombres de los ficheros pero no a los nombres de las carpetas en aquellas apps que trabajan con directorios. Es en este caso es, precisamente,\u00a0 donde encaja este estudio.<\/p>\n El porqu\u00e9<\/strong><\/p>\n Ahora voy a explicar los detalles t\u00e9cnicos:<\/p>\n Cuando una nueva petici\u00f3n llega a IIS, \u00e9ste calcula con que m\u00f3dulo se procesar\u00e1, parseando la URL de izquierda a derecha y buscando extensiones v\u00e1lidas en cada segmento.<\/p>\n Cuando una extensi\u00f3n es encontrada, en primer lugar se compara con una lista de extensiones ejecutables (.exe, .com, .dll e .isa). Si \u00e9sta es .exe o .com IIS pasa el control a CGI o a ISAPI, en caso de ser .dll o .isa. De la misma manera, tambi\u00e9n compara dicha extensi\u00f3n contra la lista configurada de extensiones de script (por defecto esta lista contendr\u00e1: .asp, .cer, .asa, etc). Si alguna de estas extensiones coincide se pasar\u00e1 el control al motor de script asociado con la extensi\u00f3n en cuesti\u00f3n.<\/p>\n La cadena que se encuentre despu\u00e9s de una extensi\u00f3n v\u00e1lida y antes del car\u00e1cter \u2018?\u2019 ser\u00e1 considerado la variable PATH_INFO seg\u00fan la especificaci\u00f3n CGI, (la cadena despu\u00e9s del car\u00e1cter \u2018?\u2019 es la query string)<\/p>\n Pero, qu\u00e9 es PATH_INFO?<\/p>\n Como se puede leer en #4:<\/p>\n The extra path information, as given by the client. In other words, scripts can be accessed by their virtual pathname, followed by extra information at the end of this path. The extra information is sent as PATH_INFO. This information should be decoded by the server if it comes from a URL before it is passed to the CGI script.<\/p><\/blockquote>\n Por lo tanto es la informaci\u00f3n extra al final del nombre de ruta virtual (donde el nombre de ruta virtual es la URL). Pero el problema es que ASP maneja de forma no standard tanto la variable PATH_INFO como la variable PATH_TRANSLATED a la hora de buscar el fichero de script a ejecutar. ASP asume que la variable PATH_TRANSLATED contendr\u00e1 el path f\u00edsico completo al fichero de script.<\/p>\n Para el correcto funcionamiento de ASP, PATH_INFO debe ser la URL, ya que el mapeo de la URL a un path f\u00edsico conducir\u00e1 a la p\u00e1gina ASP. Pero, de acuerdo con la especificaci\u00f3n de CGI 1.3 #ref 4, PATH_INFO no est\u00e1 definido como una URL.<\/p>\n IIS tiene un switch de configuraci\u00f3n que controla cuando los motores de script ven la URL o la informaci\u00f3n definida por CGI en la variable del servidor PATH_INFO. Este switch de configuraci\u00f3n se llama AllowPathInfoForScriptMappings y podeis encontrar m\u00e1s informaci\u00f3n en ref #5<\/p>\n Debemos considerar los dos valores de configuraci\u00f3n posible para la variable AllowPathInfoForScriptMappings, en ambos casos podemos reproducir el PoC:<\/p>\n AllowPathInfoForScriptMappings=FALSE<\/em> (Por defecto)<\/strong><\/p>\n En esta situaci\u00f3n la URL ser\u00e1 asignada a la variable PATH_INFO, por lo que la variable PATH_TRANSLATED contendr\u00e1 el path f\u00edsico completo a la URL.<\/p>\n Pongamos de ejemplo de URL \u201chttp:\/\/host\/path\/folder.asp\/file.txt<\/a>\u201d, veamos como quedar\u00eda:<\/p>\n Ya que la extensi\u00f3n encontrada \u2018.asp\u2019 est\u00e1 asignada para ser procesada por un script, la petici\u00f3n ser\u00e1 gestionada por asp.dll, la cual intentar\u00e1 abrir la ruta final (#3). Si este fichero existe, ASP lo procesar\u00e1 como un script ASP y enviar\u00e1 la salida al cliente. Para que el PoC funcione, el fichero \u201cfile.txt\u201d debe existir en el directorio \u201cfolder.asp\u201d. Este es el caso comentado m\u00e1s arriba.<\/em><\/p>\n AllowPathInfoForScriptMappings=TRUE<\/em><\/p>\n En este caso, veamos como queda:<\/p>\n Usando el mismo ejemplo,\u00a0 y teniendo en cuenta que la extensi\u00f3n encontrada es tambi\u00e9n .asp, la petici\u00f3n ser\u00e1 gestionada por asp.dll.<\/p>\n ASP abrir\u00e1 el fichero \u201cc:\\inetpub\\wwwroot\\file.txt\u201d (#3) y lo procesar\u00e1 como un script ASP. En este caso el sysadmin ha debido cambiar el valor de AllowPathInfoForScriptMappings manualmente, por lo que considero el ataque mucho m\u00e1s complicado.<\/p>\n Hay que tener en cuenta que configurar AllowPathInfoForScriptMappings al valor TRUE, romper\u00e1 el funcionamiento normal de ASP. Considerando una petici\u00f3n \u201cnormal\u201d de ASP como \u201chttp:\/\/host\/path\/file.asp<\/a>\u201d, significar\u00eda que la variable PATH_INFO ser\u00eda una cadena vac\u00eda (puesto que no hay nada despu\u00e9s de la URL) y PATH_TRANSLATED valdr\u00eda \u201cc:\\inetpub\\wwwroot\\\u201d sin ning\u00fan fichero. Lo que significa que las peticiones normales de ASP no funcionar\u00edan y es muy poco probable que un administrador de sistemas quiera servir ASP con esta configuraci\u00f3n.<\/p>\n La soluci\u00f3n<\/strong><\/p>\n La soluci\u00f3n va enfocada a dos roles diferentes:<\/p>\n – Sysadmins<\/strong>: Eliminar el permiso de ejecuci\u00f3n en los directorios donde se permita subir ficheros.<\/strong> Seguir la gu\u00eda de mejores pr\u00e1cticas de seguridad para IIS 6 (Ref #6)<\/p>\n – Developers<\/strong>: No confiar en la entrada proporcionada por el usuario y *nunca* usarla como nombre de fichero. Generar un nombre de fichero aleatorio<\/strong> y almacenar el nombre real en un lugar distinto (por ej, una base de datos). A ser posible setear la extensi\u00f3n por la propia aplicaci\u00f3n, con cla\u00fasulas switch-case por ejemplo. S\u00f3lo aceptar cadenas alphanum\u00e9ricas para la extensi\u00f3n y nombre de fichero.<\/p>\n Referencias<\/strong><\/p>\n Fuente: blog.48bits.com por Juan Galiana<\/p>\n","protected":false},"excerpt":{"rendered":" por Juan Galiana Descripci\u00f3n Tratando de saltar la seguridad en el componente de upload de ficheros de una aplicaci\u00f3n ASP corriendo bajo IIS 6, me d\u00ed cuenta que IIS s\u00f3lo usa la parte de la URL antes de una \u2018\/\u2019 o \u2018\\\u2019 para determinar si un fichero ser\u00e1 ejecutado como un Active Server Page por […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-790","post","type-post","status-publish","format-standard","hentry","category-profesional"],"yoast_head":"\n
\nNota: un atacante necesita interacturar con una aplicaci\u00f3n la cual debe tener permisos de escritura para subir ficheros y ejecuci\u00f3n en el servidor web.
\nSystemas no afectados: Parece que IIS 5.1 sobre Windows XP SP3 devuelve un c\u00f3digo 404 cuando se intenta reproducir el PoC, IIS 7.x not tested<\/p>\n![\"bug-feature\"](\"http:\/\/blog.48bits.com\/wp-content\/uploads\/2010\/09\/bug-feature.jpg\" "\\"bug-feature\\"")
<\/a><\/p>\n\n
\n
\n
\n<\/a><\/li>\n