Arch Linux

Windigo Botnet | Bist du infiziert?

shibumi

Im Moment erschüttert die Nachricht vom Windigo-Botnet die Linux-Welt. Ob ihr auch infiziert seid könnt ihr folgendermaßen prüfen:

ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"

Außerdem solltet ihr prüfen wie groß die libkeyutils.so ist. Die liegt normalerweise unter /usr/lib/
Ist die Datei circa 30KB groß habt ihr ein Problem und seid wahrscheinlich infiziert.
Normalerweise ist die lib so in etwa 10-20KB groß. Bei mir sind es zb 16KB

Ich denke mal das die Überprüfung in erster Linie für Leute mit Server interessant ist. Auf einem Desktop-Rechner hat man ja normalerweise keinen SSH-Server laufen und dann noch die Ports im Router freigeschaltet. Aber eine Überprüfung kann ja trotzdem nicht schaden dauert ja nur 2 Sekunden...

Liebe Grüße

Shibumi

wirr

❄ ssh -G
ssh: illegal option -- G

Leute mit Server verbieten das Anmelden mit Passwort?

Es heisst sogar, dass jetzt endlich mal 'das Linux' gehackt wurde. Aber einen Virus zu installieren, wenn man das Passwort hat ist auch nichts besonderes.

shibumi

wirr schrieb
❄ ssh -G
ssh: illegal option -- G
Leute mit Server verbieten das Anmelden mit Passwort?

Es heisst sogar, dass jetzt endlich mal 'das Linux' gehackt wurde. Aber einen Virus zu installieren, wenn man das Passwort hat ist auch nichts besonderes.

Das ssh -G nicht funktioniert ist gut^^weil dann bist du sehr wahrscheinlich nicht infiziert. Die Option wird vom Trojaner hinzugefügt. Hätte ich mal noch erläutern sollen.

Kerberos

Was soll die Option "-G" bewirken, die vom "Virus" hinzugefügt wird?

[gelöscht]

shibumis potentielle quelle.

shibumi

Kerberos schriebWas soll die Option "-G" bewirken, die vom "Virus" hinzugefügt wird?

Ein System welches mit dem Rootkit "Ebury" infiziert weist ein anderes Verhalten beim SSH-Befehl auf.
Da haben die Rootkit-Entwickler irgendeinen Fehler gemacht und die Botnet-Drahtzieher haben das Rootkit einfach so übernommen.
Ein sauberer Server schreibt den Output von ssh -G nach stderr das tut der infizierte Server wohl nicht und hat auch noch falschen Output.

Kerberos

Danke für die Aufklärung.

Henrikx

shibumi schriebAuf einem Desktop-Rechner hat man ja normalerweise keinen SSH-Server laufen und dann noch die Ports im Router freigeschaltet. Aber eine Überprüfung kann ja trotzdem nicht schaden dauert ja nur 2 Sekunden...

Au einem Desktop-System ohne SSH-Server , mit libkeyutils.so, llibkeyutils.so.1, ibkeyutils.so.1.5, jeweils 14,6kb, kommt die Meldung System infected.

Die Befehlszeile ist fehlerhaft, oder untauglich auf einem Desktop-System.
Verweise auch mal auf diesen Kommentar:

http://www.heise.de/security/news/foren/S-G-Test-taugt-nicht/forum-276611/msg-24949771/read/

fs4000

Dann würde ich diesen Test vorschlagen:

$ pacman -Qkk keyutils openssh
Warnung: keyutils: /etc/request-key.conf (Zeit der Veränderung stimmt nicht überein)
keyutils: 65 Dateien gesamt,1 veränderte Datei
Warnung: openssh: /etc/pam.d/sshd (Zeit der Veränderung stimmt nicht überein)
Warnung: openssh: /etc/ssh/ssh_config (Zeit der Veränderung stimmt nicht überein)
Warnung: openssh: /etc/ssh/sshd_config (Zeit der Veränderung stimmt nicht überein)
openssh: 58 Dateien gesamt,3 veränderte Dateien

Die Warnungen werden ab Pacman 4.2 verschwinden.

portix

Henrikx schrieb
shibumi schriebAuf einem Desktop-Rechner hat man ja normalerweise keinen SSH-Server laufen und dann noch die Ports im Router freigeschaltet. Aber eine Überprüfung kann ja trotzdem nicht schaden dauert ja nur 2 Sekunden...
Au einem Desktop-System ohne SSH-Server , mit libkeyutils.so, llibkeyutils.so.1, ibkeyutils.so.1.5, jeweils 14,6kb, kommt die Meldung System infected.

Die Befehlszeile ist fehlerhaft, oder untauglich auf einem Desktop-System.
Verweise auch mal auf diesen Kommentar:

http://www.heise.de/security/news/foren/S-G-Test-taugt-nicht/forum-276611/msg-24949771/read/

Das sollte eigentlich nichts mit Server/Desktop zu tun haben. In dem von Gastlich verlinkten Artikel wird ja auch erwähnt dass es gepatchte ssh-Versionen gibt die die Option -G haben, unter Arch sollte das aber mit openssh aus den Repos eigentlich nicht der Fall sein.

Henrikx

@portix

Und trotzdem kommt "system infected". Wollte halt nur klarstellen, dass die Befehlszeile nichts bringt.

@fs4000

pacman -Qkk keyutils openssh
Warnung: keyutils: /etc/request-key.conf (Zeit der Veränderung stimmt nicht überein)
keyutils: 65 Dateien gesamt,1 veränderte Datei
Fehler: Paket 'openssh' wurde nicht gefunden.

fs4000

Henrikx schriebUnd trotzdem kommt "system infected". Wollte halt nur klarstellen, dass die Befehlszeile nichts bringt.

Ohne ssh gibts halt einen Returncode ungleich 0 und damit springt der zu dem echo "System infected".

portix

Henrikx schrieb@portix

Und trotzdem kommt "system infected". Wollte halt nur klarstellen, dass die Befehlszeile nichts bringt.

Wenn ssh gar nicht installiert ist dann ist natürlich klar das der Befehl sinnlos ist.

Henrikx

@fs4000 und portix

Danke.

[gelöscht]

Huch! Wir sind ja gar nicht im Café. Dann sollte der Titel nicht so reißerisch sein!

shibumi

Also bitte.. ein bisschen Menschenverstand setze ich schon vorraus. Wenn kein ssh installiert ist ist doch klar, dass der Befehl "infected" ausgibt. Und der von Henrikx erwähnte Eintrag bezieht sich auf einige gepatchte SSH-Versionen die tatsächlich diesen -G parameter haben. Man sollte schon wissen auf seinem Rechner was man patcht und was nicht. Eine Andere Art der Überprüfung wäre übrigens noch folgende:

Zu erst sucht man mit "ipcs -m -p" einen Prozess der ein shared-memory-segment größer als 3MB verursacht. Handelt es sich bei diesem Prozess um den ssh-daemon und hat dieser noch systemweite Berechtigungen ala "666" dann ist das ein klares Anzeichen für eine Infektion.

Das alles gilt übrigens nur für das Ebury Root-kit.. Es gibt noch Bot versionen mit Linux/Ominiki oder Linux/Cdorked Rootkit welches auf Apache basiert...

Henrikx

Menschenverstand oder unklare Aussagen?

shibumi schrieb Auf einem Desktop-Rechner hat man ja normalerweise keinen SSH-Server laufen und dann noch die Ports im Router freigeschaltet. Aber eine Überprüfung kann ja trotzdem nicht schaden dauert ja nur 2 Sekunden...

Wollte das hier nur mal klar stellen.
Die Desktop-Überprüfung kann man sich sparen. Daher könntest du auch deinen Beitrag editieren, dass bringt dann auch keine unnötige Verunsicherung.

shibumi

Henrikx schriebMenschenverstand oder unklare Aussagen?

shibumi schrieb Auf einem Desktop-Rechner hat man ja normalerweise keinen SSH-Server laufen und dann noch die Ports im Router freigeschaltet. Aber eine Überprüfung kann ja trotzdem nicht schaden dauert ja nur 2 Sekunden...
Wollte das hier nur mal klar stellen.
Die Desktop-Überprüfung kann man sich sparen. Daher könntest du auch deinen Beitrag editieren, dass bringt dann auch keine unnötige Verunsicherung.

Nöö wieso?
Gibt genug Leute die privat einen SSH-Server betreiben mit DynDNS und portforwarding.. hab ich bei meinem Raspi selbst auch

[gelöscht]

Und außerdem ist der Befehl/Test trotzdem schlecht. Was soll das rumgegreppe? Dann sollte der Test auch valide Ergebnisse liefern. Eine Erklärung wie der Output bei einem sauberen, bei einem infizierten, und bei einem gepatchten System auszusehen hat wäre deutlicher gewesen. Und wenn zB heise das nur von eset abgeschrieben hat, hätten sie das sauberer machen können. Außerdem erklärt auch niemand _wie_ die Infektion abläuft. Was ist der Angriffsvektor? Wie kommt die veränderte Version von ssh überhaupt auf die Kiste?

[gelöscht]

https://github.com/eset/malware-ioc/tree/master/windigo
Und was heise auch nicht deutlich genug sagt: Das System ist bereits kompromittiert. Dann erst wird ssh durch die Backdoor-Version ersetzt. Verloren hatte man schon vorher.

Nächste Seite »