Are you FREAKed out yet?

So maybe you heard about the latest round of security nightmares that plague what everyone thought was secure web traffic.

A few months back it was a serious security flaw in OpenSSL known as HeartBleed that sent webmasters scrambling.  Then came a left field sucker punch when it was discovered that all an attacker needed to do to compromise your entire server (not just a website) was to insert some code that a BASH prompt would respond to. 

Encryption be damned if you have root access to the server!

Which brings us to the latest security gaffe, otherwise known as a Freak attack...

This one has its roots in the earliest implementations of web security.  Back in the days when the U.S. government was so paranoid about not being able to clandestinely snoop on your encrypted communications that they enforced a ban on strong encryption ( aka: stuff they couldn't break.) It was deemed "export-grade" encryption which was just a fancy name for "weak."

They did it by forcing SSL to downgrade its encryption bit strength when traffic left the U.S. thus allowing easy surveillance of all "suspicious" (meaning all) traffic.

Well, as we know from the Snowden leaks there's not much need to worry about borders anymore.  The U.S. has monitoring bases worldwide now.  Besides, the juicy fruit of of the spy game is gathered from far less hardened sources these days.  Just bug a German chancellor's phone and you've got all the dirt you need on the EU.

But let's get back to the problem at hand. 

There are still remnants of this "backdoor" in SSL and because of it millions of websites are vulnerable to compromise using relatively simple "man in the middle" attacks that utilize the facilities of weak encryption still present in SSL implementations.

The worst part is that the problem exists on both the client (aka: your browser) and server sides.  A compromised client and a compromised server are a marriage made in heaven. 

So what's the solution?  Pretty much the same as always.  Keep abreast of security news and patch, patch, patch!  Which is why there were so many Internet Explorer security patches this week.  Open SSL will have a patch available too.

If you'd like to dig a little deeper the following site will let you test both your browser and your favorite SSL secured websites.

https://freakattack.com/

Do it now.

Why Heartbleed Happened

Originally published on Kupeesh!

So what's up with all this HeartBleed nonsense?

What could possibly be behind the greatest crisis in Internet security since the invention of phishing emails?

How could this possibly happen?  What could possibly jeopardize the security of thousands of websites and secure services we take for granted like Google, Tumblr and even banking sites?

I have an easy answer and it points right back to the Achilles heel of Open Source. 

While proponents will argue the merits of solutions that don't come from commercial sources the one inescapable fact of Open Source software is that it's developed under mob rule.

Therein lies the problem. 

While nobody questions the benefits of Open Source software like cost and ease of customization, proponents tend to gloss over the fact that some projects are better managed than others.

Take the case of OpenSSL.  It's the foundation for thousands of web services like Google, Yahoo and even your bank.   Except that somebody wasn't minding the store and for two years the mechanism that was supposed to secure your communications...didn't.

The flaw was inadvertently discovered by Google's Neel Mehta during a routine security sweep but the flaw had been in existence for 2 years.  Overlooked by one of OpenSSL's core developers, Stephen N. Henson, the vulnerability came as the result of additional but apparently untested new functionality known as a Heartbeat for OpenSSL.  The functionality was supposed to function as little more than an "I'm still here!" beacon to whatever service you're connected to.  

The short of it is this...

The problem comes from not bothering to check that what's sent matches what was requested.  A crafty hacker can take advantage by continually sending heartbeat requests claiming to be of a certain size but not actually being that size.  The server dutifully responds by sending back a response of the claimed size to the client and inadvertently dumping the contents of its memory to fill the otherwise empty space of the response.  The contents of which have been shown to contain user credentials among other compromised information.

It's apparently a simple fix but it's taken two years for anyone to notice. 

Meanwhile, nobody knows how long the bad guys have been aware of the flaw.  How can something like this get by the supposed vigilance of security gurus and major corporations alike? 

I can tell you how, it's endemic, it's cultural and it's arrogance...

It's a misguided belief that oversight of a product is best left to a community regardless of its qualifications to do so.  A community that frequently finds itself more concerned with the technical wizardry of its products than the users who deploy them

It's the same mindset that's kept other Open Source offerings like Linux in the shadows of Windows.  Let's be honest here.  You can only stomach so many unintelligible whitepapers or narcissistic support forum posts before you just give up.  The inmates are indeed running the asylum...

Heartbleed shines a light on the failure of the Open Source community in that it lays open the lack of even the most basic oversight of a critical and widely used service.  It's not so much about the failure of OpenSSL but rather that nobody including its chief stewards noticed the problem for two years.

This is nothing less than a reality check on the entire Open Source community.  One that should be raising questions in anyone that relies on their wares.

Breaching your Security Britches

I'm still basking in the glow of the holiday season as I write this.  It's the day before New Year's eve and things are pretty quiet in the IT world.  On the IT jobs front there's a few listings all searching for the "impossible candidate" but most of them are just duplicates from agencies trying in vain to snap up those last few contracts before the Calendar ages another year.

IT budgets are still tight and salaries still aren't where they should be.  Of course if anything's increased,  it's the strain on IT staff.  It's a perfect recipe for disaster as expectations of the impossible become the norm. 

Case in point, the botched rollout of the Obamacare website.  Political motivations aside I knew it would fail.  Not because it's a bad idea but because like many corporate IT projects, nobody bothered to ask the IT guys.  It's a government venture after all, rife with bureaucratic red tape and too many layers of management.  None of which have any  clue about managing a successful IT project. 

To a public convinced that YouTube "just works" and the Internet requires nothing more than a WiFi connection  there's no further deliberation necessary.  The chant goes, "I want this, make it happen next week!"

It's a sad but common state of affairs.  IT departments are far too often under the purview of senior management with a ready, fire, aim philosophy and bad information.

All end users know is that they want more..."something" and increasingly, IT is in no position to say no.  There's even an accepted accreditation, the ITIL, that embraces the premise.  Give them what they want and to hell with the consequences even if you have to undermine the infrastructure to do it.

I can guarantee this is the root cause of most security breaches like those we saw with Target this year and Barnes and Noble in 2012.  They all stem from somebody giving in.  I can just see the exchange now...

IT Guy: You know, we really haven't updated the servers in 5 years and I'm worried about securing our customer data. BigBoxCo just got hacked last week and they've got the same stuff we do.

Accounting Supervisor (his boss): What? did the server's stop working? I got my email today and I was able to get to Ebay...

IT Guy:  No no, they're working fine but we're doing a lot of transactions and there's known vulnerabilities in our encryption algorithms.  We need to address this.

Accounting Supervisor (his boss):  Ok, but the servers are working right?

IT Guy: Yeah but that's not the point...

Accounting Supervisor (his boss): Well, do what you can with that, maybe you can fix it on your lunch break.  Just don't spend any money and for god's sake don't take down the servers for more than 10 minutes. Customers hate that!

IT Guy: Uh, ok but we don't have any failover so that's kind of impossible...

Accounting Supervisor (his boss): Oh, and lets relax those password requirements, I don't like changing it all the time and like to use my dog's name instead.  Maybe you can do that with the customer sites as well.

IT Guy: <sigh> Yeah....

I've had these conversations and they're more common than you think.  So guess who gets the blame when bad things happen. 

You can't have it both ways.  In our example above, the IT guy is right but that has to be balanced against the so-called "business case." 

Problem is the "business case" is often one-sided and incomplete.  That leaves plenty of opportunity for disaster.  It shows up in unexpected service outages, poor performance and workarounds that leave the door wide open for social engineering.

And that's the rub...

Look deep into the root cause of these high profile security breaches and you find out that somebody cut a corner.  It's human nature to want to make others happy.  So when faced with a painful and unnecessarily complex procedure that violates that desire, social engineering takes over.

"Ok, we'll relax the password policy for you"

 or

"Well we don't know much about how secure their servers are but this hosting provider is cheaper.  Oh yeah and they host porn sites so they must know what they're doing with all that traffic!"

Users let down their guard because the bad guys know your process and take advantage of its flaws.  IT guys let down their guard because they don't have the power to say no.  It's the same failing just expressed in different contexts. 

We have IT security vulnerabilities precisely because the way we interact with technology doesn't match up with our nature.  Human nature says to take the path of least resistance and 23 character passwords with mixed case, numbers and special symbols don't cut it.  Yeah, I know there's LastPass but that's a band-aid to the core problem.

So how do we secure anything in the face of all this opposition?

 It's simple, we stop thinking about "enforcing" anything.  Nobody likes to be under anyone's "enforcement."  Instead we start taking into account how people use technology instead of getting in the way of it with some clunky authentication mechanism.

While we're at it, why are we still using payment methods directly connected to bank and credit accounts?  Why aren't pre-paid instruments more popular?  I know the reason, they're a pain to use and like our 23 character password, nobody likes that much "resistance."

You now, it wasn't so long ago you could go to a store and buy things on credit. 

Not Visa or American Express credit, I'm talking about store credit.  You paid your bill every month directly to the store.  No personal information or bank accounts involved.  You just plopped down your money and you were done.

Of course we live in a world where we're forced to live beyond our means which has parlayed itself into ever increased complexity.  Banks and credit card companies have made millions based on the fact that nobody in business is willing to handle their own credit accounts if they even bother to have them.

So there's another feat of social engineering.  Another layer of abstraction between what we're trying to accomplish and what we ultimately DO accomplish. 

Somehow, we've managed to accept the ridiculous as a reasonable premise. 

That's exactly why nothing will change and security will ultimately fail simply because it's based on building a mountain of complexity where a bit of positive social engineering would do far better.

Of course there's too much money in that mountain of nonsense we keep adding to.  Entire industries owe their existence to it and nothing will change because of it.

So you have two choices, live like a hermit and pay cash for everything or accept that till somebody gets a clue there is no security or privacy.

If you need an example, try this...

Imagine you and your 5 year old daughter are at a restaurant for lunch.  A strange man approaches her and offers her candy.  Completely ignoring all your admonitions to the contrary she reaches for it.

What do you do?

It's likely you immediately intervene.  Depending on the threat it can range from tackling the guy to a dirty look.  Either way you took control of your own security concerns and it was a pretty simple process.  Nothing was going to happen without your direct involvement.

Put that in the context of how security works now, however, and you'd spend 10 minutes trying to remember your mother's maiden name and date of birth before you lifted a finger. 

Yeah, it's really that bad and exactly why security concerns in IT or otherwise need to be reframed.  All of these heaped on layers of band-aids and bailing wire are all for naught.  In the end we're not really securing anything.  How can we? We're never allowed to participate in the process. 

It's like the old joke where the man goes to the doctor and says, "Doc, it hurts when I do this!" and the only advice from the doctor is to say, " Then don't do that..." 

The more we remove human nature from the equation, the less meaning security has.