RGPD et conséquences : DomainTools fait appel dans l’affaire des whois des .NZ

RGPD
Source de l’image : mohamed_hassan via Pixabay

DomainTools poursuivi par le DNCL

En juin 2018, le registre du .NZ DNCL (Domain Name Commission Limited) avait attaqué la société américaine spécialisée dans les outils de surveillance et d’investigation, arguant que celle-ci violait les conditions générales d’utilisation du registre.

Le DNCL avait obtenu gain de cause et le tribunal fédéral de Washington avait accordé une injonction préliminaire interdisant à DomainTools de récupérer les données whois du .NZ et ordonnant la suppression des données utilisées dans des publications existantes, et ce pendant toute la durée du procès.

Depuis juin 2016, le registre du .NZ indiquait en effet dans ses conditions générales qu’il était désormais interdit de copier les données titulaires des noms de domaine.

DomainTools fait appel de l’injonction

Sans surprise, DomainTools, qui dans un premier temps avait indiqué que l’emploi de ces données était également d’intérêt général, ces dernières étant utilisées par ses clients dans le cadre de la lutte pour la cybersécurité, a fait appel de l’injonction provisoire.

Bien sûr, ce procès reflète les termes du débat qu’il avait eu lieu à l’ICANN quant au Règlement général sur la protection des données (RGPD).

DomainTools est d’ailleurs cité dans le brouillon d’un projet de loi américain révélé par l’Internet Governance Project, qui indique à ce titre que cette tentative serait menée par différents lobbys. Le Transparent, Open and Secure Internet Act of 2018, daté du 16 août 2018, mentionne deux possibilités d’évolutions :

  • La première, dite « large », propose le maintien d’un whois avec un spectre assez large d’informations (peu ou prou la même chose que nos whois ancienne mode)
  • la seconde, plus limitée, maintiendrait cette obligation de publication des données aux résidents américains ou aux acteurs visant une activité commerciale sur le marché américain.

Un débat vif autour du RGPD

Ce procès nous rappelle à quel point les débats relatifs à la mise en application du RGPD sont vifs au sein de l’ICANN, opposant les acteurs utilisant les données devenues si précieuses et les défenseurs de la vie privée, soutenus par le G29 (groupe des CNIL européennes) qui citent notamment les sanctions encourues.

Rappelons enfin que le GAC tente de minimiser les conséquences du règlement européen. Après avoir été débouté par la justice allemande de leur attaque de mai 2018 visant un registrar ayant cessé de délivrer les données clients au titre du RGPD, le GAC vise à obtenir de la Cour de justice de l’UE un avis favorable en la matière.

Les débats autour du procès DomainTools mériteront d’être suivis de près !

La révocation de la clé de sécurité DNS KSK-2010 par l’ICANN, c’est cette semaine !

La révocation de la clé de sécurité DNS KSK-2010 par l’Icann, c’est cette semaine !
Source de l’image : TheDigitalArtist via Pixabay

Après le tout premier changement de clé cryptographique d’octobre dernier, c’est maintenant que, le 11 janvier, l’ancienne clé KSK (Key Signing Key) de la zone racine sera désactivée.

Le processus enclenché en octobre 2018 pour améliorer la sécurité de la zone racine, avec le déploiement de la Key Signing Key-2017, trouve donc son aboutissement avec la révocation de la racine de l’ancienne clé KSK-2010.

Comme l’indique Paul Hoffman, responsable de la technologie ICANN, « L’Icann pense que la révocation ne provoquera aucun problème. Cependant, c’est la première fois que l’on révoque le KSK de la zone racine du système de noms de domaine (DNS). L’Icann et la communauté technique du DNS suivront donc de près tout ce qui se passera pendant les 48 heures au moins après la publication de la clé KSK-2010 révoquée ».

A noter, lors du roulement d’octobre, les impacts négatifs avaient été extrêmement limités et il semblerait que seuls deux fournisseurs de services Internet aient été victimes de coupures lors de l’opération.

L’Icann encourage bien sûr les vendeurs de solutions à ne plus utiliser la KSK-2010 dans leurs produits. L’Icann devrait ensuite publier un livre blanc traitant du processus de roulement (rollover) dans son intégralité, y compris les leçons apprises de cette opération. Les communautés Icann pourront ensuite ouvrir les discussions relatives aux prochains roulements qui pourraient avoir lieu.

Fermeture d’Incels.me, le site des « célibataires involontaires »

Fermeture de Incels.me, le site des « célibataires involontaires »
Source de l’image : geralt via Pixabay

A la suite des violations de la politique d’abus, le registre du .me a décidé de suspendre, pour une durée indéterminée, le site Incels.me. Pour rappel, le site est doté d’un forum qui regroupe des membres se disant célibataires malgré eux ou encore « incels » et échangeant par ce biais quant à leur quotidien.

Des propos inquiétants, source de la suspension

Ce n’est pas sans surprise que les administrateurs du site Incels.me ont vu leur forum rendu inaccessible. Les enquêtes menées par le registre ont permis de déceler des propos haineux, des menaces de viol et même de meurtre dans les commentaires échangés entre les participants. La décision de fermer le site a été promptement prise le 15 octobre 2018, les propos tenus s’apparentant à une violation de la politique d’abus. Selon le registre, cette mesure a été prise afin de contraindre les administrateurs d’Incels.me à ôter les contenus inappropriés et à faire en sorte que les propos haineux ne puissent plus réapparaitre sur le forum à l’avenir.

Le site Incels.me relié à des attentats ?

Au mois d’avril dernier, la ville de Toronto a été la scène d’un attentat sanglant, où un homme a assassiné 10 personnes, à la voiture bélier. Avant de passer à l’acte, l’homme en question a posté un message sur les réseaux sociaux, où il se déclarait « Incel ». Ce n’est qu’après enquête que les forces de police ont découvert que le meurtrier s’était inspiré de certains contenus violents que présentait le forum d’Incels.me. Le rapprochement entre l’individu et les incitations à la haine, mais aussi au viol, échangées dans le forum, a rapidement été fait.

Incels.me financé par un géant chinois aux activités douteuses

Les enquêtes lancées sur le site ont permis de remonter jusqu’à son principal financeur. Grâce à ces investigations, on sait aujourd’hui que le site Incels.me est appuyé financièrement par une grande entité chinoise détenant en parallèle plus de 54 000 autres noms de domaine. Les enquêteurs ont été interpellés par le potentiel à caractère illicite des activités de  cette entreprise, ZhuHai NaiSiNike Information Technology Co. En effet, sur ces milliers de noms de domaine enregistrés, la majeure partie est impliquée dans l’hébergement de sites de vente illégale de médicaments.

Malgré les demandes de suppression des propos abusifs tenus sur le forum d’incels.me, l’entreprise chinoise n’a pas donné suite. Le site restera ainsi suspendu jusqu’au retrait des contenus litigieux.     

DNS Belgium mettra désormais hors service les sites web frauduleux sous 24 heures

DNS Belgium mettra désormais hors service les sites web frauduleux sous 24 heures
Source de l’image : Kreutzfelder via Pixabay

Dans le cadre de la lutte contre l’insécurité sur le web, DNS Belgium, registre du .BE, a décidé d’intensifier son action en collaborant avec le SPF Economie [Le SPF Économie, PME, Classes moyennes et Énergie est le service public fédéral belge qui a pour mission de créer les conditions d’un fonctionnement compétitif, durable et équilibré du marché des biens et services en Belgique] pour fermer les sites frauduleux en moins de 24h.

Philip Du Bois, manager général de DNS Belgium indique ainsi : « Le présent protocole nous permettra d’agir ensemble avec le SPF Economie de manière encore plus ciblée contre les abus possibles impliquant des noms de domaine .be. Le protocole souligne notre ambition d’une zone .be sûre et de qualité qui crée un climat favorable pour le développement ultérieur de l’internet. »

Le but : garantir aux consommateurs une navigation en toute sécurité sur les sites Internet en .BE.

Cette procédure assurera une bien plus grande réactivité. En effet, jusqu’à présent SPF Economie ne pouvait demander au registre un blocage relatif au contenu, aussi les sites frauduleux mais dont les données d’identification étaient correctes (à tout le moins dont le caractère faux ne pouvait être prouvé) demeuraient intouchables. Le blocage nécessitait une requête auprès du Parquet, soit une procédure d’au moins deux semaines, laissant largement le temps au site frauduleux de créer des dommages importants auprès des consommateurs. Plusieurs centaines de sites par an sont concernés !

Dès le 1er décembre 2018, le protocole permettra donc au registre DNS Belgium, à la demande du SPF Economie, de bloquer les noms en .BE qui :

  • Sont utilisés pour des sites web frauduleux
  • Abritent des sites phishing

Bien sûr, cette procédure sera appliquée pour les délits reconnus comme sérieux. Le propriétaire du nom bloqué disposera d’une période de deux semaines pour réagir au blocage. Sans action de sa part sous 6 mois, le nom bloqué expirera.

Cette initiative, encore trop rare, est à saluer dans un contexte de lutte acharnée contre la cybercriminalité !

[INFOGRAPHIE] Sécurisez votre infrastructure DNS

Les noms de domaine stratégiques d’une entreprise et les services Internet qui y sont associés dépendent du DNS et exigent une haute disponibilité ainsi qu’un niveau élevé de sécurité. Une interruption de services aurait de lourdes conséquences pour les entreprises victimes.

Pourtant, le DNS est bien souvent l’infrastructure la moins sécurisée d’une entreprise et est exposé à de nombreuses attaques potentielles.

Quelles sont les principales cyberattaques visant le DNS ? Quelles en sont les conséquences ? Comment sécuriser votre infrastructure DNS pour vous en prémunir ?

Les réponses dans cette infographie :

[Infographie] Sécurisez votre infrastructure DNS

Retrouvez également sur le blog les articles : DNS – le grand oublié de l’Internet et  les 3 attaques DNS les plus communes et comment les combattre.

Cyberattaques, des sanctions annoncées par l’Union Européenne

Cyberattaques, des sanctions annoncées par l'Union Européenne
Source de l’image : VISHNU_KV via pixabay

Après le succès de l’opération collaborative Power Off, rassemblant plusieurs pays, dont le Royaume-Uni, l’Espagne, le Canada, les USA et les Pays-Bas, épaulée par Europol, ayant conduit au démantèlement de Webstresser.org [l’une des entités responsables de plus de 4 millions d’attaques DDoS dans le monde] en mai 2018, l’Union Européenne a décidé de travailler à la création d’un régime spécifique de sanctions contre les cybercriminels.

Lors du sommet européen du 18 octobre dernier, les dirigeants des 28 états membres se sont prononcés sur des sanctions à l’encontre des pirates informatiques et ce, après la récente tentative de piratage contre l’Organisation pour l’Interdiction des Armes Chimiques (OIAC) à La Haye.

Des accusations contre Moscou

La tentative de piratage en avril 2018 déjouée par les Pays-Bas, visait l’Organisation pour l’Interdiction des Armes Chimiques. Cette dernière aurait été perpétrée par l’agence russe des renseignements militaires ou GRU. Face à cette accusation, Moscou nie cependant toute implication.

Cette cyberattaque contrée s’est jouée au moment même où l’organisation menait une enquête sur l’empoisonnement par une substance neurotoxique au Royaume-Uni d’un ancien agent russe. Malgré le démenti de Moscou, Londres persiste à accuser le GRU d’avoir perpétré cette tentative d’empoisonnement.

Les pays européens se mettent d’accord sur la sanction

Lors d’une conférence de presse, à l’issue du sommet européen, le président du conseil européen, Donald Tusk, a affirmé avoir fait une requête auprès des ministres européens, afin qu’ils élaborent des sanctions spécifiques contre les auteurs de cyberattaques. Cette demande, visant initialement à protéger les entreprises et les internautes, a été validée par les dirigeants des états membres de l’Union Européenne. Selon Donald Tusk, les sanctions constitueront à geler les biens fiscaux des organisations ou des pirates informatiques, et à leur interdire l’accès aux 28 pays membres. Dans l’urgence, 8 états dont le Danemark, les Pays-Bas, la Lituanie, la Lettonie, l’Estonie, la Roumanie, la Finlande et la Grande Bretagne ont imposé à l’Union Européenne de prendre des mesures immédiates pour sanctionner les auteurs de piratages informatiques.

Dans un monde où les cyberattaques pourtant d’envergure semblent souvent rester impunies, les pays membres soulignent l’urgence et l’absolue nécessité d’imposer ces sanctions communes.

 

[INFOGRAPHIE] Protégez vos accès ! Le premier maillon de la sécurité de vos noms de domaine

Vos noms de domaine sont pour votre entreprise des actifs immatériels de grande valeur.

Parce que votre plateforme de gestion de noms peut être une cible de choix pour les pirates, il est crucial de sécuriser vos accès.

Voici une infographie vous expliquant quels sont les risques encourus si vos accès sont mal protégés et les 5 éléments garantissant qu’une plateforme est hautement sécurisée.

Protégez vos accès ! Le premier maillon de la sécurité de vos noms de domaine

 

 

Pour la première fois depuis 2010, l’ICANN prévoit de modifier la clé KSK DNSSEC

Pour la première fois depuis 2010, l’ICANN prévoit de modifier la clé KSK DNSSEC
Source de l’image : TheDigitalArtist via Pixabay

L’ICANN a confirmé le changement de clé KSK du DNS racine en date du 11 octobre 2018.

Pour bien comprendre, reprenons brièvement les bases. L’Internet fonctionne notamment grâce au système DNS (Domain Name System). Véritable carnet d’adresse du web, le DNS traduit en adresse IP les noms de domaine, permettant ainsi à chacun de se connecter à l’adresse voulue. Le DNS est de fait indispensable au bon fonctionnement d’Internet, pas tant d’un point de vue technique, mais d’un point de vue opérationnel. Il serait en effet aujourd’hui inconcevable de devoir utiliser des adresses IP à la place de noms de domaine pour naviguer sur le web.

Le DNS va permettre à l’internaute de renseigner dans son navigateur web, un nom de domaine pour accéder à un site web. Le navigateur va alors « résoudre » ce nom de domaine pour obtenir l’adresse IP du serveur web qui héberge ce site web et l’afficher. On appelle ça la « résolution DNS ».

Du fait de sa position centrale dans le bon fonctionnement du web, le DNS doit donc être protégé et rester hautement disponible. Si ce protocole a bien été conçu avec un souci de sécurité, le contexte cybercriminel était alors bien différent et plusieurs failles ont depuis été détectées.

C’est pour le renforcer et contrer ces vulnérabilités que le protocole DNSSEC a été développé.

DNSSEC permet de se prémunir de différents types d’attaques, en particulier l’empoisonnement du cache, en assurant l’intégrité de la résolution DNS.

Pour assurer l’intégrité de la résolution DNS, DNSSEC permet d’établir une chaine de confiance qui remonte jusqu’à la racine du DNS. La sécurité des données est effectuée à l’aide d’un mécanisme de clés (KSK pour Key Signing Key & ZSK pour Zone Signing Key) qui signe les enregistrements DNS de sa propre zone. Les clés publiques KSK sont alors envoyées au registre correspondant pour être archivées ; le registre étant lui-même lié via DNSSEC au serveur root, la chaine de confiance s’établit. Chaque zone DNS parente, garantit l’authenticité des clés de ses zones filles en les signant.

C’est aujourd’hui pour renforcer ce protocole de sécurité que l’ICANN a décidé de changer la fameuse clé DNSSEC le 11 octobre prochain.

Le roulement KSK va donc permettre de générer une nouvelle paire de clés cryptographiques publiques et privées et de distribuer le nouveau composant public aux parties qui utilisent les résolveurs de validation.

Pourquoi ce changement (KSK rollover pour les intimes) ?

Il n’est bien sûr pas souhaitable qu’une clé cryptographique demeure identique et ne soit pas modifiée. C’est ce changement qui pourra assurer que l’infrastructure DNS est en mesure de supporter un changement de clé, en cas d’urgence notamment. Depuis qu’elle est entrée en fonctionnalité en 2010, la clé KSK utilisée pour les DNSSEC de la zone racine n’a jamais été modifiée.

L’ICANN a expliqué que « l’évolution permanente des technologies et des installations Internet, le déploiement de dispositifs IoT et l’augmentation de la capacité des réseaux dans le monde entier, conjugués au défaut regrettable de sécurité de ces dispositifs et de ces réseaux, font que les attaquants disposent d’une capacité de plus en plus grande de paralyser les infrastructures Internet ». « Plus précisément, cette force d’attaque risque de dépasser les capacités de la communauté des opérateurs de serveurs root et elle ne sera pas en mesure d’opposer une défense adéquate. »

Aujourd’hui, 25% des utilisateurs mondiaux d’Internet, c’est-à-dire 750 millions de personnes, utilisent des résolveurs validant les réponses avec DNSSEC.

Qui pourra être affecté par ce changement ?

Plusieurs types de structures pourraient être affectés par le roulement de la clé :

  • Les développeurs et distributeurs de logiciels Internet
  • Les intégrateurs de systèmes
  • Les opérateurs de réseau
  • Les opérateurs de serveurs racine
  • Les utilisateurs finaux (si les mesures adéquates ne sont pas prises en amont par les opérateurs de résolveurs).

L’ICANN propose un banc d’essai pour toutes les parties souhaitant s’assurer que leurs systèmes peuvent gérer correctement le processus de mise à jour automatique : go.icann.org/ksktest

 

Pour plus d’informations : https://icann.org/kskroll

TESCO Bank sanctionnée pour avoir failli à protéger ses utilisateurs victimes d’une cyberattaque

TESCO Bank sanctionnée pour avoir failli à protéger ses utilisateurs victimes d’une cyberattaque
Source de l’image : GregMontani via Pixabay

En novembre 2016, Tesco Bank, banque de détail britannique détenue à 100% par le groupe de distribution Tesco, avait essuyé une attaque informatique d’une ampleur alors inédite dans ce secteur. En moins de 48 heures, les pirates avaient réussi à prélever sur des comptes clients près de 2.26 millions de livres.

40 000 comptes avaient été touchés par cette attaque et l’argent avait été subtilisé par les cybercriminels sur 20 000 d’entre eux.

Même s’il s’agissait de montants peu élevés et que ceux-ci avaient été remboursés aux victimes, la question de la solidité et la fiabilité des systèmes informatiques du secteur bancaire avait bien sûr été soulevée.

La décision de justice rendue par le FCA (Financial Conduct Authority), le régulateur financier du Royaume-Uni, est assez éloquente en la matière, jugeant que la banque n’a pas suffisamment protégé ses utilisateurs contre les cyberattaques. Les cybercriminels avaient en effet réussi à exploiter des failles pour mener à bien leur attaque, notamment dans le système de conception des cartes bancaires.

Si Tesco risquait une amende de 33.6 millions de livres, le groupe a finalement écopé d’une sanction de 16.4 millions de livres, soit environ 18.4 millions d’euros.

Le but de cette amende : montrer que le régulateur financier n’a « aucune tolérance pour les banques qui échouent à protéger les clients contre des risques prévisibles »*, souligne Mark Steward, executive director of enforcement and market oversight au FCA.

Le FCA a ainsi exprimé que Tesco Bank avait manqué à ses obligations de vigilance quant à :

  • La fabrication et la distribution des cartes de crédit
  • La configuration d’un système d’authentification spécifique et de détection des fraudes
  • La prise d’actions appropriées pour anticiper les risques d’attaques et de fraudes

Mark Steward ajoute également que dans le cas précis de l’attaque de novembre 2016, la banque n’avait géré une alerte spécifique qu’une fois que l’attaque avait débuté.

Pour la FCA, « la norme doit être désormais celui de la résilience, afin de réduire en amont le risque d’une cyberattaque, pas seulement de réagir à celle-ci »**.

 

*“The fine the FCA imposed on Tesco Bank today [1st October] reflects the fact that the FCA has no tolerance for banks that fail to protect customers from foreseeable risks”.

**“The standard is one of resilience, reducing the risk of a successful cyber attack occurring in the first place, not only reacting to an attack.”

Google veut-il vraiment remplacer l’URL ?

Google veut-il vraiment remplacer l’URL ?
Source de l’image : Simon via Pixabay

Dans une interview accordée à Wired, l’ingénieur en chef de Google Chrome, Adrienne Porter Felt, a déclaré la volonté de faire des URLs une espèce en voie d’extinction.

Aussi les développeurs de Chrome chercheraient-ils des alternatives permettant de remplacer les URLs. Pour le moment, Google avance sur la sécurisation du Web avec sa mesure épinglant désormais systématiquement les sites non HTTPS.

Les URLs (Uniform Resource Locators) sont les adresses web que nous utilisons quotidiennement lors de notre navigation sur Internet. Elles sont ainsi listées dans le répertoire DNS et dirige les moteurs de recherche vers l’adresse IP associée à un serveur web hébergeant le site visé.

Si Google évoque son souhait de remplacer les URLs, c’est qu’un constat sans appel fait jour : les URLs sont devenues de plus en plus difficiles à lire et à comprendre. Par-dessus tout, les URLs offrent un niveau de sécurisation trop faible. Longues et aisément manipulables, ces dernières offriraient bien trop de possibilités aux cybercriminels pour rediriger à leur insu les internautes vers des sites malveillants. Il devient de fait compliqué pour les internautes devant une relative opacité de savoir à qui ils ont affaire.

Adrienne Porter Felt déclare ainsi : “Elles sont [les URLs] difficiles à lire, il est ardu de savoir quelle partie de ces dernières est totalement digne de confiance, et, en général, je ne pense pas que les URLs jouent réellement leur rôle dans la communication de l’identité d’un site. C’est pourquoi nous souhaitons évoluer dans le sens d’une identification plus aisée et compréhensible par tous des sites web. […] Mais cela implique des changements importants sur quand et comment Chrome affiche les URLs. »*

Si l’intention est louable, dans le monde du web où la question de la sécurité et de la confiance devient chaque jour plus importante, aucune solution n’a encore été trouvée.

Le premier essai en la matière, Origin Chip en 2014, s’était soldé par un échec. Cette fonctionnalité alors testée sur Safari permettait que seul le nom de domaine visité soit affiché dans la barre de recherche, un clic sur ce dernier rendait alors l’URL complète visible. Le mauvais accueil réservé à cette fonctionnalité lui a valu assez rapidement son retrait. Cette première expérience et ses constats sont bien sûr mis à profit dans la réflexion actuelle.

Les équipes de Google sont occupées en ce moment même à identifier les différentes utilisations faites des URLs par les internautes afin d’avancer vers une alternative qui assurerait plus de sécurité et d’intégrité quant à l’identité des sites sur le web. La route semble encore longue à parcourir avant que Google ne remplace donc l’URL.

Parallèlement, c’est également fort de ce constat du caractère manipulable et difficile à lire des URLs que des solutions d’identification ont vu le jour. Nameshield propose notamment un authentificateur d’URL permettant aux marques de signaler en temps réel à leurs internautes les URLs frauduleuses, via un système de marquage clair.

 

* »They’re hard to read, it’s hard to know which part of them is supposed to be trusted, and in general I don’t think URLs are working as a good way to convey site identity. So we want to move toward a place where web identity is understandable by everyone […] this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity. »