Erste Erkennungen von Linux-Post-Exploitation mit Splunk Attack Range

Mit der erfolgten Microsoft-Veröffentlichung von Sysmon (System Monitor) for Linux ergeben sich neue Möglichkeiten für das Monitoring, die Entwicklung von Erkennungs­methoden und für die Verteidigung. Sysmon for Windows ist bei Entwicklern von Erkennungs­modulen und bei Blue Teams gleicher­maßen beliebt, weil es umfangreiche Einzelheiten zu System­aktivitäten und Windows-Logs liefert. Aufgrund der weitreichenden Informationen, die dieser Service/Treiber unter Microsoft Windows bereitstellt, ist er ausgesprochen hilfreich bei der Untersuchung von Angriffen und wenn es darum geht, Schad­verhalten auf Labor­computern zu replizieren.

Und jetzt: das Add-on for Linux Sysmon von Splunk

Das neue Add-on for Linux Sysmon von Cedric Hien, das in der Splunkbase zum Download bereitsteht, gibt uns – und euch – die Möglichkeit, Daten zu erfassen und Angriffe auf Linux-Hosts zu untersuchen. Als Erstes benötigen wir aber noch ein einfaches Verfahren zur Instrumentierung von Linux-Computern, damit wir uns die Ausführung von Payloads und die Sammlung von Angriffs­artefakten leichter machen. Und natürlich werden wir Splunk Attack Range verwenden, um uns Sysmon für Linux genauer ansehen.

Wir können also eine Attack Range mit Sysmon für Linux bauen und dann diesen Host zur Replikation von Angriffen verwenden. Wir haben darauf einige Tools getestet, die auf die Post-Exploitation von Linux ausgerichtet sind. Post-Exploitation bedeutet: Jemand ist bereits ins System gelangt und sieht sich nun nach Wegen um, seine Rechte zu erweitern, in weitere Netzwerk­segmente überzuspringen etc. All dies hinterlässt aber Spuren. Zuerst wurde also eine Attack Range mit aktiviertem Sysmon für Linux erstellt, dann haben wir untersucht, welche Artefakte nach der Ausführung beliebter Linux-Post-Exploitation-Tools wie LinPEAS, Mimipenguin, Linux Exploit Suggester und pspy entstanden sind.

Viele dieser Tools folgen ganz ähnlichen Befehlen, und manche nutzen dabei Referenzen wie die Prüfliste zur Rechteausweitung (privilege escalation checklist) von Linux. Viele dieser Befehle sind für sich genommen kein effektiver Indikator für Post-Exploitation, da sie auch von Admins für ganz legitime Zwecke verwendet werden. Dank des neuen Sysmon für Linux können wir jedoch große Mengen bisher nicht verfügbarer Daten einbeziehen und die einzelnen Prozesse, Services und User-Session-Informationen genauer untersuchen – und damit Anzeichen erkennen, die darauf hindeuten, dass die Tools zur Post-Exploitation verwendet werden.

LinPEAS

LinPEAS ist ein beliebtes Tool, das für die Suche nach möglichen Wegen zur Rechte­ausweitung auf Linux-, Unix- und MacOS-Hosts verwendet wird. Wie die folgenden Screenshots zeigen, ist die Ausführung praktisch selbsterklärend, und die Bandbreite der Prüfungen ist beachtlich.

Das Tool prüft die Betriebssystem­version, die Bibliotheken und die System­statistiken.

LinPEAS listet darüber hinaus mögliche Exploits auf dem Host auf, basierend auf System-, Service- und Bibliotheks­informationen sowie Version.

Hier habt ihr ein weiteres Beispiel, wie LinPEAS auf Rechte­ausweitung prüft, und zwar anhand von SUID-Ausführungsrechten.

Erkennung

Bei Tools, die im Rahmen der Linux-Post-Exploitation mögliche Schwach­stellen vorschlagen, ist es oft so, dass sie die System­dienstprogramme „strings“ und „grep“ suchen und. Diese Tools suchen umfassend und wiederholt nach wichtigen System­dateien wie /etc/shadow und /etc/passwd oder Verzeichnissen wie /usr/bin oder /tmp. Bei unseren Tests hat sich herausgestellt, dass einige der Tools gar nicht ausgeführt werden können, wenn „strings“ nicht auf dem System installiert ist.

Beispielereignis 
 

Unten seht ihr eine erste Suche, die uns viel darüber sagt, wie sich dieses Tool bei der Ausführung verhält.

Wie man sieht, hat dieses Tool eine ausgesprochen ausführliche Ausgabe und nutzt ausgiebig das Systemtool „grep“.

Linux Exploit Suggester

Der von Z-labs entwickelte und gewartete Linux Exploit Suggester ist ein weiteres gängiges Tool, mit dem sich Linux-Systeme auf Rechte­ausweitung prüfen lassen. Im Wesentlichen sucht es nach lokalen Schwach­stellen, die das System potenziell verwundbar machen, weil sich dadurch unter Umständen Rechte erweitern lassen. Es ist ein hervorragendes Tool für Penetrations­tester – aber wir wissen aus leidvoller Erfahrung, dass auch Schad­akteure sich oft das Arsenal der Verteidigung zunutze machen. Wie andere Tools auch prüft Linux Exploit Suggester zunächst die Kernel- und Betriebssystem­version auf der Suche nach entsprechenden Exploits und CVEs (Common Vulnerabilities and Exposures).

Wie ihr seht, gibt das Tool auf der Grundlage dieser ersten Checks seine Ergebnisse aus. Dies ermöglicht uns bereits eine Erkennung, indem wir diese anfänglichen Überprüfungen genauer unter die Lupe nehmen, etwa ob „uname“ zum Einsatz kommt (zum Prüfen auf die Linux- und die Kernel-Version). Allerdings gibt es noch eine besonders starke Signatur, durch die sich dieses Tool verrät: die Verwendung von grep und der Zeichenfolge „exploit-DB“. Mit exploit-DB bekommt man einen Link zu geeigneten Exploits an die Hand, die von exploit-DB.com heruntergeladen werden können, einer Community-Referenz für Pentester ebenso wie für Hacker.

 

In einer Produktionsumgebung wären diese beiden Prozesse zusammen sehr ungewöhnlich, es sei denn, die Umgebung wird gerade getestet.

Mimipenguin

Mimipenguin, benannt nach dem Windows-Kennwort­extraktionstool Mimikatz, versucht, Passwörter von Linux-Systemen abzufangen. Wie die anderen Tools dieses Beitrags benötigt es grep und strings zur Ausführung und zielt auf bestimmte Betriebs­systeme und Anwendungen wie Kali Linux, Gnome Keyring, LightDM (*nix-Display-Manager), Apache2-http-basierte Authentifizierung und VSFTPD FTP. Mithilfe einer Unmenge von grep-, strings- und ps-Prozessen kann Mimipenguin einen Finger­abdruck von Betriebs­system, Services und Anwendungen erstellen. Schließlich versucht es, Passwörter aus diesen Quellen abzufangen.

Dieses Tool funktionierte in der Attack Range nicht gut, da ihm mehrere Bibliotheken fehlten, auf die es angewiesen ist. Selbst in der vorkompilierten Version traten Fehl­funktionen auf. Allerdings können wir trotzdem Signaturen entwickeln, wenn wir den Quellcode lesen. Beispiels­weise sucht Mimipenguin mithilfe von grep und bestimmten Zeichen­folgen nach VSFTPD-Konfigurationen ( ps -eo pid,user,command | grep vsftpd | grep nobody | awk -F ' ' '{ print $1 }' ) oder Apache2-Konfigurationen ( ps -eo pid,user,command | grep apache2 | grep -v 'grep' | awk -F ' ' '{ print $1 }'. ). Zwar funktionierte dieses Tool nicht auf Anhieb in der Range, es funktionierte aber auf einem anderen Labor­system, auf dem es – wie oben zu sehen ist – erfolgreich Kennwörter extrahierte.

Pspy

Pspy ist ein Post-Exploitation-Tool, das für die Ausführung keinen Root-Zugang benötigt. Damit lassen sich Prozesse ausspähen, die von anderen Usern oder Services ausgeführt werden. Außerdem kann man mit pspy das Betriebs­system durchforsten und Prozesse aufspüren, die sich möglicherweise für eine Rechte­ausweitung eignen (zum Beispiel Cron-Aufträge).

 

Beispielereignis 

 

Erkennung

Zu Anfang war pspy in der Attack Range nur schwer zu entdecken. Wir hatten mit einer großen Anzahl von ps-Aufrufen zur Auflistung der Prozesse auf dem Computer gerechnet, aber pspy verwendet seine eigene Implementierung, um nach Prozessen zu suchen, und kann damit sogar kurzlebige Prozesse erkennen. Durch inotify_add_watch-Systemaufrufe unter /proc kann das Tool die Befehls­ausführung durch User und Services überwachen, indem es Informationen wie Befehlszeilen­argumente in /proc/PID/* liest und auswertet. Ein Beleg für dieses Verhalten findet sich in der Zeile cmdLine, errCmdLine := readFile(fmt.Sprintf("/proc/%d/cmdline", pid), p.maxCmdLength. Mit inotify_add_watch kann sich pspy registrieren und in Echtzeit Warnungen empfangen, wenn sich eine Datei oder der Inhalt eines Verzeichnisses ändert. So können kurzlebige Dateien und Prozesse während der kurzen Dauer ihrer Existenz erfasst werden. Ferner kann pspy Dateien und Prozesse in konfigurierbaren Intervallen untersuchen, etwa alle 1000 Millisekunden, und sich dabei auf bestimmte Verzeichnisse konzentrieren. Standardmäßig überwacht pspy ' /usr /tmp /etc /home /var /opt'.

 

Der Screenshot oben zeigt die Ausgabe einer pspy-Ausführung. Das Tool gibt eine große Menge an Informationen über Prozesse und User aus – pspy eignet sich also hervorragend, wenn man Informationen zu geplanten Services abgreifen oder arglosen Benutzern bei der Eingabe von Befehlen über die Schulter schauen möchte.

Wir hatten erwartet, viele Aufrufe der ps-Binary oder anderer Binaries zu sehen, aber stattdessen ist ein Großteil dieser Funktionalität in das pspy-Tool integriert. Mithilfe eines anderen Tools (nämlich Forkstat, siehe unten) konnten wir eine große Anzahl von inotify_add_watch-System­aufrufen feststellen. Außerdem können wir anhand des pspy-Quellcodes erkennen, dass diese Binary das Verzeichnis /proc auf Ereignisse überwacht, die mit der Erstellung von Prozessen zusammenhängen; dies geschieht durch eine eigene Implementierung der ps-Kernfunktionalität.

Im nächsten Screenshot sehen wir eine Reihe von System­aufrufen (inotifiy_add_watch). Die Funktion inotify_add_watch ermöglicht es, Änderungen an einem Verzeichnis effizient zu überwachen, ohne dass man das Verzeichnis wiederholt scannen müsste. Der Screenshot wurde mit Forkstat erstellt und zeigt uns auch die mit pspy zusammen­hängenden Prozess-IDs.

Leider werden diese Systemaufrufe aktuell nicht von Sysmon für Linux registriert, man kann sie aber mit anderen Tools wie Sysdig ausfindig machen. Im Rahmen der Untersuchung stießen wir auf etliche Monitoring-Agents, die relativ viel Rauschen verursachen, häufig Befehle ausführen und System­aufrufe tätigen. Dieses Rauschen kann die Erkennung von pspy schwierig gestalten und zu falsch positiven Ergebnissen führen. Wenn es jedoch keinen residenten Prozess gibt, von dem anzunehmen ist, dass er mit derselben Frequenz und immer vom gleichen User ausgeführt wird, dann dürfte die Ausführungs­häufigkeit dieses Prozesses darauf hinweisen, dass hier Post-Exploitation-Aktivitäten vorliegen – nur sind wir eben noch nicht in der Lage, die mit Sysmon für Linux zu messen.

AutoSUID

AutoSUID ist ein hervorragendes Open-Source-Post-Exploitation-Tool, das ausführbare SUID-Dateien sammelt, die dann für eine Rechte­ausweitung missbraucht werden können. SUID (set user id) ist ein Datei­recht, das die Ausführung als Eigentümer ermöglicht. Wenn die Ausführung einer Datei mit erweiterten Rechten (zum Beispiel root) durch nicht berechtigte Benutzer möglich ist, so stellt dies eine ernsthafte Schwachstelle dar.

Dieser Screenshot der Attack Range mit aktivem Sysmon für Linux) zeigt, dass AutoSUID einen bestimmten Befehl ausführt, der nach ausführbaren SUID-Dateien sucht (Perm-Notation 2000, 4000 und 6000). Im Grunde ist dies eine Suche nach ausführbaren Dateien, die zur Rechte­ausweitung verwendet werden können. Eine ausgezeichnete Quelle zu diesem Tool sind die Informationen zur Binary unter https://gtfobins.github.io/. GTFOBins ist „eine kuratierte Liste von Unix-Binärdateien, die zur Umgehung lokaler Sicherheits­beschränkungen bei fehl­konfigurierten Systemen verwendet werden können“, heißt es dort. Der Screenshot zeigt, dass in unserer Attack-Range-Linux-Instanz keine anfälligen SUID-Dateien gefunden wurden.

Erkennung

Bei AutoSUID lässt sich aus der Ausführung des Tools, dem Prozess­pfad und dem Verzeichnis eine eindeutige, präzise Erkennung gewinnen. Bei normalen Usern wäre diese Art von Berechtigungs­prüfung äußerst ungewöhnlich (außer wenn es sich gerade um eine Prüfung von Binary-Ausführungen oder die entsprechende Problem­lösung dreht). Von daher ist die Ausführung dieses Befehls ein Event, das weitere Analyse verdient.

LinEnum

LinEnum ist ein weiteres Post-Exploitation-Tool, das sehr effektiv sein kann. Es baucht weder sudo noch root und schafft eine umfassende Auflistung mit Footprinting des anvisierten Hosts. Die Ausführung ist aus den folgenden Screenshots zu ersehen.

Mit diesem Tool kann man eine ganze Menge nützlicher Informationen sammeln, einschließlich der Prozesse, die als root ausgeführt werden, welche Benutzer sudo ohne Kennwort ausführen können oder einfach die Liste der Admin-User (siehe Screenshot). Wie bei anderen Tools gab es auch hier eine gehäufte Ausführung von Befehlen wie „uname“ und „grep“ sowie Zugriff auf /proc/.

Das process_current_directory sollte man immer im Auge behalten, denn es kann der Verteidigung helfen, zu bestimmen, ob es sich um ein Monitoring-Tool, ein Skript oder um ein Binary handelt, das ein Angreifer eingeschleust hat; das gilt vor allem dann, wenn Monitoring-Agents im Einsatz sind, die ständig sehr ähnliche Befehle ausführen. Ohne Berücksichtigung des process_current_directory wäre das Risiko recht groß, dass Monitoring-Tools oder andere legitime Instrumente fälschlich als bösartig identifiziert werden. Wie oft führt beispiels­weise ein legitimer Benutzer eine Binary aus, die außerhalb seines $PATH liegt?

Die vorgestellten Erkennungen sind ein erster Ansatz zur Entdeckung und Bestimmung von Post-Exploitation-Aktivitäten auf Linux-Hosts. Wir konnten diese Aktivitäten auf der Splunk Attack Range mit Sysmon für Linux erfolgreich simulieren. Obwohl das Splunk-Add-on noch relativ jung ist und wahrscheinlich noch einige Änderungen erleben wird, können wir es sofort zu unserem Vorteil nutzen. Dank der Veröffentlichung von Microsoft Sysmon für Linux fällt die Post-Exploitation-Erkennung unter Linux also bereits jetzt deutlich leichter.

---

Mitwirkung

Wir möchten uns bei folgenden Personen für ihre Mitwirkung an diesem Beitrag bedanken:

• Lou Stella
• Eric McGinnis

_{*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.}