CIS v4 - Not Bulletproof

As a test, I downloaded and ran a rogue to see just how effective CIS v4 really was. Everything was set to default.

Upon execution, I was greeted with two D+ alerts, and I chose Block for both. A sandbox alert then popped up saying the rogue was placed in a sandbox, for which I clicked OK. The rogue was running in front of me, but the sandbox led me to believe that my system was safe. But I was wrong.

I used Comodo to end the rogue’s process, and while everything seemed fine, I wasn’t convinced. To see if it touched the startup settings, I went to run an msconfig. Didn’t work. I tried running another exe. It said it couldn’t find a program to run the exe.

I restarted, hoping it would all be fixed on a restart. Nope. Nothing started on startup, and I couldn’t even manually run Comodo. Now I have to reinstall Windows again. Joy. Luckily this is a fairly fresh install.

So, in conclusion: the new version of Comodo is far from bulletproof. Even with me, the user, clicking block on all the popups, the rogue was able to pass right through the sandbox.

Just an update:

Turns out I won’t have to reinstall Windows. I managed to run MalwareBytes by running it as administrator (the only way I could run .exe’s) and it corrected the problem.

According the MalwareBytes, the only thing that was infected was this key:

HKEY_CLASSES_ROOT.exe(default) (Hijacked.exeFile)
(Full data in log: HKEY_CLASSES_ROOT.exe(default) (Hijacked.exeFile) → Bad: (secfile) Good: (exefile) → Quarantined and deleted successfully.)

It was this key change that made it so I could not run any programs at all. My PC is fine now, but I have to question… Why was that key change not protected by Comodo? It was the only thing that got through the sandbox/D+, yet it managed to do a lot of damage (luckily, not permanent damage).

Maybe a dev can explain to me how a sandboxed application was able to alter my registry and mess up my system.

Wellcome to the comodo bug party:
https://forums.comodo.com/feedbackcommentsannouncementsnews-cis/bug-by-design-in-v4-vulnerable-by-default-t52440.0.html

Oh joy. Maybe I shouldn’t have been to quick to install this.

Could you please attach or give link to the rogue you are writing?

Take this and show me how to stop it->

 <url removed by moderator and sent to dchernyakov>  

It completely disables CIS 4, if the sandbox is enabled!!!

p.s. I wrote a PM to the staff about that, but no answer, so…

I’m pretty sure it was this:

But I may be wrong. It’s not like I’m going to test it to find out.

Yes, it was this.Look at my post above.I have tested it and my PC went to the valley of the dead.

Well, at least we can prove the sandbox is fatally flawed.

How can we make it better then? Or is that something that does not interest you?

By fixing the problem. ;D How we should know what’s causing the problem?

By fixing its flaws? I did post the rogue that was able to get through.

In its current state, the sandbox is flawed and far from safe. This is proof of that. I didn’t say it couldn’t be improved.

The two of you didn’t submit it in the first place…

Yes I did. I submitted the file in the program, then I posted it here when I was asked.

Sorry for that mistake with the facts… my apologies…

Valuable information Mistermooth but intentionally running malware on your real system,risky business.You should either test these things in a VM or at least have an imaging strategy in place. :o

I was under the impression that it wouldn’t matter because of the sandbox. Wasn’t the point of the sandbox to take away all the worrying of running programs and allow anything to be run without your system being open to damage?

It was a fresh install anyway.

Wells… Technically your right Mistermooth… but Ideally it should be done on a VM or a spare PC… Just like you found out the hardway, things CAN go wrong. None the less… thanks for the info

Hopefully this info can be used to help improve the sandbox and make it impenetrable.