Haftungsausschluss

Ehrlich gesagt, ich weiß nicht, wie er auf die Idee gekommen ist, diese Schwachstelle zu finden. Deshalb kann ich nicht vollständig darüber erklären. Aber ich werde mein Bestes geben, um alles zu besprechen, was ich zu dieser CVE verstehe.

Schwachstelle

Diese CVE ist etwas interessant, weil sie zwei Schwachstellen enthält. Sie sind LFD Local File Disclosure und RCE Remote Code Execution. Cool! In diesem Beitrag werde ich beide Schwachstellen dieser CVE erklären.

Local File Disclosure (verwendet das no-cgi Docker-Image)

Fangen wir mit der Local File Disclosure-Schwachstelle an. Wenn ihr mit Apache vertraut seid, wisst ihr vielleicht, dass cgi-bin (Common Gateway Interface) der Standardpfad ist, der definiert, wie ein Webserver mit externen inhaltsgenerierenden Programmen in Apache 2.4.49 interagiert.

Aber dieser Pfad ist Forbidden für alle und sogar für Admins. Hmm, das ist interessant, oder?

Und wenn ihr mit der Local File Disclosure-Schwachstelle vertraut seid, wisst ihr vielleicht, dass die meisten LFD-Schwachstellen in verbotenen Pfaden auftreten.

Lasst uns also einfache LFI-Payloads im /cgi-bin/-Pfad testen.

Ich füge ../../../../../ vor /etc/passwd ein. (Wenn ihr wissen wollt, was ../ ist, schaut euch diesen Blogbeitrag an: Local file disclosure bypass)

Mit curl:

Mit burpsuite:

Wie ihr seht, haben wir mit dieser einfachen Payload einen Fehler erhalten. Bei curl bekamen wir einen 404-Statuscode Not Found und bei Burp einen 400 Bad Request-Fehler.

Das bedeutet, dass wir unsere Payload in URL-Kodierung umwandeln sollten. Also versuchen wir es und schauen, was wir bekommen.

Also kodiere ich den . in die URL. Hinweis: . ist %2E und auch %2e in der URL-Kodierung.

Mit curl:

Mit Burp:

Ja! Unsere Payload hat jetzt funktioniert. Wir können die /etc/passwd der Website lesen.

Ich hoffe, ihr habt jetzt die LFD-Schwachstelle dieser CVE verstanden. Fahren wir nun mit der RCE-Schwachstelle dieser CVE für Apache 2.4.49 fort.

Remote Code Execution (verwendet das with-cgi Docker-Image)

Um die RCE-Schwachstelle dieser CVE zu erklären, müsst ihr einige Grundlagen von RCE und Linux-Grundlagen verstehen.

Schaut euch diesen Blogbeitrag an, um zu erfahren Was ist RCE

Ah, ich denke, ihr dachtet, ich hätte mich geirrt, als ich sagte, dass ihr Linux-Grundlagen braucht. Nein. Ich habe mich nicht geirrt, denn wir brauchen sie tatsächlich. Also los!

Zuerst zeige ich die funktionierende Payload und erkläre, wie sie funktioniert.

Mit Curl:

Payload-Erklärung

Lassen Sie mich diese Payload erklären.

Wie ihr seht, ist der Pfad /cgi-bin/ und die Kodierung .%2e gleich. Aber es gibt jetzt zwei weitere Optionen: -d data und /bin/sh /bin/bash. Lasst mich erklären, warum wir diese brauchen.

/Bin/Bash

Erstens: Wir wollen Remote Code Execution, oder?

Wie ihr wisst, ist /bin/bash in Linux-basierten Systemen der Hauptbestandteil, um Befehle und Shells auszuführen. Also brauchen wir die bash, um unsere Befehle auf dem Webserver auszuführen. Schaut euch das an: Was ist Bash in Linux.

Data

Okay, sagen wir, wir können /bin/sh erreichen. Wir müssen nur unsere Befehle injizieren. Wir können unsere Injektion als Daten mit curl übergeben.

Unsere Payload ist also C|echo;id. Lasst mich erklären, was das ist.

C ist nichts. Wir können alles vor dem | setzen, z.B. Comdey|.

Das echo;id ist ein Linux-Trick. Ich sagte ja, dass man Linux-Grundlagen braucht. Echo-Grundlagen

Wenn wir dies zusammenfügen, erhalten wir RCE in Apache 2.4.49.

Danke!

Danke fürs Lesen, Leute. Dies ist mein erster Writeup für CVEs. Verzeiht mir, wenn ich es schlecht erklärt habe. Und gebt mir bitte Vorschläge.