8
Botnet Windigo: Über 10.000 kompromittierte Linux-Server als Malwareschleudern missbraucht - Update
Es wird mal wieder Zeit für eine Überprüfung der Linux Server. Das Windigo-Botnet treibt sein Unwesen. Hier die einzelnen Schritte in Kuzform:
1. Überprüfe als erstes, ob überhaupt ein SSH-Server installiert ist. Hat Dein Linux System keinen SSH-Daemon und auch keinen "ssh"-Befehl funktioniert das Testscript natürlich nicht. Dann starte die Überprüfung mit Punkt 3.
2. Der Test sollte nicht auf einem System ausgeführt werden, das OpenSSH mit dem X.509-Patch von Roumen Petrov einsetzt. Dieser Patch fügt dem SSH-Daemon die Unterstützung für X.509-PKI-Zertifikate hinzu und enthält seit September 2013 eine -G Option. Normalerweise gibt es sonst die Option -G nicht (nur bei den infizierten Systemen meldet -G durch einen Fehler in der Programmierung einen Status).
3. Ist ein SSH-Server vorhanden und er hat keinen X.509-Patch (siehe Punkt 2), dann gebe im angemeldeten Zustand folgenden Befehl ein:
laut Sicherheitsforschern bei Eset testen, ob der Server schon Teil des Windigo-Botnets ist.
Erscheint "System infected" sollte man mit Schritt 4 das Ergebnis validieren:
4. Prüfe wie groß die Datei libkeyutils.so auf deinem System ist. Diese liegt normalerweise unter /usr/lib/ oder nur /lib/ und sollte unter 20 KB groß sein.
Man findet sie mit Hilfe des "locate"-Befehls:
Bei mir erscheinen dann zwei Dateien (Ubuntu 12.04 LTS):
Die erste Datei "/lib/x86_64-linux-gnu/libkeyutils.so.1.4" ist nur ein Link auf "libkeyutils.so.1.4".
Mit dem dir Befehl kann man sich die Größe anzeigen lassen:
Die Datei ist bei mir 17 KB groß. Normalerweise ist die lib ca 10 bis 20 KB groß.
Ist die Datei aber um die 30 KB groß, seid ihr wahrscheinlich mit dem Windigo Bot infiziert.
Weitere Informationen über die Testmöglichkeiten findet ihr unter Ist mein Linux Server mit dem Windigo Botnet infiziert?
Gruß
Frank
http://www.golem.de/news/botnet-windigo-10-000-kompromittierte-linux-se ...
1. Überprüfe als erstes, ob überhaupt ein SSH-Server installiert ist. Hat Dein Linux System keinen SSH-Daemon und auch keinen "ssh"-Befehl funktioniert das Testscript natürlich nicht. Dann starte die Überprüfung mit Punkt 3.
2. Der Test sollte nicht auf einem System ausgeführt werden, das OpenSSH mit dem X.509-Patch von Roumen Petrov einsetzt. Dieser Patch fügt dem SSH-Daemon die Unterstützung für X.509-PKI-Zertifikate hinzu und enthält seit September 2013 eine -G Option. Normalerweise gibt es sonst die Option -G nicht (nur bei den infizierten Systemen meldet -G durch einen Fehler in der Programmierung einen Status).
3. Ist ein SSH-Server vorhanden und er hat keinen X.509-Patch (siehe Punkt 2), dann gebe im angemeldeten Zustand folgenden Befehl ein:
ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"
Erscheint "System infected" sollte man mit Schritt 4 das Ergebnis validieren:
4. Prüfe wie groß die Datei libkeyutils.so auf deinem System ist. Diese liegt normalerweise unter /usr/lib/ oder nur /lib/ und sollte unter 20 KB groß sein.
Man findet sie mit Hilfe des "locate"-Befehls:
locate libkeyutils.so
/lib/x86_64-linux-gnu/libkeyutils.so.1
/lib/x86_64-linux-gnu/libkeyutils.so.1.4
Mit dem dir Befehl kann man sich die Größe anzeigen lassen:
dir /lib/x86_64-linux-gnu/libkeyutils.so.1.4
-rw-r--r-- 1 root root 14360 Okt 17 2011 /lib/x86_64-linux-gnu/libkeyutils.so.1.4
Die Datei ist bei mir 17 KB groß. Normalerweise ist die lib ca 10 bis 20 KB groß.
Ist die Datei aber um die 30 KB groß, seid ihr wahrscheinlich mit dem Windigo Bot infiziert.
Weitere Informationen über die Testmöglichkeiten findet ihr unter Ist mein Linux Server mit dem Windigo Botnet infiziert?
Gruß
Frank
http://www.golem.de/news/botnet-windigo-10-000-kompromittierte-linux-se ...
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 233096
Url: https://administrator.de/forum/botnet-windigo-ueber-10-000-kompromittierte-linux-server-als-malwareschleudern-missbraucht-update-233096.html
Ausgedruckt am: 14.05.2025 um 22:05 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
na geil, ich hab diesen Befehl mal durch die Console gejagt und bekomme ein " System infected", läuft...
Hast du ne Idee was ich da jetzt machen kann?
VG
na geil, ich hab diesen Befehl mal durch die Console gejagt und bekomme ein " System infected", läuft...
Hast du ne Idee was ich da jetzt machen kann?
VG
Hi @licorit,
die Sicherheitsforscher raten Alle zum "Neu aufsetzten des Systems", da man aktuell noch nicht ermitteln kann, welche weiteren Daemons infiziert sein könnten. Großes Sorry!
Hier noch ein Tipp für das neue System. Ändert den Defaultport (22) vom SSH Daemon auf irgendetwas anderes und schaltet ICMP per Firewall (also das Ping aus). Dadurch können Bots das eigene System nicht so schnell entdecken.
Man kann dem SSH Client den neuen Port mit "-p Portnummer" und dem scp-Client mit "-P Portnummer" mitgeben. Beispiel:
Es gibt aber noch eine elegantere Lösung: Man legt im eigenen .ssh/ Verzeichnis eine Datei mit dem Namen "config" an (~/.ssh/config) und trägt folgendes ein:
Danach kennen alle ssh, scp, etc. Befehle den neuen Port und man kann sie wie gewohnt ohne Angabe des Ports ausführen.
Gruß
Frank
die Sicherheitsforscher raten Alle zum "Neu aufsetzten des Systems", da man aktuell noch nicht ermitteln kann, welche weiteren Daemons infiziert sein könnten. Großes Sorry!
Hier noch ein Tipp für das neue System. Ändert den Defaultport (22) vom SSH Daemon auf irgendetwas anderes und schaltet ICMP per Firewall (also das Ping aus). Dadurch können Bots das eigene System nicht so schnell entdecken.
Man kann dem SSH Client den neuen Port mit "-p Portnummer" und dem scp-Client mit "-P Portnummer" mitgeben. Beispiel:
ssh -p 1234 name@server oder
scp -P 1234 user@server:/Verzeichnis/Quelle ~/Ziel
Es gibt aber noch eine elegantere Lösung: Man legt im eigenen .ssh/ Verzeichnis eine Datei mit dem Namen "config" an (~/.ssh/config) und trägt folgendes ein:
Host MeinServer1
Port 1234
User MeinLoginName
Host MeinServer2
Port 4321
User MeinLoginName2 Danach kennen alle ssh, scp, etc. Befehle den neuen Port und man kann sie wie gewohnt ohne Angabe des Ports ausführen.
Gruß
Frank
Hm echt doof.
Es hat meine virtuelle Ubuntu Installation erwischt.... ich frag mich nur WIE das passieren konnte, das System stellt owncloud zur Verfügung und in der FW waren nur die Ports offen, die für den Betreib benötigt werden.
SSH hab ich nie benutzt um auf die den Server zu kommen...
Nachträglich die SSH Ports blocken bringt nix?
Echt ärgerlich grad, das System rennt gerade mal seit nem knappen Monat und dann sowas
Es hat meine virtuelle Ubuntu Installation erwischt.... ich frag mich nur WIE das passieren konnte, das System stellt owncloud zur Verfügung und in der FW waren nur die Ports offen, die für den Betreib benötigt werden.
SSH hab ich nie benutzt um auf die den Server zu kommen...
Nachträglich die SSH Ports blocken bringt nix?
Echt ärgerlich grad, das System rennt gerade mal seit nem knappen Monat und dann sowas
Zitat von @sk-it83:
Echt ärgerlich grad, das System rennt gerade mal seit nem knappen Monat und dann sowas
Echt ärgerlich grad, das System rennt gerade mal seit nem knappen Monat und dann sowas
Bei mir hat er auch "System infected" gemeldet. Nur da ist 100% kein SSH Zugang gegeben.
Ich würd mir das erst noch mal genauer ansehen bevor du ne neuinstallation machst.
Was sagt den der Befel "ssh" für sich alleine.
Hi,
Naja, auf deinem System könnte ein fremd modifizierter SSH-Daemon laufen. Klar kannst du jetzt die Ports zumachen und evtl. kann der Bot deinen Server kurzzeitig nicht mehr kontrollieren. Aber was hält ihn zurück, einen anderen Port von innen heraus aufzumachen? Ich denke dir bleibt nichts anderes übrig, als das System neu zu installieren. Wenn es eine VM ist kannst du evtl zu älteren Snapshots springen und den Test wiederholen.
Aber er war installiert und hat auf Port 22 auf Verbindungen gewartet und geantwortet. Daher -> bei jedem neuen Rechner Port 22 auf irgendwas anderes verschieben und ICMP ausschalten!
Gruß
Frank
Nachträglich die SSH Ports blocken bringt nix?
Naja, auf deinem System könnte ein fremd modifizierter SSH-Daemon laufen. Klar kannst du jetzt die Ports zumachen und evtl. kann der Bot deinen Server kurzzeitig nicht mehr kontrollieren. Aber was hält ihn zurück, einen anderen Port von innen heraus aufzumachen? Ich denke dir bleibt nichts anderes übrig, als das System neu zu installieren. Wenn es eine VM ist kannst du evtl zu älteren Snapshots springen und den Test wiederholen.
SSH hab ich nie benutzt um auf die den Server zu kommen...
Aber er war installiert und hat auf Port 22 auf Verbindungen gewartet und geantwortet. Daher -> bei jedem neuen Rechner Port 22 auf irgendwas anderes verschieben und ICMP ausschalten!
Gruß
Frank
Hi @wiesi200,
hier noch zwei Ergänzungen zur Bot Erkennung:
1) Man sollte prüfen wie groß die Datei libkeyutils.so ist. Die liegt normalerweise unter /usr/lib/ oder nur /lib/ und sollte unter 20 KB groß sein.
Man findet sie auch mit Hilfe des Befehls:
Bei mir erscheinen dann zwei Dateien (Ubuntu 12.04 LTS):
Die erste Datei "/lib/x86_64-linux-gnu/libkeyutils.so.1.4" ist nur ein Link auf "libkeyutils.so.1.4".
Mit dem dir Befehl kann man sich die Größe anzeigen lassen:
Sie ist bei mir als 17 KB groß. Normalerweise ist die lib ca 10 bis 20 KB groß.
Ist die Datei aber um die 30KB groß seid ihr wahrscheinlich mit dem Windigo Bot infiziert.
2) Der Test sollte nicht auf Systemen benutzt werden, die OpenSSH mit dem X.509-Patch von Roumen Petrov einsetzen. Dieser Patch fügt dem SSH-Daemon die Unterstützung für X.509-PKI-Zertifikate hinzu und enthält seit September 2013 eine -G Option. Normalerweise gibt es sonst die Option -G nicht (nur bei den infizierten Systemen meldet -G durch einen Fehler in der Programmierung einen Status).
Ich habe oben im Link die Informationen dazu ergänzt.
Gruß
Frank
hier noch zwei Ergänzungen zur Bot Erkennung:
1) Man sollte prüfen wie groß die Datei libkeyutils.so ist. Die liegt normalerweise unter /usr/lib/ oder nur /lib/ und sollte unter 20 KB groß sein.
Man findet sie auch mit Hilfe des Befehls:
locate libkeyutils.so
/lib/x86_64-linux-gnu/libkeyutils.so.1
/lib/x86_64-linux-gnu/libkeyutils.so.1.4
Mit dem dir Befehl kann man sich die Größe anzeigen lassen:
dir /lib/x86_64-linux-gnu/libkeyutils.so.1.4
-rw-r--r-- 1 root root 14360 Okt 17 2011 /lib/x86_64-linux-gnu/libkeyutils.so.1.4
Sie ist bei mir als 17 KB groß. Normalerweise ist die lib ca 10 bis 20 KB groß.
Ist die Datei aber um die 30KB groß seid ihr wahrscheinlich mit dem Windigo Bot infiziert.
2) Der Test sollte nicht auf Systemen benutzt werden, die OpenSSH mit dem X.509-Patch von Roumen Petrov einsetzen. Dieser Patch fügt dem SSH-Daemon die Unterstützung für X.509-PKI-Zertifikate hinzu und enthält seit September 2013 eine -G Option. Normalerweise gibt es sonst die Option -G nicht (nur bei den infizierten Systemen meldet -G durch einen Fehler in der Programmierung einen Status).
Ich habe oben im Link die Informationen dazu ergänzt.
Gruß
Frank
Ok vielen Dank für die zusätzliche Meinung @wiesi200 und auch Danke für den Hinweis mit der libkeyutils.so @Frank.
Also ich gehe jetzt mal davon aus das ich nicht infiziert bin, bzw. mein System ;)
Ich hab mir die grösse mal angeschaut und die beträgt gerade mal 13,7 kb (13.672 Bytes)
Des Weiteren habe ich in anderen Foren gelesen das es nur anschlägt wenn SSH installiert ist bzw. bei NICHT installiertem SSH bringt er dann halt die Meldung "Infected".
Leider kämpf ich gerade noch mit einem VPN Problem, werde morgen nochmal genauer prüfen.
Also ich gehe jetzt mal davon aus das ich nicht infiziert bin, bzw. mein System ;)
Ich hab mir die grösse mal angeschaut und die beträgt gerade mal 13,7 kb (13.672 Bytes)
Des Weiteren habe ich in anderen Foren gelesen das es nur anschlägt wenn SSH installiert ist bzw. bei NICHT installiertem SSH bringt er dann halt die Meldung "Infected".
Leider kämpf ich gerade noch mit einem VPN Problem, werde morgen nochmal genauer prüfen.
1
Hi @licorit,
ok, klingt logisch. Wenn gar kein SSH-Server installiert ist, dann kann das Test-Script oben natürlich nicht funktionieren. Ich ergänze diese Info oben im Text. Dann hast du ja nochmal Glück gehabt
Gruß
Frank
ok, klingt logisch. Wenn gar kein SSH-Server installiert ist, dann kann das Test-Script oben natürlich nicht funktionieren. Ich ergänze diese Info oben im Text. Dann hast du ja nochmal Glück gehabt
Gruß
Frank
