STOP_ON_SUCCESS is always true

[wchen-r7]

Based on the following report from @francesco1119, it sounds like there is a bug in the handling of the STOP_ON_SUCCESS option.

Original report:

Hi,

I was testing your module, the option: STOP_ON_SUCCESS could be set on "true" or "false" but always stop when a credential works.

it's not a big issue but STOP_ON_SUCCESS is always working as "true"

[void-in]

@wchen-r7 The title should be changed to STOP_ON_SUCCESS is always true regardless of the module selected.

[wchen-r7]

Really? But this should kick in: https://github.com/rapid7/metasploit-framework/blob/e749733eb6118a4b089e288fc81050f76c8db5ed/lib/metasploit/framework/login_scanner/base.rb#L223

[wchen-r7]

Joomla module is checking stop_on_success too: https://github.com/rapid7/metasploit-framework/blob/4762e9f62c6fb3bb322a7fe33b283edf3ee6afec/modules/auxiliary/scanner/http/joomla_bruteforce_login.rb#L146

Weird.

[kernelsmith]

This isn't related to the bug report but shouldn't the break if be after the cred is added to the success array (next line down)? Or, is that array ignored when stop_on_success is true because it's not needed anymore?

[void-in]

@wchen-r7 I checked the modules/auxiliary/scanner/vmware/vmauthd_login module and was always stopping after successful creds no matter what the STOP_ON_SUCCESS value is. I even commented the line:

break if :stop_on_success

but the behavior was the same. The only other place where stop_on_success is checked is in the auth_brute lib but couldn't find anything obvious.

[wchen-r7]

Yeesh. Maybe that option isn't being passed properly at all for some reason. Ok I'll double check, thanks!

[void-in]

@kernelsmith You are right. That break statement looks odd because it should break once the line:

successful_users << credential.public

is executed. I think the reason it is working fine with all the modules is because each module implements its own scan! method (method overriding in ruby?). But it should be corrected in the base as well. @wchen-r7 your thoughts?

[wchen-r7]

@void-in I just double checked and there are currently no login scanner modules that override scan! except for snmp. They only need to implement their own attempt_login method.

[void-in]

@wchen-r7 Ah my bad. I didn't check before commenting. Then how is the successful_users getting populated with stop_on_success breaking before it?

[wchen-r7]

@void-in Haha well, by looking at the code of base.rb, that just doesn't look like it's possible. In fact, by just looking at code, I'm rather baffled by this problem. I will need to invest some time on actually playing with the module and see this for myself.

[wchen-r7]

@void-in Ok so, I just tested vmauthd_login and here's my outputs:

When stop_on_success is false:

msf auxiliary(vmauthd_login) > set stop_on_success false
stop_on_success => false
msf auxiliary(vmauthd_login) > run

[*] 192.168.1.78:902 VMAUTHD - Starting bruteforce
[+] 192.168.1.78:902 VMAUTHD - Success: 'sinn3r:goodpassword' '230 User sinn3r logged in.  '
[-] 192.168.1.78:902 VMAUTHD - Failed: 'connect:connect' 530 Login incorrect.
[-] 192.168.1.78:902 VMAUTHD - Failed: 'sitecom:sitecom' 530 Login incorrect.
[-] 192.168.1.78:902 VMAUTHD - Failed: 'admin:1234' 530 Login incorrect.
^C[*] Caught interrupt from the console...
[*] Auxiliary module execution completed
msf auxiliary(vmauthd_login) > 

When stop_on_success is true:

msf auxiliary(vmauthd_login) > set stop_on_success true
stop_on_success => true
msf auxiliary(vmauthd_login) > run

[*] 192.168.1.78:902 VMAUTHD - Starting bruteforce
[+] 192.168.1.78:902 VMAUTHD - Success: 'sinn3r:goodpassword' '230 User sinn3r logged in.  '
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(vmauthd_login) > 

As you can see, it's functioning properly. When stop_on_success is true, it stops. When stop_on_success is false, it keeps going.

However, after trying I think the only explanation I have is maybe the VERBOSE option has confused you. When VERBOSE is false, the module will only print successful logins (for this one, there is only one), and if you don't have a lot of creds to try, it will soon terminate, so that kind of makes it fee like it's not trying more credentials. If you set VERBOSE to true, you should see more login attempts.

Many newer login modules behave this way. We did it this way because of past pentester feedback (when they try a lot of passwords, they only care about the good ones. They don't want to see the screen filled with unsuccessful messages because that's not interesting)

Please let me know if this is the case for you :-)

[void-in]

@wchen-r7 Well I can't say it for sure but it is true that vmauth_login module is behaving properly for me now. The case you described above is the only explanation.

Sorry for letting you open a separate issue for this one. But the positive thing is @kernelsmith spotted a potential bug during the course of our investigation so it's a win win :) I think we can close this issue if you agree.

[wchen-r7]

@void-in Yeah the bug @kernelsmith found is real.

I'll go ahead and close this issue, thanks for testing!

[kernelsmith]