Les attaques de type «homme au milieu» sont-elles extrêmement rares?
In "Quelques réflexions sur la controverse de la liste de contacts iPhone et la sécurité des applications" , blog cdixon
Chris Dixon fait une déclaration sur la sécurité Web
De nombreux commentateurs ont suggéré qu'un risque de sécurité principal est le fait que les données sont transmises en texte brut. Le chiffrement sur le fil est toujours une bonne idée, mais en réalité, les attaques de type "homme du milieu" sont extrêmement rares. Je m'inquiéterais principalement de la des cas beaucoup plus courants de 1) quelqu'un (initié ou étranger) volant dans la base de données de l'entreprise, 2) une assignation à comparaître du gouvernement pour la base de données de l'entreprise. La meilleure protection contre ces risques consiste à crypter les données de manière à ce que les pirates et l’entreprise elle-même ne puissent pas les décrypter (ou ne pas envoyer les données aux serveurs en premier lieu).
Je me demande s'il existe des données froides, dures et réelles pour confirmer cette affirmation - les attaques de type "homme au milieu" sont-elles réellement rares dans le monde réel, sur la base des données recueillies à partir d'intrusions réelles ou d'incidents de sécurité?
Ma ressource actuelle préférée pour données froides, dures et réelles est le Verizon 2011 Data Breach Investigations Report . Un extrait de la page 69 du rapport:
Actions
Les trois principales catégories d'actions contre les menaces étaient le piratage, les logiciels malveillants et les réseaux sociaux. Les types d'actions de piratage les plus couramment utilisés étaient l'utilisation de données d'identification de connexion volées, l'exploitation de portes dérobées et les attaques de l'homme du milieu.
En lisant cela, j'en déduis que c'est une action secondaire utilisée une fois que quelqu'un a pris pied dans le système, mais les données de la Dutch High Tech Crime Unit disent que c'est assez crédible. Sur les 32 violations de données qui constituaient leurs statistiques, 15 impliquaient des actions MITM.
Mais ne vous arrêtez pas là. L'ensemble de ce rapport est une mine d'or de lecture et le meilleur travail que j'ai rencontré pour démontrer où se trouvent réellement les menaces.
Pour des références plus floues aux attaques et méthodes MiTM, voir aussi cette excellente réponse aux attaques MITM - quelle est leur probabilité? Sur Serverfault.
J'irais plus loin en disant que toute instance d'une racine SSL crachant un mauvais certificat est le signe d'une attaque, sinon ce serait des compromis assez inutiles. Enfin, parce que je suis ce mec, j'essaierais certainement de me raccorder à votre boîtier réseau à l'extérieur du bâtiment si je faisais votre pentest. On peut faire des choses incroyables avec une radio logicielle même sur une connexion filaire.
La réponse simple est non - il existe une grande variété de preuves que ce type d'attaque est courant.
Certains des contrôles introduits par les banques (authentification à deux facteurs, etc.) étaient en partie nécessaires pour lutter contre les attaques MITM de plus en plus courantes contre les clients.
Bien qu'il existe d'autres formes d'attaques (la compromission du client est bonne) qui peuvent maintenant être plus faciles à exécuter grâce à l'utilisation de logiciels malveillants pour placer un cheval de Troie sur le PC client, MITM est toujours relativement facile dans la plupart des cas.
Le fait essentiel à retenir est que les criminels ont tendance à travailler sur un bon retour sur investissement. Le ROI d'un attaquant est très bon:
- faible risque d'être pris
- faible risque physique
- un certain effort pour coder l'exploit peut conduire à un gain monétaire réel
- le code peut ensuite être réutilisé ou vendu à d'autres criminels
Comme l'a dit @CanBerk, nous n'obtiendrons jamais de protocoles "complètement sécurisés", mais rendre la vie plus difficile aux criminels est une solution partielle. Le MITM ne disparaîtra pas tant qu'il ne sera pas rendu trop difficile pour être rentable.
Le compromis récent de l'autorité de certification DigiNotar a entraîné l'émission de plus de 500 faux certificats pour google.com, Microsoft.com, cia.gov et des centaines d'autres sites. Ces certificats ont en quelque sorte fait leur chemin dans 40 FAI iraniens différents, entraînant une attaque massive de l'homme au milieu , confirmé pour avoir a touché plus de 300 000 utilisateurs iraniens au cours de plusieurs mois.
Le (s) pirate (s) responsable (s) - confirmé (e) être le (s) même (s) responsable (s) de la attaque antérieure sur le CA Comodo - prétend avoir un accès complet à cinq autres CA, bien qu'il (ils) seulement nommé l'un d'eux .
Alors oui, Les attaques de l'homme du milieu sont une menace très réelle , même aujourd'hui.
Remarque: pour éviter ce type d'attaques, envisagez d'utiliser un programme/addon pour suivre les certificats pour les modifications suspectes, comme Certificate Patrol , ou essayez l'un des fantaisie de nouveaux remplacements pour le modèle d'autorité de certification dont tout le monde parle.
Cette réponse concerne principalement la déclaration de Chris Dixon plus que la réponse "Combien d'attaques proviennent de MiTM".
Si nous affirmons la manière différente dont on pourrait éventuellement devenir MiTM et les conséquences données, je pense que nous pouvons tirer quelques conclusions quant à savoir si nous nous soucions de la prévalence des attaques MiTM.
Si nous examinons certains risques pour les différentes situations, nous pourrions avoir quelque chose comme:
- Quelqu'un qui vole la base de données en exploitant l'application Web elle-même?
- Quelqu'un attaque un utilisateur/administrateur via une attaque MiTM
Je dirais que le premier a un impact beaucoup plus important (en général) et devrait à bien des égards être le plus atténué et traité le premier.
Donc, pour que le point 2 l'emporte sur le point 1, je pense que MiTM devrait vraiment être fou et fou pour que nous le valorisions aussi haut qu'un obstacle de sécurité que le point 1 (comme Chris l'indique dans la citation)!
Maintenant, si nous voyons les différents vecteurs d'attaque. D'abord pour MiTM. Pour devenir MiTM, on pourrait par exemple:
- Posséder un point d'accès sans fil escroc. C'est trivial, mais pour une attaque ciblée, vous devez être au même emplacement physique que la victime à l'aide de votre application Web.
- Reniflez des données sans fil non cryptées ou des données transitant par un HUB (elles existent même plus?)
- Utilisez ARP Poisoning pour attaquer les utilisateurs. Pas anodin sauf si vous êtes sur le même réseau que les utilisateurs ciblés utilisant votre webapp.
- Empoisonnement du cache DNS. Pour que cela fonctionne, vous devez empoisonner le DNS utilisé par les utilisateurs ciblés. Si le DNS n'est pas correctement configuré, cette attaque devient quelque peu triviale à effectuer, mais il y a beaucoup à faire pour que cela fonctionne.
- Attaques de phishing. Ceux-ci trompent toujours les utilisateurs naïfs et naïfs, mais une grande partie de la responsabilité incombe à l'utilisateur.
Tout cela pour simplement attaquer un ou un petit sous-ensemble d'utilisateurs. Même alors, attaquer ces utilisateurs leur donnera un avertissement dans leurs navigateurs (il existe également des moyens d'attaquer cela, mais je ne le prends pas ici). Ce n'est qu'en compromettant une autorité de certification racine ou en trouvant une faille dans l'algorithme utilisé pour générer les certificats que vous serez autorisé à vous faire passer pour un émetteur de certificat de confiance.
Si, d'un autre côté, nous examinons toutes les choses potentiellement désagréables que nous pouvons voir si nous n'investissons pas dans une sécurité suffisante de la webapp elle-même, nous voyons des vecteurs d'attaque comme:
- Injection SQL - triviale et facile à exploiter et à découvrir. Impact de dégâts très élevé.
- XSS (Cross Site Scripting) - facile à découvrir, plus difficile à exploiter. Je pense que nous verrons de plus en plus d'impact sur les utilisateurs à l'avenir. Je prévois que cela devient la tendance "nouvelle injection SQL" que nous avons vue au cours des jours.
- CSRF (Cross Site Request Forgery) - Modéré à découvrir, modéré à exploiter. Cela nécessiterait que les utilisateurs naviguent vers un site déjà possédé, déclenchant une demande à votre application Web qui ferait une transaction au nom de l'utilisateur.
Donc, en mentionnant simplement ces quelques méthodes populaires pour attaquer la webapp et devenir MiTM, je laisserais le soin à une analyse spécifique des risques/conséquences de l'organisation donnée que vous essayez de sécuriser, si vous devez ou non défendre vos utilisateurs directement par en mettant en œuvre SSL ou en défendant la webapp dans son ensemble (ce qui inclut également la propriété intellectuelle, les données utilisateur, les données sensibles, les données potentielles qui pourraient enfreindre d'autres applications, etc.).
Donc, à mon humble avis, je suis tout à fait d'accord avec la déclaration de Chris Dixon. Donnez la priorité à la sécurisation de la webapp autant que vous le pouvez avant de commencer à penser à sécuriser la couche de transport.
Edit : Sur une note latérale: Des pages comme Facebook, Gmail et d'autres ont été soumises à de lourdes attaques MiTM pendant le sillage de Firesheep. Cela ne pouvait être atténué que par SSL et la sensibilisation.
Cependant, si vous y réfléchissez, renifler le trafic sans fil avec Firesheep et détourner les sessions nécessiterait que le LAN sans fil auquel vous êtes connecté ne soit pas crypté.
Quand je fais la guerre aujourd'hui, cela a considérablement réduit le nombre d'AP sans fil ouverts et également le nombre d'AP activés WEP. Nous voyons de plus en plus de points d'accès cryptés WPA2 qui, dans la plupart des cas, nous offrent suffisamment de sécurité.
Maintenant, quel est le risque que quelqu'un crée un outil simple et pratique pour renifler et détourner vos sessions d'utilisateurs? Quel est l'impact pour ces utilisateurs? Il peut également être atténué de différentes manières (ré-authentifier l'utilisateur lorsqu'il provient de différentes empreintes en même temps, avertir l'utilisateur lorsque quelque chose ne va pas (gmail en est un bon exemple)).
Il n'a trouvé aucun livre statique ou blanc contenant les données réelles que vous vouliez avoir.
Cependant, je voudrais ajouter que les attaques MitM au sein des entreprises se produisent quotidiennement et plus d'une fois. Plusieurs fournisseurs de sécurité ont des solutions pour analyser le trafic crypté (par exemple, Palo Alto Networks ) et au moins la société pour laquelle je travaille actuellement a activé cette fonctionnalité.
Pour ce faire, le pare-feu/périphérique proxy reçoit simplement un certificat de l'autorité de certification interne (CA) qui est déjà approuvé par tous les clients. Lorsqu'une application demande une connexion sécurisée, le pare-feu/périphérique proxy génère à la volée un nouveau certificat pour le serveur cible et l'envoie au client. Étant donné que le client fait confiance à l'autorité de certification interne, il fait également confiance au certificat du périphérique et démarre avec plaisir une connexion "sécurisée".
Je suis sûr que renifler des mots de passe sur les réseaux sans fil est extrêmement courant. Il suffit de regarder le nombre de didacticiels disponibles sur le Web à partir d'un simple Recherche Google ou Recherche Bing .
Je suis d'accord avec daramarak qu'il serait assez difficile de trouver des données réelles sur les attaques MitM. L'une des raisons en est que les attaques MitM sont par nature généralement ciblées sur des individus, tandis que des attaques comme DDoS ou injection SQL ciblent généralement des entreprises, des organisations, etc.
Par conséquent, alors que nous voyons un rapport DDoS/injection/quel que soit le rapport presque tous les jours, les informations concernant les attaques MitM sont généralement académiques (par exemple, "Twitter était DDoS!" Vs. "SSL est vulnérable à MitM")
Cependant, il convient de noter que "rare" ne signifie pas nécessairement "difficile". La plupart des attaques MitM sont sans doute beaucoup plus faciles à tirer que la plupart des autres types d'attaques, et de nombreux protocoles que nous utilisons quotidiennement sont vulnérables à de telles attaques d'une manière ou d'une autre, simplement parce qu'il est assez difficile de concevoir un protocole complètement sécurisé contre MitM. C'est en fait le cas pour la plupart des problèmes de sécurité, la plupart des solutions sont "au mieux" plutôt que "complètement et absolument sécurisées".
Par conséquent, je pense que la principale raison pour laquelle les attaques MitM sont moins courantes est qu'il n'y a généralement pas besoin/incitation à en effectuer une.