Author: NetworkAdminKB.com
Created: 2009-08-13
Modified: 2009-10-25
In this article I will discuss common misconceptions about Security Exploits and try to better inform Network Administrators about what Security Exploits are and how they can be limited in scope. Most IT Managers and Network Administrators don’t really understand what a Security Exploit is or how an attacker uses it. Because of this lack of understanding common misconceptions and overwhelming fears are very pervasive in our industry.
The protocol the Security Exploit starts with will not change to a different type of protocol.
While this statement may be a duh! moment for people, it does need to be stated. Many Network Administrators and IT Managers commonly over look this simple fact, believing and talking about scenarios where the attacker has god like powers to make every command work as if they are sitting directly at the computer. Nothing could be further from the truth.
If the Security Exploit is done via HTTP or a web server, the protocol the attacker uses to initiate commands on the target server will always be HTTP. The attacker can not turn one protocol into another, even after the Security Exploit has been made. For example, HTTP cannot become the Remote Desktop Protocol (RDP) allowing a remote desktop/GUI interface, nor does HTTP become a Telnet session allowing a DOS prompt view of the target computer. The compromised protocol is a limiting factor in how the attacker will interact with the target server.
Also, just because the attacker has exploited a Security Context via the HTTP protocol, does not mean that other protocols (like Telnet or the FTP) are now compromised (i.e. the attacker has elevated privileges via these protocols) as well. Every Security Exploit is protocol/service specific. Just because the attacker exploits HTTP to gain elevated privileges does not mean that every protocol/service on the target server is automatically compromised. However, the attacker may be able to run commands via the compromised protocol to enable/disable/compromise these other services as well.
The ability to enable/disable/compromise additional services will also be limited by the configuration of your firewall. Simply enabling a service on the target server is moot if the firewall will not allow traffic in or out on that port from the target server.
Security Exploits are always limited to shell/command line utilities
Unless the Security Exploit is done directly to the RDP (or ICA, etc) protocol the attacker is always limited to running shell/command line utilities on the target server. GUI commands that support command line switches to perform tasks can be used in this manner as well.
It may be possible for the attacker to enable the RDP protocol for Administration via a registry edit using a command line utility. However, if the target server is behind a firewall that is not configured to allow this protocol this is a moot point. Another issue is that while the attacker may be able to enable the RDP protocol that protocol would still need to be compromised and/or the attacker would need to be able to create a local Administrator account and password.
Almost all Security Exploits will require attackers to remotely initiate command line utilities to further compromise the target system. While the attacker may be able to remotely initiate command line utilities, the output/success/failure information from these commands are not always easily returned to the attacker. This is because not all protocols have the ability to return data from these non-native commands. Remember, the attacker is still bound by the rules of the original protocol.
Because of the lack of output/success/failure information that may be returned, attackers use a 3 step approach to running commands on the target computer.
1) Issue a command to the target system
2) Attempt to verify the command worked
3) Repeat until successful
It should be noted that the HTTP protocol has the ability to return command line utility output as a web page, which can greatly simplify attacker processes for compromising a computer system. If using FTP redirecting output to a file and downloading the file is very common. If a Telnet session is compromised input and output is from commands is usually easily viewed.
The last thing to note about this is that some protocols like FTP and HTTP will allow the attacker to upload their own utilities to the target server. This will also simplify the attacker processes for compromising the computer system. To mitigate these types of risks you should use realtime virus scanning to prevent potentially dangerous code from being executed.
The Security Context exploited will be the same as the process that manages the protocol/service being exploited.
A common misconception about Security Exploits is that they always grant Administrator access to the target server. This is not the case. Administrator access implies that an Administrator account or the Local SYSTEM account has been compromised directly and is not always the case.
The reality of the situation is that almost all Security Exploits are limited by the Security Context of the identity that started that process. In Windows all services/process run under a Security Context, either an actual user account or a predefined System Identity. Each service that runs is configured for a Security Context. Processes that are started from within a user session run under the user account Security Context.
Once the service/process is compromised the elevated privileges achieved are limited by the Security Context of the identity that started that process. Below are example screen shots showing how Windows Sharepoint Services are configured to run under user accounts. If these services are compromised the Security Context of those accounts will be the limiting factor on access to local and remote resources. If these accounts are Local Administrators then administrative access would be granted, if they are simply user accounts then only normal user access would be granted.
Security Exploits on one computer does not mean all computers are compromised
The basic limiting factors for Security Exploits are
1) The ability of the attacker to obtain output/success/failure information from command line utilities
2) The ability of the attacker to upload and run their own utilities on the server.
3) The Security Context of the compromised service/process
Because of these factors the ability for the attacker to compromise other systems is may be greatly reduced. This is not to say that it an attacker can’t compromise more systems, but you as the administrator should logically work through the situation and determine if the risk is real or if it is fear of the unknown people are concerned with.
Security Exploits rely on un-patched systems
You can’t protect your computer system from an unknown vulnerability. There is no fix, no setting, no tweak, etc. that will prevent the unknown vulnerability. Once the vulnerability is known (published or used publicly) you have generally two solutions
1) Implement a known solution to mitigate the vulnerability
2) Install a Patch that will remove the vulnerability
Most Security Exploits are only resolved via a patch. Thus, a well planned, designed, and implemented Patching Policy is the best solution to prevent Security Exploits on your computer systems.
Summary
The bottom line on Security Exploits is that using them to gather information take time when good security practices and patching solutions are in place. If these good security practices are in place hackers are more likely to compromise your computer systems using Social Engineering techniques to acquire passwords or get un-sophisticated users to install Trojan software, etc. With proper virus software, firewall, DMZ, and layered security approaches you can make sure that even if a perimeter computer system is compromised via a Security Exploit, the hacker is restricted to just that system.
Definitions
Security Exploit: is the process of attacking a target server for the purpose of gaining elevated privileges on the target system. Common Security Exploits are buffer over runs, malformed packets, etc. that allow the attacker to issue commands or possibly run arbitrary code on the target computer system. They are typically implemented using special tools to create special packets not normally found. The degree of elevated privileges obtained is directly related to the Security Context the targeted service/protocol is running under. A Security Exploit is not a User/Name password attack or login.
Arbitrary Code: this simply means that random or potentially specific code in memory can be executed via a Security Exploit. For an attacker to use this type of Security Exploit they must either load the code into memory via some other means or they must know where code already exists in memory and attempt to formulate a Security Exploit to run it.
Security Context: is the amount of privilege (access) a particular user account or System Identity has to various system resources.
System Identity: Windows provides several predefined Security Contexts that provide different levels of access to system resources. Common examples are Local System (aka SYSTEM), Local Service, Network Service.
System Resources: these are things like the file system (NTFS permissions), registry (Registry defined permissions), local accounts database (SAM database), and User Rights Assignments (i.e. Act as part of the operating system, Backup files and directories, etc). Access to System Resources are controlled by the permissions assigned on target System Resources and the Security Context of the requesting process.
Article ID: 8, Created On: 9/15/2011, Modified: 9/15/2011