dilan-diaz/point-to-point-protocol-daemon-rce-vulnerability-cve-2020-8597-
Sri Lanka Institute of Information Technology
Aufgabe 1
M. P. D. M. Dias
IT19165530
MLB_WD_Y2S1_13.1
Point to Point Protocol Daemon RCE
Schwachstelle (CVE-2020-8597)
System- und Netzwerkprogrammierung– IE2012
Inhalt
Einführung
Das Point-to-Point-Protokoll (PPP) ist ein Vollduplex-Protokoll, das es ermöglicht, einfache Daten zu kapseln und über Layer-2- oder Data-Link-Infrastrukturen zu verteilen, die von DFÜ-Verbindungen über DSL-Breitband bis hin zu virtuellen privaten Netzwerken (VPNs) mit SSL-Verschlüsselung reichen. Da diese Protokolle keine Punkt-zu-Punkt-Kommunikation ermöglichen, wird PPP auch verwendet, um IP und TCP über zwei direkt verbundene Knoten zu übertragen. Pppd ist ein Daemon, der auf Unix-ähnlichen Betriebssystemen verwendet wird, um den Aufbau von PPP-Sitzungen und die Beendigung von Sitzungen zwischen zwei Knoten zu verwalten.
PPP ist das Protokoll, mit dem Internetverbindungen über DFÜ-Modems, DSL-Verbindungen und verschiedene andere Formen von Punkt-zu-Punkt-Verbindungen über virtuelle private Netzwerke (VPN) wie das Peer-to-Point-Tunneling-Protokoll (PPTP) hergestellt werden. Das pppd-Programm kann außerdem einen Peer authentifizieren, der sich mit dem Netzwerk verbindet, und/oder dem Peer Authentifizierungsdetails mithilfe verschiedener Authentifizierungsprotokolle wie EAP bereitstellen.
Aufgrund eines Fehlers bei der Verarbeitung von Paketen des Extensible Authentication Protocol (EAP) durch den Point-to-Point-Protocol-Daemon (pppd) kann ein nicht authentifizierter entfernter Angreifer einen Stack-Pufferüberlauf verursachen, der eine beliebige Codeausführung auf dem Zielsystem ermöglichen kann. Diese Schwachstelle wird durch einen Fehler bei der Validierung der Eingabegröße ausgelöst, bevor die bereitgestellten Daten in den Speicher kopiert werden. Da die Validierung der Datengröße fehlerhaft ist, können beliebige Daten in den Speicher kopiert werden, was Speicherkorruption auslösen und zu unbeabsichtigter Codeausführung beitragen kann.
Die Schwachstelle liegt in der Logik des EAP-Parsing-Codes, genauer gesagt in den Funktionen eap request) (und eap response) (in eap.c, die von einem Netzwerk-Eingabehandler aufgerufen werden. Diese Funktionen verwenden das erste Byte als Typ und nehmen einen Zeiger und eine Länge als Eingabe. Wenn der Typ EAPT MD5CHAP(4) ist, betrachtet die Funktion einen eingebetteten Bereich mit einer Länge von 1 Byte. Die Logik in diesem Code soll sicherstellen, dass die eingebettete Länge kleiner ist als die Gesamtlänge des Pakets. Nach dieser Überprüfung versucht die Funktion, die bereitgestellten Daten (Hostname) zu kopieren, die sich in einem lokalen Stack-Puffer nach dem eingebetteten Längenfeld befinden. Diese Grenzwertprüfung ist fehlerhaft und ermöglicht das Kopieren von Speicher mit einer beliebigen Datenlänge.
Ein zusätzlicher logischer Fehler führt dazu, dass die Funktion eap input) (nicht prüft, ob EAP während des Line-Control-Protocol-Prozesses (LCP) ausgehandelt wurde. Dadurch kann ein nicht authentifizierter Angreifer ein EAP-Paket senden, selbst wenn ppp die Aushandlung der Authentifizierung verweigert hat, weil EAP nicht unterstützt wird oder weil in der LCP-Phase eine vereinbarte, vorab geteilte Passphrase nicht eingehalten wurde. In eap input muss der unsichere pppd-Code das EAP-Paket dennoch verarbeiten und den Stack-Pufferüberlauf verursachen. Diese unverifizierten Daten unbekannter Größe können verwendet werden, um den Speicher des Zielgeräts zu kompromittieren. pppd läuft außerdem mit hohen Privilegien (System oder Root) und arbeitet mit Kernel-Treibern zusammen.
Das pppd-Programm wird auch mit dem LWIP-Projekt (Lightweight IP) verwendet, um pppd-Funktionen auf sehr kleinen Computern bereitzustellen. Die Standardinstallation von lwIP ist nicht anfällig für diesen Pufferüberlauf. Wenn jedoch der lwIP-Quellcode verwendet und explizit so geändert wird, dass EAP zur Kompilierzeit zugelassen wird, kann das Programm anfällig für einen Pufferüberlauf sein.
CVE-2020-8597 ist ein Pufferüberlauf-Fehler in pppd, der auf einen konzeptionellen Fehler im Paketprozessor des Extensible Authentication Protocol (EAP) zurückzuführen ist. Ein nicht autorisierter entfernter Angreifer, der ein speziell präpariertes EAP-Paket an einen anfälligen PPP-Client oder -Server sendet, kann einen Denial-of-Service-Zustand oder eine beliebige Codeausführung verursachen. Da pppd mit Kernel-Treibern zusammenarbeitet und außerdem hohe Privilegien besitzt, wie etwa System- oder sogar Root-Rechte, kann jede Codeausführung ebenfalls mit denselben Privilegien erfolgen.
Referenz: Wer die Schwachstelle gefunden hat
Entdeckt wurde die kritische Schwachstelle von Ilja Van Sprundel, Sicherheitsforscher bei IOActive. Es handelt sich um eine Stack-Pufferüberlauf-Schwachstelle, die aufgrund eines logischen Fehlers im Parser des Extensible-Authentication-Protocol-Moduls (EAP) von pppd-Anwendungen auftritt – einer Erweiterung, die Unterstützung für zusätzliche Authentifizierungsmethoden in PPP-Verbindungen bietet.
Die Schwachstelle, die als CVE-2020-8597 mit einem CVSS-Score von 9.8 erfasst ist, kann von nicht autorisierten Angreifern ausgenutzt werden, um auf betroffenen Geräten aus der Ferne beliebigen Code auszuführen und die vollständige Kontrolle über sie zu erlangen.
Wie sie gefunden wurde
Diese Schwachstelle wird auf einen Fehler bei der Validierung der Eingabegröße zurückgeführt, bevor die Daten in den Speicher übertragen werden. Da die Validierung der Datengröße fehlerhaft ist, können beliebige Daten in den Speicher kopiert werden und Speicherkorruption auslösen, was wahrscheinlich zur Ausführung von nicht autorisiertem Code beiträgt.
Die Schwachstelle befindet sich in der Logik des EAP-Parsing-Codes, genauer gesagt in den Funktionen eap request) (und eap response) (in eap.c, die vom Netzwerk-Eingabehandler aufgerufen werden.
Es ist falsch anzunehmen, dass pppd sicher ist, wenn EAP nicht zugelassen ist oder wenn EAP nicht von einem entfernten Peer mithilfe eines Passworts oder einer Passphrase initiiert wurde. Ein nicht authentifizierter Angreifer kann nämlich jederzeit ein unaufgefordertes EAP-Paket senden, um einen Pufferüberlauf auszulösen.
Die Schwachstelle wurde im Daemon des Point-to-Point-Protokolls (PPP), kurz pppd, identifiziert. PPP ist ein Layer-2-Protokoll, das zum Aufbau von Verbindungen über DFÜ-Modems, DSL-Verbindungen und viele andere physische Netzwerke, einschließlich mobiler Netzwerke, verwendet wird. PPP wurde in weitere Protokolle integriert und erweitert, wie etwa das Point-to-Point Tunneling Protocol (PPTP), das in virtuellen privaten Netzwerken (VPNs) zur Bereitstellung verschlüsselter Verbindungen verwendet wird.
In diesem Zusammenhang arbeitete das SEI-CERT-Kooperationsteam mit dem Sicherheitsanalysten Ilja Van Sprundel (IOActive), der diesen Fehler entdeckte, und dem Softwareentwickler Paul Mackerras (OZlabs), der den Quellcode verwaltet, zusammen, um das Problem zu untersuchen und einen Workaround zu finden. Bei dem Problem handelte es sich um einen Pufferüberlauf im pppd-Quellcode, der auf einen grundlegenden Fehler im booleschen Ausdruck und in der Umsetzung der daraus resultierenden Bedingungsanweisungen zurückzuführen war. Die folgende Anweisung kann dazu verleitet werden, Eingaben unbekannter Länge zuzulassen und sie in einen Stack-Puffer zu kopieren. Dies wird allgemein als Frame-Überlauf oder Stack-Pufferüberlauf bezeichnet.
if (vallen >= len + sizeof(rhostname)) { // Copy to buffer rhostname
Die Behebung der Schwachstelle bestand darin, die obige Anweisung einfach durch die folgende boolesche Logik zu ersetzen.
if (len-vallen >= sizeof(rhostname)) { // Copy to buffer rhostname
Paul vergab CVE-2020-8597 für diesen Fehler und reparierte ihn anschließend im von ihm verwalteten Quellcode. Das zur Korrektur des Fehlers erforderliche Update ist geringfügig und umfasst nur wenige Zeilen Code. Dennoch ist diese unsichere Technologie in Tausenden von Bibliotheken von Softwareprojekten enthalten. Sie wurde von mehr als 100 Unternehmen übernommen, die Netzwerkzugangsgeräte anbieten, von Heimroutern bis hin zu Netzwerkhardware für Unternehmen. Da diese Schwachstelle alle PPP-Clients und -Server betrifft, sind auch Internetdienstanbieter (ISPs) betroffen.
Wann sie gefunden wurde
Am 4. März 2020 veröffentlichten Forscher des CERT Coordination Centers (CERT/CC) den Vulnerability-Notes-Eintrag #782301 für eine kritische Schwachstelle im Point-to-Point-Protocol-Daemon (pppd) der Versionen 2.4.2 bis 2.4.8, wobei die Offenlegung Ilja van Sprundel von IOActive zugeschrieben wurde.
Welchen Schaden sie verursachen kann
Durch das Senden eines unaufgeforderten EAP-Pakets an einen anfälligen PPP-Client oder -Server kann ein nicht autorisierter entfernter Angreifer Speicherkorruption im pppd-Prozess auslösen, was eine beliebige Codeausführung ermöglichen kann.
Laut dem Forscher sind die Versionen 2.4.2 bis 2.4.8 des Point-to-Point-Protocol-Daemons – also alle in den letzten 17 Jahren veröffentlichten Versionen – anfällig für diesen neuen Remote-Codeausführungs-Fehler. Einige der unten genannten, weit verbreiteten und etablierten Linux-Distributionen wurden bereits als betroffen gemeldet, und mehrere andere Projekte sind höchstwahrscheinlich ebenfalls betroffen.
Debian Ubuntu SUSE Linux Fedora NetBSD Red Hat Enterprise Linux
Darüber hinaus ist auch die Zahl der anderen anfälligen Anwendungen und Geräte (von denen einige unten genannt werden), die pppd-Anwendungen enthalten, wahrscheinlich riesig, was Angreifern eine breite Angriffsfläche bietet.
Cisco CallManager TP-LINK-Produkte OpenWRT Embedded OS Synology-Produkte
Aufgrund eines Fehlers bei der Verarbeitung von EAP-Paketen (Extensible Authentication Protocol) im Point-to-Point-Protocol-Daemon (pppd) kann ein nicht authentifizierter entfernter Angreifer einen Stack-Pufferüberlauf verursachen, der eine beliebige Codeausführung auf dem Zielsystem ermöglichen kann. Diese Schwachstelle ist auf einen Fehler bei der Validierung der Eingabegröße zurückzuführen, bevor die bereitgestellten Daten in den Speicher kopiert werden. Da die Validierung der Datengröße fehlerhaft ist, können beliebige Daten in den Speicher kopiert werden und Speicherkorruption verursachen, die möglicherweise zur Ausführung unerwünschten Codes führt.
Welche Ausnutzungstechniken gibt es
Bei dem kritischen Problem handelt es sich um eine Stack-Pufferüberlauf-Schwachstelle, die aufgrund eines logischen Fehlers im Paketparser des Extensible Authentication Protocol (EAP) der pppd-Software besteht – einer Erweiterung, die Unterstützung für zusätzliche Authentifizierungsmethoden in PPP-Verbindungen bietet.
Dazu muss ein Angreifer lediglich ein unaufgefordertes, fehlerhaftes EAP-Paket an einen anfälligen PPP-Client oder -Server senden, und zwar über eine direkte serielle Verbindung, ISDN-, Ethernet-, SSH-, Socket-CAT-, PPTP-, GPRS- oder ATM-Netzwerke. Da pppd außerdem häufig mit hohen Privilegien läuft und mit Kernel-Treibern zusammenarbeitet, könnte der Fehler Angreifern potenziell die Ausführung von Schadcode mit System- oder Root-Rechten ermöglichen.
Welche Exploit-Methode gewählt wurde
Zur Ausnutzung des anfälligen Clients wurde die Methode der Remote-Codeausführung (RCE) verwendet. Remote Code Execution (RCE) bezeichnet die Fähigkeit eines Cyber-Angreifers, in ein von einer Person kontrolliertes Gerät einzudringen und Änderungen daran vorzunehmen – ohne Erlaubnis und ohne dass bekannt ist, wo sich das Gerät befindet. RCE ermöglicht es einem Angreifer, einen Computer oder Server zu übernehmen, indem er beliebige Schadsoftware (Malware) ausführt.
Ich verwende zwei virtuelle Maschinen, um auf demselben Computer zu testen – eine als Server und eine als Client. Um die virtuellen Maschinen zu verbinden, installiere ich SSH. Über ihre IP-Adressen verbinde ich die Fedora-29-VM als Server-Seite und die Kali-Linux-VM als anfällige Client-Seite. Gemäß den Anweisungen richte ich einen PPPoE-Server ein. Danach öffne ich den Debug-Modus, lege die Logdatei fest und füge Folgendes zur Logdatei '/etc/ppp/pppoe-server-options' hinzu. Dann richte ich einen PPPoE-Client ein, indem ich 'sudo pppoeconf' eingebe. Schließlich kann mit dem Python-Code der anfällige Client ausgenutzt werden. Außerdem kann ein entfernter Angreifer durch das Senden eines unaufgeforderten EAP-Pakets an einen anfälligen PPP-Client Speicherkorruption im pppd-Prozess verursachen, was eine beliebige Codeausführung ermöglichen kann.
Screenshots des Exploits
Ping mit anfälligem Client
SSH auf dem Server installieren
Root-Zugriff auf der Client-Seite erlangen
Nach Erlangen des Root-Zugriffs des Clients
SSH auf der Client-Seite aktivieren
Absturz
Ergebnis
Fazit
GitHub Security Lab zur Rettung
Als Vijay Sarvepalli die neueste Schutzinitiative von GitHub untersuchte, wollte er Möglichkeiten identifizieren, die API- und CodeQL-Lösungen von GitHub zu nutzen, um das Problem anzugehen, und er setzte Code ein, um den Fix Nutzern von Software-Repositories vorzuschlagen. Er kontaktierte unseren Leiter für staatliche Schutzinitiativen, Allan Friedman (Direktor für Cybersicherheitsinitiativen bei der National Telecommunications and Information Administration (NTIA) im Handelsministerium der Vereinigten Staaten), der eine Reihe von Organisationen, darunter GitHub, zusammengebracht hat, um eine Software Bill of Materials (SBOM) zu erstellen. Allan stellte Vijay Sarvepalli den Leuten bei GitHub vor, die sich der Sicherheit widmen, und sie brachten mich mit dem Leiter des GitHub Security Lab, Nico Waisman, in Kontakt.
Nico und sein internationales Team im GitHub Security Lab fanden schnell einen Weg, ihren Sicherheits-Patching-Mechanismus an dieses Problem anzupassen. Sie starteten eine automatische „Roboter“-Technologie, die sich an die Besitzer aller von diesem Fehler betroffenen Repositories wandte. Die Repository-Besitzer mussten nur wenige schnelle Maßnahmen ergreifen, um ihre kopierte oder geforkte Version des pppd-Programms zu reparieren und abzusichern und den Fehler zu beheben. Diese Gemeinschaftsinitiative brachte uns an den Punkt, an dem die Technik repariert wurde. Dies bot einen modularen, zeitnahen Ansatz, um Verbesserungen am Quellcode umzusetzen und so den Schutz zu erhöhen. Innerhalb von vier Tagen nach den automatischen Updates des GitHub Security Lab erhielten 1.896 Repository-Besitzer Details zu dem Fehler und die Möglichkeit, ihn mit wenigen Klicks zu beheben. Mindestens 42 dieser Repository-Besitzer haben einen automatischen Patch genehmigt; 13 weitere haben bestätigt, dass das Problem bereits behoben wurde. Ohne Automatisierung würde es mehrere Tage dauern, die betroffenen Repository-Besitzer zu kontaktieren, um ihre Anwendungen zu reparieren.
Die Herausforderung des DoD und die Rolle des CERT in der Zukunft der Software
Als bundesweit gefördertes Forschungs- und Entwicklungszentrum (FFRDC) werden das Software Engineering Institute (SEI) der Carnegie Mellon University und seine CERT-Division ständig mit den Herausforderungen konfrontiert, denen sich das US-Verteidigungsministerium (DoD) im Cyberspace gegenübersieht. DoD-CIO Terry Halvorsen, ein bekannter Cybersicherheits-Vordenker, sagte in seiner Rede auf der AFCEA-Konferenz, dass „Cyber-Abwehrmaßnahmen und -Gegenmaßnahmen in Millisekunden erfolgen werden“. Diese gewünschten Cyber-Abwehrmaßnahmen können nicht manuell oder über schwerfällige Kommunikationsprozesse durchgeführt werden. Sie müssen über Software bereitgestellt und so weit wie möglich automatisiert werden, um Probleme mit den aktuellen Human-in-the-Loop-Patching-Modellen zu begrenzen.
Im Rahmen potenzieller Maßnahmen zur Bedrohungsbewältigung erwarten wir, Situationen zu identifizieren, in denen wir Anreize (wie diese Partnerschaft mit dem GitHub Security Lab) nutzen können, um das Patchen von Quellcode gegen Schwachstellen der Informationssicherheit zu beschleunigen. Obwohl wir wissen, dass dies kein Problem des Informationsschutzes behebt und keine Alternative zu guten Programmiermethoden darstellt, ist uns bewusst, dass Fehler tendenziell erst in Software gefunden werden, nachdem sie veröffentlicht wurde. Wenn Software in unserem täglichen Leben allgegenwärtig ist, kann sie nur durch die schnelle Identifizierung von Schwachstellen geschützt werden – und, wenn möglich, durch die Automatisierung sowohl der Identifizierung als auch der Behebung.
Referenzen
• 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