Est-il jamais sûr d'ouvrir un fichier HTML suspect (par exemple, une pièce jointe à un e-mail)?
Si je reçois un e-mail contenant une pièce jointe appelée quelque chose comme safe-link.html serait-il jamais sûr d'ouvrir ce fichier?
De toute évidence, les fichiers HTML peuvent contenir des scripts malveillants qui pourraient s'exécuter lorsqu'ils sont ouverts avec un navigateur. Cependant, je me demande si des violations pourraient se produire lors du téléchargement du fichier et de son ouverture dans Bloc-notes /autre éditeur de texte de base plutôt que dans un navigateur Web?
Contexte
Je demande seulement parce que la société pour laquelle je travaille aime envoyer de temps en temps des e-mails de "phishing" de test, et le dernier avait une pièce jointe HTML. J'ai immédiatement soupçonné l'e-mail (je n'ai donc pas cliqué pour ouvrir la pièce jointe dans un navigateur), mais j'ai été intrigué de voir s'il s'agissait en fait d'un autre test!
J'ai donc suggéré à mes collègues d'ouvrir le fichier avec le Bloc-notes. Nous sommes tous assez avertis pour lire le HTML, donc repérerions immédiatement l'habituel "Si ce n'était pas seulement un test, votre ordinateur serait compromis!", Mais ils étaient extrêmement inquiets que j'avais pensé à interagir avec le fichier. .
Je suis raisonnablement convaincu que tout script malveillant dans un fichier html devrait être ouvert dans un navigateur Web pour qu'il ait un effet.
Mes collègues sont-ils trop prudents ou étais-je trop zélé?
Je préconise "mieux vaut prévenir que guérir", je ne pense donc pas qu'ils aient eu tort de ne pas l'ouvrir; Je ne pense pas non plus qu'il était complètement dangereux d'ouvrir avec quelque chose comme le Bloc-notes. Je suis très intrigué de le découvrir!
"Gotchas" que je connais:
Je pense que la modifier dans un outil de développement de site Web plus complexe (qui rend la page en aperçu) pourrait être dangereux.
En outre, je suis conscient que le simple fait de double-cliquer sur le fichier (même si le paramètre par défaut "ouvrir avec" est défini comme un éditeur de texte) peut être dangereux. C'est parce que quelque chose comme readme.txt pourrait en fait être readme.txt.exe avec des extensions de fichiers cachées dans quelque chose comme l'Explorateur de fichiers Windows.
Les éditeurs et les bibliothèques courantes utilisées par les éditeurs peuvent présenter des vulnérabilités telles que des 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 "vaporisez-priez".
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énuation
Certaines techniques d'atténuation comme Randomization Layout Space Address (ASLR) , Data Execution Prevention et ayant un anti-virus avec un "exploit blocker" (ceux-ci sont généralement capables de reconnaître le débordement de base attaques, entre autres) peuvent aider à rendre certaines attaques inutiles.
Mises à jour de logiciel
Toutes ces techniques ne sont bien sûr pas un substitut à garder votre logiciel ( [~ # ~] tout [~ # ~] je pourrais ajouter votre logiciel) up -à ce jour. Garder votre logiciel à jour est la meilleure stratégie de sécurité possible. Cela est parfois négligé ou banalisé en raison de son manque de rétroaction. Un anti-virus vous criant: "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 anti-virus avec une personne enfonçant ses doigts dans les trous d'une digue pour empêcher l'eau de passer. Il fait de son mieux pour empêcher l'inondation, mais il est probable qu'il ne disposera pas de suffisamment de doigts pour remplir tous les trous (ou en manquer quelques-uns). Les correctifs logiciels corrigent ces trous.
Bottom Line
Vous ne pouvez jamais être sûr de ne pas avoir de 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 malveillant va être ouvert dans un navigateur, pas dans un éditeur).
Oh, ces réponses sont trop 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 sait quel éditeur vous utilisez, leur objectif n'est pas de gâcher réellement 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é probable non plus, 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 qui devraient être couverts pour que quelque chose comme ça ait un effet détectable.
Dites à vos collègues de descendre de votre dos et d'être plus prudents eux-mêmes. Permettez-moi de souligner que vous vous êtes cependant enfoncé dans ce trou et avez atteint le contraire de ce qui était prévu…. Si vous n'aviez pas annoncé que vous aviez regardé et ce que vous aviez vu, les gens qui ne connaissent manifestement rien à 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 l'attachement et vu le message, et se seraient un peu châtiés. Vous avez donc foiré le test informatique tout au long de la ligne, en mettant l'accent sur effet Dunning-Kruger qui est sans aucun doute la cause de l'envoi de ces tests. Arrête ça!
D'accord, donc techniquement, vous n'êtes jamais sûr à 100%. Oui, il pourrait y avoir des tentatives d'attaques contre votre éditeur de texte/visualiseur ASCII. Oui, quelqu'un aurait pu d'une manière ou d'une autre glisser par magie un DLL dans votre répertoire temporaire afin de jouer avec le retard du chargement du bloc-notes MS.
Mais en pratique, lorsque vous recevez un fichier HTML dans un e-mail de phishing, il va contenir du JavaScript malveillant ou plus probablement vous rediriger vers un site Web en ligne qui essaie de vous persuader de remettre les détails de votre carte de crédit/logins.
Donc, en pratique, examiner un tel fichier dans Notepad ++ est une façon 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 que mission/sécurité critique, pourquoi y a-t-il des e-mails? Pourquoi y aurait-il un 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.
Cela étant dit, vous devrez toujours faire face à 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 sous 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 que vous êtes (ou voulez être) plus intelligent que l'utilisateur moyen, voici quelques conseils:
- Pensez à lire le code source de l'e-mail, au lieu de l'ouvrir. Vous pourrez peut-être le faire directement depuis l'interface Webmail, ou en lisant les fichiers texte sur votre serveur, etc.
- Pensez à télécharger la pièce jointe à partir de la source, en copiant et en collant sa représentation base64. Ce sera simplement simple ASCII texte. Vous pouvez ensuite le reconvertir en binaire avec certains outils.
- Pensez à renommer le fichier, à l'enregistrer en tant que fichier potentiellement malveillant.txt au lieu de .html ou quel que soit le nom et l'extension dont il dispose.
- Pensez à ouvrir le fichier txt avec des éditeurs de texte très basiques, ou même des éditeurs hexadécimaux, ou même avec des outils de base très simples disponibles sur la ligne de commande qui n'afficheront que les caractères ASCII. Un exemple pourrait être
cat file.txt | lesssous Linux. (Remarque: pourquoicatavantless? Parce que j'ai remarqué quelessanalyse et convertit parfois certaines choses par défaut, comme la conversion de PDF en TXT. ce que les commandes font par défaut sur votre système de toute façon). - Pensez à ouvrir le fichier dans la machine virtuelle, qui doit être à jour et également déconnectée du réseau.
- Envisagez de faire la plupart de cela à la maison et n'en parlez jamais à votre patron ou à vos collègues. Ils peuvent voir cela comme 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 excellent OS compartimenté comme Qubes excelle. Qubes utilise un hyperviseur en métal nu durci pour garder les éléments à risque isolés 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 comme "Edit In DisposableVM" et "Afficher dans VM jetable" . En cliquant sur l'un de ces fichiers, vous instanciez automatiquement une machine virtuelle jetable (dispvm), puis vous envoyez le fichier à dispvm et le chargez 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 à l'appelant VM et le dispvm sera instantanément détruit. Remarque, cependant, ce processus en lui-même ne fait pas de doute fichier dans un fichier approuvé.
Pour certains types de fichiers (actuellement images et pdfs ), il existe également une option de menu pour convertir un fichier dans un état de confiance ... c'est-à-dire qu'un dispvm est utilisé pour traiter un pdf non approuvé et construire une version filtrée qui est chargé en arrière et peut être utilisé sans risque pour vos machines virtuelles habituelles où vous travaillez normalement. Cela est possible car l'outil de nettoyage d'origine accepte uniquement la représentation la plus prévisible des données demandées de la dispvm, telles que des images bitmap non compressées d'un nombre exactement attendu de pixels et d'octets; une fois que la version brute nettoyée est reçue, elle est recompressée au format attendu.
Il convient de noter que vous pouvez émuler le type de sécurité décrit ci-dessus en utilisant des outils plus familiers comme VirtualBox et VMware, mais le degré et la qualité de l'isolement sont peu probables pour correspondre aux niveaux atteints par un système dédié comme Qubes.
Alors que d'autres signalent des défauts, je dirais que vous avez fait la bonne chose.
Alors que vos autres collègues ont pris le parti de supposer que c'était mauvais, vous avez utilisé votre ensemble de compétences pour analyser la situation et vérifier son intention malveillante.
Vous aviez compris que vous ne devriez pas autoriser le navigateur à ouvrir le fichier, mais plutôt utiliser quelque chose qui 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, uniquement un avertissement de votre équipe informatique).
Si vous êtes suffisamment habile pour analyser les fichiers et faire le bon jugement, je trouverais cela plus sûr que vous avez une bonne compréhension de la protection contre les utilisateurs malveillants et de l'utilisation de vos compétences pour assurer votre sécurité.
Cependant, si vous n'avez pas la compétence pour vérifier que le code HTML et JavaScript n'est pas malveillant, vous ne devez 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.
N'essayez d'analyser une situation dans laquelle vous disposez des compétences appropriées pour analyser, et analysez la situation que 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écialement conçues pour interagir avec des éditeurs tels que le Bloc-notes.
Exemple: Notepad.exe, comme la plupart des programmes Windows, utilise des bibliothèques système. L'une de ces bibliothèques système charge shdocvw.dll (composant lié à Internet Explorer). shdocvw.dll a une dépendance de chargement différé sur une bibliothèque appelée 'ieshims.dll'.
Ce fichier .dll peut être recherché dans le répertoire courant et chargé à partir de là. Donc, si un attaquant le déployait avec le fichier .txt, il pourrait utiliser cette configuration comme un exploit pour charger son .dll et ensuite partir de là.
La solution à cela: tilisez votre propre éditeur/visualiseur de texte qui ne dépend d'aucun composant Windows/bibliothèques. Le mien s'appelle simplement Edit.ExE, 100% indépendant de toute ressource externe et 100% sûr en ce qui concerne le contenu traité (lit tout directement comme ASCII/texte sans détection de contenu). Vous n'avez pas un; utilisez un très obscur que personne ne prendrait la peine d'exploiter.