LFI2RCE via Eternal waiting

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !
Découvrez The PEASS Family, notre collection exclusive de NFTs
Obtenez le swag officiel PEASS & HackTricks
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Informations de base

Par défaut, lorsqu'un fichier est téléchargé sur PHP (même s'il ne s'y attend pas), il générera un fichier temporaire dans /tmp avec un nom tel que php[a-zA-Z0-9]{6}, bien que j'ai vu certaines images Docker où les fichiers générés ne contiennent pas de chiffres.

Dans une inclusion de fichier local, si vous parvenez à inclure ce fichier téléchargé, vous obtiendrez une RCE.

Notez que par défaut, PHP ne permet de télécharger que 20 fichiers dans une seule requête (défini dans /etc/php/<version>/apache2/php.ini) :

; Maximum number of files that can be uploaded via a single request
max_file_uploads = 20

Aussi, le nombre de noms de fichiers potentiels est de 62*62*62*62*62*62 = 56800235584

Autres techniques

D'autres techniques consistent à attaquer les protocoles PHP (vous ne pourrez pas le faire si vous ne contrôlez que la dernière partie du chemin), à divulguer le chemin du fichier, à abuser des fichiers attendus, ou à faire souffrir PHP d'une erreur de segmentation pour que les fichiers temporaires téléchargés ne soient pas supprimés.
Cette technique est très similaire à la dernière, mais sans avoir besoin de trouver un jour zéro.

Technique de l'attente éternelle

Dans cette technique, nous avons seulement besoin de contrôler un chemin relatif. Si nous parvenons à télécharger des fichiers et à faire en sorte que LFI ne se termine jamais, nous aurons "assez de temps" pour forcer la recherche de fichiers téléchargés et trouver n'importe lequel d'entre eux.

Avantages de cette technique:

Vous avez seulement besoin de contrôler un chemin relatif à l'intérieur d'une inclusion
Ne nécessite pas nginx ou un niveau d'accès inattendu aux fichiers journaux
Ne nécessite pas un jour zéro pour provoquer une erreur de segmentation
Ne nécessite pas de divulgation de chemin

Les principaux problèmes de cette technique sont:

Besoin d'un ou plusieurs fichiers spécifiques à être présents (il peut y en avoir plus)
Le nombre incroyable de noms de fichiers potentiels : 56800235584
- Si le serveur n'utilise pas de chiffres, le nombre total potentiel est de : 19770609664
Par défaut, seuls 20 fichiers peuvent être téléchargés dans une seule requête.
Le nombre maximal de travailleurs en parallèle du serveur utilisé.
- Cette limite avec les précédentes peut rendre cette attaque trop longue
Délai d'attente pour une requête PHP. Idéalement, cela devrait être éternel ou devrait tuer le processus PHP sans supprimer les fichiers téléchargés temporaires, sinon cela sera également une douleur

Alors, comment pouvez-vous faire en sorte qu'une inclusion PHP ne se termine jamais ? Tout simplement en incluant le fichier /sys/kernel/security/apparmor/revision (malheureusement pas disponible dans les conteneurs Docker).

Essayez-le simplement en appelant :

php -a # open php cli
include("/sys/kernel/security/apparmor/revision");

Apache2

Par défaut, Apache supporte 150 connexions simultanées, selon https://ubiq.co/tech-blog/increase-max-connections-apache/, il est possible d'augmenter ce nombre jusqu'à 8000. Suivez ceci pour utiliser PHP avec ce module: https://www.digitalocean.com/community/tutorials/how-to-configure-apache-http-with-mpm-event-and-php-fpm-on-ubuntu-18-04.

Par défaut, (comme je peux le voir dans mes tests), un processus PHP peut durer éternellement.

Faisons des maths:

Nous pouvons utiliser 149 connexions pour générer 149 * 20 = 2980 fichiers temporaires avec notre webshell.
Ensuite, utilisez la dernière connexion pour brute-force les fichiers potentiels.
À une vitesse de 10 requêtes/s, les temps sont:
- 56800235584 / 2980 / 10 / 3600 ~= 530 heures (50% de chances en 265h)
- (sans chiffres) 19770609664 / 2980 / 10 / 3600 ~= 185h (50% de chances en 93h)

{% hint style="warning" %} Notez que dans l'exemple précédent, nous sommes en train de DoS complètement d'autres clients! {% endhint %}

Si le serveur Apache est amélioré et que nous pouvons abuser de 4000 connexions (à mi-chemin du nombre maximal). Nous pourrions créer 3999*20 = 79980 fichiers et le nombre serait réduit à environ 19,7h ou 6,9h (10h, 3,5h 50% de chances).

PHP-FMP

Si au lieu d'utiliser le module php régulier pour apache pour exécuter des scripts PHP, la page web utilise PHP-FMP (ce qui améliore l'efficacité de la page web, donc c'est courant de le trouver), il y a autre chose qui peut être fait pour améliorer la technique.

PHP-FMP permet de configurer le paramètre request_terminate_timeout dans /etc/php/<php-version>/fpm/pool.d/www.conf.
Ce paramètre indique le nombre maximum de secondes lorsque la demande à PHP doit se terminer (infini par défaut, mais 30s si le paramètre est décommenté). Lorsqu'une demande est en cours de traitement par PHP pendant le nombre de secondes indiqué, elle est tuée. Cela signifie que si la demande téléchargeait des fichiers temporaires, parce que le traitement php a été arrêté, ces fichiers ne seront pas supprimés. Par conséquent, si vous pouvez faire durer une demande pendant ce temps, vous pouvez générer des milliers de fichiers temporaires qui ne seront pas supprimés, ce qui accélérera le processus de recherche et réduira la probabilité d'un DoS sur la plateforme en consommant toutes les connexions.

Donc, pour éviter le DoS, supposons qu'un attaquant n'utilisera que 100 connexions en même temps et que le temps de traitement maximal de PHP par php-fmp (request_terminate_timeout) est de 30s. Par conséquent, le nombre de fichiers temporaires qui peuvent être générés par seconde est de 100*20/30 = 66,67.

Ensuite, pour générer 10000 fichiers, un attaquant aurait besoin de: 10000/66.67 = 150s (pour générer 100000 fichiers, le temps serait de 25min).

Ensuite, l'attaquant pourrait utiliser ces 100 connexions pour effectuer une recherche brute-force. En supposant une vitesse de 300 req/s, le temps nécessaire pour exploiter cela est le suivant:

56800235584 / 10000 / 300 / 3600 ~= 5,25 heures (50% de chances en 2,63h)
(avec 100000 fichiers) 56800235584 / 100000 / 300 / 3600 ~= 0,525 heures (50% de chances en 0,263h)

Oui, il est possible de générer 100000 fichiers temporaires dans une instance de taille moyenne EC2:

{% hint style="warning" %} Notez que pour déclencher le délai d'attente, il suffirait d'inclure la page LFI vulnérable, afin qu'elle entre dans une boucle d'inclusion éternelle. {% endhint %}

Nginx

Il semble que par défaut, Nginx supporte 512 connexions parallèles en même temps (et ce nombre peut être amélioré).

8.7 KiB Raw Blame History