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.
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
Jon Hart
William Vu
Christian Mehlmauer
Brent Cook
HD Moore
sinn3r
jvazquez-r7
Meatballs
Bazin Danil
James Lee
nstarke
sgabe