Cracker modules crash when ACTION is auto and CRACKER_PATH is set #20907
Description
Description
The cracker modules (auxiliary/analyze/crack_windows and auxiliary/analyze/crack_osx confirmed, probably others) crash when the ACTION is auto, which is the default. When the ACTION is auto I would expect that it would search for hashcat or john in the path and use that one when it's available. If the CRACKER_PATH option is set, that should take precedence, but under no conditions should it fail with a TypeError as it does.
Steps to reproduce
Make sure hashcat and john are not in the $PATH environment variable. Set the CRACKER_PATH to one of the binaries, they use the auto option. See it crash.
msf > use crack_windows
Matching Modules
================
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 auxiliary/analyze/crack_windows . normal No Password Cracker: Windows
1 \_ action: auto . . . Auto-selection of cracker
2 \_ action: hashcat . . . Use Hashcat
3 \_ action: john . . . Use John the Ripper
Interact with a module by name or index. For example info 3, use 3 or use auxiliary/analyze/crack_windows
After interacting with a module you can manually set a ACTION with set ACTION 'john'
[*] Using auxiliary/analyze/crack_windows
[*] Setting default action auto - view all 3 actions with the show actions command
msf auxiliary(analyze/crack_windows) > run ACTION=auto CRACKER_PATH=/home/smcintyre/Repositories/john/run/john
[-] Auxiliary failed: TypeError no implicit conversion of nil into String
[-] Call stack:
[-] /home/smcintyre/Repositories/metasploit-framework/lib/metasploit/framework/password_crackers/cracker.rb:349:in `popen'
[-] /home/smcintyre/Repositories/metasploit-framework/lib/metasploit/framework/password_crackers/cracker.rb:349:in `cracker_version'
[-] /home/smcintyre/Repositories/metasploit-framework/lib/msf/core/auxiliary/password_cracker.rb:92:in `new_password_cracker'
[-] /home/smcintyre/Repositories/metasploit-framework/modules/auxiliary/analyze/crack_windows.rb:168:in `run'
[*] Auxiliary module execution completed
msf auxiliary(analyze/crack_windows) > use crack_osx
Matching Modules
================
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 auxiliary/analyze/crack_osx . normal No Password Cracker: OSX
1 \_ action: auto . . . Auto-selection of cracker
2 \_ action: hashcat . . . Use Hashcat
3 \_ action: john . . . Use John the Ripper
Interact with a module by name or index. For example info 3, use 3 or use auxiliary/analyze/crack_osx
After interacting with a module you can manually set a ACTION with set ACTION 'john'
[*] Using auxiliary/analyze/crack_osx
[*] Setting default action auto - view all 3 actions with the show actions command
msf auxiliary(analyze/crack_osx) > run ACTION=auto CRACKER_PATH=/home/smcintyre/Repositories/john/run/john
[-] Auxiliary failed: TypeError no implicit conversion of nil into String
[-] Call stack:
[-] /home/smcintyre/Repositories/metasploit-framework/lib/metasploit/framework/password_crackers/cracker.rb:349:in `popen'
[-] /home/smcintyre/Repositories/metasploit-framework/lib/metasploit/framework/password_crackers/cracker.rb:349:in `cracker_version'
[-] /home/smcintyre/Repositories/metasploit-framework/lib/msf/core/auxiliary/password_cracker.rb:92:in `new_password_cracker'
[-] /home/smcintyre/Repositories/metasploit-framework/modules/auxiliary/analyze/crack_osx.rb:96:in `run'
[*] Auxiliary module execution completed
msf auxiliary(analyze/crack_osx) >
Were you following a specific guide/tutorial or reading documentation?
Was testing PR #20897
Expected behavior
If the action is set to auto, it should use the CRACKER_PATH if it's set. If the CRACKER_PATH filename is john, or hashcat or something obvious, just assume that's it. If it's 'myawesomecracker', then the action should probably throw a bad-config error saying it doesn't know what 'myawesomecracker' is and that the ACTION needs to be set to either john or hashcat depending on what 'myawesomecracker' is. That seems like a reasonable middle ground vs running the binary and checking the help/banner output which would be slightly more complicated.
Current behavior
It crashes with a TypeError because the cracker is set to 'auto' which is not a valid value.
cracker is set to 'auto' here. The caller is boilerplate code. #new_password_cracker should probably be edited to check when cracking_application is 'auto' and handle it correctly so each module doesn't need to be updated.
The cracker should also be figured out