A vulnerability demonstration this week involving a technology that’s generating buzz reminded me of an important concept: Security is as much about implementation as the underlying technologies you use. You can put together several “secure” components and still build an insecure system.

The example that reminded me of this relates to Bitcoin, a somewhat controversial form of digital currency that’s recently been discussed by several high-profile media outlets. I’m not going to talk about any specific merits or problems associated with Bitcoin, but note that it relies on mathematically solid encryption schemes to allow transactions while preventing theft.

However, regardless of how strong your encryption, an insecure application using that encryption can introduce easily exploitable vulnerabilities. And Adam Baldwin of evilpacket has shown how this can happen with Bitcoin by creating a video demo of XSS/CSRF problems in a Bitcoin exchange site. These application-level issues could enable an attacker to steal Bitcoins without cracking the basic cryptography employed.

Using proven security technologies is important, but it’s only one part of securing your organization. I still remember my surprise when I first discovered that an “unbreakable” cipher did exist: the one-time pad. But using one-time pads is often impractical, and they are still susceptible to compromise from human factors. Building secure business operations requires understanding the risks at each level of a system and having a defense-in-depth response.

At Gemini, we can help you assess those risks, architect strategies to handle them, then apply those solutions in your organization to produce measurable security improvements. Don’t simply trust in “encryption” or WAFs to protect your data – let us help you understand the big picture of your company’s security today.

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.

While the software industry continues to make strides in the area of security and data protection, the hardware industry shouldn’t be underestimated. With the announcement of storage devices like Toshiba’s MK-61GSYG hard disk drives, it may only be a matter of time before we see even more creative security features for hardware (due, in part, to industry-wide adoption of standards). Toshiba’s harddrive comes with some interesting security tricks, including the ability to configure the disk to erase itself when connected to an unauthorized host, and the ability for the drive to self-encrypt without relying on the host computer’s operating system for cryptographic operations.

Most of the features are drawn from the standards found in the Opal Security Subsystem Class (SSC) (pdf). The SSC is, in turn, based on the TCG Storage Architecture Core Specification. TCG is the same company behind the TPM platform standard, which was designed to let a system create and operate a trusted subenvironment from within an untrusted environment. The TPM platform still receives a fair amount of criticism for privacy issues and the potential for abuse.

A similar approach is used for some OPAL-compliant storage devices: dedicated on-board hardware that can handle a range of specialized operations (maintenance, authentication, cryptography) independently. The result is hardware like the MK-61GSYG, which probably meets many storage security requirements right out of the box. Although much can be said of the controversy that can surrounds newer standards, they can certainly provide a welcome stepping stone for innovation.

A few years ago, I wrote a post about “the power of s” explaining how important it is to use https instead of http, and how that made things more secure. Strictly speaking, what I wrote then was true. It’s very important to implement SSL, and SSL can indeed make communications secure. But it’s more complicated than that. SSL is an excellent tool which allows secure communication if it is implemented correctly. A bad implementation, however, is no more secure than sending data via clear text. And it’s awfully easy to have a bad implementation.

Ciphers are a good place to start. A cipher is the method used to encrypt a message. It’s the basis for most of what we tend to think of as security. But not all ciphers are created equal. Some are simply not secure. DES, for example, while having no particular vulnerabilities, does not allow a long enough key to be secure with modern computing. Not coincidentally, this problem with DES demonstrates that even a secure cipher like AES can be rendered ineffective if an inadequate key length is chosen. Figuring out what key length – and comparing key lengths – takes in-depth understanding of the cipher in question: 3DES with a 128-bit key is comparable (though not equal) to RSA with a 2048-bit key!

After ciphers, there are hashes, message digests, and signatures. These authenticate a message and assure that, encrypted or not, a message came from the source which it claims to have come from and that the message was not altered in transit. These are all crucial for preventing “man in the middle” attacks by which a third party can take over communication. As with the ciphers themselves, the algorithms used here are very important, and many have been proven to be insecure.

On top of that, there is the matter of certificates. Certificates play an important role in proving the identity of each end of the communication, and determining who to trust. However, recent events have proven that the certificates themselves can be insecure, either due to poor design or compromise of the certificate authority.

These are the basic concerns entailed in implementing SSL. Would that it were really so simple. Unfortunately, the real world throws in greater complications. The truth is that implementing SSL properly relies on the options made available by the hardware and software vendors. They may not have implemented every possible cipher; it may not be possible to load custom certificates. The certificates in use may not be able to negotiate shared keys… the list goes on. And that assumes using something like a unified solution. Inevitably, almost any IT environment becomes a heterogeneous environment. There is always a particular piece of the puzzle – firewall, a management tool, a server – that simply must be from some other vendor. And these parts don’t always work well together; often the only option by which products from two different vendors can communicate at all turns out to be decidedly less than secure. On top of that, even if secure options are available, and all the various parts can use the same ciphers and other components, there’s the administrative overhead: sure, it’s possible for each SAN switch to have a certificate, but do you have the resources to administer certificates on more than 500 of them?

The more I’ve learned about SSL, the more I realize how difficult it is to truly engineer a secure solution. Doing so can require fundamental and sweeping changes to an IT infrastructure and may take months or more to enact. Of course, anyone who cares about security should implement some form of security – but it’s important to remember that not only is it not as simple as changing an option in a control panel, it’s often as difficult as engineering the infrastructure in the first place.

Last week there was talk of an information breach affecting customers of several large corporations, whereby names and email addresses may have been leaked through a marketing company (Epsilon).

Even without knowing all of the minute details, there are some important things to take away from this:

• Large pools of consolidated personally identifiable information are huge targets for would-be attackers
• Those you trust with your trusted data might not be as careful with it as you’d like them to be (applies to both customers and companies)

But, although there is much to be said of the risk we all take when we share private data, perhaps the bigger issue is the fact that companies hound you for your personal information in the first place. I can *maybe* understand a bank or financial institution needing to know a reference phone number or an email address to send you account information. But Walgreens, Kroger, Eddie Bauer; do they *really* need my personal contact info?

I once had an airport kiosk salesperson to verbally question whether or not I gave him my real phone number on the questionnaire that I filled out to get a “free” prize. I fraudulently reassured him that the last 4 digits were “3210″, and I half-expected him to whip out his phone and double-check.

But not every company is out to spam you to death. And I’m sure there are many people who don’t mind being marketed to (especially by their favorite brands). But for those of us who are asked to give up our email addy at the checkout counter, what can we do to shield ourselves from the inevitable mishandling of information we might not even want to share?

Far be it from me to suggest that *other* people willingly give out inaccurate information, but I regularly switch my phone number digits around and give out the wrong domain for my email (apologizes to my hotmail address twin). Even without resorting to harmless chicanery, there are things we can do to protect some of our important data. For example, disposable email addresses are great for keeping spam out of your real inbox, and have the added benefit of being valued lower by attackers than, say, a business or government account. After all, who targets mailinator accounts? Or, if you have the technical chops, an option may be to sign up with a call-forwarding service (like Google Voice) in order to cloak your actual phone number.

In other words, consider giving out your personal information on a need-to-know basis. Even then, we may have fewer options when it comes to protecting data a company creates in-house about its own customers, or the details associated with payment card purchases. But then again, that’s why we have standards like HIPAA and PCI-DSS…

Over the last few months, many people have talked about using HTTPS with sites such as Facebook and Twitter. The technology came up often after the release of Firesheep, which allowed Wi-Fi users to hijack other users who used these sites without HTTPS.

Part of the technology behind HTTPS are certificates – small electronic files that help your browser ensure it’s connecting to a trusted site and protect the connection from eavesdropping or tampering. For instance, when you visit https://www.google.com, the Google server has a certificate that lets your browser know it’s connecting to Google and not an impostor.

But how does your browser know if the certificate is not also from an impostor? Each browser maintains a list of certificate authorities, or CAs – special servers whose main purpose is issuing certificates for all those HTTPS websites. These CAs may also vouch for other authorities, creating a hierarchy of trust. If you access a site whose certificate is not from one of these authorities or has been marked by one of them as revoked, you’ll get an error or warning about a certificate problem. Ideally, all of the authorities are all trustworthy and only issue certificates for reputable websites.

Unfortunately, the current reality is less than ideal, and attacks can happen. Yesterday, a blog post from the Tor Project detailed research showing that two major browsers had quietly added code which blocked a few specific certificates. These certificates were issued by an authority in a hierarchy controlled by Comodo, who released a statement today providing a bit more information on what happened.

According to Comodo, attackers were able to access the account of a user who helped manage one of the servers for issuing certificates. They then created their own certificates for verifying websites from Google, Yahoo, Skype, and others. These fraudulent certificates could be used to make a user’s browser think it was connecting to legitimate sites when actually communicating with a malicious site.

Comodo stated that many of the attacks appear to be from Iran, and has said they believe the attack to be state-driven, but many details are still unknown at this point, and the situation calls into question several aspects of Comodo’s security policies. In the meantime, you should make sure you’re using the latest version of a modern browser, such as Chrome or Firefox, and avoid connecting to untrusted networks. The fraudulent certificates that have already been identified will be blocked by an updated browser, and we’ll have to wait and see if more fallout results from the attack.

Yesterday, I started getting a bunch of warnings from the anti-virus program I’ve got installed on my Mac – F-Secure Mac Protection Technology Preview. Since I wasn’t doing anything out of the ordinary or perform any “suspicious” behavior, this was a surprise to me. (Especially considering I had only received one virus alert from the software in the last 3 months.) The below is a screenshot I grabbed shortly after this began.

Every time I loaded a web page in my browser, a bunch of files would be detected and be automatically removed by the software. If I restarted the Google Chrome browser, the anti-virus deleted a critical enough file to cause Chrome to crash. Within about 20 minutes I had disabled the software and then set about trying to report it as a problem. (Notably this software does not have an option in the user interface to disable the anti-virus capability. You must run a very obscure command: sudo launchctl unload -w /Library/LaunchDaemons/com.f-secure.fsavd.plist)

What happened in this case is that the F-Secure beta software had a false-positive error, causing most if not all files to be flagged as having a virus. The F-Secure software automatically sends files to the trash when a virus is encountered and only provides the above notification window. There is no quarantine, and there is no way to restore files that are deleted.

What is notable is that I didn’t follow standard procedure. Normally when a user encounters a virus warning, the first thing they do is to scan all their files.  Since I immediately had a hunch that it was just broken, and I disabled it, I saved myself a lot of trouble.  Take a look at the pain being experienced by some of the folks in the forum posts:

I scanned my whole system and now I’ve got 90 000 files in the trash. I’m really waiting for an automated solution for this… To me this is a critical situation.

As one of the forum members noted, this is the worst possible scenario for an anti-virus software maker. While F-Secure has posted a fix along with an apology they have not yet answered my fairly critical question in the forum – how do I tell the fix has been applied? They also don’t yet have any capability to help users restore their files accidentally deleted by this error. Based on my experience, I don’t think I’ll be able to give this software a second chance.  Can you suggest alternatives?

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.

One of the primary weapons in a developer’s arsenal for stopping cross-site scripting (XSS) is output escaping. If an attacker can insert special characters into a page (such as < and >), they can potentially add new HTML or JavaScript and wreak havoc. By escaping data rendered by a page, you can change < to &lt; – the latter still gets rendered by the browser as < without creating a new HTML element.

However, it’s important to understand that this defensive strategy must include the concept of contextual escaping. That is, what characters you escape and how you handle them depends on the context of the output.

For instance, simply escaping or filtering every < and > is generally not enough to protect a web application. I’ve seen mainstream sites that escaped these characters, but then left quotation marks unchanged. When a parameter is rendered as HTML, " or ' may seem rather harmless. But consider this bit of code:

<script>var x = "parameter value";</script>

If the parameter value rendered here included a quotation mark, it would complete the variable definition and the rest of the parameter could be executed as JavaScript. I was reminded of contextual escaping’s importance just this week when I read this example of an XSS vulnerability in the password manager LastPass. In this case, the application properly escaped quotation marks in a script context, but still allowed characters that could close the script element and add a new one.

The OWASP XSS Prevention Cheat Sheet includes more details on characters to watch for in several common web app contexts. And remember that XSS in a JSON interface or iframe widget can be just as dangerous as obvious XSS in a search results page. Take note of where your application outputs data and make sure your XSS defenses match each context.