La sécurité et Java … Une mission impossible ?

Youhou ! Une torpille de plus lancée par les cyber-délinquants contre Microsoft Office a été contrecarrée par notre cyber-protection tenace et rusée.

Récemment une nouvelle attaque a été découverte : lorsque l’utilisateur ouvre des documents Word, un code malveillant est discrètement injecté dans l’ordinateur. Cela n’aurait pas dû faire les gros titres mais il s’avère qu’il s’agissait d’une attaque zero-day, c’est à dire d’une attaque qui utilise une vulnérabilité inconnue de Microsoft Office pour laquelle il n’existe pas de patch, et que la plupart des antivirus ont laissé passer entre leurs filets. Mais vous l’avez deviné – notre antivirus l’a détectée grâce à ses mailles de filet bien serrées !

Ce qui s’est produit c’est que notre technologie Automatic Exploit Prevention (AEP) a détecté un comportement anormal et en a bloqué pro-activement les attaques correspondantes. Pas de mise à jour, pas d’attente, pas de chaos. La suppression a été immédiate.

Les zero-days représentent une menace extrêmement sérieuse de nos jours et doivent être attaqués de plein fouet. Néanmoins, de nombreux antivirus sont relativement inutiles contre les futures attaques zero-days car ils fonctionnent principalement à partir de signatures, avec une « protection contre les futures menaces » seulement fournie sur papier ou sur la boîte (bien que je l’admet, la boîte est souvent très jolie:)). Mais bien sûr ! Après tout, une protection effective et réelle contre les futures menaces requiert une bonne dose d’intelligence et des ressources de développement. Tous les développeurs ne disposent pas nécessairement de ces dernières, et même si un vendeur en dispose, cela ne suffit pas forcément. Et nous ne parlons pas de technologies copiables ici….

Contrairement à ce que recommandent Buddha et les autres adeptes du « New Age », nous avons toujours pensé que pour ce qui est de la sécurité IT, il est impossible de vivre au jour le jour ou dans l’instant présent. La sécurité IT a besoin d’être constamment tournée vers le futur et de savoir ce qui se passe dans la tête des cybercriminels – avant que les événements ne se produisent. Un peu comme dans Minority Report. C’est pourquoi le terme « proactif » est sur notre agenda depuis le début des années 1990  (à l’époque nous nous distinguions déjà des autres en développant, entre autres, l’heuristique et notre émulateur. Les idées visionnaires coulent dans les veines de Kaspersky Lab !

Depuis, les technologies ont été réinventées et affinées et il y a environ deux ans et demi toutes les fonctionnalités de protection contre l’exploitation des vulnérabilités connues et inconnues étaient réunies sous le couvert de notre technologie AEP. Et ce, juste à temps. Avec son aide, nous avons pu découvrir pro-activement toutes une séries d’attaques ciblées, y compris Red October, MiniDuke et Icefog.

Ensuite, un intérêt malveillant pour Java est soudainement apparu. Mais notre technologie AEP était de nouveau prête : elle a fait ce qu’elle devait faire en combattant ces attaques. Elle a été conduite dans la bataille grâce à son module Java2SW qui a été spécialement conçu pour détecter les attaques ciblant Java.

Et c’est de ce module dont je vais vous parler dans la suite de ce post.

Le paysage des logiciels à l’intérieur d’un ordinateur traditionnel ressemble un peu à un très vieux patchwork : beaucoup de patchs mais autant de trous ! Des vulnérabilités sont régulièrement trouvées au sein des logiciels (et plus le produit est populaire, plus on en trouve fréquemment) et les entreprises qui fabriquent ces logiciels ont besoin de les sécuriser en sortant des patchs…

… Mais premièrement : les développeurs de logiciels ne sortent pas de patchs immédiatement. Certains attendent des mois ! Et deuxièmement, la plupart des utilisateurs oublient ou s’en fichent complètement et continuent de travailler avec des logiciels « troués ».

Pourtant la grande majorité des ordinateurs dans le monde disposent d’un antivirus !

Alors que peut-on faire ? C’est simple et c’est là que Java2SW rentre en piste. Pourquoi ? Parce qu’elle fait d’une pierre deux coups.

En gros, du point de vue de la sécurité, l’architecture de Java est plutôt avancée. Chaque programme est exécuté dans un environnement isolé (JVM – Java Virtual Machine), sous la supervision de Security Manager. Hélas, Java est devenu la victime de sa propre popularité – peu importe à quel point le système était protégé, (proportionnellement à sa popularité) des vulnérabilités ont rapidement été trouvées. Tôt ou tard, des vulnérabilités sont toujours trouvées, et tous les développeurs de logiciels devraient s’y préparer, en particulier (i) en développant à temps des technologies de protection, (ii) en réagissant très rapidement, et (iii) en informant les utilisateurs sur l’importance d’installer les patchs.

Le fait est que, concernant Java, Oracle n’a pas fait un très bon travail de préparation. D’ailleurs ils ont fait un travail tellement mauvais que des nombreux utilisateurs ont commencé à supprimer Java de leur navigateur – même si cela rendait l’ouverture de certains sites bien plus compliquée.

Voyez par vous même : le nombre de vulnérabilités trouvées sur Java en 2010 – 52 ; en 2011 – 59 ; en 2012 – 60 ; en 2013 – 180 (et l’année n’est pas encore terminée) ! Alors que le nombre d’attaques utilisant les vulnérabilités de Java a également augmenté de manière préoccupante :

Mais vous vous demandez sûrement ce que Java2SW a de si formidable et comment il prévient les attaques contre les vulnérabilités de Java ?

Eh bien, en plus du Security Agent par défaut, il ajoute à chaque machine virtuelle Java, un élément de sécurité supplémentaire. Il réalise des analyses indépendantes supplémentaires du code Java et l’empêche de fonctionner si une activité suspecte est détectée.

C’est particulièrement difficile à exécuter parce que nous avons besoin d’accéder à la plateforme Java et pas seulement nous contenter de l’envelopper. Pourquoi ? Parce que de l’extérieur, Java est relativement opaque – quelque chose se produit à l’intérieur, mais il est difficile de savoir pourquoi. Par exemple, Java lancera peut-être tel ou tel procédé, mais pourquoi il le fait ? Cela reste un mystère ! Mais en jetant un coup d’œil à l’intérieur, il est possible de trouver quel code est exécuté sur la machine Java, les permissions qu’il a, quelle est sa source, etc. Et c’est à partir de cela que nous pouvons tirer nos conclusions.

Grâce à son architecture, Java fournit une bonne couverture multiplateforme (les applications Java sans modification peuvent littéralement fonctionner sur n’importe quel système d’exploitation). Mais avec une si grande flexibilité vient le besoin d’un grand nombre de cellules grises pour développer une protection – puisque vous avez besoin d’un accès direct au cœur de la plateforme Java, et que la chirurgie du cœur n’est jamais directe. Cela va sans dire que tous les antivirus sont loin d’être assez intelligents pour réaliser cette chirurgie ; alors que notre technologie est déjà capable de réaliser ce travail – et est en attente d’être brevetée.

Une autre chose bien pratique en relation avec Java2SW : comment fonctionne-t-il aux côtés d’autres sous-systèmes de protection contre les vulnérabilités (AEP).

Quand il détecte une activité suspecte, le module communique l’information au System Watcher – le composant qui collecte les signaux à partir d’autres capteurs antivirus, considère l’ensemble, et agit de manière optimale et adéquate pour bloquer les attaques sophistiquées.

Par conséquent, même si le Security Manager de Java est compromis dans une attaque (et je peux vous dire que les cybercriminels aiment attaquer Security Manager) – aucun problème ! Nous pouvons toujours détecter et bloquer les attaques.

Java2SW serait-il une panacée contre les vulnérabilités inconnues de Java ?

Il est important de se souvenir d’une chose ici : Java2SW ne détecte pas les zero-days et de découvre pas de nouvelles vulnérabilités. Ce n’est pas dans ses capacités. Aussi curieux que cela puisse paraitre, son efficacité est mise en avant par de tels phénomènes. Il n’empêche pas les trous dans le patchwork que nous avons mentionné plus haut, il se contente de bloquer les attaques. Par conséquent, nous ne recherchons pas des vulnérabilités en particulier, mais nous protégeons les utilisateurs de manière plus universelle.

Le résultat ?

Premièrement, nous pouvons protéger les utilisateurs des attaques inconnues ciblant les vulnérabilités de Java de manière efficace. En d’autres termes, nous ajoutons une marge de sécurité au niveau du moment entre lequel la vulnérabilité est découverte et la sortie du patch correspondant.

Deuxièmement, même si un utilisateur appartient à la catégorie de ceux qui ignorent les patchs et ne les installent pas en temps voulu, nous le protégeons toujours de telles attaques.

Et sur cette note positive, j’y vais. À très bientôt …