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 released?
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 service.
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 response.
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