Standardisé en mai 2015 [RFC7540, RFC7541], HTTP/2 fait depuis l'objet de nombreuses campagnes « marketing » de la part de Google, Cloudflare ou Akamai. En contre-courant de cette vague (trop ?) enthousiaste se dressent des voix tentant de tempérer les prétendues améliorations en performance provenant de bancs de test biaisés. La communauté sécurité n'est pas en reste, soulignant que HTTP/2 n'est pas le remplaçant de HTTP/1.1 [Snort], mais bien un nouveau protocole à part entière dont la complexité est significative et les enjeux encore mal compris. Cet article détaille les défauts de HTTP/1.1 présentés comme justificatifs pour HTTP/2. Il dresse ensuite un portrait de ce nouveau protocole et de certaines réserves à son encontre.

Les évènements et personnages présentés dans cet article sont entièrement fictifs et ne représentent en rien le quotidien ou l’expérience de l’auteur… Enfin, faut quand même admettre que ça sent le vécu !

Lecteurs de MISC, êtes-vous sportifs ? Si oui, alors vous avez sûrement déjà entendu parler de ces bracelets connectés qui mesurent votre activité physique. Il en existe une multitude, pour ne citer que le Fitbit Flex ou Charge, Xiaomi MiBand, Misfit Flash... Et si vous n'êtes pas sportif, ne partez pas en courant : cet article vous demandera au plus un peu de gymnastique cérébrale afin de découvrir une attaque sur le Fitbit Flex.

BEAST, Lucky13, FREAK, LogJam, ou encore DROWN... Le point commun entre ces attaques sur le protocole TLS : l’exploitation de vulnérabilités connues depuis longtemps sur des algorithmes ou des constructions cryptographiques que l’on aurait dû abandonner depuis longtemps.

Qu’on se prenne pour James Bond ou pour un shaman, ce que notre industrie appelle la Threat Intelligence fait place à beaucoup de fantasmes que les vendors nourrissent joyeusement à chaque fois qu’un nouveau rapport est publié. Mais, concrètement, à quoi ça sert de « faire de la threat intelligence » ? Quelle est la différence par rapport au renseignement classique ? Quels sont les avantages concrets que le renseignement sur les menaces apporte lors de la gestion d’un incident de sécurité ? C’est ce que cet article cherche à expliquer, du point de vue de deux DFIRers.

De nombreuses publications détaillent le mode opératoire des attaques APT (Advanced Persistent Threat), ces attaques qui ciblent des entités diverses et variées afin de leur dérober leurs propriétés intellectuelles ou encore de les espionner. Ces attaques suivent généralement le même schéma connu et reconnu. Par contre, peu d’informations sont disponibles sur les attaquants. Certains chercheurs exposent des identités réelles d’attaquants, mais cela ne fournit pas forcément d’information sur les différents profils présents dans les groupes APT. Le but de cet article est de fournir une vue plus précise sur les profils composant ces groupes d’attaquants, ainsi que la façon dont ils sont structurés.

Les cas concrets où un organisme (la NSA peut-être ?) a influencé l'élaboration d'un standard cryptographique dans le but d'y ajouter une faille de sécurité sont extrêmement rares. Le cas de Dual_EC_DBRG, Dual Elliptic Curve Deterministic Random Bit Generator, un générateur pseudo-aléatoire, est un des plus parlants, nourri de détails soulevant nombre d'hypothèses sur la manière dont ce dernier a été normalisé, diffusé et, peut-être, dont la faille a été exploitée.

Les données d'une entreprise sont une ressource critique qui doit être préservée pour assurer la continuité de l'entreprise. À ce titre, tout projet de Plan de Continuité d'Activité doit prendre en compte les données. Cet article présente les différentes manières d'assurer la survie des données de manière à pouvoir reprendre ses activités suite à un sinistre.

La première série d'articles dédiée au protocole IPv6 a été publiée dans MISC n°27 à la rentrée 2006. Depuis, IPv6 n'est toujours pas omniprésent, comme certains l'avaient prédit, mais beaucoup de choses ont changé. Ainsi, la plupart des OS modernes prennent en charge IPv6, et l'activent par défaut, et de nombreux fournisseurs d'accès le propose à leurs clients [ORANGE-IPV6-NOVEMBRE-2015]. Côté serveurs, IPv6 a été largement adopté pour le DNS [IPV6-PROGRESS-REPORT]. Concernant le Web, la situation est plus mitigée, et seuls 10 % des sites les plus fréquentés, d'après la société américaine Alexa, l'ont configuré. À titre indicatif, environ 10 % des utilisateurs de Google utilisent IPv6 [GOOGLE-IPV6-STATISTICS]. Cet article présente tout d'abord les changements structurels et fonctionnels du protocole IPv6. Fort de ces descriptions théoriques nécessaires, l'objectif de cet article est de s'attarder sur cinq éléments distincts, qui 10 ans plus tard, semblent les plus pertinents pour appréhender le protocole IPv6 sous l'angle de la sécurité. Il s'agit de l'espace d'adressage, du mécanisme de découverte de voisins, de la question du respect de la vie privée, des entêtes d'extension, et de l'énumération de réseaux. Afin d'illustrer le contenu, les fonctions et messages de Scapy relatifs à IPv6 sont également discutés.

La cryptographie à base de courbes elliptiques est devenue ces dernières années une des alternatives les plus intéressantes à RSA en termes de cryptographie asymétrique. Cependant, sa jeunesse et ses développements récents en font encore une solution questionnée, tant sur sa solidité que sur la manière de correctement l'utiliser. L'heure est aujourd'hui à une nouvelle vague de normalisation dans une situation pour le peu troublée par un élément clef du succès d'un standard: la confiance.