A l'heure actuelle, il existe a ma connaissance deux technologies
permettant de detecter "heuristiquement" un virus comme Swen (en excluant
celles propres aux firewalls personnels et consistant a signaler une
tentative de connection sortante non autorisee).
La premiere, concue (il me semble) par HP et employee par McAffee
(derniere vesion) consiste a considerer comme suspect tout envoi de mail
dont le rythme serait trop eleve' (et/ou toute autre activite' reseau
"agressive", comme la connection sur des partages reseaux non proteges).
Il s'agit d'une methode de detection a-posteriori ayant pour principal
objectif de limiter l'ampleur de l'epidemie.A vrai dire, je ne sais pas si
McAffee alerte l'utilisateur ou se contente de "freiner" l'envoi.
La deuxieme consiste a emuler le code et a detecter un comportement
viral : entre l'arret force' des AV/FW persos, la modification du script
de lancement de mirc, l'envoi d'emails en masse, l'ecriture de la clef
"Run" de la base de registre ou encore la propagation via les partages
reseaux non proteges la "signature comportementale" de swen est plutot
chargee.
C'est justement le point commun aux deux techniques : la detection se
base sur le comportement, pas sur le code. Je peux me tromper, mais il
me semble que la detection heuristique d'un vers comme Swen ecrit en HLL
en se basant uniquement sur l'analyse du code de celui-ci doit etre tres
delicate.
Norman VC, qui utilise la deuxieme de ces technologies detectait Swen
heuristiquement (en tant que W32/P2PWorm) avant que celui-ci ne soit
ajoute' a la base de signature (j'ai fait le test en retardant
volontairement la m-a-j des signatures).
Je me demandais donc quels autres AVs detectaient heuristiquement Swen
avant que celui-ci ne soi ajoute' a leur base de signatures. Je parle
ici d'une detection autre que celle de la faille IFrame, qui n'est de
toute facon utilisee que par une partie des exemplaires du worm.
Votre AV detectait-il Swen avant que celui-ci ne soit ajoute' a la base
de signatures ?
Votre AV detectait-il Swen avant que celui-ci ne soit ajoute' a la base de signatures ?
J'avais donné quelques éléments ici: news:
KAV et F-Prot: rien VirusScan: Found virus or variant New Worm !!!
-- joke0
Frederic Bonroy
Tweakie wrote:
La deuxieme consiste a emuler le code et a detecter un comportement viral : entre l'arret force' des AV/FW persos, la modification du script de lancement de mirc, l'envoi d'emails en masse, l'ecriture de la clef "Run" de la base de registre ou encore la propagation via les partages reseaux non proteges la "signature comportementale" de swen est plutot chargee.
C'est justement le point commun aux deux techniques : la detection se base sur le comportement, pas sur le code. Je peux me tromper, mais il me semble que la detection heuristique d'un vers comme Swen ecrit en HLL en se basant uniquement sur l'analyse du code de celui-ci doit etre tres delicate.
Oui, pour la raison suivante certainement: les compilateurs génèrent beaucoup de code supplémentaire (bibliothèques et tout le bazar), et leur code en général n'est pas aussi condensé que le code écrit en assembleur qui contient juste les instructions pertinentes - selon les compétences du programmeur. .-) Cela fait que le programme HLL est plus long à émuler, et ce n'est pas évident de réduire de longues séquences de code à un comportement particulier.
Norman VC, qui utilise la deuxieme de ces technologies detectait Swen heuristiquement (en tant que W32/P2PWorm) avant que celui-ci ne soit ajoute' a la base de signature (j'ai fait le test en retardant volontairement la m-a-j des signatures).
Je ne sais pas comment cette détection a lieu, mais ce n'est pas forcément une émulation de code. Une recherche de mots-clé (pas toujours élégante, il est vrai) peut éventuellement permettre la détection.
Tweakie wrote:
La deuxieme consiste a emuler le code et a detecter un comportement
viral : entre l'arret force' des AV/FW persos, la modification du script
de lancement de mirc, l'envoi d'emails en masse, l'ecriture de la clef
"Run" de la base de registre ou encore la propagation via les partages
reseaux non proteges la "signature comportementale" de swen est plutot
chargee.
C'est justement le point commun aux deux techniques : la detection se
base sur le comportement, pas sur le code. Je peux me tromper, mais il
me semble que la detection heuristique d'un vers comme Swen ecrit en HLL
en se basant uniquement sur l'analyse du code de celui-ci doit etre tres
delicate.
Oui, pour la raison suivante certainement: les compilateurs génèrent
beaucoup de code supplémentaire (bibliothèques et tout le bazar), et
leur code en général n'est pas aussi condensé que le code écrit en
assembleur qui contient juste les instructions pertinentes - selon les
compétences du programmeur. .-)
Cela fait que le programme HLL est plus long à émuler, et ce n'est pas
évident de réduire de longues séquences de code à un comportement
particulier.
Norman VC, qui utilise la deuxieme de ces technologies detectait Swen
heuristiquement (en tant que W32/P2PWorm) avant que celui-ci ne soit
ajoute' a la base de signature (j'ai fait le test en retardant
volontairement la m-a-j des signatures).
Je ne sais pas comment cette détection a lieu, mais ce n'est pas
forcément une émulation de code. Une recherche de mots-clé (pas
toujours élégante, il est vrai) peut éventuellement permettre la
détection.
La deuxieme consiste a emuler le code et a detecter un comportement viral : entre l'arret force' des AV/FW persos, la modification du script de lancement de mirc, l'envoi d'emails en masse, l'ecriture de la clef "Run" de la base de registre ou encore la propagation via les partages reseaux non proteges la "signature comportementale" de swen est plutot chargee.
C'est justement le point commun aux deux techniques : la detection se base sur le comportement, pas sur le code. Je peux me tromper, mais il me semble que la detection heuristique d'un vers comme Swen ecrit en HLL en se basant uniquement sur l'analyse du code de celui-ci doit etre tres delicate.
Oui, pour la raison suivante certainement: les compilateurs génèrent beaucoup de code supplémentaire (bibliothèques et tout le bazar), et leur code en général n'est pas aussi condensé que le code écrit en assembleur qui contient juste les instructions pertinentes - selon les compétences du programmeur. .-) Cela fait que le programme HLL est plus long à émuler, et ce n'est pas évident de réduire de longues séquences de code à un comportement particulier.
Norman VC, qui utilise la deuxieme de ces technologies detectait Swen heuristiquement (en tant que W32/P2PWorm) avant que celui-ci ne soit ajoute' a la base de signature (j'ai fait le test en retardant volontairement la m-a-j des signatures).
Je ne sais pas comment cette détection a lieu, mais ce n'est pas forcément une émulation de code. Une recherche de mots-clé (pas toujours élégante, il est vrai) peut éventuellement permettre la détection.
Tweakie
On Sun, 21 Sep 2003, joke0 wrote:
J'avais donné quelques éléments ici: news:
Ah, merci, j'avais loupe' ce message aussi. Il faut dire que fcsv est plus prolifique que jamais...
KAV et F-Prot: rien VirusScan: Found virus or variant New Worm !!!
J'avais condamne' VirusScan apres une tentative avortee d'instalation catastrophique (jamais su pourquoi, sur un Win2k tout ce qu'il y a de plus normal) mais je sens que je vais reessayer un de ces jours...
Ils ont deja publie' des docs techniques sur le fonctionnement de leur AV chez NAI, ou ils sont aussi discrets que la concurence ?
-- Tweakie
On Sun, 21 Sep 2003, joke0 wrote:
J'avais donné quelques éléments ici:
news:XnF93FAC583880A74164N@joke0.net
Ah, merci, j'avais loupe' ce message aussi. Il faut dire que fcsv est plus
prolifique que jamais...
KAV et F-Prot: rien
VirusScan: Found virus or variant New Worm !!!
J'avais condamne' VirusScan apres une tentative avortee d'instalation
catastrophique (jamais su pourquoi, sur un Win2k tout ce qu'il y a de
plus normal) mais je sens que je vais reessayer un de ces jours...
Ils ont deja publie' des docs techniques sur le fonctionnement de
leur AV chez NAI, ou ils sont aussi discrets que la concurence ?
Ah, merci, j'avais loupe' ce message aussi. Il faut dire que fcsv est plus prolifique que jamais...
KAV et F-Prot: rien VirusScan: Found virus or variant New Worm !!!
J'avais condamne' VirusScan apres une tentative avortee d'instalation catastrophique (jamais su pourquoi, sur un Win2k tout ce qu'il y a de plus normal) mais je sens que je vais reessayer un de ces jours...
Ils ont deja publie' des docs techniques sur le fonctionnement de leur AV chez NAI, ou ils sont aussi discrets que la concurence ?
-- Tweakie
Misterjack
Salut !
Je ne sais pas comment cette détection a lieu, mais ce n'est pas forcément une émulation de code. Une recherche de mots-clé (pas toujours élégante, il est vrai) peut éventuellement permettre la détection.
Swen a une base MS Visual C++ et il n'est pas encrypté. Il est extrêmement simple de deviner ses mauvaises intentions avec un risque d'erreur très faible. Même la simple recherche de mots-clé que vous citez peut avoir un résultat tout à fait honorable avec Swen.
@+ MJ
Salut !
Je ne sais pas comment cette détection a lieu, mais ce n'est pas
forcément une émulation de code. Une recherche de mots-clé (pas
toujours élégante, il est vrai) peut éventuellement permettre la
détection.
Swen a une base MS Visual C++ et il n'est pas encrypté.
Il est extrêmement simple de deviner ses mauvaises intentions avec un
risque d'erreur très faible.
Même la simple recherche de mots-clé que vous citez peut avoir un
résultat tout à fait honorable avec Swen.
Je ne sais pas comment cette détection a lieu, mais ce n'est pas forcément une émulation de code. Une recherche de mots-clé (pas toujours élégante, il est vrai) peut éventuellement permettre la détection.
Swen a une base MS Visual C++ et il n'est pas encrypté. Il est extrêmement simple de deviner ses mauvaises intentions avec un risque d'erreur très faible. Même la simple recherche de mots-clé que vous citez peut avoir un résultat tout à fait honorable avec Swen.
@+ MJ
joke0
Salut,
Tweakie:
Ils ont deja publie' des docs techniques sur le fonctionnement de leur AV chez NAI, ou ils sont aussi discrets que la concurence ?
Je serais bien en peine de t'aider, j'utilise la version DOS de VirusScan.
-- joke0
Salut,
Tweakie:
Ils ont deja publie' des docs techniques sur le fonctionnement
de leur AV chez NAI, ou ils sont aussi discrets que la
concurence ?
Je serais bien en peine de t'aider, j'utilise la version DOS de
VirusScan.
Ils ont deja publie' des docs techniques sur le fonctionnement de leur AV chez NAI, ou ils sont aussi discrets que la concurence ?
Je serais bien en peine de t'aider, j'utilise la version DOS de VirusScan.
-- joke0
Tweakie
On Sun, 21 Sep 2003, Frederic Bonroy wrote:
Je ne sais pas comment cette détection a lieu, mais ce n'est pas forcément une émulation de code. Une recherche de mots-clé (pas toujours élégante, il est vrai) peut éventuellement permettre la détection.
Si on en croit Kurt Natvig, le responsable du projet (et j'aurais plutot tendance a le croire), c'est effectivement une emulation du code. Il avance dans ce document :
un nombre d' 1M instrictions/s emulees sur un PIII 700. Je ne sais pas si on peut en deduire que l'emulation est a peu pres 700 fois plus lente que l'execution (j'ai lu sur une doc que sur un PIII 750, on avait entre 650 et 800 MIPS pour un prog. standard, because of course ca depend des instructions utilisees).
Par ailleurs, dans ses articles, il n'entre pas dans le detail des elements qui forment un "comportement viral", mais il m'a ecrit qu'il y avait dans sa sandbox un ensemble de "bait processes" aux caracteristiques (nome, etc.) qui, s'ils etaient arretes par le programme teste', declenchaient la classification du programme en Win32/Malware (ce qui etait par ailleurs exactement ce que je lui suggerais de faire*...comme quoi j'aurais mieux fait de poser la question avant :-/ ).
-- Tweakie
* Ne pas en conclure hativement que je serais "lie a un quelconque editeur/distributeur d'AV" ;-)
On Sun, 21 Sep 2003, Frederic Bonroy wrote:
Je ne sais pas comment cette détection a lieu, mais ce n'est pas
forcément une émulation de code. Une recherche de mots-clé (pas
toujours élégante, il est vrai) peut éventuellement permettre la
détection.
Si on en croit Kurt Natvig, le responsable du projet (et j'aurais plutot
tendance a le croire), c'est effectivement une emulation du code. Il
avance dans ce document :
un nombre d' 1M instrictions/s emulees sur un PIII 700. Je ne sais
pas si on peut en deduire que l'emulation est a peu pres 700 fois
plus lente que l'execution (j'ai lu sur une doc que sur un PIII 750,
on avait entre 650 et 800 MIPS pour un prog. standard, because of
course ca depend des instructions utilisees).
Par ailleurs, dans ses articles, il n'entre pas dans le detail
des elements qui forment un "comportement viral", mais il m'a ecrit
qu'il y avait dans sa sandbox un ensemble de "bait processes" aux
caracteristiques (nome, etc.) qui, s'ils etaient arretes par le
programme teste', declenchaient la classification du programme en
Win32/Malware (ce qui etait par ailleurs exactement ce que je lui
suggerais de faire*...comme quoi j'aurais mieux fait de poser la
question avant :-/ ).
-- Tweakie
* Ne pas en conclure hativement que je serais "lie a un quelconque
editeur/distributeur d'AV" ;-)
Je ne sais pas comment cette détection a lieu, mais ce n'est pas forcément une émulation de code. Une recherche de mots-clé (pas toujours élégante, il est vrai) peut éventuellement permettre la détection.
Si on en croit Kurt Natvig, le responsable du projet (et j'aurais plutot tendance a le croire), c'est effectivement une emulation du code. Il avance dans ce document :
un nombre d' 1M instrictions/s emulees sur un PIII 700. Je ne sais pas si on peut en deduire que l'emulation est a peu pres 700 fois plus lente que l'execution (j'ai lu sur une doc que sur un PIII 750, on avait entre 650 et 800 MIPS pour un prog. standard, because of course ca depend des instructions utilisees).
Par ailleurs, dans ses articles, il n'entre pas dans le detail des elements qui forment un "comportement viral", mais il m'a ecrit qu'il y avait dans sa sandbox un ensemble de "bait processes" aux caracteristiques (nome, etc.) qui, s'ils etaient arretes par le programme teste', declenchaient la classification du programme en Win32/Malware (ce qui etait par ailleurs exactement ce que je lui suggerais de faire*...comme quoi j'aurais mieux fait de poser la question avant :-/ ).
-- Tweakie
* Ne pas en conclure hativement que je serais "lie a un quelconque editeur/distributeur d'AV" ;-)
Frederic Bonroy
Tweakie wrote:
Si on en croit Kurt Natvig, le responsable du projet (et j'aurais plutot tendance a le croire), c'est effectivement une emulation du code. Il avance dans ce document :
un nombre d' 1M instrictions/s emulees sur un PIII 700. Je ne sais pas si on peut en deduire que l'emulation est a peu pres 700 fois plus lente que l'execution
Le seul chiffre que je connais est celui de 100 000 instructions/seconde sur un Pentium 100 et ça concerne AVG. Donc ici, l'émulation est 1000 fois plus lente. Reste à savoir si un Pentium III est 1,4 fois plus rapide qu'un Pentium à cadence égale (en théorie). Et puis ça dépend aussi de qualité de l'émulateur, on ne peut donc en fait pas comparer.
(j'ai lu sur une doc que sur un PIII 750, on avait entre 650 et 800 MIPS pour un prog. standard, because of course ca depend des instructions utilisees).
C'est clair que ça dépend des instructions. Je dois avouer que je ne sais pas combien d'instructions un Pentium III exécute en moyenne par seconde, mais ces chiffres ne me semblent être assez réalistes. Ça fait longtemps que n'ai plus joué avec cela, mais il y a un maximum théorique de 3 instructions simples que le Pentium III peut décoder à la fois, ou une seule instruction complexe - ou bien était-ce une complexe et deux simples à la fois? Je m'y perds. Faudrait faire des tests.
Tweakie wrote:
Si on en croit Kurt Natvig, le responsable du projet (et j'aurais plutot
tendance a le croire), c'est effectivement une emulation du code. Il
avance dans ce document :
un nombre d' 1M instrictions/s emulees sur un PIII 700. Je ne sais
pas si on peut en deduire que l'emulation est a peu pres 700 fois
plus lente que l'execution
Le seul chiffre que je connais est celui de 100 000 instructions/seconde
sur un Pentium 100 et ça concerne AVG. Donc ici, l'émulation est 1000
fois plus lente. Reste à savoir si un Pentium III est 1,4 fois plus
rapide qu'un Pentium à cadence égale (en théorie). Et puis ça dépend
aussi de qualité de l'émulateur, on ne peut donc en fait pas comparer.
(j'ai lu sur une doc que sur un PIII 750, on avait entre 650 et 800
MIPS pour un prog. standard, because of course ca depend des
instructions utilisees).
C'est clair que ça dépend des instructions. Je dois avouer que je
ne sais pas combien d'instructions un Pentium III exécute en moyenne
par seconde, mais ces chiffres ne me semblent être assez réalistes.
Ça fait longtemps que n'ai plus joué avec cela, mais il y a un maximum
théorique de 3 instructions simples que le Pentium III peut décoder
à la fois, ou une seule instruction complexe - ou bien était-ce une
complexe et deux simples à la fois? Je m'y perds.
Faudrait faire des tests.
Si on en croit Kurt Natvig, le responsable du projet (et j'aurais plutot tendance a le croire), c'est effectivement une emulation du code. Il avance dans ce document :
un nombre d' 1M instrictions/s emulees sur un PIII 700. Je ne sais pas si on peut en deduire que l'emulation est a peu pres 700 fois plus lente que l'execution
Le seul chiffre que je connais est celui de 100 000 instructions/seconde sur un Pentium 100 et ça concerne AVG. Donc ici, l'émulation est 1000 fois plus lente. Reste à savoir si un Pentium III est 1,4 fois plus rapide qu'un Pentium à cadence égale (en théorie). Et puis ça dépend aussi de qualité de l'émulateur, on ne peut donc en fait pas comparer.
(j'ai lu sur une doc que sur un PIII 750, on avait entre 650 et 800 MIPS pour un prog. standard, because of course ca depend des instructions utilisees).
C'est clair que ça dépend des instructions. Je dois avouer que je ne sais pas combien d'instructions un Pentium III exécute en moyenne par seconde, mais ces chiffres ne me semblent être assez réalistes. Ça fait longtemps que n'ai plus joué avec cela, mais il y a un maximum théorique de 3 instructions simples que le Pentium III peut décoder à la fois, ou une seule instruction complexe - ou bien était-ce une complexe et deux simples à la fois? Je m'y perds. Faudrait faire des tests.
