I just read this little gem over at the CFW Beta forum

Hi Guy's:

I just read this little gem over at the CFW Beta forum.

http://forums.comodo.com/leak_testi...ect_anyone_it_is_easy_to_bypass-t12265.0.html

Does this post there ring true?

If it does, would any FW we discuss here in this forum survive such an attack?

 

Hi Escalader

No FW gives a total protection against leaks and a layered protection is always a better way to keep a computer safe...

There's also many other FW bypass explained there:

Punching holes into firewalls

or
"Why firewalls shouldn't be considered a ultimate weapon for network security"
or
"Secure TCP-into-HTTP tunnelling guide"

All leak tests are interesting because they shows how much a FW gives an internal protection sometimes as much as a HIPS ...

But in a real life nobodies have to put all his eggs ins the same basket and rely in only one security program ...

 

Hello,

That post feels incorrect.

I have tried the mentioned thing using VMware Server and Sygate firewall.
When set to block, there was no traffic on the machine. As simple as that.

Maybe the poster forgot to monitor the virtual adapters. That's an easy omission.

Plus, virtual machines have no access to "all" of the HDD unless allowed to access certain shares.

Mrk

 

Hi Mrk:

Thanks, that post caused a fuss at CFW forum.

 

Hi Climenole:

Agreed again!

On your egg's in 1 pot analogy the only way we would do that is when we want scrambled!

I'm sending you a PM so as to avoid an OT post!

See ya

 

I remember back when the CHX-I people were asked to monitor outbound applications, they always replied that it was futile in the long run since anything that can install a driver can bypass the outbound protection. I believe this is correct, but do not know too much (nor care really since I believe that you should only run applications you trust, and if malware is on the pc it is too late anyways, but that's just personal opinion) in regard to the driver bypass. However, if you run a limited user account, you wouldn't have to worry about the driver issue, so the problem is solved.

Cheers,

Alphalutra1

 

Any HIPS can probably flag a driver install too, so I think I'd rather rely on that than any software firewall....

 

Its not just driver bypass. A recent thread around here showed how malware can disable various HIPS programs bu unhooking them from the OS.

Meanwhile, the answer on the Comodo forums, to monitor protocols other than NDIS, is a setting on Comodo 2.x that is not enabled by default, and its an obscure one at that.

 

Yes, we need layers for sure not all one vendor so if one tool is disabled by the bad guy's who aren't dumb we still have the other layers.

On the obscure Comodo workaround users had better enable it obscure or not.

Be interested in Stem's take on this one

 

With respect to you and all other members.

Allow the install of software at your own peril.

I have seen too often where a user has allowed full installation of a program (bypassed an installed HIPS (either by disabling/learning mode/or clicking "allow" to all) and then come back and complained of being compromised.

You should be aware, that simply having an HIPS, or a firewall with this "leak prevention" will NOT protect when (possibly malware) software is simply allowed to install that can directly attack installed security software (or attack via other windows process).

 

Stem:
Right, not to worry about my reaction I asked for your "take" and you provided it.

But I don't think it's quite that simple (excuse the words pls). Are you indirectly agreeing with this "gem" post and saying ALL FW's, HIPS ignore drivers? I'm not trying to put words out for you just trying for detail and clarity in my own mind.

Speaking only for myself this "gem" post at CFW forum said CFW was flawed because it ignored drivers. I'd like to think members here wouldn't turn off their own tools and would be carefull selecting software. Maybe I'm naive!

Anyway here is the post I read that I called a "gem"

"WARNING: Any program can easily receive and send data to anyone on the internet and this firewall will not warn you and will not stop it.

All you get with this firewall is a false sense of security.

Want to see a prove?

1) Download and install Microsoft Virtual PC 2007.

2) Set your firewall to block all traffic.

3) Run Virtual PC, install a guest OS in it and boot it (see the Virtual PC help for info on how to do it).

Now, even though your firewall is telling you it is blocking ALL traffic, you can browse any website from the guest OS and send data to anyone on the internet. The firewall will not warn you and will not stop it.

The cause is that this firewall watches only user-space applications, not drivers. BUT, any malevolent program (e.g. a Trojan) can easily launch a driver on your Windows XP anytime!

The bottom line is, with this firewall, all you get is a false sense of security (and a much slower system). The authors of malware are laughing at you right now.... "

 

I completely agree. When malicious code is allowed to run, all bets are off. No security app or combination of security apps is %100 effective when you let the code run.

NicM has tests where malware disables or unhooks HIPS programs. In these tests, the HIPS intercepted the initial startup of the malware. The malware worked because it was allowed to run. HIPS are not damage control programs. They're Host Intrusion Prevention Systems. HIPS is that big, reinforced, locked door that stands between you and unknown intruders. If you open that door and get robbed or killed, it's not the doors fault. It's yours because you opened it. Tests like NicMs are good for showing where HIPS and firewalls can be improved, but users are missing the obvious warning.

This is Windows we're dealing with here, the operating system that's been designed over the years to allow everything to do anything it wants for the sake of user convenience and ease of use. It's the most insecure idea they could have devised, one that they're only now starting to change. Security apps like firewalls and HIPS try to enforce policies that are the exact opposite of those the operating system is based on, without knowing the code for the operating system. It's small wonder they're not %100 effective, especially when users allow malicious code to run, defeating the purpose of the security app, then claim it failed. It's the same as trying to walk right on the edge of a cliff without ever slipping. Good adventure but not very secure behavior, especially when that ground you're trusting is Windows, complete with hidden cracks and holes. Expect it to fail when you try to play at the edge.
Rick

 

No, the well known HIPS will warn of driver installation (along with autostart entries etc etc).

I have personaly only installed M$ VM once (I prefer virtualbox), that was, at the time, when I had jetico1 installed, and this did intercept the outbound from the M$ VM.
When using a VM, you should setup as NAT, or setup a Virtual NIC and use a proxy server. But, saying that, even if set up, as with ICS (direct link), then I have only seen one firewall bypassed (out of about 6 I have setup like this)

 

Thank Stem:

Of those 6 FW's and the 1 that was bypassed, was that 1 CFW V2 or V3?
Excuse poor wording!

 

I am not quite sure which firewall it was now (I did make a post on this), but it was not Comodo, I have not looked at this firewall with ICS (or with use with VM).

 

Rick:

Thanks again, I like your edge of cliff analogy!

In what sense is M$ changing? Do you mean Vista?

 

IMO, Vista is the first OS they've released that doesn't allow everything to access everything else. That said, I disagree with the methods they're using and with their decision to limit security-ware's access to the system kernel without actually securing it from malicious code. Once the malware writers work out how to crack it, Vista will prove to be very hard if not impossible to clean, thanks to the lack of kernel access. I'm not looking forward to the prospect of digging a rootkit out of Vista.

Operating systems based on a default-permit policy are only part of the problem. Users have adopted the same mentality and are expecting security-ware to conform to that mentality. HIPS programs are designed to function on the default-deny principle. Applications and their activities are whitelisted. Any process not expressly permitted is blocked. That is their strength. When used in this manner, HIPS are extremely effective. Other than testers and malware researchers, how many of you would instruct your AV to allow a file/process it flagged as infected to run? How many of you routinely ignore your AV when it flags a file, e-mail or webpage, then blame the AV for not protecting your PC? It's not expected of an AV. Why should it be for HIPS? No security program will ever be able to detect and block every possible malicious activity or command. It will never happen. If it were possible to anticipate and prevent all the ways malicious code can compromise a PC, XP would be completely patched by now.

Firewalls work on the same default-deny principle. A good firewall allows only what you instruct it to and either prompts the user or blocks everything else outright. Yet, too often users resort to "permit all" types of rules that defeat the whole purpose of having a firewall.

The vendors for security apps already have to deal with malware writers that seem to have almost unlimited ingenuity in finding ways to attack a system. They're trying to secure a system that is horribly insecure by design. We want their apps to detect and block all possible malicious activity, yet accomodate other security apps that use almost the same methods and commands as the malicious code. On top of that, we want them to protect us from our bad decisions and to protect our systems when we do the exact opposite of what we need to, allowing unknown code to run. I'm suprised the malware writers are putting effort into defeating HIPS applications when the user so often does that for them.

Rick

 

Hi GUy's:

The thread over at CFW forum just brought a reply from CEO! Have a look at posts 14,15,16, 17 if you are curious.

http://forums.comodo.com/leak_testi...ct_anyone_it_is_easy_to_bypass-t12265.15.html

Seems the tester poster did find a default flaw in 2.4 and as V3 is in beta maybe they can improve. IMHO of course.

 

I'm not sure what to make of all this. When a Vmware or Virtual PC are installed these programs install communications drivers that show up in the network connections window as additional network adapters. I don't know how any firewall is supposed to be able to do application aware monitoring of the traffic on these adapters.

The question is how do you know a good adapter/driver from a bad one.

Someone above said Vista is the first OS that does not allow full access to everything. He seems to be forgetting that XP and W2K could be run in user mode so that large parts of the OS are not accessible. The problem is the user does not know how to respond appropriately to UAC prompts.

 

Hello,
If your firewall sees these adapters, it can control them.
As simple as that.
Mrk

 

The only thing their user accounts in XP did was make it difficult for a user to get anything done. Malware had no problem escalating privelege or waiting until a user needed to in order to get an app to work properly.

Back on the original subject, defeating a firewall with virtual PC. I haven't used Virtual PC, but it seems to me that Virtual PC is an application. A firewall installed on the host system may be able to control VPCs ability to access the net as a whole, but should not be able to control apps installed on that virtual OS. If a firewall on the host system is aware of individual apps on the virtual system, the 2 are not isolated from each other and malicious code could potentially use that same data path to escape the virtual system and affect the underlying host system.
Rick

 

Yep, it pretty much always boils down to the user doesn't it....

 

Hi Stem,

As I pointed over the Comodo forum

ICS will not bypass Comodo settings.

ps. Guys do not confuse this thing with other virtual machines. VMware for example does not inject a driver in the network settings. Creates new network cards which CFW can see them and intercept any configuration you choose.

hope it helps,
Panagiotis

 

Hello pandlouk,

I would of agreed with this, without a need to setup, but, you would need to agree that your "point 3" does contradict that statement

With ICS, the client PC is "seperate" with its own (different) IP and has direct access to the (WAN (or outer LAN)) network card.

As with Jetico1, this firewall will directly block ICS, due to no binding of application to outbound packet, the SPI within Jetico1 needs to be disabled to allow such traffic.

The only actual problem I would of thought of (before this thread), was the fact that due to the seperate default "Network rules" that ICS would be allowed out without interception. But, saying that, I would of expected the firewall to block this when a "Block all" is set.
As from a "Block all" this should in fact "Block all" outbound/inbound from the main NIC interface, regardless of where the packet originates.

 

OK, so not to guess or just think of this, I have installed Comodo (2.4), I have setup my VM (virtualbox) on HOST interface, my main NIC set for sharing (ICS).

Comodo intercepts and blocks the comms from the guest as unsolicited inbound from the IP of my VM. This I would see as correct. Placing a Network rule to allow TCP/UDP inbound from the VM IP then allows the VM to connect out,.... such as IGMP/ICMP/nbdgram are still blocked correctly.

"Block all" is blocking the VM.(Vbox)