Usar Google para descubrir sitos webs con bugs de LFI

Años después, cuando sigo mostrando los sitios defaceados en tiempo real en Zone-h, la gente sigue preguntándome cómo es posible que alguien sea capaz de hacer esos ataques en tanto sitios. No hay ninguna trampa, solo experiencia y técnicas. Lo cierto es que en muchos de esos ataques hay un proceso de automatización basado en el descubrimiento de sitios vulnerables a un determinado fallo o exploit. Es decir, se tiene un exploit para un determinado CMS o Framework de Internet y se automatiza el descubrimiento de servidores con ese software afectado y la explotación del fallo. Por eso hay que tomar medidas de fortificación en los frameworks más populares como Joomla!, WordPress, y similares, ya que cuando se publica un nuevo bug para ellos, se explota de forma automatizada masivamente.

Figura 1: Los sitios defaceados y reportados esta mañana

En otras ocasiones se utilizan herramientas de escaneo automático en busca de vulnerabilidades explotables de SQL Injection, Command Injection, Remote File Inclusion, Métodos Put inseguros o Local File Inclusion, que serán las que más juego den a la hora de subir una Web Shell o meter un fichero para hacer un defacement.

Para localizar las posibles víctimas, desde hace ya muchos años se utilizan los buscadores, que permiten localizar mediante lo que se llamaron "dorks", a los que tienen una determinada característica que denota su vulnerabilidad. Esto se ha utilizado ya en ataques masivos para distribuir malware, buscando fallos de SQL Injection de forma masiva en Google y automatizando la inyección de scripts mediante sentencias Update, como se explica en el libro de Fraude Online. En alguna de ellas llegando a afectar a sitios como la propia Apple.

Saber jugar bien con Bing Hacking, Google Hacking, Shodan, Archive o Robtex es parte fundamental para los defacers, los pentesters, los analistas de seguridad y los investigadores. En el libro de Hacking con Buscadores Enrique Rando cuenta algunos trucos muy interesantes de Google, y explica en detalle cómo utilizar los comodines para localizar objetivos concretos, algo que todos los perfiles citados anteriormente utilizan en algún momento.

Yo uso los buscadores en infinidad de ocasiones para todo tipo de cosas, como para localizar centralitas de VoIP a través de Shodan, localizar sitios vulnerables a HeartBleed por puertos no habituales o para encontrar ficheros ICA usando el operador contains de Bing. Por poner algunos ejemplos de los muchos artículos en los que me han venido.

Por poner un ejemplo de cómo teniendo control de los buscadores se puede sacar petróleo, alguien podría utilizar los comodines para poder localizar sitios vulnerables a LFI (Local File Inclusion). En estas vulnerabilidades lo que se trata de poder acceder a ficheros locales del servidor manipulando los parámetros de algún programa que accede al sistema de archivos donde corre la aplicación web y normalmente se encuentran de dos tipos.

Generalmente las vulnerabilidades más comunes de LFI, llamémoslas de Tipo 1, son ficheros que acceden directamente al sistema de ficheros construyendo la ruta de acceso con algún parámetro que se les pasa desde la URL. Se localizan porque alguno de los parámetros es el nombre de un fichero "loquesea.pdf", lo que atrae la atención del pentester para hacer algunas pruebas, como las que puedes ver en este post de "descubrir un LFI al estilo FOCA" que nosotros automatizamos en nuestro servicio de pentesting persistente Faast.

Figura 2: Descargando el fichero que descarga

Si se descubre el bug, que generalmente se hace intentando descargar el propio fichero que realiza la descarga de los ficheros, basta con introducir la ruta absoluta o relativa,  según sea cada programa de descargas - en el de la Figura 2 se puede ver que es una ruta absoluta cuando el parámetro que se usa es "fichero" y relativa cuando el parámetro que se usa es "serie" -, para pedir el fichero que se desea obtener del servidor.

Figura 3: Un LFI en una web para acceder a /etc/passwd con ruta absoluta

En otras ocasiones, las que llamaremos de Tipo 2,  no viene ningún nombre de fichero como parámetro, pero el nombre de la aplicación es algo como "descargarfichero.php" o el nombre del parámetro es "fichero=identificador", lo que indica que probablemente con ese parámetro se esté accediendo a una tabla en una base de datos - o un fichero XML que sería otra historia de XPath Injection - de la que se está recuperando o el nombre o la ruta completa del fichero. En esos casos hay que hacer un ataque de SQL Injection buscando inyectar la ruta del fichero buscado.

Es decir, en una aplicación en la que apareciera algo como fichero=23, y en la que el programador generase una consulta para acceder a la ubicación donde se almacena el fichero de forma similar a esto:

$SQLCommand="Select ruta from ficheros where id="+$_GET["fichero"]+";"; 

Lo que se debería hacer el algo como:

fichero=-1 union Select '/etc/passwd'

En cada motor de base de datos y en cada aplicación programada habría que ver cómo ajustar la cadena de inyección, pero en regla general sería algo así, pero eso es otra historia para otro libro.

Para las vulnerabilidades del Tipo 1 - que es lo que os venía a contar en esta historia - como en Google se pueden usar los comodines y el truco de la barra para jugar con las búsquedas, se pueden hacer dorks para localizar aquellas URLs que cumplan una serie de condiciones, por ejemplo que tengan la palabra php file y pdf con un patrón, o que sea lo mismo pero en Español.

Figura 4: Muchos resultados para jugar y probar

Figura 5: Miles de ellos en Español

Al final, estos dorks - dale al enlace de "Mostrar más resultados" - muestran una cantidad de sitios que cumplen esa estructura en su URL y que para cualquier herramienta automatizada para la búsqueda de bugs de LFI siguiendo unos patrones será fácil explotar.

Saludos Malignos!