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

The buzz around smartphone and tablet app hacking has started to increase even more since the beginning of the year. But also making some waves in recent weeks has been the application of existing technology to allow vehicles to communicate. Automobile companies have been in the news lately concerning the Vehicle-To-Vehicle (V2V) communication system. This tech basically allows cars to communicate signals to each other over a dedicated wireless infrastructure (the implementation of which is actually being funded).

Among my concerns was the idea that such an infrastructure might attract the curious-minded. Certainly there would be concerns over privacy (tracking?), spoofed signals, hijacked systems, and other shenanigans. If manufacturers embrace this on a wide-scale (perhaps if it becomes a safety requirement), and if it is implemented while making security a priority, the result could be a welcome addition to the safety capabilities of modern vehicles. On the other hand, if security is not properly taken into account, the result could be yet another potential target for attack and exploitation. Either way, for now, we can only speculate on what future automobile hacking may look like. After all, it’s impossible to know how secure it is until the technology is ready, in the field, and smart people start poking at it.

Sometimes you receive an encrypted e-mail that you can’t open. I don’t know about other clients, but Outlook doesn’t allow you to do much with e-mails that aren’t encrypted for you, and if you’re like me, you want more information. You want to know exactly what went wrong. So, here is a quick way of retrieving the information you need from an Outlook e-mail in order to find out which certificates were used to encrypt the e-mail.  (Note: This method may not always work, but I have found it useful many times in the past.)

(more…)