NSA am Wochenende: Heartbleed war seit Jahren bekannt

Die NSA soll den „Heartbleed“-Bug in OpenSSL bereits seit zwei Jahren gekannt und ausgenutzt haben, das berichtete am Freitag die Nachrichtenagentur Bloomberg.  „Heartbleed“ hatte in der letzten Woche viele verunsichert, da der Fehler es ermöglicht hatte, Passwörter und andere sensible Informationen aus Servern auszulesen. Nachdem am Anfang wild spekuliert wurde, ob der Fehler bewusst von Geheimdiensten als Backdoor eingepflanzt wurde, hatte sich dieser Verdacht nicht weiter bestätigt. Zum einen aufgrund der Art des Fehlers, der sich mehr als eine Unachtsamkeit entpuppte, die kurz nach dem Jahreswechsel 2012 Eingang in den Code fand und die nicht besonders gut getarnt gewesen ist als auch aufgrund eines Interviews des deutschen Entwicklers mit dem Sydney Morning Herald, innerhalb dessen er das Entstehen des Fehlers aufgrund einer unterbliebenen Zahlenbereichsprüfung erklärt.

Aber dass die NSA den Code nicht selbst sabotiert hat, heißt noch lange nicht, dass sie nicht trotzdem davon profitieren kann. Und dass die NSA Fehler in Software findet, ist Teil ihrer Aufgabe, wobei sie jedoch offiziellerweise dazu angehalten ist, auf diese Fehler hinzuweisen, um Software und die Welt ein Stückchen sicherer zu machen. Die Öffentlichkeitsbeauftragte der NSA Caitlin Hayden kommentierte gegenüber Bloomberg:

This administration takes seriously its responsibility to help maintain an open, interoperable, secure and reliable Internet. […] Unless there is a clear national security or law enforcement need, this process is biased toward responsibly disclosing such vulnerabilities.

Dementsprechend bestreitet der Geheimdienst, von der Sicherheitslücke gewusst zu haben. Ein Insider, auf den Bloomberg sich beruft, behauptet jedoch, der Bug sei bereits kurz nach seiner Veröffentlichung erkannt worden und ins Standardrepertoire für Spähangriffen aufgenommen worden. Kein Wunder, denn die Verbreitung von OpenSSL ist immens und umfasst einen Großteil der hochfrequentierten, aktiven Server des Netzes. Außerdem war die NSA bereits Ende Dezember wegen der Ausnutzung von Sicherheitslücken in Kritik geraten, als auf dem 30C3 ein „Katalog“ der NSA mit Angeboten für Backdoors und Exploits veröffentlicht wurde.

Am Fall „Heartbleed“ wird ein Problem deutlich, an dem Open Source Software leidet. Der Vorteil, dass Sicherheitslücken und Backdoors erkannt werden können, wenn viele berechtigt sind, Code zu begutachten und zu verändern, ist unbestreitbar. Und natürlich ist es allemal besser als proprietäre Anwendungen, da zumindest die Chance besteht. Aber der Vorteil erscheint beinahe nichtig im Angesicht eines Gegners, der eine schiere Überzahl an Angestellten darauf ansetzen kann, Sicherheitslücken mit professionellen Werkzeugen aufzuspüren. In offener Software als auch in geschlossener, denn wir dürfen davon ausgehen, dass den Geheimdiensten auch weite Teile proprietären Codes zur Verfügung stehen. Die Logik gebietet es, dass sie dadurch immer mehrere Jahre im Vorteil sein werden, was das Aufspüren von Fehlern angeht.

In der NSA-Abteilung, die Sicherheitslücken aufspürt, dürften mehrere hundert oder tausend Experten arbeiten, das Gesamtbudget für „Data Processing and Exploitation“ beträgt Informationen über das Black Budget der amerikanischen Geheimdienste zu Folge 1,6 Milliarden Dollar. Das OpenSSL-Kernteam hingegen besteht lediglich aus vier Personen auf freiwilliger Basis, unterstützt von sieben weiteren Entwicklern – und der Bug wurde nicht einmal von einem dieser Teammitglieder gefunden, sondern von Mitarbeitern von Google und der IT-Sicherheitsfirma Codenomicon. Ein Punkt, an dem man ansetzen kann, denn es würde helfen, wenn die großen Firmen, die von Open Source profitieren, etwas von ihrem Vorteil zurückgeben und aktiv an der Verbesserung des Codes mitarbeiten. An vielen Stellen geschieht das bereits, doch diese Initiativen sind ausbaufähig.

Damit die NSA ihren Vorsprung nicht verliert und Sicherheitslücken auch weiterhin unter dem Deckmantel der Rechtmäßigkeit geheim halten kann, hat US-Präsident Barack Obama in seinen Geheimdienstreformplänen Vorsehungen getroffen. Die New York Times berichtet, die NSA müsse laut Obamas Vorschlag gefundene Schlupflöcher nicht veröffentlichen, wenn dies für die nationale Sicherheit erforderlich sei. Diese Hintertür hatte bei der ursprünglichen Veröffentlichung von Obamas Vorschlägen wenig Beachtung gefunden, da die Kompetenzen aktiver Überwachung in den Fokus der öffentlichen Aufmerksamkeit gestellt wurden.

15 Ergänzungen

  1. Kann mir jemand die Diskrepanz erklären zwischen: „Heartbleed war seit Jahren bekannt“ und „die kurz nach dem Jahreswechsel Eingang in den Code fand“
    Der Code bestand vorher schon anderswo, war aber nicht in OpenSSL? Oder wie? Aber dann konnte zumindest die NSA den Bug nicht jahrelang ausnutzen, oder was verstehe ich falsch?

    1. Das war der Jahreswechsel 2012, das hatte ich nicht explizit erwähnt. Ich besser das mal nach.

  2. Da dürfte selbst dem ärgsten „Verteidiger gegen den Terrorismus“ angst und bange werden: Geheimdienste halten also Kriminellen – abgesehen von ihnen selbst – ein Türchen offen. Es brauchte mehr Geld für die Überprüfung des (sicherheitsrelevanten) Codes. Das könnte man auch politisch anschieben, wenn man denn wollte.

  3. Eine Unachtsamkeit? Also, jedes Protokoll muss auch ohne SSL und TLS funktionieren, wenn es erforderlich ist die Tür in einer Firewall oder einem Proxy aufzuhalten dann wird es das machen, oder es ist unvollständig. es ist nicht Aufgabe von SSL.

    Diese Erweiterung ist als ob man irgendwo freundlich an der Tür klingelt und wenn der Betroffene diese schließen möchte stellt der Mafia Dolmetscher einem unverschämt den Fuß in die Tür, das ist nicht seine Aufgabe.

    Diese Erweiterung öffnet einen neuen Informationskanal auf den keiner der Nutzer hingewiesen wurde. Ist als wenn in einem Betrieb ein neuer Warenstrom entsteht von dem der Chef nichts weiß.

    Und dann ist noch aus versehen nirgends dokumentiert gewesen bis Februar, da aber auch nur wo es keiner findet. RFC’s lesen ist leicht, verstehen braucht seine Zeit.

    Es wurde Silvester durchgewunken, das ist wie die Gesetze die unachtsam während der Fußball-WM entschieden werden.

    In der Folge dieser Unachtsamkeiten verstehe ich auch wie aus reiner Unachtsamkeit jegliche Prüfung der Felder unterbleiben konnte.

    Es gibt genug Quellen die belegen das die Macher der Geheimdienste oft selbst Opfer sind und nichts wussten. Die Frage ob die NSA dahintersteht ist disjunkt von der Frage ob der Entwickler etwas von der NSA wusste.

    Ich möchte aber betonen dass ich den Entwickler als Opfer ansehe, seiner selbst, oder wessen auch immer.

  4. Eine Schwachstelle von Open Source? Nicht wirklich, dort kann man den Code einfach so auditieren. Bei kommerzieller (closed-source) Software ist das so kaum möglich.

    1. Open Source lässt Fehler schneller finden, da (theoretisch) jeder sich die Source anschauen kann). Das gilt allerdings auch für den Hacker und für alle Geheimdienste. Fehler lassen sich also schneller finden aber eben auch sehr viel einfache rausnutzen.

      Closed Source dagegen macht es schwer, Fehler zu finden, da die Source nicht zugänglich ist. Genauso schwerer ist es aber auch, Fehler auszunutzen.

      Open Source ist also nicht automatisch sicherer und Closed Source nicht automatisch unsicherer.

      1. Für Open Source spricht in jedem Fall die Transparenz. Wer weiß schon, wie viele sicherheitsrelevante Bugs in Closed Source existieren?

        Zwei notwendige Konsequenzen aus Heartbleed:
        1. Open Source: ja!
        2. Aber: bessere Kontrollen (durch mehr finanzielle Mittel).

      2. Der Vergleich hinkt. Der Gegner den wir in den letzten Jahren kennengelernt haben hatte sicherlich Zugang zu Closedsource. Er hat einen taktischen Vorteil den er bei Opensource nicht hätte.

        Allerdings finde ich Fehler im Debugger und Disassembler und nur bei Opensource kann ich sie schliessen. Das ist ein taktischer Vorteil für Opensource.

      3. @alarm:

        Allerdings finde ich Fehler im Debugger und Disassembler und nur bei Opensource kann ich sie schliessen. Das ist ein taktischer Vorteil für Opensource.

        Richtig, das schrieb ich aber auch. Nur ist es kein taktischer Vorteil, weil dieser zumindest gleich wieder dadurch zunichte gemacht wird, dass der Bösewicht genauso schnell die Sicherheitslücke findet oder finden kann.

        Gegen Insiderwissen hilft erst mal nichts. Aber davon abgesehen muss bei Closed Source ein Bösewicht die Lücke erst mal finden. Dass sie eventuell vorhanden ist, nutzt ihm nichts, weil er – genauso wie der gute Junge – eben den Quellcode nicht hat. Von Zufallsfunden abgesehen, hat der Bösewicht es also deutlich schwerer.

        Closed Source macht es also für den guten und bösen Jungen schwerer. Bei Open Source ist es genau andersherum.

  5. Wenn nun Terroristen gleich welcher Couleur ihre Aktivitäten vermehrt auf „Cyber-Terrorismus“ verlagern würden und dabei Sicherheitslücken ausnutzen würden, die der NSA längst bekannt sind aber verschwiegen wurden, würde also die NSA faktisch terroristische Aktivitäten nicht nur nicht verhindern, sondern in diesem Fall ermöglichen!?

  6. Evtl. wäre es sinnvoll mal den kompletten OpenSSL Code zu reviewen / wenigstens eine automatisierte statische Codeanalyse drüber laufen zu lassen.. Dabei wäre so ein Fehler nämlich zu Tage getreten b.z.w. mindestens als warning aufgetaucht!

  7. Was auch unverständlich ist, dass OpenSSL selbst die Speicherverwaltung in die Hand nimmt und ungenutzen Speicher nicht gleich wieder freigibt.. Würde das nicht der Fall sein, würde man mit dem Heartbleedbug den Prozess früher oder später abschießen, da er auf einen wieder freigegeben Speicherbereich zugreift und dann vom Kernel gekillt wird… Diese funktion hat man eigentlich genau gegen solche Exploits in die Speicherverwaltung von Linux eingebaut.. Leider wird diese von OpenSSL umgangen. Siehe auch: http://article.gmane.org/gmane.os.openbsd.misc/211963

  8. „[…], sondern von Mitarbeitern von Google und der IT-Sicherheitsfirma Codenomicon. Ein Punkt, an dem man ansetzen kann, denn es würde helfen, wenn die großen Firmen, die von Open Source profitieren, etwas von ihrem Vorteil zurückgeben und aktiv an der Verbesserung des Codes mitarbeiten. […]“

    Ihr widersprecht euch doch selbst… Google hat doch den Review doch ohne Probleme machen können, weil es freie Software ist!

    Außerdem werden große Teile von freier Software doch von Red Hat, Google, IBM, Intel, wen-ich-noch-vergessen-habe erstellt/gepflegt… wenn das keine Großen Firmen sind weiß ich auch nicht!

Dieser Artikel ist älter als ein Jahr, daher sind die Ergänzungen geschlossen.