Mantis Bug Tracker 2.25 - 2.28 [EDIT dregad: see 0036902:0070815] is affected by an authentication bypass vulnerability in the SOAP API as a result of an improper type checking on the password parameter. The flaw stems from the way the function user_get_id_by_cookie in core/user_api.php handles the p_cookie_string parameter.

The majority of SOAP operations are authenticated, and in some form call to mci_check_login in api/soap/mc_api.php to perform the authentication. This function contains a conditional statement that reaches auth_user_id_from_cookie at line 480, which serves as a wrapper for user_get_id_by_cookie. If auth_user_id_from_cookie returns a valid row, it will call to auth_attempt_script_login with the provided username and no password, as the application assumes that a valid row means that the provided cookies was valid. Once it reaches this function, it will successfully log the user in with the provided username.

user_get_id_by_cookie expects the p_cookie_string parameter to be a string. However, if a user is able to pass in an integer that is not converted to a string, the SQL SELECT statement will attempt to query the database using an integer for its check, i.e. SELECT * FROM mantis_user_table WHERE cookie_string=0. MySQL will attempt to CAST the cookie_string to an integer to perform the check without throwing an error. One of two things will happen:

1. If the cookie_string has a leading integer, then it will convert the entire string to that integer (i.e. a cookie_string that equals 1abcde[..] becomes equal to 1.
2. If the cookie_string does not have a leading integer, it will become equivalent to 0.

As such, so long as there is a cookie_string that does not have a leading integer, which is highly likely, passing in 0 as the p_cookie_string parameter will successfully return several rows and pass this check. If there is no cookie_string that does not start with a leading integer, it would be possible to iterate from 1-9 to eventually retrieve a row and pass this check.

SOAP envelopes can have defined namespaces that preserve the type the user defines on the parameter, i.e. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema". As a result, an attacker can explicitly type the password as an integer, pass in 0 (or iterate through other integers if necessary), define the username as administrator, pass the check in user_get_id_by_cookie, and successfully log in as the administrator.

The impact for this is quite high. The SOAP API does not perform any user operations, nor have I identified any additional vulnerabilities that may allow for a server side compromise. However, as the default username is administrator, it's possible for an unauthenticated user to act as an administrator on all tickets and projects, including private tickets.