The success of "SQLSpida," the worm that targets MS-SQL servers set upon the
Net with a blank "SA" password, is testament to how badly basic security
education is still needed.
As always, I place primary blame on the administrators of these
boxes-leaving the SA password blank on any installation is a rookie move.
To do so on a production machine placed on the Internet is just plain
stupid. You have probably guessed that my use of "primary" infers a
secondary party in responsibility; and indeed it does: Microsoft.
Microsoft has been riding the fence between marketing a concept of
"trustworthy computing" and delivering a product that caters to the least
common technically proficient denominator. Most products have been
specifically designed to allow anyone who can click "Next" to perform a
successful installation, but when it comes to their defense of insecure
default software settings, they have a matter-of-fact way of telling
everyone that they should know better.
For instance, Microsoft knows that the default application extension
mappings in IIS are deadly, and we are blamed for not removing or remapping
them; yet they are all enabled by default, and one must drill down deep into
the interface to turn them off. In default installations of SQL, the SA
user can perform remote system-level functions, yet they allow the password
to be blank, and they don't even give us the functionality of renaming the
account. Administrators are expected to set proper ACL's on system files,
but even in their Advanced Server product, Microsoft assumes the admin to be
so inept that Windows Explorer hides the contents of the WINNT directory so
that the user won't monkey with them.
It is time for Microsoft to start shipping products with more secure default
settings, and to require a certain level of expertise from the
administrators of these systems.
VENDOR NOTIFICATION ALERTS. But safer out-of-the-box settings are not the only thing we need -- clouds
continue to billow on the vulnerability landscape. Too many software
vendors are so busy working on the Next Big Thing that they are
unnecessarily putting their customers at risk by sitting on security patches
for their current products.
If you are not familiar with David Litchfield or Next Generation Security Software,
then you should be. Litchfield probably has the world record for
discovering the most buffer overflows. And like many other security
professionals, he won't disclose details of his exploits to the public until
the vendor can release a patch.
But how long is one to wait for the vendor the get their act together? How
long must customers' systems lay in wait of exploitation before a patch is
Last month, Litchfield discovered a remotely exploitable vulnerability in
Sun's iPlanet. Though Sun has already developed a patch for this critical
issue, Litchfield says, they have decided not to release it until the end of
next month so it can be included in a rollup package. So much for customer
And if you think the current scans for SQL Server are high, you ain't seen
nuthin' yet. Litchfield has also discovered a heap based buffer overflow in
SQLServer 2000 that allows an unauthenticated attacker to gain remote
control over the server in the context of the SQLSERVER service. Just the
mention of this type of exploit makes a blackhat's mouth water in Pavlovian
But even though he provided fully-functioning exploit code to Microsoft,
Litchfield tells me it took them a week to respond with simple confirmation
they were able to recreate the issue. This is simply unacceptable.
Litchfield claims similar discoveries that even eight months later have
still not been addressed by Microsoft.
Enter the Vendor Notification Alerts (VNA). Litchfield has decided to roll
out an interesting vulnerability alert system somewhere between "full" and
"wait for a patch" disclosure.
These VNA's will disclose the vendor and problem product, along with general
exploitation protection methods, without giving away too much detail about
the vulnerability itself. In this way, the heat can be turned up on the
vendor and customers can be alerted to the fact that problems exist, but a
blackhat won't get enough information to design an exploit.
To date, 15 such issues exist with other products, including more issues
with Oracle, and can be viewed on NGSSoftware's web site.
In addition, Litchfield's "Typhon II" vulnerability assessment tool will
have checks for most of these vulnerabilities built into it. Though I'm not
one to make public endorsements for commercial products, I can tell you that
purchasing a product that alerts you to problems vendors haven't even
addressed yet is most definitely a smart thing to consider.
Any successful company knows a customer's interests should come first. If
the timely distribution and maintenance of critical security patches for
their products is too much for a vendor to deal with, they should get out of
the software business. Hopefully NGSSoftware's VNA idea will catch on, and
patch production can take priority without exposing the customer to
unnecessary risk. By Timothy M. Mullen