Für unsere technischen Aktivitäten und Nachforschungen betreiben wir diverse Server. Diese Server sind jeweils losgelöst und durch Firewalls von anderen Servern getrennt und enthalten außer den jeweiligen technischen Informationen keine weiteren relevanten Daten.
So sicher unsere primären IT-Systeme auch gegen Angriffe sind, unsere temporären Testsysteme werden oft pragmatisch betrieben.
Als wir vor kurzem Systembenachrichtigungen von einem dieser Test-Server erhielten, ahnten wir noch nicht, was passiert sein sollte. In einer der Meldungen war vermerkt, dass unser Server Portscans auf andere Systeme durchgeführt hatte.
Gut, dass wir alle Möglichkeiten der Spurensuche „inhouse” haben.
Da wir vor kurzem unseren Portscanner veröffentlicht hatten, mit dem Sie Ihre eigenen Systeme auf Dienste überprüfen können (https://scan.iternas.com), nahem wir zunächst an, dass es sich dabei um ein Problem mit diesem Dienst handelte. Bei genauerem Hinsehen war der betroffene Server aber für andere Zwecke eingesetzt worden, beide Server hatten nichts miteinander zu tun.
Nun war unserer Neugier erst recht geweckt!
Als erste Sicherheitsmaßnahme wurde der betroffene Server vom Internet getrennt. Beim Einloggen konnten wir dann feststellen, dass sich ein neuer Benutzer auf dem Server eingerichtet hatte! Auf unserem Server!
Der Benutzer mit leerem Namen (' ') hatte ein Verzeichnis auf dem Server erstellt und dort Dateien, Skripte und Programme angelegt:
$ ls -la
-rwxr-xr-x 1 root root 26 Dec 3 2016 a
-rwxr-xr-x 1 root root 20 Nov 29 2016 afterab
-rwxr-xr-x 1 root root 27 Mar 10 19:14 b
-rw-r--r-- 1 root root 286346 Jul 1 11:45 bios.txt
-rwxr-xr-x 1 root root 140 Mar 20 01:21 clear
-rwxr-xr-x 1 root root 223 Apr 10 17:09 goa
-rwxr-xr-x 1 root root 223 Jun 30 10:46 gob
-rwxr-xr-x 1 root root 30 Jul 1 03:09 lista.txt
-rwxr-xr-x 1 root root 283384 Mar 20 14:44 masscan
-rwxr-xr-x 1 root root 555 Jun 30 06:42 paused.conf
-rw-r--r-- 1 root root 60357 Jul 1 12:19 solved.txt
-rwxr-xr-x 1 root root 1551 May 28 2015 solve.py
-rwxr-xr-x 1 root root 82 Mar 20 18:57 sort
-rwxr-xr-x 1 root root 3250 Mar 16 21:36 s.py
-rwxr-xr-x 1 root root 453972 Jul 12 2004 ss
-rwxr-xr-x 1 root root 1826 Mar 20 19:24 v
-rwxr-xr-x 1 root root 827 Jun 30 16:44 words.txtUnter den Dateien befinden sich die zwei bekannte tools „masscan” und „ss”. Masscan wird verwendet, um Portranges zu scannen (Link auf virustotal.com). Durch die Größe des Programms (286 kb) und die Möglichkeit große Netze schnell zu scannen, wird das Programm oft für Angriffe verwendet.
"SS" konnten wir nicht genau zuweisen. Im Forum von Virustotal.com wird vermutet, dass es sich dabei um eine Botnetzsteuerung handelt (Link ins Forum). Die Dateien "a" und "b", sowie "afterab" sind kleine Skripte, die "masscan" ausführen und die Ausgabe des Programms in eine Textdatei schreiben. "Afterab" wird nach dem Scan ausgeführt und verarbeitet die Informationen, die der Scan produziert hat.
Das Python Skript "s.py" versucht das Passwort des Servers zu erraten. Dazu werden Schlagwörter, die in den Serverinformationen vorhanden sind, erweitert, um so eine Wörterbuch-Attacke durchzuführen. Zum Beispiel werden durch reverseDNS Namen der Betreiber gesucht und dann Bindestriche und andere Sonderzeichen an das Passwort hinzugefügt.
Dann versucht das Skript, mit dem erstellten Passwort eine Verbindung zu dem Server aufzubauen und sich anzumelden. Bei erfolgreichem Login wird die Datei "lista.txt" um die IP-ADressen, den Benutzernamen und um das Passwort erweitert.
Was weiter mit den Dateien passiert ist, konnten wir leider nicht mehr feststellen. Alle Log-Dateien für den Zeitraum, in dem der Angriff stattgefunden hat, wurden gelöscht, bevor wir sie sichern konnten. Automatischer Mitprotokollierung auf einen externen Log-Server: Fehlanzeige, es war ja nur ein Testserver.
Beim Analysieren der offenen Ports des Servers konnten wir zwei weitere Dienste finden, die sowohl auf IPv4 als auch IPv6 den Port 6666 gelauscht haben. Die oben genannten Programme betrieben auf diesen Ports eine Chatsoftware, um sich mit einen IRC-Kanal eines Internetchats zu verbinden. Die Programme überprüften regelmäßig, ob sie sich noch in der Cron-Datei befanden, um auch nach einem Neustart noch aktiv zu sein.
Dieses vorgehen diente zugleich als Tarnung: Die Cronjobs waren damit nicht mit ihren Namen in der Prozessliste auffindbar. ("ps aux")
Wie kamen die Angreifer auf unser System?
Der betroffene Server wird sehr wenig genutzt. Beim Einrichten wurde ein initiales Passwort vergeben, dass nicht ausreichend sicher war. Alle unsere Systeme lassen SSH-Zugriffe nur per Zertifikat zu. Bei diesem Server wurde der Schritt aber vergessen/bewusst unterlassen. Damit konnte das Passwort erraten und von außen genutzt werden. In den Log-Dateien des gehackten Servers konnten wir den Bereich des Logins einschränken, indem wir den Zeitraum wählten, indem die "solved.txt" erstellt wurde. Normalerweise lehnt unser Server 10-15 Login-Versuche ab. In der Zeit des Hacks stieg die Anzahl auf einige 100 Versuche pro Sekunde.
Fazit
Die Einrichtung eines sicheren Passworts ist unumgänglich. Auch wenn es sich bei dem Passwort nur um ein temporäres Passwort während des Installationsvorgangs handelt, muss darauf geachtet werden, dass es sicher ist. Zu schnell kann sonst ein unsicheres Passwort in das Produktionsstadium übernommen werden. Wir haben den Server deaktivert, dann die Daten gelöscht und den Server komplett neu installiert. Das ging in diesem Fall relativ leicht, weil der Server nur für kleinste Aufgaben benötigt wurde und keine aufwändige Konfiguration voraussetzte.
Administrative Zugänge sollten nach diesen Regeln abgesichert werden:
Es gibt Funktions-Accounts, welche zentral verwaltet werden.
Alle Passwörter sind nur begrenzt gültig, bspw. 3 Monate. Danach muß ein neues Passwort vergeben werden.
Die Passwörter sollten mindesten 8 Stellen lang sein, aus Buchstaben und Zahlen bestehen und keine Wörter enthalten.
Eine Authentifizierung mit einem 2. Faktor, bspw. einer Token-App, ist bei öffentlich erreichbaren kritischen Services notwendig.