Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Kaspersky decouvre un virus "fileless" qui s'installe dans la RAM
Et désactive le contrôle des accès utilisateurs de Windows

Le , par MiaowZedong

20PARTAGES

4  0 
Suite aux indications d’un chercheur indépendant qui « souhaite garder l’anonymat », le laboratoire Kaspersky a découvert un nouveau virus. Celui-ci se propageait via les annonces du réseau publicitaire Russe AdFox.ru, présentes sur des sites d’informations populaires.

Ce qui rend ce virus particulier est son mode opératoire. Si l’inclusion d’une iFrame renvoyant vers un site contenant du code malicieux (hébergé sur un site .eu) est classique, la stratégie d’exploitation utilisée est par contre rarissime. Le virus utilise une vulnérabilité critique de la machine virtuelle Java (CVE-2011-3544, pour laquelle il existe un patch depuis six mois) ; mais contrairement aux autres attaques sur cette faille, très populaire parmi les crackers, le virus ne s’installe pas sur le disque dur.

Au lieu de cela, le virus injecte directement en mémoire une DLL cryptée dans le processus javaw.exe. Cette stratégie le rend plus résistant aux antivirus, qui scannent les disques durs, les disques amovibles et souvent les connexions réseau, mais pas la RAM. De plus, le processus javaw.exe bénéficie habituellement de la confiance de l’antivirus et de l’utilisateur, ainsi que des pleins privilèges.


Le virus s'injecte dans la mémoire du processus javaw.exe avec toutes les permissions

Cela permet au virus de désactiver le contrôle des accès utilisateurs sur les postes Windows puis de se connecter sur le serveur des cybercriminels. Par la suite, celui-ci installe à distance le trojan Lurk. Détail important : c’est la logique du serveur qui installe le trojan. Le virus lui-même ne sert qu’à la rendre possible à l’insu de l’utilisateur, en contournant les protections de l’ordinateur.

Cela rend aussi le virus facile à maintenir et faire évoluer, puisqu’il suffit de modifier les programmes du serveur, et le virus déjà dans la nature continuera de faire son travail sans modifications. Sûrement le rêve de beaucoup de codeurs de virus !

Notons que si les virus résidant exclusivement en mémoire ne sont pas une stratégie nouvelle, ce type d’attaque n’avait pas été constaté depuis 2001, avec notamment le ver CodeRed.

Les chercheurs de Kaspersky concluent en recommandant d’effectuer les mises à jour critiques du JRE, qui sont bien sûr la meilleure défense contre l’exploitation des failles Java. Ils recommandent également de bloquer l’accès aux sites en .eu, qui selon eux « contiennent de nombreuses ressources malicieuses », et d’utiliser un antivirus qui scanne les pages Web. Ils mettent également en garde contre une réutilisation probable de ce virus, qui pourrait cibler prochainement des utilisateurs en dehors de la Russie et installer des trojans autres que Lurk, et également cibler des OS autres que Windows, car Java est multiplateforme.

Source : Kaspersky

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de elaps
Membre à l'essai https://www.developpez.com
Le 19/03/2012 à 14:52
Ils recommandent également de bloquer l’accès aux sites en .eu
Un peu radical non ?

et également cibler des OS autres que Windows, car Java est multiplateforme.
Mais pas l'implementation de la machine virtuelle dans laquelle se situait la faille donc ca me semble tres speculatif.
3  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 21/03/2012 à 12:42
Citation Envoyé par MiaowZedong Voir le message

Les chercheurs de Kaspersky concluent en recommandant :
  • d’effectuer les mises à jour critiques du JRE, qui sont bien sûr la meilleure défense contre l’exploitation des failles Java.
  • de bloquer l’accès aux sites en .eu, qui selon eux « contiennent de nombreuses ressources malicieuses »,
  • d'utiliser un antivirus qui scanne les pages Web.
C'est drole, mais en matiere de securite, il vaut bien mieux recommander de desactiver Java que de bloquer l'acces aux sites en .eu (ou n'importe quoi d'autre d'ailleurs).

Quant a utiliser un antivirus qui scanne les pages web, c'est bien, mais un qui propose egalement le scan de la RAM, c'est mieux. Mais comme Kaspersky ne le fait pas, ils ne peuvent pas le recommander.
2  0 
Avatar de Jade_13
Membre averti https://www.developpez.com
Le 28/03/2012 à 10:08
Citation Envoyé par rt15 Voir le message
Java est tellement rarement utilisé dans le navigateur qu'il devrait être désactivé par défaut beaucoup plus souvent.
Désolée de te contredire.. mais dans la branche où je suis, nous avons plein d'établissements qui sont obligés de faire leur compta en ligne, et ça utilise java plein pot....
Mais bon... je doute qu'ils trainent sur les sites en .eu ^^
2  0 
Avatar de rt15
Membre confirmé https://www.developpez.com
Le 19/03/2012 à 16:22
Java est tellement rarement utilisé dans le navigateur qu'il devrait être désactivé par défaut beaucoup plus souvent. Au moins une confirmation devrait être demandée systématiquement avant l'exécution d'un applet (Ce qui est plus ou moins le cas parfois). Sérieusement, il doit y avoir plus d'applets avec des exploits que d'applets servant à quelque chose... Le taux vérolé/sain doit s'approcher de celui des ActiveX.

Concernant la "performance" de travailler en RAM (Jusqu'à l'installation du trojan...), bof bof.

Déjà, c'est ce que font à peu près tous les malware en première étape : l'exécution du shellcode se fait dans le processus dans lequel la faille est utilisée. Ensuite, c'est vrai que bien souvent, des fichiers sont téléchargés sur le disque et exécutés.

Mais télécharger une dll dans la mémoire, la déchiffrer et la charger dans le processus n'est pas beaucoup plus compliqué a priori. Faut recoder LoadLibrary mais il y a des exemples existant.
1  0 
Avatar de MRick
Membre du Club https://www.developpez.com
Le 19/03/2012 à 17:10
Citation Envoyé par MiaowZedong Voir le message
...
Au lieu de cela, le virus injecte directement en mémoire une DLL cryptée dans le processus javaw.exe. Cette stratégie le rend plus résistant aux antivirus, qui scannent les disques durs, les disques amovibles et souvent les connexions réseau, mais pas la RAM. De plus, le processus javaw.exe bénéficie habituellement de la confiance de l’antivirus et de l’utilisateur, ainsi que des pleins privilèges.
Il faudrait préciser : "mais généralement pas la RAM".
En effet, il y a plusieurs anti-virus qui sont capables de scanner la RAM. Je ne m'avancerais pas sur ceux que je connais peu, mais concernant celui que j'administre dans mon travail, à savoir McAfee VirusScan Enterprise 8.7 et 8.8, il est tout à fait possible de planifier des tâches d'analyse de la mémoire régulièrement.
Cette analyse n'est pas appliquée systématiquement, et pas activée par défaut. Je pense que la principale raison c'est l'impact sur les performances.

Ce qui est plus gênant, c'est le fait que la DLL soit cryptée, car il faut que l'antivirus soit capable de la décrypter d'une manière ou d'une autre.

Citation Envoyé par MiaowZedong Voir le message
Cela permet au virus de désactiver le contrôle des accès utilisateurs sur les postes Windows puis de se connecter sur le serveur des cybercriminels. Par la suite, celui-ci installe à distance le trojan Lurk. Détail important : c’est la logique du serveur qui installe le trojan. Le virus lui-même ne sert qu’à la rendre possible à l’insu de l’utilisateur, en contournant les protections de l’ordinateur.

Cela rend aussi le virus facile à maintenir et faire évoluer, puisqu’il suffit de modifier les programmes du serveur, et le virus déjà dans la nature continuera de faire son travail sans modifications. Sûrement le rêve de beaucoup de codeurs de virus !
Peut-être qu'il manque certains éléments dans cette explication, mais il me semble que ce mode de fonctionnement, où le code infectieux ne fait rien d'autre que de télécharger un Trojan sur un serveur afin de l'installer sur la machine infectée, est assez courant.
(Trojan = Cheval de Troie qui par définition n'est pas capable de se propager par lui-même)

C'est suffisamment courant pour que ce type de virus fasse l'objet d'une catégorie, on les appelle les downloaders.

On en voit régulièrement, ou parfois même on ne les voit pas, mais on voit les symptômes :
Si un antivirus détecte en boucle un Trojan qui est écrit sur le disque dur toutes les 5 ou 10 secondes, c'est très probablement que la machine est infectée par un downloader qui est inconnu de l'Antivirus, mais que celui-ci essaye d'installer un Trojan qui est connu.

Citation Envoyé par MiaowZedong Voir le message
Notons que si les virus résidant exclusivement en mémoire ne sont pas une stratégie nouvelle, ce type d’attaque n’avait pas été constaté depuis 2001, avec notamment le ver CodeRed.
Et il y a une raison à ça, c'est que chaque reboot ou arrêt de la machine nettoie le virus. C'est pas optimal pour infecter longtemps une machine.

Cependant entre les serveurs allumés en permanence (et dont les administrateurs se servent malheureusement pour aller surfer sur le web), et les portables qui ne sont jamais éteint mais systématiquement mis en veille / veille prolongée, ce genre de virus a peut-être un bel avenir devant lui.
1  0 
Avatar de rt15
Membre confirmé https://www.developpez.com
Le 19/03/2012 à 17:55
Citation Envoyé par MRick Voir le message

Ce qui est plus gênant, c'est le fait que la DLL soit cryptée, car il faut que l'antivirus soit capable de la décrypter d'une manière ou d'une autre.
La dll est très certainement déchiffrée en mémoire avant d'être injectée. Elle n'est chiffrée probablement que dans l'intérêt de passer un peu plus discrètement sur le réseau (Et donc dans un éventuel proxy anti-virus).
1  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 21/03/2012 à 14:25
Citation Envoyé par lamerenoelle Voir le message
je ne suis pas très douée pour internet et je voudrais savoir comment interdir au navigateur "internet explorer" et "firefox" d'aller sur les sites en .eu ? J'ai essayé de rentré quelque "chose" mais apparemment je n'ai pas le bon "code" pour me faire comprendre !! Merci de votre réponse
Ce n'est generalement pas au niveau du navigateur que tu fais cette configuration, mais au niveau de l'OS : cela permet de s'assurer que meme si tu installes un nouveau navigateur, il ne pourra pas se connecter a l'adresse indesirable.

Mais je le repete, comme d'autres, ce n'est pas une bonne solution. Si dans 3 mois tu veux acceder, par exemple, au site du parlement europeen, et que tu n'y arrives pas, tu ne sauras plus pourquoi, et l'analyse sera longue avant de penser que quelqu'un ne t'ait recommande de modifier ce type de regle.
1  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 19/03/2012 à 15:41
En effet. De plus, vu qu'il s'agit de charger une DLL et d'installer un Trojan fait pour Windows, les autres OS sont de fait à l'abri.
0  0 
Avatar de MiaowZedong
Membre extrêmement actif https://www.developpez.com
Le 19/03/2012 à 16:48
Citation Envoyé par elaps Voir le message
Un peu radical non ?
Oui.

Mais dans la mesure où il y a peu de contenu sur le .eu, je comprends leur point de vue. Pour un utilisateur qui ne va presque jamais sur des sites légitimes .eu, il n'est pas déraisonnable de bloquer l'extension. Cela vaut pour toutes les extensions "exotiques", par exemple si tu ne vas jamais sur le pr0n en .xxx il n'y a pas de désavantage à bloquer le TLD .xxx.


Mais pas l'implementation de la machine virtuelle dans laquelle se situait la faille donc ca me semble tres speculatif.
Attention, cette CVE n'est pas liée à une implémentation particulière. Il s'agit d'une faille au niveau du moteur de script Rhino qui permet d'executer du JavaScript dans la JVM. Si la JVM n'a pas le patch critique qui la corrige, il est possible de s'evader de la sandbox en executant son code Java depuis un ToString dans un message d'erreur Rhino. Un code venu d'Internet, donc suspect, peut ainsi récupérer tous les privilèges du processus Java malgré les défenses de la JVM.

L'attaque est entièrement en Java/Rhino, donc multiplateforme. C'est bien la JVM et non pas son implémentation qui est exploitée.

Par contre, comme le souligne Uther, la charge utile ne vise que Windows. En fait, pour attaquer Mac OS ou Linux, il faudrait changer de charge utile et que le serveur reconnaisse l'OS de la cible pour envoyer le bon trojan. Cela dit, avec les privilèges dont dispose habituellement la JVM, écrire une nouvelle charge utile ne serait pas le challenge du siècle
0  0 
Avatar de MiaowZedong
Membre extrêmement actif https://www.developpez.com
Le 20/03/2012 à 14:44
Citation Envoyé par MRick Voir le message
Il faudrait préciser : "mais généralement pas la RAM".
En effet, il y a plusieurs anti-virus qui sont capables de scanner la RAM. Je ne m'avancerais pas sur ceux que je connais peu, mais concernant celui que j'administre dans mon travail, à savoir McAfee VirusScan Enterprise 8.7 et 8.8, il est tout à fait possible de planifier des tâches d'analyse de la mémoire régulièrement.
Cette analyse n'est pas appliquée systématiquement, et pas activée par défaut. Je pense que la principale raison c'est l'impact sur les performances.
Merci pour tes précisions, je ne le savais pas


Peut-être qu'il manque certains éléments dans cette explication, mais il me semble que ce mode de fonctionnement, où le code infectieux ne fait rien d'autre que de télécharger un Trojan sur un serveur afin de l'installer sur la machine infectée, est assez courant.
(Trojan = Cheval de Troie qui par définition n'est pas capable de se propager par lui-même)

C'est suffisamment courant pour que ce type de virus fasse l'objet d'une catégorie, on les appelle les downloaders.
Il me semble que mon explication est complète, mais je reformule.

Contrairement à un downloader ou dropper, le virus ne prend pas la décision de télécharger le trojan: cela depend entièrement de la logique du serveur. De plus, il ne fait pas que contourner une mesure de protection, il la désactive, laissant le système moins sécurisé. Le but final pour l'assaillant reste d'installer un trojan, mais la méthode est très différente.

Et il y a une raison à ça, c'est que chaque reboot ou arrêt de la machine nettoie le virus. C'est pas optimal pour infecter longtemps une machine.
En effet. Dans ce cas cependant, ce n'est pas gênant, c'est même désirable car ça laisse moins de traces. La principale modification réalisée par le virus, désactiver l'UAC, est une opération qui aurait pu être réalisée légitimement.

Il n'y aura donc pas de traces de l'infection virale, et même si le trojan qui en profite est nettoyé, le PC pourra être re-infecté, re-rendu vulnérable et le trojan re-installé, toujours à l'insu de l'utilisateur.
0  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web