Sophos On-Access Scanner gets "disabled" by Juniper Networks Host-Checker

HI,

That's most odd behaviour by any application to start deleting drivers; sounds like something malware would do.  I'm not even sure what the thinking behind it is.

Tamper protection extends to preventing uninstallation and tampering with settings in the GUI.

Any process running with enough privledges can do anything to a computer. I assume it's running a service as local system or a process is running as an Administrative user.

Regards,

Jak

OK, That is fair on the tamper protection. I hear you about the malware, but even if it were malware, being able to brick on-access scanning so easily is concerning. Shouldn't there be some protections on these files? I was able to subvert it by simply marking the files as read only. Couldn't the on-access scanner mark the files as in-use and thus prevent deleting?

In this specific case I am working with my customer to work with Juniper and get some feedback as to why it would delete these files. But in the grand scheme of things, I think Sophos needs to look at protecting the critical files on the system for security sake.

The problem being, if the malware is already been run, i.e.. Sophos has missed it for whatever reason and it's now executing as a high privileged account, e.g. system, a member of administrators, there isn't much you can do to secure against it. 

This is the reason for running as a low privileged account and only elevating when you need to, i.e.. UAC.  You don't unwittingly run something as an admin account that can damage/take control of the system.

Your account can equally just stop the SAVService as it's a member of Administrators.  How do you stop and administrator, you can't, even if you tie a resource down to system, an admin user can take on the system user context and do what he/she likes.

Regards,

Jak

I get what you are saying. I even fully agree with running as an unprivileged account. Unfortunately there is software out there, that requires you be an administrator to run. I guess all I am saying is, it is harder to delete a file that is locked as "in use". Note that I said harder, I do aknowledge that it is not impossible, I can schedule a file to be removed on restart if it is locked as in use.

Hello TomSadowski,

you asked for thoughts, so ...

Guess while "important" files could be locked (doing so for a driver might be tricky - nevertheless the (in)famous sptd.sys does it) it would add quite some complexity. Note that "protecting" just executables or all files is not sufficient, you'd also have to take care of e.g. registry keys. In addition an anti-virus is not static, it should honour legitimate configuration requests and it has to update itself regularly. And it is not guaranteed that what you do doesn't adversely interact with other schemes. As a result "clever" locking mechanisms might mean that you'd have to to go through Safe Mode in case of even a minor hiccup. It's the usual trade-off security vs. usability.
While it might be alarming that Sophos (or other similar products) can seemingly easily be disabled this falls short of depicting an actual successful attack (which you anyway can't absolutely prevent). Whatever cripples your AV must also do some "useful" (from the point of view of malware) work - and this intention likely makes it suspicious in the first place (it has to come from somewhere and it should be scanned on the way, therefore ...). As an aside - does the Juniper software install and run with the recommended AV settings without triggering an alert (and don't forget that signed applications have slightly more leeway than unknown)? If the malicious component (apart from the "AV disabler") isn't detected it won't have to turn off your AV anyway. Actually in this such a case the fiddling with your AV is counterproductive as it increases the chance of being detected. Ever wondered why "direct" attacks on AV software aren't more widespread?

Be assured - "self-protection" is something no serious AV vendor has neglected or discarded. But AFAIK no one has come up with a perfect or even satisfying solution (and similarly the "bad guys" haven't been able to build the ultimate weapon).       

Christian

I have the same exact problem with one of clients as well!!!

hey folks...ok so i was banging my head on the table for a couple days until finally coming across this post.

i first thought was related to the Shhhh/B thing...but i guess it isn't.

per our external partner, Juniper's HostChecker has a supported set of A/V and SOPHOS ain't on the list.

Are they using one of the antivirus supported by SSLVPN?

Avast! Antivirus Personal Free Edition (Free download on http://www.avast.com/)
?AVG Anti-Virus (Free download on http://free.grisoft.com/)
?AntiVir Personal
?Kaspersky Antivirus Basic
?Kaspersky Antivirus Pro
?McAfee Antivirus
?Norton Antivirus
?Norton Internet Security
?Symantec Antivirus
?TrendMicro

so, what's a brother to do? 

I was working with our vendor, and Juniper wanted all sorts of debugging info, so I provided it, and then they came back and wanted more, some of it duplicated. By that point we said heck with it and just made the files read only and told them figure it out, we don't have time to help you debug your **bleep** any more. So I have no clue what if anything they have done to remedy the issue since then, or if they said "screw them" and moved on.