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…)

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.

This week’s questionable security breach reporting comes courtesy of the Daily Mail, regarding the compromise of accounts on Citigroup’s web site: http://www.dailymail.co.uk/news/article-2003393/How-Citigroup-hackers-broke-door-using-banks-website.html

The “attack” (if you can really call it that), required a logged in user to simply modify the URL of an authenticated session to change a plaintext URL parameter containing their account number to another account number. That was all that was required – no coding, phishing, social engineering or other technique that requires any thought was needed. Anyone with a rudimentary understanding of how URL parameters work could have figured this out. I’m amazed nobody figured it out sooner.

What bothers me about the article, though, is that the “expert” and law enforcement representatives who are quoted make it sound like this was a sophisticated intrusion.

One expert, who is part of the investigation and wants to remain anonymous because the inquiry is at an early stage, told The New York Times he wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser.
He said: ‘It would have been hard to prepare for this type of vulnerability.’
…
Law enforcement officials said the expertise behind the attack was a ‘sign of what is likely to be a wave of more and more sophisticated breaches’ by high-tech thieves.

(Emphasis added)

Nothing about changing a plaintext URL parameter requires expertise, and it would have been trivial to prepare for that kind of vulnerability. It’s nigh unbelievable that a financial institution would have such a bad security implementation, although if this is the state of expertise in this field, I suppose I shouldn’t be as surprised as I am.

I recall back in the 80s, when “computer virus” was a new term, “antivirus software” hadn’t been invented yet, nobody had coined the term “malware”, and Apple was still running incomprehensible TV ads.

It’s ironic: Apple computers were the predominant home computers when computer virii and malware were invented. And yet, the first malware kit for the MAC OS (or, more accurately, OS X), Weyland-Yutani BOT, was only released earlier this month. For obvious reasons, I’m not about to download it and play around, but preliminary reports indicate that this kit may have caused a significant increase in OS X malware. And supposedly, kits for iPad and Linux are just around the corner.

To be honest, I find the iPad more disturbing. An increased awareness of mobile OSes in the black hat community can only mean more malware for those platforms. Various experts have been predicting widespread malware in mobile devices like phones and tablets for some time now. With the release of Weyland-Yutani BOT, we’re that much closer. The exact development cycle for such kits is hard to pin down, but a spike in mobile device malware is likely in the very near future. If you haven’t already, now would probably be a good time to look at anti-malware for all of your computing devices – Weyland-Yutani BOT is just the beginning.

As you’ve doubtless heard, Sony’s PlayStation Network has been down for several days now. The exact cause of this outage, being apparently affected by hackers of some stripe, is doubtless worth investigating. However, since those details haven’t been fully divulged yet, it’s best to wait on that front.

But this brings to light an increasing problem: the erosion of standalone functionality. PSN customers have not been able to access online content since April 20th. This is, of course, to be expected – if you shut off the network, the network is not available. Unfortunately, this extends to content which isn’t actually hosted on Sony’s network, since PlayStations use the PSN to connect to outside servers. Still, though, not surprising.

Vexingly, however, a certain amount of offline content has also been rendered unavailable, specifically several Capcom games which apparently need internet connection even for single-player mode. This seems to be an increasing trend in the software industry, in games of course, but in other software as well. Even software which has no need to be online, such as a word processing suite, increasingly needs to authenticate with a server in order to install. In fact, you might have noticed that most builds of MS Windows have just such an authentication requirement. And this is continuing to the next level: the Google CR-48 laptop as almost no functionality without an internet connection. Woe betide the user who truly does not want to ever connect a machine to the Internet!

But why would someone want to keep their computer offline?

Well, security, for one. The “airwall” remains the strongest form of security available; no code can ever bridge the gap of a true lack of connection. This isn’t solely the province of super secret government facilities, after all: medical facilities, industrial applications, and numerous other facilities can achieve higher security by dint of simply not connecting machines to the Internet when it is not needed.

Some may not be able to achieve an Internet connection, either due to cost or lack of infrastructure. As amazing as it may seem in 2011, Internet access is not available everywhere, nor to everyone.

But the most important reason is highlighted by this PSN debacle: why should Internet access be necessary? The Internet is a powerful, pervasive tool – but it’s not the end-all of the computing experience, and even now there’s no reason that a computer should be rendered a paperweight by simple lack of connection.

Comptroller Susan Combs offered another apology Thursday for the information breach in her agency, saying she now is offering a year of free credit monitoring to the 3.5 million people at risk of identity theft after their data was exposed on a public computer server…She announced in a written statement April 11 that the Social Security numbers and other personal information of 3.5 million people were left exposed for a year or more in a publicly accessible computer server at her agency.

Dallas News

According to this article in the Dallas Morning News, 3.5 million identities were left free for the taking on a public server for at least a year. That is a colossal security lapse. However, it is a fairly responsible remediation that credit monitoring is being made available for the affected users. (Contrast this with Sony’s recent Playstation Network breach; Sony won’t even confirm whether or not credit card information was accessed in their attack.) Still, had literally any effort been put into keeping that information secured, the state of Texas wouldn’t have to spend an estimated $21 million for the credit monitoring services.

The security arena is one in which the maxim “an ounce of prevention is worth a pound of cure” holds especially true. How much would it have cost to audit that server deployment? A few thousand dollars? Tens of thousands of dollars? Hundreds of thousands? Any answer less than “21 million dollars” means that this should never have happened.

If you’re interested in online security, you’ve probably heard about HBGary.

If you haven’t, here’s a brief rundown with a few links:
A security firm, HBGary (or, more accurately, HBGary’s subsidiary HBGary Federal) announced that they had discovered the names of some of the supposed ringleaders of the “hacktivist” organization Anonymous.
This “angered the hive” and – rather than the generally low-risk and unsophisticated DDOS attacks for which Anonymous is better known – Anonymous used a combination of social engineering, SQL Exploits, and password cracking to compromise one of HBGary’s servers. They leveraged that to get into multiple servers, ultimately gaining access to HBGary’s email and no few internal documents – including business plans and proposals to potential clients.
Anonymous then published the information they found – all of it. This embarrassed and scared off most, if all, of HBGary’s potential clients, ruined ongoing negotiations, and exposed activities which indicated questionable ethics and which might be illegal.
HBGary’s actions after this compromise might charitably be called “unfocussed” or possibly “unplanned”. “Foolish” or “Crazy” would possibly be more accurate. The HBGary CEO even engaged with some Anonymous members via IRC, to dubious results. Perhaps the best testament to this incident is the current state of HBGary Federal’s website.

Remarkably, there aren’t any new lessons to be learned here.
HBGary Federal’s first mistake was in taunting Anonymous: no matter how secure you think you are, you’re better off WITHOUT people trying to break down the gates.

The second mistake was in underestimating the enemy. Although Anonymous as a group has mostly engaged in DDOS attacks, they did so using a modified version of a professional load-testing tool: clearly some of their members have always had access to such tools and the ability to modify them. In other words, at least some of Anonymous are clearly highly capable.

The third mistake – or rather, set of mistakes – was likely the most common. HBGary’s infrastructure wasn’t properly secured. They were vulnerable to social engineering, and an important server could be compromised with an SQL injection exploit, and – worst of all – the attackers were able to use that one compromise to access nearly everything else. This is not a very good security posture, especially for a security firm.

Lastly, they didn’t have a recovery strategy. While this sort of compromise is one of the worst-case scenarios, it clearly behooves a company to plan for it, at least in a general fashion, and respond in an organized fashion which helps rebuild client trust and reduce the damage.

While these aren’t new lessons, it’s still worthwhile to look them over again: don’t encourage attacks, maintain a realistic awareness of the attackers you’re facing, harden your infrastructure, and have a recovery plan. Remember that it CAN happen to you, and act accordingly.

Last week, we received a fax at the office from a branch of Virginia Commerce Bank. It was addressed to “Katie” and had our fax number clearly written on the cover sheet. The cover sheet had this interesting quote:

This facsimile, which may contain confidential or legally privileged information, is intended for the use of the individual to whom it is addressed only. If you are not the intended recipient (or authorized delegate for the recipient) of this message, please telephone the number listed above to advise us, so that we can arrange for its proper destruction and resend it to the correct recipient. Thank you.

It probably goes without saying that there isn’t a “Katie” working here at Gemini (yet). So of course we called the number to let them know we had received this fax in error. It took my office manager over 30 minutes on the phone to get through to the appropriate person to ensure that it was understood that the information went to the wrong fax number. We followed their instructions explicitly, but nobody at the bank seemed to know what to do. Ultimately it wasted our time.

What was in the fax? The materials attached were an absolute treasure trove of information. Names, addresses, phone numbers, birth dates, social security numbers, drivers license numbers… and that was just on the first page. A copy of two driver’s licenses. A copy of two credit cards. A letter of incorporation, a federal EIN, and copies of two credit reports.

This is more than enough information to steal the identity of two individuals and one business. And the terrifying part of it is that nobody would have been the wiser if we didn’t take the time to phone the bank to let them know we had received the information in error.

Which brings up an interesting question. Should we have called the bank? Sure, I feel bad for the individuals and the business who are having their most private information sent via fax. Their information couldn’t be in better hands though – we know better than to do anything with this information, and we securely shredded it. On the other hand, because we called them the bank now has a record that they accidentally sent us this information. If these individuals suffer identity theft, wouldn’t they immediately consider us a suspect?

In these days of heightened concern about identity theft, why are banks still using insecure transport mechanisms such as faxes without even bothering to call the recipients to ensure successful delivery?

Although we’ve made many posts about the importance of password security, have you ever wondered just how long it would take for a well-equipped attacker (having access to clusters or supercomputers) to brute force your password? Or how much more protection you gain from adding some special characters?

If you’re not inclined to crank out the numbers yourself, you might find the answers you’re looking for here.

Here are some basic stats:

• With access to super-computing-like power (trying over 1 billion per second), it only takes about 84 days to crack the common 8 character password (alphanumeric mixed case, including special characters).
• With access to a less powerful class of attack machines (10k per second), without including special symbols, an 8 character mixed-case alphanumeric password would need 692 years to brute force completely.
• Numeric-only passwords are low-hanging fruit.

The data only takes into account the maximum time it would take to brute force a password by exhausting the key space. It does not include tricks or techniques someone might use to optimize an attack. The most significant factor in the success of this approach is the use of the hardware. The price, availability, and power of hardware have a direct bearing on the protection offered by the typical single-factor password authentication scheme. In addition, as technology improves, the barrier to entry for brute forcing will drop, potentially allowing more would-be attackers to try their hand at it. Also, botnets dedicated to brute forcing passwords will get faster as the hosts (typically infected PCs) that comprise their processing power become faster. The golden standard “8 character alphanumeric+special” password is already within reach of a well-funded attacker (and has been for a while).

If you haven’t already, it may be time to start picking longer passwords for important accounts.