Startseite > Datenschutz, Internet, Sicherheit, Sonstiges, Statische Tags, Technik > Wie das BSI unsere Daten „schützt“. Ein Rant über die Schwachstelle im GSTOOL.

Wie das BSI unsere Daten „schützt“. Ein Rant über die Schwachstelle im GSTOOL.

TL;DR: Das BSI gibt ein Tool heraus, welches sensible Daten über die IT-Sicherheit von deutschen Firmen vor ausländischen Industriespionen schützen soll. Die Verschlüsselung ist derartiger Murks, dass sie als Spielzeug für Hacker verwendet wird. Sie lässt sich innerhalb von Sekunden bis Minuten knacken. Das BSI reagiert auf Sicherheitsforschung mit juristischen Drohungen – was dazu geführt hat, dass das BSI erst Jahre nach der ersten Entdeckung des Problems davon erfahren hat. Ein Sicherheitsupdate ließ über eineinhalb Jahre auf sich warten, und die Sicherheitswarnungen haben nicht alle Kunden erreicht. Es entsteht leicht der Eindruck, dass das BSI vor allem daran interessiert war, dass die peinlichen Fehler nicht allzu öffentlich werden.

Eigentlich wollte ich ja nur wissen, ob Chiasmus sicher ist. Die sagenumwobene, geheimgehaltene, nicht veröffentlichte1) Chiffre, die das BSI damals, in den dunklen Zeiten der Kryptographie, entwickelt hat. Es war damals eine durchaus nachvollziehbare Entscheidung, eine eigene Chiffre zu entwickeln. Der damalige weltweite Standard, DES, war auf Wunsch der NSA vermurkst und unsicher, AES noch nicht standardisiert – womöglich waren zu Beginn der Entwicklung Rijndael (das heutige AES) und Twofish noch gar nicht publiziert.2)

Die Chiffre ist in einem gleichnamigen Programm eingebaut, was man aber nur bekommt, wenn man ein öffentliches Interesse nachweisen kann. Das BSI hat auch ein Hilfsmittel für den IT-Grundschutz, das sogenannte GSTOOL, herausgegeben. Das GSTOOL (in der betroffenen Version) wurde nicht vom BSI programmiert, sondern von Steria-Mummert. Mit dem GSTOOL werden sensible Informationen über die Sicherheit von IT-Netzen verwaltet – insbesondere bei Firmen, die besonders schutzbedürftig sind, sowie bei Behörden. Deswegen bietet das GSTOOL auch eine Verschlüsselungsfunktion, welche ebenfalls auf der Chiasmus-Chiffre basiert. Diese Verschlüsselungsfunktion soll die Daten vor Kriminellen und vor ausländischen Geheimdiensten schützen. Daten, die zum Beispiel für Industriespione ein gefundenes Fressen wären.

Die Entdeckung

Vor knapp zwei Jahren. Wir sitzen zu dritt vor einem Computerbildschirm. Facepalmend. Auf dem Bildschirm ein Debugger, der die Schlüsselerzeugungsfunktion von GSTOOL zeigt. Verschlüsselungsschlüssel müssen zufällig und nicht vorhersagbar sein, denn sonst kann ein Angreifer sie erraten und dadurch die Nachricht entschlüsseln. Deswegen erzeugt man sie mit speziellen, sicheren (Pseudo-)Zufallsgeneratoren. Wenn man kompetent ist. Wenn nicht, googelt man „c++ zufallszahlen“, klickt das erste Ergebnis an und verwendet was man da sieht. Dummerweise sieht man da vermutlich etwas wie das hierdas Standardverfahren zum Erzeugen von Zufallszahlen. Und dummerweise sind die Zufallszahlen, die so erzeugt werden, vielleicht gut genug für die Würfel in einer digitalen Version von Mensch-Ärgere-Dich-Nicht, aber nicht für kryptographische Schlüssel. Das weiß eigentlich jeder, der auch nur ansatzweise Ahnung von Kryptographie hat. Die Entwickler des GSTOOL wussten es offensichtlich nicht. Und das BSI hat es in all den Jahren offensichtlich nicht für nötig gehalten, die Verschlüsselungsfunktion zu überprüfen, denn dann wäre zumindest eines der Probleme aufgefallen. Denn die Schlüsselerzeugung war zwar das schlimmste, aber nicht das einzige Problem. (Die Details gibts im Advisory)

Einige Zeit und einige hundert Zeilen Code später haben wir eine Software, welche mit dem GSTOOL Chiasmus-verschlüsselte Dateien entschlüsseln kann – ohne Schlüssel, in der Regel innerhalb von Sekunden. In einer Mail an das BSI bitten wir um eine verschlüsselte Testdatei – und senden sie postwendend zurück. Entschlüsselt.

Bitte keine Ergebnisse

In einigen Tagen gelangweiltem Stochern haben wir die Verschlüsselung komplett zerlegt. Totalschaden. Weniger als 2^32 effektive Schlüssellänge – das ist ein Wert, bei dem man aufhört, den Angriff zu optimieren, weil es eh schon schnell genug geht. Und das war keine besonders anspruchsvolle Aufgabe, sondern eigentlich nur Fleißarbeit. Wir haben die Software fertig analysiert, dem BSI und Steria-Mummert Ratschläge zur Behebung des Problems gegeben, und schließlich auch ein Paper mit den Analyseergebnissen geschickt, in welchem auch die Chiffre selbst beschrieben war.

Als Antwort auf das Paper erhielten wir unmissverständliche und sehr deutliche juristische Drohungen, dass das Reverse Engineering einen Urheberrechtsverstoß darstelle und von den Juristen des BSI „sehr strikt verfolgt“ würde. Daher wurden wir „dringend gebeten“ das Paper nicht zu veröffentlichen. Um dem BSI Zeit zur Fehlerbehebung zu geben und unnötige Konfrontationen zu vermeiden, haben wir eine zeitnah geplante Veröffentlichung verschoben (was im Nachhinein gesehen angesichts der langen Dauer bis zum Patch IMHO ein Fehler war). Erst als deutlich wurde, dass wir uns nicht einschüchtern lassen und das Paper definitiv irgendwann veröffentlichen werden, wurden die Drohungen telefonisch entschärft.

„Lösung“

Am 25.11.2011, über eine Woche nachdem das BSI vom Problem erfahren hat, wurde eine öffentliche Sicherheitswarnung herausgegeben; ein Sicherheitsupdate sollte in Kürze folgen. Aus „in Kürze“ wurden eineinhalb Jahre. Eineinhalb Jahre, in der eine hochkritische Sicherheitslücke in einer Verschlüsselungssoftware offen blieb. Die Sicherheitswarnung ist inzwischen auf keiner offiziellen Seite mehr aufzufinden, und hat nicht alle Kunden erreicht – in einem persönlichen Gespräch Ende 2012 war ein Nutzer über die Information überrascht und hat gesagt, dass die GSTOOL-Verschlüsselung immer noch regelmäßig benutzt werde. Das Sicherheitsupdate wurde ebenfalls kaum angekündigt, auch wir erfuhren davon nur durch Zufall, als wir auf der BSI-Website nachgeschaut haben.

Klar ist so eine dämliche Sicherheitslücke peinlich. Aber ich werde den Verdacht nicht los, dass das BSI mehr darauf bedacht war, negative Öffentlichkeit zu vermeiden, als für Sicherheit zu sorgen. Das führt dann eben dazu, dass es auch Nutzer nicht mitbekommen und so der wertlosen Verschlüsselung weiter vertrauen.

Das „Sicherheitsupdate“ bestand am Ende übrigens daraus, die Verschlüsselungs-Schaltfläche zu deaktivieren. Ohne einen Hinweis im Programm, warum das der Fall ist. Nur wer in die Update-Notizen schaut oder eine Sicherheitswarnung des BSI erhalten hat, erfährt, dass die Verschlüsselung geknackt ist.

Spielzeug

Das offensichtliche Problem, dass die GSTOOL-Verschlüsselung den unsicheren Modus ECB benutzt, war bereits Christian Gresser vom Blog „Mitternachtshacking“ aufgefallen. Und zwar 2008. Durch Zufall erfuhren wir später, dass wir auch nicht die ersten waren, die die defekte Schlüsselerzeugung gefunden haben. 2009 fragte Felix Schuster beim BSI an, ob sie daran interessiert wären, wenn er das Tool analysiert, und bekam rechtliche Drohungen als Antwort.  Er fand trotzdem die gleichen Ergebnisse wie wir, teilte sie dem BSI aber aus offensichtlichen Gründen nicht mit.

Später verwendete er ein GSTOOL-Chiffrat als Aufgabe in einem CTF-Contest – einem Wettbewerb, wo Sicherheitsexperten/Hacker in einem simulierten Netzwerk versuchen, ihre Systeme zu schützen und in die der Mitspieler einzudringen, und nebenbei noch kleine Aufgaben lösen. Die „hochsichere“ Verschlüsselung dieses von offizieller Stelle herausgegebenen Tools war also so schlecht und leicht knackbar, dass sie als Spielzeug für Hacker, eine kleine Aufgabe für zwischendurch, verwendet wurde. Immerhin gab es für die „Borg-Bureaucrats“ stolze vierhundert Punkte. Die Aufgabe wurde erfolgreich gelöst und der glückliche Gewinner hat dem BSI wohl Bescheid gesagt – vermutlich in einem relativ engen zeitlichen Zusammenhang zu unserer Meldung. (Details dazu wissen wir leider nicht)

Das würde auch erklären, warum das BSI im Advisory unsere Namen nicht nennen wollte, wie es eigentlich üblich ist, wenn man einer Organisation schon kostenlos Sicherheitslücken meldet. Wer weiß, wie viele andere das Problem schon vorher entdeckt hatten. Felix hat über die Probleme vor Kurzem einen Vortrag gehalten und die Folien online gestellt. Diese enthalten auch eine Beschreibung des Algorithmus, falls sich jemand an einer Kryptoanalyse versuchen will.

We are not alone

Das Erschreckende an dieser ganzen Sache: Wenn wir auf die Idee gekommen sind, uns GSTOOL anzuschauen, und vor uns schon mehrere andere, dann haben ausländische Geheimdienste das sicher auch gemacht. Und die Probleme sind bei einer Analyse nicht zu übersehen. Normalerweise muss sich die NSA die Mühe machen, die Zufallsgeneratoren und andere Komponenten von Kryptosystemen mittels Hintertüren zu sabotieren, hier gabs ein von Haus aus kaputtes System gratis. Und um diese Lücke zu finden, braucht es keine NSA-Experten. Das hat der chinesische Geheimdienst und jeder andere Wirtschaftsspion sicher auch hinbekommen. Kein schöner Gedanke für deutsche Unternehmen, die sich auf die Sicherheit dieser von einer für die IT-Sicherheit zuständigen Behörde herausgegebenen Software verlassen haben.

Und statt zeitnah auf eine solche Lücke zu reagieren (oder von vorne herein dafür zu sorgen, dass so etwas gar nicht erst veröffentlicht wird), bedroht das BSI lieber Sicherheitsforscher, um zu verhindern, dass solche Probleme öffentlich werden. Ohne die Drohungen hätte das BSI wohl bereits 2009 von den Problemen erfahren.

Damit hat das BSI den letzten Funken Glaubwürdigkeit in der IT-Sicherheit verloren. Schade eigentlich, denn die Chiasmus-Chiffre an sich (die vom BSI selbst entwickelt wurde) sieht sicher aus, das BSI hat also durchaus kompetente Leute (oder hatte sie zumindest damals). Für die Sicherheitsprobleme sorgen erst die Implementierungsfehler von Steria-Mummert im GSTOOL (weswegen „Chiasmus für Windows“ auch nicht von der Lücke betroffen sein sollte).

Es war eine gute Idee, dass ich damals bei der AusweisApp direkt veröffentlicht habe, statt erst das BSI zu kontaktieren. Angesichts der Erfahrungen in diesem Fall werde ich jedenfalls in Zukunft nur noch „full disclosure“ fahren (d.h. gefundene Probleme sofort öffentlich machen), wenn ich irgendwelche Lücken in „offizieller“ Software finde. Alles andere sorgt nur für unnötig Stress, Verzögerungen und unter-den-Teppich-kehren.

Auch Kontakt mit dem BSI gehabt? Kunde/Nutzer von GSTOOL und Hinweise vom BSI bekommen (oder eben nicht)? Ich freue mich über Rückmeldungen über die Kommentarfunktion oder per E-Mail!

Fußnoten:

1) Eine Chiffre nicht zu veröffentlichen ist unüblich und gilt als verpönt – eine gute Chiffre ist auch dann sicher, wenn der Angreifer sie kennt, solange er den Schlüssel nicht hat. Vor den wirklich „Bösen“ kann man die Chiffre nicht langfristig geheimhalten, aber wenn die Chiffre nicht öffentlich ist, bleiben Schwächen oft lange für die Nutzer der Chiffre verborgen.

2) AES und Twofish wurden 1998 publiziert. Die erste Referenz zu Chiasmus, die wir finden konnten, erwähnt Chiasmus für Windows in Version 1.3 und ist aus dem Dezember 2001.

  1. 2013-09-11 um 10:56 UTC

    Vielleicht ist die verschlüsselung ja auch mit absicht so schwach um dem NSA Zugriff zu geben ?

    • Jan
      2013-09-11 um 13:28 UTC

      Halte ich für ausgeschlossen. Wenn man sowas macht, dann baut man einen kleinen Fehler ein, der nicht direkt auffällt. Hier zieht sich eine rote Linie von „null Ahnung von Krypto aber programmiert Kryptosoftware“ durch die ganze Verschlüsselungsfunktion. Alle typischen Anfängerfehler sind drin.

      Abgesehen davon hat das BSI eher kein Interesse daran, die Schlüssel zu Geheimnissen deutscher Firmen nicht nur der NSA, sondern auch den Chinesen und allen anderen mit auch nur ansatzweise funktionierendem Geheimdienst zu liefern.

  2. 2013-09-11 um 11:22 UTC

    Netter Artikel. Mich würde aber noch interessieren, welche Version(en) des GSTool da eigentlich betroffen sind und ob letztlich sinnvolle Abhilfe geschaffen wurde.

    • Jan
      2013-09-11 um 13:31 UTC

      Steht im Advisory etwas genauer, Versionen 3.0 bis 4.7. In 4.8 wurde die Verschlüsselung deaktiviert. Ob das für dich „sinnvolle“ Abhilfe ist weiß ich natürlich nicht, aber es verhindert zumindest, dass Leute weiter schlecht verschlüsselte Dateien erzeugen. Einfach GPG oder irgendein anderes bekanntes Open-Source-Tool nehmen und fertig.

  3. Dennis M.
    2013-09-11 um 11:59 UTC

    Auch ich nutze in meiner Tätigkeit als Berater Chiasmus in der Stand-Alone-Version seit mehreren Jahren für eine „sichere“ Kommunikation mit den Stellen der Öffentlichen Verwaltung. Aber eine Warnung oder die Ankündigung eines Sicherheitsupdates hat mich niemals erreicht!

    • Jan
      2013-09-11 um 13:33 UTC

      Die Stand-Alone-Version ist wie im Text erwähnt nicht betroffen, der Murks ist im GSTOOL. (Heißt natürlich nicht, dass im Standalone-Chiasmus nicht andere Fehler drin sein können, aber ich denke, da haben wesentlich kompetentere Leute dran gearbeitet.)

  4. 2013-09-11 um 13:13 UTC

    Ich bin Anwender des GSTOOLs, aber von dieser Schwachstelle lese ich hier zum ersten Mal. Informationen vom BSI habe ich jedenfalls nicht erhalten (und falls doch, sind diese in einem ihrer Newsletter so versteckt gewesen, dass es mir nicht aufgefallen ist). Die genannte Verschlüsselungsfunktion nutzen wir allerdings nicht, daher betrifft uns das Problem zumindest nicht direkt.

    • 2013-09-11 um 13:33 UTC

      So, ich hab mal die Newsletter durchsucht. In der Ankündigung des Servicepacks steht im Fließtext folgendes:
      „Eine Einschränkung bringt das Servicepack leider auch mit sich. Die Verschlüsselungsfunktionalität wird deaktiviert, da dessen Implementierung in das GSTOOL angreifbar wurde. Wir bedanken uns bei der Technischen Universität Darmstadt, die diese Schwachstelle aufgedeckt und das BSI frühzeitig darauf hingewiesen hat.“

      • 2013-09-11 um 14:02 UTC

        Bin neugierig: Von wann war der Newsletter?

        • Entwickler
          2013-09-16 um 09:35 UTC

          Die Anleitung vom Servicepack ist vom 6.6.2013

  5. Alfred E. Neumann
    2013-09-11 um 15:14 UTC

    Das BSI hat ein SICHERES Haendchen, Auftraege an schlampig arbeitende Firmen zu vergeben: die aktuelle AusweisApp enthaelt grosse Teile der voellig veralteten und unsicheren JRE 7u9 (vor dem Nachfolger 7u10 warnt das BSI selbst seit Anfang des Jahres:
    https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2013/Krit_Schwachstelle_Java-7-10_11012013.html
    https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2013/Entwarnung_Update_Schw_Java_7_10_14012013.html)
    und dazu noch veraltete und unsichere MSVCRT++-Laufzeitbibliotheken 8.0.50727.762 und 10.0.30319.1
    (http://technet.microsoft.com/security/bulletin/ms11-025
    http://support.microsoft.com/kb/2538218
    http://support.microsoft.com/kb/2565063) sowie statisch gebundene Teile von OpenSSL 1.0.0c

    Hinweise auf diese Schlampereien bleiben seit Jahren unbeantwortet

  6. G. Heim
    2013-09-12 um 07:12 UTC

    Wenn man die letztes Statements unseres Bundesinnenministers zum Thema NSA/Prism hört, was erwartet man dann von einem dem Innenministerium angeschlossenen BSI?

  7. Entwickler
    2013-09-16 um 09:28 UTC

    Diese Funktion ist innerhalb des GSTOOLs immer überflüssig gewesen. Die Verschlüsselung war dazu gedacht Exporte zu verschlüsseln und dann über unsichere Wege zu versenden. Das fand de facto im Behördenalltag kaum oder sogar nie statt. Interessant deshalb auch, dass erst nach 7-8 Jahren überhaupt jemand auf die Idee kam diese Funktion zu analysieren.
    Die Export- und Import-Funktionen gehörten dazu ohnehin zu dem am meisten nicht genutzten Funktionen des GSTOOLs und waren m. E. schon 2001 nicht mehr zeitgemäß.
    Daher finde ich die vom BSI Aufhebung des Problems durch Abschaltung des Funktion auch für absolut gerechtfertigt.

  8. Entwickler
    2013-09-16 um 09:51 UTC

    Zitat: Das BSI gibt ein Tool heraus, welches sensible Daten über die IT-Sicherheit von deutschen Firmen vor ausländischen Industriespionen schützen soll.
    -> Das ist vollkommen falsch. Richtig ist:
    Das GSTOOL stellt ein Werkzeug zur Verfügung, dass dazu dient Sicherheitskonzepte auf Basis des Grundschutzverfahrens zu erstellen und zu verwalten.
    Die fehlerhafte Implementierung beeinflusst die Arbeit mit dem GSTOOL in der Regel gar nicht.

    Zitat: Mit dem GSTOOL werden sensible Informationen über die Sicherheit von IT-Netzen verwaltet – insbesondere bei Firmen, die besonders schutzbedürftig sind, sowie bei Behörden. Deswegen bietet das GSTOOL auch eine Verschlüsselungsfunktion, welche ebenfalls auf der Chiasmus-Chiffre basiert. Diese Verschlüsselungsfunktion soll die Daten vor Kriminellen und vor ausländischen Geheimdiensten schützen. Daten, die zum Beispiel für Industriespione ein gefundenes Fressen wären.
    -> Das ist falsch: Richtig ist:
    Mit dem GSTOOL werden möglicherweise sensible Informationen über die Sicherheit von IT-Netzen verwaltet – möglicherweise auch bei Firmen, die besonders schutzbedürftig sind, sowie möglicherweise bei Behörden. Die Daten werden unverschlüsselt auf einem SQL-Server abgelegt und können ggfs. in Access-Dateien exportiert werden. Zur Verschlüsselung dieser Dateien soll der (falsch implementierte) Chiasmus.

    Also: Abkühlen, denn nur wenige Nutzer sind tatsächlich betroffen und es gibt ein korrekte implementierung des Algorithmus (dessen Sicherheit oder Unsicherheit) gar nicht untersucht wurde.

  9. 2013-11-23 um 20:16 UTC

    Netter Artikel. Mich würde aber noch interessieren, welche Version(en) des GSTool da eigentlich betroffen sind und ob letztlich sinnvolle Abhilfe geschaffen wurde.

    • Jan
      2013-12-09 um 04:01 UTC

      Die Details gibts im verlinkten Advisory. Betroffen sind GSTOOL 3.0 bis 4.7. In 4.8 wurde die Verschlüsselungsfunktion deaktiviert. Das mag keine schöne Lösung sein, aber das Problem ist damit erledigt und Leute werden dazu gebracht, vernünftige Verschlüsselung einzusetzen.

  1. 2013-09-11 um 13:14 UTC
  2. 2013-09-11 um 17:00 UTC
  3. 2013-09-25 um 16:19 UTC
  4. 2013-09-27 um 19:53 UTC

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: