{"id":12401,"date":"2019-10-10T13:30:03","date_gmt":"2019-10-10T13:30:03","guid":{"rendered":"https:\/\/www.kaspersky.fr\/blog\/?p=12401"},"modified":"2019-11-22T08:46:03","modified_gmt":"2019-11-22T08:46:03","slug":"vulnerabilities-in-public-clouds","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/vulnerabilities-in-public-clouds\/12401\/","title":{"rendered":"Prot\u00e9ger les Clouds publics des vuln\u00e9rabilit\u00e9s courantes"},"content":{"rendered":"<p>Beaucoup d\u2019entreprises utilisent un environnement informatique Cloud qui fait appel \u00e0 une combinaison de services en Cloud priv\u00e9 sur site et en Cloud public. Pourtant, lorsqu\u2019il s\u2019agit de la cybers\u00e9curit\u00e9, les entreprises ont tendance \u00e0 se concentrer sur la protection des environnements physiques et virtuels, et d\u00e9laissent la partie de l\u2019infrastructure qui est bas\u00e9e dans les Clouds publics. Certaines entreprises sont convaincues que les fournisseurs de services Cloud s\u2019occupent de leur protection, alors que d\u2019autres pensent que les Clouds publics sont s\u00e9curis\u00e9s par nature et n\u2019ont donc pas besoin d\u2019\u00eatre prot\u00e9g\u00e9s. Ces deux id\u00e9es sont erron\u00e9es\u00a0: les Clouds publics sont aussi vuln\u00e9rables que le reste de votre infrastructure en mati\u00e8re d\u2019exploitation de vuln\u00e9rabilit\u00e9s des programmes, de mise \u00e0 jour de l\u2019empoisonnement, d\u2019exploitation de la connexion r\u00e9seau et de la mise en danger des informations des comptes. Nous vous expliquons pourquoi.<\/p>\n<h2>Vuln\u00e9rabilit\u00e9s de RDP et SSH<\/h2>\n<p>Le RDP est activ\u00e9 par d\u00e9faut dans les outils Amazon mais l\u2019authentification \u00e0 deux facteurs n\u2019est pas disponible par nature. Diff\u00e9rents outils ont pris le RDP pour cible lors d\u2019attaques par force brute. Certains se concentrent sur les noms d\u2019utilisateur par d\u00e9faut les plus courants (comme \u00a0\u00bb\u00a0Administrateur\u00a0\u00ab\u00a0) et essaient des milliers de combinaisons pour d\u00e9couvrir le mot de passe. D\u2019autres utilisent les noms de famille et les mots de passe les plus courants pour deviner l\u2019identifiant unique de l\u2019administrateur. Les algorithmes de force brute peuvent limiter et randomiser le nombre de tentatives, en \u00e9tablissant un temps mort entre chaque essai pour \u00e9viter d\u2019\u00eatre d\u00e9tect\u00e9 automatiquement. Une autre m\u00e9thode consiste \u00e0 r\u00e9aliser une attaque par force brute pour obtenir le mot de passe du nom d\u2019utilisateur SSM qui est souvent programm\u00e9 dans les infrastructures AWS.<\/p>\n<p>D\u2019autres attaques similaires par force brute s\u2019en prennent constamment aux services SSH, alors que SSH est \u00e9quip\u00e9 d\u2019une meilleure protection que le RDP (avec notamment l\u2019authentification \u00e0 deux facteurs). Un service mal configur\u00e9 peut facilement permettre \u00e0 un acteur malveillant et persistant d\u2019obtenir l\u2019acc\u00e8s. Les attaques par force brute qui s\u2019en prennent \u00e0 SSH ou au RDP repr\u00e9sentent 12 % des attaques qui sont tomb\u00e9es dans les pi\u00e8ges de l\u2019IoT de Kaspersky <a href=\"https:\/\/securelist.com\/it-threat-evolution-q1-2019-statistics\/90916\/\" target=\"_blank\" rel=\"noopener\">au cours du premier semestre de 2019<\/a>.<\/p>\n<h2>Vuln\u00e9rabilit\u00e9s de logiciels tiers<\/h2>\n<p>Les Clouds publics peuvent bel et bien vous rendre vuln\u00e9rable. Voici quelques exemples qui expliquent comment la vuln\u00e9rabilit\u00e9 d\u2019un logiciel tiers permet aux cybercriminels d\u2019ex\u00e9cuter le code directement dans l\u2019infrastructure.<\/p>\n<p>Le 3 juin 2019, <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/critical-exim-tls-flaw-lets-attackers-remotely-execute-commands-as-root\/\" target=\"_blank\" rel=\"noopener nofollow\">on d\u00e9couvrait une vuln\u00e9rabilit\u00e9 dans Exim<\/a>, un serveur e-mail populaire et souvent utilis\u00e9 sur les Clouds publics. Cette vuln\u00e9rabilit\u00e9 permettait d\u2019ex\u00e9cuter le code \u00e0 distance. Si le serveur \u00e9tait lanc\u00e9 en tant qu\u2019utilisateur root, comme c\u2019est souvent le cas, alors le code malveillant introduit dans le serveur pouvait \u00eatre ex\u00e9cut\u00e9 avec des privil\u00e8ges root. Une autre vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 d\u00e9tect\u00e9e dans Exim en juillet 2019\u00a0; celle-ci permettait aussi d\u2019ex\u00e9cuter des codes \u00e0 distance en root.<\/p>\n<p>Un autre exemple est le piratage du site officiel de Linux Mint en 2016. Par cons\u00e9quent, les distributions Linux ont \u00e9t\u00e9 modifi\u00e9es pour inclure le logiciel malveillant et ajouter une porte d\u00e9rob\u00e9e IRC \u00e9quip\u00e9e de la fonction DDoS. Les cybercriminels pouvaient se servir de ce logiciel malveillant pour laisser des charges malveillantes dans les dispositifs infect\u00e9s. D\u2019autres utilisateurs ont signal\u00e9 des cas qui impliquaient l\u2019utilisation de modules malveillants node.js, des <a href=\"https:\/\/www.helpnetsecurity.com\/2019\/04\/29\/docker-hub-breach\/\" target=\"_blank\" rel=\"noopener nofollow\">contenants infect\u00e9s dans Docker Hub<\/a>, et bien d\u2019autres.<\/p>\n<h2>Comment r\u00e9duire les risques<\/h2>\n<p>Les cybercriminels peuvent \u00eatre tr\u00e8s imaginatifs lorsqu\u2019il s\u2019agit de trouver des points d\u2019entr\u00e9e leur permettant d\u2019acc\u00e9der aux infrastructures\u00a0; surtout lorsque ces infrastructures sont si nombreuses, et pourtant si similaires, et qu\u2019elles rencontrent les m\u00eames probl\u00e8mes, pendant que nous croyons tout simplement qu\u2019elles sont hautement s\u00e9curis\u00e9es par nature. Nous vous conseillons de prot\u00e9ger les syst\u00e8mes d\u2019exploitation de vos services Cloud et machines virtuelles pour r\u00e9duire les risques et les g\u00e9rer plus efficacement. Il est \u00e9vident que les antivirus de base et les solutions de protection antimalware ne sont pas suffisants. Selon les pratiques exemplaires de ce secteur, chaque syst\u00e8me d\u2019exploitation qui appartient \u00e0 une infrastructure doit avoir une protection compl\u00e8te multicouche, et les fournisseurs de Clouds publics donnent les m\u00eames conseils.<\/p>\n<p>C\u2019est \u00e0 ce moment-l\u00e0 qu\u2019une solution de s\u00e9curit\u00e9 comme Kaspersky Hybrid Cloud Security entre en jeu. Notre solution prot\u00e8ge les diff\u00e9rents types de charges de travail qui s\u2019ex\u00e9cutent sur les plateformes gr\u00e2ce \u00e0 plusieurs couches de technologies de s\u00e9curit\u00e9 y compris le renforcement du syst\u00e8me, la pr\u00e9vention des exploits, la surveillance de l\u2019int\u00e9grit\u00e9 des fichiers, un outil qui bloque les attaques r\u00e9seau, un antimalware statique et comportemental, et bien d\u2019autres. Vous pouvez <a href=\"https:\/\/www.kaspersky.fr\/enterprise-security\/cloud-security?redef=1&amp;reseller=gl_hybrcld_acq_ona_smm__onl_b2b_blog_post_______\" target=\"_blank\" rel=\"noopener\">obtenir plus de renseignements sur notre solution en cliquant ici<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Contrairement \u00e0 ce que l\u2019on pense, les Clouds publics ne sont pas hautement s\u00e9curis\u00e9s par nature et c\u2019est pourquoi ils doivent \u00eatre mieux prot\u00e9g\u00e9s.<\/p>\n","protected":false},"author":1475,"featured_media":12402,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2112,3150,3151],"tags":[2638,2880,322],"class_list":{"0":"post-12401","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-cloud-hybride","11":"tag-virtualisation","12":"tag-vulnerabilites"},"hreflang":[{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/vulnerabilities-in-public-clouds\/12401\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/vulnerabilities-in-public-clouds\/16771\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/vulnerabilities-in-public-clouds\/14160\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/vulnerabilities-in-public-clouds\/18758\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/vulnerabilities-in-public-clouds\/16805\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/vulnerabilities-in-public-clouds\/15548\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/vulnerabilities-in-public-clouds\/19449\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/vulnerabilities-in-public-clouds\/18112\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/vulnerabilities-in-public-clouds\/23761\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/vulnerabilities-in-public-clouds\/6542\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/vulnerabilities-in-public-clouds\/28905\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/vulnerabilities-in-public-clouds\/12508\/"},{"hreflang":"pl","url":"https:\/\/plblog.kaspersky.com\/vulnerabilities-in-public-clouds\/11299\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/vulnerabilities-in-public-clouds\/20401\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/vulnerabilities-in-public-clouds\/24338\/"},{"hreflang":"nl","url":"https:\/\/www.kaspersky.nl\/blog\/vulnerabilities-in-public-clouds\/24707\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/vulnerabilities-in-public-clouds\/19224\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/vulnerabilities-in-public-clouds\/23540\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/vulnerabilities-in-public-clouds\/23390\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.fr\/blog\/tag\/cloud-hybride\/","name":"cloud hybride"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/12401","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/users\/1475"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/comments?post=12401"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/12401\/revisions"}],"predecessor-version":[{"id":12600,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/12401\/revisions\/12600"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media\/12402"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media?parent=12401"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/categories?post=12401"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/tags?post=12401"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}