Social engineering the deliveryman

Sometimes life gives you a great example of a vulnerable system - here's my recent exposure to an everyday system with a reasonably significant vulnerability.

We've all heard of cases of packages being left on doorsteps, or mis-delivered. This one is a bit different...

I recently ordered a new phone, and had it shipped to my apartment. As most apartment dwellers are used to, over the course of my time there any delivery that arrived when I wasn't around was taken to the complex office and a note was left on my door. That's actually quite convenient, and the complex staff require signatures and, better, recognize me.

In this case, however, something a bit different happened. First, the delivery person was told by my neighbors that I wasn't around, and carried on with his deliveries. On his way back, he saw someone outside of the apartment and stopped. The person claimed to be me - and according to the delivery person, they knew my name, and claimed to be waiting for the package. A forged signature later, and my new phone was gone.

If you ship with FedEx, DHL, or UPS, you've likely never been asked to present ID. If you're around the residence, know the person's name, and act reasonably sure of yourself, packages are free for the taking.

A hole in the system? Yes. One I had never seen exploited before, but one that is pretty easy to tackle if you can get the resident's name. The solution is amazingly simple: allow packages to be sent with a "require ID" option. A photo ID would have prevented the entire issue.

I'll post a follow up, as further investigation is ongoing. Sadly, in cases like this the value of the stolen item isn't sufficient to change policy, and is below the threshold to make any sort of police investigation likely.

Creative Commons licensed image credit to Flickr user StarMama

Encryption Key vulnerability Update...

Late last week, we reported on breaking research from Princeton in which it was found that encryption keys could be harvested from RAM. Over the last few days the folks at the Internet Storm Center (ISC) have been compiling their own research and interpretations to compile a nice guide located here for some of the more popular encryption products on the market.

In the guide you'll find several different products and their level of risk while the system is screen locked, sleeping and in a hibernation status. What stands out to me is that there are vendors that are claiming full invulnerability to this type of attack. Be mindful that most products are not safe until the memory has had a chance to fade. Further, even if a product is designed to wipe the memory at shutdown - this will only occur when the system is shutdown cleanly. So, I'll reassert my original recommendations and add a fourth:

1. Never let an application remember your password/passphrase
2. Always shut your computer down when your are done using it if you are in a non-physically secured area
3. Never set encrypted volumes to auto-mount
4. Configure auto-dismount of encrypted volumes
   

FVE: Full "Vulnerable" Encryption...

Ok, so Full Volume Encryption is something I need to ensure my data are safe right? Yes, but skip back to the first lessons your were taught in your crypto classes:

Once the data are encrypted, you must have?

A. A warm fuzzy feeling that you've done everything to protect your data - followed by a double latte
B. More than a modicum of concern about the physical security of the device that holds your encrypted data
C. Good key management practices including backup copies that are physically secured against theft and destruction and access control to the working keys
D. A tinfoil hat, because you are already reading this blog

Answers to follow

In a recent video on the Center for Information Technology Policy site for Princeton University, I saw an example of how BitLocker can be "Bit Unlocked." BitLocker is an underlying FVE engine offered with some flavors of Windows Vista. In the video, the narrator explains, with video evidence, how an attacker could read the encryption keys from RAM even after the the machine was placed in a sleep/hibernate mode and or turned off. Therefore, it is feasible that if your laptop is stolen while running, sleeping or after having just been turned off - your encrypted data are still at risk. So, you need B - more than a modicum of concern about the physical security of your computer. Not using Vista - don't feel too comfortable as the narrator also claims that similar harvesting techniques work against Apple's Filevault, Linux's DMCrypt and could be possible against TrueCrypt.

So, you also need C, good key management practices...In this case, the FVE engines are using RAM to hold the keys for inline use as the computer runs. While this is completely necessary for the system to be able to encrypt and decrypt files, it presents a problem in that the keys are in plain text within the memory. Without a wholesale rewrite of the software to clear memory pages and or provide some transform for the keys there's not much that can be done to prevent this condition. There are configuration options and human actions that can prevent this type of attack. For example, to thwart the attack on BitLocker, one can simply set up Vista to boot to the loader requiring the pass-phrase that was assigned when the volume was encrypted - and then shut the computer down when you are done with it not letting it out of site for at least a few minutes. The downside, if you can call it that, is that boot-ups take longer.

But I have a TPM chip...and I am thirsty for that double latte. Not so fast, according to the accompanying article:

"Trusted Computing hardware, in the form of Trusted Platform Modules (TPMs) [22] is now deployed in some personal computers. Though useful against some attacks, today’s Trusted Computing hardware does not appear to prevent the attacks we describe here.

Deployed TCG TPMs do not implement bulk encryption. Instead, they monitor boot history in order to decide (or help other machines decide) whether it is safe to store a key in RAM. If a software module wants to use a key, it can arrange that the usable form of that key will not be stored in RAM unless the boot process has gone as expected [31]. However, once the key is stored in RAM, it is subject to our attacks. TPMs can prevent a key from being loaded into memory for use, but they cannot prevent it from being captured once it is in memory."

In the end, this is a fairly advanced technique, that in time, I'm sure will become publicly available. Recommended countermeasures include setting the memory in epoxy, using security screws and locks for computer cases to limit physical access to the RAM and even re-engineering the RAM itself to forget faster. Today, however, I'd recommend that you think about these guidelines:

1. Never let an application remember your password/passphrase
2. Always shut your computer down when your are done using it if you are in a non-physically secured area
3. Never set encrypted volumes to auto-mount
   

Data Breach Notification requirements, state by state

The Consumerist, an online customer advocacy website pointed out that CSOOnline has put together a comprehensive list of the breach notification laws for each state - 38 states are represented on their map. While the map only covers highlights of each state's laws, it is an interesting way to visualize and review current requirements. The Consumerist article also points out CSO's coverage of current laws moving through Congress in Washington - perhaps we will see a national breach notification law enacted in the next year or two.

Blinding security cameras with IR LEDs

BoingBoing linked a translation of a German site today. The site shows a headband with an integrated IR LED that blinds security cameras. This is an interesting alternative to the old trick of blinding cameras with laser pointers, as it offers a means of creating anonymity that might not be noticed by others who saw you in person.

Proprietary encryption strikes again

Slashdot readers may have noticed the Heise Security analysis of the 2.5in. Easy Nova Data Box PRO-25UE RFID hard drive case build by Drecom. In short, the issue is that the encryption used by the enclosure's chipset is very poor, and won't stop more than a casual attempt to decrypt the data.

The article says:

The company explained that actual data encryption is based on a proprietary algorithm. The company claims the IM7206 only offers basic protection and is designed for "general purpose" users.

(Emphasis mine)

Joe Consumer isn't likely to have access to chipset specifications - and in fact, the vendor even disclaims responsibility in the Heise article:

Easy Nova product manager Holger Henke says that the improper label "128-bit AES Hardware Data Encryption" for Data Box PRO-25SUE was the result of Innmax's misleading formulation of its controller specifications.

Security analysts should know to avoid proprietary encryption algorithms if they're able to find out that they're in use, but the users who rely on what sounds like a standards based encryption capability will be disappointed - and may have their data put at risk. Very few vendors go so far as to tell you what chipset they're using for encryption, so buyers are put in the position of relying on marketing materials and product labels. That can be an uncomfortable position to be in if you really need to rely on the encryption.

Heise also notes that the same chipset used in the PRO-25UE is used in a number of other products, and that the AES encryption used in the chipset is only to encrypt the RFID unlock token, not the data on the drive. Sadly, the data on the drive is "encrypted" with a simple XOR that Heise reverse engineered rather quickly.

What options do you have? Well, hardware encryption means that you have to trust the vendor to have implemented their encryption system correctly. Since there isn't a central security standards body that certifies encryption devices like this, users are left to investigate on their own, or to rely on third parties who may take interest. If you don't trust the hardware solutions on the market, a software package like TrueCrypt, PGPDisk, or BitLocker is likely your best answer for now.

Learning from It Takes a Thief

The Discovery Channel's It Takes A Thief is an interesting method of advocating home security. For those who haven't watched it, the basic show format is that two hosts, both former burglars who have turned their lives around, first break into a house - with the owner's permission, then upgrade the house's security and retrain the owners before trying it again.

For those who have never participated in a physical security penetration test, this is a reasonable introduction to one form of penetration testing. If you're a security professional, or have physical security expertise, you'll probably note that their targets are selected for the wide variety of issues that they have, and that some of their actions as shown would make a security professional fail - things like entering the house without a written 'get out of jail free' card. You'll also note that while they make quite a few upgrades for physical security, there are often ways around the systems that are installed. If you're questioning that, read their security tips - their goal is to make the house a harder target than the rest of the neighborhood, not to make it invulnerable.

In either case, the families that are on the show do appear to get real security improvements and the impact that the show makes on their habits is real - at least in the short term. Let's hope that a year or two from now the show goes back to check how the participants are doing with their habits and whether their systems have continued to both be used and to function properly.

There are a few interesting things to note in comparison to what many of us might have considered: a penetration test by an electronic penetration testing company.

1. The hosts select the owners by checking a number of houses in a given neighborhood, rather than the owners soliciting the testing. This remarkably similar to the unsolicited companies and individuals who look for vulnerabilities in software and websites.
   
2. The owners are allowed to watch, but cannot respond to the event. In most penetration tests, organizations are encouraged to let their normal defenses respond as they normally would, typically with some level of cut-out to ensure that escalation doesn't cause damage or down-time. While one episode does see the police called on the host while he is robbing the house, the owners never come home and children or others are never in the house for the event.
3. Technology, infrastructure, and process are reviewed and upgraded. This is very similar to the result of an electronic penetration test, however the hosts provide the upgrade. A model where the assessor does a risk assessment and determines the security improvements to be deployed (albeit, with the understanding that much of it is vendor driven based on advertising) is intriguing. You don't see a companies often doing this sort of publicity, but wouldn't it be an interesting marketing strategy?
   
4. The homeowners watch video of the robbery as it happens. Typically senior members of an organization merely receive a report, as electronic penetrations are typically not as dramatic to watch. The impact of a home invasion and theft has a great impact on the homeowners, and the visceral feeling can't be easily replicated in a summary report of findings.
   

This is, at the end of the day, a live physical security penetration test. Identities are not fully disclosed, although people who recognize the homeowners or know their neighborhoods would be able to identify them and would be familiar with their security systems and their valuable possessions. That's an interesting potential issue, as the homes chosen thus far have typically had valuable possessions reaching into the hundreds of thousands of dollars.

I'll be pointing their home security tips out when I give talks on physical security - having a TV show example is a great way to reach my audience, and awareness at home is a great lead in to awareness at work.

Creative Commons licensed photo credit Flickr user Ben Scicluna