An article from Dark Reading touched on some very valid points with regards to the security at financial institutions. According to the article:

Penetration testers who work with bank clients say the fragile state of the banking community is making it easier for them to dupe understandably anxious bank employees. Bank employees are overly eager or easily coerced into cooperating with “auditors,” or into clicking on links purportedly from the bank about its own financial welfare.

Even though this is very bad from a security standpoint, it seems like a natural human response. However, if someone is able to walk into a bank merely posing as an auditor and without having their credentials checked or challenged, it’s possible for them to make off with a lot of sensitive information.

This type of behavior isn’t limited to just bank employees. Economy-induced anxiety can also affect the judgment of regular users. The most successful phishing attacks prey on a user’s familiarity or interest in the subject presented as bait. So a phishing email claiming to request important information from a bank customer might be more likely to succeed when the economy and specific financial institutions are in a state of flux.

In fact, it would be wise for both bank employees and bank customers to be MORE cautious during times of economic uncertainty, as attackers are notorious for taking advantage of such situations. It just goes to show—when it comes to security, we can’t afford to be careless.

You may have been reading about the latest advancements in quantum cryptography over the past week. Claims that the technology is unbreakable are unfounded however, if not in least for these theoretical reasons.

• Quantum Cryptography Will Be Broken With Quantum Technology - Current computing technology uses methodical means to encrypt and decrypt data. Quantum physics doesn’t work sequentially or even follow the laws of classical physics.
  
  
  
  • The first quantum hack will be done with quantum technology.
  
  
  
  


• The Human Factor - I always like to think about the “gun to head” method of cracking security. Put a gun to the right person’s head and they’ll tell you whatever you want. Quantum cryptography can be cracked by blackmailing, intimidating, and threatening the right people.
  
  
  
  • Not to mention that people lie, cheat, and steal for money or other personal gains. No technology in the world is immune from people.
  
  
  
  


• Maybe God Isn’t Playing Dice - Einstein never believed that quantum physics was random famously saying, “God doesn’t play dice with the universe”. I agree with him, consider it’s just that we don’t completely understand what’s happening to entangled particles – making them seem “magic”.
  
  
  
  • The entire physical universe works according to a set of very well defined laws and rules. Why quantum physics should be an exception is unlikely.
  
  
  • If that is the case, quantum cryptography could be unraveled by a brilliant physicist one day.
  
  
  
  

All of the above is purely theoretical, but you should always be wary of “completely secure”, “unbreakable”, and “perfect security” – because it doesn’t exist. There are other theoretical ways to possibly disrupt or eavesdrop on a quantum message – but again they’re purely theoretical.

Well, so is practical quantum cryptography.

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!

If you used to use nessus for vulnerability scanning, but stopped when Tenable released 3.0 under a non-GPL license, you’re in luck. OpenVAS is a fork of nessus 2.0 and uses .nasl files. However, the vulnerability test feeds (NVTs) seem to be lacking the same breadth as those released by Tenable. However, many .nasl files are open and released by third-parties, so you could add them to your scanner.

Nessus is one of the better vulnerability scanners I’ve used for raw data. It doesn’t do any of the fancy dashboard or report generating that some of the others do, so it tends to get a bad rap. However, if you just need a scanner that finds potential vulnerabilities, Nessus gets the job done and well.

I have yet to play with OpenVAS, but I think it’ll be on my weekend list of things to play with.

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.

Tim already posted about the Debian SSL flaw so I’ll let you read his take on it, but I wanted to bring some more information to the table.

Slashdot (of all places) has an excellent description of why the code was originally changed. The maintainer/developer had run valgrind on the code, and changed the code without thinking about it. It’s unclear who’s to blame here, we only have who checked in the code, not necessarily who changed it. However, this bug is a prime example of using “security” tools without knowing what you’re doing.

Valgrind looks for memory leaks and undefined memory usage. It’s not purely a security tool, but sometimes it’s used as one. Purify and flawfinder are others that I’ve seen used. These tools can show you how memory is used (or misused) in source code. Its these memory misuses that typically cause buffer overflows, so while it’s desirable to remove all “bad” code, it’s also desirable to understand why the code is bad or good.

Security folks aren’t always developers, and developers are almost never security folks. Get the two together to interpret the results of code scanners, it’ll make it a lot easier for you in the long run.

A serious flaw in the OpenSSL code that was being distributed in Debian’s default packages (includes Ubuntu, Kubuntu, etc) was discovered.

This is a major issue because the flaw was in the random number generator process. Instead of mixing in random data for the initial seed, the only “random” value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used.

This results in all SSH and SSL keys generated on Debian based systems dating all the way back to September 2006 being affected.

All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerabile system. Any tools that relied on OpenSSL’s PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.

Luckily there is some help, if you’re systems or users are effected check out the following link for detailed information and references for patches and tools to help you identify vulnerable keys.

source

I’ve recently heard talks of security researchers using the distributed nature of a botnet to remove existing malware. More specifically, the issue was raised after researchers over at TippingPoint Technologies managed to isolate and reverse engineer a client of the Kraken trojan botnet.

According to Pedram Amini (one of the researchers):

“By reverse-engineering the list of names and successfully registering some of the subdomains Kraken is looking for, we can emulate a server and begin to infiltrate the network zombie by zombie. Stated simply, Kraken-infected systems worldwide start to connect to a server we control.
...
We have the ability to successfully redirect infected systems. We have the ability to provide an ‘update’ through the existing Kraken protocol that can simply remove the Kraken zombie.”

This presents an interesting ethical issue— is it or is it not a good idea? From a professional standpoint, I can certainly see how it would be wrong; executing unrequested code on someone else’s computer, no matter what the reason, is a violation of their privacy. It’s technically no different from the malware itself, so there is definitely a liability issue to take into consideration.

On the other hand, for people who are unaware that they have an infected computer (or who don’t know how to fix the problem themselves), using the botnet to clean infected computers might be appreciated. It could be good in a vigilante sort of way.

But then there’s the argument that a good number of those computers that would be “cleaned” by the modified botnet would just get reinfected by the next wave of malware anyway. Maybe it’s really not even worth the risk…

This year’s PWN 2 OWN contest allowed security researchers to choose between machines running 3 different operating system flavors: Linux, OS X, and Vista.

Charlie Miller (of iPhone fame) was able to exploit a vulnerability in the Safari web browser that allowed him to take over the MacBook Air running OS X in about 2 minutes, winning him $10k.

From Engadget :

Apparently Mr. Miller visited a website which contained his exploit code (presumably via a crossover cable connected to a nearby MacBook), which then “allowed him to seize control of the computer, as about 20 onlookers [read: unashamed nerds] cheered him on.” Of note, contestants could only use software that came pre-loaded on the OS, so obviously it was Safari that fell victim here.

It just goes to show— vulnerabilities can exist anywhere and new ones are always being discovered. Just because you run a certain operating system or you use a certain type of software doesn’t mean you should let your guard down.

Some credit card companies are giving customers credit cards with embedded RFIDs (radio frequency ID tags).

They claim this makes things faster and more secure.

Its true that, implemented correctly, RFID-enabled credit cards could provide a secure alternative to taking your card out and swiping it or handing it over to a cashier.

But right now, it seems like a few dollars is all it takes to get around their virtually non-existent security measures and extract the sensitive information embedded on the cards.

Pablos Holman did a quick demonstration on BoingBoing TV about just how easy it is…