Slashdot Mirror

Its probably too late for this post to get modded up enough for anyone to see it, but I've been at home sick so I didn't check Slashdot every 20 minutes like I usually do.

Based upon marketing hype, my management chain insists on using ISS's Internet Scanner (www.iss.net) to perform site-wide security scans and do vulnerability assessments. Nessus just simply isn't as feature rich as Internet Scanner. IS searches for thousands of vulnerabilities, and they are constantly adding new checks that can be dynamically loaded into the scan tool. The scans are highly customizable. The only problems are the tool can only run on a Windows server (i.e it can scan any network device including unix, printers, and Cisco), its a huge resource hog, and GUI only.

I'd love a nice, easy command-line based unix based system that has all the functionality of ISS, including the nice HTML output. The problem is, of course, that ISS has a huge head start.

Even Norton Internet Security isn't half bad.

Don't be so sure

While the specific vulnerability exploited by Witty was announced on March 18 by ISS, there was another vulnerability in ISS products announced on February 26 that also involved the Protocol Analysis Module (PAM) component.

So, I wonder if the author of Witty, knowing that there was one vulnerability in the way those products parsed messages, looked for (and discovered) another.

From here:

The Witty worm exploits a stack-based overflow in ICQ response parsing in the Protocol Analysis Module (PAM) of ISS products.

That has nothing to do with the internal architecture of Windows. That's a bug in ZoneAlarm. There is no reason to blame Windows at all for a bug in a software product written to run on Windows.

The Spread of the Witty Worm

March 19, 2004

An analysis by Colleen Shannon (cshannon@caida.org) and David Moore (dmoore@caida.org) of the spread of the Witty Internet Worm in March 2004. The network telescope and associated security efforts are a joint project of the UCSD Computer Science and Engineering Department and the Cooperative Association for Internet Data Analysis.

We would like to thank Brian Kantor, Jim Madden, and Pat Wilson of UCSD for technical support of the Network Telescope project; Mike Gannis, Nicholas Weaver, Wendy Garvin, Team Cymru, and Stefan Savage for feedback on this document; and the Cisco PSIRT Team, Wendy Garvin, Team Cymru, Nicholas Weaver, and Vern Paxson for discussion as events unfolded. Support for this work was provided by Cisco Systems, NSF, DARPA, DHS, and CAIDA members.

Introduction

On Friday March 19, 2004 at approximately 8:45pm PST, an Internet worm began to spread, targeting a buffer overflow vulnerability in several Internet Security Systems (ISS) products, including ISS RealSecure Network, RealSecure Server Sensor, Proventia, RealSecure Desktop, and BlackICE. The worm takes advantage of a security flaw in these firewall applications that was discovered earlier this month by eEye Digital Security. Once the Witty worm infects a computer, it deletes a randomly chosen section of the hard drive, over time rendering the machine unusable. The worm's payload contained the phrase "(^.^) insert witty message here (^.^)" so it came to be known as the Witty worm.

While the Witty worm is only the latest in a string of self-propagating remote exploits, it distinguishes itself through several interesting features:

• Witty was the first widely propagated Internet worm to carry a destructive payload.
• Witty was started in an organized manner with an order of magnitude more ground-zero hosts than any previous worm.
• Witty represents the shortest known interval between vulnerability disclosure and worm release -- it began to spread the day after the ISS vulnerability was publicized.
• Witty spread through a host population in which every compromised host was doing something proactive to secure their computers and networks.
• Witty spread through a population almost an order of magnitude smaller than that of previous worms, demonstrating the viability of worms as an automated mechanism to rapidly compromise machines on the Internet, even in niches without a software monopoly.

• In this document we share a global view of the spread of the Witty worm, with particular attention to these worrisome features.

Background

Network Telescope

The UCSD Network Telescope consists of a large piece of globally announced IPv4 address space. The telescope contains almost no legitimate hosts, so inbound traffic to nonexistent machines is always anomalous in some way. Because the network telescope contains approximately 1/256th of all IPv4 addresses, we receive roughly one out of every 256 packets sent by an Internet worm with an unbiased random number generator. Because we are uniquely situated to receive traffic from every worm-infected host, we provide a global view of the spread of Internet worms.

ISS Vulnerability

A number of Internet Security Systems firewall products contained a Protocol Analysis Module (PAM) to monitor application traffic. The PAM routine in version 3.6.16 of iss-pam1.dll that analyzes ICQ server traffic assumes that incoming packets on port 4000 are ICQv5 server responses and this code contains a series of buffer overflow vulnerabilities. The vulnerability was discovered by eEye on March 8, 2004 and announced by both

The Spread of the Witty Worm

March 19, 2004

An analysis by Colleen Shannon (cshannon@caida.org) and David Moore (dmoore@caida.org) of the spread of the Witty Internet Worm in March 2004. The network telescope and associated security efforts are a joint project of the UCSD Computer Science and Engineering Department and the Cooperative Association for Internet Data Analysis.

We would like to thank Brian Kantor, Jim Madden, and Pat Wilson of UCSD for technical support of the Network Telescope project; Mike Gannis, Nicholas Weaver, Wendy Garvin, Team Cymru, and Stefan Savage for feedback on this document; and the Cisco PSIRT Team, Wendy Garvin, Team Cymru, Nicholas Weaver, and Vern Paxson for discussion as events unfolded. Support for this work was provided by Cisco Systems, NSF, DARPA, DHS, and CAIDA members.

Introduction

On Friday March 19, 2004 at approximately 8:45pm PST, an Internet worm began to spread, targeting a buffer overflow vulnerability in several Internet Security Systems (ISS) products, including ISS RealSecure Network, RealSecure Server Sensor, Proventia, RealSecure Desktop, and BlackICE. The worm takes advantage of a security flaw in these firewall applications that was discovered earlier this month by eEye Digital Security. Once the Witty worm infects a computer, it deletes a randomly chosen section of the hard drive, over time rendering the machine unusable. The worm's payload contained the phrase "(^.^) insert witty message here (^.^)" so it came to be known as the Witty worm.

While the Witty worm is only the latest in a string of self-propagating remote exploits, it distinguishes itself through several interesting features:

• Witty was the first widely propagated Internet worm to carry a destructive payload.
• Witty was started in an organized manner with an order of magnitude more ground-zero hosts than any previous worm.
• Witty represents the shortest known interval between vulnerability disclosure and worm release -- it began to spread the day after the ISS vulnerability was publicized.
• Witty spread through a host population in which every compromised host was doing something proactive to secure their computers and networks.
• Witty spread through a population almost an order of magnitude smaller than that of previous worms, demonstrating the viability of worms as an automated mechanism to rapidly compromise machines on the Internet, even in niches without a software monopoly.

• In this document we share a global view of the spread of the Witty worm, with particular attention to these worrisome features.

Background

Network Telescope

The UCSD Network Telescope consists of a large piece of globally announced IPv4 address space. The telescope contains almost no legitimate hosts, so inbound traffic to nonexistent machines is always anomalous in some way. Because the network telescope contains approximately 1/256th of all IPv4 addresses, we receive roughly one out of every 256 packets sent by an Internet worm with an unbiased random number generator. Because we are uniquely situated to receive traffic from every worm-infected host, we provide a global view of the spread of Internet worms.

ISS Vulnerability

A number of Internet Security Systems firewall products contained a Protocol Analysis Module (PAM) to monitor application traffic. The PAM routine in version 3.6.16 of iss-pam1.dll that analyzes ICQ server traffic assumes that incoming packets on port 4000 are ICQv5 server responses and this code contains a series of buffer overflow vulnerabilities. The vulnerability was discovered by eEye on March 8, 2004 and announced by both

RealSecure? MyISS.

RealSecure? MyISS.

Description:

The Witty worm exploits a stack-based overflow in ICQ response parsing
in the Protocol Analysis Module (PAM) of ISS products. It is a memory-
resident worm only, and contains no file payload. Witty propagates via
UDP, sending UDP packets with a random destination and destination port.
The source port of Witty traffic is 4000, and the source address is not
spoofed.

The worm will attempt to propagate immediately by sending copies of
itself out across the wire to random targets. After sending a predefined
number of packets, Witty attempts to open a randomly determined physical
drive and write 64k of data to a random location. This cycle repeats for
every 20,000 packets sent.

According to Symantec's Witty information page, Norton Antivirus can't detect it because it is memory resident only, and never written to disk.

As the story summary states, it "attempts to overwrite 128 sectors in a random location of one of the first eight physical hard drives with data from memory. If the randomly picked physical hard disk does not exist, the worm simply continues." Devastating.

BlackICE patches are available.

Easy :)

"The Witty worm....only infects Win32 systems."

To be fair (and it pains me to be so) but it seems to be a problem with the application rather than system softs.

In fact, it's the other way around:

The worm will attempt to propagate immediately by sending copies of itself out across the wire to random targets. After sending a predefined number of packets, Witty attempts to open a randomly determined physical drive and write 64k of data to a random location. This cycle repeats for every 20,000 packets sent.

You could say this was Microsoft's fault for making a crappy, userless don't-manage-memory-well kernel, for having inadequate file systems that lack permision bits, and the list goes on and on. Why else did the poor suckers have to BUY a third party firewall? Because Microsoft is a toy OS that has no place on the internet, that's why. There are many other good reasons this is Microsoft's fault, I'll leave them to others. That would be funny if it were not true.

Forget about the DDOS attacks. It's a distraction. The bigger problem is that the DDOS may be able to be changed on command to any other site on the internet.

This is a spam zombie virus. We need to work securing our comprimised systems and keeping them from joining the spam network and obeying the commands. If anyone has any real information about how this virus works as a relay and how to stop it at the network level please post it.

So far I've found the following links. Blocking port 3127 at the router seems like it could help a lot. Any other (real) solutions would be appreciated.

http://xforce.iss.net/xforce/alerts/id/161
http://www.savvy.net/detail.asp?category_id=7&arti cle_id=91

Well spoken. It's nice to see some clear examples instead of "AMD sucks".

But, being the AMD fan I am, I must say that perhaps your problems are more due to bad luck than anything, since RMA rates for motherboards are significantly higher than other components.

And so this brings me to a question... is there a site that gives statistics on RMA rates?

- - - - - - - - - -

P.S. - The following riposte is a cut and paste of a previous slashdot post:

Pentium Floating-point division bug [ku.edu] (it's close enough, isn't it?)
Invalid Operand Instruction crashes original Pentiums [iss.net] Pentium crash codes
Pentium Pro/II still having problems with floats [ddj.com] Unable to convert to int
Pentium III can't even start up [bbc.co.uk] You went faster with an 8088
SSE is great for when you want your PIII to crash [zdnet.co.uk] Pretty blue screens abound.
PIII Xeon, quality you can count on, except at high CPU usage [macworld.com] Watch the task manager, Phil.
Yay, PIII MTH crashes! [com.com] Does MTH stand for Meth?
Total Recall 2: PIII@1.13GHz [com.com] Fastest crashes ever.
Total Recall 3: PIII Xeons@800/900Mhz [com.com] More Xeon quality in a box.
Total Recall 4: CC820 [techweb.com] How many defects? Can't recall...
Pentium 4 overwriting data [zdnet.co.uk] Hope it wasn't something important.
Pentium 4 chipset bug [com.com] Fast video performance? Naaa.
P4 Oracle/Sun problems [indiana.edu] More workarounds than work
Itanium shipments halted [theinquirer.net] That's an expensive oops.

Just so nobody gets any ideas that Intel is perfect...

This may be redundant, but I was thinking the ISS (Internet Security Scanner) had a leak. That would be equally bad, I presume.

Here are my most favorite windows apps. Some are free. All at least have trials. They are in no particular order.

Firewall: BlackIce
Virus Scanner: AVG Anti-Virus
Instant Messaging: Trillian
Movie Player: BSPlayer
Web Browser: Slim Browser
Mail Client: The Bat!
Taskbar Improvement: True Launcher Bar
SpyWare Protection: Spybot Search & Destroy
File Compression: Win Rar
Hex Editor: Hex Workshop
Audio Player: Winamp
Ternimal Emulator (telnet/ssh/etc): SecureCRT

But you forgot the current result is that it's not routable.

ok...someone try to reach my 10.10.10.3 machine ...hard to do isn't it?


http://www.iss.net/security_center/advice/Underg ro und/Hacking/Methods/Technical/Source_Routing/defau lt.htm

That method will not work if you have a quality firewall. But the reason for that not working has absolutely nothing to do with the fact that you are NATing.

Two security companies and a publisher (and a regular joe). I'll bet if Foundstone and eEye turned *alot* of their resources on the linux os/apps or Sun os/apps, we'd see alot more reports. The reports wouldn't be nearly as visible since Microsoft actually bothers to go out of their way to annouce them.

Gibson's "Black Ice",

Yes, i'm a nit-picking bastard, but Steve Gibson did not make BlackIce.

From all appearances, I wouldn't trust the man to secure a piece of swiss cheese, let alone government systems. Read his site or visit this other site to get an idea why.

It looks like it's fixed in many Linux disributions and you don't have to downlad raw sendmail yourself. For example, ISS reports it's already fixed in updates from RedHat for 6.2 through 8.0 and presumably for 9.0 as it was released later. Other vendors have similar reports. Check out the ISS link.

Black Ice Defender
Zone Alarm

Oh you mean why didn't they bundle a free one?

Well since Microsoft tweaked free code bought and paid for by taxpayers and gave it back to their customers for free, and then found out that was illegal, I'm not so sure they'd be so quick to so flagrently dare the states to sue them again.

Probably why the XP personal firewall is so limited. But there's always IAS!

Here is a nice command line utility to scan your network for vulnerable machines. It gives you a neat list of patched and compromisable computers.

http://www.iss.net/support/product_utilities/ms03- 026rpc.php

How to find applications which use a port (necessarily incomplete)

1. Education - Get educated about what information security is all about, you should know what C.I.A. stands for (in infosec, not the US federal agency), you should know what a security policy is, understand risk management and mitigation, and known what criminals/attackers can do in your organization.

You can get a lot of this from several books and websites, such as Secrets and Lies by Bruce Schneier, the SANS Reading Room, if you can afford it SANS/GIAC training and/or certification may be of benefit to you and your org, the CISSP and SSCP Open Study Guides even if you don't go for CISSP or SSCP (I don't recommend paying any money to ISC^2), and Security Focus.

2. Audit - This step is critical and too many places forget to do it. You need to know what you are trying to secure, yet most organizations do not have a complete picture of their network and all the systems on it. This includes security and non-security issues (e.g. software licenses, maintenance patches, standardization)

Tools like those from IBM Tivoli or HP Openview can help here. For security specific vulnerability analyzer, open-source Nessus and eEye's Retina, ISS's Internet Scanner

3. Policy - You need a plan and a document to give you and others guidenance, and this if your infosec policy.

Large orgs should consider BS 7799 or ISO 17799 whereas smaller groups can look at Center for Internet Security for benchmarks, and SANS Reading Room - Auditing and Assessment, and Site Security Handbook - RFC 2196.

4. Implement -- Using your education, audits and policies you can now implement decent security.

Basic principles of defence in depth, fail-safe, separation of privilege, and complexity is the enemy of security can guide you to build a practical network of secured systems that limits exposure to criminal activities, and minimizes damage from attacks.

5. Be vigilant - "Security is a process, not a product" - Bruce Schneier

Now the work begins, up to now it was the fun stuff, now you get to dig in with boring but important tasks such as analyzing log files, maintaining a accurate asset database, applying patches, maintaining user accounts, periodic audits (internal and if you can afford it and it is warranted, external), educating users, and maintaining your security posture.

ISS is Internet Security Systems, Inc.. They produce RealSecure, Internet Scanner, System Scanner, etc.

My guess is that the root of the problem is in ntdll.dll, but it could be mitigated by filtering WebDAV requests using the URLScan utility.

Yup. According to the ISS advisory, the overflow is "in a path conversion function within NtDLL, which is called from a common API exported from the Kernel32 library." WebDAV is just the attack vector. Filtering WebDAV requests removes the known remote attack vector, but you really need to patch the underlying problem (ntdll) in order to be sure.

The proof of concept is right here.

It's a Flash animation that demonstrates how to exploit the sendmail vulnerability. They went through all this trouble to make a flash animation just because they found a vulnerability? They must not find vulnerabilities very often and this is a big deal. Or maybe they just have an overstaffed graphics/web design department with too much time on their hands.

Be sure to watch the animation of the sendmail exploit. Talk about rubbing it in. Not only did they post their discovery, but they made a cartoon about it. That takes some time to make, so they must think they'll be able to use the cartoon again. They're probably right - it's sendmail.

1. 
   Pentium Floating-point division bug (it's close enough, isn't it?)
   Invalid Operand Instruction crashes original Pentiums Pentium crash codes
   Pentium Pro/II still having problems with floats Unable to convert to int
   Pentium III can't even start up You went faster with an 8088
   SSE is great for when you want your PIII to crash Pretty blue screens abound.
   PIII Xeon, quality you can count on, except at high CPU usage Watch the task manager, Phil.
   Yay, PIII MTH crashes! Does MTH stand for Meth?
   Total Recall 2: PIII@1.13GHz Fastest crashes ever.
   Total Recall 3: PIII Xeons@800/900Mhz More Xeon quality in a box.
   Total Recall 4: CC820 How many defects? Can't recall...
   Pentium 4 overwriting data Hope it wasn't something important.
   Pentium 4 chipset bug Fast video performance? Naaa.
   P4 Oracle/Sun problems More workarounds than work
   Itanium shipments halted That's an expensive oops.
   

The advisory announcing the flaws:
http://www.nextgenss.com/advisories/mssql-udp.txt Various disassemblies and discussions: http://www.snafu.freedom.org/tmp/1434-probe.txt http://www.digitaloffense.net/worms/mssql_udp_worm / http://www.boredom.org/~cstone/worm-annotated.txt

Writeups:
http://www.cnn.com/2003/TECH/internet/01/25/intern et.attack.ap/index.html
http://news.bbc.co.uk/2/hi/technology/2693925.stm
http://story.news.yahoo.com/news?tmpl=story&u=/ap/ 20030125/ap_wo_en_po/na_gen_internet_attack_2
http://bvlive01.iss.net/issEn/delivery/xforce/aler tdetail.jsp?oid=21824

Best writeup I've seen is over at iss.net. They were the first to update their internet status homepage alerting of the vulnerability as far as I can tell.

Ummm, no. "inverse" does not in any way shape or forme identify a request for the hostname associated with an IP address.

Yeah, most of the time so-called "reverse lookups" are done by doing a normal query of a PTR RR. But there is also, an obscure DNS query called an iquery, where the answer is prefilled in with the IP address and any name. If the query type is IQUERY, then the server (if it supports it) is supposed to lookup the name that corresponds with the IP address.

More details here. See section 6.4.2.

So, basically, the previous poster is right. But as far as I know they're hardly ever used. They are, however, part of a security vulnerability of DNS. So I wonder if the 98% of packets sent to the root namesevers indicate that 98% of the time, those nameservers are really under attack.

What were their old ones? In most circumstances 30 days notice to the vendor is the only responsible way to go. Most companies are responsible enough to turn around a fix in that time.

BTW, the ISS press release is here.

No wonder we spent $40 billion on ISS!

They needed to research and develop their policies.

Whoops.... wrong ISS

Firewall ports 137-139(NetBIOS...according to ISS port 139 is the "most dangerous port on the internet")...

This should keep any machine from accessing internal Samba shares from an external connection and makes these kinds of vulnerabilities irrelevant. Unless you don't trust ppl on your own LAN...then you have other problems...

I can't think of any real reason to leave a NetBIOS port open to "the outside world"...so for those of us that actually firewall these ports, this is already taken care of...

• They were certainly well-known when I was in college in the mid 70s, but the PL/C dialect of the PL/I checkout compiler corrected mistakes like that at run-time. (OK, it often fixed them incorrectly, but at least least it wouldn't overrun an array.) And our professors dinged us for writing programs where that happened, and made us run the programs on input decks that were maliciously designed to check for programs that overflowed their buffers.
  
• They were certainly well-known when K&R wrote their books on C which warned you to be careful about bounds checking when using pointers and arrays.
  
• They were certainly well-known in the early 80s when everybody started complaining that the gets() and scanf() routines made it easy to overrun buffers on input when you weren't doing it by hand.
  
• They were certainly well-known in the late 80s when the Morris Worm wandered around a lot of the machines in the internet.
  
• They were certainly well known when the C++ string-handling libraries were designed to NOT overrun buffers, and when Java was designed to not even have pointers, and had array objects that checked bounds for you.
  
• There are enough software engineering CASE tools that try to find problems more complex than lint() looks for, though perhaps array bounds checking isn't something they check effectively.
  

There are other bugs out there - a popular attack is to try to abuse dotdots in path names, which there's more excuse for forgetting to check, and there are things like race conditions that are genuinely hard to check for (e.g. what happens when somebody's ripping up your temp files while your program is running), though checking return codes on system calls and doing something appropriate about failures is a good start.

However, as explained in this white paper you might not even want to try to run Snort rules in RealSecure, because in many cases its own signatures are much more accurate. That's because RealSecure actually does protocol analysis, while Snort just matches patterns. See the paper for details.

Full disclosure: I used to work at ISS and still own a bunch of stock in it. However I wouldn't post this for any of their products (some of them suck). RealSecure is one of their good ones.

However, as explained in this white paper you might not even want to try to run Snort rules in RealSecure, because in many cases its own signatures are much more accurate. That's because RealSecure actually does protocol analysis, while Snort just matches patterns. See the paper for details.

Full disclosure: I used to work at ISS and still own a bunch of stock in it. However I wouldn't post this for any of their products (some of them suck). RealSecure is one of their good ones.

However, as explained in this white paper you might not even want to try to run Snort rules in RealSecure, because in many cases its own signatures are much more accurate. That's because RealSecure actually does protocol analysis, while Snort just matches patterns. See the paper for details.

Full disclosure: I used to work at ISS and still own a bunch of stock in it. However I wouldn't post this for any of their products (some of them suck). RealSecure is one of their good ones.

There are no new lessons here. This is not the first worm for Linux. It is not the first DDoS architecture for Linux. Nor does CNET's estimation of 3,500 infected machines match its Code Red estimations that have floated from "...more than 15,000..." to "...more than 350,000...".

It would seem anybody who is finding something insightful in this story are either a Linux or Windows zealot, brand new to the argument, or very poor students of recent history. Granted - "recent" becomes is somewhat subjective. So let's take a brief look at past DDoS applications and Linux worms.

Distributed Denial of Service (DDoS) architectures began hitting the Industry consciousness late 1999. At that time it was trin00 and TFN. Shortly afterward, new versions showed up in the wild including TFN2K and Stacheldraht. All can be run on Linux. Although they are not, themselves, worms.

Linux worms are not new... nor are they ancient history. There are some excellent examples from a little over a year ago. One of the first worms from 2001 was the Ramen Worm and was reported by CNET January 17, 2001. Of course, CNET's article didn't have impressive numbers to report but it did liken it to the infamous 1998 Morris Worm. The Ramen Worm was followed by a less-famous variation called Adore and it also garnered CNET coverage April 4, 2001. But it wasn't too interesting a worm. It had been overshadowed by a worm reported the previous month dubed Lion. The Lion worm also got its own CNET coverage.

In each case, the worm in question used well-known security flaws with existing patches.

If one wants to point out that any OS is vulnerable if it is not properly maintained, then this latest worm is simply one of a series of worms that have proved this point. And worms have made object lessons of Linux, Windows, and other popular OS variants such as Solaris (sadmind/IIS being my favorite as it propagates on Solaris machines and then attacks and defaces IIS web sites).

Not coincidentally, ISS has a quite nice offering in this area as well.

No offense to our open-source IDS friends, but the commercial IDS world realized this exact thing at least 5 years ago. I used to work on the network based IDS products at ISS, and we started recommending this back in 1997 (when I started working there). Here is a link (PDF) to a document that describes (among other things) running RealSecure in "stealth mode" and it dates from 1998.

Security Update 2002-08-02

• This update addresses the following security vulnerabilities which affect current shipping versions of Mac OS X Server. These services are turned off by default in Mac OS X client, however if these services are enabled then the client becomes vulnerable. It is recommended that users of Mac OS X client also apply this update.
• OpenSSL: Fixes security vulnerabilities CAN-2002-0656, CAN-2002-0657, CAN-2002-0655, and CAN-2002-0659. Details are available via: http://www.cert.org/advisories/CA-2002-23.html
  
  
• mod_ssl: Fixes CAN-2002-0653, an off-by-one buffer overflow in mod_ssl Apache module. Details are available via: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0653
  
  
• Sun RPC: Fixes CAN-2002-039, a buffer overflow in the Sun RPC XDR decoder. Details are available via: http://bvlive01.iss.net/issEn/delivery/xforce/aler tdetail.jsp?oid=20823
  
  

If you can't tell I'm a big proponent of ISS. But then again I'm also a student at GA Tech! Not a big fan of their BlackICE product but a big fan of their R&D and Corp Security Audit abilities. You may want to also check out your "local" chapter of Infragard and ISSA. These are both very reputable INFOSEC SIGs with members who are actively involved in INFOSEC issues of all varieties.

First off, the reason your security is broken is that you probably don't have a policy and if you do nobody understands it and if they do there's no QA ensuring that they follow it.

Good security starts with the establishment of a security policy followed by education and regular awareness events. Please be aware that paying someone a ton of money to pen. test and inventory your assets will *not* result in a stronger security posture all on it's own. You must have a policy in place and you must compel your users to abide by it (primarily through education, secondarily through threat of penalty). Consider hiring a CISSP or other certified professional to help you through this process. You might be able to find one in your area by using the ISC2 directory. SANS is doing some ISO certification as part of the GIAC program now and they may be able to point you towards some appropriate people as well. The ISSA might be able to help as well. As has been mentioned already, you probably don't want to entrust this to someone selling countermeasures or management services.

Understand, however, that you don't need a firewall engineer right now and you don't need some krad ex-hacker to pen test either. You need someone to help you get your house in order on the administrative side and then you can look into some detailed engineering and assessment. That someone should probably be an independent consultant or at least one working with an infosec specializing firm. If you want a couple bigger names there's @Stake, Booz Allen Hamilton, and Predictive, however, I would encourage you to seek out a local independent with good references.

Any knucklehead can run Nessus and patch systems. This alone does not equal information security. If you want a secure environment, start by defining what "secure" means within your environment.

External audits are good because they bring in experts who focus on finding vulnerabilities in your network. These experts will come armed with a variety of vulnerability assessment tools to perform their audit. The only problem is that it will almost always happen less frequently than vulnerabilities are discovered, so this should only be 1 part of the overall solution.

You should adopt this practice internally, because if the tools are set up to check for vulnerabilities, you can be much more proactive about finding them than simply by scheduling consultants to come every few weeks, months, year. There are a variety of tools available, both freely and commercially.

A good tool will be updated frequently, check a lot of bugs, including the most critical (SANS Top 20, BugTraq, CERT.

Free Tools
SATAN -- Security Administrator Tool for Analyzing Networks
SAINT -- Security Administrator's Integrated Network Tool -- based on SATAN, GNU
SARA -- Security Auditor's Research Assistant -- similar to SATAN/SAINT check the Freshmeat page
NESSUS -- another free tool

Commercial Tools
ISS has a variety of tools avaiable depending on your needs
NeXpose -- try the free demo, great ui, demo only lets you assess 1 IP at a time though :( Here is a review
A Networking Computing article on Vulnerability Assessment tools. Reviews many of the major vendors (so I won't list them all). Includes some of the free tools.
Here is another overview of security tools to get you started.

We had way too many false positives with their Scanner and Realsecure, even had an ISS guy onsite for a few days. Still, too many problems. With vendor support that... well... is a pain in the *@&%#$ to deal with we switched to Snort and Nessus . Much easier to manage and the false positives went to almost nothing. I'm not even going to start on the Managed firewall crap!

"Originally, e-mail was text only, and e-mail viruses were impossible."

shame it's not true
Buffer overflow in MS Outlook & Outlook Express Email clients (Date parsing)

Here's the details on what exactly the vulnerability is

Basically, the assertion that one could gain access to the whole hard drive is false. Looks like a FUD attack on file sharing to me.