--- titre: Cybersécurité et cyberdéfense (Cours 3) description: Cybersécurité et cyberdéfense (Cours 3), 14/03/2020 tags: C&C, jerome.tchan author: Jérôme Tchan --- # Cybersécurité et cyberdéfense (Cours 3) > Guide de cours > {%pdf https://51.38.177.120/dokuwiki/lib/exe/fetch.php?media=cours:ars:guide_de_cours-c11.pdf %} ## DEFNET (✝) Au début (jusqu'à 11h45): - Est-ce que le système a été attaqué ou pas? - Est-ce que l'attaquant est toujours là ou pas? => Récupérer les premiers éléments, faire les premières analyses **Préserver la capacité d'analyse:** Récupérer des logs, des dump mémoires, faire des captures réseau, etc. en premier Caractériser l'attaque: comprendre le but de l'attaque Protéger le SI Appliquer le plan de remédiation **après autorisation de l'autorité d'emploi du SI** Inject scénario 12h: coup de pression Le pfSense peut être compromis: c'est une base FreeBSD qui peut se configurer en SSH Globalement toutes les machines étaient compromises (- le wiki et le JUMP) Il y a une liste de questions à répondre: si on peut répondre à toutes les question alors le plan d'action est bon (voir [référentiel PRIS](https://www.ssi.gouv.fr/uploads/2014/12/pris_referentiel_v2.0.pdf)) ### Scénario de l'attaquant - Reconnaissance sur myprepa.ops: nmap, nikto, dirb, wpscan - Crack d'un utilisateur limité (brute force online ou SQL injection avec sqlmap et vuln sur plugin) - Récupération des comptes utilisateur WP => crack offline - Vuln sur plugins (role editor) => escalade des privilèges => admin WP - Backdoor sur plugin HELLO DOLLY (weevely) - Connexion à la backdoor - Backdoor de secours sur akismet puis test de la backdoor de secours - Reconnaissance et utilisation des fonctionnalités de weevely - Exfiltration de la config du serveur => identifier des vuln en hors ligne - Ouverture accès meterpreter (user) - Escalade via vuln crontab + tar - Root, meterpreter (root) ouvert avec droit root sur port 31337, host gloogle.com - Mise en place d'une proxychain et autoroute pour compromettre le pfSense - Mouvement latéral vers le pfSense: medusa (bruteforce d'ID), copie de clé SSH sur le pfSense, pwn WebConfigurator (WebConfigurator tourne en root), pwn .tchrc (script attaquant encodé en base64) => meterpreter vers une kali - Mouvement latéral via la messagerie: phishing interne (pièce jointe avec macro OpenOffice) => compromission postes utilisateurs - [Water holing](https://fr.wikipedia.org/wiki/Attaque_de_point_d%27eau): publication d'un article sur le CMS avec un document OpenOffice malicieux - Mouvement latéral vers MySQL: dump de la DB avec Adminer (récupération des credentials au préalable) D'autres méthodes (plus rapides et discrètes) étaient faisables pour devenir admin sur le WordPress ## Contrôle d’accès logique (suite) Trois types (facteurs) d'authentification: - Ce que je connais (password) - Ce que je possède (carte d'accès) - Ce que je suis (biométrie) On peut combiner ces facteurs => **authentification forte** **L'authentification forte combine forcément plusieurs facteurs: un seul mot de passe fort n'est pas de l'authentification forte** **OTP:** one time password, mot de passe à usage unique - Synchrone: calcule en fonction du temps (ou d'un autre élément synchronisé entre le serveur et client), les 2 calculent en parallèle - Asynchrone: calcule en fonction d'un élément de donnée envoyé par le service (et d'une clé secrète possédée par les deux parties) ### Problématiques des mots de passe - Négligence et malveillance - On peut le cracker - Brute force - Se baser sur la langue, tous les caractères du clavier ne sont pas utilisés - Dictionnaires de mots de passe - Rainbow tables: calculer toutes les bijections possibles pour pouvoir les réutiliser après pour n'importe quel mot de passe - Pour plus de sécurité, ne pas utiliser des bijections fixes - Attaque crypto: aléa / salage, statistique, canaux auxiliaires, etc. - Outils pour collecter des mots de passe: John the Ripper, Hashcat, Hydra, etc. ### Authentification centralisée, fédérative, coopérative? **Authentification centralisée:** un seul login (robuste dans l'idéal) pour se connecter à tous les services (Ex: Active Directory) **Authentification fédérative:** un service pour se connecter à un autre service (pas forcément dans le même domaine de sécurité) (Ex: login avec Facebook) **Authentification coopérative:** deux services "s'entraident": un des services possède une partie du secret et l'autre une autre partie Challenges: - Intégration: l'application doit être compatible - Bien penser l'architecture et le domaine de sécurité - etc. ### Annuaire vs Base de données Annuaire: optimisé pour la lecture => le plus utilisé pour l'authentification Base de données: optimisé pour la lecture/écriture AAA: Authentication Authorization Accountability (RADIUS, TACACS, etc.) ### IAM Identity and Access Management ### PAM / Winlogon Abstractions ### Kerberos Au moment de l'identification, un ticket est donné, permettant de s'authentifier automatiquement sur les autres services compatibles (ex: Microsoft) ![Kerberos (simplifié)](https://i.imgur.com/OFHBuiI.jpg) ![Kerberos](https://upload.wikimedia.org/wikipedia/commons/thumb/a/a6/Kerberos-simple.svg/1000px-Kerberos-simple.svg.png) Système de poupées russes :::info Lire les RFC sur RADIUS (RFC 2865 et 2866) et Kerberos (RFC 4120) ::: ### MITRE ATT&CK Recense les techniques d'attaques https://attack.mitre.org/tactics/enterprise/ ### Privacy by design, privacy by default **Privacy by design:** Prendre en compte la vie privée et la sécurité dès le design et la conception de l'application **Privacy by default:** Mettre un haut niveau de vie privée et de sécurité par défaut ## FIC > [Documentation](https://srs.nemunai.re/fic/) > Slides > > {%pdf https://srs.nemunai.re/fic/intro/presentation.pdf %} **Le 25 janvier 2021** => Concevoir un "CTF" forensic - Choisir son équipe (par 6) et un nom - Déterminer 2 scénarios - Rechercher les caractéristiques des paliers (5 parliers par scénario) - Concevoir les défis - Réflexions sur la conception du défi - Construction du défi - Ecriture du contexte - Réalisation de la vidéo de résolution - Validation et test du défi - Préparation des serveurs Attaque, défense et admin sys - 21 mars: constitution de l’équipe et choix de 2 grandes thématiques - 4 avril: rédaction d’un document présentant les scénarios et leurs défis