Fast täglich tauchen neue Schwachstellen und Angriffsvektoren auf. Die Sicherheitsteams haben eine größere Chance, Angriffe abzuwehren, wenn zwischen der aktiven Ausnutzung durch die Hacker und der Entdeckung weniger Zeit vergeht. SRLabs erforscht sowohl Schwachstellen (z. B. Reverse Engineering, Blackbox-Tests) als auch Angriffe (z. B. Honeypots, Netzwerküberwachung). In diesem Blog-Beitrag werden interessante Ergebnisse unserer Forschung zu Zero-Day-Schwachstellen vorgestellt.
Wir haben die Nutzungsdaten analysiert, die wir im letzten Jahr im Rahmen eines separaten Honeypot-Projekts gesammelt haben, über das wir in zukünftigen Blogbeiträgen berichten werden. Die meisten der rund 100 eindeutigen Nutzungsdaten standen im Zusammenhang mit bekannten Schwachstellen, für die es Patches gab. Es stellte sich jedoch die Frage, ob diese Patches vollständig (d. h. korrekt und umfassend) waren, da neuere Untersuchungen gezeigt hatten, dass einige Patches lediglich einen bestimmten Angriffsvektor überdecken, anstatt die eigentliche Ursache der Schwachstelle zu beheben [1].
Vor diesem Hintergrund haben wir die Schwachstelle und den Patch für CVE-2020-9054, eine Pre-Auth-Command in ZyXEL NAS-Geräte, genauer untersucht. Wir fanden heraus, dass die gepatchte Schwachstelle aufgrund dieser Art von unvollständigem Patching immer noch ausnutzbar war.
Eingehende Analyse der Ausnutzung von CVE-2020-9054
CVE-2020-9054 betrifft NAS-Geräte von ZyXEL. Diese Netzwerkspeichergeräte ermöglichen es autorisierten Benutzern, Daten an einem zentralen Ort zu speichern und darauf zuzugreifen. NAS-Geräte sind ein attraktives Ziel für Hacker, da sie wahrscheinlich sensible Daten enthalten. Kleinere und mittlere Unternehmen auf der ganzen Welt setzen diese Geräte zunehmend ein, da ihnen im Vergleich zu größeren Unternehmen häufig die Ressourcen zur Erkennung und Abwehr von Angriffen fehlen.
Bei der in CVE-2020-9054 beschriebenen Sicherheitslücke handelt es sich um eine Befehlsinjektion vor der Authentifizierung, die es einem entfernten, nicht authentifizierten Angreifer ermöglichen kann, beliebigen Code auf einem anfälligen Gerät auszuführen. Wenn der Parameter username bestimmte Zeichen enthält, kann er eine Befehlsinjektion mit den Rechten des Webservers ermöglichen, der auf dem ZyXEL-Gerät läuft. Obwohl der Webserver nicht als Root-Benutzer läuft, enthalten ZyXEL-Geräte ein setuid-Dienstprogramm, das zur Ausführung beliebiger Befehle mit Root-Rechten genutzt werden kann [2].
Abbildung 1 zeigt einen Angriffsversuch mit CVE-2020-9054 auf unseren Honeypot:
Nachdem wir beobachtet hatten, dass die Schwachstelle in freier Wildbahn ausgenutzt wurde, haben wir den Patch untersucht, der das Problem beheben sollte. Der Patch wurde Anfang 2020 von ZyXEL veröffentlicht [3]. Auffallend war, dass sich die eigentliche Schwachstelle nicht in dem Codeabschnitt befand, den die CVE vorschlug, sondern in einem von ihr verwendeten benutzerdefinierten PAM-Modul. Der Patch behebt nur die Schwachstelle über den HTTP-Port, nicht aber das eigentliche verwundbare PAM-Modul, das über andere Ports zugänglich ist.
Abbildung 2 zeigt den Code mit der Schwachstelle
Anderer Port, gleicher Exploit
Neben dem Port, der von dem ursprünglichen Exploit ausgenutzt wurde, bietet das ZyXEL NAS noch eine zweite Schnittstelle an: Port 21 für FTP-Dienste. FTP verwendet das PAM-Modul zur Authentifizierung und ist daher von demselben Problem in diesem PAM-Modul betroffen. Es ist uns gelungen, eine leicht abweichende Nutzlast über das Benutzernamen-Feld von FTP zu injizieren (Abbildung 3). Dadurch konnten wir die zugrundeliegende Schwachstelle in vermeintlich gepatchten Systemen ausnutzen und beliebige Befehle als root einspeisen. Dies zeigt, dass böswillige Akteure die betroffenen Hosts vollständig kompromittieren und beliebigen Code auf der höchsten Berechtigungsebene ausführen konnten (Abbildung 4). Obwohl wir in unseren Daten keine Hinweise auf eine aktive Ausnutzung der Schwachstelle gefunden haben, kann eine Ausnutzung nicht ausgeschlossen werden.
Abbildung 3 zeigt die Ausnutzung der Schwachstelle in vermeintlich gepatchten Systemen
Abbildung 4 zeigt die Ausführung von Codes auf der höchsten Berechtigungsebene
SRLabs meldete das Problem an ZyXEL, die es als eine separate Angelegenheit mit anderen Angriffsvektoren betrachteten. Wir haben eine CVE-ID angefordert (keine Antwort) und erwarten bald einen neuen Patch. Eine schnelle Shodan-Suche ergibt etwa 2-3k anfällige Geräte.
Andere Beweise für schlecht gepatchte Sicherheitslücken
Es ist nicht das erste Mal, dass ein von einem Hersteller herausgegebener Patch das zugrunde liegende Problem nicht löst. In solchen Fällen müssen die Angreifer ihre Schwachstellen oft nur geringfügig verändern, um sie erneut erfolgreich zu nutzen [1].
Beispiele für oberflächliche Korrekturen sind an der Tagesordnung. Während unserer Recherchen entdeckten wir mehrere Schwachstellen, die öffentlich gemeldet wurden, weil ältere Probleme unvollständig oder unzureichend behoben worden waren. Dies zeigt, wie Entwickler und Sicherheitsingenieure dazu neigen, Sicherheitsprobleme zu lösen, indem sie sich auf einen bestimmten Angriffsvektor konzentrieren, anstatt die zugrundeliegende Schwachstelle zu beheben, die oft auch nach dem Patchen noch vorhanden ist. Ein Grund dafür könnte der Zeitdruck sein.
Ein weiteres Beispiel für eine Sicherheitslücke, die nach der Veröffentlichung eines Patches erneut ausgenutzt werden könnte, ist CVE-2019-16759. Dieses Problem betrifft vBulletin, eine beliebte Software für die Verwaltung von Online-Foren, und es handelt sich um die Template-Rendering-Engine, die es einem Angreifer ermöglicht, PHP-Code auszuführen, indem er eine bösartige Anfrage sendet. Nach dem Bekanntwerden dieser Sicherheitslücke wurde ein Patch veröffentlicht, um Prüfungen für die gerenderte Vorlage hinzuzufügen und die Ausnutzung von CVE-2019-16759 zu verhindern.
Ungefähr ein Jahr später tauchte die Schwachstelle als CVE-2020-17496 wieder auf, zusammen mit einem Exploit, der die vorherige Korrektur umging [4]. Ähnlich wie im Fall von ZyXEL zielte der Patch für das ursprüngliche Problem darauf ab, den Angriffspfad des Exploits zu verhindern, anstatt die zugrunde liegende Schwachstelle zu beheben.
Fazit
Das rasante Wettrüsten zwischen Angreifern und Sicherheitsforschern ist eine ständige Herausforderung. Obwohl Patches eine Schlüsselkomponente bei der Abwehr potenzieller Angriffe sind, zeigen Untersuchungen regelmäßig, dass Patches manchmal nicht die eigentliche Ursache von Schwachstellen beheben. In solchen Fällen können leicht modifizierte Versionen der ursprünglichen Angriffe die Patches leicht umgehen.
Zwar haben auch andere Sicherheitsforscher damit begonnen, sich mit diesem Problem zu befassen, aber das Thema unvollständiges Patching erfordert noch viel mehr Aufmerksamkeit und Untersuchungen. Es ist wichtig, sich ein genaues Bild davon zu machen, wie weit verbreitet dieses Problem ist. Es gilt, die Gründe für unvollständige Patches zu verstehen und dann Maßnahmen in Bezug auf Schulungen, Ressourcenzuweisung, Anreize, Partnerschaften und Prozesse zu ergreifen. Eine wirksame Verteidigung gegen Zero-Days muss sich auf die Behebung neuer Probleme konzentrieren, anstatt alte wieder aufzugreifen.
Forschung von: Alberto del Rio, Genco Altan Demir, Julian-Ferdinand Vögele
References
[1] https://googleprojectzero.blogspot.com/2021/02/deja-vu-lnerability.html
[2] https://nvd.nist.gov/vuln/detail/CVE-2020-9054
[3] https://www.zyxel.com/us/en/support/remote-code-execution-vulnerability-of-NAS-products.shtml
[4] https://unit42.paloaltonetworks.com/cve-2020-17496