Yet More on SockStress…

OK gang, the story gets interesting again….

Check this out for some deeply technical details on some level of the basics of the attack. Fyodor has done an excellent write up of his guess.

You can also check out the response from the relevant researchers here.

I do like and understand Fyodor’s point that this smells like marketing. Perhaps we are supposed to believe that the vendors will have their responses coodinated and completed before the talk and disclosure? If not, then what is the point of waiting to disclose except to sell tickets to the conference?

This is a pretty HUGE can of worms that seems to have been opened by Kaminsky during the recent DNS issue. I guess it is just another nuance of this new age of attackers that we have entered. We will have to deal with more “huge holes” accompanied by media-frenzy, hype, researcher infighting and security vendor blather until the public and the press grow tired of it.

My point yesterday was that one of these days we will reach a point when some of these major vulnerabilities will not be able to be easily repaired or patched. When that becomes so, we may have to find a way to teach every day users how to plan for, and engineer for, acceptable failures. Until then, we should probably hone those skills and ideas, because it looks like where we are headed may just be fraught with scenarios where some levels of ongoing vulnerability and compromise may be a fact of life.

I believe strongly that we can engineer for failure. We can embrace data classification, appropriate controls and enclave computing in such a way that we can live with a fairly high level of comprise and still keep primary assets safe. I believe that because it seems to be the way we have dealt with other threats throughout history that we could not contain, eliminate or mitigate. We simply evolved our society and ourselves to the point where we could live with them as “accepted risks”. Some day, maybe even soon, we will be able to spend a lot less time worrying about whether or not users click on the “dancing gnome”, keep their workstations patched or if there is a vulnerability in some deep protocol…

The Protocol Vulnerability Game Continues…

First it was the quaking of the Earth under the weight of the DNS vulnerability that kept us awake at night. Experts predicted the demise of the Internet and cast doomsday shadows over the length of the web. Next came a laser focus on BGP and the potential for more damage to the global infrastructure. Following that came the financial crisis – which looks like it could kill the Internet from attrition when vendor, customer, banking and government dollars simply strangle it to death with a huge gasp!

Likely, we haven’t even seen the end of these other issues when a new evil raises it’s head. There has been a ton of attention on the emerging “sockstress” vulnerability. According to some sources this manipulation of TCP state tables will impact every device that can plug into a network and allow an attacker to cause denial of service outages with small amounts of bandwidth. If this is truly a protocol issue across implementations, as the researchers claim, then the effects could be huge for businesses and consumers alike.

What happens when vulnerabilities are discovered in things that can’t be patched? What happens when everyday devices that depend on networking become vulnerable to trivial exploits without mitigation? These are huge issues that impact everything from blenders to refrigerators to set top cable boxes, modems, routers and other critical systems.

Imagine the costs if your broadband ISP had to replace every modem or router in their client’s homes and businesses. What choice would they have if there were a serious vulnerability that couldn’t be fixed with a remote firmware upgrade? Even if the vulnerability could be minimized by some sort of network filtering, what else would those filters break?

It doesn’t take long to understand the potential gravity of attackers finding holes deep inside accepted and propagated protocols and applications.TCP is likely the widest used protocol on the planet. A serious hole in it, could impact risk in everything from power grid and nuclear control systems to the laundromat dryers that update a Twitter stream when they are free.

How will organizations that depend on huge industrial control systems handle these issues? What would the cost be to update/upgrade the robots that build cars at a factory to mitigate a serious hole? How many consumers would be able or willing to replace the network firewall or wireless router that they bought two years ago with new devices that were immune to a security issue?

Granted there should always be a risk versus reward equation in use, and the sky is definitely NOT falling today. But, that said, we know researchers and attackers are digging deeper and deeper into the core protocols and applications that our networks depend on. Given that fact, it seems only reasonable to assume that someday, we may have to face the idea of a hole being present in anything that plugs into a network – much of which does not have a mechanism to be patched, upgraded or protected beyond replacement. Beginning to consider this issue today just might give us some epiphanies or breakthroughs between now and the tomorrow that makes this problem real…

Morfeus Scanner soapCaller.bs Scans

Our HoneyPoint deployments have been picking up a recently added (August 08) scan signature from Morfeus, the bot-based web scanner, that has been around for a long time. The new scans were first detected on our consumer grade DSL/Cable segments in late August and have now also been seen on our Corporate environment sensors as well.

The scans check for “soapCaller.bs” and then “/user/soapCaller.bs”. Returning a 200 result code did not bring any additional traffic or attacks from the original source within 96 hours of the initial scans. In fact, returning the 200 did not seem to cause any change in behavior of the scans or any additional attacks from any source. Likely, this means that vulnerable hosts are being cataloged for later mass exploitation.

Morfeus scans are quite prevalent and can include searches for a number of common PHP and other web application vulnerabilities. Google searches on “morfeus” return about 259,000 results, including quite a few mentions of ongoing scans from the bot-net.

Here is a blog post that discusses using .htaccess rules to block scans with the morfeus user agent.

Morfeus has shown itself to be quite adaptive and seems to be updated pretty frequently by the bot-masters with new application attack signatures. The scanning is very widespread and can be observed on a regular basis across platforms and ISP types.

The soapCaller.bs page is a file often associated with Drupal content management system. There have been a number of vulnerabilities identified in this package in the past, including during our recent content manager testing project. Users of Drupal should be vigilant in patching the systems and in performing application assessments.

WordPress Exploit

An exploit to hijack the administrator account has been released for WordPress. The exploit takes advantage of some flaws in both MySQL and the web application, and this vulnerability most likely affects other web applications. More information on the MySQL vulnerability can be found here. As such, we have disabled registration temporarily for this site, until WordPress has mitigated the vulnerability. We recommend that you do the same, for WordPress or anyother web application affected by this issue.

CERT Warns of SSH Attacks

Earlier this week US-CERT warned of attacks using stolen SSH keys. After access is gained to the machine, a rootkit (Phalanx2), is installed on the system. Once installed, the rootkit steals other keys from the system and sends them back to the attacker, allowing them to compromise other machines. The rootkit seems to create a directory, existance of the directory /etc/khubd.p2/ indicates a compromise. However, it should not be assumed because it’s not there that the machine is not compromised. It’s believed at least some of these machines were compromised by the Debian SSL Key bug from the summer.

US-CERT has provided some mitigation strategies to ensure that machines do not get compromised by this exploit. First, identify and examine systems where SSH keys are used as part of automated process. Any instance where keys are used without passphrases, a  passphrase should be used to reduce the risk of a compromise. Finally, ensure that internet facing systems are fully patched.

Bank Data Sold On Ebay

A few banks had a wake up surprise when they found that one of their servers had been sold on Ebay. The system was bought for about $150, and was acquired by an IT manager. Upon booting the machine he noticed that there were several cd ISOs on the disk array in the server. In each of these cd images were backups of customer credit card applications. The banks were notified by the buyer, but it is unknown where the machine was between the time it was at the bank and when it showed up on Ebay. I’m sure the banks are scrambling to implement encryption on their backups as we speak.

Trend Micro Auth Bypass

An issue has been discovered some Trend Micro products, which can be exploited by attackers to bypass authentication. Version affected are OfficeScan 7.0, 7.3, and 8.0; Worry-Free Business Security 5.0; and Trend Micro Client/Server/Messaging Suite versions 3.5, and 3.6. Currently there are fixes for OfficeScan 8.0, and Worry-Free Business Security 5.0. It’s expected that patches for other versions will follow shortly.


Web Application Scanning Tools

There have been several publicized releases of web scanning tools this week. Three specific ones come to mind, that enable assessors to automate a large part of the web application/site assessments. With this, there’s a lot of buzz on mailing lists about these tools, so expect an increase in threat to any web facing applications or sites. All of these tools are freely available for download.

Internet Explorer Security Zone Bypass

It’s possible to bypass the security zones within Internet Explorer. An issue has been identified in the way that security policies are applied when a URI is specified in the UNC form: \\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE’. When a URI like this is accessed remotely, Internet Explorer does not apply the correct Security Zone Permissions. This issue affects Internet Explorer 5,6 and 7 under all versions of Windows.
Microsoft has released a work around for this issue. The work around can be found in Microsoft’s techbulletin for this issue. http://www.microsoft.com/technet/security/bulletin/ms08-048.mspx