Black Hat Briefings have been going on all this week, with the expected announcements of vulnerabilities, tools, and other fun. I refuse to go to Vegas for health reasons, so I often miss out on Black Hat and Defcon. But this week, the one announcement that has me interested is that SMS messages are being used to unlock cars and start them – specifically the Subaru Outback. They also demonstrated that car unlocking isn’t the only capability that SMS messages have. Pretty much anything that uses the GSM network for communication may be vulnerable – electric meters, traffic lights, GPS-tracking, etc.

With more and more devices being “always connected”, I suspect we’ll see more problems. And these are the kinds of problems that may literally be life and death – turn someone’s heat off on a cold day, start a car in a closed garage, etc. Today, we assume that all Internet sites have a modicum of security knowledge, or someone has at least thought about security. Is the same true for these new technologies? In general, the Internet doesn’t control life and death – yes, it’s annoying when someone steals your credit card number, but you’re not (likely) going to die from it. These new systems are – and I suspect that security hasn’t been at the top of the designers’ minds.

The UCLA Health System was just fined $865,000 for HIPAA violations.

That probably sounds like an awful lot, but in truth it isn’t. It’s awfully difficult to find exact figures on regulatory fines – companies tend to be rather tight-lipped on the subject, after all. But on the scale of companies and business fines, and knowing that companies in general, and hospitals in particular, are generally good at cushioning themselves against such damage, it’s just not that much.

Also, HIPAA is considered something of a paper tiger. Although HIPAA was passed in 1996, there weren’t any fines issued until 2006. While there have been quite a few fines and even criminal prosecutions since then, and the UCLA fine is the third “large” fine in 2011 – the largest being $4.3 million – that’s still not all that much on a business scale.

However, HIPAA compliance is a major concern for healthcare providers; a concern which is far out of proportion to the expected costs of non-compliance?
Why? Are all hospitals, insurance providers, and private practices that concerned with patient privacy?

I’d like to say yes. But, cynically, my time working at a hospital tells me the real reason: they don’t want to undergo an inspection.

HIPAA originally set the maximum fine for each individual violation at a mere $100, with the maximum possible fines being $25,000. Those limits were raised in 2008, and there is a risk of criminal penalties to boot, but that’s not the biggest risk, nor the biggest potential cost.

Each reported violation can trigger a HIPAA inspection. Inspectors can look over the entire facility, from top to bottom, looking for each and every violation. The costs involved in such an inspection, in terms of disruption to the facility, far exceed the possible fine involved.

The numbers don’t tell the whole story with HIPAA. The fear of an inspection has motivated hospitals throughout the nation to adopt far more secure practices with respect to medical records. While there can, and will be, data leaks, HIPAA is more effective than it seems.

Disclaimer: I am *not* a mathematician. I just happened to take a Number Theory class from an awesome professor (Dr Blakley) at Texas A&M.

When I took Dr Blakley’s Math 673 class, I was in over my head at first (and probably still would be if I hadn’t seen the applications of the topics in his class since taking his class). Unfortunately, I graduated and didn’t get to take the second part of the course, which friends told me was just as good as the first part. We learned about polynomial math, and at the time, I had no clue what it could be used for…. Then a friend linked me to this awesome stick figure explanation of AES. Once again, I remembered seeing this “math” in Dr Blakley’s class. We did a lot more with it than the AES description shows (but I couldn’t tell you what or how).

We first learned finite field arithmetic by drawing the fields and looking up the solution on the “chart.” Then, we moved to making sure that we understood modulo arithmetic. Then, we finally learned how to apply this to polynomials. (I still didn’t get my aha! moment until years later). But, now, I can read (and understand) the stick figure description of AES. It’s worth learning if you want to delve deeper into cryptography, as many cryptographic functions are based on math learned in a number theory class.

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)

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.

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.

Open Authorization (OAuth), the authorization standard centered around the granting of permissions and the exchange of access tokens, has slowly gained more widespread use as a result of its adoption as an API authorization system for large web services (Google, Facebook, and Twitter all embrace some version of OAuth). Although OAuth version 2.0 probably won’t look much different from 1.0a to end users (if they even notice), most improvements seem to be aligned with the needs of a rapidly-expanding apps market. This is not a bad thing. When implemented correctly, OAuth can certainly improve security. Naturally, there would be an interest in simplifying things for both users and developers.

But this simplification comes partially from the lack of signatures (used to protect requests over unsafe channels), and a reliance on adequate transport-layer security. Check the flows.

For comparison, OAuth 1.0a contains 2 main flows:

3-Legged: A complex dance by which an application (SuperApp) asks a server (Twitter) if it can act on your behalf (post some stuff).

2-Legged: A slightly-less-complex dance by which you already gave the application permission to post some stuff, and so it does it whenever it wants.

Both of these flows rely upon the security provided by the message signatures to avoid sharing the important secrets. And if OAuth 2.0 doesn’t provide an option for message-signing, there will always be some applications where OAuth 1.0a has a logistical advantage (especially considering the TLS requirement).

Sure, v2.0 might define some useful flows for specific things, and help improve HTTPS adoption, but OAuth 1.0a is a bit more well-rounded overall.

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.

Back in August, my colleague Tim Donaworth posted about security threats in Android. Smartphone malware and smartphone botnets are buzz phases right now, but when speaking about my research in the field I am often asked, “Will this sort of attack actually happen outside of a lab?” The answer is not only will it, it already has, and is going on as we speak.

Earlier this week Symantec blogged about a malicious Android application found carrying out the exact sort of attack Tim warned about in his post. In short, there was a legitimate application called Steamy Windows that fogged up your screen and asked for reasonable permissions when installed. There was also a malicious version of Steamy Windows that still made the screen steamy, but also infected the phone with botnet software. The only noticeable difference in the two applications was the permissions asked for upon install. The malicious version asked for rights to SMS and personal data. What business does an application that basically gives you a cool, interactive wallpaper have sending text messages?

The security research community has been active in addressing this threat, showing proof of concept malware and recommending security improvements for smartphone platforms. Some examples are Tipping Point’s WeatherFist application which showed a seemingly innocuous application performing botnet functionality, John Oberheide’s Twilight botnet that showed a proof of concept of how to abuse the trust model on the Android platform to load potentially malicious code after application install, and my SMS command and control smartphone botnet proof of concept released at Shmoocon 2011 which resides at the base operating system level and thus avoids having to ask permission from the user to access functionality such as SMS.

Smartphone malware is a real threat to security in the wild. While security measures such as Android’s user accepted permissions for API calls and iPhone’s review process are a step in the right direction, as smartphone malware evolves additional measures are needed. Smartphones can be thought of the same way as computers, in fact they run on very much the same operating systems your desktop computers do. They are vulnerable to the same sort of attacks. For example recently a Linux kernel local privilege escalation worked on Android as well, allowing applications to exploit the vulnerability and gain root privileges on the phone. The update systems for smartphones need attention as these sorts of vulnerabilities are found. Additionally, security functions such as integrity checks should be put in place in the base operating system where possible.

My biggest concern in smartphone security is user awareness. We have made great progress in educating end users about computer security in recent years, but I do not see the same understanding in the smartphone realm. You would never encourage your employees to trust and install every seemingly useful computer application they could find on the internet to their desktops. Instead there is security awareness training about the threat of downloaded malware. However, in the smartphone realm it’s all about downloading applications. Buy our phones because we have better apps than anyone else! Buy the app I wrote so I can retire on a private island! Users need to be made aware that everything downloaded to a smartphone can be harmful, that a link in a text message can hurt you the same as a link in an email you are warned against clicking on. Until the security and user awareness postures of smartphones get up to speed we will continue to see the same sorts of successful attacks in the wild.

What’s the single biggest threat to your security posture? Hackers? Corporate espionage? SSL Vulnerabilities? Zero-day exploits? Maybe insufficient funding for proper risk assessment?

No. The biggest threat to security is post-it notes and random boxes. Seriously. Because these are the tools that your own employees use to make their daily jobs easier. Your own users, with no malice, regularly compromise security every day. Odds are, they train new hires to do the same thing. Why are they undermining your work? To put it simply, they’re undermining your work because you are unintentionally undermining theirs.

Imagine that you’re very worried about security. You put in place a policy requiring Very Strong passwords: 14 character minimum, must contain upper and lower case letters, numbers, and a special character. The passwords have to be changed every 30 days, and no re-use. That’s not a hypothetical: I’ve worked in an environment with just such a policy. What happened? Well, very few people wanted to, or could, readily memorize such a password. And changing passwords so frequently was, putting it mildly, a nuisance. So nearly everyone wrote down their passwords. Some used password vaults on their phones, but most used, well, post-it notes. Which meant that anyone who wandered into the office could find out half the passwords. Weaker passwords which the users could remember might have been more secure!

(more…)