---
# System prepended metadata

title: Cybersécurité et cyberdéfense (Cours 3)
tags: [C&C, ' jerome.tchan']

---

---
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