DNS Tunneling Part 4: Honorable mention

DNS Tunneling has been around since at least 2005. At least that's when I first heard about it. In the last 5 years, there have been many tools written to leverage this infrastructure vulnerability. The ones I touched on are but a few. I wanted the ability to demonstrate a working SSH tunnel via DNS, from all major operating systems. To that end, I couldn't find any one tool that worked great on all my favorites. For example: OzymanDNS won't run on OpenBSD without completely re-compiling perl in an arguably insecure configuration. It just so happens that dns2tcp works on pretty much everything except for Windows. Still, there are others out there that might be worth looking at. Here are a few:

Heyoka is a Windows-only tool, supposedly with some interesting stealth technology. The binary is both the server and the client, and it can tunnel any TCP connection to localhost (a listening VNC, RDP, Squid, or COPSSH server, for example). I tested it without using any of its advanced features, and it works. I used WinXP home in my lab as the server, and Windows 7 on my Macbook as the client. I had to spawn an administrator command shell on Win7 to get it to run. YMMV.

DNSCat is a nifty, minimal tool that acts kind of like netcat, only over DNS. For some reason, I couldn't get OS X to play nicely with it, despite the fact that it looked like it wanted to work. Also, the "server" would occasionally bail out to to the shell again, so I often found myself wrapping it in a "while true" one-liner shell script loop on the server end. Using the client on OpenBSD seemed to work great, as seen in this screen shot I took. The "server" activity is in the window on the right. Ron gets props for some other fun stuff, too, such as weaponizing DNScat as a metasploit framework payload. This tool, combined with netcat or stunnel, could prove to be quite flexible, I think.

I didn't get to play with NSTX, but it looks like a linux-only affair. I don't run Linux on my laptop, so it'd have been difficult to test in the field.

Have any others you've used with good results?

DNS Tunneling Series:
Part 1: Intro and Nameserver setup
Part 2: Windows Clients (using ozymandns)
Part 3: Linux, BSD and Mac OS X clients (using DNS2TCP)

Part 4: Honorable mention

Reverse SSH Tunnel Watchdog

We've covered tunneling before on HiR. I even wrote a little about reverse tunneling in my quick-and-dirty tunneling howto. This time, I'm building a setup to make an always-on reverse tunnel with a cron-powered watchdog script. I've even coded a cron watchdog before, but this way is less hackish, in my opinion.

Here's what's needed to make it work:

• A Linux/BSD/Unix system on the inside of your target network that's capable of SSH-ing out to the Internet (even if via strange ports)
  
• An SSH server you control on the Internet. This can be at home, or elsewhere

The reverse tunnel can handle pretty much any protocol. To a squid proxy, for example. I'll be using SSH to reverse-tunnel SSH, though, to allow SSH access to a server behind a firewall that I do not control. Here's how it'll work:

Cron will run a script on the server on the inside. This script will check to see if the SSH tunnel is working properly. If it's not (or if it hasn't been started yet), it will start the reverse tunnel.

Here's the script, which I put in /usr/local/bin/rtunnel.sh. Obviously, you need to edit the first 4 variables to reflect your environment.

#!/bin/sh
USERHOST=axon@somewhere.labs.h-i-r.net # Login and External system
RPORT=22 # SSH Listener port on your external system
FPORT=1337 # Port that will be opened locally to tunnel SSH
CONN=localhost:22   # SSH Listener on the system behind the firewall

COMMAND="ssh -q -N -R $FPORT:$CONN $USERHOST -p $RPORT"
pgrep -f -x "$COMMAND" > /dev/null 2>&1 || $COMMAND
ssh $USERHOST -p $RPORT netstat -an | egrep \
"tcp.*:$FPORT.*LISTEN">/dev/null 2>&1
if [ $? -ne 0 ] ; then
pkill -f -x "$COMMAND"
$COMMAND
fi

The above essentially runs this as the command line:

ssh -q -N -R 1337:localhost:22 axon@somewhere.labs.h-i-r.net -p 22

Then uses pgrep (ps command with grep functionality) to see if it's up and running, and tries to ssh to the outside system, using netstat to check the status on that end. If either of those fail, the process is killed with pkill (pgrep, with kill functionality) and restarted.

And then I put the entry in root's crontab, to run every 5 minutes:

*/5     *       *       *       *       /usr/local/bin/rtunnel.sh

In my implementation, the firewalled host (An OpenBSD box) is connecting to a Ubuntu desktop system at my home. I can just log into it, then use the tunnel on port 1337, using the -p [port] option.

axon@somewhere:~$ ssh localhost -p 1337
axon@localhost's password:
Last login: Sat Nov 14 00:01:04 2009 from localhost.labs.h-i-r.net
OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

-bash-3.2$

If the connection times out or fails for any other reason, the remote end should re-spawn the connection in the next 5 minutes. If you've waited, and don't get a response, something else might be amiss. DNS rules, a network admin that's blocked you, etc... You can try switching the port SSH runs on

The one problem I've had is that occasionally the session will be alive, the port will be forwarded, but I can't get it to log in. It just hangs then times out. If this happens, I use lsof on my workstation to find and kill off the process that's listening on the TCP port I am using for forwarding.

axon@somewhere:~$ sudo lsof -n | grep TCP.*:1337
sshd   20386   axon    9u   IPv6    2862057  TCP [::1]:1337 (LISTEN)
sshd   20386   axon   10u   IPv4    2862058  TCP 127.0.0.1:1337 (LISTEN)
axon@somewhere:~$ kill 20386

Of course, you can also tunnel stuff over this reverse tunnel. The possibilities are endless!

Defense: Sidejacking, subversive wireless

Karmetasploit is a fun little toy, and I think I've got it working well -- and then some. The details of that project will be revealed later this week, hopefully. Let's just say that with a La Fonera router and a laptop, I found a way to leverage metasploit (and a few other fun tools) into a very powerful subversive wireless setup.

It's pretty much a running gag. If you see Surbo from i-Hacked in the room (and sometimes even if you don't), you shouldn't bother powering on any of your wireless toys. He almost certainly has an eeePC hiding somewhere ready to rope you into his rogue wireless network and has metasploit armed and ready to steal your session IDs.

Sidejacking happens when you allow a session-id cookie to go across the wire in the clear. A third-party gets the session ID cookie (using metasploit, hamster & ferret, Wifizoo or other tools like them) and then proceeds to import the cookie into their browser, whereupon they have access to the account the session-id belongs to.

Usually, these exploits happen due to sniffing (open Wifi, wired ethernet to a hub, ARP poisoning, Arp table flooding) but the other way they occur is through subversive wireless, I.e. Karma.

In a nutshell, Karma listens for probe requests from wireless clients and immediately begins broadcasting that SSID. It effectively ropes all new wireless clients in who aren't already associated to an existing network. When you combine Karma and Metasploit together, you end up with a rogue Access point that has the following traits:

• Will associate to any SSID
• Assigns a default route to the address Metasploit is listening on.
• Runs a fake DNS server that points all domain names to the Metasploit IP
• Launches several fake servers to gather passwords, cookies and other authentication information
• In the case of Karmetasploit, it launches a page with many iframes so it gathers cookies for an entire list of popular sites.
  

So, when Thunderbird or Outlook try to connect to mail.yourcompany.com, they end up going to Metasploit. And when they hand off your username and password, Metasploit logs it in the database. Same thing goes for your cookies.

While showing a team-mate of mine how easy and devastating these tools are, we started coming up with ways to defend ourselves. Most are pretty obvious.

• Set your browser to clear the cache, any saved passwords and all cookies every time you close it.
• Always close all of your browser windows (and thus, get rid of all cookies and passwords) before closing the lid to your laptop or going out and about with your mobile device.
  
• If possible, make sure your wireless adapter is not configured to automatically join wireless networks.
• If you normally connect to an encrypted wireless network, but see one with the same name that's not encrypted, it may (or may not) be a rogue access point.
• While out-and-about, it may be wise to tunnel sensitive traffic, or just wait until you get to a trusted network in order to conduct your business affairs.
  
• Use sites that utilize SSL for everything, and be very, very cautious of tools such as SSLStrip.
  

Keep in mind a few other things:

• Anyone can set up an open wireless hotspot and sniff the traffic from it.
• The ubiquity of WiFi makes rogue hotspots easy to hide. It's not hard to make it look like it belongs to the hotel or coffee shop next door.
• Some of the most dangerous access points show no sign of being rigged. You can get online, do your stuff, and leave without knowing someone was watching.

I'll post a bit more about my latest adventures from the attack side of things later this week.

Reverse Tunnel with SSH

Inspired by a thread on the Hak5 Forums...

Sometimes, you might find yourself wishing you could poke arbitrary holes through a NAT or firewall. The potential uses (both good and evil) are nearly limitless. Perhaps you want to be able to log in to the computer in your dorm room while you're a thousand miles away on vacation with family.

You will need a few things before we start:

1. Physical access to a computer on the "inside" of the network
2. Access and permission to install software on that computer
3. A system on the "outside" that can accept SSH connections from the Internet

It helps if the 2 computers involved are running Linux, Mac OS X, BSD or some UNIX variant, but you could probably use PuTTy on Windows for the "inside" computer in a pinch.

I'll be using NetBSD on my SparcStation 20 on the inside of the HiR Lab, and one of my web servers with a public IP address on the outside.

SSH Tunneling is the process of encapsulating some other protocol within an SSH session. There are many advantages to this. Essentially, if you can get out of a network with SSH, you can get to almost any TCP service on the outside world, even if it's blocked.

Reverse SSH Tunneling is a similar process. If you can get out of the network with SSH, you can use that SSH tunnel to spawn a listening process on the outside of the network, from which you can get to anything internal.

Step One: Deploy SSH keys without a password
This has to be done from the "inside" computer. You can use your personal desktop system or a server where you have an account. It must be able to SSH out to the Internet.

I don't like to use public keys without passwords, but they do come in handy, particularly for tunneling. The un-protected public key should only be placed into the authorized keys list for UN-TRUSTED accounts that aren't in the wheel group or sudoers file.

I wrote about using passwordless SSH keys before. If you're using a UNIX variant, just follow the first few steps on generating and distributing the ssh keys. If you're using Windows, install PuTTy and follow the steps that Steve Friedl put together.

Step Two: Create and test your tunnel
I wrote a little about tunneling (forward and reverse) back in February. In this case, I'm going to tunnel SSH over a reverse SSH connection -- that is, I'm going to SSH from my inside box (NetBSD) to the web server (betaweb.h-i-r.net), and tell SSH to open a reverse tunnel port (2222) on the web server that connects to the SSH port on the NetBSD box (localhost:22). The -g option allows any remote host to use the tunnel. Otherwise, it will bind only to the localhost interface.

[axon@NetBSD]$ ssh axon@betaweb.h-i-r.net -g -R 2222:localhost:22
Last login: Sun Nov 30 14:13:08 2008 from netbsd.labs.h-i-r.net
[axon@betaweb.h-i-r.net]$

Now, from anywhere in the world that can access port 2222 on betaweb.h-i-r.net, I can SSH through my home NAT to get to the internal NetBSD box:

Chimera:~ axon$ ssh -oPort=2222 axon@betaweb.h-i-r.net
Password: [my password]
Last login: Tue Oct 14 19:01:57 2008 from localhost
NetBSD 4.0.1 (GENERIC) #0: Wed Oct 8 01:06:02 PDT 2008
Welcome to NetBSD!

[axon@NetBSD]$

You don't need to reverse tunnel to localhost, and you could just as easily use this trick to reverse-tunnel your e-mail (POP/IMAP), VNC to a Windows/Mac desktop or even to an internal web proxy server.

Step 3: Automate!
If you just leave the SSH tunnel up and running, it won't likely last too long because of session timeouts. You'll need some process to start the tunnel. Here's where you can get creative. Obviously, a process involving the use of cron or at would be one way of going about it. A script running in the background (with nohup) or in a screen session could also take care of things nicely. One idea I had was to set up fetchmail to check a dummy e-mail account every 5 minutes or so. If there's new mail, it initiates the tunnel. Send mail. Wait. Tunnel. Another way would be to upload a file to a web or ftp site to trigger it. You could even make it read information from that file to create the tunnel for different protocols. I opted to create a configuration file on the web server that would be downloaded and used.

On the "inside" box, I created this script and called it tunnel.sh:

#!/bin/sh
ssh betaweb.h-i-r.net rm .tunnel
args=`cat .tunnel`
rm .tunnel
ssh $args

Then, I added this to my crontab:

*/5 * * * * scp axon@betaweb.h-i-r.net:.tunnel ~/.tunnel && ~/scripts/tunnel.sh

Every five minutes, it will try to scp a file called ".tunnel" from the "outside" box. If it was successful, it runs the tunnel.sh script.

The tunnel.sh script removes the .tunnel file from the remote box (so that it doesn't try to spawn multiple tunnels every 5 minutes) and then uses the contents of .tunnel as the arguments for ssh.

I create a file on my laptop named ".tunnel" and add the following:

axon@betaweb.h-i-r.net -g -R 2222:localhost:22 sleep 600

Then, I upload it to the location and wait about 5 minutes. Then, I ssh to port 2222 of betaweb.h-i-r.net. The "sleep 600" is executed on the remote end, which means it will only stay connected for 10 minutes (600 seconds).

Tada!

chimaera:~ axon$ scp .tunnel axon@betaweb.h-i-r.net:
axon@betaweb.h-i-r.net's password:
stdin: is not a tty
.tunnel 100% 58 0.1KB/s 00:00

[ wait 5 minutes ... cue Jeopardy theme song ]

chimaera:~ axon$ ssh -oPort=2222 axon@betaweb.h-i-r.net
Password: [my password]
Last login: Tue Oct 14 23:24:10 2008 from localhost
NetBSD 4.0.1 (GENERIC) #0: Wed Oct 8 01:06:02 PDT 2008
Welcome to NetBSD!

[axon@NetBSD]$

Considerations and Risks:
I've already stated that using public keys without a password is risky business.

The other shady business is directly executing anything using arguments pulled from some file on a remote server. All it would take is "; [insert evil command here]" added to the .tunnel file and havoc can potentially be wreaked on that internal box.

If you can get away with it, BY ALL MEANS use separate accounts that are not used for anything other than this tunneling process. Lock them down as best you can and be mindful of local privilege escalation attacks.

See? This is why admins put firewalls up in the first place. And don't go pointing your finger at me if you get in trouble for unauthorized tunneling.

Sysadmin Sunday: Quick & Dirty SSH Tunneling

Occasionally, you might need to tunnel some other traffic over SSH. This could be to get access to an external web proxy, to get a remote X display up, or to get around a firewall-blocked port that you must access.

The syntax (on the command-line OpenSSH client) for a Local forward is like this:

# ssh remote-example.h-i-r.net -L 3128:localhost:3128

This tells my SSH client to tunnel traffic to port 3128 on my workstation to port 3128 on my DMZ box. Port 3128 isn't accessible because of a firewall, but tunnelled over SSH it works fine. In this case, I'm running squid on the remote example host. Telling Firefox to use http://localhost:3128 as the proxy will now tunnel all of my web traffic over the SSH tunnel to the squid proxy behind the firewall. The reason it's called a local forward because it forwards a local port over the SSH connection.

A remote forward will open up a port on the remote machine and connect it to a port on the client's network. The syntax is similar:

# ssh remote-example.h-i-r.net -R 3306:dbserver:3306

This would open up port 3306 (the MySQL server port) on the remote host and tunnel it to the MySQL service on the host named dbserver on my local network.

While running forwarding of either type, you can enter the hotkey sequence "~#" to see all the open connections through the forwarded ports.