There is a rather confusing bug i have found"using the latest beta but i believe it affected all other builds aswell"…when injecting a .dll into unknown application to take it over and command the application to download from the web… comodo will allert that the application is connecting to the web but wont mention that it was connecting because of the .dll injection…however after i added the unknown application to comodos allow list THEN comodo warned me about the injected .dll trying to control the now “known” application…this could be a rather bad exploit as to me it looked like a normal connection attempt
i used Zapass to inject folderlockbox"an app not known by comodo" then instruct Zapass to download from the web…and Comodo pops up telling me FolderLockBox is trying to connect to the web and i click allow cus it looks normal and then zapass is able to download the file through FLB…now this time i add FLB to the known applications and safe to access the web…then i try the Zapass test again but this time Comodo Alerts me that Zapass has injected a .dll into FLB…so you see spyware could find and see what applications are in the allowed to connect to the web database then find an application that isnt in the list then inject it with its code take controll and make what seems to be a perfectly normal connection atempt…NOT good…
And this is exactly why the known and unknown databases are not user readable or editable - to prevent poisoning by malware.
Also, in the scenario you described above, shouldn’t it be obvious to the user that as they hadn’t started FLB but it was attempting to gain net access that something was wrong? With some users, that’s a long bow to draw, but most users know when they have or haven’t started an application (the ones who don’t are the scary ones ;)).
Not for say if the app is AVG anti-spyware which has an auto update feature that will popup all of a sudden since its not in Comodos database thats its connecting to the web
if the injector injected teh .dll into an app that has an auto update feature then it would look perfectly normal…
If it was injected directly into the file as it exists on the disk, then the cryptographic signature of the host dll would have changed.
If it was injected directly into the memory space of the rujnning dll … I’ll just have to have a think about that one.
Please don’t misunderstand me, I’m not trying to hose down all of your suggestions, just trying to make us both think harder about ways to sidestep the firewall. The sooner someone thinks up a detour, the sooner the code monkeys can get back to work.
Dont worry i am not taking it as “hoseing down my suggestions” i agree with what you say…
heres another thought
“though the one i mentioned above i have tested it with a new user to comodo and allowed zapass to control AVG anti-spyware to download from the web because he allowed the internet access atempt i asked him why and he said its prolly just AVG auto updating” i did the test making sure he hadnt created rule for it in comodo that way comodo wont mention the dll is being injected into avg
also
iv noticed when trying to terminate Comodo the message pops up the engine is going to be
shutdown…well i created a very simple macro that simulates the termination using the
" normal terminate process command" as i have found comodo does not allert the user when a thread injection is used “or any other advanced command is used”
then clicks yes the message that pops up and always easily shutsdown the firewall…
the whole message thing doesnt seem like a very good idea
also modifying it just a little where it just keeps trying to terminate it creats quite a mess of alerts for the user that could frustrate a “non understanding” user to enough to shutdown the firewall for it
Its a piece of cake to terminate cpf.exe and cmdagent.exe, but you’re still protected through the lower level driver, you just cant communicate with the firewall anymore., That doesn’t mean it’s not still doing its job.
If you like a challenge, try killing off inspect.sys, the kernel level stateful packet inspection driver. LOL See you in about a year.
yes i am aware that driver is still protecting the user…
Sounds like a challange to me…I like challanges…tell you what you seem REAL confident in comodos self protection"and i must admit it is very good"…im going to start looking for a way to bypass the driver when i do ill let you know by starting a new topic under firewall leak testing…lol any rules you want to add to this lil game…like no safe mode modifications?
The only rules are that the firewall must be installed in a normal manner - i.e. normal rules in place, normal options selected and standard TCP/IP is running on the PC hosting the firewall.
Preferably, you must be able to terminate the firewall without physical access to the computer running CPF. After all, you don’t actually let crackers sit down at your PC and do their stuff, do you? LOL
Seriously, if you can crash the firewall, Comodo would be very.v.v.v.v. interested in how it was done.
Let us know how you go! A few pointers on what not to try - backfilling memory, ring manipulation, RAM flooding, dynamic NIC IP manipulation. While some of these result in a loss of connectivity, that’s not the real point, is it?
i have no other computer i can use long enough to try from the outside in…just mainly looking for a way a trojan could say could disable the FW…just mainly giving me somthing interesting to do when im bored ;)…before i try does comodo have mouse manipulation clicks protection to be able to tell a reall click from a simulated one?
