A common adage on the elementary school playground is, “There’s always someone out there bigger, stronger, and faster than you.”

If we swap “bigger” and “stronger” for “more clever” and “better typer” we have an incredibly true point for cyber security. No matter how smart you are, or how good you are at detecting attacks, there is going to be someone in China or Russia who knows more than you do. There will always be a zero day exploit someone can buy that you will never see coming. There will be the script kiddy in his basement who manages to find the one thing you forgot about.

This isn’t to say we shouldn’t try, quite to the contrary, we should try all the harder. But it should change the way that we think about our perimeter defenses. Your IDS, firewall, and AV aren’t get out of jail free cards. You can’t just play them like a wild card in uno (the only card game I’m good at).

Rather you should think of them in context. When you’re designing your perimeter defenses, you should put effort into doing them correctly.
But then when you move on to designing your client based security (client side AV, client based IDS) you should assume that your adversary has effortlessly bypassed your network based IPS.

Then when you are working on your database security, you should assume your adversary has walked past your perimeter security and your client side security. You should assume that compromised devices are hitting your database server directly and design the security with that in mind.

Cyber Security is a frustrating field because you never know for sure that you have done it well and correctly. You only (sometimes) ever sometimes find out that you have done it completely wrong.

Obviously this could turn into a black hole of time and money. Since you can never say, “We are now secure” you could always spend more money and time making things safer.

That’s really why God invented managers and gave them check books. Obviously security professionals have to keep some concept of budget in mind, but while they’re focusing primarily on making things more secure, managers are able to provide some perspective on what’s reasonable.

So in conclusion, assume everything you’re doing doesn’t work well. And then keep on doing it better.

A new cyber security story has hit the news this week: Blackshade. The FBI put out a notification about it, so it’s likely to get some play in the media. But what is Blackshade and what does it mean for you?

What is it?

Blackshade is a RAT (Remote Access Trojan). If you’ve ever had a tech support technician or friend remote control your computer this is the same idea, but without the positive intentions. It gives an attacker remote access to your computer and thus potentially access to the things you do with your computer such as social media, web cam usage, files, and email.

Why should you care?

Do you remember the Miss Teen USA incident where a teenager was blackmailing Miss Teen USA with compromising photos? Those were taken with very similar technology. Having someone with remote access to your computer is always concerning. Especially if you tend to leave your social media logged in or do banking from your personal computer.

Who is at risk?

Blackshades is a little different than most of the cyber security news events we’ve seen lately. It’s not a terribly sophisticated attack, and it’s not really aimed at stealing c from companies. It’s more aimed at an interpersonal level, like the teenager who took pictures of Miss Teen USA.

Brian Krebs had a very interesting quote:

In short, Blackshades was a tool created and marketed principally for buyers who wouldn’t know how to hack their way out of a paper bag.

All of this means that Blackshades (and RATs in general) are more of a risk to individuals than they are to businesses. Since this is more of a risk to you than your credit card company, you should pay extra attention.

What should you do?

If you are a company, the best thing to do is to search your web proxy’s logs for any activity to the known Blackshades domains, which are available in the Flash Announcement. You should also check if any domains associated with your company are in there, just in case your infrastructure was used to spread the RAT.

If you are an individual, there are a couple steps you should take.

• Read through the FBI’s article on determining if your computer is infected with Blackshades and check for the files they list. Find someone to walk through this with you, if you are unsure of how to perform the steps

• If you are concerned, but don’t have time to check if your computer is infected take some precautionary steps like

1. Cover up your webcam with a post it (prevents someone from taking pictures of you)
2. Log out of any social media, email, or IM accounts (to prevent them being used to spread Blackshades)
3. Don’t do any banking on your computer
4. Backup any important files (school papers, financial documents, etc) to prevent them from being deleted or tampered with
5. Leave your computer off if possible (an attacker can’t hurt what’s not turned on)

• Generally good advice, never click on links that look suspicious (especially if they are from a boy between the ages of 13 and 24). Even if you trust the person that sent it to you, if it’s a link with no context or explanation, make sure they meant to send it before you click on it.

This is especially interesting because of this article. I first posted it a couple days after Heartbleed came to light when there was lots of attention and activity. But now, weeks later it’s still getting a decent amount of traffic. And it certainly isn’t the only article about scanning for Heartbleed with nmap (one of my favorites), so we can assume that those other posts are getting as much or more traffic.

Most of the major security vendors have released signatures for Heartbleed at this point, so most of the people searching for cheap ways to scan for Heartbleed are likely working at smaller companies that either don’t or can’t afford an expensive vulnerability scanner.

My point is that Heartbleed could continue to be an issue for a while. Probably not for larger companies, but for smaller groups with fewer resources to throw at resolving it will probably continue to work on patching for some time.

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.