Metasploit mailing list archives

Re: Unreliable exploitation with ms08_067_netapi ?


From: HD Moore <hdm () metasploit com>
Date: Thu, 03 Jun 2010 08:56:58 -0500

On 6/3/2010 8:48 AM, Richard Miles wrote:
Independent of this, to set a correct target I need to know the OS
language and if NX is in use or not. Metasploit has a script to detect
OS language on port 445 but my experience is very bad, sometimes work
but most of the time it just return unknown. There is no way to
improve it?

Not really. The only way we can reliably detect the remote language pack
is using the printer driver technique published by Immunity. On
operating systems that do not allow the print drivers to be enumerated
without authentication, it is not possible to identify the language
pack. If you can figure out the language pack on your own, you can set
it, but thats why we have 50+ targets.

Also, there is a way to detect if NX is in use remotely?

Not that I know of.

I'm asking because most of the times the auto-target fail like that

msf exploit(ms08_067_netapi) > exploit

[*] Started bind handler
[*] Automatically detecting the target...
[*] Fingerprint: Windows 2003 Service Pack 2 - lang:Unknown
[-] Could not determine the exact language pack
[*] Auto-targeting failed, use 'show targets' to manually select one
[*] Exploit completed, but no session was created.

This doesn't actually send any exploit requests and will not affect the
exploitability of the system.


After that, I have no more shots, I only get

[*] Started bind handler
[-] Exploit failed: The server responded with error:
STATUS_OBJECT_NAME_NOT_FOUND (Command=162 WordCount=0)
[*] Exploit completed, but no session was created.

This means the service has already crashed and restarted (the BROWSER
pipe is not available).

I'm using SVN version. I'm kind of disappointed, I tested in 8
machines and all failed like that.

If all 8 machines had OBJECT_NAME_NOT_FOUND, you need to reboot those
machines to a non-crashed state first.

Reading on google people say it may be because AV blocked meterpreter,
etc. Is it real? Change to a common bind_tcp payload may be a more
reliable option?

Its unlikely than AV is blocking this exploit; normally AV only
interferes when the disk is accessed (psexec, client-sides where a local
file is dropped, etc).

I personally believe it's a problem with offsets related with Lang or
NX / NO NX.

All of those targets have been tested; the NX targets work on NO-NX
systems, but not the other way around. If you try with the wrong target
first, you will crash the service and get the error you saw above.

I tested 2 machines with target 9 (Win2003 SP2 English NX) and other
two with target 8 (Win2003 SP2 English NO NX) and all failed. I live
in a country where the native lang is English, so I believe it should
be correct...

The 2003 SP2 target is fragile; any updates to the DLLs used in the ROP
chain will cause the target to fail. They *only* work with a fresh SP2
install, not if additional patches are applied. There isn't a magic
bullet for this stuff; the existing targets are pretty solid given the
constraints they have to work within.

Maybe there are missing more offsets for Windows 2003 + SP2? Maybe not English?

Windows 2003 + SP2 is difficult to exploit, as you need to use ROP
chains to bypass DEP. It takes quite a bit of time to find a working
target for each language, and sometimes those depend on DLLs that change
more often than the service pack.

-HD
_______________________________________________
https://mail.metasploit.com/mailman/listinfo/framework


Current thread: