Tag Archives: SSL

Getting things right goes a long way when you are bleeding

I’m starting to see a trend here with the weekend posts. I can stomach most of the FUD during the work days, but things get to me through the weekend. Oh well. There goes a “mandatory” heartbleed post:

Yes, it’s a bad one. No it’s not the worst one. And no – the sky isn’t falling, and the Internet isn’t about to go away.

Heartbleed was one of the most media driven (and ready) bugs in a few years. Logo, website, clear message, and two XKCD strips. The last of which is probably the best explanation to laypersons of what it’s all about.

And did the media catch up on it. Oh yeah… The usual naysayers, FUD-spreading evangelists had their 3.5 minutes of fame. And everyone started recommending that users immediately change their password.

Or maybe not. No! Wait until the site fixes their SSL implementation. Or yes? Ummm, what to do?… That’s where things get interesting.

The real issue here is this: sites affected by heartbleed could potentially be leaking information. And by leaking I mean that anyone with intimate knowledge of the bug could have been, in the past two years, pulling data from those sites. That includes session information, usernames, passwords, and even the private keys used to secure said SSL connections.

Which means that if you think that you were targeted by someone in the past two years, or that your information could have meant something to someone in the past two years with the capability to snoop on those credentials, yes, you should probably do something about it. BUT, and it’s a bug but (yeah, yeah, yeah), you need to remember that it’s not as simple as checking that the website in question has applied the fix. Not even close. If (and again – IF) you believe you need to change your password, you also need to remember that whoever had the knowledge and capability to syphon all that information, was pretty certainly also stealing the server private keys. Initially pundits were skeptical that private encryption keys would be compromised through heartbleed. But as always – if it’s hackable, it will be hacked, and the proof came in pretty quickly.

So yes, there are online tools that will allow you to check whether a certain site had the issue fixed. But these aren’t enough, as you would need to verify somehow (and that’s not easy) that the site also generated a new private encryption key, and got a new server certificate to go with it in to be used AFTER patching the SSL implementation.

Tricky, isn’t it? Yeah, welcome to security…

Anyways – don’t just blatantly go updating your passwords nilly-nelly. First figure whether you really need to, then consider the entire picture: were you exposed just during the time from when heartbleed was announced until the site was fixed? are you concerned about three-letter-agencies that had knowledge of heartbleed and were dumping gigabytes of server RAM so they can get everyone’s data? Then figure whether that site’s private keys and certificates were updated. Then act.

Good luck with that. I’ll leave you with a bleeding heart punch so you won’t need to see that logo AGAIN on a security blog 😛

What the * is wrong with mobile security

Long time no post. Sorry about that <insert favorite excuse>.

Anyway, as you can probably imagine, here’s another rant brewing. We have been dealing with a barrage of mobile application security issues lately, and although I had the feeling that there was a lot wrong with the industry back there I haven’t realized it was that bad.

I mean – it’s supposedly almost the same developers, right? Some Java, Objective C, a little JS/Json/GUI/, the concepts are still the same. Oh, was I wrong. When testing some of these applications, and looking at how they are (much easier BTW that with “traditional” software), it almost seems like we are blinded by the fancy little gadget we got sitting on our desk waiting to be tested, and just push out really crappy code with no apparent attention to how it works, how secure it is, or how does it reflect on the security of the rest of the bank/commerce/corporate security.

Forget all the shortcuts that completely bypass any reasonable process and procedure that are implemented through the “regular” (i.e. web, web services, even client-server) interfaces, and the fact that web services are created to support that.

Forget that authentication is almost thrown out the window when you used to have multiple factor authentication on other channels.

Go back to basics. Ummmm, like, SSL? It has been too many times that you see an “application” that is no more than that hybrid thing Apple allowed developers to do – a few HTML pages that get rendered really nicely on an iDevice, some jQuery and CSS tricks, and maybe even bother through churning the end result through PhoneGap to be like the cool kids with the native apps. Problem is – developers go full retard on shiny things like this. The completely forget the fact that the user’s phone is just like a PC, and is going to be connected to so many non-trusted wireless networks that it’s not even funny to think how much data will be exposed through their insecure plaintext calls.

One thing that really helps developers stay in full retard mode is the lack of any security indication on the device that their communications are done completely in the clear. No bright yellow/red/green padlock that indicates an SSL connection, no API checks to verify that some crypto library is in use if any of the “sensitive” (read: contacts, network access, mail, locally saved data, etc…) is accessed by the application. Nothing.

That’s how we got to a point that sensitive data is leisurely sent unencrypted over non-trusted WiFi connections, along with almost everything you can think of from the phone (GPS coordinates, user information, you name it). That’s how we got to a point where useless web services are opened up (again – no requirement for an SSL connection) on financial/corporate/commercial servers to allow logical shortcuts just because the mobile applications needs to be “streamlined”.

We need to put our foot down and say “no more”. We need both the big guys (Apple, Google, Microsoft, RIM) to have a real certification and testing program for their *Stores that actually look at what the application is doing. We need more logic and more process in the way that applications get developed and commissioned. We need developers to get off the “I need to be at the *Store” mentality, and think like they used to in the sense of “we are going to get so pwned if I put this application out like this”. We need product managers and marketing departments to think if they want to be the next Sonyâ„¢ getting nailed 21 times in a row and still not realizing they are so far behind they need to take everything offline and start getting their stuff together.

We just need to pull our heads out of the sand and smell the napalm. It’s a war out there, and your shiny device doesn’t give a small rodent’s rear-end about your security as long as it looks good.

Rant off, maybe one more post before Vegas. See you all there!