Malware Corner

p. 06  Analyse de JRAT

Pentest Corner

p. 14  Techniques de communications furtives avec Empire Ou comment exfiltrer des données sans être détecté

Forensic Corner

p. 24  Désanonymisation du jeu de données MAWI

Dossier

p. 30  Préambule
p. 31  Android & TEE
p. 40  Attaques sur la technologie TrustZone d’ARM
p. 50  Fabriquer sa propre enclave à base de FPGA
p. 56  Développer une application sécurisée avec Intel SGX

Cryptographie

p. 66  Attaques par canaux auxiliaires : évaluations de sécurité à court et long terme

Système

p. 72  EDR : Endpoint Detection & Response

Code 

p. 78  Cross Origin Resource Sharing : défauts de configurations, vulnérabilités et exploitations

C’est la rentrée, le travail reprend avec force et vigueur !

Dans mon dernier édito [1] relativement optimiste quant à l’amélioration de la sécurité, j’abordais en creux certains domaines pour lesquels il demeurait une marge importante de progression. L’un d’eux me tient particulièrement à cœur, œuvrant dans la sphère de l’éducation nationale depuis une bonne quinzaine d’années, c’est celui de l’enseignement et la formation à la sécurité des systèmes d’information.

Pour ne pas jeter le bébé avec l’eau du bain, quelques initiatives particulièrement louables ont été mises en places telles que le B2I [2] (Brevet Informatique et Internet). Ce dispositif, malheureusement peu connu du grand public vise à fournir un bagage informatique de base à tous les élèves. Il intègre notamment un volet sécurité des systèmes d’information et protection de la vie privée. Un dispositif d’évaluation en ligne remplaçant les actuelles applications localement utilisées dans les collèges et lycées est d’ailleurs accessible en bêta (https://pix.beta.gouv.fr/). Sachant que la validation de ces compétences est obligatoire pour tous les lycéens, parcourir les questionnaires relatifs à la sécurité rend plutôt optimiste quant aux compétences minimales dont devraient disposer nos concitoyens d’ici quelques années. Le niveau de compétence attendu pour tous les élèves de collège et lycée en matière de sécurité et de protection de la vie privée est plutôt ambitieux. Avec un peu d’optimisme, nous pouvons espérer que dans quelques dizaines d’années le phishing ne sera plus qu’un mauvais souvenir !

A contrario, intervenant depuis une bonne dizaine d’années en écoles d’ingénieurs et universités pour des cours de sécurité, je suis régulièrement surpris par l’absence totale de prise en compte des problématiques de SSI dans les cursus informatiques. Ainsi, certains étudiants ont suivi des dizaines d’heures de C et C++ sans savoir entendu parler de buffer-overflow, imaginant qu’au pire, si leurs tableaux sont gérés à la hussarde, leur programme plantera. C’est certes fâcheux, mais un bon watchdog suffira à relancer le programme si un utilisateur malgache essaie de saisir son nom de famille dans un formulaire d’inscription. Très récemment, j’ai fait découvrir les injections SQL à des étudiants quelques mois avant la fin de leur master alors qu’ils avaient transpiré sur Java et PHP des semestres et que la promo allait faire à 80 % du développement web. Si j’ai la faiblesse de croire que certains de mes anciens étudiants se poseront quelques questions lorsqu’ils devront écrire un code manipulant des données saisies par un utilisateur, je crains que de nombreux étudiants diplômés ces dernières années n’aient entendu parler d’aucune des vulnérabilités du top 10 de l’OWASP. La solution la plus pragmatique (ou réaliste si l’on est mauvaise langue) a été de protéger le développeur contre lui-même à renfort de langages évitant au programmeur de faire n’importe quoi avec la mémoire ou de frameworks destinés à l’empêcher d’interagir directement avec les bases de données. Si je ne récuse évidemment pas la pertinence de concevoir des outils évitant un trop grand nombre de failles, la réduction des risques ne peut pas uniquement reposer sur des briques techniques en partant du postulat que les développeurs feront toujours n’importe quoi en matière de sécurité.

On pourra m’objecter que les formations dans lesquelles j’ai pu intervenir ne sont pas représentatives, mais pour avoir participé à beaucoup de recrutements d’informaticiens, le niveau moyen en sécurité d’un jeune diplômé en informatique est généralement très bas. La sécurité est en effet intégrée dans beaucoup de cursus sous forme de modules totalement séparés du reste de la formation. C’est un domaine malheureusement considéré comme relativement secondaire pour un développeur et relevant de spécialistes dont c’est le métier. La complexification des systèmes d’information a induit dès la formation initiale une grande spécialisation et la fin des informaticiens généralistes passant de la configuration d’un routeur au développement d’une application. Il est néanmoins regrettable que beaucoup de filières ne se contentent, en matière de sécurité, que d’une très fine couche de vernis plutôt que de la considérer comme une compétence transverse à tous les métiers de l’informatique.

Quelques relecteurs attentifs m’ont d’ailleurs soufflé qu’une initiative de l’ANSSI engagée en 2013, CyberEdu [3], vise à introduire les notions de cybersécurité dans l’ensemble des formations en informatique et labelliser les cursus s’engageant dans cette démarche. La liste particulièrement réduite des formations actuellement labellisées [4] donne une idée de l'ampleur du travail restant à accomplir.

Cédric FOLL

[1] https://www.miscmag.com/ledito-de-misc-n98/

[2] http://www.education.gouv.fr/cid2553/le-brevet-informatique-et-internet-b2i.html

[3] https://www.ssi.gouv.fr/administration/formations/cyberedu/

[4] http://www.cyberedu.fr/pages/formations-labellisees/