Enabling Secure Business Operations

How To Set up a SOCKS Proxy Using Putty & SSH

September 30th, 2008

If you ever find yourself in front of a public computer connected to the Internet and are concerned about the security of the path between you and a website you wish to visit, a SOCKS proxy can come in handy.

SOCKS proxies generally allow you to “bounce” a TCP connection off another server transparently– basically instructing another computer to make a connection on your behalf. When used in combination with Secure Shell (SSH), it can form an encrypted tunnel that insulates you from anyone attempting to grab traffic off the wire.

The following is a simple step-by-step tutorial about how to do this.

You will need:
-Putty SSH client: http://www.putty.org
-An account on an Internet-accessible server that accepts SSH connections and allows connection forwarding (enabled by default)
-A popular web browser or other software that supports SOCKS communications

Step 1:
Fire up Putty and navigate to the Session Category

Step 2:
Enter the hostname/IP address and port of the server on which you have an account.
(Note: The default SSH port is 22)

This tells Putty how to connect to the SSH server.

Step 3:
Under the SSH->Tunnels Category
Enter the following:
Source port: 8888 (or any port of your choosing. Just be sure to remember what it is)
Destination: hostname/IP address of the server on which you have an account

Also, select the “Dynamic” radio button.

This tells Putty that, upon a successful connection, a SOCKS tunnel should be opened from a port on the computer you are using to the SSH server.

Step 4:
Click “Add”
The forwarded port is now added to the connection settings.

Step 5:
Click “Open” to start the connection

Putty will ask for your login credentials. In most cases, this will be a username and password. (For extra security and bonus cool points, have your SSH server only accept certificates)

At this point, your Putty-enabled SOCKS proxy should be active. But how do we test it out? Keep reading…

Step 6:
Fire up your web browser and navigate to its proxy connection properties menu.

For Firefox 3, it is in Tools->Options->Advanced->Network(tab)->Connection, Settings

For IE6, it is Tools->Internet Options->Connections(tab)->LAN Settings(button)->Advanced(button)

Step 7:
Find the SOCKS settings text box and enter the following:
Proxy Address/Host: localhost OR 127.0.0.1
Port: 8888 (or whatever port you decided to use in Step 3)
Ensure SOCKS Version 4 is selected

Note: DO NOT enter any other proxy settings for other protocols (this includes the “use proxy server for all protocols” option. Don’t enable it. I’m serious. If you do, things might not work correctly.)

Step 8:
Click “OK” until you’re back to your browser.

Go to http://ipchicken.com and check your IP address. It should be different from the machine you’re on. In fact, it SHOULD be the IP address of the SSH server (or whatever machine is handling its connections).

Step 9:
Pat yourself on the back. Or have your buddies do it for you– they’ll no doubt be impressed by your newfound computer skills. Enjoy browsing the web using your own personal SSH proxy.

NOTE: Although this could be useful when using a public computer– it won’t protect you from local machine monitoring tools (keyloggers, screen captures, etc). Always exercise due diligence when using untrusted computers.

Each Tuesday, Security Musings features a topic to help educate our readers about security.  For more information about Gemini Security Solutions’ security education capabilities, contact us!

4 Quick Ways To Enhance The Security Of Your Office

September 26th, 2008

Making and breaking security is dependent on good planning, which takes time that most people won’t devote. There are however, 4 quick ways to enhance the security of any office; home, small, or Fortune 500.

  • Lock your screen every time you get up - Set your computer to automatically initiate a password-enabled screensaver when your machine is inactive for 10 minutes. Got to tinkle? Lock your screen first (Vista/XP users > Hold the Windows key [] and press L).
  • Buy a good shredder – A shredder that can destroy mail in its envelopes, CDs, and DVDs is an effective way to keep your confidential information safe.
  • Invest in an alarm system and door lock - You’d be surprised at how many small companies don’t lock their front doors or have basic alarm systems on their windows. Keeping doors locked, even when the office is occupied will stop most opportunistic thieves.
  • Enable Automatic Updates on your operating systems and applications - Or at least update notification so you can test patches before they are released into production. Don’t rely on an administrator to check for updates from time to time.

Successful security doesn’t require every component to be complex, this list could have much more added to it. I’d also recommend you take a page out of the crime book and train your users to think like the mafia.

What do you think is missing from this list?

Browser Wars on Privacy

September 25th, 2008

With the recent beta release of Google’s new browser “Chrome”, there has been a heated battle between browsers once again. The players – Microsoft’s Internet Explorer 8 (IE8), which has been passing around in alpha mode for a few months now, Mozilla’s Firefox 3 (FF), Apple’s Safari, and the new contender Google’s Chrome. I’m going to ignore all the performance perspectives, or even the debates on how shiny one is over the other, or how simple / complex any which one is or isn’t. Today, I’m going to focus on “privacy”, as I’m hoping you would have guessed from the title.

Each browser brings a different flavor of cake to the party. IE8, Chrome, and Safari are the only ones that bring something by default, but FF makes up with its plethora of extensions.

So what are these flavors exactly?

IE8’s privacy feature is being coined as “InPrivate” mode, Chrome has “Incognito”, Safari being the first to the market with its “private browse” option, and FF brings up the tail end with a newly available extension, “Stealther”.

So what’s the point of these new features?

The general intention of this feature, regardless of whose fancy name you’re using, is simply to clear out private data (cookies, browser history, cache, saved form data) from one’s session. This is mostly referred to in the context of a shared computer so that other users can’t find out what you’ve been doing. I like to look at it more in the sense of not what other users can/can’t see, but software. I’m talking about viruses, spyware, adware, malware, etc.

The rise of spyware and malware specifically has skyrocketed in the past few years. As more people become connected and the sharing of content continues to grow, this epidemic of “bad”-ware isn’t going to slow down. We’ve been preaching safe and secure browsing habits for a while now, but now that the browser makers themselves have stepped up, it really doesn’t matter who wins the battle in the end. It’s a win for everyone in my eyes.

Each Thursday, Security Musings features a
security-related technology or tool.  Featured items do not imply a
recommendation by Gemini Security Solutions.  For more information
about how Gemini Security Solutions can help you solve your security
issues,
contact us!

Getting your own certificate through CAcert.org

September 22nd, 2008

There are multiple places to get your own certificate, but this short tutorial describes how to get one through CAcert.org, a Free (as in beer) community CA.

The screenshots below use Firefox on OS X, but any browser and any operating system will work.

The first thing you will notice when you go to CAcert.org and click “Join” is a browser security warning – this is because CAcert.org is not part of most browsers or operating systems, so you have to explicitly trust it. Go ahead and click through saying you’ll accept the certificate. For the paranoid, the SHA1 fingerprint is D1:14:00:FA:E6:8C:22:CA:A1:8F:70:CA:7A:A6:50:B9:44:6C:F1:14 and the certificate expires on 5/20/10.

Complete the “Application”, and you will receive a confirmation e-mail. You’ll need to click on the link in the e-mail within 24 hours in order to confirm your e-mail address.

CAcert.org Application

CAcert.org Application

Once you’ve gotten the confirmation message, click on “Password Login” on the right, and log in using the e-mail and password you just filled in the application. You’re now logged into the system.

On the right, click “Client Certificates”, then “New”. You’ll be able to select the e-mail address you just registered with. By default, “Enable certificate login with this certificate” is selected, and I suggest you leave it selected, so you can use your shiny new certificate.

After clicking “Next”, you’ll be asked to select the key size. “High Grade” is 2048, and I recommend it unless you have a specific reason to use 1024 (such as a very slow machine). Click on “Create Certificate Request” to start the key generation process. The web page will have your web browser generate the key pair, and then offer you a link to install your new certificate.

Installed Certificate

Installed Certificate

You now have a certificate that you can use inside your web browser (and e-mail if you used Safari or IE).

In a future entry, I’ll show you how to get the certificate out of Firefox and use it with other programs.

Each Tuesday, Security Musings features a topic to help educate our readers about security.  For more information about Gemini Security Solutions’ security education capabilities, contact us!

False-Positive Trust

September 10th, 2008

Recently, I was buying a bottle of wine at the grocery store and was asked to show my ID.  My license picture was taken about 4 years ago, when I was 20-30 lbs lighter and before I started shaving my head, so it doesn’t look all that much like me anymore.  The clerk was skeptical, and he asked me to show another form of ID, which I provided by showing him a few credit cards.  Apparently, that was enough to convince him that I was who the license said I was.

What if I had just stolen someone’s wallet, though?  I would have easily been able to produce credit cards that accompanied the license in the wallet.  Showing that extra piece of ID really didn’t add any authentication to the transaction at all, but it allowed me to complete my age-restricted purchase.

Most IT people have heard of the concept of two-factor authentication;  pick two of the three classic categories (“something you have”, “something you know”, “something you are”) for a high level of authentication.  I’ve heard it argued, however, that multiple items from the same category (specifically, the “something you know” group), can be considered stronger than one.  I disagree with this sentiment.

If you can get “something you know” from someone, such as a network password or other shared secret, it’s generally trivial to get another “something you know” from them.  Two pieces of information are almost exactly as strong as one piece of information.  However, if an application designer, much like the store clerk that sold me the wine, is willing to accept two of the same authentication factor as a strong assurance of identity, then the application is more of a security risk than one that accepts only one form of identity because of the nature of the information that application is likely to provide.

It’s a common mantra of security theory that I’ve repeated ad nauseam:  security controls must be appropriate for what is being protected.  Two pieces of knowledge are not better than one, and if they are treated as such, then the application is not secure if it must protect information that requires something more than just a password.

JMU – Cyber Defense Competition

September 8th, 2008

James Madison University (JMU) held an open cyber defense competition on Saturday of this past weekend for all current or former students. A few of us here at Gemini had the opportunity to attend and participate as the attackers. It was a great experience for me as well as the students.
The students were faced with the scenario of being hired into an already existing IT infrastructure after the entire network team had previously been fired. With a tight deadline and the need to keep standard business operations running, they had to secure all computers/servers and continue to process ‘business requests’ as they came in. The students were given a one hour head start to secure as many devices as possible, and then it was free reign for us attackers.
All in all, most teams ended up falling to the majority of the same attacks or forms of penetration. The following is a list of the most common ways we were able to penetrate their systems.

  • Default Passwords – Every team except one fell victim to this. Leaving at least one system or process running under the default admin account/password. Even though we were given the knowledge that all systems had been setup with the default password, this still gives the scenario of systems using blank passwords or ones that would be easily guessable.
  • Running Older (vulnerable) Software/Processes – Two of the teams fell due to running an older version of Apache. We noticed this and exploited it right away. The remedy to this would have been patching or upgrading immediately.
  • Installing Unknown Software – The teams were given a business task to install spam-blocking software on their e-mail servers. The software that was given to them contained a rootkit. At least three teams installed this, with two falling victim and the other noticing and taking down the mail server while it was fixed.
  • Physical Access – We got a little mischievous during lunch as we knew the students would be away. We took a peek into their rooms to find unlocked screens. We took best advantage of this. Sure it was easier for us because we knew they would be out, and it was only one room over. But it only goes to show that even the smallest amount of time is enough to be compromised.
  • Un-patched E-Commerce Site/Engine – The teams were running Zen-Cart as their e-commerce engine. It just so happens that a SQL injection vulnerability was disclosed only a few days prior the competition. All but one team failed to patch this vulnerability.
  • Not finding the real problem – One of my coworkers got into a mini battle with one of the teams continually opening an SSH connection only to have it dropped. The team was noticing the process and simply killing it. This went on for a good while before we finally hosed the system. The team kept killing the process, but not recognizing the fact that we had our own account already on the machine, and that’s how we were continuing to maintain access.

Four out of the five teams took some major hits due to one or all of the above attacks. The one team that held the best did take hits for not maintaining proper services running at all times. In the end, it was clear this was the correct thing to do. They would take down a system completely, wait until the system was completely patched/upgraded and only bring it back up once they knew it was locked down properly.
All in all, it was a great learning experience for the students and for me. They learned what kind of real-life scenarios they could potentially face, and I got to ramp up on my pen-testing skills in a fun way. Kudos to all the teams that participated at JMU, and I hope to take part again sometime soon.