Local File Injection (LFI) es un error muy típico en aplicaciones web mal parcheadas, como por ejemplo apaches viejos. En este artículo, le vamos a dar un repaso a un caso muy común de LFI (muy de moda hace un par de años) y, de paso, veremos un ejemplo real de una web que todavía, a día de hoy, tiene dicho fallo.
2.- Como Funciona el LFI
Pueden escribirse ríos de tinta explicando los distintos casos de LFI que nos podemos encontrar pero, basicamente, se reduce a abusar un formulario para presentar páginas web de una aplicación web mal configurada, que permite leer archivos del sistema.
Supongamos que nuestra web es http://www.miweb.com/cgi-bin/jobs/page.pl?page=. En principio, el programador de la web ha pensado que page.pl va a ser llamado para presentar información de distintos artículos de la web. Sin embargo, nosotros podemos intentar llamar a http://www.miweb.com/cgi-bin/jobs/page.pl?page=/etc/passwd.
¿Por qué sucede esto? Sucede porque el servidor apache que corre está mal configurado. Debería haberse restringido el acceso al directorio raiz dentro del httpd.conf, pero el admin ha dejado la configuración por defecto y nos ha dado permiso para recorrer todo el sistema de archivos, y esto es lo que sucede ...
Por supuesto, este error de configuración de un apache no lo vamos a encontrar en una empresa con cierto grado de seguridad, al menos no en la DMZ (en la intranet es otra cosa).
3. QUÉ BUSCAMOS.
Una vez que hemos entendido cómo funciona, ahora necesitamos saber qué debemos intentar leer.
Si os fijáis, en el ejemplo anterior hemos añadido un carácter nulo al final de la URL. Esto es porque algunos servidores web viejos dan el código fuente si se le mete un null char al final de la URL, como es el caso. Pero puede suceder que no sea necesario añadir esto.
Por otro lado, veréis que hemos puesto varios /../ antes del/proc/version final. Esto es porque tenemos que ir subiendo de directorio hasta alcanzar el raiz. El número de veces que tengamos que subir dependerá de la configuración particular del servidor web al que nos enfrentemos.
Dicho esto, algunas cosas que podemos buscar son:
/etc/passwd
/etc/shadow
/etc/group
/etc/my.cnf
/etc/hosts
/etc/hostname
/etc/resolv.conf
/proc/version
/proc/cpuinfo
/etc/passwd
/etc/group
/var/log/messages
/var/log/maillog
/usr/local/apache/logs/access_log
/usr/local/apache/logs/access.log
/etc/apache2/conf/httpd.conf
/etc/named.conf
/etc/vsftpd/vsftpd.conf
/etc/ssh/sshd_conf
...
Aparte, miraremos también todos los anteriores pero con la extensión .old, .bak, .rar., .gz ... ya que es bastante común que los administradores hagan copias de seguridad de archivos importantes y estas, por defecto, tienen permisos de lectura para "others".
Y aquí lo voy a dejar, dado que ni mucho menos pretendo ser exhaustivo. Pero lo que si debemos tener en cuenta es que siempre añadiremos nuestros /../ para ir al raiz, como hemos hecho arriba, y que debemos intentar tanto añadiendo el null char como sin él, ambos casos.
Análogamente, podríamos construir una lista de archivos importantes para windows que deberíamos examinar en caso de tener una vulnerabilidad similar disponible.
3. CONCLUSIÓN.
De nuevo, un pequeño fallo de seguridad en la configuración del apache ha dejado todo el sistema al descubierto. Este fallo, como hemos comentado, rara vez lo encontraremos en la DMZ, pero no es tan complicado encontrarlo en la intranet de una empresa, donde los administradores son más descuidados y donde las auditorías de seguridad brillan por su ausencia.
Una vez que hemos entendido cómo funciona, ahora necesitamos saber qué debemos intentar leer.
Si os fijáis, en el ejemplo anterior hemos añadido un carácter nulo al final de la URL. Esto es porque algunos servidores web viejos dan el código fuente si se le mete un null char al final de la URL, como es el caso. Pero puede suceder que no sea necesario añadir esto.
Por otro lado, veréis que hemos puesto varios /../ antes del/proc/version final. Esto es porque tenemos que ir subiendo de directorio hasta alcanzar el raiz. El número de veces que tengamos que subir dependerá de la configuración particular del servidor web al que nos enfrentemos.
Dicho esto, algunas cosas que podemos buscar son:
/etc/passwd
/etc/shadow
/etc/group
/etc/my.cnf
/etc/hosts
/etc/hostname
/etc/resolv.conf
/proc/version
/proc/cpuinfo
/etc/passwd
/etc/group
/var/log/messages
/var/log/maillog
/usr/local/apache/logs/access_log
/usr/local/apache/logs/access.log
/etc/apache2/conf/httpd.conf
/etc/named.conf
/etc/vsftpd/vsftpd.conf
/etc/ssh/sshd_conf
...
Aparte, miraremos también todos los anteriores pero con la extensión .old, .bak, .rar., .gz ... ya que es bastante común que los administradores hagan copias de seguridad de archivos importantes y estas, por defecto, tienen permisos de lectura para "others".
Y aquí lo voy a dejar, dado que ni mucho menos pretendo ser exhaustivo. Pero lo que si debemos tener en cuenta es que siempre añadiremos nuestros /../ para ir al raiz, como hemos hecho arriba, y que debemos intentar tanto añadiendo el null char como sin él, ambos casos.
Análogamente, podríamos construir una lista de archivos importantes para windows que deberíamos examinar en caso de tener una vulnerabilidad similar disponible.
3. CONCLUSIÓN.
De nuevo, un pequeño fallo de seguridad en la configuración del apache ha dejado todo el sistema al descubierto. Este fallo, como hemos comentado, rara vez lo encontraremos en la DMZ, pero no es tan complicado encontrarlo en la intranet de una empresa, donde los administradores son más descuidados y donde las auditorías de seguridad brillan por su ausencia.
Saludos
Dr.White
Fuente: hacking-Avanzado
No hay comentarios:
Publicar un comentario