Because of this encryption on the internet is often a hard topic to discuss with people. It sounds like you’re telling them to whisper while talking to someone one on one in their living room.

Think about the internet like Twitter: anything you say can be read by (almost) anyone who’s interested. For some things this is fine like when you open up google.com. Everyone gets the same page, so you don’t really care if someone reads your message. But when you open up your email you would prefer that not everyone in the world would be able to read the information you’re sending on the internet.

Similarly, if you’re posting some messages on twitter you don’t care if everyone can read them (I.E. “I love Mickey Mouse!” “The weather is great!” “Just ate breakfast” you know, the valuable things we put on twitter).

But other messages you would want to be private. If you wanted to say, “Bob, I’ll meet you at Apple bees at 3” you and Bob could agree on a way code the information, say taking the first letter of each word and placing it at the end of the word (this would be a private encryption key). So your message becomes, “obB, ‘llI eetm ouy ta ppleA eesb ta 3”. Now when you post your message, even though anyone can see the information most of the internet won’t understand the content, but Bob can use the pattern to figure out the message and meet you on time.

This is also why the fact that Heartbleed could’ve leaked private encryption keys. Without the key, decoding the message would be pretty difficult (“Hmm….perhaps I have to read it backwards? ‘3 at bsee aelpp at yuo mtee Ill’ Bbo’? Nope. Maybe I have to add an ‘R’ to the beginning of every word? ‘RobB, R’llI Reetm Rouy Rta RppleA Reesb Rta R3’? Nope, that doesn’t make sense either. I give up!” – ok, not that difficult, but you get the picture). With the encryption key, anyone on the internet can just say, “Oh, I take the last letter in the word and move it to the front, and obviously he’s meeting Bob at Apple Bees at 3.”

So…encryption is a good idea, and you should keep how your encrypted stuff secret.

Fixing Heartbleed has received a lot of investment in a very short amount of time, both money and time wise. In my own company a number of senior Incident Response handlers and network admins were basically given a blank check on resources by management and told to solve the problem as fast as possible, regardless of the cost (Pretty unusual at my company).

Recently a number of large technology companies have created a fund to try and help different open source projects prevent the next Heartbleed 

And there is no arguing that the impact of Heartbleed remediation has a number of hidden costs.

Any time this much money and time are thrown at an issue we should pay close attention (no pun intended). The question we are behooved to ask is why. What combination factors open the budget floodgates on this particular issue and should any of those factors be applied anywhere else. I’ll take a stab at listing some.

Recent Target Breach
There’s no denying the Target Breach brought Cyber Security to the front of everyone’s mind. The phrase, “This vulnerability could turn you into the next Target” creates a connection to an event people have spent a lot of time to understand. This helps reduce the learning curve about why vulnerabilities like this are important to fix.

Widespread Issue
During the heat of the issue numbers like 2/3 of the internet being impacted were thrown around. While I doubt these estimates, they do grab your attention. And it’s hard to argue that a huge portion of the internet was impacted

Catchy Name
Heartbleed? Are you kidding me? That’s awesome to say you’re working on the Heartbleed vulnerability. It also makes for a great hashtag. The images of a heart painted in red with streaks coming from it didn’t hurt either.

Availability of a Fix
It’s more comfortable to talk about an issue that has a fix available than one that will take some thought power to solve. It’s easier to say, “You’re vulnerable, here’s how you can find out, and here’s how you fix it.” Than “BGP is based on trusting untrustworthy actors and we’re not sure how to solve that yet.”

Central website
Heartbleed.com was an easy website to remember and repost. Having a central location to go for the issue made it easier to discuss with different people.

Media Coverage
Security blogs are for Security people. But the individuals who get to write the checks to pay the security people often pay more attention to mainstream new sources. My own management become more interested in Heartbleed when the New York Times ran an article about it. The mainstream media coverage definitely helped Heartbleed get the necessary attention.

All of that adds up to a lot of attention being paid to this issue. The Security Community should probably take some notes on Heartbleed for next time. As soon as you hear of a large scale issue, higher a graphic designer to make a cool picture and reserve a domain name for a central location on the issue.

Crypto Currency is a redesign of the digital currency “protocols” (I use that word loosely here) that are already in use to make them more secure and stable. This system really needs to be better defined and implemented to create a stable infrastructure.

What will it take for Crypto Currency to gain wide spread acceptance? I see two major needs:

1. Funding. Crypto currency protocols are non-trival, both mathematically and implementation wise. Crypto currency requires a couple large backers to get involved and invest in it.

2. Education. Crypto currency has the stigma for being for video game nerds to buy magical swords made out of pixels and for criminals to sell drugs. More information needs to be available on why crypto currency is a good idea and why they should use it.

Whatever scanner you choose to use, make sure to scan your resources thoroughly, both before and after you patch.

Why? Read through this thread:

https://access.redhat.com/site/solutions/781793

Redhat released a patch, but people who scanned their systems after the patch were still showing as vulnerable. Turns out an add-on called mod_spdy was still vulnerable to Heartbleed, which made the patch from Redhat ineffective.

So, even after you’ve patched, scan again.

I would argue it would be a good idea to set up a recurring, regular scan (possibly adding this to your external/internal port scans) for the foreseeable future. I’d like to think that no one will create new software with the vulnerable versions of OpenSSL, but the chances a vulnerable version could get slipped into a product (by accident or intentionally) is probably pretty high.

In a previous post I discussed that one of the problems with digital currency is that the dollars are indistinguishable. If I pay Bank Eville Guys $100 and Bank Connman $100 there is no way to distinguish the different $100 dollars from each other.

The solution with paper currency was to put a serial number on each dollar, and specify what mint the money came from. The fix with crypto currency isn’t quite as simple. What’s to stop me from creating two digital dollars with the same serial number and claiming they came from the same mint?

Crypto currency uses a similar concept to the serial number, but also employs some cryptographic techniques to make sure that these numbers are unique across the currency world.

A detailed explanation for this methodology can be found here.

At this point in the game you have probably picked at least one (probably two or three) scanners to work with when you’re detecting Heartbleed vulnerabilities. Where do you start?

1. Start with your external, internet routable devices and services. Internal is important too, but your external stuff could be under attack from anywhere and anyone in the world.

Even if you’ve checked your tools documentation and it doesn’t specify that it uses OpenSSL, scan it. It’s easy for OpenSSL to be used somewhere and the impact of missing a vulnerable system could be large.

Take special care to scan VPN appliances, anything that processes passwords, and anything that has a private key it uses, keeping in mind that if you find something you may need to reissue a certificate.

For your first pass, scan ports you know use SSL (443, 8443, and anything else you have configured). You want to get the most value with the least amount of time spent scanning. If you just scan everything, every IP and every port, a scanner could take a long time to finish.

For your second pass, scan everything. You’ve already looked at high risk ports, now it’s time to look for fringe vulnerabilities.

2. Scan your internal network. Use the same methodology, scan high risk systems and ports first to get quick results and start your engineering teams patching them, then scan everything.

3. Scan your company’s workstations. Because Heartbleed can go both directions, look for OpenSSL on your workstations. I’d recommend first using a deployment tool to scan for any devices with OpenSSL in a file name or add/remove programs on windows. This will give you a good initial count and then you can use other methods to dig deeper.

Best of luck.

I’ve looked at a few of them, and I recommend using NMAP as a scanner for a number of reasons.

1. NMAP will allow you to scan interal network resources that are not available to the internet. Web based scanners can only look at what you expose to the greater internet.

2. Scanning with NMAP gives you access to all of NMAP’s features for specifying IP ranges, ports and port ranges, scan speeds, host detection, etc. The proprietary scanners I’ve looked at usually have fewer features.

3. Most proprietary scanners are black boxes. You put in an IP, they tell you if it’s “vulnerable” with no context for what they looked at or how they determined their results. NMAP is not a black box, you can dig in and read the NSE file to know exactly what NMAP is doing.

4. A lot of proprietary scanners will try to send your scan data back to their owning company for their own purposes. While not directly harmful if you are even somewhat concerned about being added to a report, NMAP might be a better option.

Yes, I’m reusing this graphic again. Because it’s awesome.

I’ve heard this question come up a couple of times in different forms, “Is Heartbleed a computer virus?” “Is my computer vulnerable to Heartbleed?”

This is often a difficult concept to grasp, which is actually a tribute to how well the internet works most of the time. The internet is meant to feel like there are only two people involved in communication: You and the person (or website) you communicate with.

In reality, there could be any number of participants in the communication getting your communication from you to the recipient. You communicate with your internet provider, who communicates with another provider, who sends the information to the website you want to talk to. The website responds along the same chain.

Any piece of this chain can come under attack. Your computer could be attacked, your information could be stolen as it moves through this chain, the website you’re going to could come under attack.

OpenSSL is a technology used to encrypt traffic between your device and the website you’re visiting (Encryption is a good idea because you’re passing your information to any number of unknown entities to get it to where it’s going. Encrypting it means that only you or the intended recipient can read the information).

So this is not a virus, it’s a flaw in a communication protocol. Like leaving an envelope unsealed when you put it in the mail. In some ways, that’s actually worse than a virus. Anything running OpenSSL with the Heartbeat extension is vulnerable. While this isn’t technically a virus, there are some scenarios where your computer could be attacked. The best course of action is to quickly apply any patch that becomes available for software you use.

NOTE: I say “some scenarios” because the likelihood of someone getting valuable information out of your computer using this, while possible, is low. Webservers that could have dozens or hundreds of people’s data going through them are much more attractive targets.

It sells more movies if you have flashy graphics and pretty pictures. It communicates a “technological fear” in a way that people can relate to. When you see the graph on Q’s screen re-arranging itself and turning red, it looks scary. Or the lab techs in CSI start typing madly on the same keyboard (If you don’t understand why this is ridiculous, try it some time) while windows flash across the screen you feel their horror and confusion over getting “hacked” by some invisible force. It’s an accessible metaphor for hacking.

The truth is that creating all of these fancy graphics during hacking would be as much or more work than the hacking itself. Computers aren’t like people. They don’t flinch and scream when attacked. A lot of these fancy re-arranging graphs are an anthropomorphism for the computer. We can connect to it better emotionally when the computer looks or sounds like it’s reeling under a hacker’s insidious attacks.

In a lot of ways this portrayal of hacking makes it difficult to talk to people about real hacking. The Heartbleed bug is an excellent example of the contrast between Hollywood Hacking and real hacking. There are a number of excellent technical write ups here and here on the bug, but it’s difficult to generate much interest for the public outside of the technical world. At least in part because it’s pretty dry stuff when compared to the Hollywood Hacking in movies.

Rather than flashing cool pictures or making crazy beeping sounds, the server just responds with 0’s and 1’s. The attacker quietly sends an attack to the server, the server quietly responds. There’s much less excitement during, but the impact is incredibly devastating.

Is this a problem? Maybe and maybe not. The people who enjoy hacking movies may not be in the same group as the people who enjoy hacking. But it may be a bit of a rude awakening for future security experts who grew up on Hollywood Hacking in movies and then realize there are far fewer exciting, automatically re-arranging graphs in the real world.