gehen wir durch Bogotá und bekommen Angst vor Eiswerbung

Ende der 1990er gab es es Menschen, die in Ihren Mailsignaturen Wörter verwendeten, mit denen sie automatisierte Überwachungssystem zu fluten hofften. Sowas brauchen wir heute nicht mehr.

Ich habe eine Art Testinstallation in Hyper-V mit Synology DSM 4.1-2668. Und die Verwaltungsports 5000 bzw. 5001 für SSL hatte ich -ebenfalls testweise- nach außen freigegeben. Und dann vergessen. Doof.

Jedenfalls hat sich jemand den Spaß gemacht, solche (alten) Kisten aufzumachen, um dort Bitcoins zu erzeugen (was ungefähr so klug ist, wie das testweise Freigeben und Vergessen einer Portfreigabe, weil wegen der geringen Rechenleistung selbst mit vielen, vielen, vielen NAS-Geräten für den Betreiber nichtmal Bitcoins für eine Kiste Bier hinten rausfallen dürften).

Bekannt wurde die Schadsoftware als PWNED Mitte Februar 2014.

Am Wochenende ist mir meine Synology DSM 4.1-2668 jetzt erneut in die Hände gefallen – und auch die wurde gekapert. Der Prozessmonitor auf der Web-GUI lässt sich nicht starten. Der Befehl top auf dem Secure Shell ergibt hohe Last.

Weil ich „meine“ Version des rootkits nicht im Internet gefunden habe, und auch keinen PWNED Prozess gefunden hatte notiere ich hier die Auffälligkeiten: ohne Anspruch auf Vollständigkeit oder Richtigkeit.

Infiziert wurde ich nach Dateidatum wohl am 25. Mai 2014. Die Bösewichte ersetzten die BusyBox Befehle

/bin/rm
/bin/mv
/bin/ls
/bin/ps

mit eigenen „bösen“ Versionen.

Die Dateien

/usr/syno/synoman/webman/modules/ResourceMonitor/top.cgi
/usr/syno/synoman/webman/modules/ControlPanel/modules/upgrade.cgi
/usr/syno/synoman/webman/modules/ResourceMonitor/rsrcmonitor2.cgi

wurden umbenannt in .top.cgi, .upgrade.cgi und .rsrcmonitor2.cgi. An Stelle der ursprünglichen binären Dateien wurden gleich benannte (und mit more lesbare) scripte eingesetzt.

Der eigentliche Schadcode wird wohl via

#!/bin/sh -e /var/run/shm.pid 5.104.226.33:3344

in der /etc/rc.local gestartet. Das unterscheidet sich von den anderen Infektionen, die ich im Netz finden konnte. 5.104.226.33 steht in Holland und wirkt auf mich wie ein unbenutzter und/oder ungepflegter Linux Server, den irgendwer irgendwann vergessen hat. Eine Domain consistentapp.com liegt wohl darauf – und wenn man z.B. consistentapp.com/hosting/clientarea.php aufruft kann man den Eindruck gewinnen, das hier mal ein hosting Angebot betrieben werden sollte. Naja.

Auf meiner DSM habe ich mit

busybox rm /bin/rm

die „böse“ Version des Befehls gelöscht und dann mit

ln -s busybox /bin/rm

einen link auf die „gute“ BusyBox Version gesetzt. Analog dazu noch

rm /bin/mv
rm /bin/ls
rm /bin/ps

löschen und

ln -s busybox /bin/mv
ln -s busybox /bin/ls
ln -s busybox /bin/ps

verlinken.

Die /etc/rc.local habe ich geleert. .top.cgi, .upgrade.cgi und .rsrcmonitor2.cgi habe ich zurück verschoben. Jetzt ein Neustart – und die Schadsoftware scheint nicht mehr zu laufen. Zumindest bin ich mir für meine Testinstallation sicher genug. Eine echte, produktive Installation müsste man wohl als kompromittiert ansehen.

Synology empfiehlt für „richtige“ NAS Geräte ein Update und hatte den Fehler schnell behoben, soweit ich sehe.

nicht. Zumindest bei mir.

Situation: Angemeldet als ebay@foo.de, Bezahlversuch mit paypalkonto paypal@bar.de. Das paypalkonto ist per Zwei Faktor Authentfizierung gegen Missbrach geschützt. Das ergibt bei mir den Fehler:

Wir konnten Ihre Anfrage leider nicht bearbeiten. Bitte versuche Sie es noch einmal. Sie müssen die Kaufabwicklung möglicherweise erneut durchlaufen.

Da kann man dann erneut durchlaufen soviel wie man will – nüscht.

Bei mir war das Problem behoben, nachdem ich bei paypal die Zwei Faktor Authentifizierung abgeschaltet hatte.

EDIT 22.06.: Ich lese gerade per mail: der Kauf über ebay.com soll auch funktionieren.
EDIT 26.06.: Tuts nun wieder. Scheinbar gefixt.

Finde ich merkwürdig, wenn sowas nicht vor dem Ausrollen getestet wird – gerade weil paypal und ebay so eng miteinander verzahnt sind.

Merkwürdig bis kritisch ist meiner Meinung nach auch das neue, eingeblendete paypalfenster zu Eingabe von Nutzername und Passwort. Im Browser hat der unbedarfte Benutzer keine Möglichkeit mehr, zu überprüfen, wer Ihm da genau sein paypal Kennwort abverlangt, d.h. ob dieses Fenster tatsächlich von paypal und nicht etwa von einem Bösewicht stammt. Die Adresszeile zeigt nämlich weiter ebay.de. Die Nutzer hatten gerade erst erfolgreich gelernt, dass in der Adresszeile dieses kleine Schloss und paypal.com stehen sollte – und alles andere ist Phishing.

Gerade auf heise.de gelesen: NSA entschlüsselt Webserver-Daten angeblich in Echtzeit. Das gelte für RC4 schreiben die unter Berufung auf Jakob Appelbaum. Besonders unschön: Webserver würden diese Verschlüsselung als „kleinsten gemeinsamen Nenner“ verwenden. Auch die Webserver von großen Seiten…

Und tatsächlich:

Google Mail, Paypal, die wikipedia: alle kommen in meinem Firefox irgendwie RC4 verschlüsselt an.

Zumindest als Soforthilfe ist ein about:config in der Adresszeile des Browsers wohl hilfreich. Dort nach RC4 suchen.

Hier jede Zeile Doppelklicken – im Feld „Wert“ sollte nun „false“ stehen um RC4 zu unterdrücken.

Gegenprüfung:

Scheinbar kommen nach der Änderung diese HTTPS-Seiten via AES. Mal sehen ob die Änderung der firefox Konfiguration Probleme verursacht.

Grundsätzlich sinnvoll scheint mir auch der Plugin HTTPS Everywhere – damit wird automatisch versucht, SSL zu verwenden.