Une faille dans AirDrop permet de siphonner numéros de téléphone et adresses email

Une faille dans AirDrop permet de siphonner numéros de téléphone et adresses email

Une faille dans AirDrop permet de siphonner numéros de téléphone et adresses email

AirDrop est une technologie d’Apple qui permet à deux appareils proches physiquement (iOS ou Mac) de s’échanger des données. Par défaut, on ne peut le faire qu’avec les contacts, mais un réglage peut ouvrir la capacité à tout le monde ou la désactiver.

Avant tout échange, les deux appareils doivent négocier. Avec le réglage par défaut, la personne recevant le fichier doit simplement avoir l’expéditeur dans ses contacts. Les comparaisons de numéros de téléphone et d’adresses email ne se font pas en clair : les informations sont hachées.

Des chercheurs de l’université allemande de Darmstadt se sont aperçus que le hachage utilisé par Apple n’était pas assez robuste pour masquer les informations de la personne à qui l’on souhaite envoyer un fichier.

Ils ont donc créé une méthode permettant d’obtenir les informations par force brute et pour les collecter. Il leur suffit d’être proches de la victime, le mécanisme se substituant à celui d’Apple.

Ils affirment que l’entreprise a été prévenue en mai 2019, mais qu’elle n’a jamais reconnu le problème. Si vous craignez pour la sécurité de votre appareil iOS ou de votre Mac, vous pouvez toujours désactiver AirDrop et ne le réactiver qu’en cas de besoin.

Commentaires (8)



Si vous craignez pour la sécurité de votre appareil iOS ou de votre Mac, vous pouvez toujours désactiver AirDrop et ne le réactiver qu’en cas de besoin.




Limiter la surface d’exposition est un des fondamentaux en terme de sécurité, il est bon de le rappeler.


Je comprend vos remarques mais c’est justement la promesse fonctionnelle d’AirDrop d’être sans friction. La connexion AirDrop n’est justement pas active par défaut, il faut préalablement que les deux téléphones s’échangent des hash via bluetooth et constatent chacun de leur côté que le hash envoyé par l’autre correspond bien au numéro de tel / email d’un contact connu. La comparaison se fait en local. Si ça matche, la connexion est établie mais pas le transfert qui nécessite une approbation de l’utilisateur. La faille ici est tristement simple : l’algo de hash utilisé par Apple est rapide à bruteforcer (en même temps t’as juste à tester tous les numéros de téléphone possibles, si l’algo est trop rapide, c’est fichu)



Pas la peine d’être condescendant à propos du “client Apple incapable de réfléchir”, les “clients Apple” sont pas des abrutis plus que les autres. Ils sont juste, comme l’immense majorité de la population, pas des experts en cybersécurité, simplement des gens normaux qui s’envoient la photo du petit ou un scan de facture de l’iPhone vers le mac par AirDrop.



Je t’invite à relire l’article de NXI mais aussi l’articlé lié pour te rendre compte que la surface d’attaque d’AirDrop est très réduite “by design”. D’ailleurs la faille ne permet rien d’autre que de deviner par brute force via la négo, le numéro de téléphone et l’adresse mail de la cible. C’est déjà beaucoup, on est d’accord, mais cela ne permet en aucun cas d’établir une connexion à l’insu de la victime.



Par contre on peut déplorer qu’Apple ait ignoré l’alerte une fois de plus, d’autant que le fix semble simple à mettre en place et que les chercheurs sont allés jusqu’à proposer une implémentation fonctionnelle de la solution. Ca sent la décision foireuse du genre “ouais mais ça va péter AirDrop entre deux utilisateurs qui n’ont pas la dernière version d’iOS / macOS”.


jpaul

Je comprend vos remarques mais c’est justement la promesse fonctionnelle d’AirDrop d’être sans friction. La connexion AirDrop n’est justement pas active par défaut, il faut préalablement que les deux téléphones s’échangent des hash via bluetooth et constatent chacun de leur côté que le hash envoyé par l’autre correspond bien au numéro de tel / email d’un contact connu. La comparaison se fait en local. Si ça matche, la connexion est établie mais pas le transfert qui nécessite une approbation de l’utilisateur. La faille ici est tristement simple : l’algo de hash utilisé par Apple est rapide à bruteforcer (en même temps t’as juste à tester tous les numéros de téléphone possibles, si l’algo est trop rapide, c’est fichu)



Pas la peine d’être condescendant à propos du “client Apple incapable de réfléchir”, les “clients Apple” sont pas des abrutis plus que les autres. Ils sont juste, comme l’immense majorité de la population, pas des experts en cybersécurité, simplement des gens normaux qui s’envoient la photo du petit ou un scan de facture de l’iPhone vers le mac par AirDrop.



Je t’invite à relire l’article de NXI mais aussi l’articlé lié pour te rendre compte que la surface d’attaque d’AirDrop est très réduite “by design”. D’ailleurs la faille ne permet rien d’autre que de deviner par brute force via la négo, le numéro de téléphone et l’adresse mail de la cible. C’est déjà beaucoup, on est d’accord, mais cela ne permet en aucun cas d’établir une connexion à l’insu de la victime.



Par contre on peut déplorer qu’Apple ait ignoré l’alerte une fois de plus, d’autant que le fix semble simple à mettre en place et que les chercheurs sont allés jusqu’à proposer une implémentation fonctionnelle de la solution. Ca sent la décision foireuse du genre “ouais mais ça va péter AirDrop entre deux utilisateurs qui n’ont pas la dernière version d’iOS / macOS”.


Première des choses à faire, donc, n’activer le Bluetooth que quand on en a besoin. C’est ce que je fais avec mes appareils.
Meilleure sécurité, meilleure autonomie, tout bénef !



Cumbalero a dit:


Limiter la surface d’exposition est un des fondamentaux en terme de sécurité, il est bon de le rappeler.




J’allais rebondir sur ce passage. Effectivement, le b-a-ba de la sécurité est de n’activer de ce que l’on a besoin que lorsque l’on en a réellement besoin, puis de le désactiver dès que ce besoin disparait. Autrement dir : tout désactivé par défaut, n’activer que le strict nécessaire que lorsque l’on en a besoin, puis le désactiver aussitôt.


Ouais, mais c’est pas user friendly. Faudrait pas demander au client Apple de réfléchir non plus :troll:



Bref, sécurité et simplicité ne sont que rarement compatible.



Pas la peine d’être condescendant à propos du “client Apple incapable de réfléchir”, les “clients Apple” sont pas des abrutis plus que les autres. Ils sont juste, comme l’immense majorité de la population, pas des experts en cybersécurité, simplement des gens normaux qui s’envoient la photo du petit ou un scan de facture de l’iPhone vers le mac par AirDrop.




Ou ai-je dis que les client d’Apple sont des abrutis plus que les autre ?
L’ensemble du commentaire pointait sur le difficile compromis entre simplicité d’utilisation et sécurité.
La faille était dans un produit Apple, aurais-je du mentionner les utilisateurs Android et Windows aussi, pour ne vexer personne ?



Et il y avais un :troll: a la fin, non ?



Par principe, un système actif en permanence (pour simplifier la vie des utilisateurs) aura une surface d’attaque plus grande que si elle était activée a la demande. C’est tout.



XXC a dit:


Ou ai-je dis que les client d’Apple sont des abrutis plus que les autre ?




Ici :




XXC a dit:


Faudrait pas demander au client Apple de réfléchir non plus :troll:



L’ensemble du commentaire pointait sur le difficile compromis entre simplicité d’utilisation et sécurité. La faille était dans un produit Apple, aurais-je du mentionner les utilisateurs Android et Windows aussi, pour ne vexer personne ?




Pourquoi mentionner les utilisateurs tout simplement ? Sont-ils responsables du mauvais choix de hash d’Apple ?




Et il y avais un :troll: a la fin, non ?




Oui ?




Par principe, un système actif en permanence (pour simplifier la vie des utilisateurs) aura une surface d’attaque plus grande que si elle était activée a la demande. C’est tout.



(reply:1870007:Cumbalero) Oui. Mais un compromis peut/doit aussi exister entre sécurité et simplicité. Je ne dit pas que vous avez tort de faire le choix de désactiver le bluetooth quand vous n’en avez pas besoin, c’est très bien. Mais si vous avez besoin du service AirDrop pour ce qu’il est (un service rapide, simple, et prétendument sécurisé), couper le bluetooth coupe aussi tout l’intérêt du service, autant dans ce cas couper totalement AirDrop, ce qui est tout à fait faisable en un clic. Vous devez certes accepter une surface d’attaque étendue, mais vous êtes aussi en droit d’attendre d’Apple qu’elle défende cette surface.




N’activer le bluetooth que quand on veut utiliser AirDrop revient en quelque sorte à n’activer le réseau que quand on tu es sûr et certain qu’aucun autre appareil sur le réseau ne va tenter d’utiliser ARP ou DHCP comme vecteur d’attaque, cela rend la fonctionnalité inutile, et tu es en droit d’attendre de ton implémentation locale qu’elle te protège de ces attaques durant la négociation.



Cumbalero a dit:


Limiter la surface d’exposition est un des fondamentaux en terme de sécurité, il est bon de le rappeler.




C’est pas un peu pre-AJAX cette manière de penser Internet? Comme si on appuyait encore sur un bouton ON / OFF. Désactiver le bluetooth? Et mon apple watch j’en fais quoi? :troll:


Fermer