Como ya comentamos, algunos integrantes del equipo de Laboratorio e Investigación de ESET Latinoamérica estuvimos en la ciudad de Las Vegas asistiendo a los eventos más importantes del año en seguridad y hacking, Black Hat y Defcon; y quería seguir compartiendo con ustedes algunas de las charlas a las que asistimos estos días como comenté hace unos días sobre el estado de la seguridad. En la Black Hat suelen presentarse muchas vulnerabilidades 0-day que hasta el momento no eran conocidas, y una de ellas fue presentada por dos jóvenes amigos argentinos, Matías Katz y Maximiliano Soler, en su charla "Bypassing .htaccess restrictions" (en español, salteando las restricciones de .htaccess). En ella, mostraron y liberaron una herramienta que permitiría aprovechar una vulnerabilidad en la forma en que se configura este servicio, de forma tal de saltear la barrera de seguridad que este brinda.

Para aquellos que no lo conozcan, el .htaccess es un archivo de configuración que permite, sobre servicios web, especificar configuraciones para las carpetas. Uno de los usos más frecuentes es el de limitar el acceso a un sitio con validación de usuario (generalmente contenida en el archivo .htpasswd). De esta forma, cuando el usuario se quiere conectar al sitio web, se solicita una autenticación como protección del o los directorios en el servidor.

No obstante, en la charla se presentó una vulnerabilidad que permitiría poder extraer y descargar localmente en la computadora del atacante todos los archivos detrás de la protección de .htaccess. ¿Cómo es esto posible? Los autores descubrieron una vulnerabilidad en la forma en que .htaccess toma los métodos. Por lo general, un archivo de configuración tradicional contiene estos datos (en la charla se indicó como cientos de sitios web recomiendan utilizar esta configuración):

<Limit GET POST>
require valid-user
</Limit>

No obstante, una vulnerabilidad hace que cuando PHP recibe un método no conocido, este sea tratado como GET, y de esta forma se logra realizar el request sin necesidad de autenticación alguna. Es decir, aunque no es una vulnerabilidad propia del software, sí es un mal manejo que se ve especialmente afectado en forma de vulnerabilidad de configuración.

La charla me resultó interesante ya que, más allá de la investigación, se trata de un ataque que hoy es totalmente factible de realizar contra millones de sitios web en todo el mundo. Es decir, muchas veces las vulnerabilidades presentadas son muy avanzadas desde el punto de vista técnico, muy complejas, pero su aplicación es limitada. No es este el caso, la explotación de esta vulnerabilidad es altamente probable en la mayoría de los sitios web que hoy utilizan .htaccess.

Durante la charla, se presentó el exploit (y HTExploit, la herramienta para automatizar el envío) y se mostró en vivo cómo a pesar de que desde el acceso web no era posible acceder a un directorio, a través de la explotación de la vulnerabilidad se podía acceder a los archivos detrás de esta protección. Entonces, ¿cómo pueden protegerse? Para empezar, vale destacar que si utilizan este servicio es altamente probable que sean vulnerables ya que, como mencionaban los autores durante la charla, en la mayoría de los sitios web se recomienda una configuración que sostiene la vulnerabilidad, es decir, que no se declaren las excepciones a los métodos en el archivo de configuración. Por lo tanto, aquí están las soluciones para dejar de ser vulnerables:

  • La forma más sencilla es modificar cómo se utiliza el archivo de configuración, restringiendo todos los métodos HTTP menos los indicados, con el uso de LimitExcept, como se especifica aquí:
    <LimitExcept GET POST>
    Order Allow,Deny
    Deny from all
    </LimitExcept>
  • También es posible limitar un ataque de este tipo a través de PHP, chequeando si la variable $PHP_AUTH_USER está seteada o mostrando un mensaje de error cuando $_SERVER["REQUEST_METHOD"] utiliza un método que no sea GET o POST.

Asimismo, vale recalcar que más allá de la funcionalidad de .htaccess, es importante destacar que en sitios web donde se deseen mecanismos de autenticación, este no debería ser (al menos el único) utilizado, sino otros mecanismos de validación de usuario más avanzados.

Felicitaciones a Matías y Maximiliano por la investigación, en los próximos días seguiremos informando sobre charlas, vulnerabilidades y consejos de seguridad a partir de las charlas de la Black Hat y la Defcon 2012.

Sebastián Bortnik
Gerente de Educación y Servicios

mostrando en esos casos un mensaje de error