[R00tKit]

Ok ha ha ha

just another AV killer

we ( me and my good friend 0x16/7ton ) write POC that can be able kill AV

Securuty flaw allowed total manipulation with av soft. with this trick we able to inject code inside AV processes and for test we target Dr.web , As payload we choose injecting code into the original GUI process and sending special IOCTL to it driver and disable it self-protection ( for fun :mrgreen: we select sending ioctl , although killing it is simple without send anything )

we say this is universal method fro injection code inside AV process but need test over AV's

demo :
http://www.sendspace.com/file/bm7a8i
regard

[0x16/7ton]

List IOCTL that we use:

Code: Select all

*******************************
DwProtSetControlState
8A000
8A008
8A038
8A0C8
8A074
8A040
8A048
8A010
8A098
8A06C
8A0A0
8A090
8A0C0
8A060
8A018
8A0D0
8A050
8A0E8
860EC
860E4
*******************************

Input buffer boolean type,setting them in false.

[rinn]

Hi.

Yet another Dr.Web 8 termination, which differs from the above posted.

Link to download.
http://www.sendspace.com/file/cicteh

Pasword for archive is "test" without quotes.

This is pure user-mode attack which doesn't use:

- drivers or any kind of specially mapped ring0 code
- unhooking or disabling dwprot, it is fully working but can not do anything against attack
- system reboots
- file system manipulations
- usage of system or applications bugs

Dr.Web "Preventive Protection" was set on "Paranoid" mode.

As a result of poc execution, there is a kind of self-locking of the dwengine component because it set on restart if any failure happens and it is protected by dwprot hooks along with configuration manager callback. This can't be fixed without redesigning whole SP, because it is still the same Dr.Web SP design flaw which was discovered by EP_X0FF in 2009. Three years later it is still there, they only added nonsense SSDT hooks leaving problem of overall SP silly design unresolved. No, more SSDT hooks will not help either.

Best Regards,
-rin

[rinn]

Hi.

I didn't use DefenseWall, so I don't know how good protection it provides. Is it immune to mentioned in this topic attacks?

DefenseWall is SSDT hooking based HIPS with sandboxing. It must be installed on 100% free from malware computer as it assumes most of installed programs as "trusted". This could be changed however, overall this HIPS requires manual configuration. All other programs are automatically marked by DefenseWall as "untrusted". If malware attempts to install on your system via an "untrusted" program, DefenseWall's will prevent it work because of strong restrictions. Let's say you have malware dropped from temp. When executed as untrusted it naturally can do nothing - because of sandboxed execution. If this malware extract for example another executable it also become automatically untrusted. How strong this sandboxing? Impossible to say if you don't try it yourself, usually this HIPS scores 100/100 in every test where it tested.

If you plan do tests with this HIPS you have to execute your code as "untrusted" just like it will be launched outside testlab.

Best Regards,
-rin

[kmd]

who is next? :D

[EP_X0FF]

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).

It installs 70+ splicing hooks in ntoskrnl, win32k, ndis, tdi. No surprise setup forbids installation with unknown kernels.

ntoskrnl

They hooked SSDT with inline jmp patches + Object type callbacks and even Iop* routines.

804e447f-804e4483 5 bytes - nt!MmCreateSection
80530f08-80530f0c 5 bytes - nt!IopUnloadDriver (+0x4ca89)
80568fc3-80568fc7 5 bytes - nt!NtAllocateVirtualMemory
8056a81f-8056a823 5 bytes - nt!CmpSecurityMethod (+0x185c)
8057065d-80570661 5 bytes - nt!NtCreateKey (+0x5e3e)
80570fd7-80570fdb 5 bytes - nt!NtOpenSection (+0x97a)
805715e0-805715e4 5 bytes - nt!NtDuplicateObject (+0x609)
805717c7-805717cb 5 bytes - nt!NtOpenProcess (+0x1e7)
80571cb1-80571cb5 5 bytes - nt!NtProtectVirtualMemory (+0x4ea)
80572889-8057288d 5 bytes - nt!NtSetValueKey (+0xbd8)
805735ad-805735b1 5 bytes - nt!MiUnmapViewOfSection (+0xd24)
80573a5e-80573a62 5 bytes - nt!MmMapViewOfSection (+0x4b1)
80576ce6-80576cea 5 bytes - nt!NtRequestWaitReplyPort (+0x3288)
8057b885-8057b889 5 bytes - nt!NtTerminateThread (+0x4b9f)
8057bc36-8057bc3a 5 bytes - nt!NtQuerySystemInformation (+0x3b1)
8057e2ce-8057e2d2 5 bytes - nt!NtReadVirtualMemory (+0x2698)
8057e420-8057e424 5 bytes - nt!NtWriteVirtualMemory (+0x152)
805802e7-805802eb 5 bytes - nt!PspCreateProcess (+0x1ec7)
80581d3f-80581d43 5 bytes - nt!PspProcessDelete (+0x1a58)
805822e0-805822e4 5 bytes - nt!NtTerminateProcess (+0x5a1)
8058e10c-8058e110 5 bytes - nt!PspCreateThread (+0xbe2c)
8058ecb2-8058ecb6 5 bytes - nt!NtResumeThread (+0xba6)
8058f4de-8058f4e2 5 bytes - nt!NtSecureConnectPort (+0x82c)
805902d5-805902d9 5 bytes - nt!LpcpDeletePort (+0xdf7)
8059108b-8059108f 5 bytes - nt!NtQueueApcThread (+0xdb6)
80592d50-80592d54 5 bytes - nt!NtDeleteValueKey (+0x1cc5)
805952be-805952c2 5 bytes - nt!NtDeleteKey (+0x256e)
805975b1-805975b5 5 bytes - nt!NtCreatePort (+0x22f3)
8059b19b-8059b19f 5 bytes - nt!NtSetSecurityObject (+0x3bea)
805a24ba-805a24be 5 bytes - nt!NtAssignProcessToJobObject (+0x731f)
805a2882-805a2886 5 bytes - nt!NtCreateDirectoryObject (+0x3c8)
805a31bd-805a31c1 5 bytes - nt!MmLoadSystemImage (+0x93b)
805a3599-805a359d 5 bytes - nt!IopLoadDriver (+0x3dc)
805a3af1-805a3af5 5 bytes - nt!NtLoadDriver (+0x558)
805a7bdd-805a7be1 5 bytes - nt!NtSetSystemInformation (+0x40ec)
805aeb9a-805aeb9e 5 bytes - nt!NtLoadKey2 (+0x6fbd)
805db124-805db128 5 bytes - nt!NtCreateWaitablePort (+0x2c58a)
805e045e-805e0462 5 bytes - nt!NtSuspendThread (+0x533a)
8062bf2f-8062bf33 5 bytes - nt!NtInitiatePowerAction (+0x4bad1)
8062dcdf-8062dce3 5 bytes - nt!NtSetContextThread (+0x1db0)
8062f8c1-8062f8c5 5 bytes - nt!NtSuspendProcess (+0x1be2)
8064716b-8064716f 5 bytes - nt!NtShutdownSystem (+0x178aa)
80649ce3-80649ce7 5 bytes - nt!NtSystemDebugControl (+0x2b78)
8064e79e-8064e7a2 5 bytes - nt!NtRenameKey (+0x4abb)
8064ec91-8064ec95 5 bytes - nt!NtRestoreKey (+0x4f3)
8064ed92-8064ed96 5 bytes - nt!NtSaveKey (+0x101)
8064ee7d-8064ee81 5 bytes - nt!NtSaveKeyEx (+0xeb)
8064efaa-8064efae 5 bytes - nt!NtSaveMergedKeys (+0x12d)
8064f0fa-8064f0fe 5 bytes - nt!NtReplaceKey (+0x150)
8065b1cd-8065b1d1 5 bytes - nt!NtDebugActiveProcess (+0xc0d3)
8066768b-8066768f 5 bytes - nt!NtSetSystemPowerState

win32k

Inline patching of Shadow SSDT services + inline patching of internal win32k routines.

bf8088a9-bf8088ad 5 bytes - win32k!_PostMessage
bf80ee6b-bf80ee6f 5 bytes - win32k!NtUserMessageCall (+0x65c2)
bf820e6c-bf820e70 5 bytes - win32k!NtUserGetKeyState (+0x12001)
bf840fb7-bf840fbb 5 bytes - win32k!xxxInterSendMsgEx (+0x2014b)
bf84928e-bf849292 5 bytes - win32k!NtUserGetAsyncKeyState (+0x82d7)
bf852720-bf852724 5 bytes - win32k!NtUserGetKeyboardState (+0x9492)
bf8527e0-bf8527e4 5 bytes - win32k!NtUserSetWindowsHookEx (+0xc0)
bf8b3c2e-bf8b3c32 5 bytes - win32k!_PostThreadMessage (+0x6144e)
bf8ed991-bf8ed995 5 bytes - win32k!NtUserSetWinEventHook (+0x39d63)
bf915ba7-bf915bab 5 bytes - win32k!NtUserRegisterRawInputDevices (+0x28216)

ndis splicing + new NDIS protocol "PACKETDRIVER". All other protocols for example TCPIP have multiple hooked protocol handlers (e.g. StatusHandler, SendCompleteHandler).

Code: Select all

f819617f-f8196183  5 bytes - NDIS!NdisRegisterProtocol
f8196399-f819639d  5 bytes - NDIS!NdisOpenAdapter (+0x21a)
f8197674-f8197678  5 bytes - NDIS!NdisCmRegisterAddressFamily (+0x12db)
f8199a6f-f8199a73  5 bytes - NDIS!NdisMSetAttributesEx (+0x23fb)
f819a236-f819a23a  5 bytes - NDIS!NdisMCmRegisterAddressFamily (+0x7c7)
f819b3d5-f819b3d9  5 bytes - NDIS!NdisMRegisterMiniport (+0x119f)
f819ba8e-f819ba92  5 bytes - NDIS!NdisIMRegisterLayeredMiniport (+0x6b9)
f81a0642-f81a0646  5 bytes - NDIS!NdisCloseAdapter (+0x4bb4)
f81a0821-f81a0825  5 bytes - NDIS!NdisDeregisterProtocol (+0x1df)
f81a7898-f81a789c  5 bytes - NDIS!NdisMQueryInformationComplete
f81acde3-f81acde7  5 bytes - NDIS!NdisMCoRequestComplete

TDI, two inline hooks

Code: Select all

f883a992-f883a996  5 bytes - TDI!TdiRegisterPnPHandlers
f883aaf0-f883aaf4  5 bytes - TDI!TdiDeregisterPnPHandlers (+0x15e)

[kmd]

It installs 70+ splicing hooks in ntoskrnl, win32k, ndis, tdi. No surprise setup forbids installation with unknown kernels.

lol it looks like spambot :mrgreen:

just one more question, what is the spidie you talking about?

this? :D

http://forum.drweb.com/index.php?showtopic=288595
http://forum.drweb.com/index.php?showtopic=290673

[EP_X0FF]

Rin's poc become famous :D

Some friend of mine gave me this link today.

https://forums.comodo.com/comodo-intern ... ;msg637652

I like this post

Another things I noticed was that the test was done in Virtual Box. Virtual Box was, may still be, known to not be able to handle CIS as it does/did support all functions needed.

lolwut? Have you heard - windows inside virtual box is not a correct windows for comodo. What functions? Misses SSDT? Maybe it have totally different set of syscalls? Facepalm.

[EP_X0FF]

just one more question, what is the spidie you talking about?

this? :D

http://forum.drweb.com/index.php?showtopic=288595
http://forum.drweb.com/index.php?showtopic=290673

Yes, that my SpiDiE.

It was initially Dr.Web 5.0 termination proof-of-concept. I did it in the beginning of 2009 while reversing dwprot and jetico firewall self-protection parts because I was building my own and doing some R&D for US company (name is irrelevant) and I did not want to use SSDT patches. Initially it was exploit for major flaw in dwprot (they didn't fixed it even now, see rin's poc). When it was ready i thought "it will be really entertaining to do fun from Dr.Web" (I knew that the managers of the company mentally unbalanced, and how painful they react to all bugs in their software). So I did completely different poc and it was posted on SysInternals (http://forum.sysinternals.com/spidie_topic19528.html). As a hidden payload (too make more fun from Dr.Web and irritate it more - provocing for answer) it included some "greeting" to former Dr.Web employee (really good one I must admit, name is irrelevant) who was currently under preasure from Dr.Web because this guy moved to competitor company (name is irrelevant). They took the bait, and added two first dwprot SSDT hooks - NtOpenSection + NtSystemDebugControl. But they did it really lame (one of their hook is still lame - can be used for another bypass even now in 2012). Then I have released new spidie targetting newly added NtOpenSection hook. They fixed it and I again released another spidie version, which uses csrss injection making further Dr.Web dwprot improvements are difficult to implement. And there happened ZOMG TEH DRAMA. Failed to make an adequate correction, they began to add spidie proof-of-concept to the antivirus databases as a Trojan.AVKill :) This behaviour very amused me (I got a lot of pleasure looking on company hamsters, their PR division, staff idiots posts, silly dwprot developers etc), so I continued to break their signatures releasing updated versions. In the beggining of 2010 was released spidie 2.0 (Dr.Web 6 support with FS filter detaching) which was able to do complete AV removal :) I updated this version in March (2.1) and August of 2010 (2.2), mostly removing signature detection Dr.Web. After one year problem wasn't fixed. I was bored with this AV and I forgot about it. That's all SpiDiE story, it wasn't someone else order etc, not a PR move it was all for fun and actually Dr.Web sligthly improved because of SpiDiE, so I still awaiting $$$$$ from Daniloff company :D Just kidding, he can keep his money (for a vodka! Balalayaka, kharasho :D).

Just a day ago I again looked on fresh new 8.0 version and ... guess what. Dwprot and overall AV become even worse.

[rinn]

Hi.

Some friend of mine gave me this link today.

https://forums.comodo.com/comodo-intern ... ;msg637652

I read this topic. If the program is not compatible with VBox emulation then it can be:

1. Using of x86 architecture bugs or not emulated commands (see https://www.virtualbox.org/ticket/1778). Likely they mean this old emulation bug https://www.virtualbox.org/ticket/2496. Some instructions maybe not propertly emulated like for example CPU cache invalidation, as I remember this instruction is not properly emulated by all popular virtual machines like bochs, vbox, vmware, vpc.

Obviously all this is not our case - Comodo installs and works pretty well on VBox, including fully working firewall features.

2. The program can not fully work with emulated hardware.
This is possible for example with network part, which my program does not use. Everything else hardware emulated VBox is quite common and can cause conflicts, only if the program uses it wrongly. Any firewall must follow generally accepted standards interfaces. For me would be a surprise if it turns out that a product like Comodo is so poorly written, that he suffers from incompatibilities with common virtualized hardware.

If we speak about trvial SSDT hooks they will be the same on a real machine and the modern virtual, regardless of what anyone thinks on Comodo forums. And bug itself won't disappear just because someone else think I use wrong test environment ;)

Regarding awareness of Comodo developers about the bug I use. I discovered it accidentally in about year ago while doing commercial penetration testing of other products for a private security firm. I don't remember maybe it was Zone Alarm. I tried it with different products and some of them were vulnerable too, including Comodo. The fact is that even after months this bug is still in Comodo and they seems to be unaware of it. If they were really interested in stable and correctly written software they would never have used such approaches as used now. So I did proof-of-concept and I honestly don't care about Comodo future actions. All required details already posted, of course if they are not completely dumb like they aware about copy-and-paste of their drivers code.

Best Regards,
-rin