Several fun issues found in DataHub by GitHub Security Lab, we won’t summarize all of them here but a few of our favorites:

Missing JWT signature check - Basically the backend was not verifying the signature of JWTs. This was likely because of a confusion around using the JWT libary as the parseClaimsJws and parsePlaintextJws methods both validate the signature, but the parse method they used does not.

System account impersonation - All comes down to a case-sensitive string comparison. The application used a X-DataHub-Actorheader when proxying requests to indicate who the request was made on behalf of. Naturally you don’t want attackers to be able to provide that header themselves so they have code in-place to remove it if found. The problem being that the code removing the header was case-sensitive, but the backend service looked for the header in a case-insensitive way.

JSON Injection - The AuthServiceClient which, as the name implies, handles authentication would build up JSON strings using format strings without checking for any context breaking characters. So if one provided a string that would be reflected in the output JSON containing a " character, they could break out of the string and start adding new key/value pairs to the JSON. They abused this to create an account with the email __datahub_system which is a special value used to indicate a system account is making the request.

Login fail open on JAAS misconfiguration - The authenticateJaasUser method wraps the login service access in a try/catch block. Normally when a login fails, it’ll raise a LoginException which is explicitly caught, but any other exception is simply ignored, with a comment saying this should never happen. Of course, it can happen if the JAAS configuration has an error, in which case it’ll fail-open. The liklihood of an invalid JAAS configuration is relative low, but still failing open is a poor choice.