Une chaîne d’attaques par exécution de code à distance (RCE) causée par un bogue d’inclusion de fichiers locaux dans la plateforme de blogs Hashnode a été révélée par des chercheurs en sécurité.
Le 28 février, Aditya Dixit, testeur d’intrusion et ingénieur en sécurité basé en Inde, a déclaré dans un avis de sécurité que le RCE avait été trouvé dans Hashnode, une plateforme de blogs pour la communauté des ingénieurs et des développeurs.
Dixit a rencontré des erreurs continuelles lors de la tentative d’importation de publications sur Hashnode. Après avoir examiné le problème dans Burp Suite, il a trouvé des erreurs de codage et une vulnérabilité d’inclusion de fichiers locaux (LFI) qui permettait aux utilisateurs de récupérer des fichiers de serveur internes.
Ce problème était présent dans le Bulk Markdown Importer de Hashnode, une fonctionnalité développée pour permettre aux utilisateurs d’importer des fichiers compressés .ZIP au format Markdown (.md).
En collaboration avec le chercheur en sécurité Adhyayan Panwar, Dixit a pu intensifier le LFI pour atteindre RCE.
Le duo a trouvé une erreur Error NO ENTry (ENOENT) dans Markdown – via Burp Suite – lorsqu’un utilisateur a essayé d’insérer une image avec un chemin spécifié.
« A partir de là, il ne restait plus qu’à relier les points pour récupérer les fichiers internes du serveur », a déclaré Dixit.
« Au lieu d’un chemin inexistant, nous avons décidé de donner l’emplacement d’un fichier réel comme le /etc/passwd en espérant que cela nous donnerait le contenu du fichier dans la réponse.
Cachant à la vue
Dixit et Panwar ont pu télécharger directement des fichiers, et maintenant armés de noms de chemin d’utilisateur et de répertoire personnel à partir du mot de passe dossier, l’équipe a décidé de « tenter » pour RCE.
Pour transformer cette attaque en exécution de code à distance, l’adresse IP du serveur était nécessaire. Dixit a déclaré que par défaut, les clés publiques et privées sont stockées dans deux répertoires par défaut distincts et qu’il était possible de modifier une charge utile pour récupérer la clé privée.
Le serveur était « caché derrière Cloudlfare », dit le testeur de plumes, et Panwar s’est donc tourné vers le /proc/net/tcp répertoire pour trouver la bonne adresse IP. Le /proc L’interface a révélé des connexions TCP actives, et tandis que les adresses sont stockées sous forme de valeurs hexadécimales, il était possible d’utiliser un code simple pour les convertir dans un format lisible – exposant l’adresse IP et le numéro de port.
Panwar a dit La gorgée quotidienne que /proc/net/tcp peut fournir des informations cruciales concernant les ports internes, offrant aux enquêteurs une « surface d’attaque plus large ». Cependant, un utilisateur d’infosec Discord a suggéré de vérifier le fichier pour les informations requises pour créer un déclencheur RCE.
« Nous ne l’avions jamais envisagé sous l’angle de la récupération d’adresses IP », a déclaré le chercheur. « Il contenait une liste de toutes les connexions actives sur le serveur, avec une liste d’adresses locales et distantes. Nous avons pu identifier trois adresses locales : l’une était localhost, l’autre était leur adresse IP intranet et l’autre était [a] IP publique, qui permettait les connexions SSH.
Si un attaquant est armé de ces informations, il pourrait alors exécuter du code sur le serveur.
Rotation des clés
L’équipe Hashnode a été informée des découvertes des chercheurs le 8 février. Hashnode nous a dit que « la vulnérabilité était associée à l’un de nos composants hérités et a été corrigée presque immédiatement. Nous avons également fait tourner toutes nos clés immédiatement.
Dixit a commenté : « Même si nous avons pu obtenir la clé privée de l’utilisateur, nous ne pouvions pas accéder au serveur en SSH car, selon Hashnode, il y avait une liste blanche d’adresses IP pour empêcher tout accès non autorisé ».
« Nous n’avons pas essayé de nous connecter lorsque nous avons obtenu la clé pour des raisons évidentes. Mais dans les cas où les administrateurs n’ont mis en place aucune liste blanche IP [allow listing] ou pare-feu, cela peut certainement conduire à une compromission complète du serveur.
« Le point à retenir de notre exploit serait de ne jamais afficher de messages descriptifs aux utilisateurs finaux et de toujours avoir une validation d’entrée en place sur tous les paramètres d’entrée », a ajouté le chercheur. « C’est une très mauvaise idée de faire confiance aux entrées de vos utilisateurs. »
CONSEILLÉ Discussion privée? L’extension Chrome Skype avec 9 millions d’installations révèle une fuite d’informations sur l’utilisateur