Hakin9 magazine exposed by security researchers

Speaking as someone who has recently received multiple requests from hakin9 to contribute articles to their magazine, I found this article on The Register very entertaining.

I received a request from hakin9 (at the time I hadn't heard of their website or magazine) asking for an article on achieving the CISSP certification. I was interested and replied asking for more detail on what they were looking for. They responded but I was busy and never wrote anything for them.
Then a week or so later I received another request asking me to contribute an article about SNORT but it seemed to me that whoever had written the request didn't really understand what SNORT was - which I thought was odd and forgot all about it, until someone sent me the article above. Enjoy!

Hooking the big one?

A sensitive computer network belonging to the US government has been compromised in a targeted spear-phishing attack - as reported by Bill Gertz on the Washington Free Beacon's web site.

Additional write up on CNET News.

Both stories say that China was behind the attack, but this brings to my mind the problem of attack attribution in this kind of situation. The only evidence the articles cite is that the attackers "used servers located in China". How easy is it to rent hosting space in a Chinese data center and attack the US, in order to make it look like the Chinese are behind it? I'm not sure. Wouldn't Chinese state-sponsored hackers use a third party country to avoid attracting attention? Or maybe that's what they want us to think?

Virgin Mobile: a case study on how not to implement password authentication

This article caught my eye today. Virgin Mobile shows everyone all the places you can go wrong when implementing website password authentication.

The good side of this story? I am planning to use this as a case study when discussing web app authentication with our software developers. Not much comfort if you're a VM customer though.

Social Engineering, or "Why I hate so-called Security Questions"

 You may have already read the story of a Wired reporter, Mat Honan, whose online accounts were hacked by an attacker who used social engineering tricks and then wiped data from his phone, his laptop and took over his and his employer's twitter accounts to broadcast homophobic and racist messages on his behalf.

Here's the original story that recounts all of the security failings by Mat himself, by Apple, Amazon and Google in detail.
Here are articles about changes that Amazon and Apple are making to their customer care procedures in the wake of this attack,
and here's a good article which gives a lot of good advice on how to avoid being hit by the same or similar fate.

A lot of the advice in the article has been preached by security professionals like me for years. This story is a great illustration of why I think reliance on "security questions" by businesses as a way of establishing identity of an individual is totally ridiculous in 2012. By "security questions" I mean the type of questions a business asks you like what town you grew up in, or your mother's maiden name or what year you were born etc. etc. The ones they think will really let them be 100% sure it's really you they're talking to. The problems is, anyone can find the answers to these questions about you on Facebook, or by searching other public information sources.

Photo by Dave Delaney on Flickr

The only way that "security questions" can actually work as an effective identification mechanism is if you use intentionally false and random answer that only you could ever know, (and you keep a record of it).
For example, if you set up an account and are asked for your mother's maiden name  - why not answer "geranium", "roulette", or "haddock" (assuming none of those are correct answers for you). Make a note of the answer you've given to this organization, and in future even someone who can google your entire family tree will never find the correct answer in any kind of online public record. You'll be able to supply the correct answer, because you made a note of the answer you gave when creating the account. You did remember to do that right?

In the case of Mat Honan, unfortunately customer service staff gave attackers access to his online account EVEN THOUGH the attackers could not answer the security questions required. So, obviously the method I outlined above will not help you in this case. Check out the third article in the list for other helpful advice that would have helped Mat, and can help you avoid sharing his fate.

Do you have any suggestions of other advice that would have helped? Leave a comment below.

[Updated Aug 8 2012 to add a link to story about Amazon's changes to their procedures after this attack.]

The CloudFlare breach - and what it means for organizations

In July an attack on a content delivery company, CloudFlare, exploited weaknesses in the two-factor authentication systems Google provides to protect personal and business accounts. 

Google issued an update to correct a flaw the proces used to recover passwords which allowed the attack to take place, and the CEO of CloudFlare, Matthew Prince wrote an extensive blog entry about the attack, their investigations, and giving advice to organizations on protecting themselves from the same attack.

The attack highlighted the need for organizations using software-as-a-service email providers to review the "lost password" procedures for their administrator accounts on those services, and ensure that all contact methods they will use to receive messages about password resets are secure and cannot be redirected or accessed without their knowledge.

Another day, another round of password breaches...

Today it's accounts at the website of surf clothing company Billabong, and the online forums of technology firm NVIDIA that are affected. More info here from Threapost.com.

Yahoo passwords breach

News broke today of a breach of almost 450,000 passwords from a service belonging to yahoo.com.
Initial analysis of the leaked passwords appears to show they were stored in plain text, and that they were stolen using a SQL injection attack.

Yahoo said that the passwords were from an old, out of date file, and that only 5% were valid acounts.Whether they were current or out of date, and how many were valid yahoo accounts doesn't matter. Storing user passwords in an unencrypted form puts the owners of those accounts at risk. Period. Although best practice says that you use different passwords for each service you use, we all know that some people use the same password for every single website in their life.

All yahoo.com users should change their password on yahoo itself and on all other sites where they use the same password.