Jinxed It

...So I write a blog post about security awareness and the following week LinkedIn publish details of a hack.

I've not found official confirmation yet but it sounds like they were hashing data items such as passwords with SHA-1. Which could be classified as a weakened encryption algorithm on it's own, but LinkedIn may not have been salting passwords.

I've also found another potential vulnerability across devices / platforms after changing my own password on LinkedIn. Will let them know and hope they add that to the list. Doesn't look like a big problem but could create an attack vector in < 1% of scenarios.

If you're affected by this situation I'd recommend the following for browser-based applications:

1. Don't use "password", "123abc", "123456" or your own name as your password. Don't use the same password across different applications / accounts
2. Change your LinkedIn password (if you haven't already done so)
3. Change it again in a week and then the following week. If the people at LinkedIn haven't shored up the breach in defences there could be following penetrations
4. Change your account password on any related email address accounts that are held on your LinkedIn account. Double defensibility probably isn't necessary but is a good idea
5. Always hit the "Log Out" or "Sign Out" button / link when you're done instead of just closing the browser window
6. Don't have Facebook, Gmail / G+ / etc, Hotmail or Twitter open at the same time as LinkedIn in the same browser, just in case there's a potential XSS or XSRF vulnerability across any of the applications

"He's just paranoid!", I hear you say. Guess what - Sony got hacked again this week so what's to say we won't see repeats here either?

Update - 5th July

It took LinkedIn four days to get back to my initial report / request for contact, guess they must have been pretty busy at the time *cough*. Essentially the response was "There's nothing to see here, move along" and when I retested about a week later I couldn't reproduce the problem.

Bottom line, problem fixed. From everything I've been reading in the press about the company it's been a policy of denial in an attempt to save face.

Sign of the Times

There's more and more incidents in the public domain where a security issue has seriously tarnished an organisations brand identity. Worst still is the simple fact that it could have been avoided in most cases.

Some of the most notable in the last 12 months that I remember were when the MySQL website was taken down using a SQL Injection attack vector, and the more recent PHP exploit on militarysingles.com (link takes you to the Imperva report PDF).

"Why are these such a big deal?", you may ask. Well from a distant perspective the former details an organisation (now owned by Oracle) who specialise in database systems. Even though the worst effect for customers was to have their details taken and published, it wasn't actually a vulnerability in their product. It was down to the website team not approaching the project with defensive coding in mind.

It was a political coup over brand identity.

The latter example (militarysingles.com) is both an exploit of a vulnerability as well as a lack of defensive coding for the particular scenario in question. The problem there is that gaining access to customer data in this instance means potentially sensitive information on military personal across the globe.

It's almost as if there's a lack of general awareness about key issues, and I can only draw from first-hand experience of contact with developers. For instance, I've done over 200 telephone and face-to-face interviews in the last few years for what is effectively around 30 or 40 actual roles. It's hard for me turning down applications from good developers when we find them but we're after a very specific skill set and way of thinking - especially with regards to security issues or vulnerabilities.

Hypothetical interview question: Array processing and sorting, with the ideal being some sort of pseudo-code or algorithm that details specific mechanisms or sorting. The answers to this vary but most people seem to respond with LINQ extension methods that do it all for you, without any real explanation. As an interviewer it's best to give as much chance as possible so you take the toys away and ask the question again (this time, only using .NET 2.0, or just C if it's familiar).

It's not really about the answer so much as how you come up with a solution but it's also surprising how few people think at this level. It's like all the available frameworks have dumbed-down general technical knowledge. Yes, they're useful in given situations and, yes, they make developers lives easier...But easier doesn't mean better*.

We used to ask a set of questions almost made up on the spot, but that's evolved to a question list - Some candidates recently made comments about some of them being straight from the interweb so I've added a few more different ones over time.

Some questions relate to defensive coding practises and are quite revealing in terms of the level of awareness of these attack vectors. Very few developers seem to know any more than how to prevent SQL Injection in .NET, and throw in a few answers about SSH, firewalls and DDoS mitigation. The last three are good to be aware of but only the third could be dealt with in any way by some development work - It's usually better to get something like RioRey or BlackLotus on the case.

Even the basics will only get you so far - The classic is hashing stored data. Great, but the other guys have read the same book and can break it. MD5 stopped being effective nearly a decade ago, even SHA-2 will have a shelf life defined only by "the other guys" intelligence. Maybe processing power too. CrackStation has a pretty good article actually explaining not only how but why.

At my current employer we have to take the topic very seriously - We're a global organisation who is a big target for black hats, hacktivists, competitors, money launderers and other such activity; so if there's a security problem it's got to be dealt with there and then. The sources of the majority of attacks are unsurprising, as are the sources of screen-scraping attempts. I supposed psychologically if it's not a physical attack, it's more difficult to easily quantify - which can make it more difficult to justify the additional expense for shoring up the defences to the board of directors in some places.

However, RSA were actually physically broken into and later some of their clients had their systems compromised as an indirect result. [RSA Labs has a pretty good collection of docs + discussions here]

There's always something out there that you don't know about - No system is impregnable when faced with a sufficiently well motivated and financed group of people - but you can do a lot to ward off and discourage the majority of infiltrators.

You / me / an individual can't know everything, that's why having a good team is important but here's a good place to start... OWASP (have a read of the reference area)

*(Comments about knowledge levels are generalisation only, there's a huge number of really good developers and specialists if you're lucky enough to find and hire them)