Plus de sécurité pour vos projets ESP8266 : utilisez des mises à jour OTA signées

Magazine
Marque
Contenu Premium
Domaines


Résumé

Les fonctionnalités de mises à jour OTA disponibles avec les ESP8266 apportent une grande souplesse dans le développement et surtout l'évolution de vos projets. Inutile dès lors de devoir désinstaller un matériel déjà confortablement en place pour le connecter en USB, puisque tout se passe, in situ, au travers de la connexion wifi. Mais contrairement à une liaison USB nécessitant un accès physique, l'OTA constitue un risque en termes de sécurité : quiconque trouve, espionne ou devine le mot de passe est en mesure de remplacer votre code par le sien. Mais le support ESP8266 pour Arduino propose une solution à cette faiblesse...


Précisons de suite que l'objectif du mécanisme qui va être décrit n'est pas de protéger le firmware, mais d'empêcher une mise à jour non autorisée et donc le remplacement du code par quelque chose de potentiellement nuisible. Les ESP32, eux, proposent des solutions plus poussées comme le chiffrement du firmware et un mécanisme de boot sécurisé couvrant ce type de fonctionnalité, mais pas les ESP8266.

Comme nous l'avons vu dans le numéro 31 [1], l'accès au contenu de la mémoire flash, qu'il s'agisse de la zone dédiée à SPIFFS ou au programme exécuté, n'est pas très difficile. Pour l'heure, les outils de reverse engineering comme Ghidra en version stable [2] n'intègrent pas le support pour le processeur Tensilica Xtensa utilisé par les ESP8266, mais cela ne saurait tarder [3]. Même sans un tel outil, la simple analyse des données en flash, comme les chaînes qui s'y trouvent, peut suffire à comprendre des éléments importants de votre projet ou...

Cet article est réservé aux abonnés. Il vous reste 95% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite


Articles qui pourraient vous intéresser...

Attaques en environnement Docker : compromission et évasion

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

Ces dernières années, on a pu observer une évolution croissante des environnements conteneurisés et notamment de l’usage de Docker. Les arguments mis en avant lors de son utilisation sont multiples : scalabilité, flexibilité, adaptabilité, gestion des ressources... En tant que consultants sécurité, nous sommes donc de plus en plus confrontés à cet outil. Au travers de cet article, nous souhaitons partager notre expérience et démystifier ce que nous entendons bien trop régulièrement chez les DevOps, à savoir que Docker est sécurisé par défaut.

Les taxonomies se cachent pour ne pas mourir

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

« Attention, nouveau virus ! » Nombreux sont les articles à nous alerter régulièrement, par cette métonymie, sur l’émergence d’un nouveau malware. Pourtant, le terme de virus a-t-il encore un sens aujourd’hui ? Wannacry était-il un ver, ou un ransomware ? NotPetya, un wiper, ou bien un ver ? Et plus encore, au-delà de l’utilisation de termes et expressions se pose la question de la nécessaire catégorisation des incidents de cybersécurité ; pourquoi, comment, à quelles fins ? Essai (critique) de réponse.

Les difficultés du désassemblage sur ARM

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

Cet article aborde les problèmes spécifiques à l’architecture ARM qui se posent lorsqu’on désassemble un exécutable, c’est-à-dire lorsqu’on l’analyse statiquement pour en produire une représentation en langage assembleur. En effet, les particularités de l’architecture ARM peuvent rendre le désassemblage – déjà habituellement compliqué – particulièrement ardu.

Sûreté mémoire : le temps des cerises

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

L’étude et la compréhension des buffer overflow datent de 1972, et leurs premiers usages documentés de 1988 [1]. Près de 50 ans plus tard, où en sommes-nous ? Il nous faut bien admettre que la situation est déprimante : Microsoft et Google reconnaissent chacun ([2], [3]) que près de 2/3 des attaques utilisent à un moment ou un autre une vulnérabilité mémoire. Le ver Morris, qui n’était au départ qu’une preuve de concept, avait quand même coûté la bagatelle de quelques millions de dollars à l’époque… Aujourd’hui, les coûts sont abyssaux : sur le plan financier bien sûr, mais aussi pour nos vies privées, voire nos vies tout court. Face à ce problème, de nombreuses approches sont possibles : analyse statique du code, instrumentation et vérification à l’exécution, langages « sûrs »… Je vous propose d’explorer dans cet article un vieux concept remis au goût du jour, les capabilities, et tout ce qu’elles pourraient nous permettre de faire.