Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de

Oje, was hab ich nur angestellt?
Ok, daß der Böse Bube natürlich in einem Aufwaschen auch gleich die Prüfdatei manipulieren kann, wurde mir kurz nach Erstellen des Beitrags auch klar. Betrachten wir die genannte Lösung also als Testlauf zwecks Sensibilisierung für das Problem und als Denksportaufgabe für angehende Hacker
Zur bisherigen simplen Überprüfung gebe ich noch Folgendes zu bedenken: Derzeit sind DEB-Systeme noch nicht betroffen. Davon gibt es einige. Beschränkt auf die derzeit offiziell unterstützten Ubuntu-Versionen existieren alleine vier verschiedene Versionen der libkeyutils1. Alle enthalten leicht unterschiedliche Varianten der betroffenen Library. Das bedeutet, sie muß ins laufende System passen, sonst fallen im Betrieb relativ schnell Probleme auf. Der geschulte Hacker mag sowas garnicht. Um das zu verhindern, muss er eine passende Version der Library und die entsprechende Prüfdatei für die angegriffene Ubuntu-Version bauen. Will er universell arbeiten, braucht er mehrere. Nicht, daß das alles schwierig wäre, aber es gibt wie gesagt auch andere Distributionen, die wieder eigene Versionen verlangen. Ok, egal, ich schweife ab.

Um auf der sicheren Seite zu sein, benötigt man also eine zuverlässige Referenz. Wenn man sich nicht auch noch als Opfer einer manipulierten Paketverwaltung, einer MitM-Attacke, eines DNS-Poisonings, oder sonstiger militärischer Angriffe wähnt, sollte das aktuelle Paket von einem Server der Distribution ausreichend vertrauenswürdig sein. Hier also folgende, verbesserte Version:


Nach dieser Methode habe ich eben alle Varianten durchgespielt. Mit veränderter Lib und dazu angepasster md5sum-Datei ergibt sich bei einfacher Prüfung:
Wohlgemerkt, /lib/libkeyutils.so.1.3 war hier manipuliert, aber /var/lib/dpkg/info/libkeyutils1.md5sums ist entsprechend angepasst worden. Daher ein trügerisches Bild.

Hingegen:Mit Prüfung gegen die neu heruntergeladene Paketdatei wird die Manipulation erkannt. Hier besteht kein Zweifel mehr!

Im Normalfall wäre der vorherige Download einer neuen Paketdatei nicht nötig, da sich in /var/cache/apt/archives/ meist schon eine Kopie befindet. Außer man bereinigt regelmäßig den Cache. Aber da der böse Bube ja ganz gerissen sein könnte und mit seiner manipulierten Library gleich auch ein komplettes DEB gebaut und uns untergejubelt haben könnte, holen wir es uns lieber frisch vom Server. Es lebe die Paranoia

Man benötigt also kein komplettes Referenzsystem. Es genügt, die vorhandenen Werkzeuge richtig einzusetzen.
Und vielleicht noch ein Wort zum Level der vorgetragenen Ansätze: Dieses Forum richtet sich überwiegend an Einsteiger, also sollten die Schritte auch für sie nachvollziehbar (sprich in wenigen Schritten und mit verfügbaren Kommandos machbar) sein. In der Administration von Servern, die Angriffen dieser Art eher ausgesetzt sind, arbeitet man schon im Vorfeld mit anderen Mitteln. Eine laufende Überwachung der sensiblen Bereiche auf Veränderungen gehört da neben der Härtung derselben zum täglichen Brot. Aber wer will schon auf seinem Laptop ständig Programme laufen haben, die pausenlos tausende Dateien prüfen. Auf einem Server muss das sein, im Consumerbereich wär's eher hinderlich.

Zitat von »floogy«

Selbst Einsteiger profitieren davon, wenn der Mechanismus hinter einer Software in groben Zügen erklärt wird

Genau deswegen habe ich die Meldung ja hier reingesetzt und einen einfachen Ansatz gebracht, obwohl es den Durchschnittsuser sehr wahrscheinlich gar nicht betreffen wird. Ich hielt es für eine gute Idee, auf DEB-Systeme einzugehen, da im restlichen Netz zumindest zu dem Zeitpunkt nur Lösungen für RPM angeboten waren. (Womit es ja für dieses Forum völlig uninteressant gewesen wäre)
In einem Admin-Forum hätte ich geschrieben "werft mal einen schärferen Blick auf die Logs von samhain" und fertig. Wer damit nichts anfangen kann, sitzt sowieso an der falschen Stelle. Aber das hier ist kein Admin-Forum und deshalb kam es so.

Unabhängig davon hielt ich es für angebracht, diese Warnung relativ schnell auch in unser Forum zu tragen, da SSH bei vielen Leuten mit unterschiedlichem Erfahrungslevel verwendet wird und allgemein als sicher eingeschätzt wird. Vielleicht hätte ich es einfach nur beim Reintragen der Meldung belassen sollen, um keine Kontroversen über die Qualität der Prüfmethode auszulösen.

Und ich bin froh, daß floogy immer so fleißig die passenden Links zu einem Thema zusammenträgt. Das ist mir nämlich oft zu mühsam

Nebenbei hab ich auch mal wieder ein paar Details gelernt, wie immer wenn es um ernstzunehmende Probleme geht.
In diesem Fall nicht nur über die Interna von debsums (übrigens nur ein Perl-Script, das auf dpkg-deb und md5sums zurückgreift). Sondern zum Beispiel auch, wie ich schon weiter oben erwähnt habe, wofür die libkeyutils eigentlich da sind. Unter den rückwärts-Abhängigkeiten findet man prominente Pakete, wie etwa nfs-common und auch die cifs-utils. (Von SSH fand ich übrigens gar nichts, was mich jetzt ein bisschen am reißerischen Titel der diversen Meldungen im Netz zweifeln lässt)

Wenn man sich aber einen Reim auf die Paketbeschreibungen macht, wird's vielleicht doch noch spannend:

Zitat von »libkeyutils1«

Description: Linux Key Management Utilities (library)
Keyutils is a set of utilities for managing the key retention facility in the kernel, which can be used by filesystems, block devices and more to gain and retain the authorization and encryption keys required to perform secure operations.

Zitat von »cifs-utils«

Description: Common Internet File System utilities
The SMB/CIFS protocol provides support for cross-platform file sharing with Microsoft Windows, OS X, and other Unix systems.

Die cifs-utils dienen also unter anderem dem Zugriff auf Windows-Freigaben und die libkeyutils kümmern sich dabei um die Passwörter.

Sorry für triple-posting, aber im Sinne der objektiven Information muss ich nochmal nachhaken.
Hier findet sich ein offizielles Statement von cPanel, die diesen Trojaner über einen infizierten Rechner unabsichtlich an ihre Kunden verteilt haben.
Demnach sind zwei verschiedene Software-Pakete betroffen, einmal die openssh-Binaries und zum zweiten die libkeyutils. Daher auch keine Abhängigkeit zwischen diesen, wie ich vorhin geschrieben habe.

Zitat von »http://docs.cpanel.net/twiki/bin/view/AllDocumentation/CompSystem«

In regards to CentOS and RedHat systems, we have determined that the sshd, ssh, ssh-keygen, and ssh-askpass binaries all appear to contain trojan code. This code is used to collect authentication credentials for both inbound and outbound connections. We believe that the SSH keys generated by these binaries were also captured.

Die betreffenden SSH-Pakete schnitten demnach offenbar die erzeugten/verwendeten SSH-Keys mit. Diese können somit vom bösen Mann abgefragt bzw. automatisch oder auf Abruf übermittelt werden. Soweit die Frage, wie der wohl ins System kommt.

Die zweite Frage "Was will er dort" dürfte dann wohl mit den libkeyutils zu tun haben. Wozu wären die sonst auch manipuliert und eingeschleust worden? Siehe dazu mein letzter Beitrag. Wir werden es hoffentlich erfahren, wenn sich das Ziel der Attacke herausstellt. Klar ist aber, daß die Infektion von dem Server, der bei cPanel als Zwischenstufe zwischen Kunden und Supportern die Sicherheit beider erhöhen sollte (SIC), an die Server der Kunden übertragen hat. [Quelle]

Auf der genannten Seite findet sich übrigens ein noch simplerer und dabei auch exakterer Test auf die Infektion (der libkeyutils, nicht von open-ssh!). Die infizierte Binär-Library enthält code, der in einer sauberen nicht vorkommt. Dies kann man wie folgt prüfen:
Die Ausgabe muss leer sein. Ist die Ausgabe aber:-> BEFALL! Jetzt sage keiner, das wäre nicht sinnvoll in einem cronjob (mit entsprechender Reaktion im Ernstfall) untergebracht.

Wer sich für die weiteren Tests auf der verlinkten Seite interessiert: Außer den rpm-Kommandos können sie analog auch auf Debian-Derivaten ausgeführt werden. Möglicherweise sollte man sich aber die man-pages dazu ansehen, um die Optionen und Ergebnisse zu verstehen. Ich gehe hier nicht weiter darauf ein.
Das letzte Kommando, die Prüfung auf die von SSH verwendeten Libraries könnten wir zB. so ausführen:Das Ergebnis muss eine Liste von korrekt installierten Paketen sein. Kommt dabei eine Fehlermeldung von dpkg, sollte man die Sache genauer untersuchen.

@maettu: Hast natürlich Recht. Was geht uns das an.
Braucht keinen interessieren, wie man Pakete oder Systemdateien auf Integrität prüft. Ob Einsteigerforum oder nicht.