A forum for reverse engineering, OS internals and malware analysis 

Forum for discussion about user-mode development.
 #16714  by R00tKit
 Tue Nov 20, 2012 9:10 am
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 :
 #16715  by 0x16/7ton
 Tue Nov 20, 2012 9:15 am
List IOCTL that we use:
Code: Select all
Input buffer boolean type,setting them in false.
 #16716  by rinn
 Tue Nov 20, 2012 9:54 am

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

Link to download.

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,
 #16719  by rinn
 Tue Nov 20, 2012 10:25 am
Alex wrote: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,
 #16726  by EP_X0FF
 Tue Nov 20, 2012 12:39 pm
rinn wrote: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.


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

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)
 #16745  by kmd
 Wed Nov 21, 2012 7:06 am
EP_X0FF wrote: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

 #16747  by EP_X0FF
 Wed Nov 21, 2012 9:11 am
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.
 #16749  by EP_X0FF
 Wed Nov 21, 2012 10:31 am
kmd wrote:just one more question, what is the spidie you talking about?

this? :D

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.
 #16750  by rinn
 Wed Nov 21, 2012 1:25 pm
EP_X0FF wrote: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,
  • 1
  • 7
  • 8
  • 9
  • 10
  • 11
  • 13