mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 05:03:35 +00:00
300 lines
18 KiB
Markdown
300 lines
18 KiB
Markdown
# Nginx
|
||
|
||
<details>
|
||
|
||
<summary><strong>Leer AWS hak vanaf nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||
|
||
Ander maniere om HackTricks te ondersteun:
|
||
|
||
* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
|
||
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Deel jou haktruuks deur PRs in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
||
</details>
|
||
|
||
<figure><img src="../../.gitbook/assets/image (11).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
**Onmiddellik beskikbare opstelling vir kwetsbaarheidsassessering & pentest**. Voer 'n volledige pentest uit van enige plek met 20+ gereedskap & kenmerke wat strek vanaf rekognisering tot verslagdoening. Ons vervang nie pentesters nie - ons ontwikkel aangepaste gereedskap, opsporing & uitbuitingsmodules om hulle 'n bietjie tyd terug te gee om dieper te graaf, skulpe te laat klap, en pret te hê.
|
||
|
||
{% embed url="https://pentest-tools.com/" %}
|
||
|
||
## Ontbrekende root-plek <a href="#missing-root-location" id="missing-root-location"></a>
|
||
|
||
Wanneer die Nginx-bediener gekonfigureer word, speel die **root rigtingwyser** 'n kritieke rol deur die basiese gids te definieer waarvandaan lêers bedien word. Oorweeg die voorbeeld hieronder:
|
||
```bash
|
||
server {
|
||
root /etc/nginx;
|
||
|
||
location /hello.txt {
|
||
try_files $uri $uri/ =404;
|
||
proxy_pass http://127.0.0.1:8080/;
|
||
}
|
||
}
|
||
```
|
||
In hierdie opset word `/etc/nginx` aangewys as die hoofgids. Hierdie opstelling maak toegang tot lêers binne die gespesifiseerde hoofgids moontlik, soos `/hello.txt`. Dit is egter noodsaaklik om te let dat slegs 'n spesifieke ligging (`/hello.txt`) gedefinieer is. Daar is geen opset vir die hoofligging (`location / {...}`) nie. Hierdie weglatings beteken dat die hoofdirektief globaal van toepassing is, wat versoek toegang tot lêers onder `/etc/nginx` bied.
|
||
|
||
'n Kritieke veiligheidsoorweging spruit voort uit hierdie opset. 'n Eenvoudige `GET` versoek, soos `GET /nginx.conf`, kan sensitiewe inligting blootstel deur die Nginx-konfigurasie-lêer wat by `/etc/nginx/nginx.conf` geleë is, te dien. Om die risiko te verminder, kan die hoofgids na 'n minder sensitiewe gids, soos `/etc`, ingestel word, maar dit kan steeds onbedoelde toegang tot ander kritieke lêers moontlik maak, insluitend ander konfigurasie-lêers, toegangsjoernale, en selfs versleutelde geloofsbriewe wat vir HTTP basiese verifikasie gebruik word.
|
||
|
||
## Alias LFI Misconfiguratie <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
|
||
|
||
In die konfigurasie lêers van Nginx is 'n noukeurige inspeksie nodig vir die "ligging" riglyne. 'n Kwesbaarheid wat bekend staan as Plaaslike Lêer Insluiting (LFI) kan onbedoeld ingevoer word deur 'n konfigurasie wat soos die volgende lyk:
|
||
```
|
||
location /imgs {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
Hierdie konfigurasie is vatbaar vir LFI-aanvalle as gevolg van die bedienaar wat versoeke soos `/imgs../flag.txt` interpreteer as 'n poging om lêers buite die bedoelde gids te benader, wat effektief oplos na `/path/images/../flag.txt`. Hierdie fout maak dit vir aanvallers moontlik om lêers van die bedienaar se lêersisteem te herwin wat nie via die web toeganklik behoort te wees nie.
|
||
|
||
Om hierdie kwesbaarheid te verminder, moet die konfigurasie aangepas word na:
|
||
```
|
||
location /imgs/ {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
Meer inligting: [https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/)
|
||
|
||
Accunetix toetse:
|
||
```
|
||
alias../ => HTTP status code 403
|
||
alias.../ => HTTP status code 404
|
||
alias../../ => HTTP status code 403
|
||
alias../../../../../../../../../../../ => HTTP status code 400
|
||
alias../ => HTTP status code 403
|
||
```
|
||
## Onveilige padbeperking <a href="#onveilige-variabel-gebruik" id="onveilige-variabel-gebruik"></a>
|
||
|
||
Kyk na die volgende bladsy om te leer hoe om riglyne soos te ontduik:
|
||
```plaintext
|
||
location = /admin {
|
||
deny all;
|
||
}
|
||
|
||
location = /admin/ {
|
||
deny all;
|
||
}
|
||
```
|
||
## Onveilige gebruik van veranderlikes / HTTP-aanvraagsplitsing <a href="#onveilige-gebruik-van-veranderlikes" id="onveilige-gebruik-van-veranderlikes"></a>
|
||
|
||
{% hint style="danger" %}
|
||
Kwesbare veranderlikes `$uri` en `$document_uri` en dit kan reggestel word deur hulle te vervang met `$request_uri`.
|
||
|
||
'n Regex kan ook kwesbaar wees soos:
|
||
|
||
`location ~ /docs/([^/])? { … $1 … }` - Kwesbaar
|
||
|
||
`location ~ /docs/([^/\s])? { … $1 … }` - Nie kwesbaar (ruimtes word nagegaan)
|
||
|
||
`location ~ /docs/(.*)? { … $1 … }` - Nie kwesbaar
|
||
{% endhint %}
|
||
|
||
'n Kwesbaarheid in die Nginx-opset word gedemonstreer deur die volgende voorbeeld:
|
||
```
|
||
location / {
|
||
return 302 https://example.com$uri;
|
||
}
|
||
```
|
||
Die karakters \r (Carriage Return) en \n (Line Feed) dui nuwe lyn karakters aan in HTTP-versoeke, en hul URL-geënkripte vorms word voorgestel as `%0d%0a`. Insluiting van hierdie karakters in 'n versoek (bv., `http://localhost/%0d%0aDetectify:%20clrf`) aan 'n verkeerd geconfigureerde bediener lei daartoe dat die bediener 'n nuwe kop met die naam `Detectify` uitreik. Dit gebeur omdat die $uri-veranderlike die URL-geënkripte nuwe lyn karakters dekodeer, wat lei tot 'n onverwagte kop in die respons:
|
||
```
|
||
HTTP/1.1 302 Moved Temporarily
|
||
Server: nginx/1.19.3
|
||
Content-Type: text/html
|
||
Content-Length: 145
|
||
Connection: keep-alive
|
||
Location: https://example.com/
|
||
Detectify: clrf
|
||
```
|
||
Leer meer oor die risiko's van CRLF-inspuiting en responsverdeling by [https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/).
|
||
|
||
Hierdie tegniek word ook [**verduidelik in hierdie gesprek**](https://www.youtube.com/watch?v=gWQyWdZbdoY\&list=PL0xCSYnG\_iTtJe2V6PQqamBF73n7-f1Nr\&index=77) met 'n paar kwesbare voorbeelde en opsporingsmeganismes. Byvoorbeeld, Om hierdie wanopstelling van 'n swartkassie-perspektief op te spoor, kan jy hierdie versoek stuur:
|
||
|
||
* `https://voorbeeld.com/%20X` - Enige HTTP-kode
|
||
* `https://voorbeeld.com/%20H` - 400 Slegte versoek
|
||
|
||
Indien kwesbaar, sal die eerste terugkeer as "X" enige HTTP-metode is en die tweede sal 'n fout terugstuur aangesien H nie 'n geldige metode is nie. Dus sal die bediener iets soos ontvang: `GET / H HTTP/1.1` en dit sal die fout trigger.
|
||
|
||
'n Ander opsporingsvoorbeelde sou wees:
|
||
|
||
* `http://maatskappy.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Enige HTTP-kode
|
||
* `http://maatskappy.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Slegte versoek
|
||
|
||
Sommige gevind kwesbare opstellings wat in daardie gesprek aangebied is, was:
|
||
|
||
* Merk op hoe **`$uri`** soos in die finale URL ingestel is.
|
||
```
|
||
location ^~ /lite/api/ {
|
||
proxy_pass http://lite-backend$uri$is_args$args;
|
||
}
|
||
```
|
||
* Merk op hoe weer **`$uri`** in die URL is (hierdie keer binne 'n parameter)
|
||
```
|
||
location ~ ^/dna/payment {
|
||
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
|
||
proxy_pass http://$back;
|
||
```
|
||
* Nou in AWS S3
|
||
```
|
||
location /s3/ {
|
||
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
|
||
}
|
||
```
|
||
### Enige veranderlike
|
||
|
||
Daar is ontdek dat **gebruiker-verskafte data** onder sekere omstandighede as 'n **Nginx veranderlike** hanteer kan word. Die oorsaak van hierdie gedrag bly tot op 'n sekere mate ontwykend, tog is dit nie skaars of reguit vorentoe om te verifieer nie. Hierdie anomalie is uitgelig in 'n sekuriteitsverslag op HackerOne, wat [hier](https://hackerone.com/reports/370094) besigtig kan word. Verdere ondersoek na die foutboodskap het gelei tot die identifisering van sy voorkoms binne die [SSI-filtermodule van Nginx se kodebasis](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx\_http\_ssi\_filter\_module.c#L365), wat Server Side Includes (SSI) as die hoofoor saak aanwys.
|
||
|
||
Om **hierdie wanopset** op te spoor, kan die volgende bevel uitgevoer word, wat die instelling van 'n verwysingskop behels om vir veranderlike afdruk te toets:
|
||
```bash
|
||
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
|
||
```
|
||
Skanderings vir hierdie wanopset oor stelsels het verskeie gevalle aan die lig gebring waar Nginx-veranderlikes deur 'n gebruiker gedruk kon word. Nietemin dui 'n afname in die aantal kwesbare gevalle daarop dat pogings om hierdie probleem reg te stel, tot op 'n sekere mate suksesvol was.
|
||
|
||
## Oorspronklike agterste respons lees
|
||
|
||
Nginx bied 'n kenmerk deur `proxy_pass` wat die onderskepping van foute en HTTP-koppelelemente wat deur die agterste gemaak word, moontlik maak met die doel om interne foutboodskappe en koppelelemente te verberg. Dit word bereik deur Nginx wat aangepaste foutbladsye bedien as reaksie op agterste foute. Tog ontstaan uitdagings wanneer Nginx 'n ongeldige HTTP-aanvraag teëkom. So 'n aanvraag word na die agterste as ontvangene deurgestuur, en die agterste se oorspronklike respons word dan direk aan die klient gestuur sonder Nginx se tussenkoms.
|
||
|
||
Oorweeg 'n voorbeeldscenario wat 'n uWSGI-toepassing insluit:
|
||
```python
|
||
def application(environ, start_response):
|
||
start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
|
||
return [b"Secret info, should not be visible!"]
|
||
```
|
||
Om dit te bestuur, word spesifieke riglyne in die Nginx-konfigurasie gebruik:
|
||
```
|
||
http {
|
||
error_page 500 /html/error.html;
|
||
proxy_intercept_errors on;
|
||
proxy_hide_header Secret-Header;
|
||
}
|
||
```
|
||
* [**proxy\_intercept\_errors**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_intercept\_errors): Hierdie riglyn stel Nginx in staat om 'n aangepaste reaksie te dien vir agterste reaksies met 'n statuskode groter as 300. Dit verseker dat, vir ons voorbeeld uWSGI-aansoek, 'n `500 Fout` reaksie onderskep en hanteer word deur Nginx.
|
||
* [**proxy\_hide\_header**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_hide\_header): Soos die naam aandui, hierdie riglyn verberg gespesifiseerde HTTP-koppe van die klient, wat privaatheid en sekuriteit verbeter.
|
||
|
||
Wanneer 'n geldige `GET` versoek gedoen word, verwerk Nginx dit normaalweg, deur 'n standaard fout reaksie terug te stuur sonder om enige geheime koppe bloot te stel. 'n Ongeldige HTTP versoek omseil egter hierdie meganisme, wat lei tot die blootstelling van rou agterste reaksies, insluitend geheime koppe en foutboodskappe.
|
||
|
||
## merge\_slashes ingestel op af
|
||
|
||
Standaard is Nginx se **`merge_slashes` riglyn** ingestel op **`aan`**, wat meervoudige skuiweerslagte in 'n URL in 'n enkele skuiweerslag saamdruk. Hierdie kenmerk, terwyl dit URL-verwerking stroomlyn, kan onbedoeld kwesbaarhede in aansoeke agter Nginx verberg, veral dié vatbaar vir plaaslike lêerinsluiting (LFI) aanvalle. Sekuriteitsexperts **Danny Robinson en Rotem Bar** het die potensiële risiko's wat verband hou met hierdie verstekgedrag beklemtoon, veral wanneer Nginx as 'n omgekeerde proksi optree.
|
||
|
||
Om sulke risiko's te verminder, word dit aanbeveel om die `merge_slashes` riglyn af te skakel vir aansoeke wat vatbaar is vir hierdie kwesbaarhede. Dit verseker dat Nginx versoek na die aansoek stuur sonder om die URL-struktuur te verander, en dus nie enige onderliggende sekuriteitskwessies te verberg nie.
|
||
|
||
Vir meer inligting, kyk na [Danny Robinson en Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).
|
||
|
||
### **Kwaadwillige Reaksie Koppe**
|
||
|
||
Soos getoon in [**hierdie uiteensetting**](https://mizu.re/post/cors-playground), is daar sekere koppe wat, indien teenwoordig in die reaksie van die webbediener, die gedrag van die Nginx proksi sal verander. Jy kan hulle nagaan [**in die dokumentasie**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/):
|
||
|
||
* `X-Accel-Redirect`: Dui Nginx aan om intern 'n versoek na 'n gespesifiseerde ligging te herlei.
|
||
* `X-Accel-Buffering`: Beheer of Nginx die reaksie moet buffer of nie.
|
||
* `X-Accel-Charset`: Stel die karakterstel vir die reaksie wanneer X-Accel-Redirect gebruik word.
|
||
* `X-Accel-Expires`: Stel die vervaltyd vir die reaksie wanneer X-Accel-Redirect gebruik word.
|
||
* `X-Accel-Limit-Rate`: Beperk die oordragtempo vir reaksies wanneer X-Accel-Redirect gebruik word.
|
||
|
||
Byvoorbeeld, die kop **`X-Accel-Redirect`** sal 'n interne **herlei** in die nginx veroorsaak. Dus, 'n nginx-konfigurasie met iets soos **`root /`** en 'n reaksie van die webbediener met **`X-Accel-Redirect: .env`** sal maak dat nginx die inhoud van **`/.env`** stuur (Pad Traversal).
|
||
|
||
### **Verstekwaarde in Map Riglyn**
|
||
|
||
In die **Nginx-konfigurasie** speel die `map` riglyn dikwels 'n rol in **toestemmingsbeheer**. 'n Algemene fout is om nie 'n **verstek** waarde te spesifiseer nie, wat tot ongemagtigde toegang kan lei. Byvoorbeeld:
|
||
```yaml
|
||
http {
|
||
map $uri $mappocallow {
|
||
/map-poc/private 0;
|
||
/map-poc/secret 0;
|
||
/map-poc/public 1;
|
||
}
|
||
}
|
||
```
|
||
|
||
```yaml
|
||
server {
|
||
location /map-poc {
|
||
if ($mappocallow = 0) {return 403;}
|
||
return 200 "Hello. It is private area: $mappocallow";
|
||
}
|
||
}
|
||
```
|
||
Sonner 'n `standaard`, kan 'n **booswillige gebruiker** sekuriteit omseil deur toegang tot 'n **ongedefinieerde URI** binne `/map-poc`. [Die Nginx handleiding](https://nginx.org/en/docs/http/ngx\_http\_map\_module.html) beveel aan om 'n **standaardwaarde** in te stel om sulke probleme te voorkom.
|
||
|
||
### **DNS Spoofing Kwesbaarheid**
|
||
|
||
DNS-spoofing teen Nginx is moontlik onder sekere omstandighede. As 'n aanvaller die **DNS-bediener** wat deur Nginx gebruik word ken en sy DNS-navrae kan onderskep, kan hulle DNS-rekords vervals. Hierdie metode is egter ondoeltreffend as Nginx gekonfigureer is om **localhost (127.0.0.1)** vir DNS-oplossing te gebruik. Nginx maak dit moontlik om 'n DNS-bediener as volg te spesifiseer:
|
||
```yaml
|
||
resolver 8.8.8.8;
|
||
```
|
||
### **`proxy_pass` en `internal` Direktiewe**
|
||
|
||
Die **`proxy_pass`**-riglyn word gebruik om versoek na ander bedieners te stuur, intern of ekstern. Die **`internal`**-riglyn verseker dat sekere areas slegs binne Nginx toeganklik is. Alhoewel hierdie riglyne nie op hul eie kwesbaarhede is nie, vereis hul konfigurasie sorgvuldige ondersoek om sekuriteitsfoute te voorkom.
|
||
|
||
## proxy\_set\_header Opgradering & Verbinding
|
||
|
||
As die nginx-bediener gekonfigureer is om die Opgradering- en Verbindingskoppe deur te gee, kan 'n [**h2c Smuggling-aanval**](../../pentesting-web/h2c-smuggling.md) uitgevoer word om toegang tot beskermde/internale eindpunte te verkry.
|
||
|
||
{% hint style="danger" %}
|
||
Hierdie kwesbaarheid sou 'n aanvaller in staat stel om 'n direkte verbinding met die `proxy_pass`-eindpunt (`http://backend:9999` in hierdie geval) tot stand te bring waarvan die inhoud nie deur nginx nagegaan sal word nie.
|
||
{% endhint %}
|
||
|
||
Voorbeeld van 'n kwesbare konfigurasie om `/flag` te steel van [hier](https://bishopfox.com/blog/h2c-smuggling-request):
|
||
```
|
||
server {
|
||
listen 443 ssl;
|
||
server_name localhost;
|
||
|
||
ssl_certificate /usr/local/nginx/conf/cert.pem;
|
||
ssl_certificate_key /usr/local/nginx/conf/privkey.pem;
|
||
|
||
location / {
|
||
proxy_pass http://backend:9999;
|
||
proxy_http_version 1.1;
|
||
proxy_set_header Upgrade $http_upgrade;
|
||
proxy_set_header Connection $http_connection;
|
||
}
|
||
|
||
location /flag {
|
||
deny all;
|
||
}
|
||
```
|
||
{% hint style="warning" %}
|
||
Let wel dat selfs as die `proxy_pass` na 'n spesifieke **pad** soos `http://backend:9999/socket.io` wys, sal die verbinding met `http://backend:9999` tot stand gebring word sodat jy **enige ander pad binne daardie interne eindpunt kan kontak. Dit maak nie saak of 'n pad gespesifiseer word in die URL van proxy\_pass nie.**
|
||
{% endhint %}
|
||
|
||
## Probeer dit self
|
||
|
||
Detectify het 'n GitHub-opberging geskep waar jy Docker kan gebruik om jou eie kwesbare Nginx toetsbediener met sommige van die verkeerde konfigurasies wat in hierdie artikel bespreek word, op te stel en self te probeer vind!
|
||
|
||
[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)
|
||
|
||
## Statische Analiseerder gereedskap
|
||
|
||
### [GIXY](https://github.com/yandex/gixy)
|
||
|
||
Gixy is 'n gereedskap om Nginx-konfigurasie te analiseer. Die hoofdoel van Gixy is om sekuriteitsverkeerde konfigurasie te voorkom en foutopsporing te outomatiseer.
|
||
|
||
### [Nginxpwner](https://github.com/stark0de/nginxpwner)
|
||
|
||
Nginxpwner is 'n eenvoudige gereedskap om na algemene Nginx-verkeerde konfigurasies en kwesbaarhede te soek.
|
||
|
||
## Verwysings
|
||
|
||
* [**https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/**](https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/)
|
||
* [**http://blog.zorinaq.com/nginx-resolver-vulns/**](http://blog.zorinaq.com/nginx-resolver-vulns/)
|
||
* [**https://github.com/yandex/gixy/issues/115**](https://github.com/yandex/gixy/issues/115)
|
||
|
||
<figure><img src="../../.gitbook/assets/image (11).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
**Onmiddellik beskikbare opstelling vir kwesbaarheidsassessering & penetrasietoetsing**. Voer 'n volledige pentest van enige plek af uit met 20+ gereedskap & kenmerke wat van rekognisering tot verslagdoening gaan. Ons vervang nie pentesters nie - ons ontwikkel aangepaste gereedskap, opsporing & uitbuitingsmodules om hulle 'n bietjie tyd te gee om dieper te delf, skulpe te laat pop en pret te hê.
|
||
|
||
{% embed url="https://pentest-tools.com/" %}
|
||
|
||
<details>
|
||
|
||
<summary><strong>Leer AWS-hacking van niks tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||
|
||
Ander maniere om HackTricks te ondersteun:
|
||
|
||
* As jy jou **maatskappy geadverteer wil sien in HackTricks** of **HackTricks in PDF wil aflaai** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
|
||
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opberge.
|
||
|
||
</details>
|