Le Bulletin Cyber – Février 2021

Thématiques associées Cybersécurité EY Consulting

Découvrez l'édition du mois de février de notre Bulletin Cyber, un condensé des dernières cyberattaques et cybermenaces sectorielles.

Démantèlement de campagnes malveillantes

Une fois n’est pas coutume, ce bulletin s’ouvre sur de bonnes nouvelles : le botnet Emotet, largement exploité dans des campagnes malveillantes, a été la cible d’une opération conjointe des forces de l’ordre de nombreux pays, permettant à Europol de démanteler l’infrastructure informatique du botnet.

Les polices néerlandaises et allemandes ont pu substituer les serveurs de commande et contrôle du botnet par des serveurs contrôlés par elles afin d’une part de faire cesser les activités malveillantes, mais également de connaitre l’étendue du réseau : il est également possible pour les individus de renseigner leur adresse email pour savoir s’ils ont été enrôlés dans le botnet, via un formulaire mis en ligne par la police des Pays-Bas, et disponible ici.

Cette action est la seconde d’importance, après le démantèlement de TrickBot, orchestré par Microsoft et des entreprises privées, fin 2020. Alors certes, ces opérations ne mettent pas fin aux activités cybercriminelles, mais elles mettent un coup d’arrêt au moins temporaire, aux campagnes malveillantes. Plus encore, les criminels qui utilisaient ces services doivent se réorienter vers de nouveaux acteurs, reconstruire des botnets ou mettre leurs activités en pause : l’ANSSI évoquait dans un récent rapport que Necurs, Dridex, BitPaymer, DoppelDridex ou DoppelPaymer étaient autant de clients du botnet. Concomitamment à ce coup de filet, le Département de la Justice des Etats-Unis a également indiqué avoir pris le contrôle des infrastructures du gang opérant derrière le ransomware NetWalker, en coordination avec les polices de Bulgarie, mettant la main sur près de 500 000$ provenant du versement de rançons.

Les forces de l’ordre ne sont pas les seules à faire cesser les activités des fraudeurs : les opérateurs de la marketplace Joker’s Stash ont décidé, d’eux-mêmes, de fermer leur boutique le 15 février prochain. Cette place de marché était incontournable dans l’écosystème cybercriminel : elle permettait la vente et l’achat de données de cartes de paiement volées, essentiellement pour des transactions frauduleuses : en 2020, on estimait que près de 43 millions de données bancaires avaient été publiées.

On le voit, les forces de l’ordre et les agences gouvernementales ont décidé d’agir plus fortement, et avec plus de visibilité aussi, pour contrer les activités malveillantes de groupes criminels. Ces actions, si elles ne peuvent paraitre que trop ponctuelles, participent toutefois à la déstabilisation de l’écosystème, et permettent probablement de dissuader de nouveaux arrivants ou des acteurs déjà implantés de continuer dans leurs voies criminelles.

0-Day critique : le jeu du chat et de la souris

Une vulnérabilité critique au sein de Microsoft Office 365 a été découverte par l’équipe de chercheurs en sécurité Qihoo 360 Vulcan. Cette équipe était particulièrement motivée pour trouver des vulnérabilités de type RCE (Remote Code Execution) au sein de ce logiciel, considérant que six autres vulnérabilités de ce type avaient déjà émergé au cours des deux dernières années, notamment les CVE-2020-0688 et CVE-2019-1373. Dans cette édition de notre bulleting, nous nous concentrons spécifiquement sur les deux dernières CVEs, à savoir les CVE-2020-16875 et CVE-2020-17132.

Premier correctif, premier contournement

La première vulnérabilité (CVE-2020-16875) permet à des attaquants distants d'exécuter du code arbitraire sur les installations concernées d'Exchange Server. Une authentification avec le rôle "Data Loss Prevention" est nécessaire pour exploiter cette vulnérabilité.

La vulnérabilité se trouve dans le traitement du cmdlet New-DlpPolicy, puisque les données de modèle fournies par l'utilisateur lors de la création d'une politique dlp ne sont pas correctement validées.  Le problème résulte de l'absence de validation appropriée. Un attaquant peut exploiter cette vulnérabilité pour exécuter du code dans le contexte de l’utilisateur SYSTEM. Si Microsoft a rapidement corrigé la vulnérabilité, en publiant un correctif le 08 septembre 2020 (KB4577352), il était toutefois possible de trouver le script permettant l’exploitation du bug :

Second correctif, second contournement

L’équipe de chercheur en sécurité @x41sec a étudié le correctif publié précédemment et a identifié une nouvelle possibilité d’exploiter la vulnérabilité : là encore, Microsoft propose un correctif pour la CVE-2020-17132 dès le 8 décembre 2020, avec le correctif KB4593465.

Explication du précédent correctif et explication des contournements

  • Le code corrigé qui empêche l'exploitation du CVE-2020-16875 pourrait ressembler à ceci :

    internal static void ValidateCmdletParameters(string cmdlet,

        IEnumerable<KeyValuePair<string, string>> requiredParameters)

    {

        if (string.IsNullOrWhiteSpace(cmdlet))

        {

            return;

        }

        Collection<PSParseError> collection2;

        Collection<PSToken> collection = PSParser.Tokenize(cmdlet,

            out collection2);

        if (collection2 != null && collection2.Count > 0)

        {

            throw new DlpPolicyParsingException(

                Strings.DlpPolicyNotSupportedCmdlet(cmdlet));

        }

        if (collection != null)

        {

            // #1 CHECKS IF THERE IS MORE THAN ONE COMMAND, BUT DOES NOT

            // RECOGNIZE .NET FUNCTIONS SUCH AS [Int32]::Parse("12")

            if ((from token in collection

            where token.Type == PSTokenType.Command

            select token).ToList<PSToken>().Count > 1)

            {

                throw new DlpPolicyParsingException(

                    Strings.DlpPolicyMultipleCommandsNotSupported(cmdlet));

            }

        }

        bool flag = false;

        foreach (KeyValuePair<string, string> keyValuePair in requiredParameters)

        {

            // #2 CHECKS IF THE cmdlet STRING(!!) STARTS WITH AN ALLOWED KEY

            if (cmdlet.StartsWith(keyValuePair.Key,

                StringComparison.InvariantCultureIgnoreCase))

            {

                // #3 CHECKS IF THE THE VALUES / PARAMETERS MATCH A CERTAIN

                // REGEX

                if (!Regex.IsMatch(cmdlet, keyValuePair.Value,

                    RegexOptions.IgnoreCase))

                {

                    throw new DlpPolicyParsingException(

                        Strings.DlpPolicyMissingRequiredParameter(cmdlet,

                            keyValuePair.Value));

                }

                flag = true;

            }

        }

        if (!flag)

        {

            throw new DlpPolicyParsingException(Strings.DlpPolicyNotSupportedCmdlet(

                                                                            cmdlet));

        }

    }

     

La tentative de validation du cmdlet a pour objectifs principaux d’empêcher l'utilisation de plusieurs jetons Powershell Command par cmdlet, et de n’autoriser les commandes en liste blanche qu'avec certains paramètres.

Trois contrôles sont introduits pour filtrer les tentatives d'exploitation : malheureusement, ces vérifications restent insuffisantes.

Contrôle #1

La première vérification dans le correctif ci-dessus, consiste à analyser et à marquer la chaîne de cmdlets et vérifie si plus d'un jeton de type PSTokenType.Command est présent.

Un jeton de commande est une évaluation faite par PSParser. Avant la correction de Microsoft, il était possible d’avoir plusieurs jetons de commande comme dans l’exemple ci-dessous :

New-object System.Diagnostics.ProcessStartInfo;$i.UseShellExecute=$true; //first command
$i.FileName=”cmd”;$i.Arguments=”/c %s”; //Second command
$r=New-Object System.Diagnostics.Process;$r.StartInfo=$i;$r.Start()

De plus, les jetons de type PSTokenType.Command à l'intérieur des instructions `$()` sont empêchés, donc la commande suivante ne fonctionnera pas :

new-transportrule -Name $(Diagnostics.Process.Start(....))

Toutefois, les appels directs vers .NET acceptent l’utilisation de crochets, et non plus de parenthèses, car ils ne sont pas considérés comme des jetons de "commande" par PSParser :

new-transportrule -Name $([Diagnostics.Process]::start("cmd.exe", "/C ...."))

La commande ci-dessus contient un jeton "Commande", permettant donc de contourner la première vérification.

 Contrôle #2

La seconde vérification (Check #2) peut être facilement contournée car elle est effectuée sur le

raw cmdlet string et utilise seulement `.StartsWith()` pour vérifier le début du cmdlet. Pour contourner la vérification, il suffit de fournir simplement une chaîne de commande qui est contenue dans les clés valides transmises via les paramètres fournis à la fonction.

new-transportruleSOMETHINGELSE....

Contrôle #3

La troisième vérification (check #3) consiste à appliquer une expression régulière au cmdlet pour s'assurer que seuls des paramètres et des valeurs valables sont fournis.

Malheureusement l'expression régulière présente au moins deux lacunes :

  • Par défaut, Regex.IsMatch() ne traite qu’une seule ligne et non plusieurs.
  • L'expression régulière appliquée ne vérifie pas les entrées du début à la fin de la chaîne de cmdlets, mais simplement vérifie les sous-chaînes.

Pour contourner la vérification, le cmdlet Powershell doit juste contenir l'un des paramètres attendus comme par exemple "DlpPolicy".

PoC

La charge utile suivante peut contourner les trois contrôles mentionnés ci-dessus :

<![CDATA[ new-transportrule
-Name $([Diagnostics.Process]::start("cmd.exe / C <run-as-SYSTEM>"))
-DlpPolicy "%%DlpPolicyName%%"
]]>

Cet exemple nous démontre que la correction de vulnérabilité – ou de bug - n’est jamais simple.

Dans certains cas il est difficile de vérifier l’ensemble du scope couvert par la vulnérabilité, et donc le d’évaluer la couverture de sa correction.

Le correctif peut donc, parfois, constituer un vecteur d’intrusion dans un système d’information à ne pas négliger pour des ingénieurs en tests d’intrusion.

Pour terminer il semblerait qu’un correctif de Microsoft soit en cours de rédaction.

Pour aller plus loin

Les dirigeants, les conseils d'administration et les responsables de la cybersécurité ne sont pas toujours informés des menaces que suscitent les nouvelles formes émergentes de cybercriminalité. Ce bulletin propose une vision claire de ces menaces, qu’elles soient sectorielles, informatiques ou mobiles. Il présente les dernières tendances ainsi qu’une version synthétique des rapports proposés chaque semaine à nos clients. N’hésitez pas à nous contacter pour plus d’informations

Nos atouts

  • Le Lab : 600m2 dédiés à la recherche et au développement à l’innovation et à la transformation numérique.
  • War Room : Un environnement hautement sécurisé exploitant des solutions collaboratives et des technologies propriétaires innovantes.
  • Cyber Teams : L’équipe EY France cybersécurité est composée d’experts pluridisciplinaires, proposant des solutions nouvelles pour résoudre des problématiques stratégiques pour nos clients.
  • CyberEye : Une solution leader de Cyber Threat Intelligence solution, apportant une connaissance précise des cybermenaces pouvant toucher les entreprises.
  • ASC and CTI : Nos 63 Advanced Security Centers, situés dans de nombreux pays, partagent des renseignements opérationnels et centrés vers les entreprises pour notre Cyber Threat Intelligence.

Ce qu’il faut retenir :

De nos jours, les entreprises sont de plus en plus visées par différents types de cyberattaques. Au cœur de la cybercriminalité internationale, dans cette nouvelle édition du bulletin, nos experts EY parlent d’une action de grande ampleur : le réseau cybercriminel Emotet qui a infecté des centaines de milliers d'ordinateurs a été enfin démantelé. Nous revenons également sur le démantèlement des plus grands botnets ainsi que sur une vulnérabilité critique, la faille de type « zero-day » au sein de Microsoft Office 365.