I was using an old version of Norton Anti Virus and the Live Update wouldn't run. The solution was to rename a file. This got me thinking if a virus could replace an anti-virus database with it's own bogus one and make it appear that the definitions are always up to date, would the anti-virus system be hooped? How could this be protected against?

  • 2
    I suppose but Norton signs their database. Unless they use a method to sign their method that would allow for a collision, it would be unlikely, anyone could generate a database file that matches the expected signature. Which is the reason its just easier to disable the program all together. – Ramhound Sep 5 '12 at 12:24

Anti-virus software are only useful as a preventive measure.

When your computer is clean, they are able to detect and prevent any attempts by malware to execute on your system. They rely on their malware database to do this. New and undiscovered malware will not be detected in such a way.

If a malware manages to execute on your system, you simply cannot trust the system anymore. There is no way to ensure that the malware is successfully removed. There is just too many ways a piece of malware can hide itself. Your best bet would be to wipe the system and start over in such a situation.

To answer your question - yes it can be done, it has been done.

Prevention is always better than cure. Take the usual steps to protect yourself - don't execute untrusted files and so on.

  • You can't trust the operating system. You can be reasonably sure, at the current state of the art, that the hardware is safe. If it wasn't, "wipe the system" is not very useful advice either. So: is there some problem with running a full AV scan from a clean boot disk? If you already have a Norton product key, they have one, and it claims to be able to download signatures online. ("Claims", because it's based on Windows; I would actually expect the Linux-based ones have more comprehensive network drivers & wireless support). – sourcejedi Sep 5 '12 at 14:18
  • 1
    @sourcejedi And how can you be sure that the AV can detect the malware already hidden in your system? – Ayrx Sep 5 '12 at 14:49
  • @TerryChia - Simple enough to solve. Use more then one product. If multiple security vendors are unable to detect a threat there is unlikely a threat. – Ramhound Sep 5 '12 at 17:41
  • 1
    @Ramhound That is NO guarantee. AVs are reactionary by nature. If a previously undetected threat was found on your system, there is no way an AV can detect the threat. – Ayrx Sep 6 '12 at 2:05
  • One solution is to boot off a clean disk and scan your machine from there. That's probably your best bet for detecting rootkits. – Brian Sep 6 '12 at 14:32

Some viruses simply disabled anti-virus programs. So it does happen. Another malware tactic is to install a rootkit which would prevent any other program detecting the virus.

Old-school "viruses" were a malicious prank, which would eventually do something interesting to show themselves, even if the anti-virus couldn't detect them. The modern threat is botnet software which exploits your computer to make money, so there's a big incentive to avoid being detection.

Anti-virus sellers responded to this sabotage in a classic arms race. They used all sorts of low-level tricks to detect when a virus was inhibiting them. This was not a race either side could "win" for sure; it's just two programs which can use the same powers, fighting for control of the same computer.

Modern Windows has built-in support for anti-virus. Hopefully this means Windows effectively reserving some powers for anti-virus only, so it could gain a somewhat stronger advantage than just having been installed first.

Modern Windows also has a driver-signing program, which should make it significantly harder to load malicious code like rootkits into the "kernel".

Windows 8 provides support for secure boot. This feature will (once any implementation mistakes are closed down...) prevent viruses modifying the boot path to load themselves (and then be able to sabotage the AV). Windows already attempts to stop viruses doing this while it's running. I.e. writing to the boot sector is one of these powers Windows tries to reserve. But e.g. if a virus wrote itself to e.g. a usb storage device and you left it plugged in, the BIOS could boot from that device and you be hosed. Secure boot should prevent that.

All of these are subject to local privilege escalation vulnerabilities. E.g. if there's a bug in the kernel, a virus may exploit it to load itself into the kernel. These are mitigated to some extent by NX and ASLR... but at least in Linux, which I'm more familiar with, they do still keep coming up.

I would never trust AV completely, and it's always worth exercising caution about what software you choose to run.

  • "But e.g. if a virus wrote itself to e.g. a usb storage device and you left it plugged in, the BIOS could boot from that device and you be hosed." - shouldn't boot-from-usb be disabled in any sane BIOS configuration anyway? – tdammers Sep 5 '12 at 20:32
  • @tdammers Maybe I'm thinking out of date here as well. I do like USB booting linux images, but maybe everyone's supposed to use a key-triggered boot menu nowadays, instead of giving priority to to removable boot media. Is that the default setting on all modern systems? An alternative scenario would be dual-booting, where a virus might find it easier to compromise the non-running system, but I was trying to think of a more common scenario. – sourcejedi Sep 6 '12 at 15:46

Most AV solutions prevent this by digitally signing their database. This involves computing a cryptographic hash of the database, then encrypting it with an asymmetric private key. The corresponding public key is embedded in the application, which it then uses to verify the authenticity of the database.

There are two potential attacks here:

  • Collisions if a poor-quality hash (e.g. MD5 / CRC) is used. There are practical attacks on MD5.
  • Replace the public key in the executable / in memory.

The solution to the first attack is to use a strong hash, e.g. SHA-2 family. This ensures that the database is secure against hash collisions.

The solution to the second attack is a little more difficult. Preventing the on-disk executable from being modified is just a case of digitally signing it. However, the in-memory mods are more difficult to protect against. Quite a few AVs attempt to solve this by hooking memory access APIs at the kernel level, to prevent in-memory modification of their AV processes. This works quite well, but it's not a panacea.

Another problem is that a rootkit could modify the buffer that contains the executable contents as it is read from the disk, by acting as a mass storage filter driver. Again, there are some methods that are reasonably successful in defeating this, but they're not 100% effective.

At the end of the day, once malware runs on your computer, it is no longer your computer. AV is very useful for identifying malware before it gets a chance to execute, but it's relatively bad at mitigating the damage once the malware runs. I really wish AV vendors would embrace this, and focus on identification before execution, instead of trying to push snake-oil remedies for malware already running on a box.

  • There are a few antivirus vendors that do try identifying before executing however static code analysis is not enough so they often add things like Avasts' sandbox... – ewanm89 Sep 5 '12 at 18:05

I think you should never rely on an AV software alone.

Make sure to have an admin user, that owns the file used by Norton.
Have a regular user, that you normally use, that can't change this file.

How to set up administrator account in windows

  1. From the Start menu, click Control Panel. Note: If this doesn't match what you see, refer to About navigation settings in Windows.

  2. Double-click User Accounts, click Manage User Accounts, and then click Add... .

  3. Enter a name for the administrator account. Click Next > .

  4. Select the radio button titled Other: , and from the drop-down menu, choose Administrators.

  5. Click Finish, which will take you back to the User Accounts dialog box. Click OK.

Make sure the file can only be edited by the administrator account

  1. Right click on the file and select the Properties.
  2. Under General tab place the check mark on Read-only attribute, for the non-administrator accounts and EVERYONE, which is next to Attributes label.

  3. Check the Full Control mark for the administrator account.

  • +1 for privilege separation. -1 for manual fixes. If your AV installer really didn't get this right in the first place, it's insane and you need to switch vendors. No excuses, Microsoft Security Essentials is free and google knows how to uninstall Norton. If it was broken manually, reinstalling will sort it out & make sure there aren't any other broken bits. – sourcejedi Sep 5 '12 at 13:57
  • Didn't really think AV was allowed to create a new user and remove rights from the Admin account ( If that's what you're using ), and give rights to the newly created user. – Kao Sep 6 '12 at 6:43
  • Ah, manually creating an administrator account is a good idea. I just don't like the idea of manual fiddling with permissions on AV files. – sourcejedi Sep 6 '12 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.