Abo
  • Services:
Anzeige
Auch die BERserk-Lücke hat von Intel ein Logo erhalten.
Auch die BERserk-Lücke hat von Intel ein Logo erhalten. (Bild: Intel)

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.

Anzeige

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

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.

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.


eye home zur Startseite
LateNight 02. Okt 2014

Wer sich anschauen will, wie der Bleichenbacher-Angriff funktioniert, kann dies selbst...

slashwalker 02. Okt 2014

Ich empfehle immer gern ssllabs.com, sehr ausführlicher Test



Anzeige

Stellenmarkt
  1. Control Mechatronics GmbH, Ravensburg
  2. SYNLAB Holding Deutschland GmbH, Augsburg
  3. Bernecker + Rainer Industrie-Elektronik GmbH, Essen
  4. Bosch Healthcare Solutions GmbH, Waiblingen


Anzeige
Hardware-Angebote
  1. 49,90€
  2. (reduzierte Überstände, Restposten & Co.)
  3. beim Kauf eines 6- oder 8-Core FX Prozessors

Folgen Sie uns
       

Anzeige
Whitepaper
  1. Sicherheitskonzeption für das App-getriebene Geschäft
  2. Mehr dazu im aktuellen Whitepaper von IBM
  3. Mit digitalen Workflows Geschäftsprozesse agiler machen


  1. Videocodec

    Für Netflix ist H.265 besser als VP9

  2. Weltraumforschung

    DFKI-Roboter soll auf dem Jupitermond Europa abtauchen

  3. World of Warcraft

    Sechste Erweiterung Legion ist online

  4. Ripper

    Geldautomaten-Malware gibt bis zu 40 Scheine aus

  5. Europäische Union

    Irlands Steuervorteile für Apple sollen unzulässig sein

  6. Linux-Paketmanager

    RPM-Entwicklung verläuft chaotisch

  7. Neuseeland

    Kim Dotcom überträgt Gerichtsverhandlung im Netz

  8. Leitlinien vereinbart

    Regulierer schwächen Vorgaben zu Netzneutralität ab

  9. Kartendienst

    Microsoft und Amazon könnten sich an Here beteiligen

  10. Draufsicht

    Neuer 5er BMW mit Überwachungskameras



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Radeon RX 460: AMDs kleinste Polaris-Karte braucht mehr Speicher
Radeon RX 460
AMDs kleinste Polaris-Karte braucht mehr Speicher
  1. Polaris-Grafikkarten Neuer Treiber steigert Bildrate in Tomb Raider
  2. Polaris-Grafikkarten AMD stellt Radeon RX 470 und RX 460 vor
  3. Radeon Pro SSG AMD zeigt Profi-Karte mit SSDs für ein TByte Videospeicher

Radeon RX 470 im Test: Die 1080p-Karte für High statt Ultra
Radeon RX 470 im Test
Die 1080p-Karte für High statt Ultra
  1. Radeons RX 480 Die Designs von AMDs Partnern takten höher - und konstanter
  2. Radeon Software 16.7.2 Neuer Grafiktreiber macht die RX 480 etwas schneller
  3. Radeon RX 480 erneut vermessen Treiber reduziert Stromstärke auf PEG-Slot

Garmin Vivosmart HR+ im Hands on: Das Sport-Computerchen
Garmin Vivosmart HR+ im Hands on
Das Sport-Computerchen
  1. Fenix Chronos Garmins neue Sport-Smartwatch kostet ab 1.000 Euro
  2. Polar M600 Sechs LEDs für eine Pulsmessung
  3. Garmin Edge 820 Radcomputer zeigt Position der Tourbegleiter

  1. Re: Halbe Milliarde

    ibsi | 12:36

  2. Gratualation an Blizz

    MrAnderson | 12:36

  3. Re: Habe ich da etwas missverstanden?

    stoneburner | 12:34

  4. Re: "will fair behandelt werden"

    stoneburner | 12:32

  5. Druckverhältnisse in 100 km Tiefe?

    Cassiel | 12:29


  1. 12:31

  2. 12:07

  3. 11:51

  4. 11:25

  5. 10:45

  6. 10:00

  7. 09:32

  8. 09:00


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel