Mehrere kritische Sicherheitslücken in JWT-Bibliotheken gefunden

Eine Reihe kritischer Sicherheitslücken wurde in Bibliotheken von JSON Web Token gefunden, und zwar in den Versionen für JavaScript und PHP, die es einem Cyberkriminellen ermöglichen könnten, den Verifizierungsschritt zu umgehen.

Tim McLean, ein auf Kryptografie spezialisierter kanadischer Sicherheitsforscher, der dieses Problem aufgedeckt hat, wies darauf hin, dass die Cyberkriminellen eine dieser Schwachstellen ausnutzen könnten, um den Algorithmus der asymmetrischen Verschlüsselung in einigen JWT-Bibliotheken zu hacken.

Das vor einigen Jahren eingeführte JWT ist ein Standard, der Authentifizierungs-Tokens zwischen zwei Parteien generiert. Ein Server kann beispielsweise einen Admin-Token produzieren, die als JSON übermittelt werden und mit dem Schlüssel des Servers signiert sind. Clients können diesen Token als Bestätigung dafür nutzen, dass der jeweilige Nutzer als Administrator angemeldet ist.

Das Problem besteht in einer Verwirrung um einen offenen Schlüssel zwischen Systemen, von denen das eine mit der Hash-Funktion HMAC, das andere mit RSA signiert ist.

„Wenn der Server einen Token erwartet, der mit RSA signiert ist, aber tatsächlich einen mit HMAC signierten Token erhält, hält er den öffentlichen Schlüssel für einen HMAC-Schlüssel”, erklärt Mc Lean in einem Blog. „Und was ist nun so schlimm daran? Geheime HMAC-Schlüssel sollten geheim bleiben und öffentliche sollten öffentlich sein.“

In diesem Szenario kann ein Cyberkrimineller, wenn er Zugriff auf einen öffentlichen Schlüssel über eine API in einigen JWT-Bibliotheken erhält, diesen als Token benutzen und der Server nimmt ihn an.

Via E-Mail erklärte McLean, dass er diese Sicherheitslücke im Januar entdeckt habe, als er JWT in einem Projekt nutzen wollte. Nach einer Untersuchung der Bibliotheken – die einige Zeit in Anspruch nahm, da er sich in seiner Freizeit damit beschäftigte – erkannte er, dass die Kryptografie nicht korrekt umgestzt worden war.

Um dieses Problem zu beseitigen, rät er allen, die JWT benutzen, eine Überprüfung der Tokens auf unterschiedliche Signaturen einzustellen und diese Tokens dann via Whitelisting oder Blacklisting abzulehnen.

„Der Server sollte rechtzeitigt wissen, welchen Algorithmus er für die Signatur der Tokens benutzt, es ist gefährlich Cyberkriminellen zu erlauben, das zu bestimmen.“

Ein anderes Problem, das mittlerweile in vielen JWT-Bibliotheken beseitigt wurde, gab Verbrechern die Möglichkeit, die Methode zur Überprüfung des Tokens auszuwählen, was laut McLean „katastrophale Folgen in einigen Umsetzungen hatte“.

Erstmals berichtete McLean über diese Problem im Februar und setzte seine Untersuchungen des Bugs in der vergangenen Woche fort. Auth0, Entwickler eines der populärsten Autorisierungsstandards, hielt McLeans Untersuchungen für so wichtig, dass er dessen Arbeit in seinem eigenen Blog veröffentlichte.

Das Problem dreht sich um die Methode, mit der die Bibliotheken einen Algorithmus verarbeiten, der als „none“ bekannt ist. Mit „none“ signierte Tokens könnten laut McLean als gültige Tokens mit gültigen Signaturen angesehen werden. Cyberkriminelle können die Token modifizieren und sie mit „none“ anstatt mit HMAC-SHA256 oder HS256 signieren. Dabei wird der Token als „signiert“ angesehen werden. Daraufhin könnten Hacker ihre eigene Payload hinzufügen, um Zugriff auf einen willkürlichen Account in verschiedenen Systemen zu erhalten.

Laut McLean haben die meisten Bibliotheken das Problem mit „none“ beseitigt, indem garantiert wird, dass die den „none“-Algorithmus verwendenden Token die Verifizierung nicht erfolgreich durchlaufen. Doch über dieses Problem ist er auf ein anderes gestoßen, und zwar auf das mit den asymmetrischen Schlüsseln.

„Ursprünglich war ich mit der Lösung des „none“-Problems zufrieden, doch viele Entwickler haben den Algorithmus „none“ einfach deaktiviert, anstatt die Ursache zu beseitigen (den von Angreifern kontrollierten Algorithmus), und so schaute ich mir erneut an, wie ich das ausnutzen könnte“, sagte McLean.

McLean versuchte das Problem der asymmetrischen Schlüssel mit Hilfe von Auth0 zu lösen, wo man ihm half, sich mit den Autoren einiger verwundbarer Bibliotheken in Verbindung zu setzen, um sich davon zu überzeugen, dass Tokens mit unterschiedlichen Signaturtypen grundsätzlich abgelehnt werden. Da JWT in vielen Sprachen arbeiten kann – .NET, Node.js, Python, PHP, Java, Ruby usw. – gibt es auch eine Vielzahl von Bibliotheken, die die Sicherheitslücke enthalten.

Auth0 hat das Problem in seiner Bibliothek Node.js am vorvergangenen Donnerstag beseitigt und bittet seine Nutzer, auf die neuste Version 4.2.2 upzudaten.

Jose Padilla, der das Python-Build der Bibliothek unterhält, schloss die Sicherheitslücke in der Version 1.0.0 im vergangenen Monat, in dem er die Unterstützung von Algorithmus-Whitelists hinzufügte. Die neuste Version 1.0.1 enthält ebenfalls diese Korrektur.

Gemäß jwt.io, einem Service von Auth0, sind die Versionen der Bibliothek für PHP und JavaScript nach wie vor angreifbar. Auth0 fordert diejenigen, die noch mit diesen JWT-Versionen arbeiten, auf, nach anderen, nicht angreifbaren Bibliotheken Ausschau zu halten, bis das Problem gelöst wird.

McLean, der am 9.März eine Mail zu dem Problem an 20 Autoren von Bibliotheken gesendet hat, hat noch nicht von allen eine Antwort erhalten, weist aber darauf hin, dass Auth0 nicht erwähnt, dass die Bibliothek für Ruby ebenfalls nach wie vor verwundbar ist.

„Es gibt so viele JWT-Bibliotheken, dass meine Zeit einfach nicht ausreicht, um sie alle zu untersuchen“, sagte McLean.

McLean hofft, dass seine Mitteilung im Blog künftigen JWT-Entwicklern dabei helfen wird, einige der Vorsichtsmaßnahmen zu verinnerlichen, die vor der Bereitstellung berücksichtigt werden müssen, doch er meint, dass eine Änderung der Spezifikation, die das Feld alg des Headers ablehnen würde, zum Vorteil der Community wäre. McLean hat seinen Blogeintrag an die Arbeitsgruppe Javascript Object Signing and Encryption (JOSE) geschickt und hofft, dass er dort Beachtung findet.

Quelle:        Threatpost

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.