search

rapid7 / metasploit-framework

Metasploit Framework
https://www.metasploit.com/
Other
34.14k stars 13.97k forks source link

RHOST and RHOSTS #9724

Closed sky305 closed 6 years ago

sky305 commented 6 years ago

Hi, I'm working with https://github.com/NullArray/AutoSploit/ ..

They set RHOSTS by default for a host, in my experience it does not work with most modules as it is not a range of IPs, I have recommended to set the variables for RHOST and RHOSTS to the same address, that way whichever module uses either would work. Am I correct here? Is there any documentation on this ?

busterb commented 6 years ago

Hi, there is a PR that addresses this issue in #9246, making RHOSTS the preferred way to do it with all modules. Can you give it a try and see how it works for you? More eyes are definitely appreciated.

Ekultek commented 6 years ago

@busterb so there are no docs for metasploit that indicate which method should be called by a thridparty application? What if the thirdparty is using msfrpc?

wvu commented 6 years ago

It's always been RHOST for exploits and RHOSTS for scanners (exceptions notwithstanding). It's only recently as of #9246 that we've experimented with globally supporting RHOSTS beyond writing a resource script. Setting both is usually not a problem, but only one will be used presently. Hope this helps.

busterb commented 6 years ago

Currently, for 'exploit' modules, you need to set RHOST and set it to one IP address. For all other modules, set 'RHOSTS' instead, and you can specify a range, subnet, or file. When #9724 lands the same code will work transparently.

Earlier discussion: https://github.com/rapid7/metasploit-framework/issues/7614

Ekultek commented 6 years ago

@wvu-r7 so if I set RHOST 127.0.0.1 RHOSTS 127.0.0.1 via CMD are they called in order received or by relevance to the module?

wvu commented 6 years ago

They aren't called in order because the architecture dictates modules use one or the other. If it's an exploit, RHOST is used. If it's a scanner, RHOSTS is used. If you're seeing any shells now, it's because some scanners can pop shells. You'll actually get a warning in the console now when you set the wrong option.

wvu commented 6 years ago

Setting RHOST for a scanner:

msf5 > use auxiliary/scanner/ssh/ssh_login
msf5 auxiliary(scanner/ssh/ssh_login) > set rhost 127.0.0.1
[!] RHOST is not a valid option for this module. Did you mean RHOSTS?
rhost => 127.0.0.1
msf5 auxiliary(scanner/ssh/ssh_login) > run
[-] Auxiliary failed: Msf::OptionValidateError The following options failed to validate: RHOSTS.
msf5 auxiliary(scanner/ssh/ssh_login) >

Setting RHOSTS for an exploit (soon to be supported):

msf5 > use exploit/windows/smb/ms17_010_eternalblue
msf5 exploit(windows/smb/ms17_010_eternalblue) > set rhosts 127.0.0.1
rhosts => 127.0.0.1
msf5 exploit(windows/smb/ms17_010_eternalblue) > run

[-] Exploit failed: The following options failed to validate: RHOST.
[*] Exploit completed, but no session was created.
msf5 exploit(windows/smb/ms17_010_eternalblue) >

For exploits, this isn't so much a warning as an option validation error.

Ekultek commented 6 years ago

@wvu-r7 awesome thanks man, much appreciated

wvu commented 6 years ago

And to actually answer your question, I'm afraid there's no solid documentation on this, since Metasploit was architected around single-host exploits from the very beginning. It's sort of become de facto. We're hoping to change that. :)

Ekultek commented 6 years ago

It’s all good, you’ve defiantly answered my question I very much appreciate your time

wvu commented 6 years ago

No problem. Thanks for the question! Feel free to test #9246 as time goes on. Closing this now.

wvu commented 6 years ago

Here are the positive test cases showing you can set both (don't mind the errors):

msf5 > use auxiliary/scanner/ssh/ssh_login
msf5 auxiliary(scanner/ssh/ssh_login) > set rhost 127.0.0.1
[!] RHOST is not a valid option for this module. Did you mean RHOSTS?
rhost => 127.0.0.1
msf5 auxiliary(scanner/ssh/ssh_login) > set rhosts 127.0.0.1
rhosts => 127.0.0.1
msf5 auxiliary(scanner/ssh/ssh_login) > run

[*] Error: 127.0.0.1: Metasploit::Framework::LoginScanner::Invalid Cred details can't be blank, Cred details can't be blank (Metasploit::Framework::LoginScanner::SSH)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/ssh/ssh_login) >
msf5 > use exploit/windows/smb/ms17_010_eternalblue
msf5 exploit(windows/smb/ms17_010_eternalblue) > set rhost 127.0.0.1
rhost => 127.0.0.1
msf5 exploit(windows/smb/ms17_010_eternalblue) > set rhosts 127.0.0.1
rhosts => 127.0.0.1
msf5 exploit(windows/smb/ms17_010_eternalblue) > run

[!] You are binding to a loopback address by setting LHOST to 127.0.0.1. Did you want ReverseListenerBindAddress?
[*] Started reverse TCP handler on 127.0.0.1:4444
[*] 127.0.0.1:445 - Connecting to target for exploitation.
[-] 127.0.0.1:445 - Rex::ConnectionRefused: The connection was refused by the remote host (127.0.0.1:445).
[*] Exploit completed, but no session was created.

The modules do run.

wvu commented 6 years ago

And FWIW, the run command can specify options, too:

msf5 > use auxiliary/scanner/smb/smb_login
msf5 auxiliary(scanner/smb/smb_login) > run -o RHOST=192.168.212.129,RHOSTS=192.168.212.129,SMBUser=msfadmin,SMBPass=msfadmin

[*] 192.168.212.129:445   - 192.168.212.129:445 - Starting SMB login bruteforce
[*] 192.168.212.129:445   - 192.168.212.129:445 - This system does not accept authentication with any credentials, proceeding with brute force
[+] 192.168.212.129:445   - 192.168.212.129:445 - Success: '.\msfadmin:msfadmin' Administrator
[*] 192.168.212.129:445   - 192.168.212.129:445 - Domain is ignored for user msfadmin
[*] 192.168.212.129:445   - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/smb/smb_login) >

No need to run set, but you'll need to run use.

Ekultek commented 6 years ago

@wvu-r7 thank you for the help!

wvu commented 6 years ago

@Ekultek: No problem! I'm glad it worked. :)

punammore commented 4 years ago

how to solve this error Started reverse TCP handler on 192.168.43.124:4444 [-] 192.168.43.124:135 - Exploit failed [unreachable]: Rex::ConnectionRefused The connection was refused by the remote host (192.168.43.124:135). [*] Exploit completed, but no session was created.

bcoles commented 4 years ago

how to solve this error Started reverse TCP handler on 192.168.43.124:4444 [-] 192.168.43.124:135 - Exploit failed [unreachable]: Rex::ConnectionRefused The connection was refused by the remote host (192.168.43.124:135). [*] Exploit completed, but no session was created.

The connection was refused by the remote host means the connection was refused. Ensure that port 135 is open on 192.168.43.124.