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

Kommentieren



Anzeige

Stellenmarkt
  1. Landesbetrieb IT.Niedersachsen, Hannover
  2. HERMANN BIEDERLACK GmbH + Co. KG, Greven
  3. Robert Bosch GmbH, Leonberg
  4. HELUKABEL GmbH, Hemmingen


Anzeige
Hardware-Angebote
  1. 119,00€
  2. 444,90€

Folgen Sie uns
       


  1. Bruno Kahl

    Neuer BND-Chef soll den Dienst reformieren

  2. Onlinehandel

    Amazon sperrt Konten angeblich nur in seltenen Fällen

  3. The Assembly angespielt

    Verschwörung im Labor

  4. Kreditkarten

    Number26 wird Betrug mit Standortdaten verhindern

  5. Dobrindt

    1,3 Milliarden Euro mehr für Breitbandausbau in Deutschland

  6. Mini ITX OC

    Gigabyte bringt eine 17 cm kurze Geforce GTX 1070

  7. Autonomes Fahren

    Teslas Autopilot war an tödlichem Unfall beteiligt

  8. Tolino Page

    Günstiger Kindle-Konkurrent hat eine bessere Ausstattung

  9. Nexus

    Erste Nougat-Smartphones sollen von HTC kommen

  10. Hafen

    Die Schauerleute von heute sind riesig und automatisch



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Oneplus Three im Test: Ein Alptraum für die Android-Konkurrenz
Oneplus Three im Test
Ein Alptraum für die Android-Konkurrenz
  1. Android-Smartphone Diskussionen um Speichermanagement beim Oneplus Three
  2. Smartphones Oneplus soll keine günstigeren Modellreihen mehr planen
  3. Ohne Einladung Oneplus Three kommt mit 6 GByte RAM für 400 Euro

Mobbing auf Wikipedia: Content-Vandalismus, Drohungen und Beschimpfung
Mobbing auf Wikipedia
Content-Vandalismus, Drohungen und Beschimpfung
  1. Freies Wissen Katherine Maher wird dauerhafte Wikimedia-Chefin

Neue Windows Server: Nano bedeutet viel mehr als nur klein
Neue Windows Server
Nano bedeutet viel mehr als nur klein
  1. Windows 10 Microsoft will Trickserei beim Upgrade beenden
  2. Windows 10 Microsoft zahlt Entschädigung für nicht gewolltes Upgrade
  3. Microsoft Patchday Das Download-Center wird nicht mehr alle Patches bieten

  1. Re: Wo ist eigentlich das Problem?

    Unix_Linux | 18:59

  2. Ronald Pofalla?

    crummp | 18:59

  3. Re: Glasfaser in unterversorgten Gebieten

    brainDotExe | 18:57

  4. Re: Ich bestelle nicht mehr bei Amazon...

    br92 | 18:55

  5. Re: Wäre nett gewesen, aber

    RaZZE | 18:54


  1. 17:04

  2. 16:53

  3. 16:22

  4. 14:58

  5. 14:33

  6. 14:22

  7. 13:56

  8. 13:29


  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