Using Ninja to Monitor And Kill Rogue Privilege Escalation

Tuesday, February 22, 2011

Rod MacPherson

314f19f082e69886c20e31c70fe6dceb

In the world of hacking, getting in is just the start.

Once a hacker (if they have malicious intent we'll call them crackers) has found a way onto a system s/he then usually needs to jump to the Administrator or system or root account to be most effective.

Ninja is a program for Linux (and presumably most Unix like OSes) that monitors for such privilege escalation. Privilege escalations might not be crackers though. The common administration programs like passwd, sudo, etc. also set UID to root, so Ninja has white-listing for who is allowed to run what processes as root.

The white-list function of ninja makes it useful for enforcing policy. You can have a group of users who are allowed to run file editors as root to make changes to system configs and another group who are allowed to restart services, thus providing separation of duties.

When you first install Ninja it is set to logging only. This allows you to run it in log mode for a while until you are sure your white-list covers all of the normal use cases for your system before you put it into the proactive process killing modes.

There are 2 modes for process killing, one that kills the process running as root, and one that also kills the process that spawned it.

When first installed (on a debian based system like Ubuntu) it will tell you where it's configs and logs are:

Setting up ninja (0.1.3-2) ...

log: reading configuration file: /etc/ninja/ninja.conf

log: ninja version 0.1.3 initializing

log: magic group: gid=0 (root) log: logfile: /var/log/ninja.log

log: whitelist mapped in memory at 0x7f851ba0b000

log: entering daemon mode

After install, if I run a program in sudo, it will be logged as below:

rod@rod-ubuntu:~$ sudo nano /etc/ninja/ninja.conf

rod@rod-ubuntu:~$ more /var/log/ninja.log

[Tue Feb 22 06:12:23 2011] ninja version 0.1.3 initializing

[Tue Feb 22 06:12:23 2011] magic group: gid=0 (root)

[Tue Feb 22 06:12:23 2011] logfile: /var/log/ninja.log

[Tue Feb 22 06:12:23 2011] whitelist mapped in memory at 0x7f851ba0b000

[Tue Feb 22 06:12:23 2011] entering daemon mode

[Tue Feb 22 06:12:23 2011] entering main loop

[Tue Feb 22 06:12:23 2011] generating initial pid array..

[Tue Feb 22 06:12:23 2011] now monitoring process activity

[Tue Feb 22 06:25:55 2011] NEW ROOT PROCESS: nano[3686] ppid=2740 uid=0 gid=0

[Tue Feb 22 06:25:55 2011] - ppid uid=1000(rod) gid=1000 ppid=2722

[Tue Feb 22 06:25:55 2011] + UNAUTHORIZED PROCESS DETECTED: nano[3686] (parent: bash[2740])

[Tue Feb 22 06:25:55 2011] - nokill option set, no signals sent

rod@rod-ubuntu:~$

This logging alone, makes ninja worth the install because it gives you a way to track who did what as root, no matter how they got to be root. (sudo, SUID, or a privilege escalation hack) Turn on the defensive modes, and your system learns a little bit of self defense.

Now if only I could find a version of this for Windows machines. Anyone know of something similar (free or for a fee) for Windows?

Cross-posted from Rod's Tech

Possibly Related Articles:
15882
Operating Systems
Operating Systems Linux Monitoring hackers Ninja Privilege Escalation
Post Rating I Like this!
44a2e0804995faf8d2e3b084a1e2db1d
Don Eijndhoven Thats pretty nifty Rod, thanks! I'll give it a try!
1298467570
B64e021126c832bb29ec9fa988155eaf
Dan Dieterle Thanks Rod, I will definitely check this out.

Just curious, I know there are several programs hackers can use to erase or modify the Windows logs.

Is Ninja susceptible to that too? Is it a common enough program in the Linux world that they would even check for it?
1298478815
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson Yes, like anything that writes logs, the logs can be erased, but that is why you should also have in your network, a central logging server. If you export your logs from all of your servers to a Log server or SIM/SIEM via something like syslog you have a copy of everything in another system that they would also need to compromise.

Ninja also has the option to run an external program each time it logs an unapproved root process.

My home machine, for instance, e-mails the last 10 lines of the ninja log (about 2 events) to me and touches a file that my .bashrc looks for so that even if e-mail is down it is very obvious to me when I open a command shell on that computer that something unexpected has happened.
1298487448
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson One little thing to keep in mind when creating ninja whitelists that wasn't apparent at first... Ninja only looks at the real file location, so if you have a whitelist rule that doesn't seem to work check that you are listing the executable by real location not by a symlink.

I had this problem with /usr/bin/nano in Ubuntu 10.10, which is a symlink to /bin/nano.

I e-mailed some details to the developer Tom, and he wrote this back:
--------------------------------------

After a bit of digging around on my ubuntu vmware image, I've
found the root of your problem;

tom@ubuntu:~$ ls -al /usr/bin/nano
lrwxrwxrwx 1 root root 9 2010-10-10 17:40 /usr/bin/nano -> /bin/nano

The real path of nano(1) is /bin/nano, /usr/bin/nano is a symlink.

Since '/usr/bin/' is listed before '/bin/' in your $PATH variable,
commands such as 'which nano' will always turn up /usr/bin/nano, but
you will infact be executing /bin/nano.

ninja only looks at the real path of the process -- it has no idea
that you executed it via a symlink.

The fix is to whitelist '/bin/nano' instead of the symlink.

Hope this helps! :)


- Tom

--------------------------------------
He also mentioned that the next release will warn you of symlinks in your whitelist. That's one thing I've always liked about open source projects. If I get stuck the developers are usually able to jump in and find the solution within a few days. With bigger projects other users are usually willing to help out even quicker. ...so long as you put forth a little effort on your own.
1298938749
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.