Malware auf gw02, gw06 und gw08 gefunden

Technik
#1

Ich habe heute auf den Gateways gw02, gw06 und gw08 Malware gefunden. Die VMs wurden sofort abgeschaltet. Folgendes ist aufgefallen:

  • es gab jeweils einen unerwarteten Reboot
  • der SSH Port wurde auf 57 geändert
  • ssh Zugriff als root mit Passwort wurde erlaubt
  • es fanden sich verschiedene Binaries die dort liefen:
    • /etc/my.conf
    • /var/ssh.conf
    • /usr/bin/.sshd
    • /usr/bin/pythno
    • /usr/bin/bsd-port/knerl
    • und es ist gut möglich das es da noch mehr gibt was ich nicht gefunden habe.
  • Log Dateien (.bash_history, /var/log/auth.log.*) wurden gelöscht

Es sieht stark danach aus als ob die Gateways für ein Botnet gekapert wurden.

Die Reboots (ich vermute, dass das ganze etwa zu der Zeit begonnen hat) waren bei gw02 heute um etwa 07:00, bei gw06 Sonntag um etwa 04:30 und bei gw08 Sonntag um 06:20. Aber es kann natürlich auch sein das dort schon länger etwas schlummerte und dann jetzt erst aktiviert wurde oder halt so auffälig wurde.

Aktuell ist leider völlig unklar wie diese dorthin gekommen ist und wie ein erneuter Angriff verhindert werden kann (das ist das Hauptproblem).

Auf allen unseren Gateways läuft Debian 10 und alle Updates wurden installiert. Es gab ja neulich bei Salt eine Sicherheitslücke, da wurde aber auch das Update sehr zeitnah eingespielt. Auch spricht dagegen das hier ein Zusammenhang mit Salt besteht, die Tatsache das nur 3 Gateways betroffen sind. Sollte hier wirklich Salt angegriffen worden sein würde ich erwarten das alle Server betroffen wären und nicht nur 3 Gateways.

Es gibt die Überlegung ob es eventuell mit mesh-announce zusammenhängen könnte. Aber das ist halt eigentlich eher unwahrscheinlich, da dies eine kaum verbreitete Software ist. Vorsichtshalber wurde aber der Service auf allen Gateways gestoppt.

Mein „Bauchgefühl“ würde eher dafür sprechen das kein Angriff auf „Nutzerdaten“ stattgefunden hat. Und grundsätzlich sollte das Risikopotential nicht viel größer sein als generell bei einem öffentlichen WLAN, da heutzutage durch HTTPS der meiste Traffic ja transportverschlüsselt ist. Und bis auf die Zentralität könnte das auch schon früher im Freifunk Netz abgegriffen werden, sollte es jemand darauf anlegen.

Leider sehr viel Unwissenheit aktuell. Wir werden uns das auf jeden Fall noch genauer anschauen und dann über neue Erkenntnisse berichten.

4 Like
Neuer Service: meet.ffrn.de - Videochat (erstmal testweise)
#2

Danke schonmal für die Offenheit und Transparenz. Ist leider nicht selbstverständlich.

1 Like
#3

Hast Du die Binaries mal auf Virustotal hochgeladen?

Hast Du Tripwire auf den Maschinen laufen oder woher kennst Du die Aenderungen?

#4

Ja, habe ich. Ist definitiv Malware und die wurden wohl für ein Botnet gekapert. Die IPs zeigen wohl nach China. Aber das heißt ja nichts.

#5

OK, das Dateilisting ist vermutlich nicht von Tripwire sondern von Virustotal.
Die Binaries wurden vor ueber einem Jahr schon gescannt, der Schadcode also kalter Kaffee - bleibt die Frage, ueber welchen Dienst der eingeschleust wurde, soweit bist Du aber auch schon.

#6

Danke für deine Transparenz :slight_smile:

Gibt es schon neue Erkenntnisse zu dem ganzen ?
Zurzeit werden auf der Knotenkarte alle Gateways als Offline angezeigt, aber mein Freifunk Netz scheint noch zu laufen. Ist da nen Dienst zum anzeigen der Gateways auf einer der Systeme gelaufen?

#7

Die Gateways wurden komplett neu aufgesetzt, der respondd Dienst wurde aber nicht gestartet, da wir uns immer noch nicht sicher sind worüber sie jetzt reingekommen sind. Daher werden die als offline angezeigt. Weitere Schritte sind fastd nicht mehr als root auszuführen und die Firewall weiter zu optimieren. Die Gateways waren immer frisch geupdated und es sind keine Exploits bekannt für die Dienste die drauf liefen. Es gab einen Salt exploit aber der hat nur den Masterserver betroffen und unser Masterserver wurde erst aufgesetzt als der Fix bereits bekannt war.

Da die Malware absolut generisch war und nicht wirklich im verborgenen agiert hat, gehen wir nicht von einem gezielten Angriff aus. Wie sie jetzt reingekommen ist bleibt aber weiterhin unklar. Auch die Dateisystemhistorie kann uns zwar sagen wann und was verändert wurde aber nicht wie sie sich eingeschleust hat.

4 Like
#8

Hier das was wir bezüglich der Malware noch herausgefunden haben:

Es gibt da einen Thread in einem Forum wo scheinbar Leute die gleiche Malware gefunden haben: https://www.lowendtalk.com/discussion/165364/wtf-how-was-i-pwned

Dort scheint der Zugriff über VNC erfolgt zu sein. Und auch bei uns war im Template in OpenNebula (das Tool was uns bei der Verwaltung der VMs hilft) für VNC 0.0.0.0 als Adresse hinterlegt. Und eben auch kein Passwort.
Nun sieht man, wenn man sich per VNC verbindet erstmal ja nur den Anmeldebildschirm. Das hilft einem Angreifer ja nicht wirklich. Denn auch wenn kein root Passwort auf den VMs gesetzt worden war, so sollte man sich dann ja eben trotzdem nicht als root anmelden können. Allerdings wäre es hier eventuell möglich gewesen über Grub Zugriff zu bekommen: https://www.thomas-krenn.com/de/wiki/Linux_Root_Passwort_wiederherstellen

In der Tat habe ich so auch so Zugriff auf gw02 bekommen, nachdem wir ja per ssh ausgesperrt worden waren.

Da aber der Umstand der zu offenen VNC Konfiguration auch bekannt war, das aber den dem Setup nicht so einfach auszutreiben war, wurde auf den Hosts auf die schelle damals eine iptables Regel, hinterlegt, welche eigentlich sicherstellen sollte das trotzdem kein Zugriff erfolgen kann.
Per nft (finde ich übersichtlicher) sahen die verwendeten Regeln dann so aus:

root@altneckar ~ # nft list table ip filter
table ip filter {
        chain INPUT {
                type filter hook input priority 0; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority 0; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority 0; policy accept;
                meta l4proto tcp tcp dport 5900-5999 counter packets 62 bytes 3284 drop
        }
}
root@altneckar ~ # nft list table ip6 filter
table ip6 filter {
        chain INPUT {
                type filter hook input priority 0; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority 0; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority 0; policy accept;
                meta l4proto tcp tcp dport 5900-5999 counter packets 0 bytes 0 drop
        }
}

Hier ist es natürlich etwas „ungünstig“ das hier die ouput chain gewählt wurde …
Das hätte natürlich eigentlich eine input chain sein sollen. Nichtsdestotrotz scheint die Regel doch einen gewissen Effekt gehabt zu haben, da in einem praktischen Versuch eben kein Zugriff auf VNC mehr möglich gewesen ist.

Was nun als Konsequenz passiert ist:

  • Wir haben auf den Hosts die input policy auf drop gestellt (so wie es ja auch eigentlich sein sollte)
  • alle möglicherweise betroffenen VMs (alle Gateways, die DNS Resolver und Jitsi Meet) wurden neu aufgesetzt. (Hier gibt es noch die Nachwirkung dass das wiki noch nicht wiederhergestellt wurde.)
  • Das von uns verwendete Debian Template verwendet nun 127.0.0.1 (localhost) als Adresse auf der VNC läuft und außerdem gibt es nun VNC Passwörter
3 Like