Jump to content

Recommended Posts

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.

SRTSP.png

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.

SymDS.png

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.

SymEFA.png

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.

SymEvent.png

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.

SRTSPPEL.png

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.

SYMNETS.png

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...