I’m sure if you’ve been paying attention to any of the tech/geek news blogs you’ve seen the attention given to the “COMPROMISING ELECTROMAGNETIC EMANATIONS OF WIRED KEYBOARDS” article. So you already know the buzz, and are probably all running out to build Faraday cages around your offices or workstations. But there really isn’t anything terribly new or ground breaking here. It’s simply a further spin on an old trick.

Anyone who can remember back might recall a little something about “TEMPEST”. It’s the codename given to compromising emanations (CE). This research dates all the way back to 1985 when the security risks of emanations from computer monitors was analyzed.

By no means do I want to take away from the research and proof of concept that Martin Vuagnoux and Sylvain Pasini have put together. I simply want to focus on the fact that a lot of us, especially those young in the tech and security fields, are forgetting some of the roots. We’ve already pointed out some other old-school hacks that are still relevant today. So while everyone is hardening their systems for super stealth ultra-sensitive attacks against their systems, let’s not forget where we came from, and proper education of old-school attacks deserves some attention as well.

The example I used to segue into this might not be the most stellar example of outdated attacks, as with technology growing, it might even become more of a common-day attack. But the fact that this goes way back, and technology is only making it easier goes to show – things that we think are out of reach today, aren’t  far from reach in the not-so-distant future.

So what do you think? What other areas of our past or even present do you think won’t hold any grounds for security in the not-so-distant future? What old-school hacks are still present today that many might be overlooking? Let us know in the comments…

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!

A while back I posted about my and others’ concerns about Firefox’s newly handled way of dealing with self-signed or unapproved certificates. It seems the folks over at Carnegie Mellon University have released an extension for Firefox to help deal with this exact issue.

My main issue with my last posting wasn’t directly tied to the error in the security model Firefox was introducing, but simply the intrusion factor of what was taking place, and the lack of information that FF was providing when denying access to the site. The extension provides two primary benefits:

1. If you connect to a website with an untrusted certificate (e.g., a self-signed certificate), Firefox will give you a very nasty security error and force you to manually install an exception. Perspectives can detect whether a self-signed certificate is valid, and automatically overrides the annoying security error page if it is safe to do so.


2. It is possible that an attacker may trick one of the many Certificate Authorities trusted by Firefox into incorrectly issuing a certificate for a trusted website. Perspectives can also detect this attack and will warn you if things look suspicious.
   
   The same is true for HTTPS sites with certificates that contain mismatched domain names (e.g., www.gmail.com uses a certificate for mail.google.com) or certificates that are expired.

   The primary description for Perspective also states:
   

   A client can automatically make a secure connection to one of several publicly available “network notary servers” located around the world. These servers tell the client:
   

   
   
   1. What key does the server see for host.domain.com right now?
   
   
   2. What keys has the server seen in the past for host.domain.com?
   
   

   
   The replies from the network notaries can go a long way toward either providing the user with confidence that the key it received is valid, or that a real threat of a “man in the middle” attack exists.

   The end result is that instead of having applications issue bland warnings, which users often ignore, the application can either skip the warning if notary data indicates that the key is valid, or give a very stern warning in the rare cases when an attack appears to be in progress.

   
   This extension does pretty much exactly what I wished Firefox would have done with the new policy from the beginning.

   Link to the project: HERE

   
   

One of our clients unintentionally DoSed themselves this weekend by switching registrars. In what turns out to be an honest mistake on someone’s part, the new registrar set the company’s DNS servers to the registrar’s (pretty standard action), but they didn’t copy the old DNS information from the previous registrar. Effectively denying service to the organization’s mail server (no DNS entry and no MX record), and some websites that generate revenue.

I would suspect that this is a common situation for smaller companies. They decide that they’re not happy with their current registrar for whatever reason, and switch. Unfortunately, not understanding how computers find each other and buying into the “complete hosting solution” packages offered by many registrars. In an effort to prevent other small companies from suffering the same fate, I present DNS, whois, and hosting for dummies.

(more…)

IBM’s X-Force R&D has sent out a report( pdf ) detailing computer security statistics collected over the first six months of 2008.

Among the results of this report, we find the following (compared to last year’s figures):

• Decreased time between disclosure and public exploit


• Further shift from OS and multimedia exploits to web browser exploits


• Further shift from browser core to browser plugins

What this tells us is that attackers are keeping a steady eye on the disclosure process itself, quickly adapting the details into POC code. It also shows that attackers are recognizing and taking advantage of the browser as an attack vector—a trend that has been steadily increasing over the past few years.

Another interesting trend that caught my eye was the most commonly used web browser plugin exploits… most attacks exploited vulnerabilities that were between 1 and 2 years old. On one hand, I would say that an improvement has been made—no longer are people getting exploited by 4 or 5 year old bugs. But at the same time, we have a long way to go before people constantly address the security issues of software that is regularly exposed to the dangers of web browsing.

The rest of the report ( pdf ) is a very solid read—they cover everything from spam, to phishing, and even the relatively fresh vulnerability frontier of virtualization.

This week, Websense published its State of Internet Security report for the first half of the year.  Here are some things to take away from it:

Legit Sites with Malicious Code – Most of the sites that contain malicious code are legitimate and have been compromised.  This number went up 50 percent over the past six months.  The growing popularity of sites with user-contributed content is opening holes in areas of the Web that people consider trustworthy.  Sixty percent of the top 100 sites have been involved in some kind of malicious activity this year.

“Blended Threats” Increase – Continually increasing amounts of e-mails contain a link to a spam site or a site with malicious code.  “Storm” attacks are making it more difficult to create anti-virus solutions because of their use of a mixture of attack vectors.

More Shopping Spam – Shopping has overtaken pornography as the category of spam you are most likely to see.  This could be caused by spammers using information gathered from social networking sites to tailor their messages to the victim’s interests.

Websense summarizes by predicting that reputation-based site filtering will become less effective as hackers continue to focus on attacking legitimate sites through their Web 2.0 security holes.  They also advise companies to take a more data-centric approach to security in order to protect against blended attacks which can circumvent defenses that only focus on one technology.

Today we are proud to present an update to the Security Musings site.  We’ve moved to WordPress, and made the look and feel very similar to the main Gemini Security Solutions site.  We have also started using FeedBurner to manage our feeds, allowing you to subscribe to Security Musings by email.  Please let us know if you notice any problems with the new site by leaving a comment below.  Enjoy!

I recently came across a paper by Atul Prakash Analyzing Websites for User-Visible Security Design Flaws which discusses some findings in a recent survey of 214 financial institutions conducted in 2006. The origin of the study came about when Prakash notices many of the below listed flaws in his own financial institutions websites.

The top design flaws that Prakash and his team were looking for were:

• Placing secure login boxes on insecure pages: A full 47 percent of banks were guilty of this. A hacker could reroute data entered in the boxes or create a spoof copy of the page to harvest information. In a wireless situation, it’s possible to conduct this man-in-the-middle attack without changing the bank URL for the user, so even a vigilant customer could fall victim. To solve this problem, banks should use the standard “secure socket layer” (SSL) protocol on pages that ask for sensitive information, Prakash says. (SSL-protected pages begin with https rather than http.) Most banks use SSL technology for some of their pages, but only a minority secure all their pages this way.

• Putting contact information and security advice on insecure pages: At 55 percent, this was the flaw with the most offenders. An attacker could change an address or phone number and set up his own call center to gather private data from customers who need help. Banks tend to be less cautious with information that’s easy to find elsewhere, Prakash says. But customers trust that the information on the bank’s site is correct. This problem could be solved by securing these pages with the standard SSL protocol.

• Having a breach in the chain of trust: When the bank redirects customers to a site outside the bank’s domain for certain transactions without warning, it has failed to maintain a context for good security decisions, Prakash says. He found this problem in 30 percent of the banks surveyed. Often the look of the site changes, as well as URL and it’s hard for the user to know whether to trust this new site. The solution, Prakash says, is to warn users they’ll be moving off the bank’s site to a trusted new site. Or the bank could house all of its pages on the same server. This problem often arises when banks outsource some security functions.

• Allowing inadequate user IDs and passwords: Researchers looked for sites that use social security numbers or e-mail addresses as user ids. While this information is easy for customers to remember, it’s also easy to guess or find out. Researchers also looked for sites that didn’t state a policy on passwords or that allowed weak passwords. Twenty-eight percent of sites surveyed had one of these flaws.

• E-mailing security-sensitive information insecurely: The e-mail data path is generally not secure, Prakash says, yet 31 percent of bank Web sites had this flaw. These banks offered to e-mail passwords or statements. In the case of statements, users often weren’t told whether they would receive a link, the actual statement, or a notification that the statement was available. A notification isn’t a problem, but e-mailing a password, a link or a statement, isn’t a good idea, Prakash says.

One of the focuses is the fact that these flaws aren’t exactly bugs, but actual flaws in the designs. Many can be remedied, but these are the kinds of things that should have been considered in the design phase.

It only goes to show that planning is as important as implementation.

The web becomes a more threatening place each and every day. This is especially evident due to the uptick in legitimate websites being compromised to push malware. ScanLife reported increase of over 400 percent last month.

So, what is going to help alleviate these threats? I’m pushing for more secure code. Microsoft issued a security advisory last week that offered companies free tools to help scan for SQL injection vulnerabilities.

Another area that’s helping to secure code is the new PCI Data Security Standard section 6.6 guidelines that just went into effect. Under the new rules, merchants need to implement a web application firewall and/or conduct a complete code review by a 3rd party.

It is vital that secure code become a standard in all development. Let’s hope these extra steps by PCI and additional help from companies like Microsoft can give the industry the nudging they need.

RFIDs can switch off equipment used in hospitals. Researchers tested several types of devices used to save lives in close proximity to RFIDs and found that the devices, in a number of instances, interfered with the equipment’s functioning.

A total of 123 tests, three on each machine, were carried out, and 34 produced an “incident” in which the RFID appeared to have an effect – 24 of which were deemed either “significant” or “hazardous”.

The use of RFIDs in hospitals has begun to grow. The devices are being used for tasks such as patient identification, inventory management, and allowing only relevant hospital staff to view a patient’s medical records.

Hospitals will need to consider the new findings as they continue to employ this kind of technology. Families will find little consolation in the fact that their medical records were kept safe by the same gadget that mistakenly turned off their loved one’s ventilator. They may also take legal action, and there’s too much of that going around already.