While we were scanning for Heartbleed at my company, it mostly helped us find systems that were vulnerable when the vendor or system owner claimed it was clean (That’s a fun conversation to have with a system engineer).

But occasionally the vendor would claim their system was vulnerable and our NMap scan wouldn’t find it. During the flurry of activity we didn’t have much time to look into it, so we just applied any available patches.

Later on though I did some digging through the NSE code and found that the ssl-heartbleed script uses a file called shortport.lua which is a library for common port/protocol associations (HTTP as 80 and 443, etc). Well there’s an interest list in there:

Long story short, this is the ports (plus a few others in a different method call) that ssl-heartbleed will attempt the Heartbleed exploit on. If you have something listening on an uncommon SSL port (as, apparently, we do at my company) ssl-heartbleed won’t check it unless you add the port to this list.

The convenient part is that after adding the port to the list the file can simply be saved and you can run nmap –script-updatedb and you’re good to go. Pretty easy.

I would, however, caution against adding large numbers of ports here for a number of reasons.

1. As sad as it is, a number of applications will crash if they receive a packet formed (for instance Netscreen and HP ILO so that could cause you some headaches.

2. It will take a long time if your IP address space is sizeable at all.

3. NSE might not support a list that large.

My team was recently contacted to dig into an issue with an application. A specific module refused to load while the rest of the app worked fine.

Our level 2 team had dome some preliminary work, so I began looking at their packet captures. Like anybody who has operated behind a firewall, my first question was whether or not our firewall was blocking the traffic.

There was plenty of traffic to the IP address, and a lot of it was being blocked by our firewall, starting around the time the users reported the issue.

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.