XOR.DDoS und Groundhog: Angriff auf Linux-Server oder wie man Meldungen künstlich aufbläst

30 Oktober 2015 Kein Kommentar Autor: Jürgen (jdo)

Über ein paar Ecken wurde ich in eine Pressemitteilung involviert – wie und warum ist egal. Auf jeden Fall ging es um einen Gesprächstermin zu einer Meldung, die von Security-Löchern in einem Linux-Server handelte. Es wurde gesagt, dass die Malware-Typen XOR.DDoS und Groundhog auf dem Linux-Server wüteten. Beziehungsweise nutzte man die Server als Teile von DDoS-Angriffe (Distributed Denial of Service).

Die Malware wurde installiert, nachdem man sich via SSH Brute Force Zugang zum Server verschafft hat. Nachdem sich der Kunde wegen komischer Vorgänge auf dem Server gemeldet hatte, entdeckte man die Malware und konnte die IP-Adresse nach China zurückverfolgen.

Während XOR.DDoS bekannt war, erschien Groundhog neu. Nach weiterer Analyse kam man aber zu dem Entschluss, dass es sich nur um verschiedene Module der gleichen Malware handelte, die auch ähnlichen Unsinn durchführen.

Das war im Endeffekt die Meldung und darüber wollte man sprechen.

Was ist komisch an der Meldung zur Security des Linux-Servers?

Ich konnte es nicht lassen und musste etwas nachbohren, weil das irgendwie komisch klang. Also wurden über diverse Kanäle ein paar Fragen an die entsprechende Security-Firma gestellt (die Formulierung stammt nicht von mir, ich gebe sie einfach weiter) und nach ein paar Tagen kamen dann folgende Antworten zurück:

1. In der Vergangenheit sind Cyberkriminelle immer wieder auf Servern eingebrochen und haben Malware installiert. Was ist das Besondere an diesem Server-Angriff?

Ja, SSH Brute Force Angriffe gibt es immer wieder, in der Tat. In der Regel ist es aber schwierig, eine Spur zu den Angreifern zu finden. Jetzt waren wir in der Lage, den Weg zurück zu einer chinesischen IP-Adresse zu verfolgen. Auch die Kombination der zwei Schadcodes (XOR.DDoS und Groundhog) ist einzigartig. Es gilt zu verstehen, dass heutzutage bei DDoS-Attacken die Hoster von Angriffen oft ebenfalls zu den Opfern gehören. Da Bot-Netzwerke oft soweit verzweigt sind, wird es in der Regel sehr schwer, die wahren Täter zu finden. In diesem Fall waren wir in der Lage, Einblicke über die Menschen hinter dem Angriff zu erhalten.

2. Warum konnten die Angreifer so schnell root-Zugriff erreichen? Welche Anmeldemöglichkeiten gab es, um sich auf dem Server anzumelden?

Der Server befand sich in einer Testumgebung. Das Schutzniveau war deshalb relativ niedrig. Das machte es den Angreifern leicht, sodass sie den Zugang Brute-forcen konnten; zum Root-Zugriff ist es nach Knacken des Passwortes nicht mehr weit. Unsere Forschung zeigt die gescheiterten Anmeldeversuche. Nach zwölf Tagen oder weniger hatten die Angreifer Zugang und verwendeten das SSH-Service-Passwort, um die Malware einzuschleusen. Mit erweiterten Zugriffsrechten der beiden schädlichen Payloads war es einfach, die Steuerung der Server zu übernehmen.

3. Welche Mittel und Wege gibt es für Unternehmen, um sich gegen einen solchen Angriff zu schützen bzw. diesen zu verlangsamen?

Es sollten zunächst grundlegende Sicherheitsmaßnahmen verwendet werden, insbesondere Segmentierung, Least Privilege und Überwachungs- und Kontrollsysteme für alle Systeme in einem Netzwerk. Neben den Tools für Serversicherheit sollten Unternehmen die Nachbearbeitung bedenken, um forensische Untersuchungen zu erleichtern. Check Point sieht Argumente, dass die verwendeten XOR.DDoS und Groundhog Malware-Varianten vom gleichen Autor stammen. Wir haben auch herausgefunden, dass die Angreifer ihre Netblocks für die Boot-Vorgänge verändert haben, um ihre Tätigkeiten zu verschleiern.

Die Investition in entsprechende Sicherheits-Tools ist natürlich wichtig, aber langfristig braucht es gemeinsame Anstrengungen, um die Menschen hinter solchen Angriffen zu finden. Solche Kriminelle sind nicht nur eine Gefahr für die Nutzer von Servern, sondern auch für das Gemeinwohl des Gemeingutes Internet an sich. Der Angriff liefert ein gutes Beispiel: Ein Blick auf die Check Point ThreatCloud (siehe Bericht Seite 6) zeigt die globalen Auswirkungen der organisierten Kampagne.

4. Welche Möglichkeiten bieten hier Intrusion Prevention Systeme wie Fail2Ban?

Kontrollen wie Fail2Ban hätten geholfen, aber weil der Server in einer Testumgebung war, wurden keine Schutzmechanismen eingesetzt.

Fassen wir also zusammen

Im Endeffekt konnten die Cyberkriminellen in die Server einbrechen, weil die Administratoren extrem geschlampt haben.

Das Problem ist ja nicht, dass die Angreifer eine Lücke im Linux-Server an sich ausgenutzt hätten, sondern Sie sind aufgrund mangelnder Security in den Server eingebrochen. Das hat man in der Meldung aber nicht erwähnt und diese somit künstlich aufgeblasen.

Weiterhin ist man meiner Frage etwas ausgewichen, ob die Server SSH via root zugelassen haben. Das vermute ich nämlich zusätzlich, kann es aber nicht beweisen.

Es ist ja sowas von scheißegal, wie viele Malware-Typen die böswilligen Hacker installieren konnten und was die angestellt haben. Fakt ist, dass die Security auf den Linux-Servern unter aller Sau war, was man kaum dem Betriebssystem in die Schuhe schieben kann. Oder wue es Gerhard Polt ausdrücken würde: „Wenn ein Nichtschwimmer in einem See ersäuft, dann ist das nicht tragisch, sondern konsequent.“

Im Endeffekt wollte die Security-Firma ihre eigenen Produkte verkaufen – was nicht verwerflich ist. Zu suggerieren, dass Linux per se anfällig für SSH Brute Force ist, indem man Teile der Geschichte unter den Tisch fallen lässt … hmmm.

In diesem Fall hätte sich die ganze Sache sehr wahrscheinlich durch die Installation von Fail2Ban verhindern lassen. Das beste ist, dass Fail2Ban in den Repositories der meisten Linux-Distributionen zu finden ist. Auf meinem Ubuntu-Serverchen musste ich nichts weiter tun als sudo apt-get install fail2ban. Die Überwachung von SSH ist zumindest bei Ubuntu 14.04 LTS per Standard aktiviert und Fail2Ban wird nach sechs ungültigen Versuchen aktiv.

Fail2Ban ist in den Ubuntu-Repositories und gehört auf jeden Linux-Server

Fail2Ban ist in den Ubuntu-Repositories und gehört auf jeden Linux-Server

Die korrekte Meldung wäre also gewesen: Durch Schlamperei oder Unwissen von Administratoren wurden Linux-Server kompromittiert, was sich aber sehr einfach hätte verhindern lassen.

Du kannst gerne Deinen Senf zu diesem Beitrag geben: Hier geht es zu den Kommentaren




Schreiben macht durstig! Eine kleine Erfrischung kann daher nie schaden. Wem dieser freie Artikel gefallen hat, der darf mir gerne einen frisch gezapften Hopfen-Tee ausgeben (Paypal - der Spenden-Knopf
oder bitcoin - Adresse: 1NacVNwcLLePUVv8uSafu5Ykdwh8QyDfgK). Ich freue mich über jede noch so kleine Spende. Vielen Dank und Prost!
 Alle Kommentare als Feed abonnieren

Antworten