Schwachstellendemonstration unter Ubuntu 9.04

Für eine Klasse zum Thema IT-Sicherheit möchte ich den Schülern die Eskalation von Berechtigungen demonstrieren. Dazu habe ich die exploit/linux/localListe im Metasploit Framework durchgesehen und dabei (unter anderem) exploit/linux/local/sock_sendpageab August 2009 festgestellt .

Ich habe eine VM mit 32-Bit - Ubuntu Server 9.04 (bis http://old-releases.ubuntu.com/releases/9.04/ubuntu-9.04-server-amd64.iso ) vom April 2009 uname -rgibt mir 2.6.28-11-generic. Laut Exploit-Beschreibung

Es wird angenommen, dass alle Linux 2.4 / 2.6-Versionen seit Mai 2001 betroffen sind: 2.4.4 bis einschließlich 2.4.37.4; 2.6.0 bis einschließlich 2.6.30.4

Daher sollte der von mir eingerichtete Ubuntu-Server für eine Demonstration geeignet sein. Ich konnte es jedoch nicht zum Laufen bringen.

Ich habe einen (regulären) Benutzer auf dem Server hinzugefügt und der SSH-Zugriff funktioniert. Aus dem Metasploit Framework heraus kann ich eine SSH-Sitzung mit erstellen auxiliary/scanner/ssh/ssh_login. Wenn ich jedoch den Exploit ausführe, bekomme ich

[*] Writing exploit executable to /tmp/mlcpzP6t (4069 bytes)

[*] Exploit completed, but no session was created.

Ich erhalte keine weiteren Informationen, auch nicht, wenn " DEBUG_EXPLOITtrue" eingestellt ist. /tmpwird auch aus der Metasploit-SSH-Sitzung heraus geschrieben:

$ sessions -c "touch /tmp/test.txt"
[*] Running 'touch /tmp/test.txt' on shell session 1 ([redacted])

$ sessions -c "ls -l /tmp"
[*] Running 'ls -l /tmp' on shell session 1 ([redacted])

total 0

-rw-r--r-- 1 [redacted] [redacted] 0 2016-03-28 09:44 test.txt

Ich habe auch versucht WriteableDir, das Basisverzeichnis des Benutzers auf dem Server festzulegen, aber ohne Änderungen. Was vermisse ich hier? Ist diese Version des Ubuntu-Servers (die ich absichtlich nicht aktualisiert habe!) Nicht anfällig?

Die Version 9.04 wurde bis zum 23. Oktober 2010 unterstützt . Die von Ihnen gefundene Sicherheitsanfälligkeit wurde im August 2009 gemeldet. Da die Version zu diesem Zeitpunkt noch aktuell war und unterstützt wurde, wurde die ISO-Version gepatcht und es handelt sich bei dem heruntergeladenen um eine aktuelle Version nicht mehr anfällig.

Außerdem haben Sie anscheinend sehr gut bewiesen, dass es nicht anfällig ist. Immerhin haben Sie den Exploit ausprobiert und es sieht so aus, als wäre er fehlgeschlagen.

Warum versuchst du nicht einen neueren Exploit? So etwas wie CVE-2013-2094, das zum Beispiel auch Ubuntu betreffen sollte .

Dies beantwortet nicht Ihre spezifischen Fragen, sondern bietet Ihnen mehr Möglichkeiten, Ihre Schüler zu zeigen ...

Möglicherweise möchten Sie auch die folgenden zwei Administrator-Fehlkonfigurationen berücksichtigen, die unter 'nix zu einer Fehlkonfiguration führen können (es gibt viele andere Möglichkeiten, eine' nix-Box zu konfigurieren, bei der priv esc möglich sein kann. ....

1. suid- und guid-Binärdateien im Besitz von root / root-Gruppe ( find / -uid 0 -perm -4000 -type f 2>/dev/nullund find / -uid 0 -perm -2000 -type f 2>/dev/null) und prüfen, ob sie von der Welt beschreibbar sind, damit Benutzer mit geringen Berechtigungen sie ändern können. Der Ordner, in dem sie existieren, kann von Ihrem Benutzer mit geringen Rechten beschrieben werden - für eine mögliche Bibliothekspfadinjektion. Was ist mit den Bibliotheken, die sie verwenden - können diese geändert werden? Überprüfen Sie die Werte aller DT_RPATHund DT_RUNPATHELF-Header in den Binärdateien mit einem der folgenden Befehle:

   • objdump -x ...
   • readelf -a ...
   • scanelf (von PaX)
   • elfdump (von Sun)
   • readelf -a binary | grep PATH

2. sudoers Mängel

   • NOPASSWD - Ein lokaler Angreifer kann diesen Zugriff verwenden, um seine Berechtigungen innerhalb des Betriebssystems zu erweitern, wenn der Benutzer vergisst, seinen Bildschirm zu sperren

   • Fehlende ausführbare Dateien in Sudoers - Einige ausführbare Dateien in der /etc/sudoersDatei sind nicht vorhanden. Wenn die ausführbaren Dateien erstellt wurden, können sie über sudo als root ausgeführt werden, was eine erweiterte Berechtigung ermöglicht.

   • Verwaiste Sudoer-Einträge - Die /etc/sudoersDatei enthält möglicherweise eine Reihe verwaister Einträge, für die in der /etc/passwdDatei kein entsprechendes Konto konfiguriert ist . Wenn ein Benutzer mit einem der verwaisten Namen erstellt wurde, bietet er dem Benutzer die Möglichkeit, die Berechtigungen für den vollständigen Root-Zugriff zu erweitern.

   • Einige Programme sollten nicht sudo-artig sein vi, :eoder verwenden Ctrl o und verwenden, :wum darauf zuzugreifen /etc/shadow.

   • Falsch durchdachter / falscher Befehl, der in der sudoers-Datei verwendet wird - ich sehe ihn oft httpdin sudoers -, also versuchen Sie als Benutzer mit niedrigen Rechten mit sudo-Zugriff, nur diesen Befehl auszuführen ( sudo -loder sudo -llzeigen Sie, was ein Benutzer tun kann): sudo /usr/bin/httpd -t /etc/shadowund sehen Sie sich den Fehler an.

   • Die Datei-Perms der in sudoers erwähnten Befehle und Dateien sind schwach - siehe meinen vorherigen Absatz über suid- und guid-Bit-Binärdateien von root