Quantcast
Channel: n0secure.org
Viewing all 176 articles
Browse latest View live
↧

Botconf 2018 - J1

December 5, 2018, 1:17 am
$
0
0
C'est reparti pour une nouvelle BotConf à Toulouse... malgré quelques problèmes de transports en commun pour ceux qui ont participé aux workshops ;)

[Edit: @xme à un compte-rendu en anglais ici ]

Swimming in the Cryptonote Pools

Un premier talk du CERT-EU.
Sur BitCoin, on peut tracer l'ensemble des transactions d'un wallet à l'autre. Sur monero, il vous faut la clef privée du wallet pour tracer les transactions. 
Il y a beaucoup de malwares qui minent des crypto-monnaies, et le font dans des pool de minage. L'orateur utilise des règles Yara pour récupérer les id des wallet car il s servent aussi à l'authentification des utilisateurs du pool. Le problème c'est que c'est souvent stocké en base64 dans les malwares, ce qui génère des faux positifs. Lorsque le malware est packé, l'orateur utilise retdec et snowman pour les unpacker avant d'y rechercher des informations sur les wallet.

Les API des pools de mining ne sont pas très privacy by design, et du coup l'orateur peut récupérer les wallet des participants à une pool de minage en lui envoyant les adresses qu'il à trouvé.

APT attack against the middle-east


@CurlyCyber
Description d'une attaque par apt-c-23. Tout commence avec un document piégé citant un article de news,  dont une partie du code est issu d'un code copier-collé depuis slack. Le C&C communique sur https, mais si jamais il n'y arrive pas, il y a une addresse de backup avec une URL encodée en base64 qui répond sur /api/devices/requests qui peut répondre une autre addresse de C&C.  Les fonctions des malwares de ce groupe font souvent référence à des personnages de big bang theory et autres séries télé.

Dans les whois des noms de domaines les plus anciens, on retrouve des informations probablement fausses, mais cohérentes correspondant à une entreprise de de hosting à gaza. D'autres noms de domaines employé par ce groupe pointent sur d'autres entreprises de gaza.

Code Cartographer's Diary

L'orateur nous avais déjà présenté Malpedia l'an dernier. Il s'agit d'une suite de ce talk. L'objectif de malpedia, c'est d'avoir une collection de malwares triés, rangés dans les bon contextes, unpackés, avec des yara associés, etc... L'objectif c'est de pouvoir par exemple faire des associations entre les malwares lorsqu'ils ré-utilisent du code entre eux. Tout ceci pour permettre aux chercheur de mener des expérimentations sur ce dataset (machine learning, IA, etc...).  Le dataset se veut "petit" mais complet en nombre de familles de malwares.

Petit retour sur les techniques de lookup d'API windows employés par les malwares présents dans malpédia: Import PE, Chargement dynamique par appel à GetProcAddress et hash d'API et plein de techniques d'obfuscations.  L'orateur présente en suite quelques statistiques sur l'usage de ces API extraites par ApiScout, leur distribution, leur fréquence, etc...

Malpedia permet de servir de dataset à des techniques de mesure de similarité de code. L'orateur détaille le fonctionnement de MinHash et son usage pour la similarité entre malwares. En gros, il prend les n-gram des mnemoniques et quelques stats sur la fonction, les ballance dans minhash et compare avec une autre fonction.

En faisant de la similarité multi-critères, l'orateur à essayé de comparer des familles de malwares. Le problème c'est qu'il se retrouve avec un gros blob de binaires collés, et plein de malwares éparpillés... cela s'explique par le fait que les malwares utilisent un grand nombre de librairies communes, ce qui fausse le clustering. Du coup en filtrant les libs connues des ensembles de fonctions, on obtiens des clusters par familles.

Chess with Pyotr


Storm Worm: botnet p2p, distribué par du spam. le c2 fonctionnait sur du EDonkey, et utilisait la dht de kademlia pour échanger des infos sous la forme de hash md4. ils utilisait xor pour "encoder" les échanges, mais ne comprennait pas vraiment le fonctionnement de ce protocole p2p. En empoisonnant le cache des bots, on peut faire un takeover sur le botnet et reprendre le contrôle.

Waledac utilisait une architecture hybride avec du p2p et reposait sur les bots avec une ip publique pour servir de relais pour les bots derrière des NAT ou des firewalls. Les worker qui génèrent du spam, etc... était séparé des bots de contrôle qui bénéficiait d'une ip publique. Le problème d'un botnet p2p, c'est de bootstrapper et de trouver un pair auprès de qui récupérer la liste des pairs du botnet avec qui échanger. Chaque pair générais un certificat x509 auto-signé et une clef RSA de 1024 bits. Autre stratégie employés pour le bootstrap: des serveur fast-flux dns avec des reverse proxy.

Kelihos est un botnet de spam, vol d'identifiants de connexion, ddos, de fraude au click, de proxy socks, vol de cryptomonnaies, et de "pay per install". la première version avait un mode debug intégré. Il tournait sur le port 80 par défaut, mais il était conçu pour fonctionner sur un autre port. Le port TCP était stocké sur 4 octets alors qu'un port s'encode seulement sur 2 octets, ce qui à servi aux orateurs pour attaquer le protocole du botnet et l'empoisonner.
le dev de kelihos à été spotté à l'aide de traces laissés dans ses codes. Un download d'un jpeg sur son serveur perso lancé comme tâche de test sur l'ensemble du botnet. Ils ont retrouvé le code d'une partie du malware sur github de l'auteur. Pour le poisoning, ils ont bootstrappé, puis se sont fait insérer dans la peerlist. Les orateurs détaillent le fonctionnement des tâches planifiés sur le botnet, et le mécanisme de template pour les spams.

Kelihos.B est une nouvelle version après le take-over. Apparu le 30 Novembre 2011, il restait des symboles de debug dedans, mais le code source n'était plus publique. Kelihos C à été takedownà la conf RSA, et la version D est sortie 20 minutes après. Les forces de l'ordre ont profité du fait que l'auteur du malware était en vacance en Espagne pour s'arranger avec les orateurs pour effectuer le takedown en même temps que l'arrestation.   

Formbook

@netsecurity1
Formbook cible un grand nombre de navigateur mais aussi certains clients de chat. Il est vendu & loué par le développeur. L'auteur du malware fournissait des binaires customisé par client. Le panel est fourni à ceux qui louent le malware, s'il est acheté, les clients doivent l'héberger eux même. FormBook est dans le top10 de la sandbox any.run.

Pour échapper aux analyses, Formbook obfusque ses chaînes en les construisant avec des mov sur la stack. Les api sont importé par hash, et utilise BZip2 & crc32 pour hasher les noms des fonctions. Il dispose de blacklist et ne s'execute pas si il découvre ces éléments sur le systèmes: noms de process, noms de dll présentes à l'exécution du programme, noms d'utilisateur lié à certaines sandboxes, etc...

Les chaînes peuvent être déchiffrés avec MalwareHash. La table des imports est vide, FormBook importe les fonctions de plusieurs façons: par nom, par ordinal ou par hash. Formbook fait du process-hollowing sur explorer.exe pour migrer de processus, ce qui fait qu'il ressemble à un processus windows légitime. Pour le hooking de fonction dans les programmes ciblés par Formbook, il embarque un petit disassembleur pour écrire les inline hook aussi bien dans des process 32 que 64 bits. Pour récupérer les mots de passes enregistrés, FormBook récupère les bases sqlite de Firefox & Chrome. Pour protéger ses serveurs C&C, Formbook utilise des faux serveurs C&C qui sont contactés en même temps que le vrais serveur C&C.

How much should you pay for your own Botnet

L'orateur à mis en place des botnets de test pour valider des solutions anti-DDoS, il s'est donc demandé combien ça coûtais et si c'était abordable ou pas. Cette présentation ne tiens pas compte des problèmes légaux, et n'a pas pour vocation à décrire les techniques de DDoS. Le coût du botnet dépend du coût de l'infrastructure, et du coût en bande passante. Les deux étant facturé de façon fine sur les plateformes de cloud. Après prise en compte des variation de coût induite par les localisations géographique des serveurs loués, l'orateur à effectué son comparatif.  Il a ainsi pu générer un DDoS de 9TB pour moins de 900€

Collecting particles from Neutrino Botnets

Neutrino est un botnet très connu. Les orateurs nous raconte son histoire et ses modifications, de la première version sans obfuscation aux versions récentes, plus modulaires et embarquant des mécanismes d'obfuscation des appels aux API Windows. La version actuelle chiffre ses modules, et utilise une clef de registre Winlogon pour sa persistance.

Neutrino est vendu à un grand nombre de cybercriminels, du coup il faut réussir à séparer les samples en groupes liés à chaque cybercriminel. L'identification d'une variante de neutrino se fait par les serveurs de C&C, sa version, son nom de bot, et son identifiant de build. La classification par build id se fait plutôt bien.

Les orateurs présentent en suit différents clients du malware, avec leurs objectifs et les modules qu'ils utilisent pour commettre leur forfaits. Les webinjects sont très populaires pour le vol d'identifiants bancaires et la génération de transferts bancaires à l'insu des clients.

Trickbot: The trick is on you !

Trickbot est un trojan bancaire découvert en 2016, très similaire à Dyre. C'est un bot très modulaire, avec du webinject, du vol de mots de passe de clients mail, etc...  Le loader charge un module de coeur et une configuration qui  contiens une liste de fichiers de config supplémentaires et de modules associés à charger. La communication de Trickbot est basé sur un système de commandes. Il y a deux catégories de commandes: soit elle viens du client, soit elle viens du serveur de C&C. Lorsqu'il s'agit du client, on retrouve dans les urls les identifiants de campagne, de client, etc... Du coup les orateurs ont conçu un système de tracking des commandes lancés par les cybercriminels.  La majorité des opérateurs de Trickbot sont en Russie, et la majorité des cibles sont aux US.

Automation and Structured Knowledge in Tactical threat intelligence.

Les orateurs sont membre du GReAT de Kaspersky, et suivent plus de 100 groupes d'attaquants, ce qui génère un très gros volume d'informations techniques. Les incidents isolés au sein des clients de Kaspersky, sont souvent les symptomes d'actions de cybercriminels. Le renseignement sur la menace  est le produit d'un processus de transformation d'élément techniques observés en connaissances sur les malwares, les groupes d'attaquants, leurs méthodes, etc...

Il faut d'abord transformer une expertise technique en un outil, c'est un peu la base de nombreux outils open-source. Le problème c'est de gérer la volumétrie monstrueuse d'échantillons de malwares à analyser. D'abord il faut bien cibler ce que l'on souhaite obtenir, déterminer les action à entreprendre, les subdiviser en tâches atomiques, puis déterminer la faisabilité de chacune. Par exemple, à la question "est-ce que ce sample est malicieux", on fait des vérifs VT, on lance PEiD, etc... on élimine les contradictions à coup d'IDA, et on prend une décision... le problème c'est que la partie IDA est difficile à automatiser "simplement". Du coup, il faut revoir ses attentes, éliminer ce qui n'est pas automatisable, et en faire une chaîne de traitement réalisable et adaptée.

En Threat intel tactique, on utilise un grand nombre de modèles pour faciliter la visualisation de l'information et sa transmission à des personnes moins techniques. Arbres d'attaques, modèles d'adversaires, kill chain, sont les briques de bases pour construire ces modèles de threat intel. L'att&ck framework et autres outils du MITRE sont très utiles pour ce type de modélisations, et offrent un vocabulaire structuré associé. Comme c'est un langage structuré, qui s'adosse à des bases de donnés, on peut s'en servir dans la gestion des connaissances.

Les arbres d'attaques sont assez agréables à lire, mais quand on met trop d'informations dedans, on à du mal à les interpréter s'ils sont généré automatiquement. En plus ils ne sont pas adapté à la visualisation des dépendances. La kill chain c'est linéaire, c'est agréable pour comprendre une séquence d'actions, mais ça n'est pas complet. Les graphs, c'est un super outil exploratoire, mais ça biaise l'analyse, car ça donne l'impression que deux éléments sont fortement liés alors que ce n'est pas toujours vrai.

L'objectif des orateurs est de produire des connaissances exploitables et compréhensibles. Première idée: transformer les sorties de manalyzer et les traduires sur l'att&ck framework. En partant des matrices du MITRE, et en sélectionnant les techniques qui vont bien on peut retrouver les informations de mitigation, de détection. Sauf qu'en pratique, la correspondance entre l'Att&ck et les sorties d'un outil d'analyse n'est pas toujour bonne. De plus, pour un même échantillon, les résultats varient d'une sandbox à l'autre quand aux éléments de l'Att&ck remonté ne sont pas les mêmes.

Le problème c'est que Att&ck modélise l'intention, et que cette intention peut prendre une infinité de variations observable par les outils d'analyse de malwares. Les orateurs ont donc mappé les sorties de manalyze avec la matrice du framework Att&ck pour faciliter l'analyse de ses sorties et leur mise en relation automatique avec les informations de détection et de mitigation décrites dans le framework.




↧
Search

Botconf 2018 - J2

December 6, 2018, 12:09 am
$
0
0
ça commence par du TLP Amber pour le premier talk ;)

[Edit: le cr en anglais par @xme pour le 2ème jour ici ]

Botception: a bot spreading scripts with bot capabilities

Durans le monitoring du botnet Necurs, l'orateur à découvert une campagne d'installation d'un autre bot. Necurs est apparu en 2012,  et il a eu les plus grosses campagnes de spam à ce jour. Necurs est modulaire, avec un protocole de C&C pair à pair. Pour monitorer le botnet, les orateurs ont développé un client qui émule le protocole de Necurs. Chaque branche de Necurs est identifié par un secret partagé au niveau du protocole de C&C. Le panel est en PHP, et son chemin & nom varie d'une branche à l'autre.

Lors d'une campagne, un e-mail était propagé avec un lien vers un fichier vbs. La propagation se faisait via un partage SMB que les orateurs on pu browser et ils y on récupéré toutes les campagnes préparés par le cybercriminel. Ils ont même reçu un message de sa part sous la forme d'un fichier dans le partage qui disait "fuck you!". Le C&C du script VBS était codé en dur dans le script, et communique avec un gate.php sur un serveur web en POST. En récupérant l'exécutable

Le loader VBS était aussi disponible sur le marché noir. Après analyse du mécanisme de drop, ils sont tombé sur le RAT Flawed Ammyy. Une version modifiée issue du leak du code source.

Stagecraft of malicious office document - a look at recent campaign

La majorité des documents malicieux sont des .doc avec des macros, dont certaines contiennent des messages incitant à activer le contenu dynamique pour afficher les informations. Le scénario typique consiste en une campagne de spam avec un lien ou une pièce jointe. La macro télécharge et exécute le malware, qui procède à un fingerprint du système avant de dropper le RAT ou le malware de vol d'information. 

Pour éviter l'affichage de messages d'erreur, un "On Error Resume Next" est utilisé dans le code. PowerShell sert à télécharger la dernière payload (le RAT ou le stealer). Le code powershell est souvent "chiffré". Une autre métode consiste à faire de l'obfuscation avec du junk code. pour l'évasion de sandbox, ils utilisent mshta.exe pour télécharger le second stage du malware.

Une autre campagne utilisait le powershell sous forme de propriété contenue dans des formulaires vbs ou des textbox. l'obfuscation consiste en des caractères morts et un décalage des valeurs ascii de la chaîne de caractères. Une autre variante utilisait BITSAdmin pour télécharger le malware. Le code VB contenait beaucoup de boucles pour ralentir l'analyse.  Une autre variante stockait le script sous forme d'un .bat dans %APPDATA%, mais le doc ne fonctionnait pas avec office 2007.

Souvent toutes ces campagnes comportent un grand nombre d'étapes et de vérifications pour éviter les sandboxes avec des mécanismes d'obfuscation ou de chiffrement très faibles.

Hunting and detecting APTs using Sysmon and PowerShell logging

@c_APT_ure [Edit: slides ]
L'objectif derrière ces techniques de monitoring c'est de coller à la matrice Att&ck et aux règles sigma pour écrire des règles de détection indépendantes des SIEM. Pour exploiter les techniques de l'orateur, il faut avoir les fonctions de logging activés, une centralisation des logs, la dernière version de powershell. Sur 25k machines, ça génère 150Gb par jour de donnés, ce qui fait un beau volume à indexer.

Quand on regarde les sources d'info à surveiller dans Att&ck, le cycle de vie du process ne peut être récupéré que depuis Sysmon. Crowdstrikeà fait une heatmap de genre de monitoring. Les events WMI peuvent servir à la persistance. Mandiant& FireEye ont détaillé le fonctionnement de cette technique. Hexacornà publié un article sur un ensemble de technique d'exécution au démarrage dont une à été utilisé par le groupe d'attaquant Strontium. L'orateur décrit les logs powershell qui correspondent à l'ajout de ces clefs de registres pour la persistance, et comment les extraire. PowerShell étant très utilisé par un grand nombre de cybercriminels dont des groupes d’attaquants. Le monitoring de powershell à été grandement couvert à BSides Washington par Sean Metcalf.

Pour échapper au monitoring, certains attaquant copient l'exécutable powershell et le déplace dans un répertoire random avant de l'exécuter. Pour éviter les faux positifs, on peu par exemple rechercher "Description: PowerShell" et exclure ceux qui s'appellent powershell.exe. Autre exemple avec le stager d'Empire et comment le détecter.

Autre technique: comment automatiser les screenshots avec PowerShell issu d'un blogpost d'un pentester qui s'est en suite retrouvé dans le code de plusieurs cybercriminels. L'outil powerpick utilise rundll32 pour exécuter du powershell.

C'est pas le tout de chasser les trucs malveillants que l'on connait, il faut aussi pouvoir chasser ce qu'on ne connaît pas. On peut construire une whitelist de fonctions powershell les plus connues et exécutés par des scripts légitimes, et s'en servir pour filtrer tout ça et surveiller les fonctions les moins utilisés qui apparaîtraient éventuellement et investiguer à partir de là.

Combattre le Cybercrime à la gendarmerie


La difficulté pour la Gendarmerie, c'est de s'assurer que les équipes techniques ont suffisament de moyens et le soutien qui leur permet de rendre leur missions. L'autre soucis c'est le partage du Threat Intel, qui ne peut pas toujours être obtenu de manière adéquate si l'on considère les contraintes d'une procédure judiciaire (validité de la preuve, etc...). Les Gendarmes ne travaillent pas pour le gouvernement, mais pour la justice et la sécurité des personnes. C'est eux aussi qui mènent l'enquête sur la base de signalement individuels. Autre difficulté, traduire les éléments techniques en quelque-chose de compréhensible pour Mr tout le monde afin de les sensibiliser sur les nouvelles arnaques. La lutte contre la pédopornographie est aussi dans leurs mission, avec comme objectif principal de sauver les enfants victimes de ces trafics.

En plus d'une unité structurée autour de nombreux experts, techniciens et gendarmes formés aux action forensics de base, la gendarmerie collabore activement avec la police, l'ANSSI, Europol et des partenaires internationaux comme le FBI. La vitesse de traitement du problème est crucial. Il faut sur la base du renseignement, être capable de mettre en oeuvre une solution judiciairement viable et techniquement valide tout en respectant des contraintes budgétaires inévitables.

Traiter avec des criminels classique qui opèrent sur le darknet pour vendre leur marchandises n'est pas très simple. Etre capable de faire sauter son anonymat numérique n'est pas toujours simple, même s'ils ont du mal à justifier la provenance de leur argent, il n'ont pas d'éléments incriminent chez eux lorsque la perquisition tombe.  Il n'est pas possible d'inculper quelqu'un sur la base d'hypothèses, il faut des preuves acquises avec méthode. Transformer un tuyau reçu par un expert en une enquête fait partie des missions du C3N. Reprendre l'initiative sur les cybercriminels et anticiper les plaintes qui découlerons de leurs activités est un sacré challenge. Le Cybercrime est le crime le plus difficile à résoudre.

Pour compenser le manque de techniciens et d'experts, la Gendarmerie peut recruter des experts et en faire des enquêteurs pour permettre aux enquêtes de fonctionner dans un environnement technique complexe.

Everything about panda banker.

Le malware est nommé panda à cause de l'anti-virus panda, et le titre panda dans le panel. l'autre nom c'est Zeus/Panda parcequ'il est basé sur le code source de Zeus.  Il y a eu 45 versions du malware jusqu’à ce jour. La version est stocké dans un DWord. Les api sont résolu par leur hash, technique classique d'anti-analyse. En version 2.2.9 les chaines de caractères sont chiffrés, et finissent par faire appel à une mécanique maison et différente de Zeus. De même les mécaniques de configuration ont lentement évolué de la version employé par Zeus à un système dédié à Panda.  Bien entendu, le malware fait appel à un mécanisme de DGA pour protéger son serveur de C&C. Comme de nombreux malwares, il est distribué & utilisé par plusieurs groupes de cybercriminels avec différentes activités.

The dark side of the ForSSHe

Windigo est une opération qui consistait à piper dans une session SSH un script perl qui collectais plein d'infos sur le serveur SSH. Perl est un peu obfusqué naturellement, mais c'est lisible par un être humain.  A partir de l'analyse du script PErl, ils ont recherché avec Yara des échantillons de malwares SSH. Ces backdoors SSH sont des versions patchés d'OpenSSH avec du vol d'identifiants de connexion intégré. Pour ce faire, les cybercriminels ont modifié les fonctions userauth_passd, ssh_askpass, try_challenge_response_auth, etc... qui servent à l'authentification de l'utilisateur.

L'exfiltration des informations se fait sur du GET ou du POST sur le port 80 du serveur C&C, ou par du DNS, ou encore l'envoi d'un e-mail sur SMTP. Voir des protocoles maison sur udp ou tcp.

Kamino par exemple vole les usernames & pass, les exfiltre avec la clef de session. L'opérateur peut se logguer comme root avec un password et une clef publique codée en dur. Kamino est apparemment lié aux groupes d'attaquants Carbanak et Darkleech.

Kessel utilise une fonction de chargement de configuration qui appelle une tartine de fonctions. c'est une famille de backdoors très complexes. Il leak les identifiants et les fichiers de clefs privés, peut exfiltrer par de nombreux protocoles, utiliser un proxy. Il dispose d'une fonction de C&C via les champs TXT de DNS, et il peut créer un tunnel SSH à la demande. Il utilise RC4 pour le chiffrement avec des clefs ssh en dur.

Bonadan réutilise le code d'Ondaron, une backdoor SSH publiquement disponible. Elle communique via un protocole UDP maison. Le mineur de bitcoin associé est pré-compilé sur le C&C, et correspond à l'OS de la victime.

Pour piéger les attaquant, les orateurs ont mis en place un honeypot capable d'être suffisament interractif pour que les attaquants y déposent des échantillons récents.

Borleias backdoor le client SSH, l'attaquant c'est connecté très rapidemnet après le leak des identifiants, via TOR. Il utilise OpenSSH sur Far-NEtbox, il es ttrès prudient quand à son éventuelle détection, et il nettoie l'historique après chaque connexion. Il effectue une reconnaissance en exfiltrant ssh, sshd et cron. La backdoor dispose d'un mécanisme anti-log et utilise RC4+ pour le chiffrement. Il chiffre ses rapports avec une clefs de session chiffré avec RSA.

Chandrila est une backdoor ssh qui peut recevoir des commandes sous la forme de mots de passes. Si elle reçoit un premier mot de passe elle crée un shell. Si elle reçoit un second mot de passe, elle crée un reverse-shell.

Pour échaper à ce type de backdoors, il vaut mieux utiliser l'authentification par clef, plutôt que du login/pass. Il vaut mieux désactiver le login root, et utiliser du 2FA. Vérifiez les sommes de contrôles de ssh & sshd. Linux est bel et bien une cible des cybercriminels, et ils mettent parfois beaucoup d'énergie pour éviter la détection sur les systèmes compromis. 


Onyphe - uncovering darknet websites


Onyphe est un "siem de l'internet" et fournis une API pour récupérer des infos aggrégés sur une IP. Si on peut coreller des informations sur le serveur web avec le serveur sur le darknet, on peut avoir une correllation forte. Pour la correllation, Onyphe utilise un langage de requête similaire à splunk.  Environ 3,3% des .onion sont démasquables.

Living with Kodi and a hole in your network.


Kodi est un player multi-média qui fonctionne à coup d'add-on pour lire des vidéos sur netflix, youtube, etc... Il faut être sûr de soit si l'on veut installer un plugin non-vérifié. Avec quelques fichiers, on peut créer une extension malicieuse qui exécute du python. Vu que l'install des plugins se fait en HTTP, un Man in the middle suffit pour piéger un Kodi.

Why botnet spam is going down


Depuis 2008, le nombre d'e-mails de spam descend. Le top du spam par pays, c'est l'inde, le vietnam et le mexique... c'est parceque c'est de plus en plus dur de faire tourner du malware sur des windows à jour, alors que dans ces pays... Il n'y a pas de meilleur moyen pour une machine que d'annoncer à coup de spam qu'elle est infectée.... Mais bien que le volume du spam est plus faible, le nombre de spam dans les inbox reste important. Les spammeurs se sont adaptés.

3ve


Un takedown sur 2k serveurs sur un botnet qui visait les datacenters. le bot incorpore pas mal de techniques pour éviter de se faire détecter. L'infection est surtout aux us et en allemagne, avec pas mal de serveurs sur toute l'europe.

VTHunting


un petit outil en python pour centraliser les rapports VT et les samples au travers de l'api VT, et envoyer les rapports via email, slack, telegram. Il est directement utilisable en CLI.

Splunkup

un outil pour importer des données de MISP dans Splunk, ou pousser des informations depuis splunk vers MISP.  On peut faire des recherche dans MISP, importer des IOC, créer des alertes dans splunk. Créer des events MISP.

Anatomy of a Booter


equalit.ie - le DDoS quand on a de la chance, c'est un pic de traffic sur le graph de bande passante, mais parfois c'est un site HS. Dans les logs on peut trouver par exemple des pingback wordpress qui servent au DDoS. Comme WP ajoute l'ip à l'origine de la demande de pingback dans le user-agent, il est possible d'identifier l'IP de l'attaquant, avec un répertoire ouvert contenant tous ses outils, et la liste de ses relais.

mwdbv2


malware database version 2. Quand on upload un sample sur mwdb v2, on peut récupérer la configuration du malare extraite. c'est automatisé et ça supporte plus de 70 familles de malwares.
l'url: mwdb.cert.pl

Tsurugi Linux


Tsurugi est une distribution linux orienté DFIR et OSINT soutenue par OpenMinded et basé sur la dernière version d'Ubuntu 16.04 LTS. Turugi acquire est un mini-linux 32 bits conçu pour l'acquisition live. Bento est un windows de forensic maintenu par l'équipe Tsurugi.

A kind of funny story


(j'entend rien :( une histoire de chat sur twitter entre un dev de malware et quelqu'un de MalwaresBytes)

 Bitcoin supply chain attack.


des hits sur un js modifié appellé statcounter.js. Une fois unpacké, on retrouve un js injecter depuis statconuter.com. Le site ciblé c'était gate.io. Dans le 2eme stage, le wallet de destination est remplacé par le wallet de l'attaquant. Un mec de Statcounter à posté qu'il avait installé ESET pour vérifier s'ils n'était pas compromis.


We need your IP Space


shadowserver est une association non-profit qui monitore les botnets et fait beaucoup de sinkholing. Ils partagent leurs infos avec les CERT et les forces de l'ordre gratuitement. Ils n'ont pas assez d'IP dans certains pays pour faire leur monitoring correctement.


Evil maids are evil


Quoi faire contre une attaque type evil maid ? vous pouvez utiliser les donnés SMART du hard drive. Par exemple on peut  monitorer le "power cycle count" qui compte le nombre de fois que le disque dur à été alumé. A chaque boot, s'il augmente que de 1, c'est qu'il n'a pas été booté entre temps. l'orateur à écrit un script sur son github.


↧
↧

Botconf 2018 - J3

December 7, 2018, 12:26 am
$
0
0

WebAssembly Reverse Engineering and Analysis


WebAssembly est un standard d'assembleur pour une machine virtuelle stack-based conçue pour être facilement transformé en langage natif (assembleur). C'est l'équivalent du binaire pour le web. La compilation vers WASM peut se faire avec LLVM 6.0. L'implémentation de référence est disponible sur github. WASM est disponible sur tous les navigateurs majeurs du marché.

Le minneur de bitcoin Coinhive dispose d'un shell en JS, mais le code du coeur est écrit en WASM. De plus les interpréteurs WASM souffre de nombreuses vulnérabilités. d'après les orateurs, WASM pourrais servir dans du bypass de WAF, ou pour du malvertising. WASM à des capacités d'obfuscation de code non-négligeable, et est assez désagréable à reverser. Pour désassembler WASM dans IDA, on peut utiliser le plugin IdaWasm.  WASM est parfois stocké dans un format intermédiaire le .WAT, un équivalent du PYC pour python.

Red Teamer 2.0: Automating the C&C Setup process


Comme l'a dit Eric en introduction, les red-teamer ressemble beaucoup à des attaquants type APT (avec moins de budget ?). Lors des prestations de red-team, l'opsec pour assurer la réussite de la misson est importante. Le problème c'est qu'il y a de nombreux outils de pentest à déployer et qu'ils ne sont pas tous simples à configurer sans faires d'erreurs.

Pour l'architecture, l'orateur utilise AWS et utilise du domain fronting pour échapper aux protections côté client de type DLP. Utiliser des serveurs de mail sur une plateforme de cloud réputé facilite le passage au travers des filtres de réputation pour les campagnes de phishing.

Le RAT est compilé dans une VM à la volée, et intègre le domaine de C&C qui pointera vers le reverse-proxy qui protège l'infrastructure de la red-team. Le déploiement des bucket S3 pour récupérer les résultats du phishing via Gophish simplifie la création d'une campagne de phishing.

Côté OPSEC, il faut que le domaine de phishing ne pointe pas sur une IP qui appartiens à la red-team, au risque de la leaker dans la configuration TLS. L'entreprise doit être prête à répondre aux questions d'AWS lorsque la blue-team va déclancher des demandes de fermeture de service sur l'infra de phishing.

Mirai: beyond the aftermath

Mirai a généré de gros DDoS en s'appuyant sur des IoT vulnérables. Cela a permis de mettre la lumière sur un dette de sécurité conséquente. Après le leak du code source, on à observé des botnet qui protégeaient les IoT des intrusions, et des variantes du botnets. Le nombre de Botnets IoT est en constante augmentation en terme de nombre d'échantillons uniques. en 2016 Mirai représentais 3% des samples.

L'orateur détaille en suite l'architecture et le fonctionnement de Mirai, et comment le botnet était rentabilisé en le louant par morceaux aux clients. A la release du code source de Mirai, les listes de login/pass ont été réutilisés dans  Aidra.  Hajime est un botnet qui viens sécuriser les IoT et qui laisse un message bienveillant sur les devices. Pour mesurer la ré-utilisation de code entre Mirai et les nouveaux samples, on peut utiliser BinDiff (ou minhash comme on l'a vu dans la prez malpedia). IoTReaper par exemple est composer d'une majorité du code de mirai, avec en plus de l'exploitation de vulnérabilités pour la propagation.

Persirai/Http81 réutilise le mécanisme de scan de port de Mirai. Bashlite/gafgyt/qbot  recycle certaines fonctions de scan. HideNSeek recycle le mécanisme de configuration et les fonctions de gestion des connexions telnet. ADB.miner réutilise le portscan de Mirai pour trouver des ports de debug ADB ouverts, puis déploie un mineur monero.

Les variantes mirai sont souvent packé par UPX avec un changement du magic pour empêcher l'unpacking automatique, il faut donc modifier ce magic sur le header du programme avant de le passer à l'unpacking.  OMG est une variante qui a transformé Mirai en service de proxy pour l’anonymisation des cybercriminels.

HTTP Malware distinguishing features


L'orateur explique les nombreuses différences entre une requête HTTP générée par un navigateur web, et celles généré par des bots qui viennent joindre leur serveur de C&C.  Il existe des papiers dans la littérature mais leurs travaux repose sur des jeux de donnés très petits. Du coup les orateurs ont mis en place un système de collecte et d'analyse des headers HTTP pour distinguer les navigateurs des bots.

Pour générer le Dataset, ils ont crawler le top 500 Alexa avec des navigateurs pilotés par Selenium, et exécuté des malwares dans des sandbox et monitoré les requêtes HTTP à l'aide de StratosphereIPS. L'idée c'était de rechercher des erreurs faites par les cybercriminels dans la génération de leurs requêtes.

Les éléments différentiants sont souvent des retours chariots absent, des virgules qui apparaissent à des endroits innapropriés, l'emploi de tabulation au lieu d'espaces, ou des espaces en trop. Ces petits détails ne sautent pas forcément aux yeux mais permettent de distinguer les bots des browsers. La version du protocole HTTP chez des malwares est souvent à 1.0, alors que les navigateurs déclarent du 1.1 sauf pour IE. Un grand nombre de malwares ont des caractères non-ascii dans le corps de la requête POST, et souvent le referer est manquant. La mesure d'entropie est aussi un bon indicateur d'obfuscation ou de chiffrement. Les bots ont tendance à requêter plus fréquement des IP+port là ou les navigateurs requêtent à 99,8% des noms de domaines (dans le dataset collecté ! ). Les bots ont aussi beaucoup moins de lignes dans les Headers, ils dépassent rarement les 6 headers, et la majorité tourne autour de 3 header.

Parfois IE envoie un user-agent Firefox quant il rentre dans un mode de compatibilité particulier déclanché par le contenu de la page. Beaucoup de bots oublient le User-Agent dans les Headers. Bon parfois les navigateurs ne mettent pas de User-Agent dans des requêtes initiant des websocket.  Souvent le User-Agent des bots reprend le nom de la librairie, voir des informations sur le système infecté.

Tracking actors with their WebInjects

Les WebInjects sont des scrips injectés dans les navigateur de victimes infectés par des malwares bancaires et qui viennent modifier le comportement de l'application web pour cacher aux utilisateurs certaines informations de transferts ou bien récupérer des informations d'authentification. Les donnés volés par les WebInjects sont souvent gérés dans un panel à part.

Certains cybercriminels se sont spécialisé dans les WebInjects et vendent des systèmes complets de gestion associé. Ils peuvent se vendre jusqu'a 800$. Yummba est un revendeur de WebInjects aisément identifiable avec un grand nombre de banques ciblés.  Tables est un WebInject au format Zeus et utilisé par pas mal de malwares bancaires dérivés de ce dernier.  inj_inj est en circulation depuis 2015 et se retrouve dans Gootkit, ISFB, ZeusPanda, Dridex, etc.. on retrouve souvent inj_inj comme variable dans l'injection.  LOB_ATS à été nommé d'après l'url du panel "/lob.php".

Pour analyser de façon automatique les acteurs derrière les WebInjects, l'orateur à automatisé l'extraction des configurations & urls de C&C des WebInjects, puis est allé extraire les webinjects sur les C&C en émulant les clients, puis les a aggrégé par similarité & graphé dans graphDB.







↧

SSTIC 2019 - J1

June 5, 2019, 1:02 am
$
0
0
Bon bah, c'est parti pour un nouveau SSTIC au couvent des Jacobins. L'amphi est bien rempli comme à l'habitude.

Alex Ionescu - La mort du génie logiciel

Vice-président des stratégies de détection chez Crowdstrike. Auteur de Windows Internals et reverseur de Windows NT depuis 2000.

En NT4, Mark Russinovich a écrit NTCRASH qui faisait une boucle d'appel de syscall avec des 0x00 qui provoquait des crashs dans le kernel de windows, mais ça s'appellait pas un fuzzer. Avec Windows 2000, NTCRASH ne fonctionnait plus, du coup NTCRASH2 à été publié pour faire du push 0x00, push 0x01 etc... puis appel de syscall, et paf, BSOD. Microsoft à en suite mis en place son SDLC, et l'axe à été mis sur la mitigation des exploits plutôt que sur comment éviter de coder des soft vulnérables. Depuis une course à l'exploit s'est créée pour prouver que tel ou tel bug était exploitable, et ça a créé un marché noir des 0-days. Heureusement que maintenant il existe des programmes de bug-bounty qui ont légitimé ce travail de bug hunting et d'exploit writing, et ils ont permis de réduire le gap entre le bug et le patch.

Hélas, il y a toujours autant de vulnérabilités produites dans les logiciels. La recherche de vuln est devenu un business qui paye. Mais une grosse partie des vulns remontés sont des failles pourries, et on peut se poser la question de l'intérêt de les remonter ? De plus les profils de dev sont attirés par cet argent "facile". Du coup ça réduit le nombre de dev compétents disponibles.

Les bugfixs sont souvent priorisés plus bas que les bugs liés aux fonctionnalités. Comme il n'y a pas assez de dev dans les projets open-source. Et en plus certains devs ne veulent pas patcher parce qu'ils ont mieux à faire de leur temps libre. On claque des millions pour faire du bug bounty sur des projets open-source, mais on met pas 1ct dans le dev open-source visée par le bug bounty. Donc forcément ça ne peut pas bien finir.

Côté formation, il y a des écoles de Fuzz, ou les mecs utilisent les softs des autres et ne savent pas construire des logiciels corrects et sécurisés, mais peuvent crasher des softs pourris et sont certifiés owasp, cissp, mcse et autres. Et du coup c'est les dev retraités qui vont patcher les softs !

Lorsqu'un dev produit un bout de code vuln pour le mettre dans le noyau d'un os très très populaire, le compilateur moderne lève des alertes, mais certains dev utilisent des annotation pragma pour shunter l'analyse statique parceque ça va plus vite. Dans le SDLC on à pas mal de procédures de vérification des bouts de codes qui sont ajoutés dans le noyau et ça doit être reviewé, alors comment un bug comme ça peut être accepté et mis en prod ! Un kernel c'est pas une page web !!! Lorsque l'orateur à découvert le bug, il à touché 10k$ et s'est payé des chiottes pour littéraliement se torcher avec cet argent.... mais est-ce qu'on pourrais pas plutôt mettre cet argent dans les developpeurs ? A force de chasser des bugs Sexy, on en oublie de faire les vérifications DE BASE.

On enseigne mal le developpement logiciel aux étudiants. Quand on note les étudiants, s'ils soumettent un truc, ils ont la moyenne, si ça compile ils ont un peu plus que la moyenne, et si ça fonctionne ils ont une très bonne note. Alors ils font du printf et des strcpy et après ils font developpeurs chez Microsoft. Il faudrait changer le bug-bounty et Payer pour le Patch, et pas pour le Bug.

Attaques side-channel sur des wallets hardware

Bon en gros, les wallet ça stock des clefs crypto pour vos bitcoins & cie. Lorsque l'utilisateur veux faire une transaction, il utilise une application sur son poste ou il prépare ses transactions, et c'est le wallet qui demande l'autorisation de valider la transaction, et en suite la transaction part dans la blockchain.  Les orateurs se sont intéressé au wallet Trezor qui est open-source. Comme c'est open-source, le micro-controleur qui exécute le code est générique, et n'a donc pas d'accellérateur crypto ni de fonctions de sécurité hardware. Toute la crypto s'exécute en soft.

Une attaque side-channel consiste à observer les variation d'une valeur physique sur un circuit électronique tel qu'une consomation elec ou un champ magnétique. S'il y a une correllation entre cette grandeur physique et le traitement du secret cryptographique, il y a vulnérabilité et possibilité de récupérer la clef.

A partir d'un wallet de référence, l'attaquant entraine un classifieur pour reconnaitre le PIN en fonction des valeurs des side-channels. Et du coup avec 4-5 essais on peut récupérer le PIN d'un token volé.

Pour pouvoir analyser sans hardware ces codes embarqués face aux attaques par side-channel, les orateurs ont créé un outil d'émulation basé sur unicorn capable de simuler les traces de fuites qu'on enregistrerais avec un oscilloscope.

Side channel sur le chiffrement dans un chipset mobile

Pour 10k Euros, on peut se faire un lab d'analyse de side-channel, avec osciloscope, sondes hardwares et oscilloscope. Ce qui est chiant sur un mobile, c'est que c'est tout petit, et il y a plein de puces, et la crypto se fait dans le SOC sous la RAM, donc pour l'analyse Electro-magnétique on peut se brosser. Comme la RAM fait chier, on la désoude littéralement. Comme la clef crypto est la mème pour tout les mobiles, on s'en fout, on à juste besoin de booter le SOC mais pas tout l'OS. 

Avec une caméra thermique, quand on fait faire de la crypto au CPU on peut identifier la zone ou le calcul s'effectue car elle chauffe. (mon cerveau aussi il chauffe quand ça cause crypto...). On viens alors sniffer au niveau electro-magnétique autour de la zone chaude pour trouver les pics EM correspondant aux boucles d'AES, et on viens récupérer la clefs (Magie !!!).

LEIA: un analyseur pour carte à puce

c'est la galère d'écouter le signal EM sur un lecteur de carte à puce, parceque l'antenne est grosse et on est vachement loin du device... donc l'acquisition est très bruitée, il faut écouter longtemps pour éléminer le bruite ET en plus si on change de device ça marche plus.

Du coup les orateurs ont choisi de créer un hardware dédié pour communiquer avec la carte à puce et de faire les mesures des side-channels. Les orateurs se sont basé sur ChipWhisperer. Comme l'écosystème est de qualité, très utilisé par les académiques et pas cher, bah c'est top et on à pas besoin d'oscilloscope. Par contre pour s'interface avec, c'est pas simple. Le protocole de com de la carte a puce est pas bien implémenter, et pour causer avec le PC c'est du UART donc pas ultra flexible. La capacité mémoire du ChipWhisperer est très limité en plus, il faut donc limiter la taille des captures. Pour pallier a ces galères, on peut créer un device de capture supplémentaire qu'on ajoute sur le ChipWhisperer.  

C'est pas simple de gérer l'interconnexion avec la carte à puce et de se synchroniser. Malgrès un design bien pensé, il a fallu débogguer le hardware à coup de breadboard et de fils de partout. Une fois le design revu, on obtiens une carte avec un form-factor adapté au ChipWhisperer.

pour que LEIA soit compatible avec un maximum de cartes à puce, les orateurs ont du coder une pile ISO7816 assez complète. En plus d'implémenter les fonctions du protocole, les orateurs ont choisi aussi de gérer les cas limites. Tout le projet est en open-hardware & open-source sur github
https://github.com/cw-leia/

iDRACKAR

l'iDRAC est un outil de gestion de hardware de DELL, un peu comme le HP ILO4. Récement, une vulnérabilité sur l'iDRAC à été présenté à la Black-Hat. La question que se pose donc l'orateur, c'est est-t'il possible de compromettre le système géré par l'iDRAC à partir de ce dernier. Pour analyser le fonctionnement de l'iDRAC, on peut lire les firmware qui ne sont pas chiffrés, ou aller sur opensource.dell.com pour lire le code source des composants GPL employé dans le serveur iDRAC.

A partir de la vuln BlackHat, on obtien un shell qu'on élève très facillement à root. Côté hardware, on à un processseur SuperH4, et quand on regarde les doc hardware, on à des composants bizzares, genre un bus de communication vidéo avec l'iDRAC en coupure entre le chipset graphique et le root pci-express. L'iDRAC embarque un CPLD, un espèce de fpga simplifié, mais qui n'est pas connecté au PCIe. Il est utilisé pour implémenter l'émulation usb. Sur des doc internet de lenovo, on croise un composant Renesas SH7758 présenté en tant que PBI. Dans l'iDRAC il y a l'outil pbitest qui permet d'afficher les registres de config PCIe. Ce périphérique peut émettre des requêtres DMA, ce qui signifie qu'il peut faire des accès directs à la mémoire du système. En PCIe il existe un système de routage des addresses mémoires PCIe. Et pour chaque périphérique PCIe, il y à une zone mémoire associée à chaque périphérique pour communiquer avec ce dernier. Le PBI peut communiquer avec un écran LCD qui affiche des informations en facade du serveur.

Quand on regarde le code de boot de l'iDRAC, on tombe sur un commentaire ou le developpeur écrit dans un registre pour câcher le PBI afin d'éviter un bug. Lorque le iDRAC démarre, il flash le firmware du contrôleur PCIe. Le firmware utilise le jeu d'instruction H8S d'Hitachi & Renesas. On retrouve ce jeu d'instruction dans des climatisations ou des légos. On peut communiquer avec ce chipset via des commandes iDRAC.

L'orateur ne sait pas si on peut accéder à la RAM depuis un iDRAC compromis, mais ça sent pas bon du tout, et le CERT-FR recommande de ne PAS connecter à internet ses iDRAC.

WEN ETA JB

Présentation de l'ensemble des mitigation présentes sur iOS, de l'exécution de code arbitraire dans une application jusqu'a la compromission complète du device (dans les actes). Le navigateur d'iOS est basé sur WebKit et JavaScriptCore. Typiquement on viens compromettre un objet JavaScript, typiquement un tableau, pour obtenir un r/w arbitraire dans la mémoire. Gigacage est une mitigation apple prévue pour contenir les objets dangereux dans une zone mémoire de 32G et tous les pointeurs sont modifiés avec un masque pour forcer les accès dans cette zone mémoire.

Tous les navigateurs modernes utilisent du JIT pour accélérer l'exécution du code JavaScript, et du coup c'est fait dans une zone mémoire dédiée au JIT en RWX. Du coup pour l'exploitation, on écrit une fonction JS, on l'appelle souvent pour qu'elle soit JITée, puis on l'écrase avec le shellcode.  Pour éviter ça, les Heaps du JIT sont coupés en deux portions, une en RW, et une autre en RX avec un mapping automatique entre les deux. Du coup pour exécuter arbitrairement du code il faut pouvoir écrire arbitrairement dans cette zone, puis exécuter dans l'autre zone mémoire, dont l'adresse est bien entendue randomizée (sinon c'est trop facile).

Avec les nouveaux chipsets ARM est arrivée la solution PAC: pointer authentication Code, qui va signer cryptographiquement les pointeurs "dangeureux" pour éviter qu'ils soient modifiés. Cette solution est "sensible au contexte", et du coup d'un contexte d'éxécution à l'autre, la signature peut être différente. (gestion du changement de contexte ?). Du coup sur des chip > A12, le ROP est mort à moins de pouvoir signer des pointeurs. On peut faire de la substitution de contexte, si les pointeurs sont signés avec un contexte null. PAC remplace progressivement la GigaCage.

Pour l'élévation de privilège, on va cibler les daemons utilisateurs, le kernel, et ses extensions. Par contre avec la généralisation du sandboxing, les applications ont accès à de moins en moins de surface d'attaque. La sandbox KEXT est basée sur le framework MACF hérité de TrustedBSD. La sandbox hook les syscall pour vérifier que l'application à le droit ou pas d'effectuer une action.  La signature de code est activée par défaut, et sert à donner les autorisations à la sandbox. C'est un module kernel qui effectue la vérification des autorisation sur la base de la signature. Soit il s'agit d'une signature Apple, soit c'est une signature de Dev. Le daemon chargé de valider les signatures était avant trusted dans le kernel. Maintenant il y a CoreTrust qui viens vérifier que le binaire est bien signé comme il faut AVANT exécution.

Pour limiter l'exploitation de daemon user-land, on à les classiques nx, aslr & cie, et en plus le système des platform binaries qui empèchent l'exécution de librairies arbitraires. En prme il y a PAC qui tue le ROP, il faut donc faire du JOP (jump oriented programming) pour exécuter du code arbitrairement. PAC est reservé aux binaires Apple, et donc c'est plus compliqué d'attaquer un daemon depuis une appli "classique que depuis une appli Apple qui peut signer des pointeurs avec PAC.

L'attaque du noyau et des extensions du noyau (KEXT) permettent une élévation immédiate, mais tout rattage provoque un crash du téléphone. Du coup Apple à rajouté des protections Kernel pour empêcher l'écriture sur des ensembles de pages mémoires. Du coup même avec un RW arbitraire, comme on ne peut pas créer de pages mémoires arbitraires pour exécuter du code Kernel. Les attaquants sont donc obligés de se contenter d'attaques "data-only". Dans les SOC A12, Apple à ajouté une protection contre ça. (Plus d'informations dans les actes, si j'ai écrits des conneries corrigez moi en commentaire, j'intègrerais les pull-requests)

Attaques sur un HSM

Les Hardware Security Modules, sont souvent utilisé dans les autorités de certifications ou les PKI pour la génération des clefs crypto. Les orateurs ont étudié un HSM sous la forme d'une carte PCIe. Ces cartes sont protégés physiquement par une grosse couche Epoxy. On y découvre un slot pour un connecteur ethernet, qu'il suffira de souder pour obtenir un équivalent de la version réseau.  Le HSM s'installe sur n'importe quel hôte, et on communique avec la carte PCIe via le SDK fourni avec.

Le HSM est livré avec un firmware de mise à jour signé, mais en clair. C'est un linux PowerPC pas vraiment à jour.  Pour causer avec le HSM, on utilise une API Cryptographic Token Interface documentée avec pas beaucoup de fonctions. Par contre ces fonctions prennent en paramètre des mécanismes crypto qui eux sont très très très nombreux, et qui offrent donc une surface d'attaque plus grande.

L'API manipule des données à l'aide de Handles, et les données ne serons jamais copiés côté client. Le client doit donc utiliser ces Handle pour désigner les clefs crypto à employer, etc... Les données peuvent être marqués comme privés et comme non-extractible pour éviter l'accès non-authentifié aux donnés privés, et l'extraction des secrets cryptographiques tels que les clefs privés.

Les orateurs partent du principe que l'attaquant à accès au serveur contenant le HSM et qu'ils ont le plus haut niveau de privilèges dessus. Les HSM supportent aussi des modules personnalisés qu'on peut coder et compiler avec la toolchain fournie dans le SDK. Premier module: un shell sur le HSM. Une fois le shell obtenu, on constate que le noyau est périmé, et qu'il n'a aucune protections. Il n'y a pas non plus de secure boot. Les orateurs ont fait du fuzzing sur le HSM en limitant la mutation de certains octets pour éviter les crash. Ils ont trouvé un équivalent a heartbleed sur le HSM. Ils ont aussi trouvé de la confusion de type PKCS11 un peu comme en python ou PHP. Bref, c'est gavé de vuln, et comme ya pas de secureboot, l'intégrité du HSM n'est pas garantie.

L'Audit des GPO

Les GPO servent aux administrateurs Windows pour pousser des configuration sur les postes du parc au travers de l'active-directory. L'orateur explique les principes de fonctionnement des GPO, puis la méthodologie d'audit de ces GPO, de leur collecte à leur priorisation. Puis les GPO sont filtrés en fonction des CSE à activer. Ces CSE Sont en suite ordonnées, puis exécutés.

Pour désactiver des GPO, on peut mettre leur révision à 0, modifier la révision, modifier le niveau fonctionnel (qui doit toujours être à 2), etc... (plus d'éléments dans les actes).

L'orateur présente en suite son outil GPOcheck qui sert à faire l'inventaire des GPO. L'analyse des droits d'accès d'une GPO est primordiale pour l'étude des chemins de contrôle. (présenté précedemment à SSTIC). Si une GPO contrôle un poste qui lui même est employé par un admin qui à les privilèges suffisant sur le domaine, alors cette GPO permet la prise de contrôle du domaine.

L'orateur décrit en suite le fonctionnement de son outil d'audit de GPO. On exporte d'abord des GPO à l'aide du moteur GPO au format XML.  Les fichiers XML sont en suite transformés en .SQL puis importés dans une BDD qu'on peut en suite requêter.

IDArling, plateforme de rencontre pour reverseur

Le principe c'est de faire de l'édition collaborative en live sur IDA. On peut soit lancer un serveur tiers pour la collaboration, soit utiliser un serveur "intégré"à IDArling. Chaque utilisateur à un curseur de couleur qui lui corresponnd. La synchronisation marche aussi pour le décompilateur, et les changement de types, d'enum ou de structures. On peut "inviter" quelqu'un à regarder une zone de code, et aussi un système de "follow" pour suivre les actions d'un autre utilisateur.

Le dev était loin d'être une partie de plaisir. Mais comme les dépendances sont réduites à 0, il suffit de drag-drop le plugin dans IDA. On peut aussi l'installer via IdaPython.  Par contre il n'y a pas d'API dans IDA pour charger un IDB. Du coup il a fallu bidouiller avec la fonction de snapshotting pour écraser l'IDB du snapshot puis le restaurer. Autre problème: comment colorer la fonction. Les orateurs ont utilisé Qt et rajouté un proxy pour modifier l'interface. Dernière difficulitée, les bindings python sont complètement cassés.































↧

SSTIC 2019 - J2

June 6, 2019, 12:02 am
$
0
0


Journey to a RTE-free X.509 parser

Un parser "safe"à coup de méthode formelle (ouch). X.509 c'est un format d'encodage des certificat en Type, Longueur, Valeur, avec une complexitée horrible. c'est de vrais poupées russes, et c'est une source d'erreurs de programmation et donc de vulnérabilités. L'orateur détaille un exemple de vulnérabilité liée à X.509 lors de la vérification d'un certificat par une bootrom.

Un parseur X.509 "propre" c'est essentiel pour la sécurité, et très délicat à implémenter. Le C c'est vachement bien, il y a (encore) pas mal de dev C. Par contre c'est source d'erreurs fatales, alors on aimerais bien avoir du C99 propre, et pas de trucs exotiques à base de pointeurs de fonctions & cie. Pour la compilation, on viens utiliser des flags de compilation stricts pour limiter les erreurs.  Les orateurs se sont donc appuyé sur Frama-C, une plateforme de plugins d'analyse de code. A l'aide de commentaires on va venir spécifier des propriétés que Frama-C va vérifier.

Les orateus ont passé autant de temps sur le dev que sur les annotations Frama-C, mais ils étaient débutant avec Frama-C, et avec un peu plus d'expérience ils irons plus vite par la suite. Pour la gestion des pointeurs de fonctions, le framework aide énormément le developpeur pour valider la sûreté de leur emploi. La courbe d'aprentissage est loin d'être triviale.  Il manque aussi de la doc sur les idiomes de developpement usuels pour faciliter le dev. Au début, les warnings sont compliqués à digérer, mais ça s'arrange après. Le développeur capitalise sur ses annotations,  et il n'a pas à les modifier lorsqu'il patch son code (bon sauf s'il se foire sur ses annotations hein...). Les plugins Frama-C sont complémentaires les uns des autres, et on peut les activer au fur et a mesure du dev pour progressivement durcir et améliorer son code. Le code est disponible sur le Github de l'ANSSI.

DLL Game and auther mis-directions

Chargement de DLL windows et cie. C'est souvent qu'on à des problèmes de chargement de DLL sous windows, avec plein de réponses obscures sur des forums ou on vous dit de formatter/réinstaller. WinDBG est un debuggueur windows qui marche bien, mais il faut breaker sur tout les chargements de DLL, et c'est chiant. Alors un dev de microsoft à créé Dependency Walker pour analyser ce genre de problèmes. L'outil à été developpé il y a 20 ans, mais il n'est pas vraiment supporté par Windows, et le loader NT à pas mal évolué.

L'orateur à donc redéveloppé l'outil pour analyser le chargement des DLL en comparant le binaire sur disque avec sa version exécutée. Le chargement de DLL sous Windows est très complexe (cf actes). Avec cet outil on peut analyser les dépendances de certains binaires qui charge des DLL qui n'existent pas sur le disques, et du coup en écrivant une DLL malveillante à cet endroit, on peut injecter du code arbitraire dans l'exécutable. Si cet exécutable est démarré par une tâche planifiée ou est lancé au démarrage de la machine, l'attaquant obtiens une persistance sur la machine.

Mirage: un framework d'attaque BLE

Les orateurs ont créé un framework modulaire qui travaille au niveau radio pour implémenter des attaques BLE. Les frameworks disponibles en open-source ne sont pas très adaptés pour réaliser des attaques BLE. Les communications BLE se font sur de multiples canaux avec un mécanisme de sauts de fréquence, du coup il faut que les devices se synchronisent pour les sauts de channels. Le framework intègre donc un ensemble de modules pour gérer les phases de connexion master/slave, le scan de devices, l'appairage, etc... Et bien entendu, des modules d'attaques pour faire du MitM, du Hijacking comme beetlejack de @virtualabs, et du sniffing BLE comme avec ubertooth ou beetlejack.


BGP et géométrie Riemmanienne

La surveillance de graph, c'est pas simple, parceque les liens et les lieux représentent des éléments de nature diverses, mais ça permet de représenter des relations faibles voir incertaines. La surveillance de graph consiste à observer un graphe dynamique et de décider si un changement local aboutira à un changement local. Les graphs sont extrèmement sensibles à un changement local, et ça peut affecter profondément sa topographie (plus proche chemin, communautés etc...).

Le spectre d'application de la surveillance de graph est énorme, des réseaux sociaux à la génération de proteines en passant par la sécurité informatique.

L'orateur détaille en suite les bases de la géodésique et les théorèmes mathématiques applicables: courbure de ricci, théorème de poincaré, Gauss-bonnet, Gauss et sa fourmi. (T.T finalement la crypto c'est pas si dur...). L'ensemble de ces travaux mathématiques commencent à être appliqués dans le domaine informatique sur les graphs.

Rappel sur le problème de la brouette de monge et du transport de charge d'un point A à un point B de façon optimale. Ce problème à été posé à Monge par Napoléon pour que les soldats ne soit pas épuisé par la tâche de déblaiement/remblaiement. Kantorevitch à adapté ce problème à la production et au transport optimal d'Obus. Ce problème est semblable au routage de paquets dans un réseau. Lorsqu'on applique Gauss-Bonnet à un graph, on peut observer les changement de topologie des graph à fort impact.

Sur internet, il ya entre 10k et 50k annonces de changement sur BGP par seconde ! L'intégralité d'internet est constituée de 60k à 150k noeuds. L'orateur à donc mis en place une infra d'intégration de feeds BGP qui viens créer des "snapshots" d'internet toutes les minutes sous la forme d'un graph. Une fois le graph obtenu, on peut calculer les courbures sur le graph précédent et le graph suivant, puis la différence entre les courbures. En observant la variation de ces différences, on peut mettre en oeuvre un seuil de détection d'annomalies topographiques.

Lorsque google s'est foiré sur une annonce bgp appellé leak, l'ensemble de l'internet est annoncé comme joignable depuis le réseau de google et au départ de google, du coup l'internet c'est topologiquement rétrécis. Si l'on compare la distribution des annomalies par rapport à Chi2, on se rend compte que tous les hijack BGP et les leaks sont en queue de distribution et complètement écartés par rapport à Chi2.

Lorsqu'on compare les plans de transport avant une annomalie et après une annomalie, on observe le transfert de la charge des paquets d'un chemin vers un autre. Bon quand on veux faire ça en temps réel avec un graph de l'internet toute les minutes, il faut faire tout ces calculs en moins d'une minute... oubliez Python, l'orateur à testé et ça marche pas à cause du GIL. (bon et sinon ya Celery hein ;) )

 Lorsqu'on observe les variation topologique BGP par rapport à la géopolitique, en prenant en exemple la russie et l'ukraine, on observe deux boules connectés, et la formation d'une petite boule qui progressivement migre de l'ukraine à la russie, puis s'y intègre. Actuellement on observe la formation d'une nouvelle boule qui s'extrait de l'Ukraine et qui correspond au dombas, on peut donc s'attendre à quelquechose sur cette région dans l'avenir.

La recherche multidisciplinaire est un impératif en cybersécurité, car cela mélange géopolitique, informatique, mathématiques etc...  et le domaine du suivis des graphs est très jeune.

GUSTAVE: Fuzzing de systèmes d'exploitation embarqué

L'objectif était d'étudier des OS embarqués tout petits, peu dynamiques et dont le comportement est défini à la compilation, avec des couches logicielles métier très spécifiques et avec des mécanismes de ségrégation mémoire très forts pour éviter qu'une application puisse en corrompre une autre.

Afin d'éviter l'analyse manuelle des syscall dans des OS aux fonctionnalités obscures, les orateurs se sont orienté sur du fuzzing piloté par la couverture de code.  Pour se faire, les orateurs se sont orienté vers AFL. Le problème, c'est comment adapter AFL, sans le modifier, et éviter des dev spécifiques à l'OS. Pour éviter ces modifs, AFL crois qu'il Fuzze Qemu. Les orateurs ont donc développé une couche intermédiaire via une board Qemu générique intégrant AFL. les fork sont ainsi simulé par snapshotting de la VM. Le TCG de Qemu n'a donc pas eu à être modifié, et donc on peut bénéficier des modules d'accélération matérielle pour les infra PPC et x86. Qemu à une API mémoire bien foutue qui permet de mettre à jour la bitmap AFL dans la cible. Comme AFL peut partir d'inputs random pour générer un PNG valide, les orateurs ont eu pour idée de fournir en entrée des syscall à AFL qui va le transformer en programme "malveillant".  Pour détecter les timeout, les fins d'exécution ou les accès illégitimes, il faut jouer avec les breakpoints Qemu. Pour les accès mémoire, les orateurs ont développé un oracle pour détecter les accès mémoire illégitimes.

Dissection de l'hyperviseur VMWare

Quelle confiance peut-on avoir sur la virtualisation ? le risque principal, c'est que l'isolation entre les machines est logique, et donc un VMEscape est possible. VMware offre de nombreuses fonctionnalité permettant d'améliorer l'ergonomie. D'un point de vue recherche de vulnérabilités, c'est une bonne cible. 

La virtualisation se met en oeuvre avec les extensions VT-x et utilisent des structures VMCS pour contrôler la transition entre le ring -1 de l'hyperviseur et le ring-0 virtualisé du guest. Le mécanisme Backdoor de VMWare passe par des ports d'entrée-sorite spécifiques et qui ne nécessitent pas d'être ring0. Il n'y a donc pas de différenciation de l'origine de l'appel. RPCI sert à faire passer des messages du système invité vers l'hyperviseur. TCLO permet de faire des requêtes de l'hyperviseur vers le système invité. Ces commandes sont une cible privilégiée pour le fuzzing et la recherche de vulnérabilités type VMExit.

Le reverse-engineering de l'hyperviseur est complexe car il y a beaucoup de DLL, plein de chaînes de caractères dans les binaires, etc... Bon ça aide pas mal à la rétro, et par le biais des xrefs on peut repérer plus facilement les mécanismes non-documentés. On recherche en suite des RPCI correspondantes, ce qui permet de trouver de nouvelles fonctions à fuzzer.

Dans l'hyperviseur il y a la VMDB qui fonctionne comme un système de fichiers et qui contiens plein d'information sur le système invité. sous windows, on a deux processus: vmware-vmx.exe qui gère l'hyperviseur et vmware.exe qui gère l'interface graphiques. La VMDB est au coeur des IPC entre ces deux composants. On peux donc mettre des breakpoints sur les readfile/writefile de la VMDB et observer les RPC.  Coté mode UNITY c'est l'host qui fait basculer le guest en communiquant avec les extensions tools via le protocole Backdoor.

Les orateurs ont en suite mis en place du fuzzing sur ces RPCI pour provoquer des crash avec plus ou moins de succès. Du printf qui fait foirer l'hyperviseur au bug XPATH dans la gui.

Watermarking Electro-magnétique

Comment insérer des marqueurs dans une cible non-coopérative ? on génère une perturbation qui va atteindre un sytème de stockage et reproduit par la cible pendant une durée plus ou moins longue. On obtiens donc un canal caché pour stocker et transporter de l'information. En fonction des capacités du canal de com et du stockage, on peut envisager divers scénarios. 

Exemple de scénario de Watermarking: le tatouage de films projetés en séance permettant d'identifier dans quelle salle à été induement filmé le film. Autre exemple; avec un enregistrement audio, en repérant le bruit dans l'enregistrement généré par l'alimentation électrique, on peut en déterminer une signature carractéristique du lieu qui à alimenté electriquement l'enregistrement.

Le cas d'usage du présentateur vise le survol de drones. l'idée est d'insérer lors du vol un marqueur sensisble qui va se retrouver dans les journaux de vol, et ainsi on va pouvoir lors de l'enquête déterminer si le drone à survolé la zone interdite ou non.

L'orateur à créé un lab à l'aide d'un drone civil dépourvu d'hélices pour éviter qu'il ne s'envole (petit drone si tu n'a pas d'hélices.... bah tu peux pas voler).  Du coup on met le drone en mode vol nominal, et on injecte des perturbations EM, on regarde si ça fini quelquepart dans un stockage et si ça impacte le profil de vol ou le rayonnement EM de la cible, et combien de temps il dure. Cette technique est très adhérente à la cible, ça fonctionne dans des conditions idéales, maintenant à voir ce que ca donne en vrai.

10 ans de challenge SSTIC...

Triste de la fin du challenge securitech, Stéphane duverger s'est dit que ça serais sympa d'avoir un challenge pendant le SSTIC. Il propose un mini-ctf, mais le CO n'était pas chaud, et propose à la place un challenge Avant le SSTIC. A l'époque il fallait écrire une solution en 7j. 

Le challenge était une image de boot disquette basé sur le mode virtuel des 8086. A l'époque un truc qui servait a rien à part faire chier. Hélas au même moment IDA à sorti le support de BOCHS. Puis il y a eu les cadeaux dont le fameux trophé moche. 

Le challenge SSTIC 2019

Le scénario était basé sur un pseudo-téléphone virtuel qui fonctionne dans Qemu et qui boot sur un arm-trusted-firmware avec iROM, BL1, BL2, Moniteur, Secure OS + edk2(BL33)+ Linux. C'était un boot chiffré avec uniquement l'iROM en clair, le Keystore non fourni. 

4 stages: analyse d'une trace de consomation de courant lors d'une exponentiation modulaire, un circuit logique piloté par bouton, une appli en DWARF2 et un skipjack whiteboxé dans une vm répartie dans des niveaux d'exceptions. Le code du challenge est disponible sur github.

Sollution du challenge SSTIC.

Quand on trace avec numpy et matplotlib la consomation, on observe rapidement une zone de consomation force, et quand on zoom, on observe deux patterns qui se répètent et qui correspondent aux bits de la clef à 1 ou 0. Le pattern match avec l'exponentiation rapide. (T.T)

On peut en suite booter la vm Qemu avec le secure element. Le schéma du securelement permet avec un découpage intelligeant permet de re-générer le code en python, et on est capable de déterminer les boutons pressés à partir du sha256. 

La 3ème étape est un fichier ELF arm64. L'orateur à utilisé ghidra pour décompiler le code, et on retrouve une chaîne qui fait l'objet d'une comparaison. A l'exécution dans Qemu, la copie de chaine n'est pas atteinte. quand on exécute le binaire dans un environement "sain"ça foire aussi mais différemment. Quand on regarde de plus près le fonctionnement de la gestion des exceptions qui se fait en DWARF. Ce langage est interprété, alors l'orateur l'a localisé, puis à extrait les 57M de lignes de codes. Une fois la clef trouvée, on tombe sur un autre binnaire qui contiens "/dev/sstic" dans ses strings. Avec STRACE sur le binaire, on voit 4 ioctls qui servent à communiquer avec un driver. Il faut donc reverser le driver. (et c'est HARDCORE )

RUMP Sessions

Cette année c'est 3 minutes par speaker (ouch)

rump 1 - SSTIC

Le président du sstic à décidé de dissoudre le commité d'organisation de SSTIC et mettre un terme à la chianlie des gilets rouges, pour remplacer le régime gérontocratique par un régime fachiste. Raphael rigot est élu président de l'association pour 3 ans. Remerciement aux anciens et futurs retraités: NicoB, Ben, Moutane et OlivierL. Retour sur la significations de la couverture du SSTIC. 

Les places cette année se sont vendue en 9 jours.  La partie la plus chère c'est le social event, et le couvent des jacobins. 205k euros, sans sponsors et uniquement via la billletterie. Le budget du couvent à pris 11% par rapport à l'année dernière. 24500€ pour l'amphi, 1020€ pour la connexion pour le streaming, la confing du VLAN pour 500€ et le transpalet pour les actes.... 28€

rump 2 Pourquoi? - Pierre Capillon

Pourquoi la carte est déchirée ? pourquoi pas !, et pourquoi les couleurs correspondent pas ? parcequ'une carte c'est fait de plusieurs couches et que donc ça match pas toujours. Côté streaming, la doc complète à été diffusée sur le blog du SSTIC. 

Pourquoi ça clignotte ? Il y a un convertisseur HDMI vers Ethernet qui passe sous les planches et les cables sont dénudés et très tendus, du coup ya des faux contacts, et comme la vidéo est en full HD ça se voit. 

rump 3 Le maillon faible - Patrice Auffret

Quelle est la machine la plus vulnérable sur Internet ? par exemple celle qui à le plus de CVE dont le score est suppérieur à 7.5, exploitable à distance. Pas de test unitaire des CVE mais uniquement des vulns potentielles. plus de 10, ouai, plus de 20 encore, plus de 50 il y en a encore, plus de 100 ? il y en a 2, une aux US, une en Suède. Du Apache 1.3, du php 4.4... est-ce un honeypot? en tout cas il est très crédible.

rump 4 WMI attack tools: WMI Shell, WMImplant, Crackmapexec - Andrei Dumitrescu

Plugin Crackmapexec qui va vous changer la vie ? comment extraire des choses si tous les protocoles sont bloqués sauf le 135 ? bon ya WMI, on peut l'interroger et s'en servir pour executer des process mais on peut pas en récupérer la sortie. Sauf si on le stock dans la base WMI. L'orateur à donc créé un tool qui fait le café, bientôt dans le github de orange cyberdefense. 

rump 5 When a reverser does pentest... - Fabien Perigaud

D'habitude l'orateur fait du reverse d'habitude, mais la c'était un pentest sur symphonie, avec un module de payement qui fait appel à un binaire externe avec des paramètres controlés par l'attaquant, et la c'est comme dans un CTF. La fonction à un pov STRCPY tout pourri avec un Main qui termine par des exits, l'argument contrôlé est double-encodé Hex+UUEncode. Du coup en regardant plus loin ya une vuln dans le binaire exploitable en ROP. on brute-force puis ça passe ! Le vendeur malgrès un responsible disclosure n'a pas répondu à l'auteur. 

rump 6 Thermomix: all your recipes are belong to us - Jean-michel Besnard

Le thermomix tourne sous linux, le truc vert qui contiens les recettes c'est une clef usb chiffrée. Quand on récupère le source auprès du constructeur. comme sa femme à pas voulu qu'il ouvre le thermomix pour chercher un port jtag, il a donc acheté la clef wifi. La clef est pas chiffrée... Ya peut-être un système de restoration ? et ouaip, ya une vuln dans le tar. ya plein de contraintes d'exploitation, mais on peut utiliser tcpsvd pour binder un shell. Quand on regarde le code DCP il sert pas a déchiffer mais à vérifier si la clef est bonne... on récupère la clef hardcodée dans le kernel. On modifie les fichiers qui sont signés... Avec un raspi0 on fait un fake-usb et on peut patcher la recette du far breton.

IceBox

VM introspection basé sur FDP et Sandbagillity, et ils ont rajouté du code natif pour permettre le tracing entemps réel, des os helpers, etc... Multi-platform, basé sur un virtualbox patché prêt à l'emploi, performant, et supporte windows 10 1809. Le code sur Github.

rump 7  IDATag - Tag ta base - Arnaud Gatignol

décallé ?

rump 8 L'analyse statique et le testing a la volée pour les nul(l)s - Constantin Vurli

Les humains font tous des erreurs, alors on peut se monter une toolchain qui fait de l'analyse statique à la CI. Pour faire le pipeline de test sur gitlab/github, on monte un conteneur docker avec le tooling. Vous poussez ça sur un registry docker, et vous créez un CI avec un simple fichier.

rump 9 Surimisp - Eric Leblond

Faire le lien entre Suricata et MISP. Suricata c'est plus qu'un NIDS, il peux par exemple générer des évènements en fonction de ce qu'il observe. Il n'est pas fait pour gérer des longues listes d'IOC. Une bonne source d'IOC c'est MISP. On récupère les IOC de misp via https, et on crée une alerte format JSON avec les méta-données de suricata. Le code est sur github.

rump 10 - scaffold

Une carte open-source open-hardware pour faire de l'évaluation de sécurité de circuits intégrés qui permet de faire de la mesure de consommation, du controle d'alim, des signaux de triggers, etc... avec une API Python pratique à utiliser avec une grosse doc.

rump 11 - Painless registry forensics with Regrippy - simon garrelou

Un outil de collecte des hives qui contiennent les clefs de registres. L'idée c'est d'aller récupérer ces infos avec regripper, mais c'est du PERL, et le dev est tout seul sur le projet. Du coup rewrite en python du projet basé sur python-registry. Le code est sur github et a été testé en réponse sur incident.

rump 12 - Mi casa es tu casa

Le risque du AirBNB et du couch-surfing. On vous file souvent un accès wifi et un pc en libre service, avec tous les mots de passes enregistrés ou la box de l'opérateur. Les accès des box opérateurs sont souvent les 3-6 derniers chiffres de la box. Si vous trouvez pas le password vous pouvez le resetter, mais ça efface la conf de la box parfois. Une fois la box récupérée, vous pouvez changer les DNS, ou faciliter l'accès via DynDNS, puis en ouvrant des ports, ou les interfaces d'admin à distance, voir configurer carrément du transfert d'appel !

rump 13 - La rhétorique et le serpent - Driikolu

Comment argumenter face à un utilisateur de python2 ? bah les mecs de python 2 aiment bien les print sans parenthèses et pi les strings c'est mieux. En python 3 on peut utiliser des emoji !!! Bon vous avez une grosse baseline Python2 ? bah 98,9% des libs python2 sont compatibles python3.... Ya pas de support python2 sur votre OS... si vous êtes sur du legacy, utilisez PERL !

rump 14 - The hidden recorder into mstsc

RDP c'est plein de channels, dont des channels graphiques et es channels de compression. Il y avais déjà des artefacts mstsc extractibles avec un outil de l'ANSSI. Mais dans le binaire, ya moyen d'activer un recorder en activant 2 clefs de registres. Ca génère du Calista, dont le décodage est implémenté dans FreeRDP du coup on peux décoder le flux enregistré.

rump 15 - Dexcalibur

Automatisation de reverse android avec Frida.re. La desobfuscation c'est une perte de temps quand on audite ou on reverse une app android. Du coup l'orateur à voulu automatiser tout ça. Faux poser des hooks d'un peu partout, c'est le bordel, on fait tout ça à la main c'est chiant... Du coup l'orateur à fait une interface permettant de gérer la toolchaine en NodeJS. L'outil est disponible sur github (et il déchire !!!!)

rump 16 - Trop de théorie tue la pratique

Les étudiants  manquent de pratique... parfois arrivés en bac+5 en master spécialisé sans savoir faire quelquechose sur un pc sans interface graphique. Du coup proposition pédago: faites leur monter un réseau de pme avec tout les services puis défoncez le a coup de lazagne, metasploit mimikatz, etc... pour leur apprendre la vie.

rump 17 - 

Dieharder est une succession de tests de PRNG successeur de Diehard par Marsaglia. PASS: le prng doit etre bon, FAIL c'est qu'il est à chié, WEAK c'est qu'il ne sait pas se prononcer mais ça pue... le problème avec /dev/urandom c'est que ça sort régulièrement des WEAK. Après questions sur des mailing list, personne ne répond.

rump 18 - L'émeute - Nicolas Ruff

Tchap est un système de messagerie interministerielle basé sur Riot qui implémente le protocole matrix. Hommage à Jérome Chappe. 1h après sa mise à disposition, une vulnérabilité à été découverte.

rump 19  - REsponsible disclosure GSMA

La GSMA c'est un ensemble de partenaires industriels qui bossent sur les réseaux mobiles. Ils ont lancé un programme de responsible disclosure pour les bug non-spécifiques à un opérateur ou a un matériel mais liés au protocole ou aux standards. Le process est trèèèès détaillé. Donc si vous avez des vulns à remonter n'hésitez pas.

rump 20 - IDATag - Tag ta base

Un outil de Reverse, plugin IDA publié par thalium sur github. Comment offrir une vue unifiée sur ida pour partager de l'information avec ses camarades reverseurs qui vont ouvrir votre IDB ? Eh bien faux utiliser IDATag. On peux ainsi tagguer les fonctions sur la vue fonction.

rump 21 - Les tests d'intrusion c'est vraiment trop difficile

Dans le millieu bancaire, ya de la ségrégation réseau, des composants durcis, des mots de passes random etc... heureusement qu'il ya des partages avec des n° de CB, ou des exports keepass, ou un fichier keepass avec un fichier .txt qui contiens les mots de passes. Bon quand on fait du web, ya du waf, ya des trusted type,  les entrés sont sécurisés. Heureusement lors des réunions d'initialisation, on nous dit qu'il y a des comptes user et admin, et en prime un super-admin dont le compte est filtré ... ou pas. l'intel CSME contiens un outil ftpw64.

rump 22 - Visualisation pour l'investigation en cybersécurité - Malizen

typiquement un prog de merde tourne un dimanche matin, et vous etes appellé en réponse sur incident. On utilise snort et syslog pour avoir des infos avec un pic d'innactivité à 15h. Du coup a l'aide de divers outils de viz on fait l'investigation.

rump 23

Bon quand on fait de la sécurité, on doit se tenir au courant des vulns qui sortent, des news etc... et ça fait beaucoup d'information à digérer pour un défenseur...

rump 24 - CLIP OS 4

Non, ClipOS4 n'est pas mort, l'orateur à forké clipos4, puis est parti du sdk de gentoo hardened pour créer un clip sdk bootstrap ... modulo quelques bidouilles on à un SDK qui marche, qui sera releasé avec une image QCow et un CLIP4 qui boot

rump 25 - MAC Jammer

Rump non-streamé, pas de liveblogging donc :D











↧
↧

SSTIC 2019 - J3

June 7, 2019, 12:18 am
$
0
0
Après une (très) courte nuit, nous voici reparti pour cette dernière journée de SSTIC.

Russian style (lack of) Randomness

L'aléatoire à la russe, et les standards crypto russes. Lorsqu'on crée un nouvel algo crypto, on fait un papier avec les specs de design de l'algo, et ensuite on le publie et la communauté essaye de le péter. Si le papier survit à la communauté assez longtemps, on le standardise, on l'implémente et hop. L'analyse ne s'arrête jamais, et si une attaque est trouvée sur un truc standardisé, bah faut plus s'en servir. Certains gouvernements n'aiment pas ça à cause des critiques etc... L'autre technique c'est de pondre le truc à l'arach sans demander aux autres et de dire "utilisez le".

L'algo crypto est construit avec des boiboites L pour la diffusion (??) et des boites S pour la confusion (???). C'est aussi utilisé par AES, et c'est assez standard. Bon la question sur la boite S c'est comment elle est construite ? Bah dans la spec c'est un pov' tableau, et les designers ont dit que cette boite était tirée aléatoirement, et du coup sans structure mathématique forte (LOL?). Ce type de construction est complètement absurde, c'était à la mode dans les années 90.

Streebog et Kuznyechik ont été poussé à l'IETF sous forme de RFC, et la standardisation ISO vient de se terminer sur Streebog, et Kuznyechik c'est en cours. En mai 2016, il y a eu une décomposition du tableau de la S box, et il a fini par être complètement décomposé cette année.  Les designers insistent en disant que la Sbox était tirée en random, si si ...  (détail du fonctionnement de la Sbox T.T  )

Du coup la fonction tirée au sort en random se comporte en fait comme un logarithme, du coup c'est pas random en fait. Bon la boite S ressemble franchement à une backdoor crypto, mais on en a pas la preuve, ni d'attaque adaptée. Du coup  il ne faut pas utiliser ces deux algos, et il faudrait les virer des standards. C'est pas parceque c'est standardisé que c'est bien fait !

Le quantique c'est fantastique

(des quantiques au couvent des jacobins !) 

Le calcul quantique, c'est une entrée qui s'fait secouer dans des états intermédiaires et on a une valeur finale en sortie. Certains problèmes sont plus faciles à résoudre en quantique grace à cette souplesse des états intermédiaires. Bon ça marche pas toujours super, mais pourquoi ça nous intéresse ? On estime que dans un certain temps on devrait avoir un ordi quantique fiable. On se dit que le temps qu'on trouve des algos quantiquement fiables et qu'on les standardise il ne faudrait pas que l'ordi quantique soit stable avant.

Quand on fait un calcul quantique, tous les états sont supperposés, mais lorsqu'on fait la mesure, on trash ces états pour obtenir un résultat probablement au pif (effet de sonde, le chat, etc...). Le NIST a fait un appel à candidature pour des algos qui encaissent la cryptanalyse quantique.  Sur  69 candidats, 22 se sont fait défoncer avec des ordi "classiques" (c'est con...). Comme quoi la crypto c'est très très très dur. 26 ont été sélectionnés pour le second tour d'analyse qui est toujours en cours. Fin de la standardisation estimée pour 2023.

La cryptographie quantique, c'est un échange de clef quantique. On s'échange des états quantiques, et l'échange quantique n'offre pas d'authentification donc on à toujours besoin de crypto assymétrique classique. (là je BSOD)

Ethereum: chasse aux contrats vulnérables

Une blockchain, c'est une espèce de liste chainée cryptographique. Si on a le hash du dernier block on peut reconstruire l'ensemble de la chaine. Chaque nouveau block est un instantané qui fait avancer. Les mineurs fournissent les preuvent de travail, et les transactions incluent des frais qui sont donnés aux mineurs qui font avancer le réseau et ses preuves.  Les comptes sont sous forme d'une paire de clefs crypto, la clef privée permettant de faire des transactions, et la publique de recevoir de l'argent. 

Les contrats intelligents datent d'avant les années 2000. En Ethereum, il y a des addresses de comptes et des addresses de contrats intelligents associés à du code immutable. Ce code tourne sur la VM d'Ethereum, c'est une machine à pile très très simple avec une archi 256bits ce qui est pratique pour la crypto.  L'exécution de code coute du gas (frais de transactions).  

Les contrats sont codés en solidity, une espèce de JavaScript que l'on compile en bytecode EVM pour être ensuite exécuté sur Ethereum. Les baleines sont les gros contrats Ethereum. La DAO, c'était un fond d'investissement contrôlé par un programme qui à levé plus de 100 millions de dollars. La DAO avait une vuln dans la fonction de retrait à cause d'un problème de récursivité ré-entrante.  Cette faille à créé un Hard fork et à créé ethereum classique.

Pakala est un outil développé par l'orateur d'exécution symbolique dispo sur Github qui simule les exécutions possibles d'un contrat intelligent. Pour faire son analyse, l'orateur à créé un noeud ethereum archive de 2TO sur SSD qui à pris 2 mois a se créer.  L'orateur à trouvé des honeypots avec un contrat à quelques milliers d'euros avec un bug trivial, mais pour le déclancher il faut envoyer de l'argent sur une addresse, et le bug est très subtil et du coup on récupère pas l'argent. Il y a des contrats très buggués avec pas beaucoup d'argent. Il y a des casino avec des sources d'entropie prévisibles donc prédictibles. L'orateur à trouvé des pyramides de ponzi.

Analyse de sécurité d'un portefeuille pour cryptomonaies

Le problème des wallet hardware, c'est qu'il faut le backuper sous forme papier ou "cryptosteel". Du coup HTC à sorti un smartphone dédié à la blockchain (marketing) qui fait hardware wallet en plus d'être un smartphone classique.  Les seed sont stockés dans un OS sécurisé dans une trust-zone et du coup l'OS normal n'a jamais accès à ce qui se passe. Le social key recovery permet de partager la clef avec des contacts de confiance, et chaqu'un d'entre eux vont recevoir une partie de la seed. Les tiers doivent installer une application Zion, et une partie de la seed leur est envoyée chiffrée et stockée dans le keystore android. L'algo repose sur le secret partagé à seuil de Shamir. Il faut donc un nombre minimum de portions du secret pour reconstruire la seed.

Comme il y a un soucis dans le PRNG, l'orateur a pu poser un système linéaire pour casser les bits de la clefs, et du coup avec deux contacts de confiance on peut reconstituer la seed de l'utilisateur. Si un contact est malveillant, il n'a plus qu'a convaincre ou compromettre un second contact pour voler l'utilisateur. 

A tale of Chakra bugs

L'orateur à pas mal bossé sur la sécurité du moteur Javascript et plus particulièrement Chakra, le moteur JS de Microsoft. Chakra est écrit en C++ dont 95% est opensource sous le nom ChakraCore. Tous les moteurs JS utilisent des tricks. Pour encoder les types, Chakra utilise du NaN boxing. Les JSObjects sont des dictionnaires comme en python, et chaque objet ne maintient pas sa propre map, et ils ont un type qui décrit le type de chaque objet. Les tableaux sont des objects comme les autres, mais les moteurs implémentent des optimisations pour les tableaux d'entiers, de floats et les autres. 

Les bug avec un side-effect observable. En JS on peut utiliser pas mal de callback, et certaines d'entre elles sont observables. On peut donc gérer des getter/setter sur chaque propriété pour aller les observer.. Les moteurs JS sont plein de bugs lié à des problèmes de timing dans les accès à ces propriétés. De la même façon, le moteur JIT qui compile le JavaScript en assembleur peut lui aussi souffrir de bugs sur les types des variables. Ces erreurs sur les types génèrent des confusions de type. Une confusion de Type est souvent exploitable et peut engendrer une RCE.  Les tableaux étant stockés de 3 façons différentes, il est intéressant de confondre un tableau avec un autre. Lorsque la confusion survient, certaines valeurs du tableau sont interprétés comme des pointeurs, engendant un crash.  On va utiliser ce bug pour récupérer un pointeur de VTable valide afin de pouvoir en suite mettre la bonne addresse sur le pointeur. En jouant avec ça on obtient un Read/Write arbitraire.

Il existe aussi des bugs dont les effets de bords ne sont pas observable depuis JavaScript. Lorsque le JIT fait des optimisations, parfois il peux se foirer, et écrire la ou il y a des pointeurs, et c'est le drame. 

Les bugs JS sont de moins en moins compacts, et il faut jouer avec des mécanismes de plus en plus obscurs du JIT, ce qui nécessite une bonne connaissance interne du moteur. Par exemple, certains objets peuvent être optimisés par un cache pour accélérer la résolution des types. La boucle for .. in permet de boucler sur les propriétés d'un objet, et ça déclenche des bugs subtils.

V2G Injector: whispering to cars and charging units.

Les bornes de recharge servent t'elle seulement à charger ?  Les énergies renouvelables sont difficile à gérer car la production n'est pas linéaire et il faut stocker l'énergie. Du coup les batteries des voitures pourraient former une grille de batteries pour lisser la charge par rapport à cette production. Du coup les systèmes de chargement sont bi-directionnels et vous pouvez être payé pour donner votre énergie stockée en compensation de l'usure de la batterie.

Le V2G est un standard de communication pour les véhicules électriques. Le protocole est très velu et utilise le CPL pour causer entre la voiture et la station de charge. Depuis cette couche physique, l'orateur à du dépiler toutes les couches jusqu'a arriver à la partie donnée V2G qui contient les infos de payement etc... Il est possible de chiffrer les communications, mais l'archi est très hétérogène, et du coup bah c'est l'bordel.

L'homeplug Green Phy c'est presque comme le homeplug AV utilisé dans les boitiers CPL domestiques. Dans le CPL, tout est broadcasté, et le véhicule ne sait pas à qui il est connecté. Du coup  il y a une procédure SLAC qui permet de déterminer qui est le plus près pour identifier la station de charge qui elle va répondre en Unicast.

Il y a très peu d'outils pour analyser le V2G. L'orateur à donc créé un outil qui gère l'ensemble des trucs dont il a besoin. Si on met une prise CPL en mode PEV on peut s'en servir pour communiquer avec sa station de charge. Pour 60€ on peut donc bidouiller une interface à partir d'une prise domestique. La com réseau en V2G se fait en IPv6 (si si, c'est pas des blagues, plus d'infos dans les slides). Les paquets V2G sont fait en XML avec divers protocoles plus ou moins bien documentés, pas forcément à jour etc... Le tool est sur github.

Analyse de firmwares de points d'accès

Les AP Ruckus et Aerohive disposent de backdoors root qui nécessitent une clef et l'ID du point d'accès. L'orateur détaille comment fonctionne la backdoor v54 et le calcul de clef (plus de détails dans les actes).

Under the DOM: Instrumentation de navigateurs pour l'analyse JavaScript

L'auto-blogging live de ma conf, c'est fun !!!

L'obfuscation consiste à rendre difficile à comprendre un code source, volontairement ou non. C'est très très utilisé pour éviter la détection des anti-virus notamment sur les exploit-kits. En prime le navigateur ne facilite pas la vie de l'analyste car son comportement est de plus en plus complexe et parfois pas prédictible. En prime avec les technos type Electron, les navigateurs deviennent la GUI universelle. Désobfusquer du JavaScript c'est pas très compliqué, mais c'est fastidieux et le temps de l'analyste est précieux. Mineurs de cryptomonaies, XSS, exploit-kits, fingerprinting & tracking des utilisateurs, c'est pas les menaces qui manquent. Du coup l'orateur (moi) s'est demandé comment récupérer à coup sûr l'ensemble des scripts JS qui s'exécutent dans le navigateur sans le modifier, en déjouant les éventuelles anti-analyses et en désobfusquant le JS.

Un navigateur c'est très compliqué, ça embarque des compilateurs & interpréteurs JavaScript, des libs crypto, des libs graphiques, ça fait beaucoup de code. Le moteur HTML fait régulièrement appel au moteur JavaScript pour exécuter le code qu'il trouve dans les pages. Mais parfois c'est le JavaScript qui écrit des trucs dans le HTML qui du coup doit re-analyser la page. Le moteur JavaScript et HTML s'influencent donc joyeusement l'un-l'autre durant la vie d'une page web. L'orateur va donc chercher à se placer entre le moteur HTML et le moteur JavaScript pour récupérer tout les codes JS que le moteur HTML à trouvé, ainsi que les codes JS généré par du JS.

Pour ce faire, il s'est aidé de Frida pour venir poser un hook sur l'initialisation du compilateur de bytecode du moteur JavaScript. En suivant quelques pointeurs on peut ainsi retrouver le code source à compiler et tout récupérer.

L'avantage c'est qu'on ne rate rien de ce qui s'exécute dans le moteur JS, et on à même accès au code JS privilégié qui est exécuté dans les extensions Firefox. L'approche est généralisable à tous les autres navigateurs, et est détaillée dans les actes. (Merci à François qui à géré le liveblogging et corrigé les fautes ;) )

Source-Fu: désobfuscation de code source

Au quotidien, quand on traite avec des malwares, on à souvent affaire à des scripts offusqués (jscript, wsh, bat, powershell, etc...), Les outils capables de faire de la désobfuscation de source par évaluation partielles sont au nombre de deux, et sont pas à jour. Du coup l'orateur à choisi d'écrire une grammaire par langage à désobfusquer et optimise en suite le code par des passes successives qui permettent de supprimer le code mort, de faire sauter les prédicats opaques etc.  
Une fois le ménage fait, on peut faire une passe de ré-écriture pour renommer les variables en fonction de leur contexte etc... L'outil est sympa et publié sur github.

Hyper-V - Techniques d'attaques et de défense contre la corruption de mémoire

La sécurité ne prend pas assez de place dans la formation des ingénieurs logiciels, ça devrais être un principe de base de l'ingéniérie logicielle. On peu former les gens au développement, et bien les former ça n'empèche pas que lorsqu'uon développe, on insère des bugs, et le niveau de complexité joue. Il y aura toujours des bugs, et il faut faire avec. ça ne veut pas dire qu'il faut abandonner la formation et le code review, c'est juste qu'il faut rester pragmatique, et on doit donc réduire leur risque d'apparition. 

L'orateur nous détaille en suite le fonctionnement d'Hyper-V et des hyper-calls. Hyper-V utilise des espaces mémoires partagés pour échanger des info entre l'hyperviseur et le guest sans effectuer des recopies mémoires innutiles. Le problème c'est que lorsque les recopies dans les buffers ne sont pas atomiques, on peu avoir des race condition entre les threads ce qui engendre des vulnérabilités. (l'hyper-v c'est hyper-complexe, je vous invite à regarder la vidéo dès sa publication).





↧

C&ESAR 2019

November 19, 2019, 12:33 am
$
0
0

J1

Introduction


26ème édition de C&ESAR, sur l'échange entre académique, éducation, gouvernement & industrie pour rendre le monde numérique plus sûr. Aucun système d'importance ne se conçoit sans numérisation, et donc sans prendre en compte la menace cyber qui pèse sur lui. Le thème de l'intelligence artificielle est un chantier dans lequel il va falloir trouver les moyens de sécuriser nos traitements et nos données. La conférence sur l'IA qui suit C&ESAR s'inscrit dans le même état d'esprit que C&ESAR, avec une session commune sur les problématiques cybersécurité & IA.
La recherche est aussi à l'honneur lors de l'ECW avec un workshop académique.

Virtualisation dans un cloud de télécomunication

Pour préparer la 5G,  afin de pouvoir offrir des serivces différentiés en fonction des abonnés, les opérateurs comme orange ont besoin d'un Cloud TELCO. On peut imaginer l'impact que peut avoir un incident sur un réseau mobile à l'heure ou les téléphones sont omniprésents et les usagers de plus en plus dépendants de ces derniers. La disponibilité est donc un gros enjeux. La confidentialité est elle aussi très forte pour des raisons réglementaires. 

Un Telco-Cloud est une infrastructure de virtualisation distribué sur le pays. Les équipements matériels ont été progressivement remplacé par des machines virtuelles faisant tourner le logiciel de l'équipementier. Le problème, c'est que ces fonctions virtualisés tournent sur du x86 vulnérable aux attaques matérielles type spectre/meltdown. L'OS c'est du linux, et il faut venir le durcir. Pour exécuter les vm, ils utilisent du OpenStack, et c'est pas les échanges qui manquent entre les composants OpenSTACK. KVM/Qemu souffre de pas mal de bugs de stabilité.

La transition d'un monde physique à un monde virtualisé multi-fournisseurs ne se fait pas sans heurts. Par exemple, pour un pare-feu virtuel chargé de filtrer des paquets issue d'un déni de service, les paquets ont déjà traversé la couche SDN avant d'arriver au pare-feu chargé de filtrer, il y a donc un risque de déni de service de l'infra virtualisée.

Pour se prémunir face à ces risques, les attaques types DDoS sont gérés par un ASIC. Qui dit sécurité, dit TLS et PKI, avec la gestion des secrets au sein d'un HSM qui ne doit pas devenir un SPOF. Le development sur les infrastructure cloud se fait en mode devops avec un gros impact sur la gestion des patchs en CI/CD. La supervision de sécurité, c'est la cerise sur le gateau, avec gestion au sein d'un siem de l'ensemble des logs produits par l'infrastructure.

Cloud & SOC

La réponse à incident est très complexe dans un Cloud, et la connnaissance des acteurs & intervenants est très mal maitrisé. La stratégie de détection sur une infrastructure non-maitrisée avec une cartographie réseau inconnue est une gajeure. De plus sur des portions externalisés qui sont parfois co-localisés avec des tiers dont les composants hébergés sont souvent vulnérables. 

Les provider cloud offrent des solutions de virtualisation des réseaux, de centralisation et de gestion de logs, etc... il faut donc s'appuyer sur ces derniers pour construire sa stratégie de détection. (#protip: pour le forensic, vu qu'ils font payer au débit réseau, vous pouvez utiliser une vm pour l'analyse directement chez le cloud provider ;) ).

Legislation applicable aux opérateurs de réseau 5G.

La transition de la 4G à la 5G se fera avec un carrier 5G sur un coeur de réseau 4G. Horizon 2022, l'ensemble du coeur de réseau va basculer vers un coeur 5G, avec une segmentation forte des portions de la partie utilisateur. La virtualisation est un gros enjeu des coeurs de réseau 5G, notamment le fait de pouvoir dédier des tranches de ce réseau à des fonctions critiques. Les différentes réglementations sur les télécomunications ne sont pas forcément adapté au contexte 5G, qui lui est capable de gérer les priorités et de venir réserver une majorité de la bande passante pour les appels d'urgence lors d'une catastrophe. Il faut donc adapter la legislation aux spécificités de la 5G, ce qui laisse envisager l'élaboration d'une législation spécifique. 


VMWare & Cybersécurité

Puisque tout est virtualisable et virtualisé, du réseau au cpu en passant par le stockage, du coup les infrastructures définie logiciellemnet (Software Defined Infrastructures).  Par exemple, l'utilisation du SDI pour adapter l'infrastructure aux spécificités de l'attaque.  Autre projet de r&d: S2OS qui consiste à créer un OS sécurisé basé sur les technologies de SDI. Les conteneurs partageant le kernel, ne proposent pas forcément une couche de sécurité supplémentaire comme peut l'offrir la virtualisation traditionelle. l'idée de VMWare c'est de rapprocher le SDI du concept Kubernetes. 

Scada, sécurité & virtualisation


les automates industriels contrôlant un processus industriel ont de fortes contraintes de disponibilité et de réactivité. Lorsqu'on veux construire une plateforme de test, il est difficile de reproduire un système de contrôle matériel, les piles protocolaires ne sont pas libres, et les OS non plus. Donc ça fait beaucoup de barrières pour les chercheurs. Du coup les orateurs ont décidé de construire un bac à sable libre & ouvert, utilisant du matériel SCADA documenté avec une taille proche d'un SI industriel, soit 100 devices connectés et environ 1k capteurs.  La simulation se fait donc avec du matériel dédié (hardware in the loop). Du coup ça permet de construire des infrastructures de simulation pour la formation ou l'expérimentation. Le seul cas d'usage public accessible dans la litérature de traitement industriel à été réimplémenté sur la base de ces cartes avec une simulation python. Il fût en suite possible de jouer des attaques directement sur cet environement simulé.  Pour les capteurs de courant electrique, des cartes filles ont été développés pour adapter les niveaux de voltages.

Les simulateurs existant coûtent un bras, du coup les orateurs ont re-développé un simulateur python, et le source est disponible ICI.

Sécurité & Véhicules connectés


Le SDVN est un réseau véhiculaire virtualisé. En gros chaque véhicule est un switch, et le plan DATA est coupé en deux, avec une partie mobile, les vehicules, et une partie fixe que sont les bornes sur le bord des routes. On peut ainsi segmenter les données des véhicules d'urgence des véhicules traditionnels. Dans la 5G, il va falloir trouver des compromis entre SDVN, performance & couverture radio. Cependant cela se fait avec un accroissement de la complexité de l'infrastructure, lié à la complexité intrinseque de l'infra 5G.  Côté sécurité, le contrôleur SDN est une cible potentielle à surveillé de près. Car sans ce dernier, plus rien ne fonctionne. Comme les véhicules se déplacent, le plan DATA mobile peut s'avérer compliqué à gérer. La défense en profondeur est ici préconnnisé, avec une attention toute particulière sur la sécurité du plan DATA.

Validation par introspection de code & virtualisation.

Les piles logicielles qui sont exécutés sont très très riches & complèxes, et l'approche de sécurité est très orienté système. Gestion des droits, confinement, quotas... Mais l'analyse de code est toujours une valeur sûre car elle minimise par construction la surface d'attaque. Les outils d'analyse de code automatique offrent un autre moyen de réduire les risque en pointant du doit les erreurs. La virtualisation sur Unisim-vpà été enrichie par un mécanisme de typage polymorphique. Les types peuvent être concrêts ou symboliques.

IceBox - Analyse de malware par introspection de machine virtuelle

une solution d'introspection de machine virtuelle (vmi) adapté à l'analyse de malwares. Le problème de l'analyse dynamique, c'est que le malware tourne souvent au même niveau que les outils d'analyse. Le malware peut donc déployer un certain nombre de techniques pour détecter et corrompre ce relevé d'information. Quand on remonte au niveau Kernel, le malware lui peut par l'injection d'un driver le contourner.  Le malware peut aussi faire de l'anti-debug, etc... tout ça pour compliquer la tâche de l'analyste. Lorsqu'on met en pause une VM, et qu'on regarde l'êtat de son CPU, on ne sait pas si on est en espace user ou noyau, dans quel process on est, quel thread, etc... L'idée d'ICEBox, c'est de fournir un framework qui prend en charge cette problématique. Ce n'est pas le seul projet à faire de l'introspection de VM, mais il a le mérite d'être performant et de supporter Windows comme guest OS. Les breakpoints de l'hyperviseur permettent de rester furtif vis à vis du malware. IceBox gère aussi une callstack du noyau vers l'applicatif. L'outil est disponible ICI.

Analyse morphologique & LockerGoga

Le principe de l'analyse morphologique, c'est d'observer la structure et l'agencement des instructions et des fonctions dans un binaire, et de les comparer avec un autre. S'ils ont la même apparence, ils ont probablement la même finalité.  Cette analyse morphologique se fait par analyse de similarité entre les graphs à l'aide de l'outil Gorille. 


J2

les présentations suivantes sont issue du workshop SILM

Trusted-Execution Environments

Les trusted-zones sur les CPU servent à isoler du code du reste du système, typiquement employé pour des fonctions de sécurité ou des DRM. La question que l'orateur de TU Graz se pose, c'est est-ce que l'application qui s'exécute dans l'enclave CPU est-elle vraiment protégée ? Que se passe t'il si un attaquant exécute son code malicieux dans une enclave SGX ou une trust-zone Arm ? Les enclaves sont des boites noires, et on ne sait pas ce qu'il s'y passe. Le concept à été présenté par Joanna Rutko
wska en 2013. Exécuter dans une trust-zone est contraignant, on ne peut pas faire de syscalls, etc... Il existe des side-channels qui permettent de récupérer des méta-données de l'exécution du code dans sa trust-zone, mais c'est pas très puissant, et on peut durcir le code au niveau des sources pour rendre les side-channels innexploitables. Le chiffrement de zone mémoire est une fonctionnalité des trust-zones. Si un bit flip dans une zone chiffré, cela provoque un verrouillage du contrôleur mémoire, et un freeze complet du système. (plus d'infos sur la page de l'orateur). Quand on veux faire des choses depuis l'enclave vers la mémoire système, il faut trouver un moyen de toucher les zones mémoires sans risques de crasher le système. Pour se faire, l'orateur s'appuie sur intel TSX pour pouvoir faire du roll-back en cas d'erreur mémoire, et éviter le BSOD. Le mécanisme mis en place, il faut 45min pour accéder à  toute la mémoire, et quelques secondes pour aller chercher des infos proches de la zone d'appel. Pour l'exécution, l'orateur fait du ROP depuis l'enclave SGX. En s'appuyant sur ses connaissances, l'orateur à créé un jail pour les applications SGX.  La communication entre la sandbox et le processus hôte se fait par une zone mémmoire partagée, et l'enclave est verrouillée via seccomp. L'overhead n'est pas énorme. En utilisant les fonctions MPK de protection mémoire des cpu Intel, l'orateur à pu mettre en place une enclave hardware.

Splitting the Linux Kernel for fun & profit

Docker est une alternative très populaire à Docker car c'est plus léger qu'une VM, mais la contrepartie, c'est que le conteneur à accès au Kernel de l'hôte, et donc n'importe quel exploit kernel se transforme en carte "sortie de conteneur".  Et ce ne sont pas les techniques qui manquent pour accéder à la mémoire du Kernel. L'orateur souhaite donc réduire les conséquences de l'exploitation d'une vulnérabilité Kernel en se basant sur les techniques de virtualisation matériel présent dans les cpu modernes. Dans les mécanismes hardwares du cpu pour la virtualisation, on à les instructions VT-X qui offrent un moyen de sécuriser une zone mémoire. On peut aussi mettre en place des vérifications d'intégrité de zones mémoire comme le code du noyau, ou certaines zones mémoires contenant des informations utile aux élévations de privilèges. Par contre l'orateur veux éviter de mettre en oeuvre un hyperviseur, et que ça reste un code pouvant être intégré dans les sources du noyau linux. Pour découper le kernel, l'orateur place une partie réduite du kernel dans la zone privilégiée du ring -1 traditionellement réservé à l'hyperviseur. (les sources sont sur github)

IOMMU & DMA Attacks

L'iommu permet d'assurer la ségrégation entre les périphériques ayant un accès direct à la mémoire physique (DMA). Le dma c'est un vieux système qui permetait au disque dur par exemple d'écrire directement les information demandées dans la zone mémoire adéquate pour des questions de performance et d'économie de cycles CPU. L'iommu permet de regrouper les périphériques dans des domaines et de leur donner accès a des zones mémoires particulières, protégeant ainsi le kernel et les zones mémoires sensibles des accès indues de la part des périphériques DMA (firewire,pcie, etc...).
L'orateur nous fait un état de l'art complet des attaques DMA.

Pitfalls & limits of dynamic malware analysis

L'analyse dynamique de malware peut faire gagner du temps, mais parfois n'est pas suffisante pour qualifier les intentions d'un code malveillant. L'unpacking statique est une tâche fastidieuse, et ça va souvent plus vite en dynamique. Pour observer l'exécution d'un code, c'est le debuggueur qui nous viens en tête, mais ces logiciels n'ont pas été conçus pour l'analyse de logiciels malveillants, et ne sont ni furtifs, ni sûrs. L'émulation est une autre approche, mais là encore ces émulateurs ne sont pas faîts pour encaisser les attaques, et en plus c'est très compliquer d'implémenter correctement des instructions cpu complexes. On peut aussi utiliser des modules kernel pour analyser les malwares, mais il faut qu'ils soient signés, ou désactiver la vérification de signatures, et en prime patchguard pose problème. Window 10 est accompagné d'une sandbox hyperV mais il ne fournis pas d'API pour l'analyse et l'introspection. C'est facile de détecter de la virtualisation, mais impossible de détecter l'introspection. (l'orateur rejoins le point de vue des auteurs de IceBox).

La virtualisation, c'est compliqué à mettre en oeuvre, et on peut vite se retrouver avec des race-conditions entre les différents cpu virtuels si l'analyse se fait sur une vm multi-cpu. Exemple avec PID d'un process qui est une construction de l'OS qui utilise des structures de donnés mouvantes. Les tables de pages sont un indicateur un peu plus stable, mais le matériel peut changer les tables de pages sans invalider le cache du tlb, et du coup c'est le bordel pour reconstruire la mémoire du process.  L'orateur détaille en suite de nombreux side-effects de l'introspection Xen sur les breakpoints, certaines instructions cpu,  la gestion des shadow pages, etc... Le hardware limite la furtivité de l'introspection, et il y a toujours moyen d'observer les effets de bord par mesures de temps. Une détection négative sur une sandbox indique juste que l'auteur du malware est peut-être plus malin que l'auteur de la sandbox. La diversité nous sauve, car il est très peu probable que les malwares importerons toutes les contre-mesures envisageables au risque de devenir énormes.

Combinaison de sources de SCA.

L'analyse par canaux auxiliaires consiste à mesurer les incidences d'un calcul au niveau d'un processeurs sur la consomation électrique, le rayonement électromagnetique, etc... Le problème c'est de réussir à correler ces signaux avec ce qui se passe dans le processeur. Lorsqu'on connait l'algorithme, on cherche à obtenir la clef privée qui sert au chiffrement. Les orateurs ont donc utilisé un réseau de neurones avec des données de références pour l'entrainer à selectionner et déduire les valeurs des bits d'une clef de chiffrement à partir des données mesurés par des sondes electro-magnétiques posées à différents endroits d'un microcontroleur.  Les expérimentations se sont faite en s'aider du jeu de données ASCAD. Après expérimentation, un seul canal auxiliaire suffit au réseau de neurone pour déduire la clef efficacement.


Cybersécurité & IA en environement contraint.

Intégration de Machine Learning dans un SOC. Après la réussite du ML supervisé sur de la détection de fraude, ils ont essayé de faire pareil sur de la détection d'attaques informatique. La donnée c'est l'enjeu n°1 d'un projet Data Science. La récupération de cette donnée nécessite donc beaucoup de travail avant de pouvoir bosser en machine learning.  La protection et l'anonymisation des jeux de données pour pouvoir les employer sans risques.

Une fois les donnés obtenues, les deux DataScientist se sont penchés sur les classiques kmeans, dbscan, randomforest sur les dataset CIC IDS 2017 et CIC IDS 2018, et IsolationForest sur leur DataSet Interne, et ils ont fini par valider IsolationForest pour une mise en production. IsolationForest à l'avantage de faciliter l'interprétation des données car pour chaque branche de l'arbre ont sait quel sont les features sur lesquelles le test était fait. La réduction des features permet aussi de faciliter l'interprétation des résultats par les experts.

ToxicIA - apprentissage profond appliqué aux Signaux parasites compromettants.

Lorsqu'on viens récupérer les signaux radio émis par la circulation du courant dans les cables d'alimentation ou les cables vidéo, il est possible de reconstruire l'affichage des écrans. Ces signaux parasites divulguent sur le champ radio des informations potentiellement sensibles. Cependant la récupération de ce signal n'est pas systématique, et il est souvent très bruité. C'est là que l'IA entre en jeux. En affichant des caractères sur un écran, et en passant le signal intercepté dans un réseau de neurones on peut lui apprendre à reconstruire des images non-bruités à partir des images bruités. Après expérimentation de nombreux algorithmes de débruitage, puis passage à tesseract, il s'avère qu'ils obtiennent un fscore d'a peine 0,3. En utilisant directement un réseau de neurone combinant débruitage ET reconnaissance de caractère, le fscore monte à 0,68. Par contre les caractères de petite taille sont très sensibles au bruit et difficiles à reconstruire. (cf opendenoising)

Machine Learning pour les systèmes de détection

Créer des règles de détection, c'est coûteux, et ça nécessite de les faire faire par un expert. En plus lorsque les donnés d'entrée chagne, il faut revoir les règles. Si on dispose de suffisament de données, on peut envisager de faire du machine learning. Le problème c'est qu'un algo de ML prend en entrée des tableaux ou des valeurs catégorielles représantant les caractéristiques de ce que l'on cherche à identifier. Il faut donc transformer les données brutes en attributs. L'extraction des attributs est très coûteuse et nécessite là encore de l'expertise. Si on laisse à l'algorithme le soin d'extraire les attributs caractéristiques à apprendre, on perds en interprétabilité par un expert. L'orateur c'est donc intéressé à l'abaissement du coût d'extraction de ces attributs. Les parsers contiennent un très grand nombre de techniques d'extraction d'attributs qui sont transformables en un modèle relationnel inter-entités(un peu comme un schéma de base de données). AutoFeatures va donc parcourir ce modèle pour transformer les donnés récupérés en un scalaire qui pourra alimenter l'algo de ML. Il faut en suite offrir à l'expert un moyen pour injecter ses connaissances. Pour ce faire il peut ajouter des features intéressantes, les whitelister ou les blacklister afin d'éviter d'aggréger des PID par exemple.

IA pour la détection de fake-news

La désinformation peut servir à faire gagner des conflits. les fake news ont des articles de presse intentionellement faux et dont ont peux vérifier l'absence de crédibilité. Ces fakes news n'ont qu'un seul intérêt: générer du traffic pour gagner de l'argent via les publicités. Le coût de la vérification de l'information est bien plus important que la production d'une fausse information. (bullshit asymmetry)
Dans le monde militaire les PsyOps & InfoOps sont cadrés dans une doctrine qui définis ce qui est autorisé ou non lors d'une opération. Les actions de désinformation vons s'appuyer sur des communautés qui servirons de relais et de chambre d'écho. Pour automatiser l'analyse des fake-news, il faut donc à partir des articles entrainer un réseau de neurone avec pour oracle des services de fact-checking. Une base de connaissance peut aussi servir à ce fact-checking. Cette approche fonctionne bien pour des faits simples.

Détection de comportement annormaux au niveau utilisateur  & entité.

L'IA c'est compliqué, il faut des connaissances métier fortes, des experts en DataScience et de bons jeux de données. Sur les pare-feux on à vite des volumes de données très important. A partir des logs de ces pare-feux, les orateurs génèrent des graphs qu'ils affichent aux analystes afin de faciliter la détection visuelle de l'annomalie, puis entrainent l'algo de machine learning dessus. en projetant les échanges sur un espace à deux dimentions, on essaye de préserver quelques propriétés: temporellement les ip doivent se rapprocher si elles communiquent fréquement entre-elles, ou s'éloigner si elles cessent d'échanger.  Une fois le graph généré, node2vec fait la projection sur un espace multidimentionnel. La projection est en suite réduite pour être visualisable sur 2 dimentions.
Il faut paramétrer correctement.

Evaluation de systèmes de masses de données dans le cadre d'analyse de logs. 

L'analyse de gros volume de logs c'est une problématique constante dans la mise en oeuvre d'un SIEM. à l'université de Rennes1, les logs sont passés dans greylog puis indexés dans elasticsearch (un classique du siem).  En jouant sur la taille et la complexité des requêtes, on voit bien que les performances s'effondrent avec l'augmentation de la quantité des données indexés. Comment faire pour passer à une très grande échelle ?  Pour ce faire, l'orateur à regardé du côté de HDFS et de MapReduce pour requêter de très gros volumes de données. Le problème d'Hadoop, c'est qu'il faut coder pour que ça fonctionne. Les niveaux d'abstraction sont loin d'être suffisant pour rendre ce genre d'infra accessibles à des opérateurs de SOC. 






























↧

K3S/WordPress – A (long) way to DevSecOps –Épisode 4

June 6, 2020, 2:00 am
$
0
0

A long way to DevSecOps : Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5, Épisode 6.

Comme je l’avais annoncé précédemment j’ai effectué une première migration de Blogger à WordPress. Le jour où j’écris ces lignes le blog WordPress est auto-hébergé et fonctionne dans un conteneur, mais pas dans un cluster Kubernetes.

La sécurité de départ

WordPress

Déjà, vous allez me dire qu’utiliser WordPress c’est un peu aimer le risque. On estime que WordPress c’est en 2019 environ 35% des sites Web. Ce qui est déjà conséquent, même trop. On imagine assez facilement le niveau d’exposition, et le nombre de sites qui ne sont pas à jour. Cela me rappelle un certain ver Santy.A qui touchait les forums phpBB. De plus c’est sans compter sur tous les modules additionnels que l’on peut ajouter dans ce CMS. Chaque module utilisé peut potentiellement porter des vulnérabilités et doivent être mis à jour au fur et à mesure des releases, parfois de manière indépendante et parfois de manière liée comme pour les thèmes.

Les conteneurs

Utiliser des conteneurs alors que leur sécurité est très fortement décriée, c’est aller au suicide ? Je pense qu’effectivement, il faudra bien vérifier la sécurité du socle avant de partager des ressources entre différents utilisateurs (aller un ptit lien vers la présentation SSTIC sur la sécurité K8S). Pour ma part, je reste le seul administrateur de ma plate-forme. Les utilisateurs utiliseront les services et passeront tous par l’Ingress de K3S.

Comme je l’avais dit dans l’épisode 1, une des problématiques qui apparait en premier est de savoir quelles sont les images collectées et quel est le contenu de ces images. Avant de les déployer sur l’infra il faut savoir si ces images suivent les bonnes pratiques de sécurité. On commence ici à mettre un pied dans le process de DevSecOps, et ce n’est pas le sujet pour le moment. On reviendra dans le pipeline de développement par la suite, comme je l’ai déjà dit : la route est longue.

Je ne vais pas faire un article complet sur la sécurité des conteneurs. Pour résumer très vite, les droits d’exécution peuvent parfois être plus élevés que nécessaire. C’est ce cheminement vers la sécurité qui a donné naissance à Podman, à Docker en rootless mode (encore abordé à la DockerCon cette année), ou encore à une approche encore plus extrême avec les Kata Containers. Bon l’avantage c’est qu’à l’intérieur du conteneur (qui doit être minimal), l’exposition est réduite. Mais doit être mis à jour à chaque fois qu’une vulnérabilité touche cette base.

Durcissement mail

Dans l’épisode précédent nous avons déployé un service mail. J’ai depuis « durci », en ouvrant sur l’extérieur que les ports nécessaires (super !). Cette mise à jour s’est effectuée de manière transparente en redéfinissant le déploiement et les ports exposés au niveau du conteneur (par défaut si ce n’est pas déclaré, les ports sont fermés). De plus c’est redéfini au niveau de la description du service, qui est exposé à l’intérieur du cluster (voir les services commentés dans le code dispo ici).

Nous avons vu rapidement un des premiers avantages du fichier Manifest YAML, et nous avons pu en quelques lignes faire des modifications n’ayant aucun impact fonctionnel sur le service rendu. Nous allons voir que c’est cette accélération qui est importante et qui va nous apporter un avantage considérable sur la vision du S.I. traditionnel (même si aucun principe au niveau sécurité n’est remis en cause).

Une projection de la sécurité

D’un certain point de vue, je pense que JCVD avait raison, sur la cristallisation d’un état futur, participant à la réussite de son projet. On aurait tout aussi bien pu entendre des mots comme « traçabilité des exigences », « BDD » (Behavior Driven Development), ou plus récemment « DSC » chez Microsoft (Desired State Configuration).

Disclaimer

Je tiens évidemment à refaire un disclaimer au beau milieu de ma réflexion. Car évidemment j’écris ces lignes sans avoir composé de plan particulier, sans savoir ou tout cela va me mener. La forme du discours est lui même contradictoire au fond et au message que j’aimerais faire passer. Mais j’aurais le temps de venir corriger certaines choses, et le plus important est de toujours tenter de s’améliorer. Donc, ce que je vais essayer d’expliquer n’est évidemment que mon point de vue et ce n’est certainement pas partagé par tout le monde. Tous conseils, « vérités » doivent être replacés dans le contexte de ce que l’on veut accomplir…

IaC

« Je code donc je suis« , pourrait dès à présent être remplacé par « Je code ce que j’ai envie d’être ». Dans ces belles déclarations philosophiques, ce qui est intéressant c’est de pouvoir agir à un seul endroit sur le fonctionnel, le service, et la sécurité. C’est aussi peut-être réconcilier au sein d’une même équipe le développeur, l’opérationnel et la sécurité (jusqu’à aujourd’hui c’était difficile).

Découpage en couches

L’avantage du cluster Kubernetes c’est sa faible adhérence au socle d’infra utilisé. Dans mon cas j’ai choisi de le faire fonctionner sur un « compute node » sur un fournisseur Cloud (j’en ferais certainement un billet). Le fournisseur Cloud se charge de maintenir à jour sa base de virtualisation, je dois me charger de maintenir à jour l’OS virtualisé ainsi que la base K3S. Les applicatifs (conteneurs) n’ont aussi que peu d’adhérence avec l’infra de conteneurisation. Tout peut être mis à jour indépendamment de chaque couche. K3S possède aussi une procédure pour se mettre à jour automatiquement, mais n’ayant pas de contrainte de disponibilité je ne l’utiliserais peut-être pas.

Jusqu’à aujourd’hui le principal frein à la mise à jour de l’applicatif, était les fortes dépendances et les impacts forts en production. Le coût estimé était parfois trop lourd vis à vis du risque pris d’arrêter et de redémarrer les services (ou même vis à vis du coût de revient de l’applicatif en production).

Déploiement de WordPress

Manifest YAML

Il suffit de s’inspirer du repo :

A kubectl YAML to deploy WordPress on Kubernetes
https://github.com/kyzdev/wordpress-k3s
0 forks.
0 stars.
0 open issues.
Recent commits:

Architecture n-tiers

Avec un fichier de déploiement tel que celui utilisé pour WordPress on peut voir que celui-ci utilise deux applications/conteneurs principa(les/aux) :

  • WordPress (Application PHP fonctionnant sur Apache)
  • Base de donnée MySQL

Avec K3S la sécurité reste minimale car la couche réseau utilisée est aussi minimaliste. Il est possible d’aller plus loin avec des implémentations comme Calico ou Cilium. Et de définir des règles réseau supplémentaires pour les déploiement des services. Je pense que cela pourra faire l’objet d’un article plus approfondi, notamment dans cette volonté de consolider toujours un peu plus notre cluster K3S. On peut voir aussi qu’avec les « Network Policies » ce sont des fichiers YAML qui seront intégrés au projet, et donc que les problématiques de sécurité adhèrent au projet. L’application de ces règles n’impactent pas le service (sauf si des règles viennent à couper des flux nécessaires). Je ne résiste pas à mettre un lien SSTIC intéressant aussi sur eBPF sur Kubernetes.

En première étape, ce qu’il est important de noter, c’est que depuis l’extérieur en passant par Traefik, il est impossible d’accéder directement à la base de données, que les services ne sont pas directement exposés. En deuxième étape, nous verrons plus tard…

La donnée

Toute la donnée importante de ce déploiement est située dans des volumes Kubernetes. L’utilisation d’applicatifs en conteneur répond facilement à une des questions importantes pour un DPO : Où sont situées mes données ? Et personnellement, pour le stockage, la sauvegarde, voir l’archivage des données c’est beaucoup simple : il suffit de sauvegarder tous les volumes persistants du cluster. En réalité, ça fait beaucoup moins de données que si on sauvegarde l’intégralité d’un cluster VMware avec Veeam, beaucoup moins de ressources utilisés et des problématiques de compression et de déduplication qui s’envolent. Il faut noter que des données de configuration sont stockées dans des objets ConfigMap, ou Secrets directement au sein du cluster, et qu’il ne faut pas les oublier…

Conclusion

Je crois que vous avez fini par comprendre où je voulais en venir. Mon but n’était pas technique, sur la toile on trouve suffisamment de ressources pour déployer telle ou telle application. J’avoue que parfois comme les technos vont assez vite, tout n’est pas tout à fait à jour. J’ai essayé de pointer du doigt certaines portes d’entrées, que l’on ose ou pas prendre. J’entends trop de questions ou d’affirmations sur les conteneurs ou Kubernetes qui me font sourire ou pleurer… « Kubernetes ce n’est pas pour nous », « Les conteneurs en production c’est mal », « Docker ce n’est pas secure », etc…

Je pense qu’il faut prendre un peu de recul, et surtout que l’accélération possible offerte par ces technologies est plutôt une opportunité (si vous partez sur les ressources que j’ai fourni, il faut moins de 15 minutes pour avoir des services qui tournent). Il faut se poser les bonnes questions avant de démarrer, mais les possibilités de test, de reproductibilité et d’infrastructure immutable sont de réels avantages pour un expert sécurité qui voudra apporter du hardening par petites touches.

Je pense continuer à apporter des petits compléments dans cette série d’épisodes, mais on peut dire que dès à présent la majorité du message est passé. Si vous avez des commentaires, des compléments, n’hésitez pas : ici ou sur Twitter, c’est permis !!!

L’article K3S/WordPress – A (long) way to DevSecOps – Épisode 4 est apparu en premier sur n0secure.org.

↧
Search

K3S/Monitoring – A (long) way to DevSecOps –Épisode 5

June 7, 2020, 8:12 am
$
0
0

A long way to DevSecOps : Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5, Épisode 6.

Helm

On va reparler des Charts et de Helm pour accélérer le déploiement de certains éléments. J’ai réussi à monter en compétence sur le contenu des fichiers YAML, et donc on peut passer à la vitesse supérieure. Il faut néanmoins faire attention à ce qui est « auto-magiquement » poussé dans le cluster (revoir la chaîne de confiance et toussa, toussa… bref on ne va pas se répéter…).

Je conseille de passer par une phase de compréhension des éléments contenus dans les fichiers YAML et de bien « galérer » avec kubectl, avant d’accélérer avec Helm.

Installation

Pour installer Helm sur Ubuntu 20.04, c’est assez simple on va passer par snap :

sudo snap install helm --classic

Il faut ajouter dans le fichier .profile du répertoire home :

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
export PATH=$PATH:/snap/bin
source ~/.profile

Et vérifier que helm accède bien au cluster K3S :

$ helm ls
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION

Ajouter le dépôt par défaut :

$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Monitoring

On va utilise Prometheus qui est incubé par la CNCF. C’est un logiciel assez prometteur (comme sont nom l’indique), il permet de stocker des métriques dans une base de données temporelle. Il va questionner des « exporters » en HTTP, puis stocke les infos en base. Grafana se charge de la visualisation. Cela permet d’avoir un ensemble plutôt léger programmé en Go.

J’apprécie aussi la couche Beats de chez Elastic, mais mon mini-cluster n’est clairement pas taillé pour accueillir une Elastic Stack (ELK).

[Nouvelle vidéo qui reprend tout ce qui est écrit ici]. Je vous invite à souscrire et à mettre un ptit pouce bleu (nous sommes restés so 2.0 avec le blogging).

Prometheus

Création de l’emplacement de travail

mkdir monitoring
cd monitoring

Téléchargement des valeurs customisables (dans le fichier prometheus.yaml), puis installation (mais ne pas oublier de modifier les valeurs désirées) :

helm inspect values stable/prometheus > prometheus.yaml
helm upgrade --install prometheus -f prometheus.yaml -n monitoring stable/prometheus

Il suffit de modifier les valeurs désirées dans le fichier YAML généré. Dans mon cas j’ai juste changé la classe des PVC (Persistent Volume Claim).

Grafana

helm inspect values stable/grafana > grafana.yaml (dans le fichier grafana.yaml)
helm upgrade --install grafana -f grafana.yaml -n monitoring stable/grafana

Ingress

Un petit apply sur ce fichier et Grafana est accessible sur l’URL mis en paramètre.

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: ingressroutetls-grafana
  namespace: monitoring
spec:
  entryPoints:
    - websecure
  routes:
  - match: Host(`grafana.example.com`)
    kind: Rule
    services:
    - name: grafana
      port: 80

Pour se connecter il faut récupérer le mot de passe « admin » par défaut :

kubectl get secret --namespace monitoring grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

Source

Première étape, ajouter la source « Pometheus » à Grafana. Dans la configuration par défaut du Chart, celui-ci est disponible au sein du cluster à l’adresse : http://prometheus-server:80

Dashboards

Il existe quelques dashboards pré-configurés pour aller plus vite, cependant il est important de passer un peu de temps pour avoir son propre dashboard, et avoir les informations désirées en tête de page.

Node Exporter Full

Étape facile, il faut se connecter sur : https://grafana.example.com/dashboard/import et importer le dashboard ayant l’ID 1860.

Voilà le résultat par défaut :

Kubernetes Dashboard

Pour ce dashboard, il faut importer l’ID 8685 :

Conclusion

Le monitoring est essentiel dans la création d’un cluster Kubernetes de production. Dans notre cas cela peut être assez limité, tant que les services restent minimaux, mais ce n’est plus totalement le cas (on voit déjà de la pression au niveau des process). Il va falloir jouer sur les paramètres d’allocation de ressources des Pods, pour que l’orchestration se passe de manière plus aisée.

L’article K3S/Monitoring – A (long) way to DevSecOps – Épisode 5 est apparu en premier sur n0secure.org.

↧
↧

Rancher Longhorn 1.0.0

July 1, 2020, 1:13 pm
$
0
0

Installation

Prérequis

Il faut un petit cluster Kubernetes avec 3 nœuds minimum.

Sur Ubuntu il faut installer open-iscsci sur tous les noeuds :

apt-get install open-iscsi

Installation via kubectl

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml

Documentation complète : https://longhorn.io/docs/0.8.0/install/

Utilisation

Installation de WordPress

On peut reprendre le fichier manifest déjà présenté précédemment en changeant juste la classe de stockage des données « managed-nfs-storage » en « longhorn ».

A kubectl YAML to deploy WordPress on Kubernetes
https://github.com/kyzdev/wordpress-k3s
0 forks.
0 stars.
0 open issues.
Recent commits:

Visualisation dans l’interface

On ne voit pas grand chose dans ces captures d’écran, aller voir sur le site officiel si vous voulez approfondir.

Page d’accueil

État global du cluster Longhorn

Visualisation des nœuds actifs

État des noeuds du cluster

Volumes WordPress

Volumes créés par le manifest YAML pour déployer WordPress (un pour la base MySQL et l’autre pour les fichiers PHP de WordPress)

Page de configuration

Paramètres du cluster (notamment le nombre de répliquas à créer par défaut)

Conclusion

Ce petit projet vient d’être accepté au sein de la CNCF, semble prometteur pour différents cas d’usage :

  • Petits clusters montés rapidement, sans utilisation d’un espace de stockage dédié,
  • Clusters bare metal sans déploiement d’un driver de stockage spécifique et dédié,
  • Déploiement rapide sur un cluster de VPS (mon cas d’utilisation),
  • Etc.

De plus, c’est facile à installer, à comprendre, la sauvegarde et le snapshoting est intégré. (Pour info, il y a des exemples pour monter une sauvegarde rapidement sur Minio). Bref il n’y a plus de prétexte à ne pas utiliser Kubernetes.

L’article Rancher Longhorn 1.0.0 est apparu en premier sur n0secure.org.

↧

Déploiement et sécurisation light d’un VPS sous Ubuntu 20.04

July 16, 2020, 5:10 am
$
0
0

Installation de iptables-permanent

Comme son nom l’indique ce paquet permet de sauvegarder en permanent les règles iptables stockées dans les fichiers /etc/iptables/rules.v4 (pour IPv4) et rules.v6 (pour IPv6).

apt install iptables-permanent

rules.v4

Les règles suivantes passent tous les paquets arrivant depuis l’extérieur en DROP. Comme c’est un serveur Web j’ouvre SSH, HTTP, HTTPS. J’accepte aussi les réponses aux requêtes DNS émises, et aux potentielles mises à jour de paquets via APT. J’accepte aussi les requêtes entrantes sur l’interface locale. Puis je log et drop le reste des paquets, ça permet de faire un peu de débogage. 

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Acceptable incoming TCP traffic
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 53 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 443 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i l0 -m -j ACCEPT
# Log and drop
-N LOGGING
-A INPUT -j LOGGING
-A LOGGING -m limit --limit 2/min -j LOG --log-prefix "[netfilter] " --log-level 4
-A LOGGING -j DROP
COMMIT

Il suffit de modifier la configuration rsylog, pour rediriger les logs dans un fichier spécifique (créer un fichier /etc/rsyslog.d/20-netfilter.conf) :

# Log kernel generated UFW log messages to file
:msg,contains,"[netfilter] " /var/log/netfilter.log

# Uncomment the following to stop logging anything that matches the last rule.
# Doing this will stop logging kernel generated UFW log messages to the file
# normally containing kern.* messages (eg, /var/log/kern.log)
#& stop

Les logs seront situés dans /var/log/netfilter.conf.

rules.v6

Pour l’instant je bloque tout mais je pourrais avoir besoin d’ouvrir, donc je ne désactive pas IPv6.

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
COMMIT

*raw
:PREROUTING DROP [0:0]
:OUTPUT DROP [0:0]
COMMIT

*nat
:PREROUTING DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT DROP [0:0]
:POSTROUTING DROP [0:0]
COMMIT

*security
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
COMMIT

*mangle
:PREROUTING DROP [0:0]
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:POSTROUTING DROP [0:0]
COMMIT

Vérification avec Nmap

Un petit quickscan avec Zenmap permet de confirmer la fermeture de la plupart des ports :

Installation de fail2ban

Fail2ban permet de mettre dans « une prison » toutes les requêtes insistantes sur le service SSH (par défaut c’est ce service qui est le plus utilisé mais il est possible de le faire pour HTTP, FTP, SMTP, etc).

apt install fail2ban

Configuration

Les fichiers de configuration sont situés dans le répertoire /etc/fail2ban/jail.conf. Par défaut le service sshd est bien configuré.

Vous pouvez aller voir ici, c’est bien expliqué aussi.

Bonus : utilisation d’OpenSCAP

Utilisation depuis le serveur

apt install libopenscap8

Il faut télécharger les dernières version des listes de configuration de sécurité sous format XCCDF. Ces profils sont librement téléchargeables ici.

Le principal problème c’est qu’il n’existe aucun profil pour Ubuntu 20.04 et que la compatibilité ne doit pas être « immédiate » avec la version 18.04. Il suffit d’utiliser la version pour 18.04 et de tromper la vérification de version dans le fichier ssg-ubuntu1804-ds.xml et remplacer toutes les occurrences de « CODENAME=bionic$ », par « CODENAME=focal$ ».

Puis de lancer cette commande (nous allons vérifier les règles de sécurité basique proposée par l’ANSSI) :

oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_anssi_np_nt28_minimal --report report.html ssg-ubuntu2004-ds.xml

La sortie standard ressemble à ça :

Un fichier report.html est généré :

Utilisation avec SCAP Workbench

Il est aussi possible d’effectuer à distance la vérification des règles via une connexion SSH. Il suffit de reprendre le fichier modifié des règles valables pour la version Bionic et de le charger dans l’application Workbench. Une fois l’exécution terminée on obtient directement dans l’application la validation des règles :

Conclusion

Lorsque l’on commence à mettre en place un minimum de règles de durcissement système le mieux est d’aller par étape et de bien comprendre ce que l’on essaye de mettre en place. L’avantage c’est que de nombreux utilisateurs se sont déjà frottés à cet exercice et que de nombreux tutoriels sont déjà disponibles pour aller plus vite.

Mettre en place des procédures pour améliorer la sécurité c’est bien, les vérifier et les contrôler c’est encore mieux (et optimum lorsque c’est périodique). Le projet OpenSCAP est vraiment utile pour le contrôle de ces différents points, celui-ci peut aussi valider si les CVEs sont correctement corrigés même si OpenVAS est clairement plus adapté pour ça.

Pour aller plus loin si vos règles OpenSCAP ne sont pas validées, il est possible via les playbooks Ansible fournis (dans le dossier Ansible), de corriger directement vos systèmes.

L’article Déploiement et sécurisation light d’un VPS sous Ubuntu 20.04 est apparu en premier sur n0secure.org.

↧

K3S/Velero – A (long) way to DevSecOps –Épisode 6

July 18, 2020, 6:17 am
$
0
0

A long way to DevSecOps : Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5, Épisode 6.

Edit 23/07/2020 : Remplacement de « local-path », par un nouveau provisionner de stockage (OpenEBS) qui supporte bien Velero. Un PR a été soumis, et apportera prochainement le support du stockage par défaut de K3S.

Le projet Velero

Historique

Le projet Velero naît sous le nom de « Ark » sous contrôle de l’entreprise Heptio. En 2018 alors que VMWare se rend compte de l’ampleur des technologies Kubernetes, l’entreprise décide d’absorber des compétences pour rattraper son retard sur ces technologies « Cloud-Native ». Il suffit de checker la page Wikipédia de VMWare pour se rendre compte de l’effort accordé aux technos Cloud, et le résultat qu’est aujourd’hui l’offre mature de PKS :

Velero est donc aujourd’hui sous contrôle de VMWare et l’offre « open source » de VMWare se retrouve sous le nom de VMWare Tanzu. On y retrouve Velero toujours librement accessible.

Fonctionnement

Bon, je ne vais pas refaire une nième description de ce logiciel. En gros Velero va sauvegarder tous les éléments permettant de restaurer une application. Une petite démo sympathique se trouve ici.

La sauvegarde des éléments constituant une application peut-être effectuée sur un stockage compatible AWS, c’est ici que l’on va utiliser Minio.

Projet démo

Depuis les dernières releases, il y a un petit projet démo qui est inclus dans Velero. Nous n’allons pas l’utiliser mais il y a toutes les ressources nécessaires pour comprendre rapidement le fonctionnement de Velero.

Installation et utilisation

Installation d’OpenEBS

Avec Helm c’est simple :

helm repo add openebs https://openebs.github.io/charts
helm repo update
helm install --namespace openebs --name openebs openebs/openebs

Installation de Minio

Il est possible d’installer Minio directement sur le cluster Kubernetes. Dans mon cas je l’ai installé ailleurs, pour déporter la sauvegarde en dehors du cluster (disaster recovery). Dans le projet de démo il y a le fichier Manifest nécessaire pour déployer Minio.

Installation de Velero

Ici tout se passe en une ligne de commande. Il faut néanmoins préparer le fichier permettant de se connecter à Minio. Fichier exemple (secrets) :

[default]
aws_access_key_id = accessid
aws_secret_access_key = secretpassword

Il suffit de lancer la commande velero disponible dans la release de votre choix (auparavant il faut créer un bucket sur votre Minio – ici le nom est velero, et d’avoir l’URL de votre Minio – remplacer anywhere.com) :

velero install --provider aws --bucket velero --secret-file secrets --use-volume-snapshots=false --use-restic --backup-location-config region=minio,s3ForcePathStyle="true",s3Url=https://anywhere.com,publicUrl=https://anywhere.com --plugins velero/velero-plugin-for-aws:v1.0.0

La commande velero va pouvoir être utilisée par la suite pour gérer les sauvegardes (elle va se connecter automatiquement sur les APIs de l’application nouvellement déployée sur votre K8S).

Vous pouvez déjà vérifier l’état de santé de votre déploiement avec cette commande :

kubectl get deployments/velero -n velero

Le résultat attendu :

NAME     READY   UP-TO-DATE   AVAILABLE   AGE
velero   1/1     1            1           1h

Utilisation de Velero

J’ai déployé rapidement un Prometheus/Grafana sur mon infra K3S, on va le sauvegarder, le détruire puis le restaurer.

Monitoring

Voir l’épisode précédent.

Attention : il faut customiser le déploiement en utilisant « openebs-hostpath » en tant que StorageClass.

Visualisation du fonctionnement de Grafana

Sauvegarde du namespace Monitoring

Annotation des volumes de stockage (propre à mon déploiement) :

kubectl -n monitoring annotate pod/prometheus-server-596d96465b-lxnnc  backup.velero.io/backup-volumes=storage-volume
kubectl -n monitoring annotate pod/prometheus-alertmanager-644cf8f47c-bf5b4 backup.velero.io/backup-volumes=storage-volume
kubectl -n monitoring annotate pod/grafana-7fb88c95b7-lxzb2 backup.velero.io/backup-volumes=storage

Attention, ne faites comme moi ce n’est pas le nom du PVC qu’il faut mettre mais bien le volume que l’on obtient avec un petit « describe ».

velero backup create monitoring-save --include-namespaces monitoring

Vérification de la sauvegarde

# velero get backup

Visualisation dans Minio

Destruction de l’application

kubectl delete namespace monitoring

Vérification du statut

# kubectl get all -n monitoring
No resources found in monitoring namespace.

Restauration de l’application

velero restore create monitoring-restore --from-backup monitoring-save

Vérification du statut

# velero restore get
NAME                 BACKUP            STATUS      ERRORS   WARNINGS   CREATED                          SELECTOR
monitoring-restore   monitoring-save   Completed   0        0          2020-07-23 11:56:40 +0200 CEST   <none>

Tout est bien restauré et l’application est de retour, et on voit bien le petit temps d’indisponibilité sur la supervision :

Bonus

Politique de sauvegarde

Il est possible via la commande velero de programmer (scheduler :-p) des sauvegardes périodiques.

Toutes les heures avec un maximum d’une journée :

velero schedule create monitoring-hourly --schedule="@every 1h" --ttl 24h0m0s --include-namespaces monitoring

Tous les jours avec un maximum d’une semaine :

velero schedule create monitoring-daily --schedule="@every 24h" --ttl 168h0m0s --include-namespaces monitoring

Conclusion

Nous avons vu depuis le début de cette suite d’articles comment :

  • installer K3S,
  • déployer un provisionner de stockage (NFS ou vous pouvez utiliser Longhorn, comme je suis retourné sur un master node only, je vais utiliser OpenEBS),
  • superviser rapidement le cluster avec une solution de monitoring,
  • déployer ses premières applications (WordPress / Portainer),
  • les sauvegarder et les restaurer et mettre en place une politique de sauvegarde.

C’est déjà une bonne base d’un point de vue infra, il faudra voir ce que l’on veut approfondir par la suite, plus d’un point vue DevOps. Si vous avez des commentaires, des compléments, n’hésitez pas : ici ou sur Twitter, c’est permis !!! Kenavo.

L’article K3S/Velero – A (long) way to DevSecOps – Épisode 6 est apparu en premier sur n0secure.org.

↧

Loki / Grafana sur K3S

July 23, 2020, 10:23 am
$
0
0

Précondition : Il faut avoir un Grafana de déployé dans votre cluster Kubernetes. Vous pouvez aller voir ici.

Installation de Loki

Ajout du repo

helm repo add loki https://grafana.github.io/loki/charts
helm repo update

Extraction des valeurs configurables

helm inspect values loki/loki-stack> loki-stack.yaml

Modification des valeurs

Je mets ici un extrait des valeurs pour ma propre configuration (fichier loki-stack.yaml). J’ai limité la période de rétention à une semaine. Et j’ai utilisé comme storageclass OpenEBS. J’ai choisi Promtail pour pousser les logs dans Loki.

loki:
  fullnameOverride: loki
  enabled: true

promtail:
  enabled: true
  loki:
    serviceName: loki

fluent-bit:
  enabled: false

grafana:
  enabled: false
  sidecar:
    datasources:
      enabled: true
  image:
    tag: 6.7.0

config:
  table_manager:
    retention_deletes_enabled: true
    retention_period: 168h

persistence:
  enabled: true
  accessModes:
  - ReadWriteOnce
  size: 10Gi
  annotations: {}
  # subPath: ""
  # existingClaim: ""
  storageClassName: openebs-hostpath

Déploiement

Création d’un namespace logs et déploiement de Loki dans celui-ci.

kubectl create namespace logs
helm upgrade --install loki -f loki-stack.yaml -n logs loki/loki-stack

Configuration de Grafana

Ajout de la source dans Grafana

Consultation des logs

Dans l’onglet explore (en sélectionnant comme source Loki), voici les logs pour le namespace « logs ».

Conclusion

Trop souvent, chercher pourquoi une application ne fonctionne pas dans le cluster Kubernetes c’est problématique. Avec une interface pour visualiser les logs c’est un peu plus facile…

L’article Loki / Grafana sur K3S est apparu en premier sur n0secure.org.

↧
↧

Quick Deploy #001 – NextCloud

July 24, 2020, 8:43 am
$
0
0

Contexte

J’ai déjà parlé de la sauvegarde Cloud, que j’utilisais personnellement pour les fichiers les plus importants. A l’heure du numérique même si on se remet dans un contexte où la vie est certainement plus importante, et son éphémérité sa véritable quintessence, on peut quand même avoir besoin de sauvegarder quelques fichiers…

Dans quelques jours mon abonnement Office 365 prend fin, j’aurais pu continuer dans le même schéma, mais le but est à défaut de faire mieux, de faire différent. Alors on prend ses petites mimines et en 2 temps 3 mouvements on s’installe un petit NextCloud.

Bonus

Changer le StorageClass par défaut, c’est par ici.

Installation de NextCloud avec Helm

Prérequis

Extraction des valeurs

kubectl create namespace nextcloud
helm show values stable/nextcloud >> nextcloud.values.yml

Modification des valeurs

Voici la liste des valeurs que vous pouvez modifier (dans le fichier nouvellement créé) :

  • nextcloud.host : nom de domaine
  • nextcloud.password : ce que vous voulez
  • internalDatabase.enabled=false : pour installer mariadb
  • externalDatabase.enabled=true : pounr activer mariadb
  • externalDatabase.password : ce que vous voulez
  • mariadb.enabled=true : pour activer le container mariadb
  • mariadb.db.password : correspond au password d’externalDatabase
  • mariadb.persistence.enabled=true
  • redis.enabled=true : pour activer le cache redis et avoir une appli un poil plus réactive
  • persistence.enabled=true : pour le stockage de fichiers

Déploiement de NextCloud

helm upgrade --install nextcloud -f nextcloud.values.yml -n nextcloud stable/nextcloud

Note : par défaut le déploiement est très bien adapté à un cluster en déployant Mariadb en master/slave ainsi que Redis. On peut aussi augmenter le nombre de répliquas de l’application et (ou) activer le scaling horizontal…

Conclusion

Premier petit billet d’informations que l’on peut certainement trouver partout sur le net, cela me permet d’utiliser le blog en tant que bloc-notes. A bientôt…

L’article Quick Deploy #001 – NextCloud est apparu en premier sur n0secure.org.

↧

Quick Deploy #002 – OnlyOffice DocumentServer

July 25, 2020, 9:30 am
$
0
0

Ce billet peut être la suite de celui-ci : Installation de NextCloud.

Téléchargement du Manifest

Je n’ai pas trouvé quelque chose de satisfaisant pour déployer OnlyOffice, j’ai donc refait un petit Kustomize (de plus j’ai galéré pour qu’il fonctionne derrière Traefik, donc ça peut vous économiser du temps). Il suffit de cloner ce dépot :

A kubectl YAML to deploy OnlyOffice on Kubernetes
https://github.com/kyzdev/onlyoffice-k3s
0 forks.
0 stars.
0 open issues.
Recent commits:

Customization du Manifest

Dans le fichier overlays/prod/kustomization.yaml, il faut changer le mot de passe permettant l’accès à OnlyOffice.

Il faut aussi changer l’URL dans le fichier overlays/prod/ingressroute-onlyoffice.yaml.

Installation

kubectl apply -k overlays/prod

Configuration de NextCloud

Ajouter le plugin OnlyOffice (dans les applications) :

Configurer le plugin en renseignant l’URL précédemment configurée, et le mot de passe d’accès (configuration) :

Utilisation

Pour finir, voilà à quoi ça peut ressembler :

Happy Office !!!

L’article Quick Deploy #002 – OnlyOffice DocumentServer est apparu en premier sur n0secure.org.

↧
Search

Quick Deploy #003 – Rocket.Chat

July 29, 2020, 1:45 pm
$
0
0

Extraction des valeurs

helm show values stable/rocketchat >> rocketchat.values.yaml

Valeurs intéressantes

Image

Tag : version docker

image:
  repository: docker.io/rocketchat/rocket.chat
  tag: 3.5.0
  pullPolicy: IfNotPresent

SMTP

smtp:
  enabled: true
  username: 
  password: 
  host: 
  port: 587

Paramètres Mongo

Il faut remplir les 2 champs « password », il est possible aussi de déployer Mongo en cluster avec plusieurs replicas en plus. J’ai ajouté la version de MongoDB, pour pouvoir la mettre à jour par la suite.

mongodb:
  ## Enable or disable MongoDB dependency completely.
  image:
    tag: 4.2.8
  enabled: true

  mongodbRootPassword: 

  mongodbUsername: rocketchat
  mongodbPassword: 
  mongodbDatabase: rocketchat

  replicaSet:
    enabled: true
    replicas:
      secondary: 0
      arbiter: 0
    pdb:
      minAvailable:
        secondary: 0
        arbiter: 0

  persistence:
    enabled: true
    ## mongodb data Persistent Volume Storage Class
    ## If defined, storageClassName: <storageClass>
    ## If set to "-", storageClassName: "", which disables dynamic provisioning
    ## If undefined (the default) or set to null, no storageClassName spec is
    ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
    ##   GKE, AWS & OpenStack)
    ##
    # storageClass: "-"
    accessMode: ReadWriteOnce
    size: 8Gi

Persistance des données de Rocket Chat

persistence:
  enabled: true
  ## rocketchat data Persistent Volume Storage Class
  ## If defined, storageClassName: <storageClass>
  ## If set to "-", storageClassName: "", which disables dynamic provisioning
  ## If undefined (the default) or set to null, no storageClassName spec is
  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
  ##   GKE, AWS & OpenStack)
  ##
  # storageClass: "-"
  accessMode: ReadWriteOnce
  size: 8Gi

Exemple IngressRoute

Pour avoir accès depuis l’extérieur avec Traefik, voici un exemple de configuration :

Middleware

rocketchat-middleware.yaml :

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: rocketchat-middleware
  namespace: rocketchat
spec:
  headers:
    contentTypeNosniff: true
    browserXssFilter: true
    #HSTS
    forceSTSHeader: true
    stsIncludeSubdomains: true
    stsSeconds: 31536000
    # remove Server and X-Powered-By headers
    customResponseHeaders:
      Server: ''
      X-Powered-By: ''

IngressRoute

rocketchat-ingressroute.yaml :

"rocket.chat-ingressroute.yaml"
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: rocketchat-https
  namespace: rocketchat
spec:
  entrypoints:
  - websecure
  routes:
  - match: Host(`chat.anywhere.com`)
    kind: Rule
    services:
    - name: rocketchat-rocketchat
      port: 80
    middlewares:
    - name: rocketchat-middleware

Résultat

Installation

helm upgrade rocketchat -f rocket.chat.values.yaml -n rocketchat stable/rocketchat
# installation de la configuration traefik
kubectl apply -f rocketchat-middleware.yaml
kubectl apply -f rocketchat-ingressroute.yaml

L’article Quick Deploy #003 – Rocket.Chat est apparu en premier sur n0secure.org.

↧

Fail #001 – Firewall Box Opérateur

July 30, 2020, 4:51 am
$
0
0

Livebox v4

On pourrait se demander pourquoi garder un firewall aussi peu facile à configurer, et très peu lisible dans sa manière de fonctionner… Mais n’ayant finalement pas grand chose à protéger, je me dis qu’il est naturel de garder ce qui est fourni par défaut.

De plus j’ai petit à petit pris des décisions économiques en supprimant tout ce qui pouvait consommer plus de 50W en fonctionnement continu. Ces décisions font qu’aujourd’hui je n’ai pas forcément les moyens de déployer un pare-feu sur mon infra actuelle.

Configuration du firewall

Il est possible de passer en « élevé » ou « personnalisé », par défaut le « personnalisé » intègre les règles qui existent en « élevé ». A terme je passera certainement en « personnalisé », mais je reste en « moyen » pour l’instant.

Fail

Mon erreur vient du fait que j’ai configuré une IP en DMZ, pour des tests et que je n’ai pas enlevé cette IP une fois les tests terminés. En effet par défaut la Livebox va prendre en premier les règles NAT/PAT pour rediriger vers les services que vous avez derrière le firewall. Puis la Livebox va mapper tous les ports vers le serveur que vous avez mis en DMZ.

Je m’en suis rendu compte qu’après quelques temps à l’occasion d’un Nmap lancé depuis un VPS.

Conclusion

Faire des scans de temps en temps sur vos services peut remonter des oublis ou dysfonctionnements sur vos « homelabs ». Comme on y accorde pas forcément autant de temps et de précision qu’un réseau de production. Mais en parallèle j’avais commencé à réfléchir à des alternatives, vu que la Livebox est avare en logs, notamment ce genre de carte, mais je ne l’ai pas encore achetée. Et cela veut dire potentiellement d’acheter plus de matériels, comme switchs et routeur Wifi.

L’article Fail #001 – Firewall Box Opérateur est apparu en premier sur n0secure.org.

↧
↧

Pi-hole – Bloqueur de publicités et plus

August 12, 2020, 4:53 am
$
0
0

Pi-hole

Le fonctionnement

Toute consultation sur Internet ou utilisation d’une application connectée commence par une ou plusieurs requêtes DNS pour orienter les flux sur le Web. A partir de là toute requête DNS qui aboutit, peut potentiellement servir à afficher un ou plusieurs éléments d’une page, ou requêter les APIs d’une application.

On comprend aisément que si certaines requêtes DNS n’aboutissent pas, celle-ci sont abandonnées. C’est ainsi que Pi-hole fonctionne, c’est un serveur DNS possédant la capacité de mettre en blacklist, tout domaine ne servant qu’au tracking publicitaire des utilisateurs.

Raspberry Pi et pas seulement

L’avantage de ce projet est que maintenant il existe plusieurs façons de le déployer, et le petit docker est vraiment facile à mettre en œuvre.

Le docker-compose de la documentation officielle est suffisant pour se lancer :

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "80:80/tcp"
      - "443:443/tcp"
    environment:
      TZ: 'America/Chicago'
      # WEBPASSWORD: 'set a secure password here or it will be random'
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole/:/etc/pihole/'
      - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    # Recommended but not required (DHCP needs NET_ADMIN)
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    cap_add:
      - NET_ADMIN
    restart: unless-stopped

En gros, le conteneur va écouter sur le port 53, pour les requêtes DNS et propose aussi de remplacer le serveur DHCP si besoin (67). L’interface d’administration sera disponible via les ports 80 et 443. Le mieux est d’utiliser un petit Traefik en frontal pour l’administration et avoir un certificat poussé par Let’s Encrypt. Computerz.solutions, a rédigé un bel article là dessus, allez faire un tour !!!

Bonus

Contrôle parental

Comme les serveurs DNS sont configurables, il est facile de mettre en place un pseudo contrôle parental avec certains type de DNS :

Et comme ça peut filtrer assez fort sur certains contenus, voir même bloquer certains contenus Youtube, j’ai donc 2 instances de Pi-Hole qui fonctionne. De plus petit à petit ces services commencent à inclure aussi une politique de filtrage des publicités.

Pour aller encore plus loin

Gestion des listes

Il est possible d’ajouter d’autres sources de listes à bloquer, et d’ajouter par exemple des nom de domaines explicites dont on ne veut pas afficher le contenu :

Bloqueur de publicités sur le navigateur

Il faut aussi terminer cet article en parlant de l’extension qui permet de bloquer les publicités directement depuis le navigateur : uBlock Origin.

L’extension historique AdBlock Plus ayant perdu de sa superbe avec le virage commercial clairement pris, uBlock peut être une alternative de choix.

Note : Bien faire attention aux extensions installées, car certaines extensions se permettent de copier ces leaders, pour finalement n’être que des spywares…

Conclusion

Comme annoncé dans l’introduction, Pi-hole a le mérite d’être devenu un incontournable dans une installation domestique. Cela permet de déployer un premier bouclier face aux trackers omniprésents sur la toile. Il est possible d’améliorer ce filtrage en passant par des services DNS spécifiques (en incluant la chasse aux sites malveillants), et de compléter du coté « end user » en utilisant les bonnes applications ou bonnes extensions. Cette bonne hygiène va vous permettre de bloquer une bonne partie d’Internet (on le voit assez facilement dans l’interface d’administration de Pi-hole, ou la moitié des requêtes peuvent être bloquées), et d’aller vers un internet un poil plus sûr et plus sain. Bon surf !!!

L’article Pi-hole – Bloqueur de publicités et plus est apparu en premier sur n0secure.org.

↧

Unraid – Quelques plugins utiles

August 19, 2020, 6:45 am
$
0
0

Fonctionnement des applications

Les applications sous Unraid sont pour la plupart des conteneurs Docker qui se basent directement sur les images officielles. Elle sont juste « customisées » par la communauté pour mettre en valeur les paramètres nécessaires à son démarrage. En gros via l’interface d’administration des applications nous avons accès aux variables du container (template).

Exemple (variables du container BitwardenRS) :

Plugins

Community Applications

Ce plugin est la base de tout le système des applications/plugins de Unraid. Il est le « store » des applications et plugins fournis par la communauté. Il faut l’ajouter via l’onglet plugin d’Unraid et saisir l’URL suivante :

https://raw.githubusercontent.com/Squidly271/community.applications/master/plugins/community.applications.plg

CA Backup / Restore Appdata

Ce plugin permet de sauvegarder toutes les « applications », de stopper tous les containers, de sauvegarder l’intégralité des données liées à ceux-ci puis de les redémarrer. Il est possible de définir un horaire, et de garder un historique de ces sauvegardes.

CA Auto Update Applications

Ce plugin est assez « magique », je l’ai testé ces derniers mois, et il permet de maintenir tout à jour automatiquement. Il permet de mettre à jour, les plugins et les containers (applications). De plus il est possible de définir un nombre de jours à attendre avant de les mettre à jour (histoire d’attendre que d’autres puissent corriger d’éventuelles erreurs de mise à jour entre temps).

Rclone

J’en ai souvent parlé, Rclone permet d’effectuer des synchronisations (sauvegardes), sur les différents fournisseurs Cloud de sauvegarde. Bref vraiment utile si vous voulez sauvegarder vos données en dehors de votre NAS.

User Scripts

Ce plugin permet de manager des scripts périodiques de manière graphique. Je l’utilise par exemple pour nettoyer le serveur, ou pour lancer les tâches de sauvegarde périodique. Il est possible de visualiser les logs depuis l’interface, par contre pour les notifications mails il vaut mieux les programmer dans le script. La commande « notify » permet d’envoyer des mails en utilisant les paramètres au niveau du serveur Unraid.

/usr/local/emhttp/webGui/scripts/notify

Pour aller plus loin

Je conseille de visualiser cette série de vidéos, ou l’auteur passe un peu plus en profondeur sur différents plugins utiles. Depuis les applications fournies par la communauté (Community Applications) il est possible sans effort d’installer :

Note: Ces derniers sont maintenus par la communauté, à voir si vous voulez re-générer les containers pour des images plus récentes.

L’écosystème est assez immense, sachant qu’il est possible d’adapter assez rapidement une application Docker en un service Unraid.

L’article Unraid – Quelques plugins utiles est apparu en premier sur n0secure.org.

↧

Quick Deploy #004 – Gogs

September 9, 2020, 7:10 am
$
0
0

Installation de Gogs

Il y a quelques temps j’ai testé rapidement un déploiement rapide de Gogs sur K3S. Nous allons reprendre ces travaux et voir si ça fonctionne toujours.

A kubectl YAML to deploy GOGS on Kubernetes
https://github.com/kyzdev/gogs-k3s
0 forks.
0 stars.
0 open issues.
Recent commits:

Il suffit de récupérer les sources de ce Kustomize, puis de modifier les valeurs suivantes (dans l’overlay que vous voulez) :

  • gogs-deployment.yaml : modifier le driver de stockage (j’ai mis par défaut openebs).
  • gogs-ingressroute.yaml : pour correspondre au FQDN utilisé.

Configuration

Au premier lancement une interface vous permet d’effectuer une configuration assez facile de l’environnement Gogs, qui sera stocké sous forme de fichiers de configuration dans le répertoire persistent de Gogs. Il n’est pas possible de changer les valeurs depuis l’interface d’administration.

Voici les valeurs à modifier :

  • Database Type : SQLite (base interne), si vous installez MariaDB ou postgreSQL sélectionnez la base que vous avez choisie (comme c’est un repo interne, pas besoin de se prendre la tête…)
  • Domain : nom de domaine choisi dans le FQDN de déploiement.
  • HTTP Port : 443.
  • Application URL : FQDN.
  • Autoriser ou pas les utilisateurs à s’enregistrer.
  • Paramètre du serveur mail : Pour l’instant j’utilise un serveur mail externe.
  • Etc.

Premier lancement

On se retrouve sur cette interface sans repo par défaut :

Création d’un repo de test :

Test du fonctionnement du repo :

Il suffit d’effectuer les commandes « Create new repository on the command line » pour valider le fonctionnement de Gogs.

Une fois les commandes effectuées on obtient un repo avec un README.md vide :

Traefik

Par défaut dans ce manifest, Traefik est utilisé, cela permet d’avoir le site sécurisé via TLS.

Vous pouvez regarder ce post pour déployer la base Traefik nécessaire pour K3S.

Mot de la fin

N’oubliez pas d’inclure cette application dans votre politique de sauvegarde.

L’article Quick Deploy #004 – Gogs est apparu en premier sur n0secure.org.

↧
Viewing all 176 articles
Browse latest View live
Search