Kiosk Vulnerable to Simple Simple LeakTest

Okay, to me this appears to be a vulnerability of the Kiosk through which keyloggers could potentially transmit the data they have logged. As keylogging, or screencaptures are possible in the Kiosk (at least some methods are possible) I believe this to be a significant vulnerability.

I think the easiest way to test this is to open your browser sandboxed (I tested with Comodo Dragon). Then navigate to this page and download the leaktest. Then open it inside the program and run it. At least on my system it is able to display information through the browser, meaning that there is a leak.

The interesting thing is this. When I tested this on my system with the BB set to Untrusted it couldn’t start. That made sense. However, under Partially Limited to Restricted what happened was I got a popup from the Firewall asking if I wanted to allow Dragon access to the internet. I don’t get that unless it was opened by the leaktest (which by the way is how I believe the leaktest sneaks the data out). The strange thing is that although I didn’t change the Firewall level between testing different levels of the BB it was actually the firewall component which appeared to stop the leaktest.

Thus, I worry that perhaps the Firewall component is not yet working correctly with the fully virtualized sandbox. Can anyone confirm this?

Thanks.

Windows 8 x64
fully virtual browser (CD)
proactive config - HIPS off

Browser leaked data…

Edit: FW set to custom with alerts set to high

On your computer, if you run this outside the Kiosk is the firewall component able to block the leak?

When run outside of the kiosk/full virtual browser the test is sandboxed but leak still occurs
This is with FW set to custom and alerts set to very high

Is the option for the firewall to “Do NOT show popup alerts” disabled? Also, are you running in either Partially Limited, Limited, or Restricted?

I have popups allowed
I had been running as fully virtual
I have just ran the test in Partially Limited and Limited
The FW popup is for explorer.exe to connect to the net the weird thing is the “leak” page loads whether I answer the popup or not.

Testing the BB set to Fully Virtualized is the same as testing the Virtualized Browser or the Kiosk. They all share the same environment.

So do you mean that when you run as Partially Limited you at least get a Firewall alert which, if you choose block, does not allow the leaktest to connect to the internet? Is that correct?

Testing the BB set to Fully Virtualized is the same as testing the Virtualized Browser or the Kiosk. They all share the same environment.

I understand this, I was giving confirmation

So do you mean that when you run as Partially Limited you at least get a Firewall alert which, if you choose block, does not allow the leaktest to connect to the internet? Is that correct?

No I was getting an alert but the test was connecting even if I didn’t answer
However I am trying to reproduce this
Right now I get no FW alert only auto sandbox
I will reset all FW rules and try again

I’m confused now…
I have an instance of CD open running virtual
when I run the leak test now it’s auto sandboxed but the “leak” page opens in another non-virtual instance of CD
No FW alerts at all now
If someone else can try this and see if they can replicate what I saw with the FW pop ups and page loading regardless that would be helpful…

Ok when run with BB set to full virtual the leaktest is sandboxed and the FW alerts to the connection request
The leaktest connects to the internet and loads leak results before ANY interaction with FW pop up

I can consistently reproduce this

[attachment deleted by admin]

for me it seems like a bug, it should not send data before u allow it.

I downloaded and tried to run but the HIPS stop it.

Try it with the HIPS disabled.

I did a quick test, with just firewall and BB. Any setting other than partially limited prevented the leak program from finding the browser. I don’t use Silverlight, so I haven’t looked at the other areas.

I just tested it with a non-sandboxed IE9 on all the different BB settings. Here are the results.

Partially Limited---- Firewall alert for iexplore.exe
Limited----------------Same as above
Restricted-------------says “Unable to find default browser” and therefore does not run
Untrusted--------------Will not run at all
Fully Virtualized-------Runs and leaks info with no alerts of any kind

I think I may change my BB setting back to restricted. It is currently on Fully Virtualized.

Okay, the plot thickens. I reinstalled CIS (as I was getting inconsistent results but couldn’t find an issue). Then only changes I made from default were that I enabled FV for the BB. I also unchecked the Firewall option to “Do NOT show popup alerts”. Other than that everything was default.

My default browser was Dragon, and I couldn’t seem to get the program to test any others, even if I made IE the default browser it would load in Dragon. Thus, I’ve only tested Dragon.

However, this time I found that everything from Partially Limited to Restricted blocked the leaktest via a Firewall alert. However, FV let it right through. Thus, my test at least shows that the only option which needs to be addressed is FV.

This vulnerability makes me now want to encourage people to do baking outside of the Kiosk, as it appears to be less vulnerable to keyloggers. Hopefully Comodo addresses this vulnerability in the next update. I’ve already sent a PM to egemen about this. Hopefully he responds and lets us know exactly what’s going on.

Thanks.

As you said there appears to be a problem with the Firewall in the virtual environment. It could be serious and they need to track it down ASAP. I do think however, that it would take a keylogger being present in the virtual space in order for it to transmit data. If the keylogger is only present outside the Kiosk, it shouldn’t be able to do anything. I therefore think that the main problem exists within the fully virtualized setting for the BB which I can no longer justify using. I’m back to restricted.

Tell me if this is wrong. You’re browsing in the Kiosk and a keylogger tries to install itself. The Behavior Blocker set to restricted prevents it from functioning but a BB set to fully virtualized allows it through. Is this a valid scenario?

I have also re-installed as they only consistent result was the leak phoning home through fully virtual
if internet access is denied the test opens up a new browser page (only dragon) but no data is sent but it passes thru the FW as if its not there.
I don’t have silverlight installed.
On a clean install with default settings…
with partially imited and limited the results are same as fully virtual.
untrusted blocks it - only autosandbox no FW popups - Unable to find default browser
restricted blocks it - only autosandbox no FW popups
I have tried to replicate the autosandbox and FW popup seen in limited but cannot, very frustrating now the test escapes the sandbox but no FW alert.
hope someone can sort this till then i figure untrusted is the way forward

I believe that in Fully Virtualized most keylogging methods are automatically blocked. However, not all are and screen grabbing is allowed for many methods. Is this this correct?

Anyway, yes, I believe that in order for this to be a vulnerability the keylogger itself would have to be running as fully virtualized as well. However, as long as you set the BB to FV this would be the case. Thus, I believe that it’s a severe problem for people who are running with the BB set to FV, or those trying to use the Kiosk for secure browsing, such as banking.

This inconsistency may be due to the Firewall automatically creating rules. I’m not sure, but I do also know that the results may be different depending on whether the browser was already open.

Hopefully egemen will look at this and let us know what’s going on.

Hopefully egemen will look at this and let us know what's going on.

Hopefully
thanks for bringing this to our attention :-TU

After some deliberation I have decided to stick with the BB set to FV but have also reactivated HIPS
No matter how you look at it HIPS takes some beating…