Search the Community

I receive crash dumps containing pirated antiviruses all the time, however I felt the need to blog about it for once because it's actually so often and just comical to me at this point. I also haven't blogged in a little while. I'm not really here to discuss the pros & cons of antivirus software, it's obvious. What I will say however is it's also obvious that for any software you install regardless of its intended job, you're increasing your attack surface. Given the fact that most antiviruses are granted complete come/go access to the kernel, have the highest privileges, have various kernel-mode drivers, etc, your surface is increased just that much more. Let's take a look at this crash dump (unfortunately only a Small Memory dump...): 2: kd> .bugcheck Bugcheck code 00000024 Arguments 00000000`001904fb fffff880`085866a8 fffff880`08585f00 fffff880`016b1d82 Right, so we have our bug check - NTFS_FILE_SYSTEM (0x24). Big hint, if you see this bug check on a crash dump from a user, chances are it's 50/60% (or more) the fault of either the one security application they have installed (whatever the actual problem with the application is), or user error as far as installing more than one security applications go. It's generally a bad idea to pigeonhole a bug check with a single problem (because it's ridiculous to do so), but I'd personally say over the years 0x24 has been much more of a security software issue than anything else. 2: kd> .exr fffff880`085866a8 ExceptionAddress: fffff880016b1d82 (Ntfs!NtfsRemoveHashEntry+0x00000000000000c2) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000000 Parameter[1]: ffffffffffffffff Attempt to read from address ffffffffffffffff By taking a look at the exception record structure, we can see the direct reason for the exception being thrown that caused the actual crash was an access violation occurring in Ntfs!NtfsRemoveHashEntry. Now that we know why, let's take a look at the context record using the address from our 3rd parameter in the .bugcheck output. 2: kd> .cxr fffff880`08585f00 rax=0000000000000000 rbx=fffff8a00224e050 rcx=0001000000000000 rdx=0000000000000000 rsi=000000001fdefdd9 rdi=fffffa80049be358 rip=fffff880016b1d82 rsp=fffff880085868e0 rbp=00000000000001d9 r8=00000000000003b2 r9=0000000000000000 r10=00000000000003b2 r11=fffff88008586910 r12=0000000000000001 r13=0000000000000000 r14=0000000000000001 r15=fffff8a003533ed0 iopl=0 nv up ei pl nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010206 Ntfs!NtfsRemoveHashEntry+0xc2: fffff880`016b1d82 397110 cmp dword ptr [rcx+10h],esi ds:002b:00010000`00000010=???????? On the instruction regarding Ntfs!NtfsRemoveHashEntry, we can see it was comparing the esi register to the memory at address rcx+10. rcx looks pretty bogus, and just to confirm: 2: kd> !pte 0001000000000000 // Or !pte rcx VA 0001000000000000 PXE at FFFFF6FB7DBED000 PPE at FFFFF6FB7DA00000 PDE at FFFFF6FB40000000 PTE at FFFFF68000000000 Unable to get PXE FFFFF6FB7DBED000 WARNING: noncanonical VA, accesses will fault ! So here's the reason why the exception was thrown, it was noncanonical. Now that we've also instructed the debugger to use the context record as the register context, we can run a k(b,nL,whatever) to get a more detailed stack in our case - even with a Small Memory dump: 2: kd> k *** Stack trace for last set context - .thread/.cxr resets it Child-SP RetAddr Call Site fffff880`085868e0 fffff880`016b224f Ntfs!NtfsRemoveHashEntry+0xc2 fffff880`08586970 fffff880`016b0a24 Ntfs!NtfsDeleteNormalizedName+0x7f fffff880`085869a0 fffff880`016b4cdb Ntfs!NtfsDeleteScb+0x1f4 fffff880`085869e0 fffff880`0162e343 Ntfs!NtfsRemoveScb+0x5b fffff880`08586a20 fffff880`016b2a3c Ntfs!NtfsPrepareFcbForRemoval+0x53 fffff880`08586a50 fffff880`01635a52 Ntfs!NtfsTeardownStructures+0xdc fffff880`08586ad0 fffff880`016c22d3 Ntfs!NtfsDecrementCloseCounts+0xa2 fffff880`08586b10 fffff880`01714d32 Ntfs!NtfsCommonClose+0x353 fffff880`08586be0 fffff800`02ae1561 Ntfs!NtfsFspCloseInternal+0x186 fffff880`08586cb0 fffff800`02d740ca nt!ExpWorkerThread+0x111 fffff880`08586d40 fffff800`02ac8be6 nt!PspSystemThreadStartup+0x5a fffff880`08586d80 00000000`00000000 nt!KxStartSystemThread+0x16 Not going to put comments, but rather just talk about it. We were starting a system thread which turned out to be a worker thread (as we can see from the ExpWorkerThread function), and from then on go throughout various NT file system calls. Given the fact that it's a worker thread dealing with NTFS tells us we're likely dealing with a driver requiring delayed processing, etc. As we're going through various NTFS calls, we can see we're preparing the File Control Block (FCB) and Stream Control Block (SCB) for removal and deletion. This also tells us if anything, it's a driver working actively with/for the file system. Looking at the loaded modules list for any drivers actively working with the file system, what do we find? Hint: A lot of Symantec/Norton kernel-mode drivers 2: kd> lmvm SRTSP64 start end module name fffff880`082d4000 fffff880`08394000 SRTSP64 (deferred) Image path: SRTSP64.SYS Image name: SRTSP64.SYS Timestamp: Tue Mar 29 22:46:12 2011 Here is Symantec's x64 Real Time Storage Protection (SRTSP) driver. This driver is used by Symantec's Auto-Protect feature, which is what scans files under various conditions. You can expect to find this kernel-mode driver on any system with NIS installed, so what's the big deal? The timestamp/date on the driver itself is from March 29th 2011. The time of the bug check is: Debug session time: Tue Feb 3 23:57:58.466 2015 (UTC - 5:00) Okay, so we have a kernel-mode driver from/for Norton that's approximately as of this blog post 3.8 years old. That's.... bad. To give the user the absolute ultimate benefit of the doubt, I for a split-second thought that perhaps maybe Symantec really has a kernel-mode driver regarding RTP that's 3.8 years old. Surely there may be hundreds of vulnerabilities, but it's possible.. right? Wrong. 2: kd> vertarget Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 7601.18700.amd64fre.win7sp1_gdr.141211-1742 It's a Windows 7 x64 system, so let's create a test environment really quick and install the latest trial version of NIS. Ah, that's much better. Unfortunately, that wasn't the only out of date kernel-mode driver regarding Symantec loaded on this particular system. Let's keep comparing: 2: kd> lmvm SYMDS64 start end module name fffff880`01279000 fffff880`012ea000 SYMDS64 (deferred) Image path: SYMDS64.SYS Image name: SYMDS64.SYS Timestamp: Tue Dec 07 19:16:58 2010 Symantec's x64 Data Store (SymDS) driver. 2: kd> lmvm SYMEFA64 start end module name fffff880`014f4000 fffff880`015d8000 SYMEFA64 (deferred) Image path: SYMEFA64.SYS Image name: SYMEFA64.SYS Timestamp: Sun Mar 13 23:20:58 2011 Symantec's x64 Extended File Attributes driver. 2: kd> lmvm SYMEVENT64x86 start end module name fffff880`01dbf000 fffff880`01df5000 SYMEVENT64x86 (deferred) Image path: SYMEVENT64x86.SYS Image name: SYMEVENT64x86.SYS Timestamp: Thu Mar 24 19:02:36 2011 Symantec's x64 SymEvent driver. 2: kd> lmvm SRTSPX64 start end module name fffff880`01c2d000 fffff880`01c43000 SRTSPX64 (deferred) Image path: SRTSPX64.SYS Image name: SRTSPX64.SYS Timestamp: Tue Mar 29 22:46:18 2011 Symantec's x64 Real Time Storage Protection (SRTSP - PEL) driver. 2: kd> lmvm SYMNETS start end module name fffff880`01d58000 fffff880`01dbf000 SYMNETS (deferred) Image path: SYMNETS.SYS Image name: SYMNETS.SYS Timestamp: Tue Apr 19 18:33:31 2011 Symantec's Network Security WFP driver. Overall, we can see that all of these Symantec/Norton kernel-mode drivers are not their latest versions. Given the fact that the user's system bug checked Feb 2015 and many of its kernel-mode drivers are 3.8 years (or older) old, we know it's pirated. Remove pirated Norton, crashes stop. Surprise surprise. Moral of the story: If you really are going to pirate an antivirus, be sure it's actually as up to date as it would be if you paid for it. If you're running an antivirus with kernel-mode drivers from 3.8> years old, the amount of vulnerabilities you're vulnerable to that were patched years ago is pretty high. You're also opening yourself up to becoming infected with old malware that was invalidated if not further developed if it relied on certain EOP (or other) exploits to get around active protection. Also, as you can see here, chances are you'll bug check considering you're also subject to ~3.8> year old driver bugs that have since been patched. You could alternatively just buy the antivirus. Crazy, I know. source