When something fails, the target is given a hardcoded 404 message
generated by the framework. But the user (attacker) now can configure
this. When the Custom404 option is set, the mixin will actually
redirect (302) to that URL.
There are several scenarios that can trigger a 404 by BES (custom or
default):
* When the browser doesn't allow javascript
* When the browser directly visits the exploit URL, which is forbidden.
If this actually happens, it probably means the attacker gave the
wrong URL.
* The attacker doesn't allow the browser auto-recovery to retry the
URL.
* If some browser requirements aren't met.
* The browser attempts to go to access a resource not set up by the
mixin.
This should fix up #4642 with respect to #4504.
Squashed commit of the following:
commit 124d53ccb00cd200bede092e893dda7e033d3e17
Merge: cb2bef8 ccad159
Author: Tod Beardsley <tod_beardsley@rapid7.com>
Date: Mon Jan 26 16:23:03 2015 -0600
Merge branch 'feature/creds-blank-finders' into temp
commit ccad159222eaa949d76e22b588d1ac7709fb2f27
Author: Tod Beardsley <tod_beardsley@rapid7.com>
Date: Mon Jan 26 15:58:02 2015 -0600
Clean out whitespace, make vars more meaningful
commit 266b45dff26e2778e43d8e4750d212b5aee5a009
Author: Tod Beardsley <tod_beardsley@rapid7.com>
Date: Mon Jan 26 15:54:32 2015 -0600
Add some specs for regular users and blank users
commit 2e51503f76e9a2f6921c57e86a2f98527f80c874
Author: Tod Beardsley <tod_beardsley@rapid7.com>
Date: Mon Jan 26 15:04:03 2015 -0600
Users should be able to find blank user/pass
jvazquez-r7
sinn3r
William Vu
Tod Beardsley
Jonathan Claudius
Jon Hart