Previously the status message timing was determined by the number of
pairs left to process. I have adjusted the code to rely on Time.now
in order to consistently print a message out every 60 seconds.
This commit removes the creation of a separate, timed
thread for printing out status messages to the user
in the case of large PASS_FILEs. This adjustment eliminates
the overheard of context switching associated with
spinning off separate threads, as well as the dangers
associated with the Thread#kill method.
SeeRM #8704
When running a *_login module that contains a large PASS_FILE
the module appears to hang while it is creating the combinations over
such a large dataset. The solution proposed in the Redmine task
requested that the user be alerted with some sort of progress feedback
if the process takes an excessive amount of time.
I have added a message that logs to the console that contains the
number of pairs left to be constructed before the module will continue.
The verbiage is fairly arbitrary and should probably be updated to
something that might be more descriptive. Likewise, the sleep
interval may need to be adjusted.
John cares not one whit how many colons are in a hash line, only that
there are enough for the format (at least 2 for regular /etc/passwd, at
least 3 for NTLM, etc). So there is no simple way to programmatically
determine whether a password had a colon or there was just an extra on
the end of the original hash line.
[MSP-9778]
See #2515
Also:
* Import John the Ripper's plaintext from cracked NTLM hashes in the
same way
* Don't choke on : in passwords when reading JtR's output
* Fix some whitespace
* Show a count of inactive creds if there are any instead of acting like
they don't exist
On systems without bundled johntheripper (either by removing the bundled version or by no compatible version shipped) the system john is used. In this case, all of the checking for compatible bundled jtr makes no sense and as such we can shortcut out of this to not only reduce the size of msf (for embedded) but also to speed execution (saving multiple calls to some random bundled binary cpuinfo*.bin).
This patch makes it very easy to simply remove cpuinfo and msf will not try to run it when missing and default to running john from the path.
[#46491831]
Comments at the start of the file with ## caused YARD to think the
comment was documenting the require call. By removing the ##, the
warning disappeared. I did not determine what is special about ## in
file comments.
store_local calls report note from db.rb directly instead of going
through the report method. this means we might miss the workspace
causing a stack trace
Recent category updates to modules caused variations of vulns of the
same type to be ignored leading to a smaller exploitation surface.
Thus, use the #name of the module as the key instead of the category name.
#log_fingerprint and #log_resource now create a key in the
parent's #vulns attribute with the name of the vuln type and
store the details of each such vuln under it.
nstarke