Curiosidades De Hackers: enero 2024

Insecure Direct Object Reference (IDORs): Prueba de Concepto y Explicación

   Las Insecure Direct Object References (IDOR) son un tipo de vulnerabilidad de seguridad que se presenta cuando una aplicación web emplea identificadores internos (como números o nombres) para identificar y acceder a recursos, como archivos o datos, sin validar adecuadamente la autorización del usuario para acceder a ellos.

   Por ejemplo, si una aplicación web utiliza un identificador numérico para identificar un registro en una base de datos, un atacante puede intentar adivinar este identificador y acceder a los registros sin la debida autorización. Esto puede permitir a los atacantes acceder a información confidencial, modificar datos, crear cuentas de usuario no autorizadas y realizar otras acciones maliciosas.

   La vulnerabilidad IDOR puede surgir cuando una aplicación web no implementa controles de acceso adecuados para los recursos que gestiona. Por ejemplo, una aplicación puede validar el acceso mediante autenticación y autorización para los recursos que se muestran en la interfaz de usuario, pero no aplicar la misma validación para los recursos que se acceden directamente a través de una URL.

   Para explotar una vulnerabilidad IDOR, un atacante puede intentar modificar manualmente el identificador de un objeto en la URL o utilizar una herramienta automatizada para probar diferentes valores. Si el atacante encuentra un identificador que le permite acceder a un recurso que no debería estar disponible, entonces la vulnerabilidad IDOR se ha explotado con éxito.

   Por ejemplo, supongamos que un usuario 'A' tiene un pedido con el identificador numérico 123 y el usuario 'B' tiene un pedido con el identificador numérico 124. Si el atacante intenta acceder a través de la URL "https://example.com/orders/124", la aplicación web podría permitir el acceso a ese pedido sin validar si el usuario tiene permiso para acceder a él. De esta manera, el atacante podría acceder al pedido del usuario 'B' sin la debida autorización.

   Para prevenir la vulnerabilidad IDOR, es crucial validar adecuadamente la autorización del usuario para acceder a los recursos, tanto en la interfaz de usuario como en las solicitudes directas a través de URL. Además, se recomienda restringir los permisos de acceso a los recursos y mantener actualizado el software y los sistemas operativos.

Veamos un ejemplo:

http://ejemplo.com/pagina?documento=12345

En este caso, el valor del parámetro "documento" se utiliza como índice en una tabla de documentos en la base de datos. La aplicación toma el valor de este parámetro y lo utiliza en una consulta a la base de datos. Luego, la aplicación devuelve la información de la factura al usuario.

Dado que el valor de "documento" entra directamente en la consulta, al modificar el valor del parámetro es posible recuperar cualquier docuemnto, independientemente del usuario al que pertenezca la factura.

PoC

Para la prueba de concepto utilizaremos el laboratorio de Skf-labs IDOR.

La aplicación permite al usuario crear un archivo PDF y recuperar el archivo con el identificador que se le asigna:

Intentamos acceder aleatoriamente con el identificador 4000 para forzar que nos de un documento y nos indica que solo hay identificadores del 1-1500.

Para explotar e intentar acceder a otros documentos indexados, usaremos burpsuite que nos ayudaría a automatizar la tarea de borrar. Aunque mas adelante veremos con hacerlo con Wfuzz.

Preparamos el ataque con numero del 1 al 1500 y vamos viendo la longitud de respuesta.

Entonces, a partir de los resultados de la prueba de fuzzing, si observamos de cerca, el ID de índice "1612" parece interesante, ya que los otros ID parecen tener la misma longitud de respuesta. Vamos a verificar qué logramos con ID=356.

Hemos podido acceder al documento perteneciente a algún otro usuario eludiendo los controles de acceso de la aplicación.

De la misma manera lo podemos hacer mediante Wfuzz inficando con FUZZ donde queremos que haga fuzzing.

Eliminamos los chars que se repiten hasta que nos salga el resultado esperado.

Y como vemos nos arroja 3 documentos creados previamente por usuarios, incluido el que he creado yo, el 356.

Vulnerabilidad de Contaminación de Prototipo(Prototype Pollution): Prueba de Concepto y Explicación

   La técnica de ataque conocida como Prototype Pollution se vale de debilidades presentes en la forma en que se implementan los objetos en JavaScript. Este método se emplea para alterar la propiedad "prototype" de un objeto en una aplicación web, brindando al atacante la capacidad de ejecutar código malicioso o manipular la información de la aplicación.

   En el contexto de JavaScript, la propiedad "prototype" se utiliza para definir las características y funciones de un objeto. Los atacantes aprovechan esta particularidad del lenguaje para modificar las características y funciones de un objeto, logrando así tomar el control de la aplicación.

   El ataque de Prototype Pollution se materializa cuando un atacante altera la propiedad "prototype" de un objeto en una aplicación web. Este acto puede llevarse a cabo manipulando datos transmitidos mediante formularios o solicitudes AJAX, o introduciendo código malicioso en el código JavaScript de la aplicación.

   Una vez que el objeto ha sido manipulado, el atacante puede ejecutar código malicioso en la aplicación, manipular datos o incluso tomar el control de la sesión de un usuario. Un ejemplo ilustrativo sería la modificación de la propiedad "prototype" de un objeto de autenticación de usuario para permitir el acceso a una cuenta sin requerir una contraseña.

   Las consecuencias de la explotación del ataque Prototype Pollution pueden ser graves, ya que los atacantes pueden asumir el control de la aplicación o comprometer los datos de los usuarios. Además, debido a que este tipo de ataque se basa en vulnerabilidades en la implementación de objetos en JavaScript, su detección y corrección pueden resultar desafiantes.

JavaScript está basado en prototipos: cuando se crean nuevos objetos, se transfieren las propiedades y los métodos del prototipo "object", que contiene funcionalidades básicas como toString, constructor y hasOwnProperty.

   La herencia basada en objetos le otorga a JavaScript la flexibilidad y eficiencia que los programadores web han apreciado, pero también lo hace vulnerable a la manipulación.

   Los actores maliciosos pueden realizar cambios en toda la aplicación de todos los objetos modificando el objeto, de ahí el nombre de "contaminación prototipo".

   Curiosamente, los atacantes ni siquiera necesitan modificar directamente el objeto; pueden acceder a él a través de la propiedad __proto__ de cualquier objeto JavaScript. Y una vez que realizan un cambio en el objeto, este se aplica a todos los objetos JavaScript en una aplicación en ejecución, incluidos los creados después de la manipulación.

PoC

Para esta prueba de concepto utilizaremo el siguiente laboratorio: SKF-LABS Prototype Pollution

Abrimos la aplicación, tenemos el panel de resgitro:

Vemos que este usuario no tiene privilegios de administrador y también podemos enviar un mensaje a un administrador.

Si echamos un vistazo al código, vemos que cuando somos admin la propiedad esta en "true", en cambio cuando no pone "false"

Utilizamos el panel que nos da para enviar un mensaje al administrador interceptándolo con burpsuite

La idea es tratar de llegar a ser admin viendo que almacena como objeto.

La operación merge itera a través del objeto de origen y agregará cualquier propiedad que esté presente en él al objeto de destino.

Todo lo que tenemos que hacer para modificar su prototipo es proporcionarle datos JSON que tienen el __proto__ como propiedad. Una carga útil común se verá así:

Si pasamos esta carga útil a la operación de merge sin sanitizar los campos, contaminará/moficara completamente los prototipos de objetos.

Interceptamos la petición de envió de correo

Cambiamos la estructura a JSON y lo acepta

Modificamos y al no tener una propiedad, nuestro usuario la va a heredar, contaminamos el prototipo proporcionando datos JSON como explicamos antes en la propiedad __proto__

Y conseguimos hacernos administrador

Si creamos otro usuario vemos que el nuevo usuario también tendrá admin establecido en True.

¿Cuál es la solución?

Si está utilizando una operación vulnerable como la operación de merge que vimos anteriormente, puede solucionarla simplemente evitándola si el nombre de la clave es ___proto___ como el siguiente código.

Ataque de oráculo de relleno (Padding Oracle): Explicación y ejemplos.

   Un ataque de oráculo de relleno (Padding Oracle Attack) es un tipo de ataque dirigido a datos cifrados que permite al atacante descifrar el contenido sin tener acceso a la clave correspondiente.

   El concepto de "oráculo" se refiere a un "indicador" que proporciona al atacante información sobre la validez de la acción realizada.

   La noción de relleno tiene relevancia en el ámbito criptográfico. Algunos algoritmos de cifrado, que son esenciales para cifrar datos, operan en bloques de datos con tamaños predefinidos. Si los datos que deseas cifrar no cumplen con el tamaño adecuado para llenar estos bloques, se procede a su relleno automático hasta alcanzar el tamaño requerido. Muchos métodos de relleno exigen que este esté presente siempre, inclusive si la entrada original ya tiene el tamaño adecuado. Esto garantiza la eliminación segura del relleno durante el proceso de descifrado.

   Al combinar ambos elementos, la implementación de software con un oráculo de relleno revela si los datos descifrados poseen un relleno válido. El oráculo podría ser tan sencillo como emitir un valor que indique "Relleno no válido" o, en su lugar, algo más complejo, como tomar un tiempo sustancialmente distinto para procesar un bloque válido en comparación con uno no válido.

   Los cifrados basados en bloques también incluyen otra característica denominada "modo", que establece la relación entre los datos del primer bloque y los del segundo, y así sucesivamente. Uno de los modos más comunes es CBC. En CBC, se utiliza un bloque inicial aleatorio llamado "vector de inicialización", que se mezcla con el bloque anterior y el resultado del cifrado estático, evitando que cifrar el mismo mensaje con la misma clave genere siempre la misma salida cifrada.

   Un atacante puede aprovechar un oráculo de relleno junto con la estructura de datos CBC para enviar mensajes ligeramente alterados al código que expone el oráculo y seguir enviando datos hasta que el oráculo indique su corrección. A partir de esta respuesta, el atacante puede descifrar el mensaje byte a byte.

   Aunque el ataque de oráculo de relleno pueda parecer intrincado, ya que implica un proceso iterativo para adivinar el contenido cifrado y modificar el relleno, existen herramientas como PadBuster que pueden automatizar gran parte de este procedimiento.

CIPHER BLOCK CHAINING

CBC es un modo de cifrado en el que el mensaje se divide en bloques de longitud de X bytes y cada bloque se XORed con el bloque cifrado anterior. El resultado se cifra entonces.

Durante el descifrado, se usa la operación inversa. Los datos cifrados se dividen en bloques de bytes X. Luego, el bloque se descifra y se XOR con el bloque cifrado anterior para obtener el texto claro. El siguiente esquema destaca este comportamiento:

PADDING

El cifrado se realiza mediante bloques de tamaño fijo. Para garantizar que el texto claro se ajuste exactamente en uno o múltiples bloques, a menudo se usa relleno. El relleno se puede hacer de múltiples maneras. Una forma común es usar PKCS7. Con PKCS7, el relleno se compondrá del mismo número: el número de bytes que faltan. Por ejemplo, si al texto claro le faltan 2 bytes, el relleno será '\x02\x02'.

PKCS7 es el mecanismo que se utiliza para cifrar el texto, cuando cada cubo al expandirlo no lega a 7 bytes se rellena con \x02 en el caso de que falten dos bloques o 0x03 si faltan 3, esto es llamada como padding:

PADDING ORACLE(ORÁCULO DE RELLENO)

Cuando una aplicación descifra datos cifrados, primero descifrará los datos; luego eliminará el relleno. Durante la limpieza del relleno, si un relleno no válido desencadena un comportamiento detectable, tiene un oráculo de relleno. El comportamiento detectable puede ser un error, una falta de resultados o una respuesta más lenta.

Si puede detectar este comportamiento, puede descifrar los datos cifrados e incluso volver a cifrar el texto claro de su elección.

Si nos acercamos, podemos ver que el byte en texto claro 'C15' es solo un XOR entre el byte cifrado 'E7' del bloque anterior, y byte 'I15' que salió del paso de descifrado de bloques:

En el proceso de descifrado tendrías el texto correspondiente totalmente descifrado con esta técnica llamada XOR, para llegar al texto claro si tienes a nivel de texto claro tienes esta longitud de tamaño, esto se computa utilizando del bloque cifrado el bloque E7 con la parte intermediaria que a sido descifrada que es i15, te daría en el texto claro el bloque C15 como se muestra en los ejemplos

Esto también es válido para todos los otros bytes:

- 'C14 = I14 ^ E6'

- 'C13 = I13 ^ E5'

- 'C12 = I12 ^ E4'

Ahora, si modificamos E7 y seguimos cambiando su valor, seguiremos obteniendo un relleno no válido. Ya que necesitamos que C15 sea \x01. Sin embargo, hay un valor de E7 que nos dará un relleno válido. Llamémoslo E'7. Con E'7 obtenemos un relleno válido. Y como sabemos que obtenemos un relleno válido, sabemos que C'15 (como en C15 para E'7) es \x01.

\x01 = I15 ^ E'7

Nos da:

I15 = \x01 ^ E'7

Entonces podemos calcular I15.

Como conocemos I15, ahora podemos calcular C15.

C15 = E7 ^ I15 = E7 ^ \x01 ^ E'7

Ahora que tenemos C15, podemos pasar a C14. Primero necesitamos calcular otro E7 (llamémoslo E''7) que nos dé C15 = \x02. Necesitamos hacer esto ya que ahora queremos que el relleno sea \x02\x02. Es realmente simple de calcular usando la propiedad anterior y reemplazando el valor de C15 que queremos (\x02) e I15 ahora sabemos:

E''7 = \x02^I15

Después de E6, para encontrar el valor que nos dé un relleno válido E''6, podemos reutilizar la fórmula:

C14 = I14^E6

Llegar

I14 = \x02^E''6

Una vez que obtengamos I14, podemos calcular C14:

C14 = E6 ^ I14 = E6 ^ \x02 ^ E''6

Usando este método, podemos continuar hasta que descifremos todo el texto cifrado.

PoC

Utilizaremos como laboratorio la maquina Padding Oracle de VulnHub

Al registrarme en una web podemos ver una cookie de sesión que l descifrarla siempre y cuando sea vulnerable a padding attack podríamos ver la cookie en texto claro

PadBuster es una herramienta diseñada para automatizar el proceso de descifrado de mensajes cifrados en modo CBC que utilizan relleno PKCS7. La herramienta permite a los atacantes enviar peticiones HTTP con rellenos maliciosos para determinar si el relleno es válido o no. De esta forma, los atacantes pueden adivinar el contenido cifrado y descifrar todo el mensaje.

Indico '2' donde preguntó ID recomendado.

Ahora al saber esto podemos cifrar una cookie valida para el usuario admín y entrar como usuario admín, cifrando una cookie valida.

Aquí la parte resaltada es nuestro valor cifrado para admin.

Copiamos la nueva cookie y recargamos, pudiendo acceder como admin:

Otra manera similar es haciéndolo mediante fuerza bruta con un ataque byteflipper en burpsuite

Al registrarnos como bdmin la cookie de sesión va a variar muy poco, unos pocos bloques o bytes, lo que podríamos hacer fuerza bruta con burpsuite.

Interceptamos la peticion con burpsuite

Preparamos el ataque

Si no sale, la cookie, la url encadenamos con CTRL SHIFT U y repetimos el proceso o cambiamos el usuario como al principio como "cmin", es ir probando, siempre que estén cerca de admin y que la cookie no tenga símbolos raros, repetimos el ataque

Esperamos hasta que veamos un código de respuesta distinto, hay que tener mucha paciencia hasta que los vemos

Copiamos la cookie, y recargamos la web

Explotación de la Vulnerabilidad de Inyección XML External Entity (XXE)

   Una vulnerabilidad XML External Entity (XXE) Injection es una brecha de seguridad que aprovecha el procesamiento de archivos XML para acceder a recursos a los que normalmente no se debería tener acceso. Esto ocurre cuando un atacante introduce datos XML manipulados en una solicitud, logrando exponer información confidencial o acceder a recursos del sistema, como archivos locales o servicios de red.

   Un ataque XXE implica inyectar entidades XML maliciosas en las solicitudes HTTP. Por ejemplo, un atacante podría usar una entidad XML para apuntar a archivos en el servidor y extraer información sensible, como contraseñas o nombres de usuario.

   La debilidad se presenta cuando un servidor web no valida correctamente la entrada XML, permitiendo que un atacante inyecte entidades maliciosas para acceder a archivos del sistema a los que el servidor tiene acceso. Esto facilita la obtención de datos confidenciales.

   A veces, los ataques XXE no revelan información sensible de inmediato. En estos casos, el atacante puede usar técnicas "a ciegas", como enviar peticiones especialmente diseñadas para conectarse a un Document Type Definition (DTD) externo que valida la estructura del XML y puede hacer referencia a recursos del sistema.

   El enfoque "a ciegas" requiere más tiempo y esfuerzo, pero puede ser efectivo si el atacante tiene cierta información sobre los recursos disponibles en el sistema y busca obtener datos específicos sin levantar sospechas.

   Además, un ataque XXE puede ser utilizado como punto de partida para explotar una vulnerabilidad como un Server-Side Request Forgery (SSRF). Esta técnica permite al atacante escanear puertos internos, normalmente protegidos por un firewall, al inyectar una entidad XML que apunta a direcciones IP o puertos internos en la red del servidor.

   Al explotar con éxito un SSRF, el atacante puede enviar solicitudes HTTP a servicios internos y obtener información sensible o incluso tomar el control de estos servicios.

Usaremos el laboratorio de X XELab para el ejercicio:

Ahora debería tener la aplicación Web vulnerable creada con Docker en la siguiente URL:

"http://localhost:5000"

Nos registramos en la pagina capturándolo con Burpsuite:

Cuando enviamos una solicitud al servidor web vemos que se envía en formato XML, cuando vemos esto podemos intuir una vulnerabilidad de XXE.

Para comenzar, vamos a declarar una entidad interna con DTD, para declararla vamos a usar el siguiente código:

<!DOCTYPE foo [ <!ENTIDAD prueba “ [email protected] ” > ] >

Para usar la entidad solo necesita ejecutar el nombre de la entidad con "&" y ";"

Esta es la inyección XXE más básica, es la inyección de un archivo, en este caso, modificaremos la entidad creada con un wrapper para obtener acceso a un archivo de la máquina victima y finalmente podremos mostrarlo por pantalla gracias al campo de el correo electrónico que, como puede ver, es el que se refleja en la salida. En este caso hemo llamado a la entidad "&Curiosos" (puedes nombrarla como quieras).

El servidor interpreta estas etiquetas como output lo que hayas introducido como input

XXE OOB BLIND

Este caso es un poco especial, hay momentos en los que no permitirá crear entidades o usarlas en el XML. A veces no las muestra y entran en juego las XXE OOB (a ciegas), así que montaremos un servidor con Python y las almacenarías en nuestro equipo.

En ese momento, debemos usar un DTD externo, que puede alojar en una máquina que tenga conexión con la víctima.

Lo primero que hay que hacer es crear un servidor Python con el que podamos recibir los datos y las conexiones, y también sirven para alojar el DTD malicioso que necesitamos para realizar el ataque.

En el caso de que no pueda declarar la entidad con los "%" podría ponerlas de la siguiente manera:

Aquí lo que estamos haciendo es una inyección a ciegas mandándonos el output a nuestro servidor Python

Como atacante vamos a declara un archivo.dtd indicando lo que queremos que haga:

La primera línea del DTD va a ser declarar el archivo que queremos leer, para ello usaremos Base64, esto básicamente convertirá el archivo /etc/passwd a base64 para poder transportarlo fácilmente con peticiones web.

*%es lo mismo % pero en hexadecimal*

Llamamos a la entidad "eval" y "exfil" para que cargue puesto que es una entidad externa, este archivo lo vamos a llamar "curiosidadesdehackers.dtd"

Posteriormente nos va enviar en base64 el output del contenido "/etc/passwd" a nuestro servidor:

Y lo recibimos en base 64 en nuestro servidor en Python, solo falta de decodearlo

Más información en:

• PayloadsAllTheThings

• Hacktricks

Vulnerabilidad Local File Inclusion (LFI); Explicación y PoC

   La vulnerabilidad de seguridad denominada Local File Inclusion (LFI) ocurre cuando una aplicación web no verifica de forma adecuada las entradas de usuario, lo que posibilita que un atacante acceda a archivos locales en el servidor web.

   Los atacantes suelen aprovechar esta vulnerabilidad manipulando los parámetros de entrada de la aplicación web, como las URL o los campos de formulario, utilizando una técnica conocida como "Path Traversal". En este tipo de ataques, los atacantes emplean caracteres especiales y de escape en los parámetros de entrada para navegar por los directorios del servidor web y acceder a archivos en ubicaciones sensibles del sistema.

   Por ejemplo, al incluir "../" en los parámetros de entrada, un atacante puede ascender en la estructura de directorios y acceder a archivos en ubicaciones críticas del sistema.

   Para prevenir estos ataques, es crucial que los desarrolladores validen y filtren adecuadamente las entradas de usuario, restringiendo el acceso a los recursos del sistema y asegurándose de que los archivos solo se incluyan desde ubicaciones permitidas. Además, las empresas deben implementar medidas de seguridad adicionales, como el cifrado de archivos y la restricción del acceso de usuarios no autorizados a los recursos del sistema.

   Además de validar y filtrar adecuadamente las entradas de usuario, así como restringir el acceso a recursos del sistema y asegurar la inclusión de archivos solo desde ubicaciones permitidas, existen otras medidas importantes para prevenir y mitigar los ataques de LFI:

      • Principio de mínimo privilegio: Limitar los privilegios de los usuarios y procesos en el servidor web. Esto implica asignar solo los permisos necesarios para cada usuario o proceso, reduciendo así el impacto en caso de una explotación exitosa de LFI.

• Actualizaciones y parches: Mantener actualizados tanto el software de la aplicación web como el sistema operativo del servidor. Los desarrolladores y administradores deben estar al tanto de las actualizaciones de seguridad y aplicar los parches correspondientes para corregir vulnerabilidades conocidas.

• Auditorías de seguridad: Realizar auditorías regulares de seguridad en el código de la aplicación web y en la configuración del servidor. Estas auditorías pueden identificar posibles puntos débiles y ayudar a implementar medidas preventivas antes de que se produzcan ataques.

• Monitoreo de registros: Establecer sistemas de monitoreo de registros (logs) para detectar actividades sospechosas o intentos de explotación de vulnerabilidades, incluyendo patrones de acceso inusuales a archivos del sistema.

• Protección de acceso a archivos sensibles: Aplicar medidas de protección adicionales, como el uso de listas blancas para restringir explícitamente qué archivos pueden ser accesibles a través de la aplicación web y limitar el acceso a archivos sensibles mediante mecanismos de autenticación y autorización.

• Educación y concienciación: Capacitar a los desarrolladores, administradores y usuarios finales sobre las buenas prácticas de seguridad informática, incluyendo la importancia de validar entradas de usuario y de mantener la seguridad de las aplicaciones web.

Al implementar estas medidas en conjunto con la validación adecuada de entradas de usuario y la restricción de acceso a recursos del sistema, las organizaciones pueden reducir significativamente el riesgo de explotación de la vulnerabilidad de LFI y mejorar la seguridad de sus aplicaciones web.

PoC

Para esta prueba de concepto estaremos utilizando el laboratorio Chain de Vulnyx que iremos retocando para dificultarla

Nada mas entrar en la maquina vamos a probar acceder al archivo "/etc/passwd", de manera que vamos a ir retrocediendo entre directorios "../../../../../etc/passwd"

Como acabamos de ver tenemos la vulnerabilidad LFI presente, de la misma manera podríamos hacerlo fuzzeando

Vamos a intentar vemos si podemos inyectar comando mediante wrappers(filtros).

Este wrapper nos va a convertir en base64 el archivo /etc/passwd, lo importante de esto , es que sabemos que podemos ejecutar comandos

Con la herramienta php filter chain generator que hace cadenas de filtros para poder introducir comandos eludiendo posibles reglas, vamos a indicar que ejecute el comando ls-l mediante php system para que ejecute comandos en el sistema

Ahora añadimos toda esta cadena ;

Y como vemos hemos conseguido listar archivos, si de la misma manera intentamos lanzar una reverse shell;

La cadena se va a alargar tanto que nos va a indicar que la petición es muy larga.

Pero si nos creamos un archivo con una reverse shell;

E indicamos mediante una cadena que nos descargue ese archivo, teniendo un servidor en Python por ejemplo levantado;

Y la ejecutamos en el navegador;

Y vemos que la petición se efecto correctamente;

Y de la misma manera creamos una cadena para que ejecute dicho archivo, e indicamos index.html.1 puesto que el archivo index.html ya existe;

Antes de ejecutarlo en el navegador nos ponemos en escucha con netcat, copiamos la cadena, la pegamos en el navegador y obtenemos una reverse shell;

De esta misma manera podríamos efectuar un Log Poisoning, os dejo un articulo sobre esta explotación que escribí anteriormente;

Explotación de la vulnerabilidad Log Poisoning mediante LFI, RFI y RCE, explicaciones y PoC

En ocasiones esta vulnerabilidad se nos va a presentar con algunas reglas establecidas y con códigos "bien" sanitizados, en este caso nos encontramos con las función str_replace que sustituira "../" por nada es decir ""

Pero podríamos eludirlo de la siguiente manera;

Ya que solo elimina "../" si duplicamos los caracteres se quedara igual: "../"

De la misma manera de esta forma con la función pregt_match bloquea la palabra passwd

Pero siguen habiendo formas de eludirla:

De la misma manera con el empleo de wrappers podríamos utilizar una conversión a rot13

Y posteriormente a utf8

Otra forma es url-encodear la cadena para eludir posibles "reglas"

El empleo de wrappers y cadenas de filtros es esencial para "bypasear" algunas restricciones al igual que las técnicas mostradas anteriormente.

Os dejo un recurso para que veáis la infinidad de técnicas que hay para "bypasear" algunas restricciones y de las misma manera os recomiendo que veáis el video de el compañero El Pingüino de Mario donde explica esta vulnerabilidad

Y además un video del compañero CondorHacks donde se le presenta vulnerabilidad LFI y explica las diferencias en la que entrar a la maquina victima.