Fix#6658.
When there is no service pack, the
Msf::Exploit::Remote::SMB#smb_fingerprint_windows_sp method returns
an empty string. But in the MS08-067 exploit, instead of check an
empty string, it checks for "No Service Pack", which causes it to
never detect the right target for Windows Server 2003 SP0.
In #6283, we discovered that ms08_067 was busted with reverse_tcp. The
solution was to bump the amount of space needed to help with encoding.
However, we flew a little too close to the sun, and introduced a
regression with bind_tcp on Windows XP SP2 EN where the payload stages
but does not run.
This shrinks the payload just enough to make bind_tcp work again, but
reverse_tcp also continues to work as expected.
Most exploits don't check nil for generate_payload_exe, they just
assume they will always have a payload. If the method returns nil,
it ends up making debugging more difficult. Instead of checking nil
one by one, we just raise.
msf exploit(ms08_067_netap) > show targets
Exploit targets:
Id Name
-- ----
0 Automatic Targeting
1 Windows 2000 Universal
2 Windows XP SP0/SP1 Universal
3 Windows 2003 SP0 Universal
4 Windows XP SP2 English (AlwaysOn NX)
[...]
62 Windows 2003 SP1 French (NX)
63 Windows 2003 SP2 English (NO NX)
[...]
71 Windows 2003 SP2 French (NO NX)
72 Windows 2003 SP2 French (NX)
This psexec payload size should be evaluated to make sure I'm not doing
anything stupid. i can't see a reason why increasing these sizes would
be bad. They seem to work fine.
This missing parameter was causing the payload 'Size' to come through to
the encoders as `nil`. This meant that all the stagers that were
looking at the payload sizes were being told there was no size. In the
case of the meterpreter payloads, this was causing issues with the proxy
settings because the proxy configuration detail isn't added to the
payload unless there's enough space.
This fix adds a default size of 2048 (the same as the plain psexec
module). This makes the proxy settings work as expected.