Firefox/Chrome: BERserk hätte verhindert werden können

Die Sicherheitslücke BERserk ist nur deshalb ein Problem, weil einige Zertifizierungsstellen sich nicht an gängige Empfehlungen für RSA-Schlüssel halten. Mit BERserk akzeptieren Firefox und Chrome gefälschte Zertifikate.

Artikel veröffentlicht am , Hanno Böck
Auch die BERserk-Lücke hat von Intel ein Logo erhalten.
Auch die BERserk-Lücke hat von Intel ein Logo erhalten. (Bild: Intel)

Neben Shellshock ist in der vergangenen Woche eine weitere gravierende Sicherheitslücke publiziert worden. Eine Fehlfunktion in der Verschlüsselungsbibliothek NSS, die den Namen BERserk erhalten hat, erlaubt das Ausstellen gefälschter Zertifikate. Die Lücke ist eine Variante eines bereits 2006 vom Kryptographen Daniel Bleichenbacher vorgestellten Angriffs auf fehlerhafte Implementierungen des RSA-Signaturverfahrens. Ein Blick auf die Hintergründe zeigt: Diese Lücke wäre kaum der Rede wert gewesen, wenn man aus der Bleichenbacher-Attacke die richtigen Schlüsse gezogen hätte. Das hängt mit dem sogenannten Exponenten in RSA zusammen.

Problem seit 2006 bekannt

Stellenmarkt
  1. Senior Software Architect (m/w/d)
    DRÄXLMAIER Group, Vilsbiburg bei Landshut
  2. IT Service Management Expert (m/w/d)
    Soluvia IT-Services GmbH, Mannheim, Kiel, Offenbach
Detailsuche

Der Angriff hängt mit der relativ simplen Struktur des RSA-Standards PKCS #1 1.5 zusammen. Hierbei wird eine Nachricht gehasht, anschließend wird eine Kombination aus einem Padding, dem Hash und einer Codierung des verwendeten Hash-Algorithmus mit der RSA-Funktion signiert. Das Problem, das Bleichenbacher fand: Befinden sich hinter dieser Abfolge aus Padding, Hash und Algorithmus-Identifikation noch weitere Daten, so ignorieren viele Verschlüsselungsbibliotheken dies. Mit einigen mathematischen Tricks gelang es damit, ohne den privaten RSA-Schlüssel Signaturen zu erzeugen, die von gängigen RSA-Implementierungen akzeptiert werden.

Der damals von Bleichenbacher beschriebene Angriff betraf unter anderem OpenSSL und NSS. Der Angriff hatte allerdings eine Besonderheit: Er funktionierte nur, wenn man für den sogenannten Exponenten den sehr kleinen Wert drei wählte.

Kleine Exponenten riskant

Ein öffentlicher RSA-Schlüssel besteht aus zwei Zahlen: einer sehr großen Zahl, die das Produkt zweier Primzahlen ist, und dem öffentlichen Exponenten. Für diesen Exponenten können sehr kleine Zahlen gewählt werden, drei ist der kleinstmögliche Wert (e=3). Aus Performancegründen haben sich früher viele Verschlüsselungsprogramme für einen solch kleinen Exponenten entschieden. Ein Exponent drei ist zwar theoretisch immer noch sicher, allerdings nur dann, wenn bei der Implementierung von RSA keine Fehler gemacht werden. Inzwischen verwenden die meisten RSA-Implementierungen als Standardwert 65537. Das ist ein Kompromiss zwischen Geschwindigkeit und Sicherheit. Da sich 65537 als Binärzahl sehr einfach darstellen lässt, sind Berechnungen immer noch sehr schnell, sämtliche Angriffe mit sehr kleinen Exponenten werden dadurch jedoch ausgeschlossen.

Golem Karrierewelt
  1. AZ-500 Microsoft Azure Security Technologies (AZ-500T00): virtueller Vier-Tage-Workshop
    28.11.-01.12.2022, virtuell
  2. Informationssicherheit in der Automobilindustrie nach VDA-ISA und TISAX® mit Zertifikat: Zwei-Tage-Workshop
    22./23.11.2022, Virtuell
Weitere IT-Trainings

Bleichenbacher empfahl bereits 2006, auf RSA-Schlüssel mit einem Exponenten von drei zu verzichten. Diese Empfehlung wurde später von verschiedenen Institutionen übernommen. Eine Empfehlung der US-Behörde Nist (National Institute of Standards and Security) aus dem Jahr 2010 verbietet generell Exponenten, die kleiner als 65537 sind. Standards des FIPS und des CA/Browser-Forums sagen zumindest, dass man Exponenten kleiner 65537 vermeiden soll.

2014: Die Lücke kehrt zurück

Vor wenigen Tagen wurde nun bekannt, dass eine Variante der Bleichenbacher-Lücke in mehreren Verschlüsselungsbibliotheken gefunden wurde. Die meisten Auswirkungen hat die Lücke in der Bibliothek NSS, denn diese wird von Firefox und Chrome verwendet. Entdeckt wurde dies fast gleichzeitig von Antoine Delignat-Lavaud vom miTLS-Projekt und vom Advanced Threat Research Team bei Intel. Getauft wurde diese neue Lücke BERserk.

Der Name leitet sich von der sogenannten BER-Codierung ab, die Teil des ASN.1-Standards ist. Das neu aufgetauchte Problem hängt mit der Verarbeitung der Algorithmus-Identifikation zusammen. Hierbei wird für den verwendeten Hash-Algorithmus - beispielsweise SHA-1 oder SHA-256 - ein sogenannter Object Identifier mit dem BER-Verfahren als Teil der Signatur codiert. Das Problem: Verschiedene Verschlüsselungsbibliotheken sind zu ungenau bei der Decodierung des BER-Verfahrens, somit kann ein Angreifer erneut zusätzliche Daten in der Signatur unterbringen und damit den alten Angriff von 2006 wiederholen. Die Details des BER-Codierungsproblems hat Google-Entwickler Adam Langley in seinem Blog beschrieben.

Langleys Ausführungen machen noch ein weiteres Problem des PKCS #1 1.5-Standards deutlich: In einer kryptographischen Basisfunktion wie den RSA-Signaturen ein komplexes Codierungsverfahren wie BER einzusetzen, ist höchst problematisch. BER ist Teil des ASN.1-Standards, ein Verfahren der ITU aus den 80er-Jahren. Dass beim Parsen von BER Fehler auftreten, ist eigentlich keine große Überraschung.

Langley schlägt hierfür eine Abhilfe vor: Statt den entsprechenden Teil zu decodieren, sollten die TLS-Bibliotheken die möglichen Werte für diesen Wert selbst codieren und mit dem Wert in der RSA-Signatur vergleichen. Sämtliche fehlerhafte Codierungen hätten somit keine Auswirkungen und würden den Decoder überhaupt nicht erreichen. Langley hat dies in BoringSSL, dem Google-Fork von OpenSSL, bereits so umgesetzt.

BERserk in NSS, CyaSSL und im Entwicklungszweig von OpenSSL

Neben NSS steckte die neue BERserk-Lücke im Code von CyaSSL und nach Aussage von OpenSSL-Entwickler Rich Salz auch im Entwicklungszweig von OpenSSL. Der entsprechende OpenSSL-Code war jedoch nie Teil eines Releases, von diesem Code dürfte also keine Gefahr ausgehen.

Ähnlich wie für die alte Bleichenbacher-Lücke gilt jedoch auch für BERserk: Ausnutzen lässt sich der Fehler nur, wenn ein RSA-Schlüssel mit einem Exponenten von drei eingesetzt wurde. Das Problem: In den aktuellen Versionen von Mozilla und Chrome werden sechs Zertifikate von Zertifizierungsstellen mitgeliefert, die nach wie vor einen solch riskanten RSA-Schlüssel benutzen.

Es handelt sich um ein Zertifikat von GoDaddy, zwei Zertifikate der Zertifizierungsstelle der spanischen Handelskammer (Camerfirma), zwei Zertifikate der Firma Digital Signature Trust und ein Zertifikat der Firma Starfield Technologies. Da ein Browser grundsätzlich allen Zertifizierungsstellen gleichermaßen vertraut, führt BERserk dazu, dass man gefälschte Zertifikate dieser Zertifizierungsstellen erstellen kann, die von verwundbaren Firefox- und Chrome-Versionen akzeptiert werden. Damit lassen sich dann etwa HTTPS-Verbindungen mittels Man-in-the-Middle-Angriffen manipulieren.

Zu diesen sechs Root-Zertifizierungsstellen kommen weitere Unter-Zertifizierungsstellen, die ebenfalls problematische RSA-Schlüssel einsetzen. Etwas weniger kritisch sind solche RSA-Schlüssel bei End-Zertifikaten für einzelne Webseiten. Damit könnte im Zweifel nur die spezielle Webseite selbst angegriffen werden. Wer selbst eine HTTPS-Seite betreibt, sollte trotzdem sichergehen, dass der zugehörige RSA-Schlüssel einen größeren Exponenten nutzt.

Der Bleichenbacher-Angriff und BERserk könnten auch andere kryptographische Tools mit RSA-Schlüsseln betreffen, da das RSA-Verfahren nach PKCS #1 1.5 weit verbreitet ist, darunter etwa PGP. Allerdings wurden bislang keine entsprechenden Lücken gefunden.

BERserk wäre keine Sicherheitslücke gewesen

Alle sechs betroffenen Root-Zertifikate wurden lange vor der ursprünglichen Bleichenbacher-Lücke erstellt, die Probleme mit kleinen Exponenten waren damals nicht bekannt und eine Wahl von drei war völlig normal. Hätte man die Warnungen, die es lange Zeit gab, berücksichtigt und die entsprechenden Zertifikate entfernt, wäre die BERserk-Lücke viel weniger dramatisch. Es würde sich dann immer noch um einen Fehler handeln, den man beheben sollte, aber BERserk wäre kein Sicherheitsproblem.

Da die Bleichenbacher-Lücke bereits in den unterschiedlichsten Software-Bibliotheken in verschiedenen Varianten gefunden wurde, erscheint es durchaus realistisch, dass weitere Verschlüsselungsprodukte davon betroffen sind. Es wäre also nach wie vor sinnvoll, derartige RSA-Schlüssel mit einem Exponenten von drei zu meiden. Die Schwierigkeit dürfte darin liegen, dass dies im Fall von Browsern nur hilft, wenn alle riskanten Root-Zertifikate entfernt werden und ausgeschlossen werden kann, dass Unter-Zertifizierungsstellen entsprechende Schlüssel einsetzen. Denn eine einzige Zertifizierungsstelle reicht im Zweifel für einen Angriff auf beliebige Webseiten.

Verbesserter RSA-Standard wird nicht genutzt

Eine weitere Möglichkeit, derartige Angriffe generell zu meiden, wäre der Einsatz eines neueren RSA-Standards. PKCS #1 2.1 enthält bessere Padding-Verfahren für RSA mit den Namen PSS (für Signaturen) und OAEP (für Verschlüsselung). Doch obwohl dieser Standard bereits 2002 veröffentlicht wurde, setzen nach wie vor fast alle kryptographischen Protokolle auf das weniger sichere PKCS #1 1.5. Selbst der Entwurf für den kommenden TLS 1.3-Standard nutzt noch das veraltete Verfahren.

Mit PKCS #1 2.1 würde man auch die problematische BER-Codierung in der RSA-Signatur meiden. Derart komplexe Codierungen in einer kryptographischen Basisfunktion zu verwenden, ist generell keine gute Idee.

Der Autor dieses Texts hat ein Onlinetool bereitgestellt, mit dem sich die RSA-Exponenten von HTTPS-Webseiten prüfen lassen.

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed


Aktuell auf der Startseite von Golem.de
Smartwatch
Öffnen der Apple Watch Ultra trotz Schrauben riskant

Die Apple Watch Ultra verfügt über vier Schrauben auf der Unterseite. Nutzer sollten sie nicht lösen, um die Uhr nicht zu zerstören.

Smartwatch: Öffnen der Apple Watch Ultra trotz Schrauben riskant
Artikel
  1. Gegen Amazon und Co.: Frankreich führt Mindestgebühren für Buchbestellungen ein
    Gegen Amazon und Co.
    Frankreich führt Mindestgebühren für Buchbestellungen ein

    Mit einer Mindestliefergebühr will Frankreich kleinere Geschäfte vor großen Onlinehändlern wie Amazon schützen.

  2. Gen.Travel: Volkswagen zeigt autonomes Elektroauto mit Betten
    Gen.Travel
    Volkswagen zeigt autonomes Elektroauto mit Betten

    VW hat eine Autostudie vorgestellt, in der niemand mehr fahren muss. Stattdessen kann gearbeitet, geschlafen oder gefreizeitet werden.

  3. E-Commerce und Open Banking: Big-Tech-Konzerne drängen in den Finanzsektor
    E-Commerce und Open Banking
    Big-Tech-Konzerne drängen in den Finanzsektor

    Open Banking sollte Innovationen fördern. Stattdessen nutzen Amazon, Apple und Google es dazu, ihre Marktmacht auszubauen.
    Eine Analyse von Erik Bärwaldt

Du willst dich mit Golem.de beruflich verändern oder weiterbilden?
Zum Stellenmarkt
Zur Akademie
Zum Coaching
  • Schnäppchen, Rabatte und Top-Angebote
    Die besten Deals des Tages
    Daily Deals • CyberWeek: Gaming-Hardware uvm. • Crucial P2 1 TB 67,90€ • ViewSonic VX2719-PC FHD/240 Hz 179,90€ • MindStar (u. a. MSI MAG Z690 Tomahawk 219€ + $20 Steam) • Apple AirPods 2. Gen 105€ • Alternate (u. a. Chieftec GDP-750C-RGB 71,89€) • Logitech G Pro Gaming Keyboard 77,90€ [Werbung]
    •  /