Lab zur Rechteausweitung unter Linux: eine setuid-Binärdatei, eine sudo-Regel und ein Cron-Job zum Knacken

Jede lernende Person erhält eine eigene Ubuntu-VM mit einem zweiten Konto mit wenigen Rechten namens intern, dessen Name samt Passwort in der README steht. Root hat drei gewöhnliche Administrationsfehler hinterlassen: ein Hilfsprogramm mit einem Bit, das es nicht haben sollte, eine sudo-Regel, die nie eingegrenzt wurde, und ein Wartungsskript, das der Cron von root ausführt und das jeder ändern kann. Die Aufgabe ist, mit einem der drei root zu erreichen und aufzuschreiben, was genutzt wurde.

Die VM gehört allein der lernenden Person, ohne Verbindung zur Maschine einer anderen lernenden Person und ohne Verbindung ins Internet außer zum Paketarchiv von Ubuntu, PyPI, npm und GitHub. Die einzige Maschine, die sich angreifen lässt, ist also die, die das Lab ihr gegeben hat. Die Regel steht ganz oben im Lab und gilt nach dem Gesetz ebenso wie bei uns: Greifen Sie nur Ihre eigene VM an, niemals eine, die Ihnen nicht gehört, nach dem Computer Misuse Act 1990.

Was die Lernenden lernen

Wie eine gewöhnliche kleine Abkürzung in der Administration zum Weg zu root wird: ein Programm mit mehr Rechten, als seine Aufgabe braucht, eine sudo-Regel, die für einen Befehl geschrieben und nie überprüft wurde, und ein geplanter Job, der einer Datei vertraut, die jeder ändern kann. Jede davon zu finden heißt, eine Maschine so anzusehen, wie es eine Administratorin oder ein Administrator vor der Übergabe eines Kontos an andere tun sollte, nicht, einen Scanner laufen zu lassen. Das Lab passt zu einem ersten Kurs über Linux-Sicherheit, Systemhärtung oder einer Einführung in Penetrationstests.

Die Schwachstellen

Ein Hilfsprogramm, das eine Kopie eines gewöhnlichen Systemwerkzeugs ist, mit gesetztem setuid-Bit, sodass es immer als root läuft. Eine Zeile in der Konfiguration von sudo, die dem Konto mit wenigen Rechten erlaubt, ein gewöhnliches Programm ohne Passwort als root auszuführen. Ein Skript, das der Cron-Job von root jede Minute ausführt und das für jeden auf der Maschine beschreibbar ist. Die README, die das Lab im Home-Verzeichnis hinterlässt, nennt das zweite Konto und verrät keine der drei.

Im Browser ausführen

VM-Labs werden als Lab-Aufgabe in einem Modul gestellt, und das Beispiel steht auf der Seite des Labs. Die Maschine ist klein: eine CPU, 1 GB Arbeitsspeicher und 6 GB Festplatte.

  1. Lab hinzufügen. Fügen Sie in einem Modul, das Sie unterrichten, eine Aufgabe hinzu und wählen Sie die Karte „Ubuntu-VM-Lab“. Die Seite zeigt statt einer Compose-Datei eine kurze Beschreibung der Maschine.
  2. Vom Beispiel ausgehen. Die Seite bietet fertige Labs als Ausgangspunkt an. Wählen Sie „Rechteausweitung unter Linux“. Ein Beispiel zu verwenden ersetzt den Text, und „Rückgängig“ bringt Ihren zurück.
  3. Veröffentlichen und eine eigene Kopie starten. Veröffentlichen Sie, dann „Starten“. Das Einrichtungsskript des Labs legt beim ersten Start der VM das zweite Konto an, schreibt die Flag und bringt die drei Schwachstellen aus dem Archiv von Ubuntu ein, in etwa zehn Sekunden.
  4. Terminal öffnen. Öffnen Sie sein Terminal und lesen Sie README.md im Home-Verzeichnis: Sie nennt Namen und Passwort des zweiten Kontos und verrät keine der Lösungen.

Eine Basics-Lektion zu diesem Lab

Privilege Escalation Basics ist eine kleine Lektion, die in diesem Lab durchgearbeitet wird, einer Ubuntu-VM: Jeder Schritt ist erklärt und hat eine Schaltfläche „Ausführen“, die ihren Befehl in das Terminal der Maschine tippt und zeigt, was ausgegeben wurde. Lernende lernen das zweite Konto kennen, sehen nach, was es ausführen darf und was nicht, und lesen die drei Stellen, an denen root etwas hinterlassen hat, ohne eine davon zu nutzen.

Die Lektion sieht sich um und überlässt die eigentliche Aufgabe des Labs, root zu erreichen, den Lernenden, sie verteilt also keine Lösungen. Sie ist absichtlich klein: Sie zeigt Lehrkräften, was eine in einem Lab durchgearbeitete Lektion ist, und das Lab erledigt den Rest. Kopieren Sie sie in ein eigenes Modul, um sie zu ändern.

Wie abgegeben und gelesen wird

Dieses Lab hat absichtlich kein Bewertungsskript. Eine lernende Person auf der Maschine hat bereits eigene Administratorrechte, sodass sie jede Datei, die ein Skript als Nachweis lesen könnte, in einer Zeile selbst schreiben könnte, ohne über die Schwachstellen des Labs root zu erreichen. Eine Bewertung, die sich leicht fälschen lässt, ist schlechter als keine, daher besteht die Arbeit aus einem schriftlichen Bericht, den Sie lesen. Die Flag ist das eigene Ziel der lernenden Person und ein Anstoß für diesen Bericht, kein Nachweis. Die Schwachstellen anschließend zu beheben wird hier nicht verlangt, Sie können es als weiterführende Arbeit stellen.

  1. Zuweisen. Weisen Sie das Lab wie jede Aufgabe zu, auf Wunsch mit Fälligkeitsdatum. Jede lernende Person erhält eine eigene VM, die zwischen den Sitzungen erhalten bleibt. Wählen Sie in den Abgabeeinstellungen der Aufgabe „Ein Dokument oder eine PDF-Datei“, damit Lernende einen schriftlichen Bericht abgeben können.
  2. Bericht lesen. Die lernende Person gibt einen kurzen Bericht ab: welche Schwachstelle sie genutzt hat, welche Befehle es bewirkt haben und was die Flag lautete. Nichts auf der Maschine bewertet ihn, Sie lesen ihn also selbst.
  3. Bewerten. Bewerten Sie ihn wie jede Abgabe und geben Sie die Arbeit mit einer Begründung zur Überarbeitung zurück, wenn mehr nötig ist.

Die Definition auf GitHub

Die Datei ist die gesamte Lab-Definition, derselbe Text, den die Plattform ausführt: Größe, Einrichtungsskript und README. Kopieren Sie sie und ändern Sie, welches Programm das setuid-Bit trägt, welchen Befehl die sudo-Regel erlaubt oder was das beschreibbare Skript tut, um ein eigenes Lab zu erstellen.

Häufige Fragen

Können Lernende das gegen einen echten Server einsetzen?
Nein, und das Lab sagt das vor allem anderen. Die VM hat keine Verbindung zu einer anderen Maschine, und die README und diese Seite nennen beide die Regel: Greifen Sie nur Ihre eigene Kopie an, was der Computer Misuse Act 1990 zur Bedingung dafür macht, dies überhaupt zu tun.
Kann eine lernende Person es fälschen, ohne root zu erreichen?
Ja, und das Lab tut nicht so, als wäre es anders: Eine lernende Person auf der Maschine hat eigene Administratorrechte und könnte die Flag in einer Zeile lesen. Deshalb bewertet nichts automatisch. Der Bericht in den eigenen Worten und Befehlen der lernenden Person ist es, was Sie lesen.
Müssen die Lernenden die Schwachstellen anschließend beheben?
Nein, nicht in diesem Lab. Das Beheben ist eine eigene, weiterführende Arbeit, die eine Lehrkraft stellen kann.