Cliquez et faites glisser sur les ondes sonores ci-dessous pour passer à n'importe quel point. Vous pouvez également écouter directement sur Soundcloud.

[MODÈME MUSICAL]

CANARD.  Bonjour tout le monde.

Bienvenue dans un autre mini-épisode spécial du podcast Naked Security.

Je suis Paul Ducklin, rejoint à nouveau par mon ami et collègue Chester Wisniewski.

Bonjour Chet.

CHET.  [FAUX ACCENT AUSSIE] Bonjour, canard.

CANARD.  Eh bien, Chet, je suis sûr que tout le monde écoute. s'ils écoutent peu de temps après la sortie du podcast, savent de quoi nous allons parler !

Et ça doit être ce double canon Microsoft Exchange zéro jour qui est sorti au lavage à peu près le dernier jour de septembre 2022 :

Nos copains des ventes disent: "Oh, c'est la fin du mois, c'est la fin du trimestre, c'est une période frénétique… mais demain, tout le monde reçoit une réinitialisation à 0 $."

Ce ne sera pas comme ça ce week-end pour les Sysadmins et les DSI !

CHET.  Duck, je pense, dans les mots immortels du cher Douglas Adams, "NE PAS PANIQUER" pourrait être en ordre.

De nombreuses organisations n'hébergent plus leur propre messagerie sur site sur les serveurs Exchange, donc un bon nombre de personnes peuvent respirer profondément et laisser passer un peu de temps ce week-end, sans être trop stressées à ce sujet.

Mais si vous exécutez Exchange sur site…

… si c'était moi, je ferais peut-être des heures supplémentaires juste pour mettre en place quelques atténuations, pour être sûr de ne pas avoir de mauvaise surprise lundi ou mardi quand cela, selon toute vraisemblance, se transformera en quelque chose de plus spectaculaire.

CANARD.  Alors c'est CVE-2022-41040 ainsi que CVE-2022-41042… c'est toute une bouchée.

J'ai vu qu'il était mentionné sur Twitter comme ProxyNotShell, car il présente certaines similitudes avec le ProxyShell vulnérabilité qui était la grande histoire il y a un peu plus d'un an,

Mais bien qu'il présente ces similitudes, il s'agit d'une toute nouvelle paire d'exploits qui s'enchaînent, donnant potentiellement l'exécution de code à distance - n'est-ce pas ?

CHET.  C'est ce que ça ressemble.

Ces vulnérabilités ont été découvertes lors d'une attaque active contre une victime, et une organisation vietnamienne appelée GTSC a dévoilé ces deux nouvelles vulnérabilités qui ont permis aux adversaires d'accéder à certains de leurs clients.

Il semble qu'ils aient divulgué de manière responsable ces vulnérabilités à la Zero Day Initiative [ZDI] qui est gérée par Trend Micro pour signaler les vulnérabilités zero-day de manière responsable.

Et, bien sûr, ZDI a ensuite partagé à son tour toutes ces informations avec Microsoft, il y a un peu plus de trois semaines.

Et la raison pour laquelle il sort aujourd'hui, c'est que je pense que le groupe vietnamien…

… il semble qu'ils deviennent un peu impatients et inquiets que cela fait trois semaines et qu'aucune alerte ou conseil n'ait été envoyé pour aider à protéger les gens contre ces acteurs présumés de l'État-nation.

Ils ont donc décidé de tirer la sonnette d'alarme et de faire savoir à tout le monde qu'ils devaient faire quelque chose pour se protéger.

CANARD.  Et, pour être juste, ils ont soigneusement dit, "Nous n'allons pas révéler exactement comment exploiter ces vulnérabilités, mais nous allons vous donner des mesures d'atténuation que nous avons trouvées efficaces."

Il semble que l'un ou l'autre des exploits en soi ne soit pas particulièrement dangereux…

… mais enchaînés, cela signifie qu'une personne extérieure à l'organisation qui a la capacité de lire les e-mails de votre serveur pourrait en fait utiliser le premier bogue pour ouvrir la porte, et le second bogue pour implanter essentiellement des logiciels malveillants sur votre serveur Exchange.

CHET.  Et c'est un point très important à souligner, Duck, que vous ayez dit, "Quelqu'un qui peut lire les e-mails sur votre serveur."

Il ne s'agit pas d'une attaque *non authentifiée*, donc les attaquants ont besoin d'avoir des renseignements sur votre organisation afin d'exécuter avec succès ces attaques.

CANARD.  Maintenant, nous ne savons pas exactement de quel type d'informations d'identification ils ont besoin, car au moment où nous enregistrons ceci [2022-09-30T23:00:00Z], tout est encore largement secret.

Mais d'après ce que j'ai lu (de la part de personnes que j'ai tendance à croire), il semble que les cookies de session ou les jetons d'authentification ne soient pas assez bons et que vous ayez en fait besoin du mot de passe d'un utilisateur.

Après avoir fourni le mot de passe, cependant s'il y avait une authentification à deux facteurs [2FA], le premier bogue (celui qui ouvre la porte) se déclenche * entre le moment où le mot de passe est fourni et le moment où les codes 2FA seraient demandé*.

Vous avez donc besoin du mot de passe, mais vous n'avez pas besoin du code 2FA…

CHET.  Cela ressemble à une "vulnérabilité de mi-authentification", si vous voulez l'appeler ainsi.

C'est une bénédiction mitigée.

Cela signifie qu'un script Python automatisé ne peut pas simplement analyser l'ensemble d'Internet et exploiter potentiellement tous les serveurs Exchange du monde en quelques minutes ou heures, comme nous l'avons vu avec ProxyLogon et ProxyShell en 2021.

Nous avons vu le retour du vermifuge ces 18 derniers mois, au détriment de nombreuses organisations.

CANARD.  « Vermage » ?

CHET.  Vermifuge, oui ! [DES RIRES]

CANARD.  Est-ce un mot ?

Eh bien, si ce n'est pas le cas, c'est maintenant !

J'aime ça… Je pourrais l'emprunter, Chester. [DES RIRES]

CHET.  Je pense que c'est légèrement vermifuge, non ?

Vous avez besoin d'un mot de passe, mais trouver une combinaison d'adresse e-mail et de mot de passe valide sur un serveur Exchange donné n'est probablement pas trop difficile, malheureusement.

Lorsque vous parlez de centaines ou de milliers d'utilisateurs… dans de nombreuses organisations, un ou deux d'entre eux sont susceptibles d'avoir de mauvais mots de passe.

Et vous n'avez peut-être pas été exploité à ce jour, car pour vous connecter avec succès à Outlook Web Access [OWA] nécessite leur jeton FIDO, ou leur authentificateur, ou tout autre facteur que vous pourriez utiliser.

Mais cette attaque ne nécessite pas ce deuxième facteur.

Ainsi, le simple fait d'acquérir une combinaison de nom d'utilisateur et de mot de passe est une barrière assez faible…

CANARD.  Maintenant, il y a une autre complexité ici, n'est-ce pas ?

A savoir que bien que La directive de Microsoft dit officiellement que les clients Microsoft Exchange Online peuvent se retirer de Blue Alert, ce n'est dangereux que si vous avez Exchange sur site…

… il y a un nombre surprenant de personnes qui sont passées au cloud, il y a peut-être plusieurs années, qui exécutaient à la fois leur service sur site et leur service cloud pendant le changement, qui n'ont jamais pris le temps de désactiver le sur site Serveur d'échange.

CHET.  Précisément!

Nous avons vu cela revenir à ProxyLogin et ProxyShell.

Dans de nombreux cas, les criminels sont entrés dans leur réseau via des serveurs Exchange qu'ils pensaient ne pas avoir.

Par exemple, quelqu'un n'a pas vérifié la liste des machines virtuelles s'exécutant sur son serveur VMware pour remarquer que ses serveurs Exchange migratoires l'aidaient lors du forklifting des données entre son réseau sur site et le réseau cloud…

… étaient toujours, en fait, allumés, activés et exposés à Internet.

Et pire, lorsqu'ils ne sont pas connus pour être là, ils sont encore moins susceptibles d'avoir été patchés.

Je veux dire, les organisations qui ont au moins Exchange font probablement tout leur possible pour planifier une maintenance régulière.

Mais lorsque vous ne savez pas que vous avez quelque chose sur votre réseau "parce que vous avez oublié", ce qui est vraiment facile avec les machines virtuelles, vous êtes dans une situation encore pire, car vous n'avez probablement pas appliqué les mises à jour Windows ou Exchange.

CANARD.  Et la loi de Murphy dit que si vous comptez vraiment sur ce serveur et que vous ne vous en occupez pas correctement, il plantera juste le jour avant que vous en ayez vraiment besoin.

Mais si vous ne savez pas qu'il est là et qu'il pourrait être utilisé à mauvais escient, les chances qu'il fonctionne pendant des années et des années et des années sans aucun problème sont probablement assez élevées. [DES RIRES]

CHET.  Oui, malheureusement, c'est certainement mon expérience !

Cela semble idiot, mais analyser votre propre réseau pour savoir ce que vous avez est quelque chose que nous vous recommandons de faire régulièrement de toute façon.

Mais certainement, lorsque vous entendez parler d'un bulletin comme celui-ci, s'il s'agit d'un produit que vous savez avoir utilisé dans le passé, comme Microsoft Exchange, c'est le bon moment pour exécuter ce bulletin interne Analyse Nmap...

…et peut-être même se connecter à shodan.io et vérifiez vos services externes, juste pour être sûr que tout cela a été désactivé.

CANARD.  Nous savons maintenant, d'après la propre réponse de Microsoft, qu'ils se démènent frénétiquement pour obtenir des correctifs.

Lorsque ces patchs apparaissent, vous feriez mieux de les appliquer assez rapidement, n'est-ce pas ?

Parce que si jamais un correctif doit être ciblé pour une ingénierie inverse afin de comprendre l'exploit, ce sera quelque chose de ce genre.

CHET.  Oui, absolument, Canard !

Même une fois que vous aurez corrigé, il y aura une fenêtre de temps, n'est-ce pas ?

Je veux dire, typiquement Microsoft, pour les Patch Tuesdays de toute façon, publiez leurs correctifs à 10.00hXNUMX, heure du Pacifique.

En ce moment, nous sommes à l'heure d'été, donc c'est UTC-7… donc, vers 17h00 UTC, c'est généralement lorsque Microsoft publie des correctifs, de sorte que la plupart de leur personnel a toute la journée pour répondre aux requêtes entrantes à Seattle. [Le siège social de Microsoft est à Bellevue, Seattle, WA.]

La clé ici est qu'il y a une sorte de "course" d'heures, peut-être de minutes, selon la facilité d'exploitation, avant que cela ne commence à se produire.

Et encore une fois, en revenant à ces exploitations Exchange précédentes avec ProxyShell et ProxyLogon, nous avons souvent constaté que même les clients qui avaient corrigé dans les trois, quatre, cinq jours…

… qui, pour être honnête, est un peu rapide pour un serveur Exchange, ils sont très difficiles à corriger, avec de nombreux tests nécessaires pour s'assurer qu'il est fiable avant de perturber vos serveurs de messagerie.

C'était assez de temps pour que ces serveurs obtiennent Webshells, cryptomères, toutes sortes de backdoors installés sur eux.

Et donc, lorsque le patch officiel est sorti, non seulement vous devez agir rapidement…

… * après * avoir agi, cela vaut la peine de revenir en arrière et de vérifier soigneusement ces systèmes pour trouver des preuves qu'ils ont peut-être été attaqués entre le moment où le correctif est devenu disponible et le moment où vous avez pu l'appliquer.

Je suis sûr qu'il y aura beaucoup de conversations sur Naked Security, et sur Twitter et d'autres endroits, parler des types d'attaques que nous voyons afin que vous sachiez quoi rechercher.

CANARD.  Alors que vous pouvez aller chercher un tas de hachages de logiciels malveillants connus qui ont déjà été distribués dans un nombre limité d'attaques…

… vraiment, l'essentiel est que toutes sortes de logiciels malveillants sont des possibilités.

Et donc, comme je pense que vous l'avez dit dans le dernier mini-épisode comme nous l'avons fait, il ne suffit plus d'attendre que les alertes d'un incident survenu apparaissent dans votre tableau de bord :

Vous devez sortir de manière proactive et regarder, au cas où des escrocs auraient déjà été dans votre réseau et qu'ils auraient laissé quelque chose derrière eux (qui aurait pu être là depuis des lustres !) que vous n'avez pas encore remarqué.

CHET.  Je pense donc que cela nous mène vers, « Qu'est-ce qu'on fait maintenant, en attendant le patch ?

Publication du blog Microsoft Security Research Center (MSRC) quelques conseils d'atténuation et des détails… autant que Microsoft est prêt à divulguer pour le moment.

Je dirais, si tu es un pur Microsoft Exchange en ligne client, vous êtes à peu près au clair et vous devez simplement faire attention au cas où les choses changeraient.

Mais si vous êtes dans une situation hybride, ou si vous utilisez toujours Microsoft Exchange sur site, je pense qu'il y a probablement du travail qui vaut la peine d'être fait cet après-midi ou demain matin si rien d'autre.

Bien sûr, au moment de l'enregistrement, nous sommes vendredi après-midi… donc, vraiment, quand vous écoutez ça, "Immédiatement, chaque fois que vous l'entendez, si vous ne l'avez pas déjà fait."

Quelles sont les meilleures pratiques ici, Duck ?

Évidemment, une chose que vous pouvez faire est simplement de désactiver l'accès Web externe jusqu'à ce qu'un correctif soit disponible.

Vous pouvez simplement éteindre votre serveur IIS et ça ira !

CANARD.  Je soupçonne que de nombreuses entreprises ne seront pas dans cette position.

Et Microsoft énumère deux choses qu'ils disent… eh bien, ils ne disent pas, "Cela fonctionnera certainement."

Ils suggèrent que cela limitera considérablement votre risque.

La première est qu'il existe une règle de réécriture d'URL que vous pouvez appliquer à votre serveur IIS. (Je crois comprendre que c'est IIS qui accepte la connexion entrante qui se transforme en accès aux services Web Exchange [EWS].)

Il existe donc un paramètre IIS que vous pouvez définir pour rechercher les exploitations probables du premier trou, ce qui empêchera le démarrage du déclenchement de PowerShell.

Et il existe des ports TCP que vous pouvez bloquer sur votre serveur Exchange.

Je crois que c'est le port 5985 et 5986, qui arrêtera ce qu'on appelle Accès à distance PowerShell… cela empêchera ces commandes d'exécution à distance PowerShell malveillantes d'être insérées dans le serveur Exchange.

Notez, cependant, que Microsoft dit que cela «limitera» votre exposition, plutôt que de promettre qu'ils savent que cela résout tout.

Et c'est peut-être parce qu'ils soupçonnent qu'il existe d'autres moyens de déclencher cela, mais ils n'ont tout simplement pas encore tout à fait compris ce qu'ils sont. [DES RIRES]

Aucun paramètre n'est quelque chose que vous faites dans Exchange lui-même.

L'un d'eux est dans IIS, et l'autre est une sorte de règle de filtrage de réseau.

CHET.  Eh bien, c'est utile pour nous permettre de traverser les prochains jours pendant que Microsoft nous donne une solution permanente.

La bonne nouvelle est que je pense à beaucoup de logiciels de sécurité, qu'il s'agisse d'un IPS qui peut être intégré dans votre pare-feu, ou de produits de sécurité des terminaux que vous avez pour protéger votre infrastructure Microsoft Windows Server…

… les attaques pour cela, dans de nombreux cas (au moins les premiers rapports), ressemblent beaucoup à ProxyLogon, et, par conséquent, il n'est pas clair si les règles existantes protégeront contre ces attaques.

Ils peuvent, mais en plus de cela, la plupart des fournisseurs semblent essayer de les resserrer un peu, pour s'assurer qu'ils sont aussi prêts que possible, sur la base de tous les indicateurs qui ont été actuellement partagés publiquement, afin qu'ils détectent et vous envoyer des alertes si celles-ci devaient se produire sur vos serveurs Exchange.

CANARD.  C'est exact, Chester.

Et la bonne nouvelle pour les clients Sophos est que vous pouvez suivre les détections spécifiques à Sophos si vous souhaitez consulter vos journaux.

Pas seulement pour l'IPS, qu'il s'agisse de l'IPS sur le pare-feu ou sur le terminal, mais nous avons également un ensemble de règles de comportement.

Vous pouvez suivre ces noms de détection si vous voulez aller les chercher… suivez cela sur le @SophosXops Fil Twitter.

Au fur et à mesure que nous recevons de nouveaux noms de détection que vous pouvez utiliser pour la chasse aux menaces, nous les publions ici afin que vous puissiez les rechercher facilement :

Sophos X-Ops a ajouté les détections suivantes :

Troj/WebShel-EC et Troj/WebShel-ED détectent les webshells discutés dans les attaques.

Signature IPS sid:2307757 basée sur les informations publiées par Microsoft pour Sophos XG Firewall ainsi que Sophos Endpoint IPS.

– Sophos X-Ops (@SophosXOps) 30 septembre 2022

CHET.  Je suis sûr que nous aurons plus à dire sur le podcast de la semaine prochaine, que ce soit Doug qui vous rejoigne ou que je sois à nouveau à la place des invités.

Mais je suis assez confiant que nous ne pourrons pas mettre cela au lit avant un bon moment maintenant….

CANARD.  Je pense que, comme ProxyShell, comme Log4Shell, il y aura un écho qui se répercutera pendant un certain temps.

Alors peut-être ferions-nous mieux de dire, comme nous le faisons toujours, Chester :

Jusqu'à la prochaine fois…

TOUS LES DEUX.  Restez en sécurité.

[MODÈME MUSICAL]