Unsecured IP Cameras

February 17, 2011

Here is an interesting article over at Ars Technica about the prevalence of Internet-accessible cameras that you can find with a simple Google query. Some of them are intended for public consumption, like the aquarium cam he posts a picture from. Some of them are not, like the jewelry store security cam. But all of them are available to anyone who can find the URL in a search engine.

Why is this so?

Well, security cameras used to be a dedicated product with specialized cabling and deployment techniques. But like so many things (voice telephones, printers, POS terminals, etc.), someone had the innovative idea to just put cameras onto an IP network instead. This meant that the cameras no longer needed runs of special analog cabling back to a VCR or monitor – instead, you could just access the video feed with a web browser.

Well, this is an excellent advancement. But moving things into the IP world means that you now have to be familiar with how to secure things in that world. And clearly, many people are not. They don’t think to change default passwords, or close firewall holes, or whitelist allowable addresses. And their cameras show up in this article.

Cameras aren’t the only culprit. Here’s a list of common IP devices; are you sure that they’re all properly secured on your network?

  • Printers
  • Vending Machines
  • Cash Registers
  • Card Swipe Readers
  • Handheld Scanners
  • Smartphones
  • Tablets
  • Administration Interfaces (like HP’s ILO)

Securing an IP network means securing everything on that network, not just what we traditionally think of as “computers”. Because everything on that network is a potential target and a potential beachhead for an attacker.


Robotic Safe Cracking

February 16, 2011

So, what do you do when you get your hands on an old safe with an unknown combination?

Build a robotic safe cracker, of course! It’s either that or die of curiosity – the Magic Safe could contain anything!


Rivest Lecture

February 16, 2011

Ron Rivest, perhaps best known as the “R” in “RSA”, delivered a lecture yesterday at MIT on the past and future of cryptography. It touches on his invention of public-key crypto in the 1970s, as well as some possible applications — such as micropayments and electronic voting systems — in the future. Not a lot of new material for people who work in the field, but still interesting stuff.


Java Updates

February 15, 2011

It’s that time of month again – Oracle has released another patchset for Java, including fixes for 21 different security issues.

Write once, hack everywhere, I guess.


Cybersecurity Budget

February 15, 2011

In a fairly austere budget year, the Obama administration is pushing for a significant increase in cybersecurity research funding at the federal level. This is a clear response to the complete inability of some government agencies to control data exfiltration (see: Wikileaks) as well as the threat to SCADA and other systems represented by Stuxnet.


IT Turf Wars

February 14, 2011

An interesting taxonomy of some of the common turf wars in corporate IT departments. Clearly, we are not a socially deft people.


Definition Monday: Multifactor Authentication

February 14, 2011

Welcome to Definition Monday, where we define and explain a common technology or security concept for the benefit of our less experienced readers. This week: Multifactor Authentication.

Authentication is a key security concept in today’s networked environments, but it’s one that is commonly both misunderstood and underappreciated.

For a long time now, the most common type of authentication on computer systems has been the password or passphrase (These terms are essentially interchangeable, though “passphrase” generally refers to a longer string of characters). Examples abound – logging into your email account, logging into your workstations, even logging into this blog to leave a comment; in each of these cases, you need to enter a username and a passphrase to verify your identity. The thought is that the username of your account might be common knowledge, but the passphrase should be a secret that is known only to the appropriate user, and so knowledge of the passphrase is de facto proof that the user requesting access is indeed the user who was issued the account.

(Tangential comment: As I often say when giving basic security lectures: passwords are not just a cruel joke perpetrated by the IT staff on unsuspecting users to make their lives more difficult. They are a means of authentication, a means of proving that you are indeed the legitimate owner of an account. The authentication leads to authorization, the assignment of proper access rights and controls to your login session, as well as accounting, the recording of your successful authentication and any particularly interesting things you do while logged in. Collectively, these are known as the AAA services and are provided by protocols like RADIUS.)

These days, though, passphrases are no longer adequately secure for some environments. They can be compromised through brute force attacks, if poorly chosen. They can be harvested from plaintext database records if a web site is poorly engineered. They can be entered by users into a phishing web site, or on a computer running a keylogging daemon. Knowledge of a passphrase is no longer an ironclad proof of identity; we need something more.

In order to mitigate this, then, some services are beginning to use multifactor authentication, requiring more than just a single passphrase to allow authentication. These additional factors can be grouped into one of three categories:

  • Something You Know

The simplest factor, the passphrase, is an example of “Something You Know”. That is, the secret that the user is able to enter into the computer system is a partial proof of identity.

  • Something You Have

Another factor, “Something You Have”, refers to an object that is in the possession of the user attempting to log in. Something like an RSA SecureID, for example, would count as “Something You Have”. The numbers that the SecureID generates cannot be replayed and cannot be predicted. Being able to enter the numbers into the login window is undeniable proof that the user possesses the device.

  • Something You Are

The final factor, “Something You Are”, is also known as biometrics. This encompasses fingerprint readers, retinal scanners, voiceprints, and other mechanisms that use part of the user’s anatomy as an authentication token.

Combining two or three different authentication techniques from these three broad categories is what constitutes “multifactor authentication”. Using only one of them is “single-factor authentication,” requiring two is “two-factor authentication”, and asking for something from each category is “three-factor authentication”.

Let’s take a look at this in a normal office environment. You probably have an ID Card that is used with a magstripe reader or an RFID reader to open the door at work: this is single-factor, because it only requires Something You Have. Similarly, logging into your computer with a username and passphrase is also single-factor, because it only requires Something You Know. But if you log in to your GMail account using their new phone-based authentication system, you are using two-factor: the original passphrase is Something You Know, and the mobile phone is Something You Have. Similarly, if you have something like a fingerprint reader on your portable and must enter a passphrase and swipe your finger to log in, that is also two-factor (Something You Know and Something You Are).

A word of caution: clearly, multifactor authentication architectures can make authentication more reliable. While it is easy for a passphrase to be compromised, intentionally or not, it is much more difficult to steal someone’s passphrase AND their employee ID card or mobile phone or other physical token. But when planning to deploy a system like this, it is very important to ensure that it can recover from lost authentication tokens. If you’re using a phone system like the Google example, what happens when a user loses his or her phone? Can your fingerprint reader handle a situation where a user has a cut on his or her fingertip? It is important to think through the failure scenarios as thoroughly as the successful ones.


The Google Two-Step

February 11, 2011

Google has announced that two-factor authentication will be available for users to log into their Google Apps / GMail accounts. Essentially, the account holder’s mobile phone is used as an authentication token; once the number is registered, the user can opt to receive a numeric authentication code via SMS or voice call, or generate it with a local application. Both the traditional password and the authentication code from the phone must be used to access the account.

This is a tremendous step forward in security, especially for a free online service. Passwords have historically been the weak link in most network security schemes; they are often easily guessed or acquired through social engineering techniques. By requiring users to not only have a password but also have a physical token like a designated mobile phone, Google can render phishing and brute-force attacks completely impotent.

Excellent.


iPhone Password Disclosure

February 10, 2011

Apple’s iPhone product line doesn’t exactly have the most secure reputation – and this new attack certainly won’t help.

Researchers from Fraunhofer SIT have found a way to download all of the usernames and passwords stored in the iPhone’s keychain in a matter of minutes. A jailbreaking tool is used to install an SSH server on the phone, and then the SSH protocol is used to run a keychain access script and pull all of the credentials out. Even a “locked” phone is susceptible.


UL Approval

February 10, 2011

Underwriters Laboratories, the independent product testing firm that certifies electrical and electronic devices of all stripes, is launching a new standard for security testing. UL2825, which will be officially launched on February 14, will verify that equipment can handle DDOS traffic, malicious traffic, and other adverse security conditions.