Exploiting an Order of Operations Bug to Achieve RCE in Oracle Opera
Two issues came together here, the first one is the more “fun” issue in a file upload handler.
String jndiname = DES.decrypt(SanitizeParameters.sanitizeServletParamOrUrlString(request.getParameter("jndiname")));
String username = DES.decrypt(SanitizeParameters.sanitizeServletParamOrUrlString(request.getParameter("username")));
It does sanitization, and then it decrypts the data which is simply the wrong order and effectively means the sanitization is meaningless. The decrypted value is what should be sanitized. It is an interesting bug to see, if I had to guess about how it was introduced, I’d guess when they introduced theSanitizerParameters
class, they might have just done a global search and replace on the request.getParameter
replacing it with a wrapped call to sanitize it. Not really considering the context of its usage.
You end up with those parameters being unsanitized, and the username
is used in creating the file path. So if you can encrypt a valid string for it, you can get a easy directory traversal.
The second issue is one we see all too often, static keys were used for the cryptography here. So an attacker could recreate the encryption routine, reuse the static keys and generate a malicious payload.