Slight Increases in SSH Probes

Our HoneyPoints have been picking up slight increases in the probes and brute force attacks against port 22 – SSH. We are seeing increases in wide scale SSH scans and attacks against common login/password combinations.

Now might be a good time for folks to take a look at their perimeter and make sure no one has poked an SSH exposure through. If you have some, they should be immediatly audited for common account use. Treat any system with these issues as likely compromised and initiate an investigation.

Most of these compromised systems are used for further scanning and many have bot-net clients installed. Keep an extra eye on your logs for obvious forms of bot-net traffic, such as IRC connections, odd ports and outbound half-open TCP connections.

InstallShield Issues and BorderManager Vulns

Macrovision InstallShield Update Service contains an insecure method vulnerability. InstallShield contains an ActiveX control that is marked safe for scripting. An attacker could leverage the update service to download and install malicious software. Due to the fact that it is marked safe for scripting, this could be exploited by a malicious web site or a downloaded application. The following ActiveX control should be disabled so that Internet Explorer will not load the control.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{E9880553-B8A7-4960-A668-95C68BED571E}]

“Compatibility Flags”=dword:00000400

The updated versions of FlexNet and InstallShield products will not be marked safe for scripting.

Additionally, Novell Border Manager Client is vulnerable to a remote heap-based buffer overflow. The vulnerability exists within the Client Trust Application and can be exploited by sending a specially crafted packet to the application. Successful exploitation could result in the exploitation of arbitrary code. The vulnerability is reported in Novell BorderManager 3.8.

WatchDog Content Moving to StateOfSecurity.com

If you are a regular WatchDog product user, then you may already know this, but on November 1, 2007 MSI will move all WatchDog content to this blog and begin to phase out the WatchDog client program.

This is being done to simplify the use and access to the information and to enable users to easily leverage our threat intelligence offerings via RSS and other popular mechanisms without using our locked-in client.

The same information that WatchDog has brought to you for years will continue, but hosted here instead of through the WatchDog client. It will also be stored in the emerging threats category – thus making it easy to subscribe or filter on.

We hope you continue to benefit from our work and insights, and please, let us know how you like the WatchDog content and if we can do something better or more helpful with the data.

Blast(s) From the Past

A few of my HoneyPoints delivered an interesting blast from the past to me this morning. Around 2pm Eastern yesterday, one of our IP ranges got hit by a scan with this signature on port 80:

GET /level/16/exec/-///pwd HTTP/1.0

The web connection was then followed by a series of connections on port 23, though the tool did not do anything more than banner grabbing on the telnet port.

While the scan was obviously an attempt to exploit the old Cisco HTTP vulnerability (circa 2001), I had not seen probes for those issues in quite some time. I also had not seen a tool that also connected on port 23 of the same host and did banner grabbing, so thus why this stood out above the usual noise.

This brought about a very interesting point that many of these old vulnerabilities are making comebacks. Scans for old web vulnerabilities like Unicode issues, Double Decode, Code Red and the ASN.1 worm continue to be among the most seen probes on the Internet. Other folks have talked about the idea that perhaps as more third world countries become more Internet connected, that technology may not be updated there as rapidly – which could cause the lifecycle of older vulnerabilities to either be reborn or at least, eek out a longer existence. Could ancient vulnerabilities like RDS and .HTR buffer overflows still be leveraged for Internet compromise? The possibility is high that some small percentage of systems is likely available as a vulnerable target.

Does this mean that vulnerabilities will have a lifecycle that approaches infinity? If there are still systems out there that are vulnerable, why would some attacker without general worries of discovery not just keep building a super-worm that continually crawls the net looking for every known web vulnerability to date? If incorporated and distributed through bot-net style approaches, this is likely pretty feasible – particularly if you can make the attack smart enough to adapt its vulnerability testing to the specifics of a target – much like a modern scanning tool.

How will some of these older vulnerabilities fair? It remains to be seen, but my bet is that blasts from the past are likely to keep on rolling in some diminutive way. Let’s just say that I think it will be a long time before we live in a Code Red free world.

VMWare Guest Security Problems

A few more problems seem to have been identified in VMWare and the potential isolation of the Guest systems. This article discusses how malicious code can be spread to Guest hosts via the scripting API of VMWare products.

This is especially dangerous given that many security researchers use VMWare and other virtualization mechanisms to study malware, attack code and other less-than-friendly mechanisms, but it has ramifications for everyone else too. VMWare claims, according the author of the article, to stick to their design decision that allows the issues to exist. They believe that the good of the feature outweighs the risk of compromise. I am not so sure they are right.

VMWare and other solutions are quickly moving into the core of most organizations and their IT spectrum. They have long evolved from geek-centric tool to mainstream deployment. As such, a vulnerability of this magnitude should be treated as severe. Guest OS isolation has always been a deep value to be maintained if virtualization is to reach even higher market penetration. Organizations simply can not afford, in today’s regulatory environment, to not be able to depend on isolation in their virtual systems. Without it, they will be back to deploying multiple physical systems to manage compliance – and we have already seen that this is not the way we want to go.

While work-arounds for fixing this specific issue exist (read the article for details), I think all IT folks should make it very clear to VMWare and other virtualization vendors that we can not accept issues with host isolation, no matter the cost to features and shortcuts. The risk is simply too high. Please, if you are a user of VMWare, let them know your thoughts. Drop them, or us, a line.

Oh, and don’t forget to modify your config files to disable the feature that makes this vulnerability possible!