Recently in Vulnerabilities Category

Doug Pearson of REN-ISAC just sent an announcement to the public EDUCAUSE security listserv that MS09-039 is actively being exploited in the higher education arena.

The message confirms earlier speculation by the Internet Storm Center that exploits for the WINS vulnerability are live on the Internet and spreading.

On interesting item in the REN-ISAC bulletin in the explicit warning not to just rely on perimeter firewalls for protection as successful WINS server compromises have been seen originating from inside the organization.

Once again: it is time to patch, block, or disable unused services.

I regularly review firewall configurations to figure out what incoming connections we allow, other than web access. In the course of the last 5 years or so, it has become abundantly clear that there had better be a very good reason for anything that is not web to be still exposed directly to the Internet. As more obscure protocols become less used, it becomes harder to retain experienced administrators who really know what they are talking about, and as a result, securing those protocols becomes much harder.

Which the advent of 'everything over the web', new challenges have emerged. Secure application development, web content filtering (inbound and outbound), web application firewalls, specialized intrusion detection systems, etc. are all important tools to have, but, in the end, all those tools must be configured, maintained and tested also.

As a result, requiring regular vulnerability scans is an important tool to not only detect problems in the application, but also to test all the controls that protect the information that is manipulated by it. Penetration testing to assess the potential impact of the vulnerabilities that were discovered would sometimes be the logical next step.

There are roughly two types of vulnerability scans: manual scans and automated scans. Manual scans, if conducted by a highly skilled individual with enough time, will find things that you would not have even dreamed about. A major drawback is that they are (very) costly and the outcome of the scan is highly dependent on the person conducting it. Automated scans are relatively cheap, can run consistently and continuously and they are thorough. The drawback of automatic scanning is that they will only find vulnerabilities that were previously known and have been implemented in the scan tool's logic.

There are some solutions out there that take a hybrid approach to vulnerability scanning. They perform an automated scan, which is supported by human experts who manually verify the  results in order to avoid false positives. Human testers will also be much more qualified to detect business logic flaws than automated scans can.

The automatic scans will detect of the vast majority of the problems, which allows the human expert to concentrate on the more interesting stuff.

One vendor that offers this service is WhiteHat Security through their Sentinel product. I have been working with Sentinel for a few weeks now, and my impression that our developers had things fairly well under control was confirmed. Yet, Sentinel also found a number of vulnerabilities that I had no idea were present on our web presence. The WhiteHat staff is very responsive to inquiries and I am a very happy customer. The price tag is reasonable; a full year of continuous scanning will amount to roughly the same price tag as a once-off scan of a medium-sized site conducted by a human tester.

If you are in the market for a hybrid web application vulnerability scanner, you should check out WhiteHat's offering.

Whether or not it will prove to justify the effort, Conficker has kept many of us fairly busy over the past few weeks. When the news broke late last weekend that machines infected with Conficker were, at least for the time being, network-detectable, many vulnerability scanners have been running 24/7.

My own group was no exception; we are a paying Tenable customer and we were able to get a handle on the Nessus plugin right away.

When we had not found a single detection after scanning for nearly 24 hours, we were getting a little worried. While we believe that we are doing a fairly good job at keeping our end points patched and firewalled, it was (and still is) hard to believe that we did not have a single infection on our network.

SRI International's Malware Threat Center recently published a technical report titled An Analysis of Conficker's Logic and Rendezvous Points. In the report, its authors Phillip Porras, Hassen Saidi, and Vinod Yegneswaran, do an excellent job at analyzing the different Conficker variants.

Conficker targets an array of attack vectors: some are network-based and some are based on users sharing portable media. The authors of the report pose a good question: why has Conficker been able to proliferate so widely? As they point out, one possible solution may be the stubbornness of some PC users to avoid staying current with the latest Microsoft security patches.

Other explanations may be that coporate networks are often slow to deploy patches-- even those marked critical. It is highly possible that in an intial vulnerability assessement, security teams may have decided that the network-based vector is only exploitable when users activate file- and printer sharing, and assigned the patch roll-out a lower priority. By now, I hope that most (if not all) security professionals are aware of the effectiveness and widely-spread nature of Conficker in all its variants.

However, whatever the reason may be that Conficker was so effective in spreading on a large scale, the fact of the matter is that is did. The authors of the report proceed to disect the binary payload of the worm and describe its inner workings. For anyone who is interested in large-scale malware distrubution, this paper is a must-read.