Les éditeurs et les bibliothèques courantes utilisées par les éditeurs peuvent avoir des vulnérabilités telles que les dépassements de tampon. Votre attaquant devrait savoir (ou deviner) quel éditeur vous utilisez et créer un exploit spécifiquement pour cet éditeur (il est peu probable que différents éditeurs aient les mêmes vulnérabilités à moins que la vulnérabilité ne réside dans une bibliothèque qu'ils ont en commun). Une attaque peut viser un éditeur populaire et être envoyée au plus grand nombre de personnes possible, la transformant essentiellement en une attaque "spray-n-prier".

Surface d'attaque

Un éditeur très simple comme le Bloc-notes de Microsoft a une surface d'attaque plus petite qu'un éditeur plus avancé (comme Visual Studio Code). Plus de code signifie généralement plus de vulnérabilités potentielles.

Atténuations

Certaines techniques d'atténuation comme Randomisation de la disposition de l'espace d'adresse (ASLR), Exécution des données La prévention et le fait d'avoir un antivirus avec un "bloqueur d'exploit" (ceux-ci sont généralement capables de reconnaître les attaques de débordement de base, entre autres) peuvent aider à rendre certaines attaques inutiles.

Mises à jour logicielles

Toutes ces techniques ne remplacent bien sûr pas la mise à jour de votre logiciel ( TOUS vos logiciels que je pourrais ajouter). Garder votre logiciel à jour est la meilleure stratégie de sécurité que l'on puisse avoir. Ceci est parfois négligé ou banalisé en raison de son manque de rétroaction. Un anti-virus qui vous crie: "Vous êtes protégé!" envoie un signal beaucoup plus fort qu'une mise à jour logicielle qui corrige silencieusement les vulnérabilités en arrière-plan. J'ai tendance à comparer un programme antivirus avec une personne qui met les doigts dans les trous d'une digue pour empêcher l'eau de passer. Il fait de son mieux pour empêcher les inondations d'entrer, mais il est probable qu'il n'aura pas assez de doigts pour remplir tous les trous (ou en manquer quelques-uns tout à fait). Les correctifs logiciels corrigent ces trous.

Conclusion

Vous ne pouvez jamais être sûr de ne pas passer une mauvaise journée en ouvrant n'importe quel type de fichier dans n'importe quel type de programme. Cependant, certains programmes (comme les éditeurs) sont beaucoup plus difficiles à attaquer en raison de leur faible encombrement ou de leur conception sécurisée et sont donc moins susceptibles d'être ciblés pour des attaques de masse (en particulier parce qu'un attaquant est susceptible de supposer que leur fichier .html diabolique va être ouvert dans un navigateur, pas dans un éditeur).

Oh, ces réponses sont bien trop sophistiquées pour votre situation. Il est très peu probable que votre service informatique utilise une solution de contournement sophistiquée en supposant qu'il sache quel éditeur vous utilisez, son objectif n'est pas de gâcher vos systèmes. Le bloc-notes ne fera rien avec une image ou une pièce jointe, quoi qu'il arrive, et le texte que vous avez vu n'a certainement rien fait de répréhensible pour votre système. Cela n'aurait pas été non plus probable, même s'il s'agissait d'une véritable attaque, car les éditeurs sont des outils très personnels et il y en a beaucoup et beaucoup d'entre eux qui devraient être couverts pour que quelque chose de ce genre ait un effet détectable.

Dites à vos collègues de vous lever et de faire plus attention eux-mêmes. Permettez-moi juste de souligner que vous vous êtes plongé dans ce trou et que vous avez réalisé le contraire de ce qui était prévu…. Si vous n'aviez pas annoncé que vous regardiez et ce que vous avez vu, les gens qui ne savent clairement rien de la sécurité informatique ne vous harceleraient pas et ne se sentiraient pas supérieurs à ce sujet. Au lieu de cela, certains d'entre eux auraient ouvert la pièce jointe et vu le message, et se sont un peu châtiés. Vous avez donc raté le test informatique tout au long de la ligne, en mettant l'accent sur l ' effet Dunning-Kruger qui est sans aucun doute la cause de l'envoi de ces tests. Arrêtez ça!

D'accord, donc, techniquement , vous n'êtes jamais sûr à 100%. Oui, il pourrait y avoir des tentatives d'attaques sur votre éditeur de texte / visualiseur ASCII. Oui, quelqu'un pourrait avoir en quelque sorte glissé une DLL dans votre répertoire temporaire afin de gâcher le chargement différé du Bloc-notes MS.

Mais en pratique , lorsque vous recevez un fichier HTML dans un e-mail d'hameçonnage, il contiendra du code JavaScript malveillant ou vous redirigera probablement vers un site Web en ligne qui tente de vous persuader de transmettre les détails / connexions de votre carte de crédit.

Donc, en pratique , examiner un tel fichier dans Notepad ++ est un moyen parfaitement raisonnable de voir ce qui vous a été envoyé. La réaction de vos collègues semble injuste, sauf si vous travaillez dans un silo nucléaire… et si votre travail est vraiment cette mission / sécurité critique, pourquoi y a-t-il des e-mails? Pourquoi y aurait-il accès à Internet? Et, s'il n'y en a pas, pourquoi auriez-vous besoin d'audits / tests / pots de miel de phishing? Quelqu'un quelque part est trop paranoïaque.

Nous pouvons essayer de réduire notre risque à zéro, mais le seul moyen d'y parvenir est de ne pas utiliser d'ordinateur.

Tout cela étant dit, cependant , vous aurez toujours affaire à des gens stupides, alors gardez peut-être cette activité pour vous la prochaine fois. ;)

En général, ce n'est pas sûr car si vous recevez un e-mail suspect ou inattendu, quelle que soit la pièce jointe, il ne doit pas être ouvert. C'est la chose la plus sûre à faire. Surtout si vous êtes sur Windows, qui est connu pour exécuter des choses quand il ne devrait pas, et qui est le système d'exploitation le plus ciblé par les attaquants, exécutant les applications les plus ciblées.

Mais si vous voulez quand même l'ouvrir, peut-être parce que vous êtes un passionné d'INFOSEC ou que vous pensez être (ou vouloir être) plus intelligent que l'utilisateur moyen, voici quelques conseils:

• Envisagez de lire le code source de l'e-mail au lieu de l'ouvrir. Vous pourrez peut-être le faire directement depuis l'interface de la messagerie Web, ou en lisant les fichiers texte sur votre serveur, etc.
• Pensez à télécharger la pièce jointe depuis la source, en copiant et collant sa représentation base64. Ce ne sera qu'un simple texte ASCII. Vous pouvez ensuite le reconvertir en binaire avec certains outils.
• Envisagez de renommer le fichier, en l'enregistrant en tant que fichier potentiellement malveillant.txt au lieu de .html ou quel que soit le nom et l'extension qu'il possède.
• Pensez à ouvrir le fichier txt avec des éditeurs de texte très basiques, voire des éditeurs hexadécimaux, ou même avec des outils basiques très simples disponibles sur la ligne de commande qui n'afficheront que les caractères ASCII. Un exemple pourrait être cat file.txt | less sous Linux. (Remarque: pourquoi cat avant less ? Parce que j'ai remarqué que less analyse et convertit parfois certaines choses par défaut, comme la conversion de PDF en TXT. Donc attention, il vaut mieux vérifier de toute façon ce que font les commandes par défaut sur votre système).
• Pensez à ouvrir le fichier dans la machine virtuelle, qui doit être à jour et également déconnectée du réseau.
• Pensez à faire la plupart de ces choses à la maison et n'en parlez jamais à votre patron ou à vos collègues. Ils pourraient y voir un comportement dangereux, une violation de la politique de sécurité ou quelque chose qui pourrait vous causer des problèmes de toute façon.

Ses situations comme celle-ci, où le risque pour des objets particuliers est une quantité inconnue, qu'un OS fortement compartimenté comme Qubes excelle. Qubes utilise un hyperviseur sans système d'exploitation renforcé pour isoler les éléments à risque des zones sensibles (comme les fichiers personnels et le système d'exploitation principal). Il isole même les appareils à risque. Cet isolement est exprimé et contrôlé via l'interface graphique de manière assez conviviale:

Dans l'exemple ci-dessus, un clic droit sur un fichier html dans KDE Dolphin vous permet de choisir des options telles que "Modifier dans DisposableVM" et "Afficher dans DisposableVM" . Cliquer sur l'un ou l'autre de ces éléments instanciera automatiquement une machine virtuelle jetable (dispvm), puis enverra le fichier à dispvm et le chargera dans l'application associée. Cela ne prend que quelques secondes. Lorsque vous avez terminé avec l'application d'édition, la version modifiée sera renvoyée à la VM appelante et le dispvm sera instantanément détruit. Notez, cependant, que ce processus en lui-même ne transforme pas un fichier non approuvé en un fichier de confiance.

Pour certains types de fichiers (actuellement les images et les pdfs), il existe également une option de menu pour conversion d'un fichier à un état de confiance ... c'est-à-dire qu'un dispvm est utilisé pour traiter un pdf non approuvé et construire une version nettoyée qui est rechargée et peut être utilisée sans risque pour vos VM habituelles sur lesquelles vous travaillez normalement. Ceci est possible parce que l'outil de nettoyage d'origine accepte uniquement la représentation la plus prévisible des données demandées en retour du dispvm, comme des images bitmap non compressées d'un nombre exact de pixels et d'octets prévus; une fois la version brute purgée reçue, elle est recompressée dans le format attendu.

Il convient de noter que vous pouvez émuler le type de sécurité décrit ci-dessus en utilisant plus familier des outils comme VirtualBox et VMware, mais le degré et la qualité de l'isolement sont peu susceptibles de correspondre aux niveaux atteints par un système dédié comme Qubes.

Pendant que d'autres signalent des failles, je dirais que vous avez fait la bonne chose.

Pendant que vos autres collègues prenaient la route de supposer que c'était mauvais, vous avez utilisé vos compétences pour analyser la situation et vérifier qu'elle intention malveillante.

Vous aviez compris que vous ne devriez pas autoriser le navigateur à ouvrir le fichier, mais plutôt utiliser quelque chose avec lequel il n’était pas destiné à être ouvert par le destinataire. Vous avez analysé le code et vous avez pu vérifier qu'il avait une intention malveillante (dans ce cas, seulement un avertissement de votre équipe informatique).

Si vous êtes assez habile pour analyser les fichiers et faire le bon jugement, je trouverais cela plus en veillant à ce que vous ayez une bonne compréhension de la protection contre les utilisateurs malveillants et d'utiliser vos compétences pour assurer votre sécurité.

Cependant, si vous n'avez pas les compétences nécessaires pour vérifier le code HTML et le code JavaScript n'est pas malveillant, vous ne devriez tout simplement pas l'ouvrir et supposer qu'il est malveillant car vous ne pouvez pas garantir sa sécurité même si vous l'avez ouvert dans le bloc-notes.

Essayez uniquement d'analyser une situation dans laquelle vous avez les compétences appropriées pour analyser et analyser la situation uniquement si vous attendez l'e-mail ou s'il provient d'une source connue.

Oui, des violations peuvent se produire lors du téléchargement du fichier, puis de son ouverture dans le Bloc-notes / autre éditeur de texte de base largement utilisé , car les charges utiles peuvent être spécifiquement conçues pour interagir avec des éditeurs tels que le Bloc-notes.

Exemple: Notepad.exe, comme beaucoup de programmes Windows, utilise des bibliothèques système. Une de ces bibliothèques système charge shdocvw.dll (composant lié à Internet Explorer). shdocvw.dll a une dépendance de retard de chargement sur une bibliothèque appelée «ieshims.dll».

Ce .dll pourrait être recherché dans le répertoire courant et chargé à partir de là. Donc, si un attaquant le déploie avec le fichier .txt, il pourrait utiliser cette configuration comme un exploit pour charger son .dll et ensuite partir de là.

La solution à ceci: utilisez votre propre éditeur / visualiseur de texte qui ne dépend d'aucun composant Windows / bibliothèques. Le mien s'appelle juste Edit.ExE, 100% indépendant de toute ressource externe et 100% sûr en ce qui concerne le contenu traité (lit tout directement en ASCII / texte sans détection de contenu). Vous n'en avez pas; utilisez une personne très obscure que personne ne prendrait la peine d'exploiter.

Si vous êtes un scientifique nucléaire paranoïaque travaillant dans une base secrète en Antarctique, peut-être. Sinon, personne ne passera le temps à implémenter des débordements de tampon, etc.

La première chose qui vient à l'esprit de la plupart des gens lorsqu'ils voient un fichier HTML est probablement de l'ouvrir avec un navigateur . S'ils voulaient vous "tromper" pour que vous l'éditions avec Notepad ++ ou similaire, ce serait probablement un fichier texte, un fichier JSON, etc.

Donc non, vous n'êtes probablement pas en danger, mais oui, vous pourriez l'être.