Computersicherheit - Warum sich der Bereich zurückentwickelt

Computersicherheit

Warum sich der Bereich zurückentwickelt

Marc Ruef
by Marc Ruef
time to read: 8 minutes

Sie sind schuld! So oder so ähnlich klang der Vorwurf, den mir ein Hersteller einer Sicherheitslösung in einem Telefonat an den Kopf warf.

Aber lassen Sie mich die Geschichte von vorne beginnen. An einem kühlen Morgen des letzten Herbsts fand ich mich im Server-Raum einer unserer Kunden wieder. Eine Privatbank aus Zürich, die ein sehr gepflegtes Netzwerk ihr eigen nennt. Während mir die Server die heisse Luft ihres Innenlebens entgegenbliesen, hackte ich wie wild auf meiner Tastatur herum. Meine Aufgabe in diesem schon fast menschenfeindlichen Umfend, bestehend aus riesen Blechkisten war es, eine potentielle Sicherheitslücke in der frisch eingeführten E-Banking Lösung zu finden. Na ja, nicht das erste Mal, dass man mich auf so etwas loslässt und meine Erfahrung hat entsprechend meinen Optimismus nur gestärkt, dass ich wohl oder übel etwas finden werde.

Die Stunden vergingen, als ich denn so vor meinen VMware-Geräten sass und mich durch unendliche Zeilen an Programmcode und Ausgaben meiner Analyse-Tools wühlte. Plötzlich fiel mir etwas auf: Die Authentisierung des Benutzers findet in einem ersten Schritt mittels Benutzername und Passwort über die Web-Schnittstelle statt. Es war mir nun möglich zu bestimmen, wohin der Benutzer nach dem Durchlaufen dieser Authentisierungs-Prozedur landen würde. Das Umsetzen von Phishing-Attacken war nun ein Kinderspiel, denn ich konnte jeden Online-Kunden der Bank auf meine eigenen Server locken und ihm dort die sensitiven Kunden-Daten aus der Tasche ziehen. Heureka, Auftrag erfolgreich erledigt!

Nach dem eindeutigen Verifizieren meiner Vermutung besprach ich das Problem kurz mit dem Security Officer der Bank. Ich schilderte ihm die Möglichkeiten und taxierte die Schwachstelle als ernstzunehmendes Risiko für die Reputation der gesamten Bank. Er stimmte mir zu. Ich schlug vor, dass ich mich sofort mit dem Hersteller der betroffenen Lösung – namentlich Netegrity – in Verbindung setzen würde, damit so schnell wie möglich Gegenmassnahmen ergriffen werden konnten. Ein Patch oder ein Workaround in der Konfiguration wären ideal, um dem Problem mit möglichst wenig Aufwand von unserer Seite Rechnung zu tragen. Als ich zurück im Büro war, schrieb ich sofort ein Email an Netegrity, in dem ich das Problem kurz schilderte und um eine baldige Rückantwort bat.

Es vergingen keine zwei Stunden, da klingelte mein Telefon. Die Nummern-Anzeige liess ein Anruf aus Frankreich vermuten. Mit gebrochenem Englisch begrüsste mich ein Herr von Netegrity. Ich war froh, dass so schnell jemand reagierte, denn ich lasse meine Kunden nur ungern exponiert im Internet alleine. Mein Gegenüber bedankte sich, dass ich das Problem gemeldet habe. Er wolle nun jedoch wissen, um welchen Kunden es sich handelt. Ich verweigerte eine Auskunft, denn durch das stets mit unseren Kunden abgeschlossene Non Disclosure Agreement (NDA) und das uns auferlegte Schweizer Bankengesetz ist es untersagt, mit Drittpersonen in irgendeiner Weise über unsere Kunden und die Beziehungen mit ihnen zu sprechen. Wir halten uns daran und eine Hilfestellung muss auch ohne die Weitergabe dieser Information erfolgen, erwiderte ich auf die Frage. Der Ton meines neuen Freundes aus Frankreich wurde schärfer. Er griff mich an und fragte, warum ich mich denn übrhaupt mit ihnen in Verbindung gesetzt hätte, wenn ich mich sowieso nicht kooperativ verhalten möchte. Ich wies nocheinmal sachlich darauf hin, dass ich an Abmachungen gebunden sei und zuerst unseren Kunden fragen müsse, ob er eine Preisgabe seines Namens zustimmt. Mein Gesprächspartner meinte darauf hin, dass ich die Bewilligung einholen müsse und er mir ansonsten nicht weiterhelfen würde. Ich bestätigte und legte den Hörer wieder zurück in die Gabel.

Unverzüglich rief ich unseren Kunden an und schilderte ihm den Ablauf des etwas sonderbar anmutenden Gesprächs. Wie auch ich sah er den Grund nicht, warum Netegrity den Namen des Kundens zur Bearbeitung eines technischen Grundproblems ihrer Lösung wissen wolle. Der Kunde verweigerte die Herausgabe seines Namens und übertrug mir nocheinmal die volle Kompetenz bei der Abarbeitung dieses Falls.

Wiederum rief ich meinen Kontakt bei Netegrity an und teilte ihm mit, dass die Nennung des Kundens nicht möglich sei. Die Abarbeitung des Problems sei sowieso kundenunabhängig und betreffe jegliche Installation von Netegrity SiteMinder. Ich hätte das Problem ja auch bei einem privaten Test per Zufall finden können und in einem solchen Fall könne ich ebenso nicht mit einem Kundennamen aufwarten. Mein zunehmends unfreundlicher werdendes Gegenüber sagte mir schroff, dass er sich nicht mehr mit mir unterhalten wolle. Der Kunde müsse nun über die offizielle Webseite einen Support-Case eröffnen und dort kommt er halt um die Nennung seines Namens bzw. seiner Kundennummer nicht herum.

Einmal mehr rief ich unseren Kunden an und schilderte ihm das letzte Gespräch. Auch er wurde langsam über das Verhalten von Netegrity ungehalten. Er weigerte sich, einen offiziellen Support-Case zu eröffnen, denn die technischen Daten zum Problem habe ich schon bei meinem ersten Email an Netegrity geliefert. Es lag eigentlich nur noch am Hersteller, mir einen Hinweis auf das weitere Vorgehen und eine Terminierung für eine Lösung mitzuteilen. Ich einigte mich mit dem Kunden darauf, dass wir nun noch einige Wochen ins Land gehen lassen würden. Danach setzen wir ein Advisory zum Problem auf, das wir über die jeweiligen Sicherheits-Mailingliste und -Newsseiten verteilen. Durch das Publizieren der Schwachstelle machen wir dem Hersteller Druck, so dass er sich des Problems zwingend annehmen muss.

So war es denn nun auch. Ich setzte ein kleines Advisory auf, das ich an die üblichen Dienste wie Bugtraq, Full-Disclosure, SecuriTeam.com und Secunia schickte. Ebenfalls nahm ich das Problem in unsere hauseigene Verwundbarkeitsdatenbank auf. Die Resonanz auf unser Advisory war interessant. Eine Vielzahl an Firmen, die die gleiche Lösung einsetzen, schrieben uns an und baten um Unterstützung. Sie erbeteten zusätzliche Details zum Problem und fragten, ob wir denn schon einen Workaround ausgearbeitet hätten. Ich merkte, dass die Sache durchaus für so manche Bank ein reales Risiko darstellte.

Ich bin der Meinung, dass ein Hersteller – egal welcher Couleur – das Recht auf eine faire Behandlung bei neu entdeckten Sicherheitsproblemen hat. Dies bedeutet, dass man nach einem Fund sofort den Hersteller informiert und mit ihm das weitere Vorgehen koordiniert. In den meisten Fällen wird er die kommenden Tagen oder Wochen für die Entwicklung eines Patches investieren. Sobald dieser erscheint, wird ein Advisory herausgegeben, der die Benutzer auf das Problem und die möglichen Gegenmassnahmen aufmerksam macht. So kann garantiert werden, dass das Zeitfenster für erfolgreiche Angriffe möglichst klein gehalten wird. Der Hersteller muss nicht erst nach der Veröffentlichung eines Exploits unter Zeitdruck mit einer Gegenmassnahme reagieren.

Das Verhalten von Netegrity hat aber eindeutig bewiesen, dass weder der Kunde noch die Qualität des Produkts von Wichtigkeit ist. Netegrity war einzig und alleine darum bemüht, den Kunden zu identifizieren und ihm die Sache schön zu reden. Dadurch sollten wir als kritische Auditoren umgangen und hinter unserem Rücken Lobbyismus betrieben werden. Es kostet weniger Geld, einen Kunden mit Geschwafel einzulullen, weder einen funktionierenden Patch auszuarbeiten. Der Kapitalismus treibt manchmal sonderbare Früchte.

Dies ist nicht die einzige Geschichte mit einem solchen Ablauf, der aufgrund fehlender Kooperation durch Hersteller mit einem absoluten Nachteil für alle Beteiligten endet. Mir fällt es schon länger auf, dass Sicherheitsprobleme zunehmends durch „mafia-ähnliche“ Methoden bearbeitet werden. Hersteller ignorieren Meldungen zu Schwachstellen, Advisories werden einfach zurückgehalten oder durch einen Marketing-Vertreter schöngeredet, Auditoren werden mit Drohung von Anwälten eingeschüchtert oder in der Öffentlichkeit diffarmiert.

Die Konsequenz davon ist verheehrend. Eine Vielzahl an Leuten, die sich in den vergangenen Jahren durch ausgezeichnete Publikationen und clevere Exploits einen Namen gemacht haben, ziehen sich zunehmends aus der Öffentlichkeit zurück. Ihnen fehlt der Wille und die Energie, auch weiterhin auf Schwachstellen hinzuweisen. Der Lohn, der ihnen gezollt wird, ist ja sowieso nur Ignoranz oder gar Aggressivität. Die Anzahl der technisch fundierten Advisories hat in letzter Zeit abgenommen – Ich zweifle aber daran, dass auch wirklich weniger Sicherheitslücken in den eingesetzten Produkten gegeben sind. Die Einschüchterung der Hersteller scheint zu funktionieren. Die freien Journalisten der Computersicherheit sind zum Grossteil mundtot gemacht. Zustände, die an die staatliche Zensur in China erinnern.

Das Ganze macht mich traurig, denn der Kapitalismus hat sich eine Welt geschaffen, in der er sich selber legitimiert. Dadurch schützt er seine eigenen Interessen und kann fast nicht mehr durchbrochen werden. Vor allem dann, wenn das EU-Parlament irgendwelche dubiosen Gesetze verabschiedet, die es verbieten, sich mit Sicherheitslücken in Computersystemen auseinanderzusetzen. Das ist so, wie wenn den Zeitungen durch ein Gesetz verboten werden würde, auf fehlerhafte Arbeiten der Polizei hinzuweisen. Ein solches Gesetz schützt den Staat davor, sich Kritik aussetzen zu müssen. Dies ist der erste und wichtigste Schritt in die Richtung eines autoritären Systems.

About the Author

Marc Ruef

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

You are looking for an interview partner?

Our experts will get in contact with you!

×
Specific Criticism of CVSS4

Specific Criticism of CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentication

Voice Authentication

Marc Ruef

Bug Bounty

Bug Bounty

Marc Ruef

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here