Heartbleed Schwachstelle in allen Systemen: Vorgehensweise

  • Moin Ihr,


    der aktuell bei Heise (Der GAU für Verschlüsselung im Web: Horror-Bug in OpenSSL | heise online) beschriebene SSL Bug zwingt ja zum unverzüglichen handeln.


    Die OpenSSL Lib ist bereits via APT Upgrade (Debian) bzw Pacman (Arch Linux) ausgetauscht, und alle betroffenen Dienste wurden neu gestartet. Die Tests die es für diese Schwachstelle gibt sagen auch alle "wieder alles okay, entspann dich". Selbst bei selbst gebackenen Diensten ist dies der Fall.


    Was habt ihr so gemacht?
    So ganz 100% sicher bin ich mir bisher noch nicht wieder...


    Sollte man vielleicht sogar die Schlüssel der SSH- und Web Server austauschen bzw neu generieren lassen?


    Die Tests:
    Test your server for Heartbleed (CVE-2014-0160)
    http://possible.lv/tools/hb/



    VG
    Christian

  • Guten Morgen,



    zunächst sollte man prüfen, ob man von dem GAU betroffen war. Debian Squeeze oder CentOS 5.x waren in der Regel von dem GAU z.B. gar nicht betroffen. Sollte man von dem GAU betroffen gewesen sein, ist der sicherste Weg die Private-Keys neu auszustellen und neue Zertifikate zu generieren. Andernfalls besteht die Gefahr, dass jemand unbekanntes den alten Private-Key abgreifen konnte.


    Kunden die von dem GAU betroffen waren und ihre Zertifikate über uns bezogen haben, erhalten bei unserem Support entsprechende Hilfe wenn sie ihre Private-Keys tauschen wollen.



    Mit freundlichen Grüßen


    Felix Preuß

  • Ist euch eigentlich irgendein Anbieter bekannt, der in diesem speziellen Fall für Revoke/Regenerate nichts verlangt? Besonders lustig ist es zur Zeit ja für viele StartSSL-Nutzer. Zertifikate gab es kostenlos, für den Widerruf müsste man aber zahlen. Ich will die Kosten auch gar nicht kritisieren, zumal sie jedem vorher bekannt waren. Aber ich fürchte, dass es viele davon abhalten wird, sich neue Zertifikate zu holen. Oder alternativ die "alten" StartSSL-Zertifikate einfach auslaufen zu lassen und sich woanders günstiger welche zu holen, was genauso schlimm wäre…



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Bei einigen ist es wohl kostenlos: Heartbleed SSL-GAU: Neue Zertifikate braucht das Land | heise Security


    Ich persönlich habe bisher noch keines zurückgerufen. Die meisten werden sowieso für nichts kritisches verwendet und der Rest war größtenteils auf nicht betroffenen Systemen. Außerdem war es mir in keinem gestrigen Test möglich die privaten Schlüssel auszulesen. Ich sah sehr viel HTTP-Traffic von anderen Nutzern, aber nichts was den Rückruf rechtfertigen würde. Das ist natürlich nicht 100% aussagekräftig, schon klar. Aber ich werde die meisten Zertifikate einfach verlängern, wenn es soweit ist. Ist bei den meisten sowieso bald der Fall. Wie ich eventuell kompromittierte Benutzernamen und Passwörter von betroffenen Projekten behandle, muss ich mir erst ansehen. Alle aktiven Sessions und Autologin-Keys der Projekte habe ich bereits zerstört.


    Mehr Sorgen machen mir aktuell ungepatchte Systeme von großen Herstellern. Keine Firmware-Updates für die Geräte in Sicht und viele verwundbare Dienste… :(



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Zertifikate zurückrufen bringt IMHO wenig.


    Chrome prüft in der Standardeinstellung nicht darauf. Muss man erst in die Einstellungen -> Erweiterte Einstellungen und unter HTTPS/SSL einstellen.
    Davon abgesehen, dass ein Zertifikat die wenigsten erneuern werden.


    Da kein normaler Anwender die Einstellungen ändern wird, ist SSL kaum mehr als ein Indiz, das übertragene Daten vielleicht nicht mitgelesen werden können.

  • Du willst auf Man-in-the-middle-Angriffe raus (wo ein anderes Zertifikat untergeschoben wird)? Was hat das hiermit zu tun? Mit Heartbleed ist es u.U. möglich den Traffic mit korrektem Zertifikat zu entschlüsseln.

  • Ja, ich will auf man in the middle hinaus.


    Selbst wenn ein neues Zertifikat verwendet wird, so ist es beispielsweise möglich einfach in die leitung zu hängen und die kommunikation vom server neu zu signieren.


    da der nutzer nicht auf widerruf prüft, akzeptiert er das dann auch.


    ist recht theoretisch, aber danach fragt keiner, wenn es eintreten sollte.

  • Da wir den Bug als sehr kritisch einstufen, informieren wir jetzt Kunden die noch kein Update eingespielt haben. Dazu überprüfen wir alle IP-Adressen aus unserem Netzbereich. Die Kunden werden per E-Mail informiert.


    Zertifikate die über uns bezogen werden, können kostenlos ausgetauscht werden. Details: Kostenlose Neuausstellung von Zertifikaten « netcup news


    Mit freundlichen Grüßen


    Felix Preuß

  • seltsam - ich hatte das Update gestern schon eingespielt und neu gebootet - jetzt kriege ich heute die Mail, mache nochmals update/upgrade und das openssl package wird nochmals erneuert... gestern waren wohl die wheezy packages im repository noch nicht alle upgedated....


    Danke jedenfalls für den Hinweis.

  • Es gab zwei Updates aufgrund zwei Sicherheitslücken.


    Nein, das 2. Update (1.0.1e-2+deb7u6) des Pakets liefert nur eine Funktion nach um betroffene Dienste neuzustarten:

    Zitat

    This revision to the recent OpenSSL update, DSA-2896-1, checks for some services that may use OpenSSL in a way that they expose the vulnerability. Such services are proposed to be restarted during the upgrade to help in the actual deployment of the fix.


    The list of services that are checked is not comprehensive. For a more detailed check, it is recommended to use the checkrestart tool from the debian-goodies package. Note that client applications also need to be restarted.


    Die Sicherheitslücke wurde bereits im Update vorher behoben (1.0.1e-2+deb7u5).

  • Vielen Dank für die Korrektur!


    Sagen wir es so: Es gab zwei Sicherheitsupdates bei Debian :)


    Rückmeldungen im Support bestätigen, dass viele das erste Update eingespielt, dann aber die Dienste nicht neu gestartet haben.


    Viele Grüße


    Felix Preuß

  • Hallo zusammen.


    Nur das openssl Paket updaten reicht nicht aus. Zumindest ist mir das unter Debian aufgefallen. Extrem wichtig ist auch die libssl zu updaten, da die Anwendungen dieses Paket nutzen.


    Hier noch ein Link unter dem ihr überprüfen könnt, ob noch ein Ridiko besteht: Heartbleed OpenSSL extension testing tool, CVE-2014-0160


    EDIT:
    Zu Erwähnen ist natürlich auch noch, dass alle Libraries/Anwendungen die statisch mit openssl gelinked wurden auch noch ein Update brauchen!
    Wenn ich mich recht erinnere, enthält das Modul mod_spdy (SPDY Erweiterung für den Apache) statisches SSL.
    Dadurch kann es vorkommen, dass der Heartbleed Bug weiterhin aktiv bleibt!


    Viele Grüße
    Marcel Luckas

  • Mein über netcup bezogenes Zertifikat habe ich jetzt doch vorsichtshalber austauschen lassen, auch wenn es nächsten Monat sowieso erneuert worden wäre. War nach einer Stunde alles erledigt :)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)