SSH Tunneling: a gate to freedom and a threat Andrei Hodorog, DefCamp 2014
This presentation is a proof of concept and is intended for educational purposes only!
Do not proceed pentesting your corporate network without authorisation!
Apart from the annoyances, there are beneficial aspects of the restrictions (if you are a newbie, some of them are really for your security and the safety of the wider organisation).
You can get fired or expelled if caught!
Disclaimer 11/29/2014
Andrei Hodorog, DefCamp 2014
2
Second year student @ Cardiff University (Computer Science with Security and Forensics)
Security enthusiast
Freelancer web developer
Cisco CCNA Certified (I also have a passion for networks!)
Who am I? 11/29/2014
Andrei Hodorog, DefCamp 2014
3
Restrictions in a big UK institution 11/29/2014
Andrei Hodorog, DefCamp 2014
4
The annoying message 11/29/2014
Andrei Hodorog, DefCamp 2014
5
Live HTTP header analysis - not using a blacklist, but blocking all non-HTTPs websites containing words such as “proxy”, “hack”, “bypass”, “torrent”, etc.; Blocking even legitimate hosts (e.g.: the BitDefender website and the BitDefender update server); Blocking short URLs (marked as SPAM); Blocking all the network user ports (above 1024); Routers having VPN passthrough disabled; ◦ Cannot connect to VPNs or TOR
Restricting DNS access to their DNS server ◦ Unable to use OpenDNS or any other alternatives;
Without their DNS server, can’t even ping 8.8.8.8 ◦ DNS tunneling not working.
Tight firewall and tight policy 11/29/2014
Andrei Hodorog, DefCamp 2014
6
3G / 4G connection tethering - not reliable: Drains phone battery (~1% / min) – if not using USB tethering; For some providers, cannot receive calls during the data connection; Providers generally detect and block tethering, unless stated otherwise in the contract; Sometimes need to use ClockworkMod Tether – very slow; The need for an unlimited plan; Limited to 71.8 Mbps for 4G in the best scenario – Why if you have a FREE 1Gbps connection provided by the institution?
The most popular bypass method 11/29/2014
Andrei Hodorog, DefCamp 2014
7
ForceBindIP – old tool (last version released in 2009), not supported anymore, but still working; http://www.softpedia.com/get/System/System-Miscellaneous/ForceBindIP.shtml
ForceBindIP {4FA65F75-7A5F-4BCA-A3A2-59824B2F5CA0} c:\path\to\app.exe OR
ForceBindIP 1.2.3.4 c:\path\to\app.exe
This way, you could force blocked applications to access the tethered connection, but not reliable either: Need to add the command to the path of each application; Need to always have the tethered connection active.
Another try – two connections 11/29/2014
Andrei Hodorog, DefCamp 2014
8
80 (HTTP); 443 (HTTPS – secure HTTP); 20 & 21 (FTP); 22 (SFTP – secure FTP and SSH).
They had to allow connections through SFTP in order to allow the users to securely upload / download files remotely to / from the work server.
Ports open 11/29/2014
Andrei Hodorog, DefCamp 2014
9
All the magic is done through port 22, which can be used to establish an SSH (Secure Shell) connection. In plain terms, a secure connection to a server where you have a shell account.
The little “gate” 11/29/2014
Andrei Hodorog, DefCamp 2014
10
Tunneling all the traffic through that secure connection in order not to be detected by the firewall.
The basic concept: SSH tunneling 11/29/2014
Andrei Hodorog, DefCamp 2014
11
The connection can be established through any SSH client, including the popular Putty. Then you have to emulate a SOCKS proxy through which you will tunnel all the traffic.
Linux: ssh -D 9999
[email protected]
The configuration 11/29/2014
Andrei Hodorog, DefCamp 2014
12
Then you only need to configure the SOCKs connection in your applications!
You should also configure your browser to resolve all the DNS requests through the proxy!
The configuration
11/29/2014
Andrei Hodorog, DefCamp 2014
13
Use a software such as Proxifier (www.proxifier.com) for applications that don’t support SOCKs connections (e.g.: TeamViewer, Winamp).
Linux: Proxychains (proxychains.sourceforge.net): bash$ proxychains firefox localhost:9999
The configuration 11/29/2014
Andrei Hodorog, DefCamp 2014
14
You should leave the legitimate traffic untouched in order not to raise suspicions)… The network admins will think something is wrong if they only see encrypted traffic coming from your host. Use FoxyProxy (available for both FireFox and Chrome): getfoxyproxy.org
The automation 11/29/2014
Andrei Hodorog, DefCamp 2014
15
Setup rules based on the web URLs patterns (e.g.: all the addresses containing “torrent”, “hack”, etc.) – useful for Google and YouTube search queries.
Add websites automatically to the “whitelist” (list with tunneled addresses) based on a certain content pattern (e.g. A text fragment like “This website is blocked in accordance with the institution policy”, “torrent”, “hack”, etc.).
When you access a blocked website matching a pattern, it automatically refreshes through the tunnel.
Setup “blacklists” (maybe you never want to tunnel Facebook, email, online banking, PayPal, unless you really trust your server – remember the HeartBleed bug!).
What you can do with FoxyProxy? 11/29/2014
Andrei Hodorog, DefCamp 2014
16
Encrypting the traffic in a public WiFi network: by default, all the non-HTTPs traffic is unencrypted and can be sniffed!
Bypassing geolocation restrictions of certain websites (e.g.: BBC iPlayer, Hulu, YouTube, Netflix). An additional layer of protection for your real IP address when using VPN or anonymity services (e.g.: Tor).
Other uses of this method 11/29/2014
Andrei Hodorog, DefCamp 2014
17
Most reliable – set up your own server or buy a VPS or dedicated package; Cheapest and almost as much reliable - shared hosting – some providers:
You will probably need to contact support and ask them to enable it – provide a valid reason (a little social engineering involved ): “I need to practice MySQL commands on CLI for my work.” “I need to run live Python and Ruby on Rails scripts on REPL.” These are big companies – have better things to do than monitoring you!
Getting an SSH account 11/29/2014
Andrei Hodorog, DefCamp 2014
18
You can check for yourself if it’s already enabled by default! Just try to establish a SSH connection to your shared IP address with your cPanel credentials! Some webhosts allow connecting only through stored RSA keys (passwordless login). You can generate your own key using PuTTYgen and add it in the allow list in cPanel:
You can either generate a new key and use it with your SSH client or import an already generated key using, for example, PuTTYgen.
Getting an SSH account 11/29/2014
Andrei Hodorog, DefCamp 2014
19
Jailbroken iPad with OpenSSH installed at home – low electricity consumption; Gigabit connection; gigabit router – connected through Thunderbolt to Ethernet adapter!
Might need to configure port 22 forwarding on your router: www.portforward.com – Guidance for any model!
My option
11/29/2014
Andrei Hodorog, DefCamp 2014
20
All traffic – RSA encrypted Even if they see suspicious traffic coming from your IP address / account, simply say that you connected to your home machine to download large files – nobody can prove anything – unless they have NSA like folks in the IT department that can intercept your keys and sniff your traffic. SSH connections perfectly legal if the port is open and not stated in the organisation policy otherwise! What goes through the tunnel – your business, not their ;)
Getting caught?
11/29/2014
Andrei Hodorog, DefCamp 2014
21
Users accessing illegitimate websites (SSH tunneling is the most popular method to bypass WebSense) and use illegitimate applications against your policy;
Users can tunnel any TCP-based protocol, including P2P and squeeze your bandwidth;
A rootkitted host can attempt to covertly connect to the outside world.
Risks posed to your organisation 11/29/2014
Andrei Hodorog, DefCamp 2014
22
The general solution to avoid your network users to do this is to either disable port 22 completely or only allow connections to the hosts in your Local Area Network or a whitelist of trusted IP addresses or hosts.
…but this way you only make the work harder, as an SSH connection can be established through any port, including 80!
Partial solutions: ◦ Deep Packet Inspection – if packet payload is SSH and not in the whitelist – drop it ; ◦ Only allow inbound traffic (especially on ports 80 and 443) and allow outbound traffic only to trusted IP addresses.
Avoiding this in your organisation 11/29/2014
Andrei Hodorog, DefCamp 2014
23
There's no way for a firewall to determine if HTTP (or any other protocol) is being tunnelled over SSH, as SSH is encrypted against eavesdropping, which will also impact your ability to do protocol inspection.
Short version: you can't inspect SSH payloads.
The protocol is designed to prevent man in the middle. You can tell that the protocol is SSH easily enough by network inspection, but not that it is being used to tunnel something else.
The general remaining problem 11/29/2014
Andrei Hodorog, DefCamp 2014
24
By default, sshd allow to forward TCP sessions to any ports. You can restrict them to specific hosts and/or ports via the PermitOpen parameter (available since release 4.4):
PermitOpen host:port PermitOpen IPv4_addr:port PermitOpen [IPv6_addr]:port
It can also be useful to restrict who can use the port forwarding:
Simple rules:
Allow specific port per groups:
AllowTcpForwarding no Match User john,andy,ted AllowTcpForwarding yes
AllowTcpForwarding no Match Group admins AllowTcpForwarding yes PermitOpen 192.168.0.1:443
If you have your corporate SSH server running OpenSSH 11/29/2014
Andrei Hodorog, DefCamp 2014
25
By default, the SSH daemon does not log the sessions established via a tunnel.
To show them, you need to run the sshd in debug mode (-d).
This is not acceptable in an operational environment because of the large overhead.
Logging 11/29/2014
Andrei Hodorog, DefCamp 2014
26
Here is a quick patch to log all outgoing sessions initiated by the sshd with a mapping to the UID (UserID). In serverloop.c, patch the function server_request_direct_tcpip() like this: 915,918d914 < // BEGIN PATCH TunnelLogging < uid_t who; < // END PATCH < 925,930c921,922 < // BEGIN PATCH TunnelLogging < // debug("server_request_direct_tcpip: originator %s port %d, target %s port %d", < who = getuid(); < logit("Tunnel: %s:%d -> %s:%d UID(%d)", < originator, originator_port, target, target_port, who); < // END PATCH --> debug("server_request_direct_tcpip: originator %s port %d, target %s port %d", > originator, originator_port, target, target_port);
Logging 11/29/2014
Andrei Hodorog, DefCamp 2014
27
For each new TCP session, the following line will be sent to Syslog:
Feb 27 08:03:08 honey sshd[9060]: Tunnel: 127.0.0.1:51209 -> 0.channel26.facebook.com:80 UID(2349).
The patch will allow to correlate who connected and from which IP address.
Logging 11/29/2014
Andrei Hodorog, DefCamp 2014
28
If you run an external SSH server that your users need to log into, disable SSH forwarding with the AllowTcpForwarding option in sshd_config.
Watch your traffic. See how much traffic various protocols use on your network. This will not only help you catch SSH tunnels, it will help you catch any other sort of tunnel.
You could forbid external SSH, and only permit protocols that can be proxies, such as Telnet.
You can set up a legitimate SOCKS server, with logging, and require all traffic pass through it. Anyone tunneling large amounts of traffic through the server will stand out in the logs.
Summary 11/29/2014
Andrei Hodorog, DefCamp 2014
29
Thank you for your attention!
Questions?
[email protected] http://uk.linkedin.com/in/hodorogandrei
11/29/2014
Andrei Hodorog, DefCamp 2014
30
