Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: aphexv3 on August 25, 2004, 03:17:20 AM
-
if i know a file is a trojan/virus, how can i exclude it? i dont want to move/rename or move to chest, i want to leave it right where it is and have avast ignore the file in the future. like most antivirus programs do. can avast do this?
-
ap,
Firstly, If you know you have a trojan or virus, WHY would you want to keep it?
Avast can move the file to the Chest where it will be rendered harmless, but you can restore it from whence it came if the need arises.
Secondly, I am not wholly sure if this will work for the Home version (since you didn't state PRO), but you can open up the On Access Protection Module by right clicking on the A ball in the tray, locate the Standard Module on the right panel, open it up and find the Advanced tab.
You can enter the FULL path to the file or virus in the list.
This should work.
......but again....why would you want to do this?
Other AVs may be able to do this because they incorporate an "ignore list" which Avast does not have in that context.
Good luck.
-
Right, you can put the file to the list of exclusions of the Standard Shield (and you may also want to put it into the list of exclusions of the Simple/Enhanced User Interface).
-
this question brought me to this:
as i noticed exclusion paths are stored in Avast4.ini , and this file is not encrypted ...
this lead me to user visiting site with malicious script which first add line with exclusion for trojan / virus file/directory/extension/whatever ....
and then execute trojan/virus ...
and that lead to question:
how are Avast users protected against this situation ?
-
This "script" itself would be malicious then... and should be detected as such, and not be allowed to start.
If the script can modify an ini file, it can do other things as well... e.g. delete files.
-
so in fact,
when this type of script or executable (which alter exclusion entries in avast ini)
pass throught "malicious" script detection of Avast , script blocker or browser/os security
then Avast users are not protected ... right?
hmm, any way to force avast use encrypted config? :)
-
Well, I was trying to say that when such a malware is executed, you simply have a running virus on your computer. It can do anything... delete files, spread itself, kill & delete any antivirus... why bother with modifying the antivirus settings?
-
Dwarden,
Don't mean to upset the "apple cart" but it would be hard to encrypt an Av file with a modecum of success.
Encryption is a touchy issue and for general purpose applications like an AV, should be avoided.
However, your comment was a good one. The only thig that does help somewhat is a process guard which can be set to "prevent" AV shutdown from such an executable. ( I have one installed). This way, your AV continues to function and should be able to deal with the intruder.
What happens quite often is as Igor stated....
the exe file modifies or shutdowns the AV to the point of uselessness.
You can download "freeware" process guards.
Good luck
-
Dwarden,
Don't mean to upset the "apple cart" but it would be hard to encrypt an Av file with a modecum of success.
Encryption is a touchy issue and for general purpose applications like an AV, should be avoided.
However, your comment was a good one. The only thig that does help somewhat is a process guard which can be set to "prevent" AV shutdown from such an executable. ( I have one installed). This way, your AV continues to function and should be able to deal with the intruder.
What happens quite often is as Igor stated....
the exe file modifies or shutdowns the AV to the point of uselessness.
You can download "freeware" process guards.
Good luck
but even if your process guard works, if configuration is changed, you as user are not aware of such change, also this virus can go in multiple stages ...
first it will alter avast configuration file and add exclusion to various files/folders etc
second it wait till computer / avast restart ...
third execute real trojan / virus ...
i know the content of that code in someway dangerous, but if it become directed against avast, it will be very hard to defend before you know there is something like this ...
same problem got Kerio Personal Firewall and Tiny Personal Firewall and some other PF ... they got configurations in pure mode (xml etc) and were like open doors to mess with ...
avast can have e.g. md5 hash of own configuration file, if something alter it then md5 change, Avast see someone messed with and it will tell user in warning ...
that will be simple compromise ...
thoughts ?
-
Basicaly, if the malware is running with admin rights and explicitly knows its target it wants to kill (like avast), there's NO way to prevent it from doing so (no ProcessGuard, no MD5 hashes of config etc. will help). Such a process can load even device drivers (as some of the latest viruses/worms actually do), modify kernel structures etc... E.g., it can zero out the memory of the avast process to make it crash etc.etc. -- the possibilities are unlimited. There's really no way to prevent this generally.
On the other hand, there can be some ad hoc solutions aimed to protect avast from specific types of attacks. Fortunately, most virus writers really are not so smart (=computer proficient) as they feel and their code is far from perfect. But again, once a (malware) process is executed under admin rights, it can effectively become part of the OS and can alter behavior of any part of the system, including avast...
-
VLK,
Well, if that is the case......
What can we do to protect our systems short of not using them anymore? :D
Is there any way to "early detect" the presence of these executables before they start the damage, or a way to limit the damage caused?
I was under the belief that a process guard would protect at least the AV. Now I am a bit worried.
Thanks.
-
Techie101
Im not really sure how to do it, but im told you can "debug" the win INI file.
--lee
-
What can we do to protect our systems short of not using them anymore? :D
1) SafeHex & Brain 1.x
2) Trust that avast detects the malware as it's written to the disk and blocks it before execution
3) if that fails: you didn't use No 1) enough..
;D ;D ;)
-
you simple missing the fact that AVAST ini file is raw text file and don't have anything with active process of avast
no validation of ini done on program restart (e.g. md5 or so)
also i never said here "bad" program/script must kill avast (ie need use of process guard)
it will simple wait for next reboot ...
saying like, it will not happen, is like asking for it to happen ....
so i become now prophet and say if nobody take care about this, then it will happen ...
understood it as you want ::) ...
-
Vlk, can you answer Techie... I'm curious too...
I thought there will be a way to prevent that... Maybe the only will be use the system as a limited user but, in this case, the malware could be executed with a 'Run as' similar command :-\
Life is becoming dangerous... we're near to the Matrix ;D
-
Well, I believe Vlk stated it quite clearly...
When a malware is running under Administrator account, there is no way to prevent it from doing whatever it wants to. No antiviruses, no process-guards... nothing.
You can use tools (such as PG) to prevent some "generic" techniques... but when the malware is cleverly written (it usually isn't) and specifically targets the particular protection programs (PG, avast!, whatever...), it will win. That's the fact.
-
But please note this is not anything new: it has actually ever been so.
Linux/Unix users somehow know (count with) this and really really take care of which account they're working under. They usually use the root (=admin) account only if they really need to (such as to make some changes in the system config or install a program). Otherwise, they run under an account with limited rights (limited only to the extent that their apps work OK, of course) and this is because they somehow anticipate that something bad will happen. And if something bad really happens, running under a non-root account can mitigate the threat enormously...
Dwarden, why do you think that protection of the ini file would help? There are multiple places where avast stores its configuration. Registry keys, the ini file and the data storage (the mdb or xml file) where avast actually stores all task settings (including the on-access task). So it'd actually make more sense to tamper with the data storage than with the ini file I guess... Anyway, if the malware doesn't change any of those, it can patch any of the avast files. Same effect. And if it doesn't patch any of the files, it can remove the reference to avast from all the registry entries (preventing it to start on next boot). Same effect... Etc. etc. You see what I'm saying? There are unlimited possibilities. There's no generic way to fight with that. The only way is not to run under the admin account.
Cheers
Vlk
-
But when the malware is cleverly written (it usually isn't) ... it will win. That's the fact.
Men, I hope you never go to the dark side of the power :o
There are multiple places where avast stores its configuration. Registry keys, the ini file and the data storage (the mdb or xml file) where avast actually stores all task settings (including the on-access task).
Vlk, is there any way to 'understand' or 'edit' the mdb file?
Everytime I browse it with Access I can't figure out anything I can change, do, tweak, even understand... :'(
-
The MDB file is quite straightforward (of course, only if you open it with Access... :)).
Almost everything is in the LocalProperty table.
BTW this is becoming way too off-topic!
-
Wouldn't it be a good idea to backup the INI files and Registery keys/values so they if avast is "tamperd with" you can just put it back.
Mabey this could be done as an option when you install avast, a sort of Avast recovery.
--lee
-
yes but there is major difference between configuration stored in "raw" format and encrypted format (of course if someone decide to debug and analyse what where why, no way to win over him, but this is not that case) ...
anyway i got my own meaning about this as i already got experience with trojans which done exactly this to KPF configs (when they were in raw mode).
and in windows you not need to be in admin account to spread damage and destruction :) ...
oh well ... it was just thought ... i see i need keep using file integrity guard ...
-
anyway i got my own meaning about this as i already got experience with trojans which done exactly this to KPF configs (when they were in raw mode).
If the trojan specifically targets the program (KPF) configs, it can modify them in any case, encrypted or not - so I don't really see any difference. For encryping the configs, the encryption key has to be stored somewhere on the disk - so, the malware can simply extract the key and access the encrypted files.
(Even though as I said, I find it unnecessarily complicated - it can just delete or trash the files, or the whole program).
The only difference it could make is as a protection against "malicious user" - but not again clever malware.
-
anyway i got my own meaning about this as i already got experience with trojans which done exactly this to KPF configs (when they were in raw mode).
If the trojan specifically targets the program (KPF) configs, it can modify them in any case, encrypted or not - so I don't really see any difference. For encryping the configs, the encryption key has to be stored somewhere on the disk - so, the malware can simply extract the key and access the encrypted files.
(Even though as I said, I find it unnecessarily complicated - it can just delete or trash the files, or the whole program).
The only difference it could make is as a protection against "malicious user" - but not again clever malware.
you know it can takes exactly 10 seconds w/o any ecryption or checksum (e.g. md5 of ini to "detect" something messed with)
and i'm quite sure it will need hours - days - weeks to get your "key stored somewhere" ...
since when is no security better than some security ? especially when talking AV software ...
-
The problem with encrypted data is that they are fragile. If a single bit is changed, the whole block becomes useless.
That is, if a malware changes anything in an encrypted config blob, the configuration becomes invalid and we're toast.
Encryption is not the way in this case -- OS level protection is much better.
-
It takes 10 seconds to whom? To the program or to the author of the malware?
From the point of view of the program, it doesn't matter - both are basically the same. From the point of view of the author, yes, it may take slightly longer to program the malware (but not that much... finding the key wouldn't be very hard when the author decides what application he'll target specifically).
Additionally - what would be the hash of the ini file good for? OK, let's say we know that the file has been tampered with... but what next? The settings may be completely changed/overwritten (and we cannot restore them by the hash). The mail accounts may have been changed completely, redirected somewhere... if it's a filewall, then the list of allowed applications may be modified... are we going just to freeze the computer and not allow anything to do its work (because we don't know what is safe to allow)?
-
I agree with Igor and Vlk especially on the used account(s). As I always say to my customers: Security starts with the user, not the system.
What good is it to lock a draw in your desk when you leave the frontdoor open wide and the key of the draw hangs in the hal?