Pirating Antiviruses

[Aerosol]

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