mailing list archives
Re: Unreliable exploitation with ms08_067_netapi ?
From: Richard Miles <richard.k.miles () googlemail com>
Date: Thu, 3 Jun 2010 16:09:35 +0000
Thanks, very informative.
Not really. The only way we can reliably detect the remote language pack
is using the printer driver technique published by Immunity.
Can you please point me to this paper?
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.
There is a way to use the metasploit smb scanner with a credential to
identify it? I mean, sometimes we have a restricted account
credential, if a restricted/normal user credential allows to enumerate
it, there is a new light on the dark, not?
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).
Appear that restart the server service and browser service service is
not enough to give another shot too. Do you know other if there is
another trick instead of reboot?
I also was thinking, this exploit do not restart the machine if the
exploitation fail, if the box is vulnerable it's very probable the
target also will be SMBv2 DoS, which could help us to force a reboot
to give another try. There is such a exploit at Metasploit?
If all 8 machines had OBJECT_NAME_NOT_FOUND, you need to reboot those
machines to a non-crashed state first.
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).
Hummm, interesting.See this description
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.
So, from now I will always use only the NX targets.
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 add target of 2003 SP2 with all patches less one up to the one
that fix ms08-67? Or it could be useless in real world?
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.
Humm... for this kind of exploit is impossible to brute force this
address values, like in old overflows where ret brute force was
possible? I mean, if used together with a SMBv2 DOS exploit it could
work, not? Or exploitation is too different on recent days?