Authentication Bypass in Apache’s OFBiz by including a the GET param requirePasswordChange=Y using this will simply bypass the need to authenticate due to some mishandling of errors.

The problem starts with the login function. The code is documented as returning a boolean representing whether or not the caller should generate its own content. In reality the normal code flow returns a somewhat boolean string, either “error” or “success” (during the episode I think I mentioned thinking it was a default or empty string, I dug into the code and found the “success” return a few more functions deep). This is a bit odd and is a bit of a codesmell on its own, but the function can also return a third value, so not even truly boolean as it can return “requirePasswordChange”.

The problem comes with the fact that the checkLogin function which calls login only falls into the error path when the return value is “error” and the “requirePasswordChange” return slips through. And continues to slip through the code, taking a couple different paths depending on whether the username and passwords are blank, but ultimately that unexpected return value means the login proceeds.

This bug was was in a sense found previously, though the focus of the prior disclosure was more about the remote code execution due to the insecure serialization that could be exploited through it. The patch was to just remove access to the vulnerability XML-RPC route rather than dealing with the authentication bypass.

Dynamic typing strikes again! Once again some fun stuff can happen when passing in an array where a string is expected.

In this case if instead of passing in a single email string when trying to reset a password, you can pass in an array of emails. The lookup process to find the appropriate user to reset seems to only take a single email, but the lower-level lookup function used supports an array of emails. So by providing an array of emails it will return the user of the first match. There is a tweet POC of the payload.

Then once its found the user it will pass in the provided email as the email to send the password reset information to, once again accepting an array in the to argument leading to the password reset token being sent to all of the emails even if its not associated with the user.

The patch on this one was fairly simple, they removed the option to specify the email to which the reset information will be sent, opting to derive that form the user record itself

A somewhat odd vulnerability in Adobe Coldfusion, where it would take an attacker controllable classname parameter and use it to compile Coldfusion code on the fly to render in the response. If the classname didn’t match a valid Coldfusion Class, it would treat the it as a path to a Coldfusion template. So by setting classname=../../../etc/passwd for example, they could get /etc/passwd’s contents echo’d in the response. This also didn’t require any pre-authentication to exploit.

A clever way they were able to take this to Remote Code Execution (RCE) was by sending a request to the CFIDE/AIR/Conflict endpoint’s test method, which would log the _variables parameter passed. By setting _variables to a Coldfusion execute tag (ie. _variables=<cfexecute name=’/usr/bin/gnome-calculator’></cfexecute>) and sending a second request that set the classname to that log file path, they could get the cfexecute tag processed to get RCE.