CTF_WRITEUPS-TryHackMe-CVE-2021-41773-

CTF_WRITEUPS/TryHackMe /CVE-2021-41773/

CVE-2021-41773/42013

Eine kleine Erklärung eines Apache-Pfad-Traversal-Bugs und einer unvollständigen Behebung

Task 1: Ein bisschen Hintergrund...

Eine kurze Geschichte

Am 5. Oktober 2021 wurde eine CVE veröffentlicht, die einen Pfad-Traversal-Angriff auf Apache HTTP Server v2.4.49 beschreibt. Mit der Nummer CVE-2021-41773 versehen, wurde sie mit folgender Beschreibung veröffentlicht:

Es wurde ein Fehler in einer Änderung der Pfadnormalisierung in Apache HTTP Server 2.4.49 gefunden. Ein Angreifer könnte einen Pfad-Traversal-Angriff nutzen, um URLs auf Dateien außerhalb des erwarteten Dokumentenwurzelverzeichnisses abzubilden. Wenn Dateien außerhalb des Dokumentenwurzelverzeichnisses nicht durch "require all denied" geschützt sind, können diese Anfragen erfolgreich sein. Zusätzlich könnte dieser Fehler die Quelle interpretierter Dateien wie CGI-Skripte preisgeben. Dieses Problem wird bekanntermaßen im Internet ausgenutzt. Dieses Problem betrifft nur Apache 2.4.49 und nicht frühere Versionen.

Lassen Sie uns dies aufschlüsseln und sehen, was das tatsächlich für uns bedeutet:

• Aus dem ersten Teil sehen wir, dass eine kürzliche Änderung den Fehler offengelegt hat. Pfadnormalisierung bedeutet, dass wir einen gegebenen Pfad in eine kanonische Form umwandeln, die die Software verstehen kann, und ihn so auf das tatsächliche Dateisystem abbilden. Dies führt uns bereits zu dem Verdacht auf einen Pfad-Traversal-Angriff, der potenziell unbeabsichtigte Dateien lesen kann.
• Der nächste Teil bestätigt unseren Verdacht, und wir sind in der Lage, einen Pfad-Traversal-Angriff zu nutzen, um Ressourcen außerhalb des beabsichtigten Bereichs zu lesen.
• Wir sehen, dass eine sehr spezielle Konfiguration erforderlich ist. Dateien außerhalb des Dokumentenwurzelverzeichnisses müssen explizit Berechtigungen erhalten. Dies ist nicht die Standardkonfiguration und sollte daher diesen Exploit gegen einen großen Teil der Apache-Hosts unwirksam machen (glücklicherweise).
• Der nächste Teil spricht über CGI-Skripte, was uns fälschlicherweise zu der Annahme verleitet, dass CGI für diesen Angriff aktiviert sein muss oder dass der Pfad in irgendeiner Weise CGI involviert.
• Selbst wenn unsere Konfiguration nicht direkt von diesem Fehler betroffen ist, möchten wir dennoch die verwundbaren Versionen so schnell wie möglich aktualisieren.

Viel später repariert...

Also hat Apache diesen Fehler behoben und die Version 2.4.50 veröffentlicht. Ende der Geschichte, oder? Nun, nicht ganz. Nur 2 Tage später, am 7. Oktober, wurde eine neue CVE veröffentlicht, die sich auf die vorherige bezog. Diese erwähnt, dass die Behebung des früheren Pfad-Traversal-Angriffs unvollständig war und wir immer noch traversieren konnten, wenn der betreffende Pfad eine Alias-Direktive verwendete, um seine URLs auf das Dateisystem abzubilden. Der CVE wurde die Nummer CVE-2021-42013 zugewiesen, mit der folgenden Beschreibung:

Es wurde festgestellt, dass die Behebung für CVE-2021-41773 in Apache HTTP Server 2.4.50 unzureichend war. Ein Angreifer könnte einen Pfad-Traversal-Angriff nutzen, um URLs auf Dateien außerhalb der durch Alias-ähnliche Direktiven konfigurierten Verzeichnisse abzubilden. Wenn Dateien außerhalb dieser Verzeichnisse nicht durch die übliche Standardkonfiguration "require all denied" geschützt sind, können diese Anfragen erfolgreich sein. Wenn CGI-Skripte auch für diese Alias-Pfade aktiviert sind, könnte dies eine Remote-Code-Ausführung ermöglichen. Dieses Problem betrifft nur Apache 2.4.49 und Apache 2.4.50 und nicht frühere Versionen.

Wie zuvor können wir hier einiges lernen:

• Während der erste Exploit angeblich behoben wurde, gibt es eine weitere Eingabe, die das Traversal ermöglicht (merken Sie sich das für später).
• Jetzt sind wir auf Alias-Pfad-Direktiven beschränkt.
• Verzeichnisse außerhalb der üblichen Pfade benötigen immer noch explizite Berechtigungen.
• Wenn CGI aktiviert ist, können wir zusätzlich zur einfachen Offenlegung auch RCE erreichen 😲

Während wir diesen Wahnsinn verarbeiten, werden wir uns in der nächsten Aufgabe mit der erforderlichen Konfiguration befassen.

Beantworten Sie die folgenden Fragen

1. Welche Version von Apache httpd war ursprünglich für diese CVE anfällig?

• 2.4.49

2. Diese Verwundbarkeit erfordert eine ungewöhnliche Fehlkonfiguration, um ausgenutzt werden zu können (Ja/Nein)

• Yea

---

Task 2 Was ist überhaupt ein Pfad-Traversal?

Ein bisschen Theorie

Ein Pfad-Traversal-Exploit ist ein Angriff, der darauf abzielt, auf Ressourcen zuzugreifen, die normalerweise nicht zugänglich sind, indem er Schwachstellen in der Pfadauflösung und/oder -normalisierung ausnutzt. Wir nutzen diese Art von Angriff normalerweise aus, indem wir uns mit der ..-Syntax rückwärts (auch als traversieren bezeichnet) über die angenommene Wurzel hinaus bewegen.

Normalisierung? Was?

Normalerweise ist bei der Angabe eines Pfades für einen Code, um eine Datei zu finden, ein absoluter Pfad erforderlich. Nennen wir diesen den kanonischen Pfad. Wenn stattdessen ein relativer Pfad angegeben wird, muss dieser in eine kanonische Form normalisiert werden, damit die Betriebssystembibliotheken, die diesen Pfad verwenden, die betreffende Ressource dann finden können. Dies ist natürlich eine Vereinfachung, aber der Kern bleibt bestehen.

Im Allgemeinen gibt es Plattformbibliotheken, die diese Normalisierung für uns durchführen, aber in C/C++ müssen wir normalerweise alles selbst machen. Dies kann zwar etwas Flexibilität bieten, aber auch leicht Schwachstellen einführen, wenn unsere Implementierung nicht perfekt ist.

Normalisierung von URLs

Ein HTTP-Server muss eine URL in einen kanonischen Pfad im Dateisystem übersetzen, um die richtige Datei zum Ausliefern zu finden. Obwohl es definitiv einige Filter gibt, um ein Traversieren über das Dokumentenwurzelverzeichnis hinaus zu verhindern, können einige Anwendungsfälle leicht übersehen werden. In diesem Fall nutzt der Exploit nicht nur die URL-Kodierung (darauf kommen wir gleich zurück), sondern auch einen Fehler in der Pfadnormalisierung des Alias-Moduls (angeblich).

Ein Exkurs zur URL-Kodierung

Definiert in RFC 3986 Abschnitt 2, ist die URL-Kodierung ein Schema zur Kodierung von Sonder- oder reservierten Zeichen innerhalb einer URL. Beispielsweise werden Leerzeichen in einer URL als +-Zeichen kodiert (insbesondere in Abfrageparametern). Wenn wir ein tatsächliches Plus kodieren möchten, müssen wir es mit einer sogenannten "Prozentkodierung" kodieren. Dabei wird dem US-ASCII-Hexadezimalcode des Zeichens einfach ein %-Zeichen vorangestellt. In unserem Beispiel kann das +-Symbol als %2B kodiert werden.

Jedes Zeichen kann URL-kodiert werden, und vollständig URL-kodierte URLs sind funktional äquivalent zur nicht kodierten Version. Aus dem RFC: Wenn zwei URIs sich nur in der Groß-/Kleinschreibung der hexadezimalen Ziffern unterscheiden, die in prozentkodierten Oktetten verwendet werden, sind sie äquivalent.

Was ist also mit Apache passiert?

Eine kürzliche Änderung im Pfadnormalisierungsmodul des Apache-Servers ermöglichte es dann, dass eine speziell gestaltete URL die Filter umgehen und über das Dokumentenwurzelverzeichnis hinaus traversieren konnte, was ein beliebiges Dateilesen auf dem System ermöglichte, wenn die Konfiguration dies erlaubte. Darüber hinaus ist, wenn das CGI-Modul aktiviert ist, auch eine beliebige Dateiausführung möglich!

Beantworten Sie die folgenden Fragen

1. Ein Pfad-Traversal-Exploit wird (wählen Sie die beste Antwort):

A) Beliebige entfernte Dateien einbinden, die auf dem Server verarbeitet werden. B) Beliebige lokale Dateien einbinden, die auf dem Server verarbeitet werden. C) Ermöglicht, dass beliebige Dateien vom Server preisgegeben werden. D) Keine der obigen.

• C

2. URL-kodieren Sie das .-Symbol

• %2E