En raison d'une faille dans le traitement par le démon du protocole Point-to-Point (pppd) des paquets du protocole d'authentification extensible (EAP), un attaquant distant non authentifié peut provoquer un débordement de tampon de pile qui peut permettre l'exécution arbitraire de code sur le système cible. Cette faiblesse est déclenchée par une erreur dans la validation de la taille d'entrée avant de copier les données fournies en mémoire. Étant donné que la validité de la taille des données est erronée, des données aléatoires peuvent être copiées en mémoire, ce qui peut entraîner une fuite de fichier contribuant à une exécution de code non intentionnelle.

La faiblesse réside dans la logique du code d'analyse EAP, spécifiquement dans les fonctions eap request() et eap response() dans eap.c qu'un gestionnaire d'entrée réseau appelle. Ces fonctions, utilisant le premier octet comme type, prennent un pointeur et une longueur en entrée. Si le type est EAPT MD5CHAP(4), alors elle examine une zone intégrée de longueur d'1 octet. La logique de ce code vise à s'assurer que la durée intégrée est inférieure à la longueur totale du paquet. Après cette vérification, elle tente de copier les données fournies (nom d'hôte), qui sont situées dans un tampon de pile local après le champ de longueur intégré. Cette vérification des limites est incorrecte et permet la copie en mémoire avec une longueur de données arbitraire.

Une erreur logique supplémentaire fait que la fonction eap input() ne vérifie pas si EAP a été résolu pendant le processus du protocole de contrôle de liaison (LCP). Cela permet à un attaquant non authentifié d'envoyer un paquet EAP même si ppp a refusé de négocier l'authentification en raison d'un manque de support pour EAP ou d'une non-conformité avec une phrase de passe pré-partagée convenue lors de la phase LCP. Dans eap input, le code pppd non sécurisé doit toujours traiter le paquet EAP et provoquer le débordement du tampon de pile. Ces données non vérifiées et de taille inconnue peuvent être utilisées pour compromettre la mémoire du périphérique cible. Le pppd s'exécute également avec des privilèges élevés (système ou root) et fonctionne en tandem avec les pilotes du noyau.

Le programme pppd est également utilisé avec le projet LWIP (lightweight IP) pour fournir une capacité pppd aux petits ordinateurs. L'installation et les installations lwIP par défaut ne sont pas sensibles à ce débordement de tampon. Cependant, si le code source lwIP est utilisé et modifié explicitement pour permettre EAP au moment de la compilation, le programme peut être sensible au débordement de tampon.

CVE-2020-8597 est un bogue de débordement de tampon dans pppd dû à un défaut conceptuel dans le processeur de paquets du protocole d'authentification extensible (EAP). Un attaquant distant non autorisé qui envoie un paquet EAP spécialement conçu à un client ou un serveur PPP vulnérable peut provoquer une condition de déni de service ou une exécution de code arbitraire. Comme pppd fonctionne en tandem avec les pilotes du noyau et dispose de privilèges élevés, tels que périphérique ou même noyau, toute exécution de code peut également être effectuée avec les mêmes privilèges.

Référence sur qui a trouvé la vulnérabilité

Découverte par Ilja Van Sprundel, chercheur en sécurité chez IOActive, le problème crucial est une faille de débordement de tampon de pile qui se produit en raison d'une erreur logique dans l'analyseur du module du protocole d'authentification extensible (EAP) des applications pppd, une amélioration qui offre un support pour des méthodes d'authentification supplémentaires dans les connexions PPP.

La faiblesse, suivie sous le nom de CVE-2020-8597 avec un score CVSS de 9,8, peut être exploitée par des attaquants non authentifiés pour exécuter à distance du code arbitraire sur les appareils affectés et en prendre le contrôle total.

Comment elle a été trouvée

Cette faiblesse est attribuée à une erreur dans la validation de la taille de l'entrée avant de transférer les données en mémoire. Parce que la validation de la taille des données est erronée, des données aléatoires peuvent être copiées en mémoire et peuvent déclencher une fragmentation de base de données, contribuant probablement à l'exécution de code non autorisé.

La vulnérabilité se trouve dans la logique du code d'analyse EAP, spécifiquement dans les fonctions eap request() et eap response() dans eap.c, qui sont appelées par le gestionnaire d'entrée réseau.

Il est erroné de conclure que pppd n'est pas non sécurisé si EAP n'est pas autorisé ou si EAP n'a pas été initié par un pair distant utilisant un mot de passe ou une phrase de passe. En effet, un intrus authentifié peut toujours être en mesure de soumettre un paquet EAP non sollicité pour provoquer un débordement de tampon.

La vulnérabilité a été identifiée dans le démon du protocole Point-to-Point (PPP), ou pppd. PPP est un protocole de couche 2 utilisé pour établir des connexions via des modems commutés, des connexions DSL et de nombreux autres réseaux physiques, y compris les réseaux mobiles. PPP a été inclus et étendu pour inclure des protocoles supplémentaires, tels que le protocole de tunnellisation point à point (PPTP) utilisé dans les réseaux privés virtuels (VPN) pour fournir des connexions chiffrées.

Tout au long de cette situation, l'équipe de collaboration SEI CERT a collaboré avec l'analyste en sécurité Ilja Van Sprundel (IOActive) qui a découvert cette faille et le développeur de logiciels Paul Mackerras (OZlabs) qui gère le code source pour examiner facilement le problème et trouver une solution de contournement. Le problème impliquait un débordement de tampon dans le code source de pppd en raison d'un débordement de tampon de base dans l'expression booléenne et la mise en œuvre des instructions conditionnelles qui en ont résulté. La phrase ci-dessous peut être trompée pour permettre une rétroaction de durée inconnue et la copier dans un tampon de pile. C'est ce qu'on appelle communément une surcharge de trame ou un débordement de tampon de pile.

if (vallen >= len + sizeof(rhostname)) { // Copier dans le tampon rhostname

Le correctif de la vulnérabilité consistait simplement à modifier l'instruction ci-dessus pour la logique booléenne ci-dessous.

if (len-vallen >= sizeof(rhostname)) { // Copier dans le tampon rhostname

Paul a publié CVE-2020-8597 pour cette faille et a continué à la réparer dans le code source qu'il gérait. La mise à jour système nécessaire pour corriger le bogue est mineure et ne nécessite que quelques lignes de code. Néanmoins, cette technologie non sécurisée réside dans des milliers de bibliothèques de projets logiciels. Elle a été adoptée par plus de 100 entreprises proposant des dispositifs d'accès au réseau allant des routeurs domestiques au matériel réseau d'entreprise. Comme cette faiblesse affecte tous les clients et serveurs PPP, elle affecte également les fournisseurs de services Internet (FAI).

Quand elle a été trouvée

Le 4 mars 2020, des chercheurs du Centre de coordination CERT (CERT/CC) ont publié l'avis de vulnérabilité n° 782301 pour une vulnérabilité critique dans les versions 2.4.2 à 2.4.8 du démon du protocole Point-to-Point (pppd), la divulgation étant attribuée à Ilja van Sprundel d'IOActive.

Quels sont les dégâts qu'elle peut causer

En soumettant un paquet EAP non sollicité à un client ou serveur PPP vulnérable, un intrus distant non autorisé peut déclencher une corruption de la mémoire dans le mécanisme pppd, ce qui peut nécessiter une exécution de code arbitraire.

Selon le chercheur, les versions 2.4.2 à 2.4.8 du démon du protocole Point-to-Point - toutes les versions publiées au cours des 17 dernières années - sont sensibles à ce nouveau bogue d'exécution de code à distance. Parmi les distributions Linux couramment utilisées et réussies mentionnées ci-dessous, certaines ont déjà été signalées comme impactées, et plusieurs autres projets sont très probablement également affectés.

Debian Ubuntu SUSE Linux Fedora NetBSD Red Hat Enterprise Linux

De plus, le nombre d'autres applications et dispositifs sensibles (dont certains sont mentionnés ci-dessous) qui livrent des applications pppd est également probablement vaste, offrant une surface d'attaque large pour les pirates.

Cisco CallManager Produits TP-LINK Système d'exploitation embarqué OpenWRT Produits Synology

En raison d'une faille dans le traitement des paquets du protocole d'authentification extensible (EAP) dans le démon du protocole Point-to-Point (pppd), un attaquant distant non authentifié peut être en mesure de provoquer un débordement de tampon de pile, ce qui peut permettre l'exécution de code arbitraire sur le système cible. Cette vulnérabilité est due à une erreur dans la validation de la taille de l'entrée avant de copier les données fournies en mémoire. Comme la validation de la taille des données est incorrecte, des données arbitraires peuvent être copiées en mémoire et provoquer une corruption de la mémoire pouvant conduire à l'exécution de code indésirable.

Quelles sont les techniques d'exploitation

Le problème critique est une vulnérabilité de débordement de tampon de pile qui existe en raison d'une erreur logique dans l'analyseur de paquets du protocole d'authentification extensible (EAP) du logiciel pppd, une extension qui offre un support pour des méthodes d'authentification supplémentaires dans les connexions PPP.

Pour cela, tout ce qu'un attaquant doit faire est d'envoyer un paquet EAP non sollicité et malformé à un client ou un serveur ppp vulnérable via une liaison série directe, RNIS, Ethernet, SSH, socket CAT, PPTP, GPRS ou des réseaux ATM. De plus, comme pppd s'exécute souvent avec des privilèges élevés et fonctionne en conjonction avec les pilotes du noyau, la faille pourrait permettre aux attaquants d'exécuter potentiellement du code malveillant avec des privilèges système ou de niveau root. Quelle méthode d'exploit j'ai choisie

Méthode d'exécution de code à distance utilisée pour exploiter le client vulnérable. L'exécution de code à distance (RCE) concerne la capacité d'un intrus informatique à entrer et à apporter des modifications à un dispositif contrôlé par quelqu'un, sans autorisation et sans savoir où se trouve la machine. RCE permet à un attaquant de prendre le contrôle d'un ordinateur ou d'un serveur en exécutant un logiciel malveillant arbitraire (malware).

J'utilise deux machines virtuelles pour tester sur le même ordinateur. Une comme serveur et une comme client. Pour connecter les machines virtuelles, j'installe ssh. En utilisant leurs adresses IP, je connecte la machine virtuelle Fedora 29 comme côté serveur et la machine virtuelle Kali Linux comme côté client vulnérable. Selon les instructions, je configure un serveur pppoe. Après avoir ouvert le mode débogage et défini le fichier journal, j'ajoute ce qui suit au fichier journal '/etc/ppp/pppoe-server-options'. Ensuite, je configure un client pppoe en entrant 'sudo pppoeconf'. Enfin, en utilisant le code python, je peux exploiter le client vulnérable. De plus, en envoyant un paquet EAP non sollicité à un client ppp vulnérable, un attaquant distant pourrait provoquer une corruption de la mémoire dans le processus pppd, ce qui peut permettre une exécution de code arbitraire.

Captures d'écran de l'exploit

 Ping avec le client vulnérable

 Installer SSH sur le serveur

 Obtenir l'accès root côté client

 Après avoir obtenu l'accès root du client

 Activer SSH côté client

 Crash

 Résultat

Conclusion

GitHub Security Lab à la rescousse

Alors que Vijay Sarvepalli faisait des recherches sur la dernière initiative de protection de GitHub, Vijay Sarvepalli voulait identifier les opportunités d'utiliser les solutions API et CodeQL de GitHub pour résoudre le problème, et il a utilisé le code pour proposer le correctif aux utilisateurs du référentiel de logiciels. Il a contacté notre Leader de la Protection Gouvernementale, Allan Friedman (Directeur des Initiatives de Cybersécurité à l'Administration Nationale des Télécommunications et de l'Information (NTIA) au Département du Commerce des États-Unis), qui a réuni une série d'organisations, dont GitHub, pour créer une Fiche de Matériel Logiciel (SBOM). Allan a présenté Vijay Sarvepalli aux personnes de GitHub dédiées à la confidentialité, et ils m'ont mis en contact avec le chef du GitHub Security Lab, Nico Waisman.

Nico et son équipe internationale au GitHub Security Lab ont rapidement trouvé un moyen d'adapter leur mécanisme de correction de sécurité à ce problème. Ils ont déclenché une technologie automatique "robot" qui a contacté les propriétaires de tous les référentiels impactés par ce bogue. Les propriétaires de référentiels devaient simplement prendre quelques mesures rapides pour corriger et sécuriser leur copie ou version forkée du programme pppd, corrigeant ainsi le bogue. Cette initiative communautaire nous a menés à l'étape où la technologie était en cours de correction. Cela a offert une approche modulaire et opportune pour mettre en œuvre des améliorations du code source afin d'améliorer la protection. En quatre jours après les mises à jour automatiques du GitHub Security Lab, 1 896 propriétaires de référentiels ont reçu les détails du bogue et ont eu la possibilité de le corriger en quelques clics. Au moins 42 de ces propriétaires de référentiels ont approuvé un correctif automatique ; 13 autres ont confirmé que le problème avait déjà été corrigé. Sans automatisation, il faudrait plusieurs jours pour contacter les propriétaires de référentiels concernés afin de corriger leurs applications.

Le défi du DoD et le rôle du CERT dans l'avenir des logiciels

En tant que centre de recherche et développement financé par le gouvernement fédéral (FFRDC), l'Institut de génie logiciel (SEI) de l'Université Carnegie Mellon et sa division CERT sont constamment confrontés aux défis auxquels le Département de la Défense des États-Unis (DoD) fait face dans le cyberespace. Le DSI du DoD, Terry Halvorsen, un évangéliste renommé de la cybersécurité, a déclaré que "les actions défensives cybernétiques et les contre-mesures se produiront en millisecondes" lors de son discours à la conférence AFCEA. Ces actions défensives cybernétiques souhaitées ne peuvent être effectuées manuellement ou par des processus de communication lourds. Elles doivent être délivrées via des logiciels et automatisées autant que possible pour limiter les problèmes des modèles de correction actuels avec intervention humaine.

Au cours des activités de gestion des menaces potentielles, nous nous attendons à identifier des situations où nous pouvons tirer parti des incitations (comme ce partenariat avec GitHub Security Lab) pour accélérer le correction du code source contre les vulnérabilités de sécurité de l'information. Bien que nous comprenions que cela ne résoudra aucun problème de protection de l'information et ne remplace pas les bonnes méthodes de codage, nous réalisons que des bogues peuvent être trouvés dans l'information après sa publication. Lorsque l'information est omniprésente dans notre vie quotidienne, l'information ne peut être protégée que par une identification rapide des vulnérabilités — et, si possible, par l'automatisation à la fois de l'identification et de la réponse.

Références

• https://www.kb.cert.org/vuls/id/782301/ • https://thehackernews.com/2020/03/ppp-daemon-vulnerability.html • https://www.tenable.com/blog/cve-2020-8597-buffer-overflow-vulnerability-in-point-to-point-protocol-daemon-pppd • https://insights.sei.cmu.edu/cert/2020/03/security-automation-should-begin-at-the-source.html • https://packetstormsecurity.com/files/156802/pppd-2.4.8-Buffer-Overflow.html • https://www.drizgroup.com/driz_group_blog/what-is-remote-code-execution-attack-how-to-prevent-this-type-of-cyberattack • https://github.com/WinMin/CVE-2020-8597 • http://www.howtodoityourself.org/pppoe-server-how-to-do-it-yourself.html