[R00tKit]

+
Add dll in AppInit_DLLs
when dll get load check if it is in AVP.exe so ExitProcess ( tested 2012 in xp sp3)

+ one untested method ( but i think it will work , i send idea to 0x16/7ton for test )

[kmd]

+
Add dll in AppInit_DLLs
when dll get load check if it is in AVP.exe so ExitProcess ( tested 2012 in xp sp3)

strange :?
isnt such simple trick handled by hips? are you doing reg key modification from your program? no hips alerts?

[R00tKit]

strange
reg key modification from your program?

i dont remember it it was old time ! but i think NO :lol: :lol: :lol:

[kmd]

strange
reg key modification from your program?

i dont remember it it was old time ! but i think NO :lol: :lol: :lol:

if you did key modification from

trusted application like for example regedit than i think hips will pass it - this is not bypass
your own program and hips allow this - this is bypass

[m5home]

I don't think attack UI is a good method.

[rinn]

Ahh, AV sandbox/monitoring drivers (a.k.a. marketing "proactive defense") always were big joke. If you remember few years ago matousec published report about common plague in HIPS drivers (see http://www.matousec.com/info/articles/p ... rivers.php) - drivers that implement SSDT hooking do not properly validate the parameters of the hooking functions - multiple BSoD's and even privilege escalation exploits. If you have source code of KAV you can check how this monitoring features were implemented in that time. Klif was full of silly bugs. Six years after we have more secured code (BSoD's mostly fixed) and such results http://www.matousec.com/projects/proact ... esults.php with Comodo at top of "Pro security". The Comodo firewall, it is really strong as in this table? Nope, the cmdguard.sys is still vulnerable for attacks from user mode, so this result is 100% joke.

I did little demonstration which exploits vulnerability in cmdguard.sys driver (v5.12.55693.2551 - up-to-date version from their site). The core of this exploit is again incorrect processing of parameters sent from user mode. This time it happens inside NtOpenProcess handler, but I'm sure the same type of vulnerability exists with other comodo hooks (basically all that are operating with user mode pointers). It isn't race condition however. It does not use any kernel memory modification, does not unhook anything, it is doing just a few system calls from user mode. Probably it is possible to do invisible for comodo memory ring3 inject based on this method, didn't tried honestly :)

As payload it terminates Comodo application from user mode (even without assigning debug privilege) bypassing all Self-Defense. The size of exploit code is ridiculously small. This is amusing bug inside comodo driver. Without comodo driver Windows won't allow such system call.

For security and from ethic reasons because I believe this kind of exploit can also work with wide range of different AV/FW products (it can be fundamental flaw in security drivers just like before bad SSDT hooking) I will refrain from placing ready-to-use code or compiled modules. Excuse me for sort of off-topic.


Link to swf demo
http://www.sendspace.com/file/lifudv

password is "test" without quotes.

Best Regards,
-rin

[EP_X0FF]

Hello,

As payload it terminates Comodo application from user mode (even without assigning debug privilege) bypassing all Self-Defense. The size of exploit code is ridiculously small. This is amusing bug inside comodo driver. Without comodo driver Windows won't allow such system call.

Interesting, in this video cmdagent service is untoched, as I guess it wasn't a point of demo? It is working for all comodo processes, not GUI attack in other words, because system calls can be for win32k obviously too?

[rinn]

Interesting, in this video cmdagent service is untoched, as I guess it wasn't a point of demo? It is working for all comodo processes, not GUI attack in other words, because system calls can be for win32k obviously too?

Hi.

Comodo service is alive only because it wasn't in list on termination. This is not GUI attack. To be honest I was inspired by your Spidie series :) I've made a little test with products-winners from Matousec list. I assume they use the same drivers in "Security Suite" versions.

Comodo Firewall --- you saw result.

Online Solutions Security Suite 1.5 --- doesn't work on my machine. Error message while installation - "unknown versions of kernel modules, please submit them to us". Too much fingerprinting, heh? This product wasn't updated for more than year, so I assume it is dead (Updated: 15-Feb-2011 13:50).

Privatefirewall 7.x --- not affected by this bug like Comodo, but still can be easily terminated from user mode by simple switching to different method.

Outpost Firewall 7.5.x --- Sandbox.sys is suffering from this bug. Agnitum product can be terminated from user mode.

And special test against ESET NOD32 6 because I've near to me machine with it. As expected complete bypassing and gui + service termination from user mode, but Nod32 driver is not affected by "comodo style" bug. However application is suffering from another bug which results in Nod32 self-blocking and application crash ;)

I can do a short videos for each except OSSS if interested.

Best Regards,
-rin

[EP_X0FF]

Hello,

I can do a short videos for each except OSSS if interested.

sure, interested.

Regards.

[rinn]

Hello,

I can do a short videos for each except OSSS if interested.

sure, interested.

Regards.

Hi.

Link to download.
http://www.sendspace.com/file/4y6s0y

Pasword for archive is "test" without quotes.

Outpost 7.6 (3986.649.1842) - outpost_demo.swf
Pfw 7.028.1 - pfw_demo.swf
Nod32 6.0.115.0 - nod_demo.swf

All of them terminated very well, furthermore nod32 experiencing additional crashes.

Kaspersky immune to "comodo style" bug, but this thread is full of the different Kaspersky termination methods, so I skipped it.

Best Regards,
-rin