Un excellent document de l’#IAB, sur les tentatives maladroites de « réguler » l’Internet via une action sur l’infrastructure, et pourquoi c’est une mauvaise idée. (Le #DNS, et notamment les résolveurs menteurs comme en France, est cité, mais aussi #BGP et autres technologies.)
À faire lire à tous vos amis députés ou ministres.
▻https://www.iab.org/documents/correspondence-reports-documents/2019-2/avoiding-unintended-harm-to-internet-infrastructure
]]>RFC 7970 : The Incident Object Description Exchange Format Version 2
Pour rendre plus facilement analysables les innombrables rapports d’incidents de sécurité qui circulent sur Internet tous les jours, ce #RFC spécifie un format standard XML, nommé #IODEF, pour décrire ces incidents. Ici, il s’agit de la version 2 de ce format IODEF, la 1 était dans le RFC 5070.
]]>RFC 7908 : Problem Definition and Classification of BGP Route Leaks
Il est bien connu que le protocole de routage #BGP connait fréquemment des « fuites de route » (route leaks). Les forums où les opérateurs discutent sont plein de discussions et d’alertes sur la dernière fuite en cours, il existe un compte Twitter dédié pour les alertes automatiques de fuites, le rapport sur la résilience de l’Internet en France en parle longuement. Bref, le sujet est bien connu. Curieusement, il n’y a pas de définition simple et consensuelle de ce qu’est une fuite. Il en existe en fait plusieurs sortes, et ce nouveau #RFC tente de faire le point et de définir rigoureusement les différents types de fuite.
]]>RFC 7873 : Domain Name System (DNS) Cookies
La grande majorité des requêtes #DNS passent aujourd’hui sur UDP. Ce protocole ne fournit aucun mécanisme permettant de vérifier un tant soit peu l’adresse IP source de la requête. Contrairement à ce qui arrive avec TCP, il est trivial de mentir sur l’adresse IP source, sans être détecté. Cela permet des comportements négatifs, comme les attaques par réflexion. Ce nouveau #RFC propose un mécanisme simple et léger pour s’assurer de l’adresse IP source du client : des petits gâteaux, les cookies.
]]>RFC 7707 : Network Reconnaissance in IPv6 Networks
Soit un pauvre petit réseau innocent, et un méchant attaquant qui va essayer de faire subir les derniers outrages au réseau en question. L’attaquant commence souvent par une phase de reconnaissance, où il cherche à améliorer sa connaissance du réseau visé. Un outil souvent utilisé dans cette phase est le balayage (scanning) systématique du réseau, à la recherche d’adresses IP de machines à attaquer. En #IPv6, contrairement à IPv4, la tâche semble colossale, vu le nombre d’adresses IP possibles. Mais, comme l’avait déjà noté le RFC 5157, cette tâche n’est pas impossible. Ce nouveau #RFC fait le point sur le balayage IPv6 et détaille les techniques utilisables.
]]>Grosse attaque par déni de service contre l’important hébergeur #Linode. Exceptionnelle par sa durée (plusieurs jours) et son intensité.
►http://www.scmagazine.com/cloud-hosting-company-linode-sees-service-interruptions-for-ddos-attacks/article/462535 ▻http://www.theregister.co.uk/2015/12/29/day_four_of_linode_data_center_attacks
]]>On a beaucoup parlé des attaques #DoS par réflexion + amplification en les présentant souvent comme spécifiques à #UDP. Mais un article récent (mais passé curieusement inaperçu) montre qu’on peut en faire également avec #TCP.
]]>RFC 7513 : SAVI Solution for DHCP
Le cadre #SAVI (Source Address Validation Improvement), décrit dans le RFC 7039, vise à rendre plus difficile l’usurpation d’adresses IP. SAVI fournit un cadre général et plusieurs solutions techniques concrètes sont ensuite développées selon le type de réseau et selon le niveau de sécurité qu’on désire et qu’on est prêt à « payer ». Ainsi, le RFC 6620 décrivait un mécanisme où le réseau d’accès assurait que le premier titulaire d’une adresse IP puisse la garder. Ce nouveau #RFC décrit un autre mécanisme, où c’est via l’utilisation de DHCP qu’on contrôle les adresses : le réseau d’accès va empêcher l’utilisation d’adresses qui n’ont pas été allouées par le serveur DHCP. (Ce mécanisme est largement déployé depuis des années, sous divers noms, comme « #DHCP_snooping », mais n’avait pas été formellement décrit dans un RFC.)
]]>On vous a répété plein de fois que, si vous voyez un petit cadenas à gauche de la barre d’adresse de votre navigateur Web, c’est que vous êtes en sécurité ? C’est faux. Il existe plusieurs techniques pour contourner cette sécurité (surtout si vous n’avez pas un complet contrôle de votre ordinateur et que quelqu’un peut, par exemple, ajouter une autorité de certification) et en plus elles sont légales.
La décision de la #CNIL : ▻http://www.cnil.fr/linstitution/actualite/article/article/analyse-de-flux-https-bonnes-pratiques-et-questions
Une explication simplifiée : ▻http://www.01net.com/editorial/651057/votre-employeur-peut-espionner-vos-communications-chiffrees-et-la-cnil-est-d-
Les détails techniques : ▻http://www.ssi.gouv.fr/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https
]]>RFC 7469 : Public Key Pinning Extension for HTTP
Depuis que les piratages de Comodo et DigiNotar ont fait prendre conscience du peu de sécurité qu’apportent les certificats #X509, plusieurs solutions ont été proposées pour combler les failles des autorités de certification. La proposition de ce #RFC consiste à permettre à un client d’épingler (to pin) les clés cryptographiques d’un serveur HTTP utilisant #TLS, c’est-à-dire à s’en souvenir pendant une durée spécifiée par le serveur. Ainsi, même si un faux certificat est émis par une AC, il ne sera pas accepté.
]]>« En vertu d’un décret du 27 mars 2015, les fournisseurs d’accès à internet et hébergeurs déclarés "d’importance vitale" [la liste est secrète, au passage] auront l’obligation de fournir à l’État toutes les documentations techniques sur les matériels et logiciels utilisés dans leurs réseaux, ainsi que les codes sources. »
▻http://www.numerama.com/magazine/32633-les-fai-devront-livrer-a-l-etat-toutes-les-infos-sur-leurs-reseaux.h
▻http://www.nextinpact.com/news/93636-lanssi-detaille-obligations-securite-operateurs-dinfrastructure-vi
Protestations dans ▻http://www.lesechos.fr/tech-medias/hightech/0204266819340-la-pression-saccroit-sur-les-operateurs-dimportance-vitale-11 qui note à juste titre que la communication avec l’État est à sens unique
Même 20 minutes en parle ►http://www.20minutes.fr/high-tech/1575583-20150331-operateurs-importance-vitale-contraints-jouer-transparenc
]]>Encore un détournement de trafic Internet, via un détournement #BGP (apparemment accidentel, comme c’est en général le cas), cette fois de #Google par des indiens.
▻http://www.bgpmon.net/what-caused-the-google-service-interruption
]]>RFC 7454 : BGP operations and security
Tout l’Internet repose sur le protocole #BGP, qui permet l’échange de routes entre opérateurs Internet. La sécurité de BGP est donc cruciale pour l’Internet, et elle a fait l’objet de nombreux travaux. Ce nouveau #RFC résume l’état actuel des bonnes pratiques en matière de sécurité BGP. Du classique, aucune révélation, juste la compilation de l’état de l’art. Ce RFC porte aussi bien sur la protection du routeur, que sur le filtrage de l’information (les routes) reçues et transmises.
]]>Compte-rendu du #FIC, le Forum International sur la Cybersécurité, qui vient de se tenir à Lille, en pleine ambiance Charlie et cyberdjihadistes.
▻http://rue89.nouvelobs.com/2015/01/23/forum-cybersecurite-jusque-prenait-paranos-257257
]]>Bon article sur la mission impossible de l’évaluation des coûts d’une cyberattaque...
▻http://www.zdnet.fr/actualites/fic-2015-evaluer-le-cout-d-une-cyberattaque-mission-impossible-39813397.htm
]]>Bon article sur les actuelles cyberattaques contre la France (probablement menées par des intégristes islamistes). Mais dommage qu’il mélange un peu défigurations de sites Web et attaques par déni de service (DoS).
▻http://www.arbornetworks.com/asert/2015/01/ddos-attacks-in-the-wake-of-french-anti-terror-demonstrations
Un exemple d’une attaque DoS est celle contre l’AFNIC :
▻http://www.nextinpact.com/news/92821-suite-a-attaque-site-afnic-est-en-maintenance.htm
]]>RFC 7194 : Default Port for IRC via TLS/SSL
Le protocole de messagerie instantanée #IRC est toujours très utilisé, malgré la concurrence de XMPP. Il n’existait pas de port « officiel » pour les connexions IRC sécurisées par #TLS, ce qui est fait avec ce #RFC, qui décrit l’usage, déjà très répandu, du port 6697.
]]>« Analyzing Forged SSL Certificates in the Wild » de Lin-Shung Huang, Alex Rice, Erling Ellingsen et Collin Jackson
Excellente et très amusante analyse de faux certificats #X.509 (appelés à tort « SSL certificates ») trouvés dans la nature. Les auteurs ont mis une pub en Flash sur le site de Facebook, et le code Flash faisait une connexion HTTPS avec Facebook et récupérait le certificat X.509. Cela permet de tester le Web sécurisé vu depuis un grand nombre de machines. Ils ont ainsi récupéré 6 845 faux certificats.
Certains étaient ultra-malveillants, prétendant venir d’autorités de certifications connues comme Verisign. Beaucoup venaient d’anti-virus comme Bitdefender qui détournaient le trafic TLS pour l’examiner, à la recherche de virus (du point de vue sécurité, c’est l’équivalent de se jeter dans le lac pour éviter d’être mouillé par la pluie). La catégorie la plus fréquente, après les anti-virus, était celle des logiciels d’espionnage, qui permettent de surveiller le trafic de ses employés : le logiciel détourne le trafic TLS, le déchiffre et le rechiffre après examen. Plusieurs des faux certificats venaient de la société ContentWatch qui s’en vante sur son site Web « This technology also ensures the users cannot bypass the filtering using encrypted web traffic, remote proxy servers or many of the other common methods used circumvent content filters. » Dans une catégorie proche, les logiciels de contrôle parental tentent aussi de casser la protection qu’offre HTTPS, en présentant des faux certificats (le faux certificat qui est marqué « Louisville Public Library » est probablement dans ce cas, les bibliothèques publiques étant souvent contraintes, par les règles puritaines, de censurer certains services). Et il y avait même du pur malware.
]]>Du 4 au 8 novembre 2013 se tient à Vancouver la 88ème réunion de l’#IETF. Elle verra notamment un grand nombre de discussions sur l’espionnage de masse auquel se livrent des organisations comme la #NSA, et aux moyens d’adapter la sécurité de l’Internet à ce type de menaces. Bien sûr, le problème est surtout politique, et c’est sur le champ politique qu’il va essentiellement se jouer. La technique seule ne peut pas grand’chose contre un attaquant qui contrôle autant de leviers. Mais, à une réunion IETF, il est normal qu’on se pose la question « Que peut faire l’IETF ? » Il y a deux axes importants : défendre les normes IETF contre les attaques visant à affaiblir délibérement leur sécurité pour faciliter l’écoute, et rendre l’Internet plus résistant à l’espionnage.
]]>RFC 7039 : Source Address Validation Improvement Framework
Une des choses agaçantes sur l’Internet est qu’il est trivial de tricher sur son adresse IP source. Une machine qui a comme adresse 2001:db8:1:2::42 peut parfaitement émettre un paquet où l’adresse IP source est 2001:db8:9fe:43::1 et, là plupart du temps, ce paquet arrivera à destination (le routage ne se fait que sur la destination, pas sur la source), trompant le récepteur sur la vraie source de l’envoi. Cette faiblesse a donc des tas de conséquences pour la sécurité. Il existe des bonnes pratiques documentées pour empêcher l’émission de tels paquets (RFC 2827 et RFC 3704) mais elles sont peu déployées en pratique. Le projet #SAVI (Source Address Validation Improvement) vise à propose des mécanismes pour rendre plus difficile l’utilisation d’adresses IP usurpées. Ce document est son cadre général, exposant les principes.
]]>Détournement de certains canaux de communication Internet de Barack Obama par la #SEA (Armée Électronique Syrienne, pro-Assad). Apparemment, pas de jeu avec les noms de domaine (en tout cas, je n’en trouve aucune trace dans le DNS), uniquement une prise de contrôle de certaines ressources via le panneau de contrôle qui permet de les éditer et dont le mot de passe avait circulé.
▻http://mashable.com/2013/10/28/syrian-electronic-army-obama
▻http://news.softpedia.com/news/Syrian-Electronic-Army-Hijacks-Barack-Obama-s-Social-Media-Accounts-
▻http://www.datasecuritybreach.fr/la-syrian-electronic-army-sattaque-a-obama
▻http://www.lemonde.fr/technologies/article/2013/10/28/l-armee-electronique-syrienne-revendique-le-piratage-des-sites-lies-a-barack
La normalisation est une chose merveilleuse. Il existe même une norme pour le transport de trafic Internet espionné (pardon, « légalement intercepté »). Publiée sur le site du Ministère de la Justice néerlandais : ►http://www.rijksoverheid.nl/documenten-en-publicaties/regelingen/2012/02/08/tiit-v1-2-0-transport-of-intercepted-ip-traffic.html (de la Justice, oui : Oceania avait bien un Ministère de la Vérité)
« This document describes in detail the Internet Lawful Interception (LI) interface required for LI based upon the requirements described in the Functional Specifications [2]. It provides the specification of the interface from an Interception Function within an IP network to a Law Enforcement Monitoring Facility (LEMF) for the purpose of providing data to Law Enforcement Agencies (LEAs) in the area of LI of communications. »
Plein de choses intéressantes du point de vue technique dedans, comme le détail de l’interception d’une communication SIP (voix sur IP).
Les #Amesys du monde entier peuvent donc travailler sur la base d’un standard commun, au lieu d’avoir des mécanismes privés (« Allow implementation using only open standards », dit le document)
Notez que la norme impose l’usage d’un protocole sécurisé par la cryptographie (comme TLS) : les espions ne veulent pas être espionnés.
]]>Un long article détaillé sur les questions politiques que soulève le déploiement de la #RPKI : « Negotiating a New Governance Hierarchy : An Analysis of the Conflicting Incentives to Secure Internet Routing » de Brenden Kuerbis et Milton Mueller.
Rien de très nouveau (l’article date de l’année dernière), il reprend et développe les idées que les auteurs avaient déjà exprimé : la #RPKI va déplacer le pouvoir depuis les opérateurs réseaux (qui routaient comme ils voulaient) vers les #RIR (qui vont gérer la RPKI, donc les certificats, donc les routes). Très bien fait, très pédagogique.
►http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2021835
Pöur la question technique, voir ►http://seenthis.net/messages/55501
]]>Plusieurs articles sur la #sécurité_Internet au #Brésil citent une attaque par empoisonnement #DNS. Ces articles ne contiennent aucun détail (par exemple le résultat d’un dig), semblent écrits par des journalistes incompétents et rien ne permet d’établir qu’il y a eu empoisonnement DNS, il semble plutôt qu’il s’agisse d’attaques contre les routeurs CPE (ceux qui sont chez l’utilisateur). Bref, de la soupe journalistique habituelle.
►http://www.securelist.com/en/blog/208193214/Massive_DNS_poisoning_attacks_in_Brazil (l’avis d’utiliser Google Public DNS n’est pas du tout étayé par les faits - mal - rapportés)
►http://threatpost.com/en_us/blogs/major-dns-cache-poisoning-attack-hits-brazilian-isps-110711
►http://www.theregister.co.uk/2009/04/22/bandesco_cache_poisoning_attack (il y a deux ans, la même soupe sans détails)
]]>Bon article technique sur la sécurité des CPE (le petit machin qui connecte le réseau local de votre maison ou de votre petite entreprise à l’Internet, une « box », un Linksys acheté à Carrefour, etc). On se focalise sur la sécurité des postes clients et des serveurs et on oublie celle de ces petits boîtiers, qui font souvent l’objet d’attaques, comme par le logiciel malveillant #Hydra, décrit ici.
►http://www.securelist.com/en/analysis/204792187/Heads_of_the_Hydra_Malware_for_Network_Devices
]]>