Discussion :

[MiaowZedong]

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

[elaps]

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.

[Uther]

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.

[rt15]

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.

[MiaowZedong]

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

[MRick]

...
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.

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.

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.

[rt15]

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).

[MiaowZedong]

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.

[gangsoleil]

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.

[lamerenoelle]

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

[gangsoleil]

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.

[Uther]

En effet, de plus le virus ne passant certainement pas par le navigateur pour télécharger le trojan, bloquer l'accès aux sites .eu au niveau du navigateur ne te protègerais absolument pas.

[F@bien.fd]

En tant qu'utilisateur lambda... quelle est ou quelles sont les solutions a utiliser pour régler le compte à ce virus SVP ?

[Uther]

Si tu as Java, mettre a jour ta JVM.

[Totony]

Si tu as Java, mettre a jour ta JVM.

Si tu as Java, désinstalle le.
</troll>

[Jade_13]

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 ^^

[rt15]

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 ^^

Attention, on parle bien d'applet java ici, c'est à dire de java côté navigateur. Il y a moult application d'entreprises qui utilisent java côté serveur (servlet + n'importe quoi jsp ou autre), mais côté navigateur c'est quand même assez rare. Tu es peut être juste l'exception confirmant la règle. Et côté site web public, il y a encore moins d'applet.

[Uther]

Il y a plus d'entreprises qui utilisent les applets que tu le pense, j'en connais également pas mal qui sont dans ce cas.

[F@bien.fd]

Si tu as Java, désinstalle le.

si je fais ça, tous mes graphiques de bourse tombent à l'eau et moi je suis mort...

[Uther]

A noter que Firefox viens de se décider à placer les plug-ins java victimes de cette faille dans sa liste noire des plug-ins dangereux, ils seront désactivés par défaut et indiqués comme dangereux si l'on souhaite les réactiver.