Dangers with Privilege Escalation Attacks
Privilege escalation attacks bring an additional dimension to the attack surface when an attacker is attempting to achieve administrative control of a network. Although the dangers of a successful privilege escalation attack may be clear from the perspective of gaining elevated administrative access, some of the consequences of gaining such access are often overlooked by administrators.
Gaining administrator-level access to any network will allow attackers to perform many tasks that can cripple network resources and significantly impact the confidentiality, integrity, and availability of network resources. In the case of a Windows Active Directory domain, obtaining privileges equal to the domain administrator or any member of the Domain Admins group will most likely allow attackers to have unfettered access to all data and services within the domain. Access may include full control of applications, such as Exchange and Structured Query Language Server instances, as well as data stored by those applications.
Elevated access may also allow attackers with administrative access to reconfigure services and applications in such a manner that would cause a DoS condition. Causing a DoS condition may prevent access of legitimate users to a service or application that is required to complete normal work tasks. The DoS condition may also have an effect on multiple applications. For instance, if a database that supports a Web application is compromised, a loss of availability for the database and the Web application may result. Additionally, the DoS condition may prevent legitimate customers access to services, causing an impact to customer satisfaction and possibly affect revenue streams for the organization.
Escalated privileges are not always used to cause DoS conditions or for gaining administrative access to resources. Sometimes, the primary reason for escalated privileges being sought is to gain access to data. Data can include customer records, employee records, or even proprietary information that may provide the organization with a strategic market advantage. Attacks such as these can be used for gathering information and may include prolonged access with a goal of spying on competitors' development efforts. In these cases, an attacker may not be after gaining root or administrator-level access but just enough access to gain access to sensitive data.
alt1 Note
If an attacker is attempting to obtain a specific piece of data or information, he may choose to only gain as much access as required to achieve his goal. Obtaining only the access needed to complete his mission may reduce his attack signature and reduce the likelihood of detection. Always ensure logging and intrusion detection systems are enabled to help identify malicious activities and provide valuable information about impending attacks.
Obtaining escalated privileges may also allow attackers to forge legitimate requests and use the identity of compromised accounts to cause other disruptions of business activities. If an attacker is able to gain access to a privileged account and is able to create a new account or hijack other accounts, he may be able to cause severe panic and loss of confidentiality of the organizations customers. Attacks such as these can trigger unwanted media exposure and can have a lasting impact on the reputation of the organization.
Scenario 1: Escalation through Batch Scripts
Sometimes when attackers decide on a target and begin working toward the goal of gaining administrative access, it is beneficial to take into account the flaws found within the operating system as well as the common mistakes administrators may make in supporting the systems. This first attack scenario explains how batch scripts used to automate tasks can be used by attackers to gain additional privileges in a Microsoft domain environment.
Traditionally, batch scripts have been used by network and system administrators, as well as application developers, to automate the execution of routine administrative tasks. This type of automated administration helps reduce the administrative burden that administrators face on a daily basis. (Can you imagine having to defragment hundreds of computers every week and not having an automated way to do it?)
Creating a batch script to automate system tasks is fairly easy to accomplish. A series of commands or statements can be written in a text file using applications such as notepad and saved for use by the system task scheduler or executed manually. The batch script itself can make tasks that need to be performed frequently. Although this sounds fairly convenient, implementing batch scripts with little concern of what context the batch script is running under can be disastrous.
In this scenario, the attacker obtains access to a Windows XP computer that is a member of the skynet.local domain. The attacker was able to leverage a Server Message Block vulnerability on a Windows XP system by using a publicly available exploit to cause a buffer overflow and return a system shell back to the attacker. The attacker was then able to obtain the contents of the password database and crack the passwords offline. Cracking the passwords provides the attacker with several sets of valid usernames and passwords for the system, including the local Administrator account password.
Once the attacker has access to the compromised system, he is able to gather additional information about the system that may provide the attacker with more ideas for performing additional attacks. In this scenario, the attacker inspects the scheduled tasks configured to run on the system. Figure 2.1 displays a scheduled task called “defrag” configured to run every day at 9:52 p.m. To learn more about the scheduled task, the attacker may view the properties of the task right-clicking on the task and selecting Properties.
FIGURE 2.1. Task Scheduler
Upon closer review of the scheduled task (Figure 2.2), the attacker learns the scheduled task uses a batch script to perform defragmentation of the hard drive every night. The batch script is located in the skynetuser's My Documents folder and is called “defrag.bat.” The attacker also notices this task is configured to run under the context of the SKYNETadministrator user account. This means that the script is running under the context of the domain administrator and the actions within the script will also be executed under the same context.
FIGURE 2.2. Task Scheduler Properties
In Figure 2.3, the attacker uses the system access he has already gained to modify the batch script to add a user account to the domain. The NET USER command is used to create a user account named jrivas on a domain controller in the domain. The NET LOCALGROUP command adds the jrivas account to the administrators group for the domain. With both of these commands, the attacker has added the /DOMAIN switch to the command. The /DOMAIN switch directs to command to be executed on a domain controller within the domain.
FIGURE 2.3. Batch Script Modifications
After the attacker makes the modifications and saves the defrag.bat file, he can either run the scheduled task immediately or wait until the next time the task was scheduled to run. Once the script runs, it executes two commands in the script. Figure 2.4 shows the results of the script execution. The user jrivas is added to the domain and is now a member of the domain administrators group.
FIGURE 2.4. Domain Administrator Added
The attacker now has all the rights and privileges he needs to perform whatever actions he wishes on the domain. Depending on the goal of the attacker, this can be simply stealing data or causing DoS conditions. With domain administrator access, the attacker may also consider obtaining the user accounts and passwords hashes for all users in the domain and cracking them offline.
It is important to understand that this attack allowed the attacker to create a user account in the domain, but it also allowed him to make that user a domain administrator. Both of these tasks were done without ever logging in as a domain administrator and were the result of a poorly patched system and the presence of a batch script that was configured to perform normal maintenance operations under the context of a domain administrator account. Sadly enough, this attack is not theoretical and actually takes place every day.
With the access to a local administrator's user account credentials, an attacker may be able to view the tasks scheduled on other computers within the domain. This helpful feature may allow attackers to use accounts that have been compromised to identify other systems with tasks scheduled that may be leveraged for privilege escalation attacks. As this scenario illustrates, this can provide a very large number of potential targets when an attacker is trying to escalate privileges. An example of how to browse a network and identify scheduled tasks on a remote computer is explained at the Microsoft support site (http://support.microsoft.com/kb/310424).
Scenario 2: Attacking Customer Confidence
This scenario builds on the methods described in Scenario 1, “Escalation through Batch Scripts,” but describes how deadly these attacks can be. We often hear about the malicious activities performed by attackers who make headline stories in the media. In many cases, the activities revolve around stealing account information or other corporate data and selling it to underground organizations for distribution in the pursuit of committing fraudulent acts. However, consider the possibility where the goal of the attacker is not stealing customer data but to tarnish the image of a company.
Our attacker “Josue” recently went to his favorite local restaurant, “Casa de Marginal,” for some fine Puerto Rican buffet. Every Friday, the restaurant features one of his favorite foods, Seafood Paella, and he always makes it a point to build up a good appetite for lunch to maximize his return on investment from the buffet. This Friday was a little different- the restaurant decided to change the buffet menu and fired the previous chef. The new chef made major changes in the menu and also in the recipe for Josue's favorite dish.
After experiencing one of the worst dining experiences he has had in a long time, the attacker decided to take matters into his own hands and distribute a little “Internet justice.” The attacker gains access to the internal network using a point-to-point tunneling protocol virtual private network connection and a user account with a weak password. Having the knowledge of how to escalate privileges, the attacker modifies a batch script similar to the one we discussed in the last scenario and adds a domain administrator account to the casademarginal.local Windows domain.
Now that the attacker has access to the domain with administrator-level access, he can do anything he wants. The attacker finds the restaurant is hosting its own Web site and e-mail servers from within the network he has access to and leverages his access to conduct some nefarious tasks.
First, the attacker configures an e-mail client to access the Exchange server and browse the Global Address List (GAL). As the attacker is viewing the contents of the GAL, he notices that there is a distribution list named “Customer Mailing List” and further identifies that the list has over 3000 customer e-mail addresses within it. The attacker decides to craft an e-mail and send it to the restaurants' customers as depicted in Figure 2.5.
FIGURE 2.5. Example E-mail
After sending the e-mail to the entire customer list, the attacker logs into the Microsoft Internet Information Services (IIS) server and modifies the home page of the restaurant to notify the customers the restaurant is temporarily closed for “renovations.” The attacker then changes the passwords of all the domain administrators' accounts, so it will not be easy for legitimate administrators to revert the malicious acts of the attacker.
As you can imagine, a situation like this can be absolutely devastating to small and large companies alike. Winning back customers and reestablishing a good reputation by word of mouth for how good the restaurant really is will be a significant challenge. This type of attack can cause a large loss of revenue for the restaurant and can ultimately lead to the failure of the business altogether.
Think of ways an attack similar to this can be used against your organization. Can you think of similar attacks that would be such devastating? How long would your organization be able to withstand a significant decrease in revenue? What is the likeliness an attack like this will or can occur?
Scenario 3: Horizontal Escalation
Horizontal privilege escalation can allow an attacker to gain access to data that may not necessarily belong to him. In poorly designed applications, an attacker may have the capability of identifying flaws within a Web application that allows him access to other users' information. Once access is gained to another users' data or account via leveraging flaws, he may modify, copy, destroy, or use the data for his needs.
In this scenario, the attacker works as a telemarketer for a training company that sells training to potential students who want to pass information technology (IT) certifications. The job is okay, but sometimes it feels like all our attacker does is make calls and cross his fingers whether the call will result in a sale. Part of the job is to track all of the potential sales or “leads” in a custom Web application developed by corporate application developers. All telemarketers are required to keep track of their leads and the progress made toward a sale.
Our attacker is having a slow month and needs to make sure he is performing well so he can keep his job. He notices that if he changes the employee ID number displayed in the URL of the lead-tracking Web application, he can see and modify other telemarketers' leads. He decides to change the employee ID to one of the employees he works with (but is not too fond of) and views the status of several of the coworker's leads.
Since the attacker has successfully performed a horizontal escalation of privileges attack and can view and modify the coworker's leads, he decides to use this access to make his productivity numbers look better than they currently are. The attacker deletes a few of the coworker's leads and can now re-create the leads under the context of his own account. The attacker has now “skimmed” several of the accounts and improved his productivity numbers, keeping him well within range of another successful sales month.
Attacks such as the one described in this scenario are still relevant today and pose a significant security threat to organizations. Imagine if this type of scenarios was played out against your online backing account. What dangers could you think of? What if another customer from your bank was able to access your account by using horizontal privilege escalation attacks?
Future of Privilege Escalation Attacks
As some of these attack scenarios have illustrated, attacks may be executed in ways that developers and administrators never thought of. Attackers have a keen eye and thought process for finding methods of increasing access to target systems and networks. Flaws in application development and implementations have been a rigid backbone for fostering new avenues of exploitation of privilege escalation attacks.
As new technologies are introduced and methods of development are refined, attackers will most likely be only a few steps behind, and they will identify flaws that allow similar attacks to what we are experiencing today. It is unlikely that programming and administrative practices will become inherently stronger in the near future to help defend against these types of attacks, so it is very likely that the success of attackers today will continue to remain worthwhile for similar attacks in the future.