So in the previous refactor, we made the dedicated method to parse
usernames and passwords from the split up config values. However, that
didn't work, because on a single iteration of the loop, you only have
access to a possible username OR password. The other matching key will
be another iteration of the loop. Because of this, no credential pairs
were being reported.
The only way I can see around this (maybe because I'm a ruby newb) would
be to iterate over configs, and if the user or password regex matches,
add the matching value to a hash, which is identified by a key for both
user & pass. Then upon completion of the loop, it'd iterate over the
hash, finding keys that had both user & pass values.
The get_once would *only* return "MMcS", and stop. I
modified it to be a get(3, 3). Additionally, the command
length was set to 0x01 when it needed to be 0x00.
Refactored the configuration settings so that creds could be reported to
the database more easily, while still being able to print general
configuration settings separately.
Changed datastore['rhost'] to rhost
Made the array storing configuration values into a class const
Moved superfluous array look-over to not be executed unless in verbose
mode
This module exploits a SQL injection vulnerability in the "explorer"
action of "miq_policy" controller of the Red Hat CloudForms Management
Engine 5.1 (ManageIQ Enterprise Virtualization Manager 5.0 and earlier)
by changing the password of the target account to the specified
password.
The HttpClient mixin has a peer() method, therefore these modules
should not have to make their own. Also new module writers won't
repeat the same old code again.
See #2583. Since there are several types of hashes, we need to be more
specific about this -- see modules/exploits/windows/smb/psexec.rb which
uses an "smb_hash" as a password type.
Also, the fixes in #2583 do not appear to address anything else reported
on the Redmine issue, namely, operating system and architecture
identification discovered with this module (assuming good credentials).
Therefore, the Redmine issue should not be considered resolved.
[SeeRM #4398]