Actually, it was mouse1 who brought it to my attention. He also made a report about it here last November.
Does activating the HIPS protect against leaks if the BB is set to FV?
I missed this first time round
On both my systems W7 and W8 with BB set FV the test is blocked by the HIPS
I’m now running with BB set to FV with HIPS enabled and feel pretty secure with minimal impact to functionality
Like i mentioned earlier i downloaded the test and attempted to run it and the HIPS blocked it which is good.
Ive changed the BB setting to untrusted and feel secure enough with this and the hips turned on.
I’m reluctant to use restricted/untrusted because previously some programs wouldn’t function.
I figure with FV and HIPS set to create rules I get usability plus the granular control of HIPS so I get good usability but also control over what does what within the sandbox.
What is worrying is the fact that as this leak test showed some FW popups don’t work when the BB is set to FV, I also saw this happen when the BB was set to limited, if the FW fails here where else is it failing ?
I can consistently get the FW popup with the leak test passing right through it when the BB is set to FV however I only saw this the first time I ran this test against limited, As Chiron stated probably something to do with FW rules been created
While I’m certainly not trying to downrate the problem, I think we have to realize that a real piece of malware would not behave like this tester does. It would simply transmit the data and would not open a web page that showed what it collected. Therefore the Firewall alert for the browser would never happen no matter what your settings are. It should happen for the malware file itself but if the BB is set to restricted or untrusted,(without HIPS being enabled) it looks like you might be okay.
I believe what this test is supposed to illustrate is that malware can trick the firewall component into allowing it to transmit data through the browser (which could include your password, etc…). Thus, for those using the Kiosk, if a keylogger manages to install itself, and then they do banking, this could become a very serious problem for them.
agree 100%
key logging has always been an Achilles heel
It will be interesting to see how CIS deals with this using a BB approach, considering the recent moving away from HIPS and aiming at a larger base of non geeky default settings user.
right! it is a serious problem! u already got some infos from egemen about that?
In my opinion keylogging is not too large a problem as long as the firewall is able to stop it. However, the issue I have with this leaktest is that it shows that the firewall is not able to stop leakage. Therefore, if they fixed the firewall leak I wouldn’t be too worried, even though some keylogging methods are successful, as at least the data can’t be transmitted from my computer.
No, egemen has not responded yet.
How legitimate is this test file.?..
Is the firewall faulty in general or just in the virtual environment.?
To be honest isnt that what generally constitutes a true virtual environment?..Nothing can get in even the security program.?
Even if that is the case this is still a vulnerability. Something, regardless of what it is, needs to be able to stop malware from sending anything it is able to log back to its creators. For reference, please see the topic here, which shows that it’s possible for an application sitting in the FV environment to log keystrokes from the actual computer.
Coupled with this vulnerability, which allows data to be leaked past the Firewall component, I believe this definitely warrants our concern.
I just ran the AKLT keylogging test in the Comodo sandbox and it did record every keypress from outside the sandbox. Running it outside the sandbox and with the BB set to restricted, it captures nothing. With the BB set to Fully Virtualized, it once again captures every keypress. It’s almost like CIS is treating things in the sandbox as if they were trusted. This is troubling.
[attachment deleted by admin]