the preauth fingerprinting for postgres is somewhat
unmaintainable, but due to a specific customer request
i have added these two FPs for 9.4.1-5
MS-1102
Exploit::Remote::HttpServer and every descendant utilizes the
print_prefix method which checks whether the module which mixes in
these modules is aggressive. This is done in a proc context most
of the time since its a callback on the underlying Rex HTTP server.
When modules do not define :aggressive? the resulting exceptions
are quietly swallowed, and requestors get an empty response as the
client object dies off.
Add check for response to :aggressive? in :print_prefix to address
this issue.
Fix#6445
Problem:
When an HttpServer instance is trying to register a resource that
is already taken, it causes all HttpServers to terminate, which
is not a desired behavior.
Root Cause:
It appears the Msf::Exploit::Remote::TcpServer#stop_service method
is causing the problem. When the service is being detected as an
HttpServer, the #stop method used actually causes all servers to
stop, not just for a specific one. This stopping route was
introduced in 04772c8946, when Juan
noticed that the java_rmi_server exploit could not be run again
after the first time.
Solution:
Special case the stopping routine on the module's level, and not
universal.
def peer is a method that gets repeated a lot in modules, so we
should have it in the tcp mixin. This commit also clears a few
modules that use the HttpClient mixin with def peer.
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.
Platform can be seen from different sources:
1. From the opts argument. For example: When you are using
generate_payload_exe, and you want to set a specific platform.
This is the most explicit. So we check first.
2. From the metadata of a payload module. Normally, a payload module
should include the platform information, with the exception of
some generic payloads. For example: generic/shell_reverse_tcp.
This is the most trusted source.
3. From the exploit module's target.
4. From the exploit module's metadata.
Architecture shares the same load order.