Infecte, mais je ne sais pas quoi faire...

AMcD® wrote:

Moi, je ne suis pas si "opimiste" que vous pour le futur. C'est surtout une
question de compétence technique, de temps, d'argent, etc.

Bof. Il me semble que le code de Sasser ne t'a pas emballé, et regarde
le succès qu'il a eu. Regarde aussi un peu les bestioles les plus
répandues. Quel est leur intérêt technique? Il n'y en a pas. Je ne veux
pas dire par là qu'elles sont mal programmées, simplement qu'il n'y a
rien de vraiment exceptionnel.

En fait, pour camoufler, beaucoup d'auteurs de virus passent par les
AsPack et companie, c'est plus simple que de manipuler les instructions
assembleur une par une. Et comme certains antivirus ne sont pas très
doués pour déballer les exécutables protégés ainsi, je pense avoir
compris que c'était le cas notamment de NOD32 et de Norton, ben nul
besoin de passer des nuits blanches sur un moteur métamorphique.

"LaDDL" <alamaison-MOVEOUT@HIt-THE-DIRTnoos.fr> a écrit dans le message
news: 40ab3a2c$0$2144$79c14f64@nan-newsreader-04.noos.net

C'est contradictoire ce que vous dites, enfin. :-( En haut vous dites
être d'accord sur le fait que l'analyse spectrale est une forme
d'heuristique et maintenant vous dites que ce sont deux analyseurs
distinct.
Au plan théorique nous sommes d'accord spectral & heuristique c'est

pareil.

ben non... même pas, vous n'êtes pas d'accord
(c'est sûrement pour cette raison que ce fil se développe encore)

t'es toujours d'accord avec tout, mais ça ne t'empêche de continuer à écrire
des conneries

FB te dit ==> heuristique (émulation, analyse spectrale, ...)
et toi tu maintiens ==> heuristique & analyse spectrale c'est pareil

techniquement, l'analyse spectrale n'est qu'un outil de plus dans la
panoplie "heuristique"

je ne parle pas des tests AV ni des autres conneries proférées à propos de
l'impérative nécessité d'utiliser un AV heuristique (c'est quoi ?) + FW +
contrôleur machin +...

vive le safe-hex :-p

@tchao
--
FAQ du forum fr.comp.securite.virus :
http://www.lacave.net/~jokeuse/usenet/faq-fcsv.html

Frederic Bonroy wrote:

AMcD® wrote:

Bof. Il me semble que le code de Sasser ne t'a pas emballé, et regarde
le succès qu'il a eu. Regarde aussi un peu les bestioles les plus
répandues. Quel est leur intérêt technique? Il n'y en a pas. Je ne
veux
pas dire par là qu'elles sont mal programmées, simplement qu'il n'y a
rien de vraiment exceptionnel.

Je ne parle pas de Sasser. Ni des principaux virus actuels. Je dis qu'il est
largement possible de nos jours de faire se dresser les cheveux aux AVs, pas
que c'est encore afit ou diffusé ;o).

En fait, pour camoufler, beaucoup d'auteurs de virus passent par les
AsPack et companie, c'est plus simple que de manipuler les
instructions assembleur une par une.

Eh ben ? C'est ce que je t'explique ! Obfuscation, packing exotique, EPO,
patching, polymorphisme et autres joyeusetés et boum, dans la choucroute les
AVs...

Et comme certains antivirus ne
sont pas très
doués pour déballer les exécutables protégés ainsi,

C'est ce que je te dis, pas fut-fut les AVs...

je pense avoir
compris que c'était le cas notamment de NOD32 et de Norton, ben nul
besoin de passer des nuits blanches sur un moteur métamorphique.

Lol. Faut quand même bien que quelqu'un les écrive à un moment donné les
moteurs, packers, etc.

--
AMcD®

http://arnold.mcdonald.free.fr/

AMcD® wrote:

LaDDL wrote:

Techniquement l'algorithme employé va permettre d'étudier s'il existe
des fréquences d'apparition et d'interrelation liées aux instructions.

Pfff, c'est du vent ça, du blabla. T'as pas un peu plus "précis" comme
explication ?
Prends le cas d'un virus polymorphe. Et checkes tes favoris ou documents

tu trouveras bien une analyse.
T'es quand même pas en train de vouloir me demander de t'expliquer les
algorithmes employés par les AV. Tu connais le cadre légal non ?

Et ce qui fait la différence entre certains AV heuristique c'est leur
taux de faux positifs.

En fait, le problème c'est que tu parles beaucoup sans être précis ou que tu
produit des poncifs sans grande information technique précise. C'est pour
ça, je pense, que t'as pas mal de "retour" :o).
Je prends note de ce que tu me dis. Mais ça n'est pas la seule raison.

Autrement, je ne vois pas de poncifs dans mes échanges. Les explications
sont claires. Autrement il suffit de demander des cas concrets et dans
ce cas je renverrai vers des exemples il n'en manque pas. Il est
pourtant simple de se représenter l'exemple d'un virus polymorphe.

Au risque de me répéter le code des AV est protégé par le droit à la
propriété intellectuelle donc dilvuguer des informations de ce type
serait vraiment malvenu.

AMcD® wrote:

Je ne parle pas de Sasser. Ni des principaux virus actuels. Je dis qu'il est
largement possible de nos jours de faire se dresser les cheveux aux AVs, pas
que c'est encore afit ou diffusé ;o).

Bien sûr que c'est possible. Les ZMist, Prizzy, Crypto etc. l'ont prouvé.

En fait, pour camoufler, beaucoup d'auteurs de virus passent par les
AsPack et companie, c'est plus simple que de manipuler les
instructions assembleur une par une.

Eh ben ? C'est ce que je t'explique ! Obfuscation, packing exotique, EPO,
patching, polymorphisme et autres joyeusetés et boum, dans la choucroute les
AVs...

Je ne sais pas si un antivirus a besoin d'émuler pour déballer un
exécutable comprimé avec AsPack ou autre. Je suppose que non. Il doit
pouvoir appliquer un algorithme de décompression. Et ça c'est plus
facile à faire que d'analyser des séquences de code.

JacK wrote:

sur les news:40ab47a2$0$4251$79c14f64@nan-newsreader-04.noos.net
LaDDL <alamaison-MOVEOUT@HIt-THE-DIRTnoos.fr> signalait:

Frederic Bonroy wrote:
[..]

Comme je vous l'ai dit aujourd'hui dans l'un de mes posts, je n'ai
fait que dire que je reprochais aux tests de l'uni de Magdeburg de ne
pas étudier tous les AVs. Je n'ai rien ajouté de plus.
Ces tests sont réalisés avec l'accord du Dev où ils ne sont pas faits (ou du

moins publiés...)
Bjr, je te le confirme.

Je doute qu'ESET autorise à nouveau A. Marx à tester leurs
produits
Ils se sont expliqués. L'avenir nous le dira.

ou que TEGAM accepte un jour d'être testé par un organisme
indépendant :o)
C'est une autre histoire. Si tu veux bien ne dérivons pas. Et surtout

pas là-dessus. Merci.

AMcD® wrote:

Et c'est quoi une instruction "anormale" ? À ce compte là, tous mes softs
sont detectés comme des virus...

Petit extrait du code de Spaces.

0040A019 0F014D 00 sidt fword ptr ss:[ebp]
0040A01D 8B6D 02 mov ebp, dword ptr ss:[ebp+2]
0040A020 83C5 20 add ebp, 20
0040A023 FA cli
[...]
0040A054 FB sti
[...]
0040A05F 66:B8 2020 mov ax, 2020
0040A063 CD20 00004000 vxdcall IFSMGR_Get_Version
0040A069 66:3D ADDE cmp ax, 0DEAD
0040A06D 74 6D je short SPACES.0040A0DC


Tu en vois beaucoup, des sidt, cli, sti dans les programmes normaux?
Quant à vxdcall, je ne me suis jamais occupé de savoir ce que cela
faisait exactement, mais j'ai aussi rarement vu ça.

De toute façon il ne s'agit pas de gueuler pour un malheureux cli. Mais
quand on a plusieurs telles instructions et ce dans un espace "confiné"
alors on peut commencer à se poser des questions sur la nature du programme.

LaDDL <alamaison-MOVEOUT@HIt-THE-DIRTnoos.fr> signalait:

Frederic Bonroy wrote:
[..]

Comme je vous l'ai dit aujourd'hui dans l'un de mes posts, je n'ai
fait que dire que je reprochais aux tests de l'uni de Magdeburg de ne
pas étudier tous les AVs. Je n'ai rien ajouté de plus.
Ces tests sont réalisés avec l'accord du Dev où ils ne sont pas faits (ou

du

moins publiés...)
Bjr, je te le confirme.

Je doute qu'ESET autorise à nouveau A. Marx à tester leurs
produits
Ils se sont expliqués. L'avenir nous le dira.

Andreas, Antoon et Rodzilla sont des correspondants perso. On ne peut pas
parler d'explications mais plutôt d'échange d'insultes et/ou menaces :)

Pas avant le prochain millénaire pour un test ESET par Adreas et/ou l'Unif
de Magdeburg :o)
--
JacK

Un Trojan exploite une/des vulnérabilités pour s'installer sur le
système de la victime. Une fois installé c'est clair il agit point
barre.

A condition de considérer l'utilisateur comme une "vulnérabilité" alors
oui...
L'homme est par définition vulnérable. Devant un système c'est pareil.

Oui en effet. Mais ranger l'utilisateur au rang de vulnérabilité me parait
un peu excessif.

, et les pare-feu ne peuvent rien
faire contre.
Ca dépend du type d'attaques par Trojan.

La on parle de la personne qui va télécharger un programme sur un site
quelconque pour une raison quelconque et qui va l'exécuter sur son poste.
Résultat. Un trojan qui lui formate son disque dur.

Non on parle des attaques par Trojan en général et pas d'un type en
particulier ou d'une attaque passive via un serveur hostile.

Voir news:2gv4rhF7bcg6U2@uni-berlin.de et ta réponse.

dont je cite la partie sur laquelle ce fil a pris naissance
"Un cheval de Troie qui formate le disque dur n'exploite aucune
vulnérabilité dans quoi que ce soit, et les pare-feu ne peuvent rien
faire contre."

Ma réponse était basée sur le fait que ta réponse ignorait le cas
particulier donné par Frédéric pour généraliser au niveau trojan. Et donc
de sortir de la partie spécifique : le firewall ne sert a rien dans le cas
d'un trojan qui formate le disque dur. Ce qui permet a l'utilisateur de
voir les failles dans sa sécurité. Si il pense que son firewall suffit
alors son firewall est inutile car l'erreur viendra de son comportement à
lui qui se croira protégé.

Le firewall n'a *rien* pu faire pour l'empecher. La seule chose qui aurait
pu c'est un antivirus qui aurait la signature du programme dans sa base ou
qui arriverait a le détecter par heuristique.
Pour contrer ce mode d'attaque il y a bien entendu un AV heuristique

mais aussi un contrôleur d'intégrité de la BDR que certains appellent
ici bloqueur.

Le terme bloquer définit un programme qui possède une liste finir
d'application autorisée a se lancer. Le controle de la base de registre
n'est plus du blocage mais un bonus.

Mais sur ce point la
particulier. Avec ou sans firewall le résultat est le *même*.

Sur cet exemple oui si tu parles du user connecté chez lui et qui ne
dispose pas des autres contre-mesures (AV heuristique + contrôleur
d'inteégrité de la BDR/bloqueur)

Déjà l'heuristique des antivirus c'est pas un truc optimal... le controleur
d'intégrité tant que l'intégrité du fichier bouge pas il dira rien et le
controleur de BDR il verra rien non plus. Donc meme avec tes autres
contremesure j'estime que je trojan a de bonne chance de passer et de virer
le disque. Pour les autres types de trojans ca les arrêteras.

Et il existe
de nombreux cas ou ca aurait été pareil.

Tous les scénarios sont envisageables.

C'est l'éternelle lutte mal contre bien.

Ce n'était pas le propos. Une bonne sécurité s'appuie sur une protection
multi-niveau.

Non. Une bonne sécurité s'appuye sur un utilisateur averti des risques et
qui, a partir de ce moment la, utilise des outils adaptés a ce qu'il veut.
Prendre la question sécurité au niveau des outils est le meilleur moyen de
se casser la gueule. Jamais un outil ne garantira une sécurité a 100% et il
suffit de peu de choses pour que la situation devienne critique.

L'analyse des flux peut fournir beaucoup d'informations.

mais trop tard... quand le mal est déjà fait.

Avant que le mal n'arrive comme tu l'as souligné un AV heuristique peut
remplir cette fonction pour détecter du code hostile sur une page html
ou dans une url. Mais pas toujours. C'est pourquoi il faut
contrôler/gérer les entrées/sorties dans la BDR ainsi que le flux
http/https.

Le controle de la BDR a partir du moment ou ce que le trojan veut faire
c'est effacer des fichiers ou lire directement dans d'autres (voir meme
lire la BDR) ca ne servira a rien. Commencer a gérer des droits de lecture
ecriture a un fichier en fonction du programme qui en fait la demande c'est
pas gérable.

Quand au flux http... a partir du moment ou c'est toi qui initie le
téléchargement... ca reste du domaine de l'antivirus. Le firewall n'est pas
concu pour analyser un flux. Il est concu pour bloquer ou autoriser des
connections sur base de critères. Le filtrage des flux se situe au niveau
de l'IDS qui est un autre aspect de la sécurité.

Sinon le flux HTTPS ... si tu veux l'analyser ca veut dire que ca doit se
faire par le programme qui établit la connexion... puisque ce qui arrive
au niveau du firewall est déjà illisible.

--
Noshi

djehuti wrote:

"LaDDL" <alamaison-MOVEOUT@HIt-THE-DIRTnoos.fr> a écrit dans le message
news: 40ab3a2c$0$2144$79c14f64@nan-newsreader-04.noos.net

C'est contradictoire ce que vous dites, enfin. :-( En haut vous dites
être d'accord sur le fait que l'analyse spectrale est une forme
d'heuristique et maintenant vous dites que ce sont deux analyseurs
distinct.
Au plan théorique nous sommes d'accord spectral & heuristique c'est

pareil.

ben non... même pas, vous n'êtes pas d'accord
Il semble que si dorénavant.

(c'est sûrement pour cette raison que ce fil se développe encore)
Ca n'est pas la seule raison (et tu en as la réponse)

t'es toujours d'accord avec tout, mais ça ne t'empêche de continuer à écrire
des conneries
Encore des mensonges. Tu peux pas changer de disque.

FB te dit ==> heuristique (émulation, analyse spectrale, ...)
et toi tu maintiens ==> heuristique & analyse spectrale c'est pareil
Oui.

Tu interprêtes très mal ce qu tu lis.

techniquement, l'analyse spectrale n'est qu'un outil de plus dans la
panoplie "heuristique"
C'est ce que j'ai expliqué.

je ne parle pas des tests AV ni des autres conneries proférées à propos de
l'impérative nécessité d'utiliser un AV heuristique (c'est quoi ?) + FW +
contrôleur machin +...
Décidemment tu t'enfonces dans ta propre bêtise.

vive le safe-hex :-p
C'est pas nouveau et il s'accompagne de la mise en oeuvre d'outils de

protection tels que ceux cités précédemment. La sécurité se gère. On
appelle ça aussi de l'administration/optimisation.
Qui au fait me parlait de l'emploi "abusif" d'anglicismes ?!
Commencez par franciser ce terme - safe hex - au lieu de l'employer à
tout va. IMHO cela évitera aux utilisateurs débutants d'être rébutés par
un terme non explicite.