[RedBlock]

It works! The poc i referenced above and edit request data to ../../../etc/passwd and file is returned!

Are you sure that it is not your's /etc/passwd?

Lmao ? ? ?

[test030]

It works! The poc i referenced above and edit request data to ../../../etc/passwd and file is returned!

Can you paste the script with /etc/passwd

[llamamorg]

This definitely seems like we need to combine the two PoCs. Been trying to adapt the websocket connection from the Include Security post (HyperReality) with the SSRF PoC (Chebuya). Kudos to both box creators tho, this one has had me debugging my crappy python for a while now. haha

[Donde]

Chaining the two exploits still seems like the most likely way. The first exploit opens us a socket and allows us to send/read from the socket. We also know that 40056 is the websocket port to talk to havoc and that it has been modified to not use TLS, meaning we can send plain data to talk to it.

The second poc shows how using a websocket api we can use a auth'd user to get RCE in 2 commands.

The challenge is in modifying the first CVE to not just send a GET request, but instead to upgrade the socket to a websocket and then send the data from the second cve to get RCE.

Sadly we can't use any websocket libraries for this but have to craft the requests manually.

[bedtimexv]

root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
ntp:x:123:123:ntp:/var/run/ntp:/bin/false
dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false
logd:x:514:514:logd:/var/run/logd:/bin/false
ubus:x:81:81:ubus:/var/run/ubus:/bin/false
netadmin:x:999:999::/home/netadmin:/bin/false

[test030]

1027355[/url]' dateline='1737236068']
root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
ntp:x:123:123:ntp:/var/run/ntp:/bin/false
dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false
logd:x:514:514:logd:/var/run/logd:/bin/false
ubus:x:81:81:ubus:/var/run/ubus:/bin/false
netadmin:x:999:999::/home/netadmin:/bin/false

Should I paste ../../../etc/passwd instead of vulnerable

[ZenMunk3y]

Chaining the two exploits still seems like the most likely way. The first exploit opens us a socket and allows us to send/read from the socket. We also know that 40056 is the websocket port to talk to havoc and that it has been modified to not use TLS, meaning we can send plain data to talk to it.

The second poc shows how using a websocket api we can use a auth'd user to get RCE in 2 commands.

The challenge is in modifying the first CVE to not just send a GET request, but instead to upgrade the socket to a websocket and then send the data from the second cve to get RCE.

Sadly we can't use any websocket libraries for this but have to craft the requests manually.

why can't you use the websocket libraries?

[thedubb1313]

i think that /etc/passwd is from wifinetic, i call bs

Just google the last line netadmin....

[Donde]

Chaining the two exploits still seems like the most likely way. The first exploit opens us a socket and allows us to send/read from the socket. We also know that 40056 is the websocket port to talk to havoc and that it has been modified to not use TLS, meaning we can send plain data to talk to it.

The second poc shows how using a websocket api we can use a auth'd user to get RCE in 2 commands.

The challenge is in modifying the first CVE to not just send a GET request, but instead to upgrade the socket to a websocket and then send the data from the second cve to get RCE.

Sadly we can't use any websocket libraries for this but have to craft the requests manually.

why can't you use the websocket libraries?

Port 40056 is only open locally on the machine. You need to use the first SSRF exploit to access the service behind that port. This forces us to use the socket connection that the SSRF Exploit opens for us. It should be as easy as upgrading the socket to a websocket and sending the login json/rce json from the second exploit, but for some reason the service does not respond the way I want it to to my websocket handshake.

[ahmedmsehli216]

1 w4nt 2 sw1tch 2 h4rd h4t c2

https://github.com/DragoQCC/HardHatC2

PORT    STATE    SERVICE REASON              
7096/tcp filtered unknown port-unreach

somehow this is some unintended way ?