Archive for July, 2009

Invisible security bug spray

July 11th, 2009

Figured it would only be a matter of time before someone asked about the “Invisible security bug spray” comment at the top of each page. Didn’t think it would take less than one day. ;)

Here’s the scoop. Its a play on a quote from one of my all time favorite ISP responses to letting them know that one of the IPs within their network is hostile.  Here’s some quotes from their response:

Snip #1:
Hackers are like ants, chasing one away from the picnic table will not protect you from the thousands and thousands in the local ant hill that are still hungry. As soon as you rid yourself of one, you will still have an infinite risk available to you to get scanned or probed again.

Snip #2:
The point of the above statements are, as soon as you’ve had one hacker prosecuted and/or addressed, you’ve only swatted one gnat on a hot & humid summer afternoon. A few seconds to a min later, you will start feeling itchy again because there’s another one biting you.

Granted there is some Zen truth to their commentary (malicious IPs always make me itchy), but what an interesting choice of words. The response then went on to say:

Snip #3:
Firewall logs such as yours will often show the paper trail of the framed computer rather than the hacker itself. The real hacker hasn’t been and normally cannot be detected during those circumstances. We’re looking into the situation but we get dozens, if not hundreds of these a week.

Snip #4:
What you should focus on is not trying to kill every gnat, but rather wear invisible bug spray so that no matter how many of them there are, they cannot find you therefore there is no war. You cannot win the war, all you can do is stay out of it.  The better the firewall you use, the more likely you will remain invisible.

We apologize for any inconvenience but just bear in mind the broader perspective to this.

So there you have it, invisible security bug spray. :D

Dealing With Malware On Windows (Part 1) – Why Anti-Virus Is A Dying Technology

July 11th, 2009

Sometimes a technology outlives its usefulness. A good example is the automobile carburetor. While we have known the performance gains and fuel savings of multi-port direct fuel injection for decades, some (NASCAR!) still cling to the use of the outdated, yet familiar carburetor. Much the same has occurred with the technology to fight Malware. Anti-virus has become the “carburetor” of keeping malicious code off of our systems.

What is A/V software?

Anti-virus is still primarily a signature based system. In other words, we define a code pattern that we want to detect and then search memory or the hard disk for that pattern. This is referred to as “application black listing”, because we are defining the bad applications we want to keep off of the system.

Where do A/V signatures come from?

Typically an A/V customer will become infected and report the problem to their vendor. The A/V vendor can then generate a pattern, which permits their other clients to be protected from this same strain. Its also possible for the signature to get generated if the code is found in the wild prior to release, or if another vendor generates a signature.

What about heuristics?

Heuristics looks at suspect behavior and then white lists known to be good applications. For example we may check all attempts to create a user account on the system and then check to see if the application is a known administrator tool. This technology has some really cool potential, but it also has a number of flaws. The primary problem, and the reason heuristics sees little to no use, is the fact that its prone to false positives. Try to use a 3rd party tool to manage your user accounts and the A/V heuristic engine is probably going to block it.

The business model of Malware

When anti-virus was first developed, Malware had two specific traits:

  1. Malware distribution was slower than signature distribution.
  2. Malware writers were mostly script kiddies attempting mass propagation.

Neither one of these items are applicable in today’s environments. Symantec states that in 2009 they are averaging a new Malware signature every eight seconds.   For F-Secure, this frequency is closer to a new signature every four seconds. Do you update youy A/V every 4-8 seconds? Does your A/V vendor even release a new signature file every 4-8 seconds? You see the problem. Even if you diligently update A/V every night, 11,000-20,000 new signatures and pieces of Malware have ticked by.

But let’s talk a bit more about item #2; script kiddies and mass propagation. Around 2001 or so I noticed a change in the Malware world. The folks who really knew what they were doing stopped doing mass release. Think about it, most Malware writers usually start when they are very young. When you are still in school and living at home, its trivial to release your code for free. At some point however you need to get a job and start earning some income. When you personally reached that place in life, what did you do? For most of us, it involves looking at what we are good at and trying to match that up to a high paying job.

So if you are good at writing Malware, where are the high paying jobs? Some possibilities:

  • Extortion – Steal info and sell it back.
  • Espionage – Steal info for a competing company, government, etc.
  • Steal data with value in the wild – bank logon, credit card info, etc.
  • Resell botnet and Malware services – Become a gun for hire. Typically spam distribution of DDoS.

While we still have some number of script kiddies doing mass propagation (think of them as Malware writers in training), the smart attackers have turned it into a profitable business model. When it’s a business model, the code of course has monetary value. This means an attacker will not risk mass propagation of high end Malware code. They are going to sit on it and only use it when there is the potential for a high rate of financial return. So we can’t count on the truly nasty stuff being mass propagated anymore. The stuff you need to worry about most is used in a targeted fashion.

Why does my A/V fail so often?

A couple of problems should be immediately apparent with the above model. To start, because we are black listing bad applications, the assumption is everything else is OK. If we do not have a signature identifying the application as malicious, we assume it is safe to run. This means that all Malware without a signature is free to infect the system. This model also assumes some level of acceptable losses. Typically there is a lag time between when systems get infected and when we get a signature to protect ourselves. This could be hours, days or in some cases even months.

Problems under the hood

One of the biggest issues with A/V software is the signatures. Most of us would not even consider purchasing a NIDS or NIPS which does not provide access to the signatures, but that’s exactly what you get with an A/V system. This leads to little to no sanity checking of signatures within the industry, as well as limited customization capability. For example I have yet to see an A/V vendor give me the ability to let my network administrator group run a password cracking tool from known to be secure machines. If I have any customization capability at all it is a tedious process to get specific applications approved for use, and even then enforcement is limited.

So where do we go from here?

With all these problems, its no wonder that application control (sometimes called application white listing) is starting to replace A/V software as the tool of choice for controlling Malware. I’ll get into application control in part 2 of this post.

TIC article on Networkworld

July 10th, 2009

Networkworld has an article on the DDoS attacks that appears to be originating out of North Korea. Here’s a link to it. The jist of the article is that the DDoS attacks were worse than they should have been because security folks did not know what ISP they were using. The claim was that if the government would hurry up and implement the Trusted Internet Connect (TIC) program, these problems would be a thing of the past.

First a little background, TIC is an effort to reduce the number of connections to the Internet maintained by federal, state and military networks. In 2006 there was somewhere in the neighborhood of 4,500 connections (at the time I was involved no one knew for sure exactly how many connections there were). The original goal was to reduce this to 50 connections. Last I heard the goal was 113. Expect it to float around in this ballpark for a while. Currently they’ve been able to eliminate about 25% of the connections.

There are many reasons why this is a good idea. Single point of security implementation, consolidation of resources, a more uniform implementation of security policy, just to name a few. There are many reasons why this is also a bad idea, one of which is the mitigation of DDoS attacks like the one described in the article.

Look at it this way, if I take 100 Internet connections and consolidate it into 1, I’m not going to implement a single link with 100X bandwidth (30 Gb is about the max we can push today anyway and running at that level severely limits your security product options). I’m going to do the same thing ISPs do, over subscribe the link. Since it is unlikely everyone will try and access the Internet at the same time, normally this works just fine. The problem occurs when a DDoS attack takes place as now there is less bandwidth that needs to be saturated in order for the DoS to be successful. It also means that a greater number of sites will be affected. So I would argue that TIC has the potential to make this problem worse, not better.

But let’s try and look at the true root cause of all of this. They quote Alan Paller as saying they could not get the ISP to filter the traffic. The author states this is because they didn’t know which ISP to contact. Huh? How about a whois query on the address space? Traceroute? Check the monthly bill? Direct ARIN query? I find it hard to believe that a staff of security folks would sit around staring at each other with no idea how to figure out who their ISP is. More likely the ISP did not want to take responsibility for filtering the traffic. I know I’ve run into that problem dozens of times over my career.

Its also possible that this was a pretty low priority. Think about it. The attack started on July 4th. Think back to that day. Were you out enjoying sun and family or thinking “Humm, I wonder if the Federal Trade Commission posted anything today on the state of the economy. OMG I’m financially ruined, I can’t get to their Web site!”? :) My guess is the former. This is/was a relatively lame attack which was easily mitigated by Monday morning, when access to the site actually had some value. For anyone who’s taken one of my classes, you know I’m fond of saying “Its OK to accept risk provided its an informed decision”. I can see someone making a business decision that it was better to get it working by Monday morning than to spend time, resources and tax dollars on recovering the site during a time period when it would see little use.

So it remains to be seen if TIC will make the DDoS problem better or worse. What would certainly help is a good SLA written into the contract requiring the ISP to respond to these types of attacks.

May the bits be with you,

C

New site intro

July 10th, 2009

Greets all,

I’ve run this site for a number of years now by granting access to specific sections for only a limited number of people. While I will continue to do this for certain clients, I’ve decided its time to open up a large portion of it to public access. I also want to try my hand at integrating much of the advice I give via e-mail and private lists here as well. Figure that way the greatest number of folks will be able to benefit.

If you are used to having access to something and you don’t anymore, I apologize in advance. Please be patient as I try and integrate everything into WordPress. The system is very cool, but its also very different than what I was using in the past. Please give me time to cut the curve.

Yours in bits,

Chris