During security assessments, I always make sure they’re performing security testing as part of their development process.

This is why: “Apple security blunder exposes Lion login passwords in clear text”

No need to go into details as to what happened here; it’s well-researched in the linked article. However, this is exactly the scenario that development security testing is meant to avoid. A seemingly innocent patch disables or circumvents an important security feature. The results are predictable.

It could be worse, though. Here’s the worst case: the problem isn’t detected. Because the security was included in the original version, and because nobody checked, it is assumed that the security is in place, and successive updates are made, with the security feature in question not working, but everyone assuming it does. And successive patches are built upon the circumvented security. by the time the bug is discovered, fixing it is a gargantuan task.

So, it’s not that bad. It’s still a major breach, though. So if you ever wonder if that testing is really necessary during development, you can point to this incident and confidently say “Yes.”

A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the provider’s transmitting, routing, or providing connections for, material through a system or network controlled or operated by or for the service provider, or by reason of the intermediate and transient storage of that material in the course of such transmitting, routing, or providing connections – 17 USC § 512, from the Cornell University Law School

No business is an island. There’s no company that does not, to some extent, rely on other businesses. Business models assume that vendors will be able to assure a steady flow of goods, that retailers will sell goods and pay as contractually bound, that shippers will actually ship goods, etc. Our legal system is filled with assurances to that effect. And this is important, because it gives companies confidence to make such agreements. Knowing that business partners can in fact be bound and trusted to perform their duties, companies can more readily act to grow and increase their revenues. The key component here is confidence – a certainty that once a contract is signed, it will be followed.

That’s what makes the MegaUpload case rather disturbing. There’s no doubt that MegaUpload was hosting infringing content. However, the content was not all infringing – but all of it was taken down. Right now there is a case and the hosting company, Carpathia, is seeking court action which would allow it to release the existing data back to MegaUpload users.

However, in a way, the damage has already been done. Whatever the outcome of the case itself, one message has been sent clearly: your data can be held hostage by others’ data. That’s sure to have a chilling effect on the hosting industry for years to come.

The following events are based on actual facts and actual events. Names have been changed to protect the oblivious.

I would like to start off by stating that I take no pity on the individual this story is about. I refer to them as oblivious because to do what they did simply can’t be categorized in any other way.

Let’s back up a week. I’ve been in need of another Android device to do some tinkering with, have a backup for my daily driver, and to have something that my son can play with and not fear total destruction (again of the daily driver). After checking with friends and co-workers if they had any spares – they didn’t – I resorted to Ebay. Long story short, I found an LG Optimus S – a rather sturdy little phone for its age for $7 plus $4 shipping. The description said that it did not boot. Being the hacker that I am, I generally don’t let simple statements like that deter me.

A few days later I had the phone in my mailbox. It even included the battery, which I wasn’t expecting. I attempt to boot it up, and as described – it doesn’t boot. I plug it in to ensure it has a charge. It won’t charge. I pull out the voltmeter and quickly determine the battery is junk. Fast-forward two more days after a visit to Amazon (Prime). A new battery is awaiting me in my mailbox. Plug it in, viola, Android magic!

(more…)

Around this time of year, many people receive new devices and gadgets as gifts, and some of those gadgets turn out to be smart phones. But smart phone security is very tricky to pin down, as there are multiple vendors and platforms to take into consideration, not to mention the speed at which smart phone technology is evolving. So when I came across this Top 10 iPhone Security Tips whitepaper (pdf), I knew that it was probably a good thing that it attempts to target a specific platform. However, after reading through it, I think that many of the things McAfee points out can also apply to a Droid or BlackBerry. And so, by stripping away the platform-specific details, we arrive at a pretty decent list of things a new smart phone owner can do to achieve some basic smartphone security:

• Enable passcode/lock

Mobile phones have had passcode capabilities for a long time. Make sure you’re using it, since a passcode lock is often the first line of defense.

• Erase all data before a return, repair, or resale

If you will no longer be the owner in possession of the device, it’s best to erase everything you can first. Everything. If you can do a factory reset, do so, because your phone constantly records information and there is always some data that isn’t easily found, let alone purged.

• Regularly update firmware

I’m guilty of not doing this– sometimes the update notification will sit around for a week before I finally give it permission to run. But this is one of the easier things to do, since it’s mostly automatic.

• Don’t run shady apps

Just like with a personal computer, if you run unknown or untrusted applications, you substantially increase your chances of getting got. So if you don’t want to get got, be prudent about what apps you run on your device.

• Take advantage of the web browser’s security

For smartphones with native web browser apps, be sure to use the security features to clear caches and stored passwords when it’s necessary. Just because a web browser is on a mobile device doesn’t mean it’s a security lightweight. Check out the “settings” or “options” to see just how much your mobile phone web browser can do to help you out.

• If you’re not using it, disable it

I’m also guilty of leaving stuff running unnecessarily. Be careful about leaving debug mode enabled, Bluetooth and wifi on, etc. Generally speaking, the more doors you leave unlocked, the lighter you sleep at night. Turning off unused services when they aren’t needed is a good habit to form, even outside the realm of security.

• Secure that email

In addition to providing native web browser apps, many smartphones also come bundled with a native email app. Check the settings for these apps to take advantage of any security features they’re offering (such as SSL/TLS).

• Use a phone tracker

The GPS can be bad for privacy if you are reckless with it. However, it can also be a powerful tool to help you recover a lost/stolen device. I believe the iPhone 4 has a built in device-finding service (complete with a remote wipe). But even if you have a different smartphone, there is almost certainly an app that provides some remote tracking for lost devices (i.e. Where’s My Droid app for Android).

This certainly isn’t a comprehensive list, but it should be enough to get both new and old smartphone users thinking about general mobile device security in a healthy way.

A few years ago, a friend of mine served in Afghanistan. It was, as he described it, a long and mostly dull duty. When not busy with soldierly duties, he wrote on his blog and took pictures, often of the rather picturesque – to those who didn’t have to traverse it – scenery. At one point, however, he was informed that these landscape pictures were, in fact, an operational security violation. Not the ones taken in-camp, but the gorgeous panoramas of Afghani mountains and valleys. The theory was that, using those pictures, insurgents could find their position. My friend’s response was succinct: “I think they already know about the mountains, sir.”

In a previous job, I was charged with creating the security documentation for a particular government system, including the disaster recovery plan. That plan necessarily had to include the power requirements for the system. However, with a certain amount of digging, I discovered that by the standards to which I would be held, the simple fact that the servers used either 110V or 220V power was considered “secure unclassified information” and my report would require rather cumbersome treatment. Mind, what put it over the top was not that the servers required 110V, or that the servers required 220V, but simply that the servers might require one or the other. Or, in other words, that the servers required electricity in the same fashion as every other standard server. The bleedingly, patently, absurdly obvious. But that fact was somehow important for security.

There is a certain tendency, with respect to security, to classify, render confidential, or otherwise obscure every piece of information. I cannot count how many times I have heard “we can’t tell you what kind of encryption we use – that would make it insecure!” or some other variant. Indeed, there is a certain value to hiding some seemingly obvious pieces of information – the number of servers, the ports being used, the location of a datacenter in a building. These are not without purpose. There is no sense in making an intruder’s job any easier, and great value in making it as trudgingly difficult and annoying for them as possible.

But this must be tempered with a modicum of sense. In risk assessment terms, this means examining a piece of information and determining what level of risk it exposes. There is no sense in restricting the fact that servers run off of electricity; an intruder knows that – it’s not something that takes much knowledge to figure out. There’s no sense in hiding the fact that a base which is in contact with the local population can see the mountains – the insurgents know that. These are obvious things.

And there’s an important psychological component there. By trying to secure patently obvious things, security by obscurity (already a bad idea) becomes security of absurdity. The very concept of security becomes eroded. Yes, it’s easier to treat all information as secure, but the end users won’t view it that way. What they’ll see – correctly – is a security posture which has gone amok and which is not connected to the reality of their work. And they’ll start ignoring it because it’s ridiculous. And then they’ll be ignoring actually sensible security; they’ve lost confidence in the directives and the purpose behind them. And then you have a problem.

The point is to maintain a real connection with the people who have to implement security directives. As I’ve said before, their job is not to keep your infrastructure secure – their job is, well, their job. To keep people following secure processes, they have to be invested. They have to be able to understand why they’re doing these things. You have to acknowledge that they know the mountains are there, and work within that reality.

A lot of what we security professionals do includes protecting information from being compromised (especially personal information). The shift towards more profit-driven computer crime has happened swiftly over the last decade, so it should come as no surprise that there is a booming underground market centered almost entirely around compromised financial and personal data. And, on the other end of the spectrum, we have laws and regulations to help minimize the leakage of this data in the first place. Plenty of research and documentation exists for the many ways we try to protect information, but there isn’t much (public) info on the underground market populated by the attackers and their associates who trade in illegally-gotten information. So, how do someone’s bank account credentials grease the wheels of this unique ecosystem?

The Underground Economy: Priceless (pdf) touches on the subject in a great amount of detail, even explaining the importance of reputation and the lengths people take to avoid prosecution.

Essentially, public and private servers host communities of individuals who offer their services for a fee. Maybe one person will help someone else cash out an entire bank account (for a 50% cut). And maybe another person will deliver ill-purchased goods to a safe location (for a 30% stake). In the mix are also those who initially did the work (or wrote the code) to capture the information, as well as people who specialize in forging IDs, curious researchers, law enforcement… the list goes on. Compromised financial data seems to lead to a very deep chain of events that attracts many people with varying skillsets, most of whom are simply offering to perform the same hustle(s) over and over. It is a system where both information and skills are bartered/exchanged and high risk is accepted for high returns on investment.

But not all participants are highly skilled– there should be some low-hanging fruit in there too, right? Surely, there are people who aren’t as cautious or who miscalculate their risk of exposure, yet we still have trouble keeping up with even a fraction of the online fraud. While I’m glad we are focusing efforts on preventing information from being compromised in the first place, I feel like there is a growing opportunity to focus a lot more research on thwarting these high-risk behaviors directly. Sometimes you have to treat both the symptom and the cause.

In light of all the discussions about maintaining a secure posture on trusted certificates, we oftentimes forget about the little guys. In this case, I’m talking about our mobile devices. We tend to forget that these devices are just as vulnerable as our desktop/laptops. Unfortunately, it’s not always easy to manage the certificates on these devices. But if you own an Android device and would like to take a little more control over what your device is trusting, here’s how you can do it.

Remove a CA Cert from Android System
The bouncycastle library will be required, you can grab it here:
BouncyCastle Library

You’ll need the Android-SDK as well in order to utilize ADB. It can be found here if you don’t already have it:
Android SDK
(more…)

edited September 2 with an update on Apple/Safari.

Another case of a certification authority (CA) issuing a certificate they never should have has surfaced. You may remember when we discussed the Comodo incident earlier this year. Now, a certificate issued by DigiNotar has surfaced in the wild, being valid for *.google.com – meaning it could be used to secure any transaction with any Google web property, including GMail. According to this pastebin post, this certificate “is being used in the wild against real people in Iran *right* now.” DigiNotar has issued a statement. Here is some information about why this is bad, and what steps you should take to remove this issuer from your trust lists. (more…)

Disclaimer: I requested and received an evaluation version of the Apricorn Aegis Padlock. I was sent the 250GB AES-256 version, and I need to return it to the company in 30 days.

This is a pretty sweet hard drive, but there are a few annoyances that I think can be improved upon. I was unable to test a few things just due to the time I could devote to this, the fact that I need to return the drive in working condition, and that I don’t have access to some specialized hardware to test timing attacks.

The drive is FIPS 197 validated – aka, uses AES according to NIST.

You can check out Apricorn’s site for the specs and details, but what you see on the product site is pretty much what you get. The drive draws power from your USB port, so you’ll need a powered port. The drive came with an adapter (1 USB to 2 USB) if one of your USB ports doesn’t provide enough power. I had no issues with power on my MacBook Air, but I did on my office desktop since all USB ports were already taken – easily solved with a powered USB hub.

(more…)

I just recently bought a new netbook. Now, I know that netbooks are supposedly on the way out, but I love the low price, long battery life, and massive portability. But there’s a problem with netbooks and security. They’re massively portable – whether the person doing the porting is me or a thief. I do my best to keep my netbook safe, but being realistic I’ll admit that it could happen.

Now, the biggest loss from someone stealing my netbook is in data; the hardware really isn’t all that expensive. My netbook doesn’t just contain personal information; it’s also full of important business data. I can and do perform regular backups to make sure I don’t lose any of the data, but I don’t want anyone else reading what I’ve got, either.

That’s where file encryption comes in. If properly encrypted, my data won’t be accessible even if someone has the hard drive. So, with that in mind, I’m looking at three different utilities for encrypting my drive:

TrueCrypt – TrueCrypt is kind of the grand-daddy of Whole Disk Encryption; it’s currently on release 7. Being free for download, it’s rather popular. It offers a range of features, including the ability to perform whole disk encryption, and the ability to create hidden volumes and hidden operating systems, meaning that even if you’re compelled to divulge passwords, your attacker won’t know about these volumes and thus won’t know to get access to them. In addition, TrueCrypt comes with a pretty impressive set of encryption algorithms, including AES-256.

AxCrypt – Another piece of freeware, AxCrypt doesn’t offer quite as much as TrueCrypt. Unlike TrueCrypt, AxCrypt exists for encrypting files and doesn’t have a whole disk option. Also, it’s limited to AES-128 which is not bad but certainly not as secure as 256. It seems to have a bit more open UI, however, letting users execute scripts on it. It’s also more oriented toward online shares and network storage – so if you want to put encrypted files on online repositories, AxCrypt may be the one for you.

PGP – The third tool I’ve been looking at is Symantec’s PGP. Unlike the other two, PGP costs – roughly 90USD per license. What do you get for $90? Well, it looks like it’s not a bad piece of software. As with TrueCrypt, Whole Disk Encryption is an option. It also has centralized management options, so it seems the best of the three for large-scale implementations. In addition, it has a host of certifications, notably FIPS 140-2 compliance. If you’re in an environment where that’s required, this is likely the way to go. While the online information is not immediately forthcoming on encryption algorithms, FIPS-140-2 compliance means that at minimum it offers AES-128.

For my purposes, I’m likely going to use TrueCrypt. AxCrypt and PGP both have their place. But the most important thing? Implement something. It’s easy to put off such a step, but you never know when your mobile device might be lost or stolen.