Security tools have one of two primary goals: block unwanted activity from happening in the first place, or report that it happened after the fact. While we’d always rather block the attack from happening, we do need to have competent tools that can detect the signs of a compromise as well.
We’ve just finished working on some additional monitoring tools that can catch some forms of compromise by detecting changes to critical files on the system. We wanted to elaborate on how they work and why you might want to use them
Set-You-Eye-Dee? What’s that?
Let’s assume for a moment that an attacker breaks into a Linux/Unix-class system and has the ability to run remote commands, but does not have the root privileges (think Windows’ “Administrator” account) needed to have complete control over the entire system. How do they get it?
Those systems are very likely to have programs that can briefly become root to do their job, even if they’re run by non-root users. For example, /bin/passwd (which changes your local login password) needs root privileges to update the password store, something which I can’t do from my normal wstearns account. To make it possible for me to change my own password (as opposed to hunting down an administrator to do every password change), we add a flag called “setuid” to the /bin/passwd program:
The highlighted “s” is a note to the operating system that tells it: “Whenever this program is run, temporarily run it not as the user that started it up, but as the owner of the file (in this and most cases, the root user)”. That gives the program the root privileges it needs to change my password, and when it exits, I’m back to running programs under my own “wstearns” account again. From a Windows perspective, this is much like right clicking on a program and choosing “Run as Administrator”, but doesn’t require me to know the Administrator password.
For more details on setuid, see this Wikipedia entry.
OK, back to our attacker now. Ideally she’d like to use our /bin/passwd program not to just change a local user password, but to get full root privilege. She could do a couple of things to reach that goal: 1) change the root password somehow and later log in as root, 2) exploit a programming weakness in the password executable that allows her to perform a different task as root, or 3) replace the /bin/passwd executable code with her own custom code while still preserving the setuid flag. That custom code could do any number of tasks that would give her full root privilege.
The important point is this; programs with the setuid flag turned on are ones that may be used to give an attacker higher privileges, and so are considered more critical than normal programs. If the attacker did modify a setuid program with her own custom code, we’d like to know this, and that’s where File Integrity Monitoring (FIM) steps in.
We’ve written a File Integrity Monitoring policy (named “Monitor Changes to Files with SETUID (Linux) v1”, available in the FIM Policy Templates) that includes all the standard setuid programs; you can add any custom compiled setuid programs to the policy. When you import that policy and create a FIM baseline from a clean system, you can now watch your production machines for changes to any of those files. If any changes show up, you can investigate and see if there has been a compromise.
Will this catch every break in? No. But it does keep an eye on some critical files that may be modified in the course of a break in.
To use this policy, go to Policies->File Integrity Policies in the portal. Press “Import File Integrity Policy” and pick “Monitor Changes to Files with SETUID (Linux) v1”. At the bottom of the policy page press “Add baseline” and pick a gold master system that you’re confident has never had a break in. Assign the policy to one or more groups whose systems have the same base operating system as your baseline, and you’re done. Your next FIM report will alert on any modified setuid binaries (you can either wait for the next scheduled scan or start one manually).
I’ve glossed over a lot of the steps needed to perform a successful attack, but want to keep this to blog length and not write a full system penetration textbook. 🙂
This policy template covers a lot of files I don’t have.
Yes, that’s correct. We pulled a list of all the setuid programs from a wide range of Linux distributions, so it will list a lot of files that simply won’t be on your Cloud servers.
When you create a baseline for this policy the FIM code discovers which setuid programs are installed and which are not. From that point on we make sure that your production machines exactly match the files that were present on the baseline system, as well as making sure the production machines don’t have the files which were absent. You’ll get an alert if the former files change, or if any of the latter files suspiciously show up.