Welcome to the MSI Podcast Studio! In this edition, we interview Gary Moser, MicroSolved’s Project Manager. We chat about the current threats and trends facing businesses today, and what a business can do to protect itself.
So, the worm based on MS08-067 was rumored last week and now SANS confirms that the worm is spreading from at least one host. SANS is blaming 61.218.147.66. We also have seen scans from 208.23.24.52, 66.100.224.113, 97.89.26.99, 219.158.0.96, 88.178.18.41, 91.142.209.26, 189.20.48.210, 212.122.95.217, 131.118.74.244, 84.3.125.99, 81.57.69.99 and a ton more. Those started to increase dramatically starting this morning around 9:25 am Eastern and have continued throughout the day.
HoneyPoints on consumer bandwidth networks and commercial ISP’s alike are picking up a spike in 445 scans and traffic.
Obviously, given the metasploit framework’s improvement of the exploit in the last week or so and the myriad of proof of concept tools that have been filtering around the underground, the threat of a worm is a reality. Worm code was first announced several days ago, but seemed to fail to propagate likely due to the lack of port 445 being available on most Internet connections. However, it appears that some victims have been found and have been slowly accumulating.
While we are not yet seeing the massive scans and probes associated with the worms of the past, we are beginning to see traffic levels that indicate increasing worm behaviors.
Obviously, if you have not yet ensured that port 445 is blocked at your Internet connection, you should immediately do so. HoneyPoint users can also setup TCP listeners or basic TCP HornetPoints to discover and attempt to “defensive fuzz” the worm code. Mixed results of causing termination have been shown so far, but our lab is working on a HornetPoint configuration to cause exceptions in the worm code in a stable manner.
HoneyPoint TCP listeners can be deployed on Linux boxes and other platforms where port 445 is undialated and used to identify hosts performing 445 scans and probes. This is an excellent approach to finding laptops and portable devices that might be infected on the internal network.
Officially, the flu season begins on the first of October and runs until spring. Even though the CDC says that this year’s flu is starting out a little bit milder than the two previous years, I know several people that are suffering through a nasty type of flu already this year. This stuff starts out with the usual fever and aches, and then turns into “cold” symptoms that hang on for weeks! We all know how nasty this is on a personal level, but a virulent long lasting flu like this can also really stress your business as well. So, let’s take a look at how the flu really works and what we can do about it.
First off, there are few real defenses against the flu if you are going to interact with other people. “Flu’s” are viruses that can infect you in several different ways and that mutate often and rapidly. The flu vaccine that is produced every year is really only devised to have some effect on the top three dominant flu strains of the year. The amount of effect they really have also depends on just how and how much each virus strain has mutated by the time you get the flu shot. So, although it is liable to help, don’t put too much faith in the flu vaccine.
So how can flu infect you? The most insidious way for the flu virus to spread is through the air in the form of “droplets”. When persons with the flu cough or sneeze into the air, large and very small droplets of liquid filled with virus travel through the air and can easily make their way into lungs or onto hands. Large droplets generally do not travel more than six feet but small “micro-droplets” can float through the air for some time and travel greater distances. Flu virus can also enter your body through your digestive system or eyes. If there is flu virus on your hands or food and you put them in your mouth, you can get the flu. If you have flu virus on your hands and you rub your eyes or nose, you can get the flu. So, what can you do to protect yourself from getting the flu or giving it to others?
The best thing you can do, even though it is a pain, is wash your hands. I mean wash your hands each time before you touch anything and put it in your mouth, or before you rub your eyes. Also, I wouldn’t eat food that has been sitting uncovered around where people have been coughing or sneezing.
There are also a number of different things that can kill microorganisms like flu viruses. Ultra violet radiation, such as direct sunlight, kills microorganisms almost instantly. Also, Microorganisms die quickly when they come in contact with hard, smooth, dry surfaces. And, microorganisms can be killed or removed by the use of soaps and other chemical cleaners such as hand sanitizing lotions or disinfectant sprays.
So how do you protect your business from the flu? When the flu is rampant in the community, protect yourself when you are in close public areas such as grocery stores, automobiles, airplanes or malls. Have your workers do any work remotely that they can. If they can VPN into the network securely and work from home, have them do so. If you are a financial institution, consider closing or restricting access to the lobby and doing as much business as possible via the drive up windows. Insist that employees that have the flu stay home. And finally, make sure that your business has good written operating procedures in place, and that your employees cross train with each other on a regular basis. This will be a real help in times of great absenteeism. Expect the best, but plan for the worst – the height of the flu season is just two or three months away!
A worm has been spotted in the wild that is exploiting the MS08-067 vulnerability for which Microsoft released an out-of-band update for yesterday. We urge you to update as soon as possible as there is now working code in the wild. All servers should be patched, especially external ones. If for some reason you have RPC exposed to the world, a very close look should be given to those systems as they may have already been compromised. Internal systems should be patched as soon as possible since this is now a worm, a worm that could be brought in through laptops or other means of access.
A little info on the worm itself, it has been dubbed Gimmiv.A. When the worm executes it will drop three files, winbase.dll, basesvc.dll and syicon.dll into the %System%\Wbem\basesvc.dll. It will then install a service named BaseSvc which will then force svchost.exe to load the trojan dlls. The trojan will collect data from the machine, including passwords, and send them to a remote machine.
Today Microsoft is rolling out an unscheduled update. This vulnerability is critical and there are reports that it has been exploited by malware for the last few weeks. The most vulnerable systems are Windows 2000, Windows XP and Windows 2003. On these systems it is possible exploit the system without authentication. On Windows Vista and Windows Server 2008, the exploit requires authentiation to run, it would likely also lead to a Denial of Service condition due to the use of DEP and ASLR in these versions of Windows.
This is the first vulnerability that can be easily wormable in the past few years. It is very important that this update be tested and rolled out by your organization as soon as possible to prevent exploitation. The Security Bulletin can be found here.
Microsoft patches now include a new exploitability index. This new rating attempts to quantify when/if an exploit is likely to become available for a given vulnerability. The rating also attempts to take into consideration how stable a given exploit is likely to be.
Personally, I think this is a good idea, especially if they keep their methods for rating issues consistent and transparent. Already, a number of vendors have said that they will be adding support for the new index value in their tools and software. As might be expected, reaction has been mixed from the community, though, I have yet to see any response that included how such information could be truly harmful.
You can read Microsoft’s published information here.
I hope more vendors embrace this seemingly small detail. I think it is helpful for more than a few organizations overwhelmed by patch cycles. It may not be the “holy grail of patch risk”, but it is likely better than what we have now.
How does your organization plan to use this new information, if at all? Drop us a comment and let us know!
I’d like to go over some of the tools that we mention on the blog. The first one I’d like to take a look at is OSSEC. You may have heard of us talking about it before, we mentioned it a few days ago. That was in relation to HoneyPoints and using OSSEC as another layer of your “defense in depth” strategy. I’ll explain what it does, and how it can help you.
First of all, what is OSSEC? OSSEC is an acronym for “Open Source Host-based Intrusion Detection System”. From the name you can see it’s a Host-based Intrusion Detection System (HIDS). As a HIDS it has the capability to do log analysis, integrity checking, Windows registry monitoring (and event log), rootkit detection, real-time alerting and active response against malicious hosts. It can be run locally, or as a centralized system with agents running on hosts.
So how does OSSEC relate to HoneyPoint? Well they both watch different things, and complement each other. While HoneyPoints are psuedo services and capture traffic from them, OSSEC watches real services for probes and compromises. It does this largely by a system of log analysis. I won’t go into it deeply, but the log analysis rules are very configurable, chainable, and fairly easy to write for anyone that knows regex and has a familiarity of basic scripting language.
With OSSEC’s active monitoring, it’s possible for the host to dynamically write firewall rules to block that host. Similar to HoneyPoints Plugin interface, with which you could also use to write a plugin to do that. You could even use OSSEC to watch your HoneyPoint Console syslogs and integrate HoneyPoint Console triggers with its own active response rules, to centralize blocking of hosts between HPSS and OSSEC.
As you can see, OSSEC can work quite nicely with HoneyPoint Security Server as part of a “defense in depth” strategy. There’s no single tool to “rule them all”, so to speak, so it’s important to watch from multiple perspectives! If you want to check out OSSEC, you can visit www.ossec.net.
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…
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…
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.