Remote and Local Exploits

If an attacker wants to compromise a server that he or she does not already have legitimate access to (e.g., console access, remote authenticated shell access, or similar access),then a remote exploit is required. Without remote access to a system, local vulnerabilities cannot be exploited.

Vulnerabilities either exist in a network-based application such as a Web server, or a local application such as a management utility. Most of the time, separate, local, and remote vulnerabilities are exploited consecutively to yield higher privileges; however, frequently the services that are exploited by remote exploits do not run as root or SYSTEM. For example, services such as Apache, Internet Information Server (IIS), and OpenSSH run under restricted, non-privileged accounts to mitigate damage if the service is remotely compromised. Consequently, local exploits are often necessary to escalate privileges after remote exploitation.

For example, if an attacker compromises an Apache Web server, he or she will most likely be logged in as user “Apache,” “www,” or some similarly named non-root user. Privilege escalation through local exploits, kernel bugs, race conditions, or other bugs can allow the attacker to change from user “Apache” to user “root.” Once the attacker has root access, he or she has far more freedom and control of that system. Remotely exploiting a recent vulnerability in Apache under OpenBSD yielded non root privileges; however, when combined with a local kernel vulnerability (a select() system call overflow), root privileges were obtained. This combined remote-local exploit is referred to as a two-step or two-staged attack.