The web is completely broken,

sagt sinngemäss Jeremiah Grossman [1], ein alter Hase im Bereich der Web Application Security. Zwar vertreibt seine Firma auch einen eigenen Webbrowser mit Fokus auf Security und vor allem Privacy, Recht hat er trotzdem: Täglich verwenden wir Technologien, welche das Etikett “Broken by Design” tragen (sollten). In diesem Artikel befassen wir uns mit zwei Themen: Cross Site Request (Forgery) CSR(F) und Certificate Authorities (CA). Die Probleme sind seit Jahren bekannt. Heute wurde gerade wieder ein CSRF-Exploit für WordPress 3.9.1 publiziert. Und ja, das ist die aktuelle WordPress-Version.

CSR(F) – Cross Site Request (Forgery)

Cross Site Request Forgery ist im Gegensatz zu seinem Bruder Cross Site Scripting nur marginal bekannt. Dennoch belegte CSRF 2010 in den OWASP Top Ten Platz 5, und im Jahr 2013 immerhin noch Platz 8. Es handelt sich folglich um eine häufige und durchaus kritische Sicherheitslücke in Webapplikationen. Doch was ist CSRF und was hat das mit “Broken by Design” zu tun?

Viele Webseiten binden externe Ressourcen, beispielsweise Bilder, Javascripts oder Werbung, ein. Das Adjektiv extern verweist hierbei auf eine andere Domäne. Ein Beispiel: Was geschieht, wenn man auf die Webseite einer typischen Schweizer Tageszeitung http://www.typischeschweizertageszeitung.ch/ geht?

Es werden Ressourcen von typischeschweizertageszeitung.ch geladen.
Es werden weitere Ressourcen von beispielsweise adtech.de, cxense.com, cxpublic.com, visualrevenue.com, wemfbox.ch etc. geladen.
Es werden von cxpublic.com wiederum weitere Ressourcen von 2mdn.net, serving-sys.com etc. geladen.

Diese Anfragen für externe Ressourcen nennt man Cross Site Requests. Und jetzt? Zunächst muss man sich fragen, wer denn diese Requests im Auftrag von typischeschweizertageszeitung.ch ausführt: der Browser. Anschliessend muss man verstehen, dass dieser Request unter Verwendung sämtlicher lokal gespeicherter Daten (insbesondere Cookies) für diese externe Domäne abgesetzt wird. Schauen wir uns ein relativ harmloses Beispiel an:

<html>
<head>
<script type="text/javascript">
   function csrf() {
      alert("Auf 192.168.1.1 läuft ein Apache Server unter OpenBSD.");
   }
   function nocsrf() {
      alert("Test fehlgeschlagen, aber vielleicht funktioniert etwas anderes? ...");
   }
</script>
</head>
<body>
   <img src="http://192.168.1.1/openbsd_pb.gif" onload="csrf()" onerror="nocsrf()">
</body>
</html>

Der Betreiber der Webseite (oder ein Angreifer, welcher die Kontrolle über diese Webseite erlangt hat) kann mit diesem Code ermitteln, ob im lokalen Netzwerk des Webseiten-Besuchers auf der IP 192.168.1.1 [2] ein (default) Apache-Server unter OpenBSD läuft. Weitergeführt kann CSRF dazu verwendet werden, Informationen über ein lokales Netzwerk des Webseiten-Besuchers zu sammeln. Und noch mehr: Bereits im Jahr 2009 ist es TecChannel [3] damit gelungen, die Konfiguration von typischen Heimroutern (Fritz!Box, LinkSys, ZyXEL) beliebig zu verändern. Ein vorstellbares Szenario dabei ist die Manipulation der DNS-Auflösung, um beispielsweise Bankenseiten auf vom Angreifer kontrollierte Seiten umzulenken, siehe hierzu auch CA – Certificate Authority. Und noch mehr: Da in einem Cross Site Request das Cookie mitgegeben wird, kann der Angreifer den Umstand ausnutzen, dass ein Benutzer bei einer anderen Webseite (Soziales Netzwerk, Webmail) eingeloggt ist. Ein vorstellbares Szenario dazu ist das (ungewollte) Hinzufügen von “Freunden” oder Absenden von E-Mails. Ein weiteres Beispiel neueren Datums: Vor knapp einer Woche (12.06.2014) hat OpenNebula die Version 4.6.2[4] veröffentlicht. Warum? Dennis Felsch und Mario Heiderich der Ruhr-Universität Bochum haben CSRF-Schwachstellen entdeckt, welche root-Access und Denial-of-Service-Attacken erlauben.

Fazit

Cross Site Requests sind “Broken by Design”. Sie erweitern das Web mit potentiellen Sicherheitslücken, dennoch kann man sie nicht entfernen. Die Verantwortung, Cross Site Request Forgery zu verhindern, wird den Webapplikations-Entwicklern weitergereicht. Gegenmassnahmen sind nicht schwierig (beispielsweise über Synchronizer Token Pattern), müssen aber gemacht werden.

CA – Certificate Authority

Spätestens seit Heartbleed ist SSL/TLS in jedermanns Munde. Doch wie funktioniert SSL/TLS, was sind Zertifikate und wie kommen Certficiate Authorities (CA) ins Spiel? David Basin und Ueli Maurer von der ETH Zürich geben in ihrem inspirierenden Seminar Information Security and Cryptography[5] formale Definitionen und zeigen deutlich auf, dass wir auf ein Trust Model setzen, welches dem Wort Trust eine andere Bedeutung zukommen lässt als gemeinhin angenommen. Doch wir greifen vor.

Wann immer wir sensitive Daten, wie beispielsweise Kreditkarten-Nummern, über das Internet senden, stellen wir sicher, dass wir uns mit einer https-Verbindung mit dem Zielserver verbinden. https entspricht http, dem HyperText Transfer Protocol, aber zusätzlich werden die Daten über eine sichere SSL/TLS-Verbindung gesendet, welche mit AES, Camellia, ECC, RSA etc. sicherstellt, dass die übertragenen Daten verschlüsselt sind. Wir sind also sicher! Sind wir das? Wir beschäftigen uns jetzt nicht mit NSA-gefärbten Audits der verwendeten Verschlüsselungsalgorithmen oder Man-In-The-Middle Attacken, sondern mit dem Design von SSL/TLS an sich. In diesem Protokoll identifiziert sich der Server über ein Zertifikat, welches besagt: “Ich bin der Server switch.ch und dies ist mein Public Key”. Doch woher kommt das Vertrauen in dieses Zertifikat? Jeder Webserver kann diese Aussage machen. Der Schlüssel zum Vertrauen liegt in den Certificate Authorities. Betrachtet man das Zertifikat von switch.ch genauer, stellt man fest, dass dieses Zertifikat von QuoVadis Global SSL ICA G2 herausgegeben, welches wiederum von QuoVadis Root CA 2 herausgegeben wurde.

Weiter sind wir damit eigentlich nicht, denn wir begründen das Vertrauen in das Zertifikat von switch.ch mit dem Vertrauen in QuoVadis Root CA 2. Und woher kommt dieses Vertrauen? Vom Browser selbst. Von einem Stück Software, welches lokal auf dem PC des Benutzers installiert ist. Wie? Das Zertifikat QuoVadis Root CA 2 ist ein Builtin Object Token des Browsers, abgelegt im Bereich der Authorities. Diese speziellen Zertifikate, und es gibt viele davon, sind letztendlich für das Vertrauen im Web verantwortlich. Was heisst das?

Global: Ist eine Authority kompromittiert (siehe beispielsweise DigiNotar [6] oder TürkTrust [7]) ist das ganze Web kompromittiert.
Lokal: Es ist möglich, lokal auf dem PC des Benutzers, ein weiteres Root-Zertifikat, sprich eine Authority, zu installieren. Damit ist der PC kompromittiert. Ein Beispiel für Windows:

BYTE *pbMyEncodedRootCert = ...;
DWORD dwLengthOfMyEncodedRootCert = ...;

HCERTSTORE  hRootStore = CertOpenSystemStore(
   0,
   "Root");
PCCERT_CONTEXT  pCertContext = CertCreateCertificateContext(
   (PKCS_7_ASN_ENCODING | X509_ASN_ENCODING),
   pbMyEncodedRootCert,
   dwLengthOfMyEncodedRootCert);
CertAddCertificateContextToStore(
   hRootStore,
   pCertContext,
   CERT_STORE_ADD_NEW,
   NULL);
CertCloseStore(hRootStore, 0);

Fazit

CA sind “Broken by Design”. Das Vertrauen in Zertifikate wird auf die Builtin Object Tokens des verwendeten Browsers zurückgeführt. An dieser Stelle sei erwähnt, dass demnächst in diesem Blog ein weiterer Artikel zum Thema DNSSEC publiziert wird. Eine Technologie, die äusserst vielseitig einsetzbar ist und beispielsweise das CA-Problem mit DANE entschärfen kann.

Update 11.7.2014

Am Dienstag hat Google’s Adam Langley über gefälschte Google-Zertifikate geblogged[8]: Ist eine CA kompromittiert, zerfällt die Vertrauenwürdigkeit des gesamten Systems. Gestern wurde bekannt, dass die Kompromittierung tiefer greift: Neben Google, ist bestätigterweise auch Yahoo betroffen[9].