Amado Hidlago of Symantec has written a nice technical article explaining what happened and how it may effect you.

Prerequisites:

1. Remote PC running an SSH server. Windows XP default does not come with an SSH client / server, so I recommend OpenSSH. Most Linux distributions already have installed a SSH client / server that can be used.
2. Determine which ports you are going to use? It is sometimes difficult to determine which ports you are allowed to use but most organizations are going to have port 80, 443, and most likely 22 open for communication. In this tutorial we are going to use ports 22 and 80 for our tunneling although you can use any port that is open.

Tunneling with Windows XP, IE (internet explorer), Firefox, and Putty (SSH client):

I recommend the Putty client when using XP because it’s free and easy, but you can use any SSH client. For this tutorial I will only focus on Putty. So the first step is to configure Putty for tunneling. Click on the “Tunnels” tab underneath the branch of “SSH” within Putty. There under the Source port form you will add what port will be doing all of the forwarding. I have chosen to use port 80 as most organizations allow the use of this port. You will also put in the IP address of your remote PC that is running a SSH server. You’ll also need to highlight the button that says dynamic. A screen shot of this can be seen in Figure 1.

Figure 1: Putty port forwarding configuration page

Once you have done this click the Add button, this will create the forwarded port for the session. You will notice that it puts a letter beside the port you have chosen. This can be seen in figure 2.

Figure 2: Add port and destination settings

Once you have set up port forwarding you can then go back to the main “Session” page and type in the IP address of your remote PC. You can also see that I am connecting to the remote SSH server on port 22. This could easily be changed to a port of your choosing. If your organization doesn’t allow communication on port 22 but does allow port 443 simply put 443 in the port form. If this were the case you need to make sure that the remote SSH server is listening on port 443 instead of the default 22. Once you have done this you can save your session so that you can easily connect the next time. You can see that I have named my session HTTPtunnelViaSSH in Figure 3.

Figure 3: Putty main menu

Now click open and another window will open asking for authentication credentials on the remote PC. Once connected the cursor will move down to the next line, this is the normal operation of Putty. If you didn’t input your authentication credentials correctly you will get a message stating so. A successful connection with Putty can be seen in Figure 4.

Figure 4: Successfull connection via Putty

Now once a successful connection has been made with Putty we need to configure our browser to use the SSH proxy so that all of our HTTP traffic is funneled over our secure connection. We will first configure Firefox. The actual steps to get to the “Connection Settings” within Firefox may vary depending on which version you’re running but generally the path is: Tools >> Options >> Advanced Tab >> Network Tab >> Settings. Once there you will need to highlight the “Manual proxy configuration”, then for the “SOCKS Host” use localhost. The port will be port 80 in this case because we told Putty to tunnel our connection via port 80, YMMV (your method may vary). The screen shot of this configuration can be seen in Figure 5.

Figure 5: Firefox configuration settins for tunneling HTTP over SSH

The same concept applies when configuring internet explorer. Once again the location of the “Proxy settings” for internet explorer will vary depending upon which version you are running but generally the path is: Tools >> Internet Options >> Connections tab >> LAN settings. Here you will need to check the box that says “Use a proxy server for your LAN”, this screenshot can be seen in Figure 6.

Figure 6: Proxy server settings for Inernet Explorer

You must then click on the “Advanced” tab to fill out the Socks connection form. Once again we’ll use the “localhost” as the host and port 80 for our tunnel. This screenshot can be seen in Figure 7.

Figure 7: Socks settings for Internet Explorer

Once you have completed this step you are done, just click all of the OK buttons. You should now be tunneling all of your HTTP connections to your remote PC in a secure shell, congratulations. You have now stuck it to the man, whomever that may be.

Tunneling HTTP via SSH with Linux, Firefox, and SSH:

The procedures for tunneling HTTP traffic in Linux is almost exactly the same as it is in Linux, the only exception being the SSH client. The operating systems have really nothing to do with this whole process. There are numerous SSH clients that can be used with Linux although most distributions come with a SSH client. I will be using the command line interface as oppose to a GUI interface. So using your favorite shell use the following command.

After issuing this command you will be prompted for your password. Keep in mind that you may need to be “root” in order to run this command. Unlike Putty you will be given the prompt for the remote PC instead of the cursor going to the next line. After the connection has been established just go into the settings for Firefox, as seen in figure 5, and type in “localhost” and which port you are forwarding your traffic. Once again we could have chosen any open port to tunnel out HTTP traffic. This is accomplished with the -D option within the SSH command, instead of 80 you could have chosen port 443. That’s it for Linux, you are now keeping your communications private and secure, congrats.

As always I welcome your feedback in the comments section if you have found this article erroneous or have a better solution.

References:

http://polishlinux.org/apps/ssh-tunneling-to-bypass-corporate-firewalls/, http://www.forniol.cat/?p=50

If a malicious user is on the same network as you there are numerous types of attacks they could carry out to compromise your computer and identity. One common attack they might use is called ARP (Address Resolution Protocol) spoofing. Before we get into the details of ARP spoofing it’s helpful to understand how this protocol came about.

The early developers of Ethernet or LAN technology designed the system based upon trust, meaning they never thought anyone using this technology would use it in a malicious way. About thirty years ago, the early stages of Ethernet development, it was hard to imagine a large scale LAN. Hardware was very expensive in those days and only large organizations could afford such technology, even then these large organizations only had a small number of computers that could communicate with one another. So it was hard to imagine that they would ever communicate with someone they didn’t trust. Problem is that Ethernet exists on Layer 2 using a flat addressing scheme (e.g. MAC address). This type of addressing doesn’t scale well for the internet, which uses a hierarchical addressing scheme (e.g. IP). The solution to this problem was ARP.

ARP is used for mapping IP addresses to MAC addresses. A basic diagram for ARP can be seen in figure 1 below.

Figure 1: ARP protocol diagram

So A wants to communicate with B:

1. A checks its local ARP table for B’s info
2. A doesn’t have B’s info so its sends a request
3. Router closet to B adds A’s info to ARP table
4. Router sends B’s info to A so it can update its ARP table
5. ARP info updated, A & B can now communicate

This ARP thing seems to work out nicely, so what’s the problem? In an untrusted environment how does A know that B is who he says he is? Turns out that the ARP protocol has a slew of vulnerabilities.

Vulnerabilities of ARP:

• No authentication! (you cannot be assured who you are talking to)
• ARP tables can be manipulated by anyone on the LAN
• Allows malicious users to pretend to be someone else (the SPOOF)
• Perfect protocol for launching Man in the Middle Attacks (MITM)

Once a malicious user is on your LAN they can easily manipulate ARP tables, spoof who you are trying to communicate with, and launch a MITM attack. A MITM attack allows the attacker to sniff all your traffic and pick up sensitive information (e.g. username, passwords). A diagram of a MITM attack can be seen in figure 2.

Figure 2: Man in the middle diagram

Anytime you are on an untrusted LAN (e.g. Hotel, Public WiFi, University, any large organization) there is the possibility that someone could be listening in on your communications via ARP spoofing. There are plenty of tools available that would allow even the most novice attacker to gain your personal information. So if you are going to communicate on an untrusted LAN here are some tips to stay secure.

• Use encryption (e.g. SSL, SSH, or VPN)
• If unencrypted, don’t communicate private information
• Only visit trusted websites (easier said than done)

For system administrators there are two countermeasures against ARP spoofing.

1. Static ARP tables (difficult to maintain)
2. Arpwatch (will notify if someone is ARP spoofing)

The point of this article is to educate others about how protocols behind the scenes work and how insecure they can be. If you can’t trust everyone on your current LAN, then use encryption and stay away from communicating sensitive information. Now you know, and knowing is half the battle. As always feel free to leave comments if you find any errors within this article.

References:

http://www.grc.com/nat/arp.htm, http://en.wikipedia.org/wiki/ARP_spoofing