Are top rated firewalls useless against malware I found on this post...

Here is the link:
http://forum.sysinternals.com/forum_posts.asp?TID=6711

A poster named Crawler says that as seen in the message:
"My computer infected by unknown rootkit.

I have found the strange network activity, big size of the traffic going with my computer. This comes to light only external sniffer. The Personal firewall (Agnitum Outpost) does not find any network activity and opened ports, and can not block the goinging traffic. Use ZoneAlarm 6 has shown similar results. netstat and Tcpview do not show unknown opened ports. Checking the system several antiviruses nothing have not found. RootkitRevealer and F-Secure BlackLight have not been able nothing find.
Please, advise how do I find and dispose of this gunk."


So, ZoneAlarm and Outpost failed to protect him. At scan of the disk on the other computer, antivirus has found file c:\windows\system32\lzx32.sys Trojan.Bot-Mailer After its deleting, problem solved (supposedly).

Any opinions/comments?

It's really weird that ZoneAlarm and Outpost couldn't protect Crawler from Trojan or rootkit connecting to the internet

That reminds me one thing:NONE IS SAFE THESE DAYS!!!!

 

The rootkit we are talking about is using techniques to bypass firewalls. From symantec website, about the rootkit in question (Backdoor.Rustock.B):
"Alters the correct functioning of the following system modules used for network communications to bypass firewalls and to perform network packet manipulations:
tcpip.sys
wanarp.sys
ndis.sys"

NDIS.sys is the lowest component in TCP/IP stack, so it is very hard for a firewall to protect the user in the case of ndis manipulation.

 

From the Symantec site,

I would be more interested in how this rootkit (executable file) became installed in the first place, and then ask myself, "Could those circumstances happen to me?"

My conclusion would be to use the poster's situation as an opportunity to re-examine my own security to insure that preventative measures are in place which would allow me to say, "I am safe these days!"


----
rich

 

Yes,but I'm quite surprised that ZA's OS Firewall who acts like HIPS and component control didn't detect that?

Maybe this guy turned ZA's OSFirewall off, or perhaps he wa susing the free version of ZoneAlarm 6

 

Perhaps all this leak proof firewall stuff is BS.

 

Are these or can they be protected from modification/manipulation in Comodo V3 via Defense +?

 

I guess there are two schools of thought...:

• Leaktest results are germane since they provide - in a somewhat obscure fashion - an indication of the robustness of a firewall against specific types of compromise
• By the time a firewall can react to the challenge of a leaktest type of incursion in a real scenario, the system is already compromised and it's "game over".

There is merit to both schools.

Blue

 

Do you think biased personal opinion is any better ? No, it cannot be better. No one individual can meet in real life all the spectre of all the possible malwares to check his security software against it. He can only experience some few episodes. Leakproof is an attempt to consolidate information. It is not perfect, of course, as anything people do But .. in any case, in case firewall performes bad against leaktests, there is a great risk it will not be any better against the real malware. From the other side, excellent leaktest performance doesn't guarantee the same perfect result against the real malware, though, many of the leaktests were taken from the _real malware_.

 

I completely agree with these statements.

 

One of the problem with gauging protection based on leaktests is that each tests one method for bypassing a firewall. They're very specific in what they do. Malware uses many more methods than those covered by leaktests. Because of all the hype surrounding leaktest results, vendors have made passing these misused tests a priority, whether it adds anything to the relative security provided by their products or not.

I've stayed with Kerio 2.1.5 which isn't known as a leaktest passer. I also use SSM, which can be used to defeat all the leaktests. About half of the leaktests will run on my 98 box. I can make my system pass or fail all the leaktests that will run on my box just by modifying the firewall rules, with SSM disabled. The point? How well a firewall is configured is equally or more important that the amount of features it has, or how it does with leaktests. Leaktests weren't intended to compare products. They were intended to find specific weaknesses, not just in a firewall but in its rules.

Using leaktests to evaluate HIPS is another example how they're misused. HIPS stands for Host Intrusion Prevention System. They're designed to prevent infection, not to contain one. Leaktests work on the assumption that the user is already infected, that either the security-ware or the user has already failed. Some HIPS do this suprisingly well, but that wasn't the intent of their design. The HIPS do their job, intercepting the launch of the leaktest or malware, and the user chooses to let it run, because it's a test. If it's a piece of malware like that Rustock rootkit instead of a test, for the average user, that is game over. You're owned.

HIPS will stop most any malware from executing. If the user chooses to allow it (or their rules are so permissive that they allow the launch of an unknown), all bets are off. Some malware can attack HIPS, effectively blinding it. The vendors patch this weakness, the malware writers find another. Sound familiar? It's the same old game we've been thru with Windows and AVs all these years, the game that has no end. Penetrate, patch, repeat, except for one big difference. The user could have said "game over" by choosing deny and never allowing that malware (or test) to run. Finish and tighten those rules up. HIPS are not noisy when the rules are finished. Don't take the easy way out when configuring it (no allow all rules). Set it to say no for you instead of asking, especially for other users. Let the HIPS do the job it was designed to, preventing unwanted code from running in the first place.
Rick

 

Most probably because ZA was installed after the rootkit and not before...

Cheers,
Fax

 

Hello,

If a firewall was meant to stop malware it would have been called malwarewall.

Firewalls are designed to control traffic, not to control Windows. If the underlying platform is compromised - and the user is unable to prevent it for some reason - why should a program running on top of the platform, slaved to the platform, be expected to prevent this from happening?

Mrk

 

I canot agree with this statement. What reasonable rules can you apply to iexplore.exe to pass all the leaks ? Allow only update.microsoft.com ? Even this can fail in case something changes hosts file, for example.

 

Is there any Law of Nature that states this ?

When the word Firewall was used for the first time there was not that lot of malware we face today. The current environment changed initial requirements. Usual thing, many terms get adjusted. And a few care to invent the new words. But it just appeared that to really control network traffic today firewall needs a lot more to control than just to control the ethernet frames. The case described in the initial post of this thread proves that firewall did control nothing ..

 

In SSM's case, you can prevent other processes from launching, manipulating, or otherwise tampering iexplore.exe, thereby ensuring that whatever connections iexplorer.exe tries to initiate are under commands from the user. This is not always foolproof, but I'm just clarifying what I think herbalist meant.

 

No, there aren't any Laws of Nature(tm) that explicitly state this, but that's a very truthful statement nonetheless. Do you define a firewall as a program that controls the OS?

That is not relevent, seeing as how firewalls were never meant to defeat malware in the first place.

Yes, and those firewalls are among the best in the industry when it comes to doing what you seem to be advocating that they should do. Perhaps this is a sign that we need more, better, and stronger of the same... or perhaps it's a sign that we're looking at the wrong way to solve the problem.

 

If something changes the hosts file without your knowlege, you've already got a bigger problem than a failed leaktest.

Several of those leaktests target Internet Explorer. If IE is not the default browser or is only used for windows update, limiting it to connecting to their site is reasonable. Many firewalls have provisions for creating a custom or trusted address group. Allowing IE to connect only to those sites prevents it from being used to covertly connect elsewhere. The tests that exploit IE are realistic in the fact that IE is the most often targeted and exploited app in use.

Many firewalls also have a global "deny unknown" setting, which blocks without prompting everything not expressly permitted by rule. A user could also run this setting, not make any rules for IE, and update manually by changing the global setting and using an "allow once" option for IE. If you don't normally use IE, it makes perfect sense to block it. On my primary box, IE6 is only allowed to connect to Proxomitron using a non-standard port. On this text box, IE has been removed entirely.
Rick

 

I was referring more to actual firewalls, but HIPS when properly configured will defeat most of the methods malware would use to exploit IE. Then again, if the user doesn't let that malware run in the first place, it can't do anything with IE or any other app. This does become more of a problem when the malicious code is embedded in a file whose default handler is a permitted process and that app is an allowed parent or child of IE or is a legitimate BHO. PDFs launched in your browser are one such example as Adobe Acrobat is a legitimate BHO. Neither a firewall or HIPS will prevent malicious code embedded in a PDF that's launched in the browser from affecting that browser. If that same PDF is downloaded and opened independently in its default app (Adobe Acrobat in this instance) instead of in the browser, then HIPS can prevent the vulnerability in Adobe from being used to gain access to IE.

The problem isn't just the vulnerabilities in the different apps or the formats they handle. In Windows, it's their interconnection that makes everything so vulnerable. HIPS that can control the parent-child relationships between these apps go a long way in preventing a given vulnerability from becoming a system takeover. The code exploits the PDF reader but goes no farther. In this example, system configuration is equally important. In the end, it comes down to a tradeoff, not of functionality but of convenience. The launching of apps in your browser to handle different types of media and file types makes your browser targetable by any vulnerabilities that are found in those other apps. Once that happens, it's only a matter of what the code wants to target. If it's opened in the browser, it's a safe bet that IE will be the target. Now we're back to penetrate and patch again, with security apps not in a position to fix the problem.
Rick

 

Hello,
For your info, firewalls also exist in other operating system, no just Windows, where there is no malware - and they do their job. You make sure you don't get infected and the firewall will keep filtering traffic for you.
Mrk

 

Yes you could add those files to the file protection component. But this still keeps the problem of deciding which legitmate aps are allowed to change it. Next step would be to prevent tampering with those allowed applications.

Another problem would be the boot loading sequence of your security ap in regard to the malware. Therefore file protection contained in the OS is usally better than 'added' security aps.

When you use Comodo 3 with D+ on Vista, for fun allow Defender to be run also. You can see Defender popping up earlier than other aps in the sys tray. So with a boot loader analysis tool you should have to be damned sure it starts early enough. Same applies to the new leaktest now targetting OS shutoff. When they are being shut off later than your security application, your 'protected' OS files are a green field for this malware.

With more mature aps where most explotation holes are found (and fixed) during normal operation, you will see a tendancy of malware to sneak passed it at shut down and boot up. Dealing with this type of malware is easier for OS-ses with well designed architecture. This because the borders and possible entry points are easier to protect in a well structured OS than a more loosely organised OS (this is one of the main reasons Vista is better than XP for instance).

That is why OS integrated protection is best (running as limited user), next are the HIPS/FW integrated aps in my opinion.

 

I had a very similar problem a few days ago and found it looking in my Injoy Firewall logs.
I tried to find the source of the problem with Bitdefender Antivrus installed, Dr. Cureit, Kaspersky on-line scanner, Ewido on-line scanner, F-secure on-line scanner, Webroot spyweeper, MS-Defender, maybe others with NO results.
In the End I had been forced to reformat the system.

Injoy Firewall DID blocked the activity but the source never had been found.

Maybe a good stand alone anti-rootkit to suggest?


Regards
joter

 

Ok, a quick update on what I said first. By manipulation of NDIS I meant creating a NDIS hook driver, or even a protocol driver which allows sending and receiving data at the lowest possible level. This is a known technique used by rootkits. But none of the leaktest from Matousec, for instance tests a firewall's capability of stopping this kind of activity. So even if a firewall passes all leaktests, that doesn't mean that the computer is 100% secure. It only means that the firewall provides security for those specific leak methods.

@joter: The source was not found probably because it originated from a malicious kernel driver, and those drivers do not have an associated process ID, so the firewall can't exactly say who sent the data. As for an anti-rootkit, some of them look for hidden data in the filesystem or registry, but keep in mind that there are rootkits who do not attempt to hide, and the tools will not be aware of these rootkits - sonuns weird, but it is normal . If you suspect there is something wrong with your computer, it would be beter to boot in safe mode and to scan it, and even look for suspicious drivers by hand.

 

Bottom line is simple: It just goes to show you, NO, you can't rely on any software firewall to protect you from all possibilities of outbound communication...

 

In my view the anti leak features of firewalls are an indication of a firewalls ability to limit outbound communication to authorized applications started in an authorized manner. If your firewall tells you worm.exe wants to connect to the internet then it it telling you your system is compromised, hopefully before you have given up the password to a bank account. That's it, nothing more or less. Your firewall could pass every leak test and still that gives no indication of how well it would stand up to inbound attacks. Matousec does make the incredible statement that nearly all handle the inbound side well.


HIPS are a completely different sort of beast. I agree with those who feel leak testing HIPS is irrelevant. HIPS are designed to prevent infection through hardening the operating system. Of course, running in a LUA also hardens the operating system as does Vista's UAC and memory architecture features.

 

Firewalls will and always have centered around controlling network traffic.
They are not for controlling your computer configuration, files etc.
E.g. Block traffic from IP 1.2.3.0 inbound Port 80

So its useful to remember this these days when leaktests and HIPS softwares become intermixed together.