Les articles de MISC N°82

Image promotionnelle
Protégez vos codes à tous les niveaux 
Article mis en avant

Introduction au dossier : Protégez vos codes à tous les niveaux 

Nous avons tous écrit du code, et avoir quelque de chose de concis et propre reste compliqué. Frederick Brooks le dit bien, un développeur professionnel n'écrit qu'une dizaine de lignes de code par jour. On peut faire le calcul sur un gros projet comme le noyau Linux. En reprenant le dernier rapport de la Fondation Linux [1], c'est environ 19 millions de lignes de code et 12 000 collaborateurs depuis 2005 (date d'utilisation du git). Une estimation généreuse, car le projet a commencé en 1991 et possède donc plus de contributeurs, nous donne le troll chiffre surprenant de 0.43 ligne par contributeur par jour !

Safe Harbor, vos données seront bien (re)gardées. Coup de tonnerre automnal (ou d’épée dans l’eau) dans le milieu des fournisseurs de services : l’accord dit « Safe Harbor » vient d’être invalidé par la Cour de Justice de l’Union Européenne (CJUE).
Lors de l'audit de sécurité d'un client lourd, il est primordial de pouvoir analyser le trafic réseau entre celui-ci et les serveurs avec lesquels il communique. Il est alors fréquent que des besoins plus ou moins avancés se fassent ressentir, tels que : la modification de certains paquets à la volée, le parsing de « protocoles maison », le déchiffrement et/ou la décompression de certains flux réseaux, la séparation des flux selon leur type... Bien que relativement peu connu, l'outil Canape permet d'effectuer toutes ces tâches et s'avère être une sorte de véritable couteau suisse dédié à l'analyse de protocoles binaires, indispensable à tout pentester de clients lourds. Cet article offre un premier aperçu de la puissance de l’outil.
L’analyse des requêtes et des réponses est essentielle lors d’un test d’intrusion visant une application Web. La capacité d’interception, de consultation et de modification de ces éléments est un prérequis indispensable dans l’évaluation de la sécurité d’une telle application par un auditeur, dans la mesure où ce dernier doit pouvoir librement injecter ou modifier des entrées utilisateurs et autres entêtes du protocole HTTP.L’outil Burp Suite [1], développé par la société PortSwigger, répond parfaitement à ces besoins dans la plupart des situations. Il montre néanmoins ses limites dans certains cas où la structure des messages échangés et du protocole applicatif utilisé n'est pas standard, par exemple dans un cas où pour chaque requête, un entête HTTP personnalisé ou un paramètre spécifique (token CSRF, hash, etc.) doit être ajouté pour que la requête soit acceptée. Face à ces situations, l’auditeur va généralement tenter de contourner ces limitations en développant tant bien que mal un script qui sera plus ou moins fonctionnel, qui ne sera généralement pas réutilisable par d’autres et surtout, qui ne sera pas intégré à « l’outil-qui-va-bien » utilisé en temps normal… Afin de répondre à cette problématique, un mécanisme « d’extension » a été introduit au sein de Burp pour étendre ses fonctionnalités de manière programmatique via une API. À travers cet article, nous vous proposons une introduction pragmatique au développement d’extensions Burp en nous appuyant sur deux cas d’usages détaillés, afin de pouvoir rapidement intégrer les éventuelles spécificités protocolaires que vous pourriez rencontrer dans un test d’intrusion.
D'après Wikipédia, « un ransomware, ou rançongiciel, est un logiciel malveillant qui prend en otage des données personnelles. Pour ce faire, un rançongiciel chiffre des données personnelles puis demande à leur propriétaire d'envoyer de l'argent en échange de la clé qui permettra de les déchiffrer. Un ransomware peut aussi bloquer l'accès de tout utilisateur à une machine jusqu'à ce qu'une clé ou un outil de débridage soit envoyé à la victime en échange d'une somme d'argent ».
Les attaques Cross Site Request Forgery (CSRF) sont particulièrement redoutables. Si une équipe de développeurs n’est pas consciente du problème, les applications qu’elle produira seront très certainement vulnérables. Ces dernières années, de gros efforts ont été faits par les éditeurs pour équiper leurs frameworks d’outils de protection adéquats, allégeant ainsi la tâche du développeur. Leurs travaux ont été payants : la prévalence des vulnérabilités de ce type a chuté. Néanmoins, avec l’essor des applications SPA (Single Page Application), la mise en place d’une protection anti-CSRF n’est plus aussi directe. Dans cet article, nous proposons une approche pour défendre une application AngularJS reposant sur un backend ASP.NET Web API.
La protection de code est omniprésente au sein des programmes propriétaires ou des malwares. Essayons ensemble de découvrir les différentes méthodes utilisées par les attaquants et éditeurs. Cet article aborde la protection de code d'une manière générale en présentant au lecteur les différentes méthodes de protection (anti-désassemblage, obfuscation, packer…), mais également l'application de ces méthodes à différents langages de programmation (C#, PHP, VBScript...), ainsi que l'application de ces techniques au malware Dridex. Pour finir, le système d'exploitation Windows et les technologies web seront mis en avant.
L’obfuscation binaire est utilisée pour protéger la propriété intellectuelle présente dans un programme. Plusieurs types d’obfuscations existent, mais grossièrement cela consiste en la modification de la structure du binaire tout en gardant la même sémantique d’origine. Le but étant de faire en sorte que les informations d’origine soient « noyées » dans un surplus d’informations inutiles qui rendra le reverse engineering plus long. Dans ce numéro, nous montrons comment il est possible d'analyser du code obfusqué avec le framework Triton à des fins de gagner du temps.
Au siècle dernier, Sartre écrivait : « Plus claire la lumière, plus sombre l'obscurité… Il est impossible d'apprécier correctement la lumière sans connaître les ténèbres. » C'est cette pensée qui va nous guider tout au long de cet article : découvrir et comprendre quelques techniques d'obfuscation, mais surtout appréhender les mécanismes qui les guident, pour en implémenter de plus robustes, ou pour mieux les contrer.
Un environnement virtualisé a besoin d'utiliser les ressources physiques de notre machine pour fonctionner. Alors que l'accès à ces ressources physiques se fait d'habitude directement par la machine virtuelle, l'hyperviseur est contraint parfois à prendre la main sur la machine virtuelle, et ce en utilisant la fonction VM_exit. Cependant, cette caractéristique entraîne une latence lors de l'utilisation de certaines instructions. Les logiciels malveillants (malwares) peuvent alors utiliser cette particularité en mesurant ce délai pour détecter leur exécution dans une machine virtuelle. Dans cet article, nous expliquons la fonction VM_exit, son utilisation par les malwares et nous proposons un mécanisme de détection de cette dernière.
Qui n’a jamais rêvé d’apporter un peu d’intelligence dans sa maison ? Gérer son système d’alarme avec des notifications en temps réel, ouvrir/fermer ses volets en fonction de l’heure du jour et des saisons, adapter le chauffage de chaque pièce de sa maison au degré près, disposer de toutes les informations sur sa consommation en énergie et tout cela à distance depuis une plage à l’autre bout du monde… C’est pour réaliser ce rêve que la domotique a été inventée.
Nous présentons dans cet article comment renforcer la sécurité par configuration d’un équipement exécutant un système d’exploitation de type CISCO IOS afin de faire face à la fois à des menaces aussi bien distantes que locales (prise en main physique de l’équipement). Ce guide permettra d’associer à chaque menace une contre-mesure de type configuration.
Que se passe-t-il lors de l'exécution d'un malware ? Cet article a pour objectif de parler des premières phases de l'infection d'une machine, en prenant Emotet comme exemple pratique, depuis l'arrivée du logiciel malveillant sur la machine cible, en passant par son intégration dans le système, jusqu’à sa première connexion à son serveur de commande et de contrôle.