One of the interesting things about being a VERT Engineer is that you never know what type of work you're going to be doing from week to week and sometimes even day to day... A while back we had a request to detect the popular Japanese file sharing application WinNY. I was tasked with this and it was actually quite a bit of fun. You see WinNY has a UI that is Japanese and although there are patches available to change the button text to English, navigating it was, at times, trying. A bit of research and some testing on my own and I'd managed to write a small script that could detect WinNY running on a computer.

I'm not going to give out any more information on WinNY but I am going to introduce you to a new part of the VERT blog... the VERT Challenge. These will occasionally be posted, the prize going to the person with the correct answer. Yes, that's right... there will be a prize. The concept is fairly simple.

For this challenge you will:

• Locate the WinNY application Online (Both Versions 1 and 2)


• Determine how to perform proper WinNY detection. (remotely -- via the listening TCP port)


• What you need to provide in order to win:




• Any encryption, authentication or hashing used for communication.


• A breakdown of the information provided by WinNY when you connect to it.


• The unencrypted strings that distinquish between WinNY 1 and WinNY 2.


• Bonus Points for providing a script or source code to perform the detection.

• 1st Place - nCircle Remote Control Car + nCircle Polo Shirt


• 2nd Place - nCircle Remote Control Car


• 3rd Place - nCircle Polo Shirt

The Rules:

• Submission of materials already available online will NOT be accepted.


• Submissions will be accepted in the order they are received but complete submissions will receive consideration before partial submissions.


• The contest will close at 12:00PM (Noon) EST on Friday, March 16th 2007.


• You are free to submit a partial submission and then submit additional data, however you can only resubmit once.

Sometimes you have to wonder... There are plenty of public vulnerabilities in Windows and related Microsoft products (See: The Missing Microsoft Patches)... yet Microsoft has chosen not to put out any security patches this month. That's right, the advanced bulletin for March claims they will release no new security patches. Now I'm slightly concerned about this... There are plenty of issues that could, and should, be patched. If they can't keep up and therefore can't get anything out, perhaps they should hire more people... If this is due to QA problems, then perhaps it's time for retraining. In the end this is definitely very concerning... I've been a big supporter of Microsoft and there steps forward in security lately. Yet the release of 0 patches when there are identified problems leaves me with some questions.

So... I pose the following questions to Microsoft:

- Why have you chosen to release 0 patches this month, when there are obviously vulnerable issues that need to be address?

- Why are you unlikely to provide patches for several of the issues listed on The Missing Microsoft Patches list?

- What does this say to your customers and the public, when after several promises to be committed to security you are a) taking your time to release patches and b) ignoring certain issues because you don't deem them important enough to patch?

I've spent quite a bit of time supporting Microsoft and perhaps that support came to early... Perhaps I've trusted Microsoft a bit too much and they aren't taking security nearly as seriously as they claim to be. That's what this advanced bulletin says to me... What does it say to everyone else?

I just wanted to let everyone know that we've extended the deadline for VERT Challenge #1 to Monday. We've received some good feedback and comments and some good discussion about it on other blogs and websites, but I haven't seen any submissions that I would consider to be serious contenders yet. Monday is coming fast, so get your entries in soon if you've been working on them... If you haven't, you'd better get started now.

Also, it should be noted that we're using this challenge to gauge interest. This will, in a way, be a deciding factor for future VERT Challenges. Personally, I'd much prefer this be VERT Challenge #1 and not VERT Challenge FINAL. We have a bunch of challenges lined up for you... do you have the goods?

Pass this on to anyone you know as well... Anyone you think would be interested in accepting the challenge.. For those of you that are procrastinating and putting this off... consider this a virtual kick in the pants to get you in gear and working on it... After all who wouldn't want to drive their victory lap with a nCircle Remote Control Car!?

Bragging rights are yours... Come and get 'em.

Even though this isn't new, there was an advisory released a couple of days ago by Core Impact (via Matasano). The vulnerability was in the handling of IPv6 packets in OpenBSD. This vulnerabilitity brings the discussion about the severity of denial of service (DoS) vulnerabilities into the light again. OpenBSD no longer considers remote denial of service "issues" vulnerabilities anymore. They believe that these vulnerabilities are not at severe as others that allow for the remote control of a server, so they differentiate between them.

My first instinct was to poke fun at OpenBSD as many others have done. However, I've decided not to here. I'm going to step back for a bit and try to look at it from their point of view.

Are DoS vulnerabilities, specifically remotely exploitable ones, really that important? An attacker cannot take control of the remote server using this method. I don't think you are going to get any argument from the security community that DoS vulnerabilities are less severe than their remote control counterparts. The ability of an attacker to gain entry into a network through remotely exploitable means can have severe repercussions and is why people like me are employed. An attacker can use this to gain highly sensitive information, use the vulnerability to leverage their access for future attacks, or use it as a vehicle for financial gain (spam, spyware, etc). I would agree that these kinds of vulnerabilities need to be separated somehow from the denial of service counterparts. However, I'd argue that since we give them different names, they already are.

However, just because DoS vulnerabilities are not as dangerous as their remote control counterparts, it does not mean that they are not important. A lot of this is subjective. Look at the following scenario.

Here's a simple question. What is more important to the average, non-security centric, user? Do they care whether or not their box has been exploited or do they care whether or not they access to their e-mail? In most cases, I would argue that the average user cares a LOT more about getting their e-mail. This can be a source of frustration for most of us in the industry, but shows the disconnect between what we (as an industry) deem important and what everyone else does. Take a look at the MySpace vs corporate password complexity analysis done by Bruce Schneier on his blog. In one sample analysis, MySpace users have stronger passwords than their counterparts in the corporate world. Why? Who knows. However, one theory is that the risk of losing their MySpace account is greater than their corporate account. If their corporate account gets hacked, that is a problem for someone else. What's on their MySpace account is what's important to them.

I've gone slightly off topic here, but I think the security industry (or security centric groups/individuals) needs a little bit of a reality check. To us, we may dismiss the average DoS vulnerability because there are thousands of them and they may not be that exciting to us anymore. But we are often in our own little world. As an example, do home users reinstall a new copy of Windows or buy a new computer because their machine has spyware installed? In most cases, probably not. They do it because malware gets so intrusive that they can no longer do the things that they want to do. However, for the average user, losing their access to a service or tool may be way more severe than anything else that we could possibly think of.

So the conflict of interest red herring has bubbled to the surface looking to feed on your scraps again. For those who don't remember, I blogged about this farce of an argument after John WTF Thompson's RSA keynote back in February.

Mark Litchfield just sent out a quick e-mail asking for our opinions on the latest stop on Thompson's BS Blitzkrieg at a conference in Germany, with a link to CSOonline's article. Mark and I (and I assume the rest of the sane world) are on the same page with this one ... get real.

These kinds of self-interested rants do little more than diminish the value of our competitive space. When I was on the customer side, I wanted as many competitive products from as many capable vendors as possible so I could secure my networks to the best of my ability at a competitive price. I didn't change my mind when I moved to the vendor side. No misguided analogy to "accountants should not audit their own bookkeeping" is going to change this lesson that I and many others have learned the hard way.

I said it in February and I'll say it again now - If you don't want the world to buy a competitor's products, explain to the world why your solutions are better. Better yet, forget the explaining and prove it.

It doesn't matter if Security Solutions and Operating Systems roll out of the same corporate entity. Make a better mouse trap and those who care about solution quality and value will buy it. If IP360 wasn't better than MBSA, there wouldn't be a VERT Daily Post for you to read - we'd be out of work. There's a good reason why we're here.

Sorry Johnny ... this pig of an argument doesn't fly.

A quick update.

I've had a few people mention to me that with current schedules, the time provided just wasn't enough to adequately complete the challenge. As a result, since we have not yet given away all the prizes, I'll be extending the competition until the end of the month. Since the month ends on a weekend I'll be accepting all emails found in my inbox when I come into the office on Monday, April 2nd. The address again, for those of you that have forgotten or misplaced it is: ~treguly~ (at) ~ncircle.com~. The complete competition details can be found here.

RSnake over at ha.ckers.org discusses his ideas on a topic he calls "iterative scanning". His idea is that one should take into account what information they already know. He concludes that, during an assessment, one should not run a check for a vulnerability if you have already know that the vulnerability cannot be present on the remote server. For example, there is no reason to an exploit on an IIS server when the vulnerability only affects instances of Apache.

He's absolutely right of course. There is no reason to even try to check for an IIS vulnerability when you already know that the remote web server is Apache. A solution for this was implemented at nCircle for this problem years ago. Before checking to see if a vulnerability is present on a computer, we try to ascertain whether or not it is even possible for the vulnerability to be present on the server.

There are many advantages to doing things this way. First, it speed things up significantly. Instead of enumerating through the entire list of known SMTP vulnerabilities, you can just focus on the ones that affect Sendmail if that is what is presently running. Secondly, it minimizes false positives. There is no absolutely no chance that a check for a Postfix vulnerability will fire in the above example.

Of course, fingerprinting can be both easy and difficult depending on the protocol. However, even with the high cost of entry, the benefits to determining what is running prior to performing any form a vulnerability scan outweighs the cost. I'm really glad that others in the industry have started to get on that bandwagon.