Wie wurde Matasano gehackt?

von: http://seclists.org/fulldisclosure/2009/Jul/0388.html

Wenn ich es am besten aus den Beiträgen von http://news.ycombinator.com/item?id=723798 verstehe, haben die Matasano-Leute das sshd-Internet zugänglich gemacht - irgendwelche Lösungsvorschläge dafür (aus programmtechnischer Sicht)?

Wie wurde Matasano gehackt?

Es ist unmöglich, von den Informationen in der Post bis zur vollständigen Offenlegung zu antworten. Es ist jedoch immer interessant zu spekulieren, da sie ein paar Informationen verraten -

# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Verbindung zu 69.61.87.163:22 herstellen ..
[/] Auf der Suche nach einem gültigen Nicht-Root-Benutzer. Adam
******** R3D4CT3D h4h4h4h4 ********

Sie führen ihre Binärdatei " th3_f1n41_s01ut10n" auf Matasanos Server aus, der eine Verbindung zum SSH-Port herstellt. Es findet einen gültigen Nicht-Root-Benutzer auf unbekannte Weise, und der Rest der Ausgabe wird redigiert.

# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Connectback-Listener unter 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19. Oktober 2007] 

Die Binärdatei wird erneut mit dem gefundenen Benutzernamen ausgeführt, der sich an Port 3338 anmeldet und eine Verbindung zu ihrem Server herstellt (hoffentlich ist dies nicht in ihrem Namen registriert ...).

adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP So 4. März 12:44:55 UTC 2007 i686 GNU / Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****

Sie könnten bedeuten, dass sie einen 0-Tage gegen diesen Kernel haben, was ziemlich alt ist, wenn man die Aktien dieses Unternehmens betrachtet.

adam_at_www: ~ $ cd / tmp
*********** B0R1NG ***********
root_at_www: ~ # cat / etc / shadow 

Whoops - plötzlich ist der Benutzer jetzt root. Sie haben einen lokalen Exploit zur Eskalation von Berechtigungen in / tmp, der möglicherweise der 0-Tag ist, auf den sie sich bezogen haben.

Hier werden also mindestens zwei Exploits ausgeführt - der OpenSSH-Exploit, um einen gültigen Benutzer ohne Rootberechtigung auf dem System zu erhalten, sich als dieser Benutzer anzumelden und anschließend die lokalen Berechtigungen zu eskalieren.

In Anbetracht dessen, dass OpenSSH seit Version 4.5 einige bekannte Sicherheitsprobleme aufweist:

Von der Sicherheitsseite von OpenSSH :

• OpenSSH vor Version 5.2 ist anfällig für die in CPNI-957037 "Plaintext Recovery Attack Against SSH" beschriebene Protokollschwäche. Aufgrund der begrenzten verfügbaren Informationen scheint dieser beschriebene Angriff jedoch in den meisten Fällen nicht durchführbar zu sein. Weitere Informationen finden Sie in der cbc.adv-Empfehlung und in den Versionshinweisen zu OpenSSH 5.2.
• OpenSSH 4.9 und ~/.ssh/rchöher werden nicht für Sitzungen ausgeführt, deren Befehl mit einer ForceCommand-Direktive sshd_config (5) überschrieben wurde. Dies war ein dokumentiertes, aber unsicheres Verhalten (beschrieben in OpenSSH 4.9-Versionshinweisen).
• OpenSSH 4.7 und höher greifen nicht auf das Erstellen vertrauenswürdiger X11-Authentifizierungscookies zurück, wenn die Erzeugung nicht vertrauenswürdiger Cookies fehlschlägt (z. B. aufgrund einer absichtlichen Erschöpfung der Ressourcen), wie in den Versionshinweisen zu OpenSSH 4.7 beschrieben.

Ich denke, dieser ältere Linux-Kernel und der ältere SSH-Daemon haben das für sie getan. Außerdem lief es auf ihrem WWW-Server, der für das Internet verfügbar ist, was meiner Meinung nach ziemlich zuversichtlich ist. Die Leute, die eingebrochen waren, wollten sie offensichtlich in Verlegenheit bringen.

Wie können diese Angriffe verhindert werden?

Dies hätte durch eine proaktive Verwaltung verhindert werden können. Stellen Sie sicher, dass alle mit dem Internet verbundenen Dienste gepatcht sind, und begrenzen Sie die Anzahl der Personen, die eine Verbindung herstellen können, anstatt es Personen zu ermöglichen, von überall aus eine Verbindung herzustellen. Diese Episode fasst die Lehre zusammen, dass eine sichere Systemadministration schwierig ist und das Engagement des Unternehmens erfordert, um der IT Zeit zu geben, um die Dinge in Ordnung zu halten - in Wirklichkeit ist dies zumindest in kleineren Unternehmen nicht einfach.

Die Verwendung eines Belt-and-Braces-Ansatzes ist am besten geeignet. Die Verwendung der Authentifizierung mit öffentlichem Schlüssel, die Whitelist auf dem SSH-Dämon, die Zwei-Faktor-Authentifizierung, IP-Einschränkungen und / oder die Hinterlegung des VPN sind mögliche Wege, um das VPN zu sperren.

Ich glaube ich weiß was ich morgen bei der Arbeit machen werde. :) :)

Die Leute lieben es, darüber FUD zu erstellen, aber es scheint, dass sie wussten, dass der Benutzer Adam bereits da war und auch sein Passwort kannte (möglicherweise durch Brute Force oder andere Methoden). Sie wollen jedoch cool aussehen und diese Aufregung überall erzeugen.

Interessant ist auch, dass sich der Benutzer adam seit mehr als einem Jahr nicht mehr in diesem Feld angemeldet hat:

(Ausgabe von lastlog)

 adam             pts/1    ool-4350ab48.dyn Sat Jul 26 20:45:18 -0400 2008

Also hat er dieses Passwort wahrscheinlich eine Weile behalten (vielleicht ein schlechtes).

* Wenn sie wirklich ein Tool zum Erkennen von Benutzernamen über SSH hätten, hätten sie alle anderen Benutzer verwenden können, um Fernzugriff zu erhalten, aber sie haben den gebräuchlichsten Benutzernamen in diesem Feld verwendet (leicht zu erraten).

Warum sollten Sie versuchen, dies aus programmtechnischer Sicht zu lösen?

Sie sollten es stattdessen aus Sicht eines Smart-Server-Administrators lösen. In den Kommentaren der von Ihnen geposteten Links finden Sie einige gute Vorschläge, z. B. die Verwendung einer Whitelist.

Ich möchte auch hinzufügen, dass Sie, da Sie hier fragen, höchstwahrscheinlich kein Sicherheitsexperte sind und alles, was Sie schreiben könnten, nur weitere Löcher hinzufügen würde. Dies ist wirklich überhaupt keine Programmierfrage.

Schützen Sie Ihre Software vor 0-Tage-Angriffen ... was unmöglich ist.

Vielleicht besteht ein guter Ansatz darin, zu behaupten, dass Ihre Software nicht hackbar ist, was dazu führt, dass Whitehats sie ausprobieren und alles vollständig offenlegen, wodurch weniger Lücken entstehen. Oracle 10 hatte diese Behauptung, dann wurden am folgenden Tag wie 9 neue Löcher gefunden. Es ist jetzt ziemlich sicher.

Höchstwahrscheinlich hat der Hacker die Konfiguration perfekter Software missbraucht

Es ist unglaublich, dass sie so viele Benutzer mit Shells auf dieser Maschine hatten. So wurden sie sicher besessen, alles andere ist roter Hering, der ablenken soll. Einer von ihnen hat höchstwahrscheinlich seinen SSH-Client auf einer anderen Shell-Maschine hinter die Tür gebracht, und dann war das Spiel vorbei. Es ist einfach faul und dumm, allen Shell-Accounts zu geben und sshd world zugänglich zu machen.