Security Watch

Criminals on Autopilot

Also:

• By Russ Cooper
• 07/14/2008

CA has a security blog that points to yet another example of how criminals are gradually getting their malware onto Web sites that would normally be considered "safe" or, at the very least, not be expected to deliver malware. The blogs points to criminals using automated tools to scan search engine records for specific criteria. In an example, a Web page has a reference to .asp as well as an a= tag. denoting it's an IIS Server running ASP that has a page that can be called with a parameter named "a". Such pages are likely hosted with an SQL server, at which point the criminals try to use SQL commands to alter the content.

No rocket science involved here, but it demonstrates the potential problems with having search engines storing so much information. There is nothing the search engine companies can do and in this case, nothing indicates that the sites being discovered by such searches are vulnerable. The criminals don't really care one way or the other; they simply look for likely targets and attempt to compromise them.

That our sites are under constant attack is a given. That those attacks are typically old is also equally true. That we must maintain vigilance, particularly when implementing a new server, is a must. Bringing a new server up, online, and then configuring it securely is just bad practice. The box must be secured first.

It is equally true that our mantra about how services should be separated onto different platforms has also been borne out. If you have a Web site serviced by a SQL server, but that server is accessible only by that Web server, then the attacks I mentioned simply wouldn't work with your site, regardless how securely you implemented SQL. The criminals are relying on the premise that a Web site found with those parameters also hosts a SQL server which the criminals can then connect with. Without that basic service, and assuming the Web server is secured from being written to by the criminals via other methods, the criminals are stopped dead in their tracks.

Another method that criminals can get in is within your own ASP code. If you just pay attention to the parameters used in your URL references -- both what parameters are allowed and what content you expect in each (including a maximum length) -- then you can effectively "scrub" your input to your SQL server.

Unfortunately, there are more than a few Web hosting providers who put SQL servers on the same servers as the Web servers. You should verify whether this is the case with your hosting provider.

SoundBlaster Goes Silent
Creative Labs' automatic update mechanism incorporates an ActiveX control that's activated when you visit the company's Web site. The control is marked safe-for-scripting, and as such, can be invoked by any site. Criminals could exploit a vulnerability in the control via the CacheFolder parameter, which could trigger a buffer overflow and allow a criminal to run code on a victim's system in the context of the control, typically whatever the user is. Updates are not yet available.

This is certainly a concern given how widely deployed are Creative Labs' products, such as SoundBlaster. However, there are clearly extra steps the average user would have to take in order to have the control installed -- many systems we checked which had Creative Labs' hardware did not have the control. While it is possible to imagine all sorts of scenarios which may prove attractive, such as "Please visit Creative Labs to update your software," followed by a prompt to install the official Creative Labs update control, the simple fact remains that the victim must first visit a criminally controlled site.

We have little doubt this will attract the attention of the criminals, and we remain reasonably confident that the control is not widely deployed and not likely to be installed by many potential victims should attempts such as the one above be made. We are, of course, tracking this issue.

We would recommend that the killbit be set in IE for this control via the following key/value pair:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Internet Explorer\ActiveX Compatibility\
{0A5FD7C5-A45C-49FC-ADB5-9952547D5715}]
"Compatibility Flags"=dword:00000400

Botched Play
A few weeks ago, Symantec alerted the media to what they believed was an attack involving an unpatched Adobe Flash vulnerability. This was picked up in a number of sources, and various security companies debated whether it was exploiting the vulnerability that was found in Flash back in April. Adobe has since confirmed that it was indeed the April vulnerability patched by v9.0.124.0. Exploitation results in code running in the context of the victim user. Patches are available.

The Adobe link here will determine the version of Flash you have installed and offer an update should you not be running a current version. We believe it to be prudent to try to incorporate this link into internal landing pages you have within your Intranet in an effort to get clients to update to recent versions if alternative updating mechanisms are not available.

Beware the Kraken
Microsoft's Anti-Malware Engineering Team published numbers on this month's Microsoft Software Removal Tool attempt at cracking the Kraken botnet. A humorous and informative read, providing some interesting statistics worth noting.
http://www.securityfocus.com/brief/743?ref=rss
http://blogs.technet.com/antimalware/archive/2008/05/21/
oderoor-all-its-kraked-up-to-be.aspx

Both good and bad news in the report.

Bad: Approximately half of the PCs in the world are running the MSRT, meaning the others are likely not getting automatic updates. Good: Kraken was found and removed from more than 250,000 machines. No doubt that 250,000 sounds like a lot, but that's just 0.05 percent of the 500 million systems that ran MSRT this month. The idea that the majority of systems connected to the Internet are infected with something takes another shot in the rear.

What would be interesting would be for Microsoft to use some method to find out how many of the systems they clean need to be cleaned again, regardless what it is that MSRT finds. We tend to believe there are a bunch of people out there who simply get infected over and over again, which is one reason we also suggest you focus on users who have had a previous infection when deploying patches -- those users simply are more likely to succumb to something in the future.

Bad: The report tends to make a game out of whose botnet is bigger, something we never like to see. Some criminals are out there bragging based on the wording used by the MS folks, despite the fact their botnets are being devastated by MSRT's effectiveness.