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:
- Unreliable exploitation with ms08_067_netapi ? Richard Miles (Jun 03)
- Re: Unreliable exploitation with ms08_067_netapi ? HD Moore (Jun 03)
- Re: Unreliable exploitation with ms08_067_netapi ? Richard Miles (Jun 03)
- Re: Unreliable exploitation with ms08_067_netapi ? HD Moore (Jun 03)
- Re: Unreliable exploitation with ms08_067_netapi ? Richard Miles (Jun 03)
- Re: Unreliable exploitation with ms08_067_netapi ? Richard Miles (Jun 03)
- Re: Unreliable exploitation with ms08_067_netapi ? HD Moore (Jun 03)