mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 22:52:06 +00:00
296 lines
18 KiB
Markdown
296 lines
18 KiB
Markdown
# Nginx
|
||
|
||
<details>
|
||
|
||
<summary><strong>Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)</strong></a><strong>!</strong></summary>
|
||
|
||
Njia nyingine za kusaidia HackTricks:
|
||
|
||
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
|
||
* Pata [**bidhaa rasmi za PEASS & HackTricks**](https://peass.creator-spring.com)
|
||
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) za kipekee
|
||
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos za github.
|
||
|
||
</details>
|
||
|
||
<figure><img src="../../.gitbook/assets/image (14) (1).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
**Usanidi wa papo hapo wa upimaji wa udhaifu & kudukua**. Tekeleza pentest kamili kutoka mahali popote na zana na vipengele zaidi ya 20 vinavyoanzia uchunguzi hadi ripoti. Hatuchukui nafasi ya wadukuzi - tuna
|
||
```bash
|
||
server {
|
||
root /etc/nginx;
|
||
|
||
location /hello.txt {
|
||
try_files $uri $uri/ =404;
|
||
proxy_pass http://127.0.0.1:8080/;
|
||
}
|
||
}
|
||
```
|
||
Katika usanidi huu, `/etc/nginx` imepewa jukumu la kuwa saraka kuu. Usanidi huu huruhusu ufikiaji wa faili ndani ya saraka kuu iliyotajwa, kama vile `/hello.txt`. Walakini, ni muhimu kuelewa kuwa eneo maalum (`/hello.txt`) limefafanuliwa tu. Hakuna usanidi kwa eneo la msingi (`location / {...}`). Kutokuwepo kwa hii kunamaanisha kuwa maelekezo ya msingi yanatumika kimataifa, kuruhusu maombi kwa njia ya msingi `/` kupata faili chini ya `/etc/nginx`.
|
||
|
||
Kuzingatiwa kwa usalama muhimu unatokea kutokana na usanidi huu. Ombi rahisi la `GET`, kama vile `GET /nginx.conf`, linaweza kufichua habari nyeti kwa kuhudumia faili ya usanidi wa Nginx iliyoko katika `/etc/nginx/nginx.conf`. Kuweka saraka kuu kuwa ni saraka isiyo na habari nyeti, kama vile `/etc`, kunaweza kupunguza hatari hii, hata hivyo bado inaweza kuruhusu ufikiaji usiokusudiwa kwa faili muhimu zingine, ikiwa ni pamoja na faili zingine za usanidi, magogo ya ufikiaji, na hata vibali vilivyofichwa vilivyotumika kwa uthibitishaji wa msingi wa HTTP.
|
||
|
||
## Kosa la Mpangilio wa LFI kwa Kutumia Alias <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
|
||
|
||
Katika faili za usanidi za Nginx, uchunguzi wa karibu unahitajika kwa maelekezo ya "location". Udhaifu unaojulikana kama Ujumuishaji wa Faili za Kienyeji (LFI) unaweza kuingizwa kwa bahati mbaya kupitia usanidi unaofanana na ule ufuatao:
|
||
```
|
||
location /imgs {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
Hii mipangilio inaweza kushambuliwa na mashambulizi ya LFI kwa sababu ya seva kutafsiri maombi kama vile `/imgs../flag.txt` kama jaribio la kufikia faili nje ya saraka iliyokusudiwa, ikielekeza kwa `/path/images/../flag.txt`. Kasoro hii inaruhusu wachomaji kuchukua faili kutoka kwa mfumo wa seva ambazo hazipaswi kupatikana kupitia wavuti.
|
||
|
||
Ili kupunguza udhaifu huu, mipangilio inapaswa kurekebishwa kuwa:
|
||
```
|
||
location /imgs/ {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
Zaidi ya habari: [https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/)
|
||
|
||
Vipimo vya Accunetix:
|
||
```
|
||
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
|
||
```
|
||
## Kizuizi hatari la njia <a href="#matumizi-hatari-ya-variable" id="matumizi-hatari-ya-variable"></a>
|
||
|
||
Angalia ukurasa ufuatao kujifunza jinsi ya kudukua maagizo kama:
|
||
```plaintext
|
||
location = /admin {
|
||
deny all;
|
||
}
|
||
|
||
location = /admin/ {
|
||
deny all;
|
||
}
|
||
```
|
||
## Matumizi hatari ya kivinjari / Kugawanya Ombi la HTTP <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||
|
||
{% hint style="danger" %}
|
||
Vidokezo vinavyoweza kudhurika `$uri` na `$document_uri` na hili linaweza kurekebishwa kwa kuvibadilisha na `$request_uri`.
|
||
|
||
Regex inaweza pia kuwa hatarini kama:
|
||
|
||
`location ~ /docs/([^/])? { … $1 … }` - Hatarini 
|
||
|
||
`location ~ /docs/([^/\s])? { … $1 … }` - Si hatarini (kuangalia nafasi)
|
||
|
||
`location ~ /docs/(.*)? { … $1 … }` - Si hatarini
|
||
{% endhint %}
|
||
|
||
Udhaifu katika usanidi wa Nginx unadhihirishwa na mfano hapa chini:
|
||
```
|
||
location / {
|
||
return 302 https://example.com$uri;
|
||
}
|
||
```
|
||
```
|
||
Wahusika \r (Carriage Return) na \n (Line Feed) hufafanua wahusika mpya wa mstari katika maombi ya HTTP, na fomu zao zilizo na URL-encoded hurejelezwa kama `%0d%0a`. Kujumuisha wahusika hawa katika ombi (k.m., `http://localhost/%0d%0aDetectify:%20clrf`) kwa seva iliyo na mipangilio mibovu husababisha seva kutoa kichwa kipya kilichoitwa `Detectify`. Hii hutokea kwa sababu ya kigezo $uri kudecode wahusika wa mstari walio na URL-encoded, ikisababisha kichwa cha kutarajia katika jibu:
|
||
```
|
||
```
|
||
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
|
||
```
|
||
Jifunze zaidi kuhusu hatari za CRLF injection na response splitting katika [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/).
|
||
|
||
Pia hii technique inaeleweka katika [**maongezi haya**](https://www.youtube.com/watch?v=gWQyWdZbdoY\&list=PL0xCSYnG\_iTtJe2V6PQqamBF73n7-f1Nr\&index=77) na mifano ya hatari na mbinu za kugundua. Kwa mfano, Ili kugundua hii hitilafu kutoka mtazamo wa blackbox unaweza kutumia maombi haya:
|
||
|
||
* `https://example.com/%20X` - Kila nambari ya HTTP
|
||
* `https://example.com/%20H` - 400 Ombi Batili
|
||
|
||
Endapo ina hitilafu, ya kwanza itarudi kama "X" ni njia yoyote ya HTTP na ya pili itarudi kosa kwani H si njia halali. Hivyo server itapokea kitu kama: `GET / H HTTP/1.1` na hii itasababisha kosa.
|
||
|
||
Mifano mingine ya kugundua itakuwa:
|
||
|
||
* `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Kila nambari ya HTTP
|
||
* `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Ombi Batili
|
||
|
||
Baadhi ya mazingira yaliyopatikana kuwa na hitilafu yalipresentiwa katika maongezi hayo:
|
||
|
||
* Tazama jinsi **`$uri`** inavyowekwa kama ilivyo kwenye URL ya mwisho
|
||
```
|
||
location ^~ /lite/api/ {
|
||
proxy_pass http://lite-backend$uri$is_args$args;
|
||
}
|
||
```
|
||
* Tafadhali angalia jinsi **`$uri`** ilivyo kwenye URL (wakati huu ndani ya parameter)
|
||
```
|
||
location ~ ^/dna/payment {
|
||
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
|
||
proxy_pass http://$back;
|
||
```
|
||
* Sasa katika AWS S3
|
||
```
|
||
location /s3/ {
|
||
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
|
||
}
|
||
```
|
||
### Kila kivinjari
|
||
|
||
Iligundulika kwamba **data iliyotolewa na mtumiaji** inaweza kutibiwa kama **kivinjari cha Nginx** chini ya hali fulani. Chanzo cha tabia hii bado ni cha kufichika kidogo, lakini sio nadra wala rahisi kuthibitisha. Kosa hili lilisisitizwa katika ripoti ya usalama kwenye HackerOne, ambayo inaweza kuonekana [hapa](https://hackerone.com/reports/370094). Uchunguzi zaidi wa ujumbe wa kosa ulisababisha kutambuliwa kwa kutokea kwake ndani ya [moduli ya kichujio cha SSI ya msimbo wa Nginx](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx\_http\_ssi\_filter\_module.c#L365), ikilenga Seva Upande wa Pili (SSI) kama chanzo cha msingi.
|
||
|
||
Kutambua **hii hitilafu ya usanidi**, amri ifuatayo inaweza kutekelezwa, ambayo inahusisha kuweka kichwa cha kurejelea ili kujaribu uchapishaji wa kivinjari:
|
||
```bash
|
||
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
|
||
```
|
||
Uchunguzi wa konfiga hii kwenye mifumo ulifunua visa vingi ambapo mchanganyiko wa Nginx ungeweza kuchapishwa na mtumiaji. Hata hivyo, kupungua kwa idadi ya visa vinavyoweza kudhuriwa kunadokeza kuwa juhudi za kusawazisha tatizo hili zimekuwa na mafanikio fulani.
|
||
|
||
## Kusoma jibu la nyuma la seva
|
||
|
||
Nginx inatoa kipengele kupitia `proxy_pass` kinachoruhusu kuingilia kati makosa na vichwa vya HTTP vilivyozalishwa na nyuma, lengo likiwa kuficha ujumbe wa makosa na vichwa vya ndani. Hii inafanikishwa na Nginx kutumikia kurasa za makosa za desturi kujibu makosa ya nyuma. Hata hivyo, changamoto huibuka wakati Nginx inakutana na ombi lisilo sahihi la HTTP. Ombi kama hilo hupokelewa kwa nyuma kama lilivyopokelewa, na jibu la nyuma la nyuma linatumwa moja kwa moja kwa mteja bila kuingilia kati kwa Nginx.
|
||
|
||
Zingatia mfano wa tukio linalohusisha programu ya uWSGI:
|
||
```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!"]
|
||
```
|
||
Kusimamia hili, maelekezo maalum katika usanidi wa Nginx hutumika:
|
||
```
|
||
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): Mwongozo huu unawezesha Nginx kutumikia jibu la desturi kwa majibu ya seva ya nyuma yenye nambari ya hali kubwa kuliko 300. Inahakikisha kwamba, kwa mfano wetu wa programu ya uWSGI, jibu la `Hitilafu ya 500` linazuiliwa na kusindikwa na Nginx.
|
||
* [**proxy\_hide\_header**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_hide\_header): Kama jina linavyopendekeza, mwongozo huu huficha vichwa vya HTTP vilivyotajwa kutoka kwa mteja, ikiboresha faragha na usalama.
|
||
|
||
Wakati ombi la `GET` halali linafanywa, Nginx hulisindika kawaida, likirudisha jibu la kosa la kawaida bila kufunua vichwa vya siri. Walakini, ombi lisilo sahihi la HTTP linapuuza mbinu hii, ikisababisha kufichuliwa kwa majibu ya seva ya nyuma moja kwa moja, ikiwa ni pamoja na vichwa vya siri na ujumbe wa hitilafu.
|
||
|
||
## merge\_slashes imewekwa kuwa off
|
||
|
||
Kwa chaguo-msingi, mwongozo wa **`merge_slashes` wa Nginx** umewekwa kuwa **`on`**, ambayo inapunguza mabano mengi ya mbele katika URL kuwa mabano moja. Kipengele hiki, wakati wa kusafisha usindikaji wa URL, inaweza kuficha kimakosa udhaifu katika programu zilizo nyuma ya Nginx, haswa zile zenye uwezekano wa mashambulizi ya kuingiza faili za ndani (LFI). Wataalamu wa usalama **Danny Robinson na Rotem Bar** wameonyesha hatari zinazowezekana zinazohusiana na tabia hii ya chaguo-msingi, haswa wakati Nginx inafanya kazi kama seva ya mbele.
|
||
|
||
Ili kupunguza hatari kama hizo, inapendekezwa **kugeuza mwongozo wa `merge_slashes` kuwa off** kwa programu zinazoweza kuathiriwa na udhaifu huu. Hii inahakikisha kwamba Nginx inapeleka maombi kwa programu bila kubadilisha muundo wa URL, hivyo kutoficha masuala yoyote ya usalama yanayoweza kuwepo.
|
||
|
||
Kwa maelezo zaidi angalia [Danny Robinson na Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).
|
||
|
||
### **Vichwa vya Majibu Yenye Madhara**
|
||
|
||
Kama inavyoonyeshwa katika [**hii andishi**](https://mizu.re/post/cors-playground), kuna vichwa fulani ambavyo ikiwa vipo katika jibu kutoka kwa seva ya wavuti vitabadilisha tabia ya proksi ya Nginx. Unaweza kuvichunguza [**katika nyaraka**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/):
|
||
|
||
* `X-Accel-Redirect`: Inaonyesha Nginx kuelekeza kwa ndani ombi kwa eneo lililospecifika.
|
||
* `X-Accel-Buffering`: Inadhibiti ikiwa Nginx inapaswa kubana jibu au la.
|
||
* `X-Accel-Charset`: Inaweka seti ya herufi kwa jibu wakati wa kutumia X-Accel-Redirect.
|
||
* `X-Accel-Expires`: Inaweka muda wa kumalizika kwa jibu wakati wa kutumia X-Accel-Redirect.
|
||
* `X-Accel-Limit-Rate`: Inapunguza kasi ya uhamisho kwa majibu wakati wa kutumia X-Accel-Redirect.
|
||
|
||
Kwa mfano, kichwa cha **`X-Accel-Redirect`** kitasababisha **uelekezaji wa ndani** katika nginx. Kwa hivyo kuwa na usanidi wa nginx na kitu kama **`root /`** na jibu kutoka kwa seva ya wavuti na **`X-Accel-Redirect: .env`** kutafanya nginx itume maudhui ya **`/.env`** (Uvamizi wa Njia).
|
||
|
||
### **Thamani ya Chaguo-msingi katika Mwongozo wa Ramani**
|
||
|
||
Katika **usanidi wa Nginx**, mwongozo wa `map` mara nyingi unacheza jukumu katika **udhibiti wa idhini**. Kosa la kawaida ni kutotaja **thamani ya chaguo-msingi**, ambayo inaweza kusababisha ufikiaji usioruhusiwa. Kwa mfano:
|
||
```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";
|
||
}
|
||
}
|
||
```
|
||
Bila `default`, **mtumiaji mwenye nia mbaya** anaweza kudukua usalama kwa kufikia **URI isiyoelezwa** ndani ya `/map-poc`. [Mwongozo wa Nginx](https://nginx.org/en/docs/http/ngx\_http\_map\_module.html) unapendekeza kuweka thamani ya **default** ili kuepuka matatizo kama hayo.
|
||
|
||
### **Ugumu wa Udukuzi wa DNS**
|
||
|
||
Udukuzi wa DNS dhidi ya Nginx unawezekana chini ya hali fulani. Ikiwa mshambuliaji anajua **seva ya DNS** inayotumiwa na Nginx na anaweza kuvuruga maswali yake ya DNS, wanaweza kudukua rekodi za DNS. Hata hivyo, njia hii haifanyi kazi ikiwa Nginx imeboreshwa kutumia **localhost (127.0.0.1)** kwa ufumbuzi wa DNS. Nginx inaruhusu kutaja seva ya DNS kama ifuatavyo:
|
||
```yaml
|
||
resolver 8.8.8.8;
|
||
```
|
||
### **`proxy_pass` na Maelekezo ya `internal`**
|
||
|
||
Maelekezo ya **`proxy_pass`** hutumiwa kwa kuelekeza maombi kwa seva nyingine, ndani au nje. Maelekezo ya **`internal`** hufanya uhakika kuwa maeneo fulani yanapatikana tu ndani ya Nginx. Ingawa maelekezo haya si udhaifu wenyewe, usanidi wao unahitaji uchunguzi wa makini ili kuzuia upungufu wa usalama.
|
||
|
||
## proxy\_set\_header Kuboresha & Uunganisho
|
||
|
||
Ikiwa seva ya nginx imeboreshwa kupitisha vichwa vya Kuboresha na Uunganisho, shambulio la [**h2c Smuggling**](../../pentesting-web/h2c-smuggling.md) linaweza kutekelezwa kufikia vituo vilivyolindwa/ndani.
|
||
|
||
{% hint style="danger" %}
|
||
Udhaifu huu ungeiruhusu mshambuliaji **kuanzisha uhusiano moja kwa moja na kituo cha `proxy_pass`** (`http://backend:9999` katika kesi hii) ambacho maudhui yake hayataangaliwa na nginx.
|
||
{% endhint %}
|
||
|
||
Mfano wa usanidi unaoweza kudhuriwa ili kuiba `/flag` kutoka [hapa](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" %}
|
||
Tafadhali kumbuka hata kama `proxy_pass` ilikuwa ikielekeza kwenye **njia** maalum kama vile `http://backend:9999/socket.io` uhusiano utaanzishwa na `http://backend:9999` hivyo unaweza **kuwasiliana na njia nyingine yoyote ndani ya kipande hicho cha mwisho. Kwa hivyo haifai ikiwa njia imetajwa kwenye URL ya proxy\_pass.**
|
||
{% endhint %}
|
||
|
||
## Jaribu mwenyewe
|
||
|
||
Detectify wameunda hazina ya GitHub ambapo unaweza kutumia Docker kuweka seva yako ya majaribio ya Nginx yenye kasoro na baadhi ya misconfigurations iliyozungumziwa katika makala hii na jaribu kuzipata mwenyewe!
|
||
|
||
[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)
|
||
|
||
## Zana za Uchambuzi wa Stetiki
|
||
|
||
### [GIXY](https://github.com/yandex/gixy)
|
||
|
||
Gixy ni zana ya kuchambua usanidi wa Nginx. Lengo kuu la Gixy ni kuzuia misconfigurations ya usalama na kugundua kasoro kiotomatiki.
|
||
|
||
### [Nginxpwner](https://github.com/stark0de/nginxpwner)
|
||
|
||
Nginxpwner ni zana rahisi ya kutafuta misconfigurations ya kawaida ya Nginx na mapungufu.
|
||
|
||
## Marejeleo
|
||
|
||
* [**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 (14) (1).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
**Usanidi uliopo mara moja kwa tathmini ya kasoro & upimaji wa uingiliaji**. Tekeleza pentest kamili kutoka popote na zana na vipengele zaidi ya 20 vinavyoanzia uchunguzi hadi ripoti. Hatuchukui nafasi ya pentesters - tunatengeneza zana za desturi, ugunduzi & moduli za uingiliaji ili kuwapa muda wa kuchimba kwa kina, kuvunja makompyuta, na kufurahi.
|
||
|
||
{% embed url="https://pentest-tools.com/" %}
|
||
|
||
<details>
|
||
|
||
<summary><strong>Jifunze kuhusu kudukua AWS kutoka mwanzo hadi shujaa na</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||
|
||
Njia nyingine za kusaidia HackTricks:
|
||
|
||
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
|
||
* Pata [**bidhaa rasmi za PEASS & HackTricks**](https://peass.creator-spring.com)
|
||
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) ya kipekee
|
||
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **fuata** sisi kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
||
</details>
|