meterpreter

In the recent Applocker/SRP discussion meterpreter came up as the most likely attack vector against Anti-executeables (even if they work 100% )

I've installed metasploit and used this vulnerability against Windows 7 SUA+AL: http://www.metasploit.com/modules/exploit/windows/browser/ms11_xxx_ie_css_import

With EMET enabled it fails. I don't even have to enable all 6 protection mechanisms, mandatory ASLR or EAF alone would suffice. EAF could probably be worked around, but with all 6 enabled I don't see much of a chance that this class of exploit could results in reliable code execution.

There's another reason this exploit isn't that scary as I first thought:
It locks up IE, a user might suspect something is wrong and will most likely try to kill it (the gui is completely unresponsive, you need to use taskmanager). Metasploit has a workaround for that: as soon as the payload is successfully executed it will "migrate" to another process. Because IE is running in low IL on Windows 7 it doesn't have sufficient privileges to attach meterpreter to Medium Level process. On most systems you only have a single process running in low, the one we just crashed. So it launches a new Low process, by default it's notepad.exe (the real one), it's hidden but visible in taskmanger and this should rise a red bar in any HIPS and firewall worth its salt.
However as ILs are embraced by more 3rd party devs meterpreter can migrate to an already running process and stay under the radar. If you exploit a medium IL process you can migrate to explorer.exe for example which gives a very stable and long term meterpreter session.

I'd really like to know how the meterpreter migration works. When I protect notepad with EMET it can't migrate to it. This is what you see in Process explorer when meterpeter is running in notepad (the 0x0):

 

@katio,

thank you for sharing the findings of your research; much appreciated

 

Very Interesting - Thanks for researching this.

 

The IE sandbox is actually the only sandbox I researched that allows you to open a handle to another LI process to write (and thus migrate). The Adobe Reader X, MS Office 2010 and Google Chrome sandboxes don't allow you to do this (they achieve this by using a restricted token with restricting SIDs).
What's more, these sandboxes don't allow you to create another process either (achieved via a job object limited to 1 process).

 

Thanks, I new about the job limit but not about the other. But not every exploit crashes its host, right?

Could you briefly explain how meterpreter can "infect" another process that isn't even vulnerable?

 

Open handle to said process, create virtual memory page with read/write/excute rights, write meterpreter stager to said page, create remote thread in said process, meterpreter is loaded into said process.
As the creation of a remote thread is also used in DLL injection, many HIPS will detect this. But there are ways to hijack an existing thread in stead of creating a new thread.

 

Thank you again! Do you have an idea why EMET blocks the migration though?

I wonder why the IE sandbox isn't more locked down. 3rd party/backwards compatibility maybe? At any rate, another reason not to use it....

 

Some more tests and I think firewalls are no solution, it will detect a firewall and route the traffic through IE and not notepad, if you kill IE the meterpreter session ends.

 

Even Win7/Vista fw with Advanced security?

 

Can you set up an attack situation with this payload as it might be encountered in the wild, so that we can test our defenses?

thanks,

rich

 

The migration is blocked when you enable EMET EAF option, and it is not when the option is disabled, right?

That's a good indication that the meterpreter stager uses shellcode that scans the EAT for functions it needs. EMET puts some memory breakpoints on the EAT to detect such shellcode.

Metasploit could avoid this by passing the addresses of LoadLibrary and GetProcAddress to the stager, and then let it lookup all the functions it needs, without scanning the EAT.

 

That killed it. I set it to block outgoing and added a single rule for iexplorer to allow everything, it migrated to notepad which is blocked and I lost the connection. But you don't have to migrate to another process, it's more reliable but not necessary.
It's probably not how it's supposed to be done but by renaming or moving msf3\scripts\meterpreter\migrate.rb I can prevent meterpreter from automatically spawning and migrating to notepad. So as long as no one kills iexplorer.exe I can get in despite the firewall. the standard configuration also could be blocked by a more fine-grained browser rule since it uses nonstandard ports, but what's going to stop me from using 80 and 443?

That's a bit difficult I'm afraid. I'd need to setup dynamic DNS, forward and open at least two ports on several firewalls and then babysit all the running sessions, restart them manually and so on.
I'm sure I could automate some of that but I've only installed metasploit yesterday and I'm far from knowing all its functions.

Instead I'd ask you to install it yourself as it's really easy and a quick setup. I'll give you a rundown to get started.

Since I'm a bit small on RAM I can't run two graphical VMs side by side. I installed metasploit framework-3.5.1.exe
http://www.metasploit.com/framework/download/
on a Windows 7 host and another Win 7 inside Virtualbox. I'm using bridged mode which of course isn't exactly best practice but I'm not testing malware after all.

On the attacking computer (=host):
install metasploit, and open its GUI (you'll probably find that the console is actually a better interface but this is just intended for a quick start):
select:
Exploits>windows>browser>more>more...>ms11_xxx...css
in the new dialog window select:
meterpreter->reverse_tcp
then enter your (local if you do it on the local network) IP into LHOST and SRVHOST below.
finally press on the button
"Run in Console"

The console window pops up and among other messages you'll see something like:
Using URL: http://192.168.0.2:8080/UwndiWge83
Open this URL on your target computer (=guest) with IE6-8

Wait a bit
in the metasploit console you'll see:
"Meterpreter session 1 opened"
enter
sessions -i 1
into the box at the bottom
and you get an interactive shell, type
help
for a list of commands

Spot on

 

I'm not making myself clear.

I'm not interested in installing/running this on my computer. I'm interested to see if this payload can get onto my computer in the first place. That is, to penetrate my outer perimeter.

My outer perimeter, or fence, consists of four gates, or entry points:

1) firewall
2) browser
3) USB port
4) email

With a properly configured firewall, exploits such as Conficker.A cannot penetrate and get onto my computer. Checking my firewall log, I see probes all the time that are blocked from entering a closed port.

With a properly configured browser, exploits such as a booby-trapped PDF file cannot run (PDF plugin disabled). The browser then prompts for action, to Open, Save, Cancel. I certainly wouldn't open a PDF file on the web that I didn't go looking for.

With USB port protected from autorun, should such a situation occur (autorun.inf and malicious file on a USB drive), nothing would happen.

With my email program being text only, no malicious HTML code in a message will do anything when viewed in the message window.

You will notice that no traditional security product other than a firewall is required to secure my outer perimeter. (so far)

I say "traditional" because I'm on record as considering a properly configured browser as a (non-traditional) security product.

I say "so far" because there is always that possibility... which is why I ask for an exploit, an attacking mechanism, so I can check.

(The other possibility, which you raised in another thread, is the social engineering trick, where you wrote,

Or, I might include another trick: sending a booby-trapped PDF file as an email attachment)

Now, I detail all of this because what you are doing is testing this exploit against the inner perimeter defenses. Some of these are, Anti-executables, HIPS, EMET, Sandboxie, and more. These attempt to block, mitigate, contain, etc., once the payload has been permitted to run.

There is certainly nothing wrong with this, as it provides much interesting drama, watching the sophistication of such stuff as it works its way through the system.

But from a preventative point of view, I'm interested in what happens at the outer layer of my defense strategy. That's why I ask for an attacking mechanism.

The only attacking mechanism I've seen so far in the other threads is an XLS file with a macro that does the dirty work. I assume the delivery mechanism to get that onto a victim's computer would be an email attachment, where by the victim is tricked/enticed to run the file.

Please understand that I'm not criticizing analyzing what this payload does if it is permitted to run. But unwanted fear can result with those readers who don't realize that any malicious payload needs to somehow get onto the computer in the first place. Only by examining the possible breaches in the various points of entry into the computer can one evaluate the strength of one's defenses!

regards,

-rich

 

The css vulnerability I mentioned is triggered if you browse a site with default IE (medium security). Firewalls, plugins, email programs, USB got nothing to do with this one.

I didn't say you have to set up metasploit on your computer and then attack your computer from within the network. I only said you should attack your Computer yourself because that's much easier to do for both of us.
You can test all your perimeter defenses as well, by separating host and target instead of using the more convenient VM setup. But that won't stop this exploit, or do you block 80 on your firewall?

 

Well, you did. You suggested that I install it myself. (Unless I misinterpreted what you were saying, which is posssible!)

Which site? Is there one out there some place? How would I be led to the site? This last point figures greatly into my reviewing of security when stuff like this sufaces. (Risk assessment, in other words)

You see, all of this is hypothetical for me, which is why I always ask to see a working exploit in the wild. It's just the way I work, and I'm not asking anyone to agree with it. Nonetheless, I have the right to question the immediate threat of a particular vulnerability by asking to see an exploit in the wild. I don't feel that I need to go to the trouble of setting something like that up myself. I don't know how to, anyway. So, if there is no current delivery mechanism out there being used, I normally don't get fearful and anxious.

EDIT: this just in --

Vulnerability in MHTML Could Allow Information Disclosure
Published: January 28, 2011
http://www.microsoft.com/technet/security/advisory/2501696.mspx

(my emphasis)

By including those in my response above, I was covering all possible entry points on my system for any exploit -- not just the potential for these current ones!

In summary: I'm not making light of the potential mishief of these vulnerabilities. I just want to see evidence of how they are being successfully used in the wild. That is my starting point.

Regards,

rich

 

Interesting, and once again, thank you for testing and posting results.

Rich, you are the best

 

Thanks, JR, I didn't realize they were the same exploit. This is the MS Advisory which I've seen:

Microsoft Security Advisory (2488013)
Vulnerability in Internet Explorer Could Allow Remote Code Execution
Published: December 22, 2010 | Updated: January 11, 2011

So, I'll answer my own question to katio!

Yes, there are exploits in the wild, but since the attack vector is IE/HTML email, it doesn't affect me (I don't use IE or HTML email) so, there is no need for me to test it because I don't need to worry about it on my own system.

Thanks again, JR.

rich

 

Is this only an IE exploit? One can assume then that an alternate browser, no matter the settings/config, is immune to it? (I have no idea because I don't follow this much, just a question).

Sul.

 

Yes, IE only. Metasploit doesn't contain any exploits against the latest versions of other browsers at this time. For a targeted attack you clearly have to be very patient but sooner or later a 0day will crop up again...

Currently the second most dangerous 0day is CVE-2010-3970
Two mitigating factors: metasploit's code only works against 2000 and XP and since it doesn't exploit a browser an outbound firewall might catch it.

 

I've had MHTML & various other vectors disabled for about 5 years or so with BugOff.exe by Merijn



From Ronjor's posts

I created a test.mht by opening Metapad/Notepad and carefully copy/pasted the data into it, then renamed it test.mht. This is what happenned.

MHTML enabled



MHTML disabled





So along with the other things BugOff.exe helps protect, this 6 year old little non install free app does the trick Thanks Merijn wherever you are these days

If anyone wants BugOff.exe to try/use let me know

 

From JRViejo's link, an IE mitigating workaround is available until a patch is released:

-http://blogs.technet.com/b/srd/archive/2011/01/11/new-workaround-included-in-security-advisory-2488013.aspx

 

It should be clear but just in case: I'm referring to MSA 2488013/CVE-2010-3971 and MSA 2490606/CVE-2010-3970 which both are unpatched and there's a metasploit module but for both a workaround is available. I'm NOT referring to MSA 2501696 which doesn't have a CVE yet (and no module either).