Web App Hacking con RFI, LFI y RCE

Web Applications
Hacking and
Penetration Testing
Jose Antonio Gonzales Jurado > e-mail: jgonzalesjurado@gmail.com

Agenda
 Ejecución de Comandos + RFI.
 Ejecución de Código con LFI + RCE.
 Mitigación / Referencias.

Whoami:
Egresado en Redes y Comunicaciones de Datos
Instituto: Grupo IDAT.
Especialidad: Me desempeño como Security Analyst & Pentester.
Experimentado desarrollador de escenarios de Ofensiva & Defensiva para
pruebas de concepto. Implementador de servicios de Networking y
Telecomunicaciones.
Tengo experiencia en el Mercado de la Tecnologías de Seguridad, Gestión
y Análisis Múltiples amenazas que afectan al orden Mundial.
Experiencia en Multi-Plataformas de Seguridad ya sean SIEM / Firewall /
Balanceadores / Anti-Virus / Wireless / Layer 2 & Layer 3 / IDS-IPS y etc.

Ejecución de Comandos & RFI
(Demo)

• La inyección de comandos es un ataque en el que el objetivo es la ejecución de comandos
arbitrarios en el sistema operativo host a través de una aplicación vulnerable.
• Los ataques de inyección de comandos son posibles cuando una aplicación pasa datos no
seguros provistos por el usuario (formularios, cookies, encabezados HTTP, etc.) a un shell del
sistema. En este ataque, los comandos del sistema operativo suministrados por el atacante
generalmente se ejecutan con los privilegios de la aplicación vulnerable. Los ataques de
inyección de comandos son posibles en gran parte debido a una validación de entrada
insuficiente.
• Este ataque difiere de la inyección de código, ya que la inyección de código permite al atacante
agregar su propio código que luego ejecuta la aplicación. En la inyección de comandos, el
atacante amplía la funcionalidad predeterminada de la aplicación, que ejecuta los comandos
del sistema, sin la necesidad de inyectar código.
Ejecución de Comandos

Inclusion de Archivos Remotos
(RFI)
• RFI (Remote File Inclusion): Permite cargar en el servidor código que se encuentra en
otro servidor.
 Normalmente se utiliza para subir una WebShell y tomar el control del servidor.
 Es complicado encontrar este tipo de vulnerabilidades, ya que se necesita que se den
una serie de condiciones.
 Para explotarlo únicamente sería necesario cargar la url donde se encuentre la
WebShell, siempre en txt debido a que si no se ejecutaría en nuestro servidor.

Descripción Gráfica

Identificar el tipo de Aplicación
• Lo principal que se debe hacer primero es identificar los tipos de aplicaciones que están
dirigidas. Tener la mayor cantidad de información posible aumentará nuestras
posibilidades de encontrar vulnerabilidades o debilidades en la aplicación. Por ejemplo,
después de saber que el objetivo utiliza la aplicación de inicio de sesión de archivo de
texto simple, usamos Google para averiguar si hay publicaciones que expliquen las
vulnerabilidades en la aplicación. La siguiente alternativa para detectar vulnerabilidades
es hacer un código fuente de revisión y, por supuesto, esta no es la opción principal
porque el proceso llevará mucho tiempo.

• Ejecute Burp Suite desde linux (máquina atacante). Asegúrese de que la opción de proxy intercepte
la solicitud del cliente y la respuesta del servidor.
• Abra su navegador y luego asegúrese de que la configuración del proxy apunta a localhost con el
puerto 8080.
• Acceda a la aplicación a través de su navegador escribiendo la dirección IP de destino http :
// target - ip / admin y asegúrese de reenviar todas las solicitudes y respuestas.
• Después de eso, ingrese su nombre de usuario y contraseña (no necesariamente válidos) para ver
los datos de solicitud y respuesta.
• Preste atención a los resultados que aparecen en la suite de burp de destino -> Site map->
Wordpress -> wp-login.php -> log=….

• Abra Google con la palabra clave log=admin&pwd para averiguar qué tipo de aplicación está
ejecutando el objetivo. Los siguientes resultados son dados por Google

• En primera instancia para hacerlo mas interesante vamos a autenticarnos con el black-
user que generamos en la anterior demostración de Vuln CSRF-Tester.
(Demo)

• Una vez que esté dentro del panel de
administración, haga clic en “Appearance” desde el
panel y luego seleccione “Theme Editor”.
(Demo)

• En el siguiente mensaje le damos click en “I understand”.
(Demo)

• Ahora seleccione la plantilla archive.php dada en el lado derecho del marco; después de
eso, encontrarás algún código php en el cuadro medio para el template de archive. Borre
todo el código php para que pueda agregar código PHP malicioso para generar puerta
trasera dentro del sitio web como un nuevo tema.
(Demo)

(Demo)

• Ahora vamos a descargar el siguiente Script, que abrirá una conexión TCP saliente desde el
servidor Web hacia el host Atacante mediante el puerto que le agregamos como Listener.
• Enlace: http://pentestmonkey.net/tools/web-shells/php-reverse-shell
(Demo)

• Abrimos el script, y modificamos los siguientes datos de entrada para nuestra Shell interactiva.
(Demo)

• Ahora procedemos a cargar el
Script que agregamos como un
nuevo tema.
(Demo)

• Cuando ejecutes el tema cargado archive.php en el otra pestaña del navegador,
recibirás una conexión reversa por nc y obtendrás una sesión de medición del
sistema de la víctima. Por lo tanto tenemos que colocar la siguiente ruta en nuestro
navegador.
• 192.168.42.162/wordpress/wp-content/themes/twentythirteen/archive.php
(Demo)

• Una vez que cargue el Script modificado en la página, se verá que el Netcat se
conecta a un Shell interactiva.
(Demo)

• A continuación, si deseamos actualizar a una Shell TTY totalmente interactiva, podremos utilizar el siguiente
comando.
(Demo)

Execución de Código
con LFI + RCE
(Demo)

• LFI: Nos permite acceder a los ficheros del servidor de
carácter privado. Para ello normalmente se hace uso
del Path Transversal, que es una técnica para ir
saltando de directorio.
• El atacante abusa de una función de carga de archivos
para cargar un script malicioso.
• El script se ejecuta y permite futuros ataques.
 Webshell.
Execución de Código con LFI + RCE
(Demo)

¿Que Peligrosa es esta Vulnerabilidad?
RFI / LFI
• El peligro de esta vulnerabilidad es que si esta
presente en un Site Web, un atacante podría leer
información sensible, ejecutar comandos, obtener
una conexión inversa y de esta manera controlar al
servidor, etc. A continuación se mostrará parte de
un código PHP vulnerable.

• En primera instancia, nos mantendremos en el Target por nc, y desde nuestra maquina
atacante vamos a subir el script malicioso que nos permitirá acceder a los ficheros del
servidor web.
(Demo)

• Para copiar un archivo de un sistema local a un sistema remoto, ejecute el siguiente
comando.
(Demo)

• Ahora procedemos a ingresar a la siguiente ruta,
para poder crear un directorio llamado “LFI”, dentro
del directorio procedemos a pegar el fichero
“lfi.php”.
• Este proceso lo vamos hacer mediante SSH desde la
maquina atacante hacia el target.
(Demo)

(Demo)

• Desde que agregamos un archivo php con función de inclusión dentro de /var/www/html,
nos va permitir leer el contenido de otro archivo a través de él y puede llevar a un ataque LFI.
Vamos a demostrarlo explorando la siguiente URL para leer los archivos de contraseña.
• http://192.168.42.162/lfi/lfi.php?file=/etc/passwd
(Demo)

• Ahora intentaré abrir el archivo access.log a través de lfi.php en el navegador, por lo
tanto, le doy permiso de lectura y escritura a al directorio de apache2 y luego incluiré el
archivo access.log.
(Demo)

• Ahora incluya el archivo acess.log como parámetro y proporcione la siguiente URL dentro del navegador. En la
siguiente imagen podemos ver los registros de acceso que muestra el servidor apache, en este caso serian las
solicitudes entrantes y todas las solicitudes procesadas.
(Demo)

• También podemos visualizar las solicitudes entrantes del fichero access.log mediante el
Terminal del atacante aplicando lo siguiente.
(Demo)

• Para mejorar las gráficas, usaré Burp Suite para interceptar, modificar y analizar las
solicitudes. Una vez más, aquí está cómo se ve cuando se intenta incluir el archivo de
entorno.
(Demo)

• Listo, ya teniendo claro lo anterior vamos a proceder a obtener los siguientes datos,
aplicando URL Codificación.
• Codificación URL Ctrl + U: Hostname
(Demo)

• Codificación URL Ctrl + U: Ping
(Demo)

• Codificación hacia los archivos de contraseñas ocultas.
• Ctrl + U: /etc/passwd
(Demo)

• La técnica que vamos a examinar primero es el método más común utilizado para
obtener una shell de un LFI. El archivo ubicado en /lfi/lfi.php contiene varias variables de
entorno como REMOTE_PORT , HTTP_USER_AGENT y más. Para la mayoría de los
sistemas operativos Linux, el archivo no debe ser accesible desde usuarios no root. Esta
es la razón por la que esta técnica es antigua y en los sistemas actualizados, podría no
funcionará.
(Demo)

• En primera instancia vamos a cargar la siguiente Shell Reversa usando Python. Pero lo mas importante es
seleccionar desde python asta la comilla final, después Ctrl + U y lo ultimo cambiamos el Request “GET”
por “POST” y “Go”.
(Demo)

• Al escuchar en el puerto 9999 podemos ver que se ha recibido un Shell interactiva.
(Demo)

• Por ultimo, si queremos analizar los logs de acceso que se registraron cuando cargamos
el LFI + RCE, desde el Target vamos aplicar el siguiente comando.
(Demo)

Recomendaciones

Recomendaciones
• La gran mayoría de fallos vistos se podrían evitar si desde un principio se hubieran
implementado medidas de seguridad, normalmente con un correcto tratamiento de
todos aquellos input es suficiente.
• Daremos una solución sencilla pero efectiva a los ataques vistos (SQLi, XSS, RFI/LFI).
• Como por ejemplo, si se espera un numero, utilizar funciones como isint en php,
evitando que se introduzca otra cosa.
• Aunque para asegurar realmente una aplicación a “prueba de bombas” suele ser muy
efectivo un WAF.

• Inyección SQL:
 Transformar todo a ascii (evitando caracteres en hex.).
 Utilización de funciones propias del servidor para securizar las consultas (php+mysql
como mysql_real_query, etc…).
 Realizar un filtrado de las palabras:
And, or, union, select, concat, group, from, where, sleep, etc…
Recomendaciones

• Secuencias de Comandos entre Sitios (XSS):
 Utilizar funciones propias del lenguaje como: html_entities.
 Además realizar un filtrado tanto de comentarios como de caracteres especiales.
 Dejar todo en minúsculas o mayúsculas.
Recomendaciones

• Ejecución de Comandos + RFI / LFI:
 Desactivar características del servidor web como:
allow_url_fopen
allow_url_include
 Estas características evitan que un atacante pueda incluir archivos tanto remotos
como locales.
 Evitar el uso de ciertas funciones como:
Include
Require
Require_once…
Recomendaciones

• Falsificación de Solicitud de Sitios Cruzados (CSRF).
 La única forma efectiva de hacerlo es mediante tokens (valores aleatorios) generados por
la aplicación y anexados al formulario que muestra la aplicación, luego si al procesar los
valores del formulario, el token que se recibe corresponde al token de la aplicación, eso
significa que la petición es auténtica.
Recomendaciones

Referencias

• RFI / LFI:
https://www.welivesecurity.com/la-es/2015/01/12/como-funciona-vulnerabilidad-local-file-
inclusion/
https://www.imperva.com/learn/application-security/rfi-remote-file-
inclusion/?utm_campaign=Incapsula-moved
https://liberty-shell.com/sec/2018/04/04/lfi/
Referencias / RFI & LFI

• Ejecución de Código con LFI + RCE:
https://resources.infosecinstitute.com/local-file-inclusion-code-execution/#gref
https://highon.coffee/blog/reverse-shell-cheat-sheet/
https://outpost24.com/blog/from-local-file-inclusion-to-remote-code-execution-part-1
Referencias / LFI & RCE

Gracias 

Web App Hacking con RFI, LFI y RCE

Recomendados

Recomendados

Más contenido relacionado

Similar a Web App Hacking con RFI, LFI y RCE

Similar a Web App Hacking con RFI, LFI y RCE (20)

Último

Último (20)

Web App Hacking con RFI, LFI y RCE