Temos um software de gerenciamento empresarial que faz conexão com a internet em alguns momentos e também tem a conexão com um equipamento externo(ECF). Nosso aplicativo é atualizado frequentemente, são 2 ou 3 atualizações por semana. Estamos tendo muitos problemas com o Avast em nossos clientes, pois muitos deles utilizam o Avast. Gostaria de saber que medidas eu poderia tomar para o meu software ser confiável perante as análises do Avast.
Quero resolver este problema, só preciso saber o que preciso fazer pra isso.
Houshi, bem vindo aos fórums e obrigado por informar esses falsos positivos.
Por favor, informe falsos positivos (detecções erradas em arquivos ou sites) aqui: https://www.avast.com/pt-br/false-positive-file-form.php
Assim que fizer, por favor, volte a postar aqui para que possamos acompanhar a análise junto ao nosso Laboratório de Ameaças.
Então cara, esse problema já foi visto por ticket em outro momento. Seguimos os passos e tudo mais, porém a cada versão do software que lançamos e mandamos as atualizações automáticas para os clientes o Avast pega como vírus e nossos clientes acabam ficando sem sistema.
Eu gostaria de saber o que fazer para ter uma solução definitiva para o meu problema. Ao invés de deixar o nosso processo de release mais burocrático. Existe algum tipo de certificação para o software que faça com o que ele seja confiável ou algo do gênero? É um software comercial. Gostaria de saber como resolver meu problema definitivamente, somente.
Houshi, eu entrei em contato com o Laboratório de Ameaças. Por favor, me cobre uma posição.
Suponho que eles vão dizer algo sobre assinatura digital dos arquivos.
Lisandro is correct. The easiest way is using a digital signature.
It would help if I knew which detections are triggering on the new files. Is is caused by having similar stucture to known malware? Does it contain similar byte sequence(s)? Does it have similar metadata? Without the file, I canot say much.
Pelo que li nos dois links acima, isto pode ocorrer se em algum momento meu software fizer o download de algum arquivo.
Acontece que na legislação das regras do PAF, existem vários arquivos considerados para a geração de um md5 ao abrir o software chamado de ISA_Pdv(Que é homologado com o PAF), precisamos garantir que quando atualizamos uma DLL, ela deve ser obrigatoriamente atualizada em nossos clientes. O processo de atualização do nosso software é o seguinte:
Ele baixa os novos executáveis em um zip,
Extrai eles com um “new.” na frente do nome do executável
Executa o executável com o “new.” e fecha a si mesmo
O executável com o “new.” copia a si mesmo para um executável sem o “new.” executa esse novo executável e se fecha.
Após abrir novamente ele faz duas coisas:
A primeira é rodar as migrações na base de dados.
A segunda é verificar se alguma das DLLs foi modificada, caso sim, é feito o download dessa nova DLL para substituir a antiga.
Acredito que o problema pode estar neste processo.
Without any example files, I really cannot say anything else. If I have the file, I can decide 1. why it was detected in the first place, 2. what is the best way to prevent something similar happening in the future.
HonzaZ, if you need the files, can i send a link to you, but i think you can’t run the application with no db, then you will not see the behavior i sayed.
One of the files, Isa_PDV.exe, was actually detected by FilerepMalware. Let me know if you still have issues, and if so, post a printscreen of the detection, that helps a lot!
Exactly, Isa_PDV has been moved to quarantine every time. Like i said up here, it downloads dll files and copy herself to the same directory with another name.
If you need can i translate the explanation of our update process to you.
I was able to find the file thanks to the data from the printscreen. It looks like the culprit was this file: 5FD8504E2FC351570EA9112B737D180CDED479A2A6C6D219A9FECB3D130A0D3D.
This file was whitelisted 13.2., so it shouldn’t happen anymore (the printscreen is from 10.)
Could you try again and check if you still have the same issue?
But we release more then once every week. New files be detected. This file has been whitelisted, but the new ones no! If we release a new emergency version and update our customer, the file can be deleted by Avast.
Put a single file in a whitelist does not solve my problem. I want identify what i need to do, i want solve my problem definitely.
I haven’t used a digsig myself yet, so I cannot be of much help with signing But I do know that we can then whitelist the signature, which will make all behav shield detections, as well as most other detections, go away.
FileRepMalware means that the exact file (based on sha256) was classified as malicious. Now that might have been becuase of behav shield detection previously, or because of many different reasons. If you paste the SHA here (or if you upload the file to virustotal, which also computes the hash, and post the result link here), I can tell you why it was blocked and whitelist it.
Whitelisted the file (8F789AABCDBE2A56977883188991066E28C62484E8DFF855F87290185AECC0F1), so it will not be detected any more
Added isaerp.com.br to clean cybercapture class, meaning all files should be classified as clean when they go to cybercapture
Found that there is a detection (Sf:GenMalicious-C [Trj]) on the file when it is executed in sandbox, so I contacted the author of the detection for it to be altrered (if possible)
Hopefully these steps can prevent some of the false positives, but digitally signing the files is still considered the safest bet
It is not as strong as I (might have) made it sound, which is why I also said that it might only prevent “some” of the FPs and that digsig is still the preferred way.
Firstly, this rule I made could only trigger on files that go to cybercapture. This means that it must be a PE file that is downloaded from a certain domain, and the user who downloads it must be the very first person in the world (with Avast) to execute it, and there must be no detection on the file yet. If the file is non-PE (HTML, JS, PDF), or if it is known (prevalence > 1), or if the file is similar to other malware (so the detections, such as trojangens or evogens would trigger), it would not go to cybercapture at all.
Secondly, even within cybercapture there are many (what we call) boxes, which each tests one thing. One might check the URL, one might run the sample in sandbox, one might check similarity to other files, you get the idea. These boxes all produce results (clean, unknown, malware) and based on these results, Decision Maker decides. Even with some boxes reporting “clean”, cybercapture might still say “do not allow this program to run”.
I hope I made myself clear that there is very little security risk when I add the URL to clean class If not, I will be happy to elaborate, ask away! 8)
But I do know that we can then whitelist the signature, which will make all behav shield detections, as well as most other detections, go away.