This incidentally also allows for a custom collector to be implemented
by the user -- for example, if they'd rather pick up a session ID or
inject a browser hook or something along those lines. It's a little
clunky, using the advanced option of CUSTOM_JS, but it seems to work
fine.
Variable on line 67 needs to be changed to "user" from "username" which was undefined and causing error during exploit execution.
[-] Exploit failed: NameError undefined local variable or method `username' for #<Msf::Modules::Mod6578706c6f69742f756e69782f7765626170702f77705f736c69646573686f7767616c6c6572795f75706c6f6164::MetasploitModule:0x0055c61ab093f8>
After changing the incorrect variable name from "username" to "user", the exploit completes.
A few things were changed as per the PR comments:
1) The module title was reworded
2) The module description was multi-lined
3) Negative logic was rewritten to use 'unless'
4) Strings which did not require interpolation were rewritten
5) Documentation markdown was added.
Instead of an alert() (which the attacker won't see), this collects the
offered credentials in a POST action, and displays them in the console.
This should further store the creds somewhere handy, but this is good
enough for now for testing from @RootUp
"ua-parser-js" is an npm module for parsing browser
user-agent strings. Vulnerable version of this module
have a problematic regular expression that can be exploited
to cause the entire application processing thread to "pause"
as it tries to apply the regular expression to the input.
This is problematic for single-threaded application environments
such as nodejs. The end result is a denial of service
condition for vulnerable applications, where no further
requests can be processed.
Tod Beardsley