Das L in Linux steht für laterale Netzwerkbewegung
Einführung
Was können Sie außer SSH noch tun?
Kandidatenauswahl
Protokolle, die eine sofortige Codeausführung ermöglichen
SNMP
Remote Desktop-Protokolle
Telnet
Berkeley r-Befehle
Ich lass das mal eben hier – Protokolle, die Dateiübertragungen zulassen
FTP
Samba
NFS
rsync
Remote-Ausführung durch Dateiübertragung
Remote-Persistenz
Webshells
Container sollten nicht undicht sein, oder?
Schützen Sie sich, bevor Sie sich selbst zerstören
Zusammenfassung
Einführung
Was laterale Netzwerkbewegungen betrifft, die sich nicht auf die Ausnutzung von Schwachstellen stützen, so gibt es viele legitime Protokolle und Tools, die Angreifer einsetzen können: PsExec, RDP, SSH, WMI und mehr. Die meisten von ihnen sind in der Regel nur auf Windows-Computern verfügbar. Bei Linux-Rechnern fällt einem dagegen nur ein Protokoll ein: SSH. In diesem Blogbeitrag werden wir uns mit anderen Protokollen in Linux befassen, mit denen laterale Netzwerkbewegungen erreicht (oder unterstützt) werden können.
Natürlich ist Linux kein Betriebssystem, sondern nur der Kernel. Richtiger wäre es zu sagen: Wir werden uns mit Linux-basierten Betriebssystemen oder Linux-Bereitstellungen beschäftigen. Es ist praktisch unmöglich, einen gemeinsamen Service oder ein gemeinsames Protokoll zu finden, der bzw. das direkt „out of the box“ über mehrere Bereitstellungen hinweg funktioniert (nicht einmal SSH ist in allen Bereitstellungen bereits installiert). Daher konzentrieren wir uns stattdessen auf die wichtigsten Protokolle und Services, unabhängig davon, mit welcher Linux-Bereitstellung sie geliefert werden.
Dieser Blogbeitrag ist nicht als Leitfaden für Linux-Hacking gedacht. Er soll Netzwerkschützer über potenzielle Bedrohungen informieren, die sich auf ihre Netzwerke auswirken können.
Was können Sie außer SSH noch tun?
Die meisten (wenn nicht alle) Protokolle, die wir in diesem Beitrag behandeln, sind nicht sofort verfügbar, sondern müssen auf eine bestimmte Weise konfiguriert werden, damit laterale Netzwerkbewegungen erreicht werden können. Wir geben keine Anleitungen zur missbräuchlichen Verwendung der in diesem Beitrag behandelten Protokolle.
Wir hoffen, das Bewusstsein für andere Protokolle zu schärfen, die so konfiguriert werden können, dass sie als Einfallstor für Angriffe missbraucht werden können. Ein entschlossener Hacker kann und wird die in diesem Beitrag behandelten Protokolle finden und missbrauchen, ohne dass wir ihm davon erzählen. Wir möchten, dass das Blue Team darauf vorbereitet ist.
Um den Verteidigern zusätzlich zu helfen, haben wir uns mit unserem Infection-Monkey-Teamzusammengetan. Infection Monkey ist eine automatische Open-Source-Prüfplattform für Eindringversuche und Angriffe, die Ihr Netzwerk auf viele gängige laterale Netzwerkbewegungen und Methoden der Netzwerkausbreitung testet.
Das Entwicklungsteam nutzte die Ergebnisse unserer Forschung und berücksichtigte sie als neue Exploit-Technik im Tool. Verteidiger können Infection Monkey verwenden, um ihr Netzwerk auf einige der in diesem Beitrag erwähnten Methoden der Remote-Ausführung zu testen.
Kandidatenauswahl
[Hinweis: In diesem Abschnitt geht es um die Methode, die wir verwendet haben, um interessante Ziele für laterale Netzwerkbewegungen zu finden. Wenn Sie an der Methodik nicht interessiert sind und lieber direkt bei den praktischen Maßnahmen einsteigen möchten, können Sie gerne direkt zu Protokollen übergehen, die eine sofortige Codeausführung ermöglichen.]
Da wir nach Protokollen und Services für laterale Netzwerkbewegungen suchen, können wir bei der Suche nach potenziellen Kandidaten sowohl den Aspekt des Betriebssystems als auch den Netzwerkaspekt berücksichtigen. Das bedeutet konkret: Wir können nach den gängigsten Prozessen in Linux-Computern oder an den gängigsten Listening-Ports suchen. Wir dürfen nicht das eine zugunsten des anderen vernachlässigen, da es unterschiedliche Implementierungen desselben Protokolls (unterschiedlicher Prozessname, gleicher Port) oder einen einzelnen Prozess mit mehreren oder sich ändernden Ports (zum Beispiel flüchtige Ports in RPC) geben kann.
Als wir die wichtigsten bei der Kommunikation mit Linux-Computern verwendeten Ports untersuchten, stellten wir fest, dass SSH (Port 22) die Liste dominierte. Es gab jedoch noch andere vielversprechende Kandidaten für eine Untersuchung: FTP (Port 21), SNMP (Port 161) und Sun RPC (Port 111).
Es gibt auch einige Ports, die von sshd verarbeitet wurden (dem SSH-Daemon-Prozess), obwohl sie nichts mit SSH zu tun haben. Wir gehen davon aus, dass diese in SSH-Tunneln verwendet werden und daher außerhalb unseres Untersuchungsbereichs liegen.
Nehmen wir beispielsweise die Ports 135 und 5985, die unter Windows für RPC bzw. WinRM verwendet werden. Wir erwarten diese Ports nicht auf Linux-Computern, wenn sie zumal von sshd überwacht werden. Wahrscheinlicher ist, dass ein SSH-Tunnel auf einem Linux-Computer geöffnet wurde, der extern verfügbar ist, um den Zugriff auf interne Maschinen zu ermöglichen. Da SSH-Tunnel den Traffic nur an einen anderen Empfänger weiterleiten, sind sie in Bezug auf laterale Netzwerkbewegungen in den Host des Tunnels nicht von großer Bedeutung.
Unsere Ergebnisse weisen auf zwei interessante Prozesse, die besondere Aufmerksamkeit verdienen: xinetd und rpcbind. Sie sind als Ziele für laterale Netzwerkbewegungen nicht brauchbar, da sie nicht viele Funktionen bieten. Sie werden überwiegend für Abfragevorgänge verwendet, mit denen Kommunikation und Ports anderen Prozessen zugeordnet werden. Stattdessen können wir sie nutzen, um andere interessante Services zu suchen.
xinetd (und sein Vorgänger inetd) wird zur Steuerung und Verwaltung von Daemons verwendet. Wenn wir uns die Standardliste der von ihm verwalteten Daemons ansehen, finden wir rexec sowie rlogin und rsh, die alle zur Suite der Berkeley r-Befehle gehören. Wir können auch verschiedene FTP-Daemons finden: VNC und Telnet.
rpcbind ist der RPC-Portmapper-Prozess für Sun RPC. RPC-Server registrieren sich beim Portmapper und Clients können den Portmapper abfragen, um den flüchtigen Port des Servers zu finden. Im Gegensatz zu MS-RPC verwendet Sun RPC Programmnummern, um bestimmte RPC-Server zu identifizieren, die bei der IANA (Internet Assigned Numbers Authority) registriert sind. Wenn wir uns die registrierten Programme anschauen, sehen wir einige interessante Namen, wie zum Beispiel rexec und NFS.
Protokolle, die eine sofortige Codeausführung ermöglichen
SNMP
24 % der getesteten Linux-Computer
Das Simple Network Management Protocol (SNMP) wird für die Überwachung verwendet. Computer führen einen Daemon-Prozess aus (in der Regel snmpd genannt), der Verbindungen über UDP-Port 161 registriert. Obwohl SNMP in der Regel zur Abfrage von Rechnerparametern und Statistiken verwendet wird, lassen sich einige Parameter und Konfigurationen auch per Remote-Zugriff über das Protokoll festlegen. Frühere Versionen von SNMP (v1 und v2) verfügen auch nicht über nennenswerte Verschlüsselung oder Authentifizierung und erfordern nur ein Passwort (eine sogenannte „Community“-Zeichenfolge), das aus dem Netzwerktraffic ausgelesen oder mit Brute-Force-Methoden erraten werden kann.
Wie sich zeigt, ist es auch möglich, Remote-Befehle über SNMP auszuführen. Dazu wird das EXTEND-Plug-in verwendet, das in älteren Versionen des SNMP-Agenten standardmäßig geladen wurde. Zwar ist diese Option in neueren Versionen von SNMP (v5.8+) aufgrund einer teilweise verwandten CVE deaktiviert. Doch es gibt immer noch Umgebungen, in denen die anfällige Version von SNMP installiert ist. Es ist auch möglich, einen eigenen SNMP-Agenten zu erstellen und das EXTEND-Plug-in zu aktivieren (Abbildung 1).
Abb. 1: Ausführen eines Remote-Skripts mit dem EXTEND SNMP-Plug-in
Unabhängig von den integrierten SNMP-Funktionen ist es auch ein Ziel für Angreifer, wobei manche Cyberkriminellen Schwachstellen von SNMP-Implementierungen in Routern und IoT-Geräten nutzen, um in Netzwerke einzudringen. Der Missbrauch von SNMP hat ein Ausmaß erreicht, dass die CISA (Cybersecurity & Infrastructure Security Agency) eine Empfehlung zu dem Protokoll veröffentlicht hat.
Damit Systeme auf ihre Anfälligkeit gegenüber dieser Bedrohung getestet werden können, haben wir mit unserem Infection-Monkey-Team ein Exploit-Plug-in für das SNMP Remote EXTEND-Plug-in entwickelt. Wenn Sie Infection Monkey ausführen, können Sie sehen, wie dieser Angriff in Ihrer Umgebung aussehen würde. Außerdem können Sie überprüfen, ob Ihre Sicherheitsvorkehrungen ausreichen, um einen Angriff abzuwehren. Der SNMP-Angriff ist in der neuesten Version von Infection Monkey verfügbar: v2.2.1.
Remote Desktop-Protokolle
10 % der getesteten Linux-Umgebungen
Nein, wir sprechen hier nicht speziell über RDP, das proprietäre Remote-Desktop-Protokoll von Microsoft (aber keine Sorge, das kommt noch). Es gibt andere Remote-Desktop-Protokolle, die auf Linux-Maschinen ausgeführt werden können. Sie sind wesentlich seltener als in Windows-Umgebungen, da sie für die gemeinsame Nutzung von grafischen Desktops vorgesehen sind und die meisten Linux-Server ohne Desktopumgebung installiert werden.
Wir haben jedoch festgestellt, dass diese Protokolle in einigen Netzwerken verwendet werden. Daher haben sie es in die Liste geschafft und sind hier mit berücksichtigt:
Das X Window System ist ein Desktop-Window-System, das für Unix verfügbar ist und auch Remote-Verbindungen überwachen kann. Es verwendet TCP-Ports 6000+ (es beginnt bei Port 6000, aber die Portnummer wird anschließend für jeden ausgeführten Desktop-Server erhöht).
VNC basiert auf dem Remote-Framebuffer-Protokoll (RFB) und verwendet TCP-Ports 5900+ (ähnlich wie bei X erhöht sich die Portnummer mit jedem ausgeführten Desktop-Server).
XRDP ist eine Implementierung des Microsoft RDP-Protokolls, die auf Nicht-Windows-Computern verwendet werden kann. Als eine RDP-Implementierung verwendet sie Port 3389.
Einige der Remote-Desktop-Protokolle sind sicherer als andere, aber prinzipiell können sie alle von Cyberkriminellen missbraucht werden. Es gibt auch mehrere Implementierungen der Protokolle in Linux, weshalb wir hier Portnummern anstelle von Programmnamen angegeben haben.
Telnet
4 % der getesteten Linux-Umgebungen
Ähnlich wie SSH und rlogin ist auch Telnet ein Protokoll für Remote-Konsole und -Steuerung. Es ist ebenfalls unsicher und unverschlüsselt, ähnlich wie rlogin, und anfällig für Abfangversuche oder Paket-Sniffing-Angriffe. Wir haben es nur in etwa 4 % der untersuchten Netzwerke festgestellt, doch das bedeutet: Es ist noch immer in Gebrauch und könnte Auswirkungen für Ihr Netzwerk haben. Das Protokoll verwendet den TCP-Port 23 oder 2323.
Berkeley r-Befehle
1 % der getesteten Linux-Umgebungen
Die Berkeley r-Befehle sind eine Suite von Programmen, die Remote-Operationen über Computer im Netzwerk hinweg ermöglichen. Ursprünglich wurden sie als Teil von BSD entwickelt, inzwischen jedoch größtenteils durch SSH ersetzt. Grund dafür sind in erster Linie die Sicherheitsbedenken gegenüber diesen Protokollen (keine Verschlüsselung und nur minimale oder gar nicht vorhandene Authentifizierung).
Trotzdem haben wir hier und da ein paar der Daemons der Suite gesehen. Es ist also noch zu früh, um sie ganz außen vor zu lassen. Es gibt drei Daemons, die wir herausstellen möchten:
rexec: ermöglicht Remote-Befehlsausführung; verwendet TCP-Port 512
rlogin: ermöglicht Remote-Anmeldung und -Konsole; verwendet TCP-Port 513
rsh: ähnlich wie rexec, erfordert jedoch keine Authentifizierung; verwendet TCP-Port 514
Ich lass das mal eben hier – Protokolle, die Dateiübertragungen zulassen
Selbst wenn Remote-Steuerung oder -Ausführung nicht möglich sind, kann allein die Möglichkeit, Dateien auf den Zielcomputer zu übertragen, die Entwicklung von Angriffen begünstigen. Sehen wir uns einmal PsExec als eine verbreitete Methode (und Tool) für laterale Netzwerkbewegungen an – auch wenn sie Windows-basiert ist.
Als Erstes kopiert PsExec seine Dienst-Binärdatei über SMB auf den Zielcomputer. Erst dann kann es den Dienst ausführen, indem es per Fernzugriff mit dem Dienst-Manager kommuniziert. Daher halten wir es für wichtig, auch die verschiedenen Möglichkeiten abzubilden, mit denen Angreifertools und Binärdateien auf den Zielcomputern platziert werden können. Wir haben uns auch mit einigen Methoden des Missbrauchs von Tool-Transfers zur Erzielung einer Fernausführung befasst. Wir werden darauf später in diesem Beitrag zu sprechen kommen.
FTP
31 % der getesteten Linux-Umgebungen
Das File Transfer Protocol (FTP) gehört zu den klassischen Protokollen. Es war das erste Protokoll auf Anwendungsebene, das in Kursen zu Netzwerken vermittelt wurde. Das für die Dateiübertragung verwendete textbasierte Protokoll ist nicht sicher, da es Klartext verwendet.
Samba
20 % der getesteten Linux-Umgebungen
Samba ist eine Programmsuite, die die Interoperabilität mit Windows unterstützt. Sie implementiert das SMB-Protokoll (TCP-Port 445) und kann Fileserver hosten oder mit ihnen interagieren. Sie kann auch in Active Directory integriert werden oder selbst als Domain-Controller dienen (Abbildung 2).
SMB ist an sich zwar nur ein Datenübertragungsprotokoll. Doch die Integration mit Active Directory bedeutet, dass Sie unter Umständen mehrere Implementierungen von RPC-Servern und -Clients finden, die eine gute Auswahl an potenziellen lateralen Netzwerkbewegungspfaden ergeben können.
Glücklicherweise konnten wir keinen ersichtlichen Weg finden, Samba für laterale Netzwerkbewegungen zu missbrauchen. Da Samba lediglich darauf ausgelegt ist, Dinge zum Laufen zu bringen, wurden unnötige RPC-Logik und -Funktionen großenteils nicht implementiert, sodass die Angriffsfläche begrenzt war. Außerdem gibt es weniger Prüfungen im Code, wie sich an verschiedenen Kommentaren im Quellcode erkennen lässt.
Es könnte ratsam sein, ein Red Team zu beauftragen, die Sicherheit des Domain Controllers zu überprüfen, wenn ein Samba Active Directory verwendet wird. Das gilt selbst dann, wenn es keine offensichtlichen seitlichen Bewegungspfade zu diesem Active Directory gibt.
Abb. 2: TODO-Kommentar im Quellcode von Samba
NFS
18 % der getesteten Linux-Umgebungen
Das NFS (Network File System) ist eine weitere Möglichkeit zum Erstellen von Fileservern. Es wird über Sun RPC (TCP-Port 111) aufgebaut. Es gibt viele RPC-Funktionen, die wir uns ansehen können, aber wir haben keine direkte Möglichkeit gefunden, über diese Funktion die Ausführung von Remote-Befehlen zu erreichen.
rsync
16 % der getesteten Linux-Umgebungen
rsync ist ein Dienstprogramm für die Dateiübertragung und Synchronisierung zwischen Computern im Netzwerk. Es kann als Service oder Daemon ausgeführt werden und Dateien über das dedizierte Protokoll (TCP-Port 873) bereitstellen. rsh oder SSH.
Remote-Ausführung durch Dateiübertragung
Wir können über Dateiübertragung sprechen, so viel wir wollen, aber es ist nicht sonderlich hilfreich, wenn die Angreifer die übertragenen Dateien nicht irgendwie ausführen können. Der Nutzer kann durch Täuschung dazu verleitet werden, die Datei selbst auszuführen. Daneben haben wir zwei Möglichkeiten in Betracht gezogen, die Ausführung zu erreichen. Beide erfordern eine Art Fehlkonfiguration oder eine (schwerwiegende) Lockerung der Sicherheitseinstellungen.
Remote-Persistenz
Es gibt viele legitime Speicherorte im Linux-Dateisystem, die für die Installation von Persistenz verwendet werden können. Bei lateralen Netzwerkbewegungen konzentrieren wir uns jedoch auf /etc/cron.hourly. Wenn ein Angreifer dort eine Datei mit Ausführungsberechtigungen hochladen kann, wird diese einfach zur nächsten vollen Stunde ausgeführt und es kommt so zur heiß begehrten lateralen Netzwerkbewegung.
Dazu benötigt ein Angreifer jedoch Sudo- oder Root-Berechtigungen, die nicht einfach zu bekommen sind. Leider ist es möglich, Fileserver auf unsichere Weise zu konfigurieren, was genau dieses Szenario ermöglichen würde (siehe zum Beispiel rsync). Warum sollte jemand diese Dienste mit so wenig Sicherheit konfigurieren? Weil es praktisch ist und einem das Leben erleichtert. Bitte seien Sie nicht so jemand: Schützen Sie sich.
Webshells
Statt des Zugriffs auf /etc wäre ein weit plausibleres Szenario der Remotezugriff auf einen Web-Root-Ordner eines aktiven Webservers. In diesem Fall dürfte es möglich sein, eine nutzerdefinierte Webshell hochzuladen und diese zur Ausführung von Remote-Befehlen zu verwenden. Es gibt viele online verfügbare Beispiele für Webshells, sodass Angreifer das Rad gar nicht neu erfinden müssen.
Container sollten nicht undicht sein, oder?
Ein weiterer Aspekt, der in den letzten Jahren immer beliebter geworden ist, sind Container. In unserer Forschung haben wir mehrere Fälle von Containerprogrammen beobachtet, die Verbindungen abhören und annehmen, und das scheint auch absichtlich erlaubt zu sein. Wenn Angreifer Zugriff auf einen Remote-Container-Manager erhalten, können sie ihr eigenes schädliches Image hochladen und es zur weiteren Ausbreitung innerhalb des Netzwerks verwenden.
Schützen Sie sich, bevor Sie sich selbst zerstören
Nachdem wir Möglichkeiten behandelt haben, wie Angreifer in Computer eindringen können, geht es jetzt um die Frage, wie sie sich fernhalten lassen.
Transparenz
Wie bereits erwähnt, wird keines der hier besprochenen Protokolle vorinstalliert und konfiguriert mit Linux geliefert. Jemand muss sie erst speziell installieren. Wichtig wäre hier zuallererst, einen guten Überblick darüber zu haben, was im Netzwerk läuft und an welchen Stellen kommuniziert (bzw. Kommunikation überwacht) wird. Oder wie der chinesische Philosoph Sun Tsu schreibt: „Wenn du weder den Feind noch dich selbst kennst, wirst du in jeder Schlacht unterliegen.“
Konfiguration
Wenn Sie eine Bestandsaufnahme Ihres Netzwerks vorgenommen und einen der hier besprochenen Dienste identifiziert haben, müssen Sie als Nächstes die Konfiguration dieser Dienste überprüfen. Beispielsweise ist ein aktueller SNMP-Agent, der für die Verwendung von SNMPv3 mit Kerberos-Authentifizierung konfiguriert ist, in Ordnung. Aber SNMPv2 mit einer leicht zu erratenden Community-Zeichenfolge? Eher nicht.
Sicherheit vor Verschleierung
Andere Protokolle oder Services können möglicherweise durch neuere, sicherere Protokolle ersetzt werden, zum Beispiel durch die Verwendung von SSH anstelle der r-Command-Suite oder Telnet. Einige Protokolle wie FTP oder rsync können auch über SSH eingekapselt werden. Der zusätzliche Nutzen liegt dabei in der Verschlüsselung, die SSH bietet. Natürlich müssen Sie sicherstellen, dass SSH auch korrekt konfiguriert ist, mit PKI oder starken Passwörtern, die nicht leicht zu knacken sind.
Segmentierung
Selbst wenn die gesamte Kommunikation gesichert ist, bedeutet das nicht, dass jeder Zugriff auf alles haben sollte. Ein flaches Netzwerk können Angreifer leicht ausbreiten. Ein segmentiertes Netzwerk stellt eine viel höhere Hürde dar (Abbildung 3).
Wenn man es Angreifern schwer macht und sie für jeden Schritt in das Netzwerk viele Ressourcen aufwenden müssen, geben sie den Angriff möglicherweise auf, weil er nicht kosteneffektiv ist. Außerdem gilt: Je mehr Aktionen Angreifer innerhalb des Netzwerks ausführen müssen, desto mehr Gelegenheiten bieten sich, den Angriff zu erkennen und Alarm zu schlagen. Anschließend können Sie eine Vorfallsreaktion einleiten, um den Angreifer herauszudrängen und die Einbruchsstelle zu schließen.
Abb. 3: Segmentierung als Strategie zur Abwehr von Angriffen. links: ohne Segmentierung; rechts: mit Segmentierung.
Zusammenfassung
In diesem Blogbeitrag haben wir auf verschiedene Protokolle und Programme hingewiesen, die auf Linux-Computern verbreitet sind und nützlich für Angreifer sein können, die versuchen, sich lateral durch das Netzwerk zu bewegen. Wir haben bewusst keine konkreten Beispiele aufgenommen, da wir auf die blaue Seite des Zauns abzielen. Wir möchten diese Protokolle stärker ins Bewusstsein rücken, damit Netzwerkschwachstellen vor Bedrohungen geschützt werden können.
Was Abwehr- oder Schutzmaßnahmen angeht, empfehlen wir die Verwendung der sicheren Versionen der in diesem Beitrag behandelten Protokolle (SNMPv3, SFTP anstelle von FTP usw.). Außerdem empfehlen wir, nach Möglichkeit flankierend Strategien zur Netzwerksegmentierung zu anzuwenden.
Für die meisten der hier erörterten Protokolle gibt es in der Regel eine kleine Untergruppe von Client- oder Serverprozessen sowie eindeutige Portnummern oder -bereiche. Insofern sollte es möglich sein, den Netzwerkzugriff einzuschränken, indem man bestimmte Ports oder Prozesse für die Untergruppe von Servern blockiert, für die dies erforderlich ist. Der normale Netzwerkbetrieb wird dadurch nicht nennenswert beeinträchtigt.
