Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Mizani ya Kushiriki Rasilimali za Mikoa Mbalimbali (CORS) **inawawezesha seva kufafanua ni nani anaweza kufikia mali zao** na **ni njia zipi za ombi la HTTP zinazoruhusiwa** kutoka vyanzo vya nje.
Sera ya **same-origin** inahitaji kwamba **seva inayotaka** rasilimali na seva inayohifadhi **rasilimali** zishiriki itifaki sawa (mfano, `http://`), jina la kikoa (mfano, `internal-web.com`), na **bandari** (mfano, 80). Chini ya sera hii, ni kurasa za wavuti kutoka kikoa na bandari sawa pekee ndizo zinazoruhusiwa kufikia rasilimali hizo.
Header hii inaweza kuruhusu **mikoa mingi**, thamani ya **`null`**, au wildcards **`*`**. Hata hivyo, **hakuna kivinjari kinachounga mkono mikoa mingi**, na matumizi ya wildcard `*` yanakabiliwa na **mipaka**. (Wildcard lazima itumike peke yake, na matumizi yake pamoja na `Access-Control-Allow-Credentials: true` hayaruhusiwi.)
Header hii **inatolewa na seva** kama jibu la ombi la rasilimali ya mikoa tofauti lililoanzishwa na tovuti, huku kivinjari kikiongeza kiotomatiki header ya `Origin`.
Kwa **kawaida**, maombi ya mikoa tofauti yanafanywa bila akidi kama vile vidakuzi au header ya Uidhinishaji. Hata hivyo, seva ya mikoa tofauti inaweza kuruhusu kusoma jibu wakati akidi zinatumwa kwa kuweka header ya `Access-Control-Allow-Credentials` kuwa **`true`**.
Wakati wa kuanzisha ombi la kuvuka eneo chini ya hali maalum, kama vile kutumia **mbinu isiyo ya kawaida ya HTTP** (chochote isipokuwa HEAD, GET, POST), kuanzisha **vichwa** vipya, au kutumia **thamani maalum ya kichwa cha Content-Type**, ombi la awali linaweza kuhitajika. Ombi hili la awali, linalotumia mbinu ya **`OPTIONS`**, linatumika kuarifu seva kuhusu nia za ombi la kuvuka eneo linalokuja, ikiwa ni pamoja na mbinu za HTTP na vichwa inavyokusudia kutumia.
Itifaki ya **Cross-Origin Resource Sharing (CORS)** inahitaji ukaguzi huu wa awali ili kubaini uwezekano wa operesheni ya kuvuka eneo iliyohitajika kwa kuthibitisha mbinu, vichwa, na uaminifu wa chanzo. Kwa ufahamu wa kina wa hali zipi zinazoepusha hitaji la ombi la awali, rejelea mwongozo wa kina ulioandikwa na [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests).
Ni muhimu kutambua kwamba **ukosefu wa ombi la awali hauondoi hitaji la jibu kubeba vichwa vya idhini**. Bila vichwa hivi, kivinjari hakiwezi kushughulikia jibu kutoka kwa ombi la kuvuka eneo.
Katika majibu, seva inaweza kurudisha vichwa vinavyoashiria mbinu zilizokubaliwa, asili iliyoruhusiwa, na maelezo mengine ya sera ya CORS, kama inavyoonyeshwa hapa chini:
* **`Access-Control-Allow-Headers`**: Kichwa hiki kinaeleza ni vichwa gani vinaweza kutumika wakati wa ombi halisi. Kimewekwa na seva kuashiria vichwa vinavyoruhusiwa katika maombi kutoka kwa mteja.
* **`Access-Control-Expose-Headers`**: Kupitia kichwa hiki, seva inamjulisha mteja ni vichwa gani vinaweza kufichuliwa kama sehemu ya jibu mbali na vichwa vya jibu rahisi.
* **`Access-Control-Max-Age`**: Kichwa hiki kinaonyesha ni muda gani matokeo ya ombi la pre-flight yanaweza kuhifadhiwa. Seva inaweka muda wa juu, kwa sekunde, ambao taarifa iliyorejeshwa na ombi la pre-flight inaweza kutumika tena.
* **`Access-Control-Request-Headers`**: Inayotumika katika maombi ya pre-flight, kichwa hiki kimewekwa na mteja kuijulisha seva ni vichwa gani vya HTTP ambavyo mteja anataka kutumia katika ombi halisi.
* **`Access-Control-Request-Method`**: Kichwa hiki, pia kinachotumika katika maombi ya pre-flight, kimewekwa na mteja kuashiria ni njia gani ya HTTP itakayokuwa ikitumika katika ombi halisi.
* **`Origin`**: Kichwa hiki kimewekwa kiotomatiki na kivinjari na kinaonyesha asili ya ombi la cross-origin. Kinatumika na seva kutathmini ikiwa ombi linalokuja linapaswa kuruhusiwa au kukataliwa kulingana na sera ya CORS.
Kumbuka kwamba kawaida (kutegemea aina ya maudhui na vichwa vilivyowekwa) katika **ombio la GET/POST hakuna ombi la pre-flight linalotumwa** (ombio linatumwa **moja kwa moja**), lakini ikiwa unataka kufikia **vichwa/mwili wa jibu**, lazima iwe na kichwa _Access-Control-Allow-Origin_ kinachoruhusu.\
**Hivyo, CORS hailindi dhidi ya CSRF (lakini inaweza kuwa na manufaa).**
1.**`Access-Control-Request-Local-Network`**: Kichwa hiki kimejumuishwa katika ombi la mteja kuashiria kwamba uchunguzi unalenga rasilimali ya mtandao wa ndani. Kinatumika kama alama kuijulisha seva kwamba ombi linatoka ndani ya mtandao wa ndani.
2.**`Access-Control-Allow-Local-Network`**: Katika majibu, seva zinatumia kichwa hiki kuwasiliana kwamba rasilimali iliyohitajika inaruhusiwa kushirikiwa na vyombo vya nje ya mtandao wa ndani. Kinatumika kama mwanga wa kijani kwa kushiriki rasilimali kati ya mipaka tofauti ya mtandao, kuhakikisha ufikiaji ulio na udhibiti huku ukihifadhi itifaki za usalama.
Kumbuka kwamba IP ya linux **0.0.0.0** inafanya kazi ili **kuepuka** mahitaji haya ya kufikia localhost kwani anwani hiyo ya IP haichukuliwi kuwa "ya ndani".
Pia inawezekana **kuepuka mahitaji ya Mtandao wa Ndani** ikiwa utatumia **anwani ya IP ya umma ya mwisho wa ndani** (kama anwani ya IP ya umma ya router). Kwa sababu katika matukio kadhaa, hata kama **IP ya umma** inafikiwa, ikiwa ni **kutoka kwenye mtandao wa ndani**, ufikiaji utawezesha.
Imeonekana kwamba kuweka `Access-Control-Allow-Credentials` kuwa **`true`** ni sharti la awali kwa mashambulizi mengi **halisi**. Kuweka hii kunaruhusu kivinjari kutuma akidi na kusoma jibu, kuimarisha ufanisi wa shambulizi. Bila hii, faida ya kufanya kivinjari kutoa ombi badala ya kufanya hivyo mwenyewe inapungua, kwani kutumia vidakuzi vya mtumiaji inakuwa vigumu.
Kuna tofauti ambapo mahali pa mtandao wa mwathirika hutenda kama aina ya uthibitisho. Hii inaruhusu kivinjari cha mwathirika kutumika kama proxy, kuzunguka uthibitisho wa IP ili kufikia programu za intranet. Njia hii ina fanana katika athari na DNS rebinding lakini ni rahisi kutekeleza.
Hali halisi ambapo thamani ya kichwa cha `Origin` inarefushwa katika `Access-Control-Allow-Origin` ni ya nadharia isiyowezekana kutokana na vizuizi vya kuunganisha vichwa hivi. Hata hivyo, waendelezaji wanaotafuta kuwezesha CORS kwa URL nyingi wanaweza kuunda kwa dinamik `Access-Control-Allow-Origin` kichwa kwa kunakili thamani ya kichwa cha `Origin`. Njia hii inaweza kuleta udhaifu, hasa wakati mshambuliaji anatumia kikoa chenye jina kilichoundwa kuonekana kuwa halali, hivyo kudanganya mantiki ya uthibitishaji.
`null` origin, iliyoainishwa kwa hali kama vile redirects au faili za HTML za ndani, ina nafasi ya kipekee. Programu zingine zinaweka orodha ya kuruhusiwa kwa origin hii ili kuwezesha maendeleo ya ndani, bila kukusudia ikiruhusu tovuti yoyote kuiga `null` origin kupitia iframe iliyo sanduku, hivyo kupita vizuizi vya CORS.
Wakati wa kukutana na orodha ya maeneo yaliyoruhusiwa, ni muhimu kujaribu fursa za kupita, kama kuongeza eneo la mshambuliaji kwenye eneo lililoruhusiwa au kutumia udhaifu wa kuchukua subdomain. Zaidi ya hayo, matumizi ya mifumo ya kawaida kwa ajili ya uthibitishaji wa maeneo yanaweza kupuuzilia mbali tofauti katika kanuni za kutaja maeneo, na kutoa fursa zaidi za kupita.
Mifumo ya Regex kawaida inazingatia wahusika wa alphanumeric, nukta (.), na alama za kuunganisha (-), ikipuuzilia mbali uwezekano mwingine. Kwa mfano, jina la eneo lililotengenezwa ili kujumuisha wahusika wanaotafsiriwa tofauti na vivinjari na mifumo ya regex linaweza kupita ukaguzi wa usalama. Utunzaji wa wahusika wa alama ya chini katika subdomains na Safari, Chrome, na Firefox unaonyesha jinsi tofauti hizo zinaweza kutumika ili kuzunguka mantiki ya uthibitishaji wa maeneo.
**Kwa maelezo zaidi na mipangilio ya ukaguzi huu wa kupita:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **na** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)
Wakuu wa programu mara nyingi wanaweka mifumo ya kujihami ili kulinda dhidi ya matumizi mabaya ya CORS kwa kuorodhesha maeneo ambayo yanaruhusiwa kuomba taarifa. Licha ya tahadhari hizi, usalama wa mfumo si wa kuaminika kabisa. Uwepo wa subdomain moja tu yenye udhaifu ndani ya maeneo yaliyoruhusiwa unaweza kufungua mlango wa matumizi mabaya ya CORS kupitia udhaifu mwingine, kama vile XSS (Cross-Site Scripting).
Ili kuonyesha, fikiria hali ambapo eneo, `requester.com`, limeorodheshwa ili kufikia rasilimali kutoka eneo lingine, `provider.com`. Mipangilio ya upande wa seva inaweza kuonekana kama ifuatavyo:
Katika mpangilio huu, subdomain zote za `requester.com` zinaruhusiwa kupata. Hata hivyo, ikiwa subdomain, sema `sub.requester.com`, imeathiriwa na udhaifu wa XSS, mshambuliaji anaweza kutumia udhaifu huu. Kwa mfano, mshambuliaji mwenye ufikiaji wa `sub.requester.com` anaweza kutumia udhaifu wa XSS ili kupita sera za CORS na kwa uovu kufikia rasilimali kwenye `provider.com`.
Inawezekana kwamba kwa kutumia uchafuzi wa cache upande wa seva kupitia sindano ya kichwa cha HTTP, udhaifu wa Cross-Site Scripting (XSS) unaweza kuanzishwa. Hali hii inatokea wakati programu inashindwa kusafisha kichwa cha `Origin` kwa wahusika haramu, ikisababisha udhaifu hasa kwa watumiaji wa Internet Explorer na Edge. Mablua haya yanachukulia (0x0d) kama mkataba halali wa kichwa cha HTTP, na kusababisha udhaifu wa sindano ya kichwa cha HTTP.
While directly exploiting this vulnerability by making a web browser send a malformed header is not feasible, a crafted request can be manually generated using tools like Burp Suite. This method could lead to a server-side cache saving the response and inadvertently serving it to others. The crafted payload aims to alter the page's character set to UTF-7, a character encoding often associated with XSS vulnerabilities due to its ability to encode characters in a way that can be executed as script in certain contexts.
**Note**: The exploitation of HTTP header injection vulnerabilities, particularly through server-side cache poisoning, underscores the critical importance of validating and sanitizing all user-supplied input, including HTTP headers. Always employ a robust security model that includes input validation to prevent such vulnerabilities.
Katika hali hii, mfano wa ukurasa wa wavuti unaonyesha maudhui ya kichwa cha HTTP cha kawaida bila uandishi sahihi unakabiliwa. Kwa usahihi, ukurasa wa wavuti unarudisha maudhui yaliyojumuishwa katika kichwa cha `X-User-id`, ambacho kinaweza kujumuisha JavaScript mbaya, kama inavyoonyeshwa na mfano ambapo kichwa kina tag ya picha ya SVG iliyoundwa kutekeleza msimbo wa JavaScript wakati wa kupakia.
Sera za Cross-Origin Resource Sharing (CORS) zinaruhusu kutumwa kwa vichwa vya kawaida. Hata hivyo, bila jibu kutolewa moja kwa moja na kivinjari kutokana na vizuizi vya CORS, matumizi ya sindano kama hiyo yanaweza kuonekana kuwa na mipaka. Kitu muhimu kinatokea wakati wa kuzingatia tabia ya cache ya kivinjari. Ikiwa kichwa cha `Vary: Origin` hakijabainishwa, inakuwa inawezekana kwa jibu mbaya kuhifadhiwa na kivinjari. Baadaye, jibu hili lililohifadhiwa linaweza kuonyeshwa moja kwa moja wakati wa kuhamasisha URL, kupita hitaji la uonyeshaji wa moja kwa moja wakati wa ombi la awali. Mekanismu hii inaboresha uaminifu wa shambulio kwa kutumia caching upande wa mteja.
Ili kuonyesha shambulio hili, mfano wa JavaScript unapatikana, ulioandaliwa kutekelezwa katika mazingira ya ukurasa wa wavuti, kama kupitia JSFiddle. Skripti hii inafanya kitendo rahisi: inatuma ombi kwa URL maalum yenye kichwa cha kawaida kinachojumuisha JavaScript mbaya. Baada ya kukamilika kwa ombi kwa mafanikio, inajaribu kuhamasisha URL ya lengo, huenda ikasababisha utekelezaji wa skripti iliyosambazwa ikiwa jibu limehifadhiwa bila kushughulikia ipasavyo kichwa cha `Vary: Origin`.
XSSI, pia inajulikana kama Cross-Site Script Inclusion, ni aina ya udhaifu inayotumia ukweli kwamba Sera ya Asili Moja (SOP) haitumiki wakati wa kujumuisha rasilimali kwa kutumia lebo ya script. Hii ni kwa sababu scripts zinahitaji kuweza kujumuishwa kutoka kwa maeneo tofauti. Udhaifu huu unaruhusu mshambuliaji kufikia na kusoma maudhui yoyote ambayo yalijumuishwa kwa kutumia lebo ya script.
Udhaifu huu unakuwa muhimu hasa inapohusiana na JavaScript ya dinamik au JSONP (JSON na Padding), hasa wakati taarifa za mamlaka ya mazingira kama vile vidakuzi zinapotumika kwa uthibitishaji. Wakati wa kuomba rasilimali kutoka kwa mwenyeji tofauti, vidakuzi vinajumuishwa, na kuwafanya waweze kupatikana kwa mshambuliaji.
Ili kuelewa na kupunguza udhaifu huu, unaweza kutumia plugin ya BurpSuite inayopatikana kwenye [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp). Plugin hii inaweza kusaidia kubaini na kushughulikia udhaifu wa XSSI katika programu zako za wavuti.
Jaribu kuongeza **`callback`** **parameter** katika ombi. Huenda ukurasa ulikuwa umeandaliwa kutuma data kama JSONP. Katika kesi hiyo, ukurasa utarudisha data na `Content-Type: application/javascript` ambayo itapita sera ya CORS.
Njia moja ya kupita kizuizi cha `Access-Control-Allow-Origin` ni kwa kuomba programu ya wavuti kufanya ombi kwa niaba yako na kutuma majibu nyuma. Hata hivyo, katika hali hii, akidi za mwathirika wa mwisho hazitapelekwa kwani ombi linafanywa kwa eneo tofauti.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Chombo hiki kinatoa proxy inayosambaza ombi lako pamoja na vichwa vyake, huku pia ikidanganya kichwa cha Asili ili kufanana na eneo lililoombwa. Hii kwa ufanisi inapita sera ya CORS. Hapa kuna mfano wa matumizi na XMLHttpRequest:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Chombo hiki kinatoa njia mbadala ya kupitisha maombi. Badala ya kupitisha ombi lako kama lilivyo, seva inafanya ombi lake mwenyewe kwa vigezo vilivyotolewa.
Unaweza **kupita ukaguzi wa CORS** kama `e.origin === window.origin` kwa **kuunda iframe** na **kutoka kwake kufungua dirisha jipya**. Maelezo zaidi katika ukurasa ufuatao:
1. Mshambuliaji anaunda ukurasa wa wavuti na kumfanya mwathirika aupate.
2. Mshambuliaji kisha anabadilisha DNS (IP) ya eneo lake mwenyewe ili kuelekeza kwenye ukurasa wa wavuti wa mwathirika.
3. Kivinjari cha mwathirika kinahifadhi jibu la DNS, ambalo linaweza kuwa na thamani ya TTL (Muda wa Kuishi) ikionyesha ni muda gani rekodi ya DNS inapaswa kuzingatiwa kuwa halali.
4. Wakati TTL inapoisha, kivinjari cha mwathirika kinafanya ombi jipya la DNS, kuruhusu mshambuliaji kutekeleza msimbo wa JavaScript kwenye ukurasa wa mwathirika.
5. Kwa kudumisha udhibiti juu ya IP ya mwathirika, mshambuliaji anaweza kukusanya taarifa kutoka kwa mwathirika bila kutuma vidakuzi vyovyote kwa seva ya mwathirika.
DNS rebinding inaweza kuwa na manufaa kwa kupita ukaguzi wa IP wazi unaofanywa na mwathirika au kwa hali ambapo mtumiaji au bot inabaki kwenye ukurasa mmoja kwa muda mrefu, kuruhusu cache kuisha.
Ikiwa unahitaji njia ya haraka ya kutumia DNS rebinding, unaweza kutumia huduma kama [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html).
Ili kuendesha seva yako ya DNS rebinding, unaweza kutumia zana kama **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)). Hii inahusisha kufichua bandari yako ya ndani 53/udp, kuunda rekodi ya A inayotaja hiyo (mfano, ns.example.com), na kuunda rekodi ya NS inayotaja subdomain ya A iliyoundwa hapo awali (mfano, ns.example.com). Subdomain yoyote ya subdomain ya ns.example.com itatatuliwa na mwenyeji wako.
Unaweza pia kuchunguza seva inayofanya kazi hadharani kwenye [http://rebind.it/singularity.html](http://rebind.it/singularity.html) kwa ufahamu zaidi na majaribio.
DNS rebinding kupitia mafuriko ya cache ya DNS ni mbinu nyingine inayotumiwa kupita mfumo wa kuhifadhi wa vivinjari na kulazimisha ombi la pili la DNS. Hapa kuna jinsi inavyofanya kazi:
1. Kwanza, wakati mwathirika anafanya ombi la DNS, linajibiwa kwa anwani ya IP ya mshambuliaji.
2. Ili kupita ulinzi wa kuhifadhi, mshambuliaji anatumia mfanyakazi wa huduma. Mfanyakazi wa huduma anafurika cache ya DNS, ambayo kwa ufanisi inafuta jina la seva ya mshambuliaji lililohifadhiwa.
3. Wakati kivinjari cha mwathirika kinapofanya ombi la pili la DNS, sasa kinajibiwa kwa anwani ya IP 127.0.0.1, ambayo kwa kawaida inarejelea localhost.
Kwa kufurika cache ya DNS na mfanyakazi wa huduma, mshambuliaji anaweza kudhibiti mchakato wa kutatua DNS na kulazimisha kivinjari cha mwathirika kufanya ombi la pili, wakati huu likitatuliwa kwa anwani ya IP inayotakiwa na mshambuliaji.
Njia nyingine ya kupita ulinzi wa kuhifadhi ni kwa kutumia anwani nyingi za IP kwa subdomain moja katika mtoa huduma wa DNS. Hapa kuna jinsi inavyofanya kazi:
1. Mshambuliaji anaunda rekodi mbili za A (au rekodi moja ya A yenye anwani mbili za IP) kwa subdomain moja katika mtoa huduma wa DNS.
2. Wakati kivinjari kinapokagua rekodi hizi, kinapata anwani zote mbili za IP.
3. Ikiwa kivinjari kitachagua kutumia anwani ya IP ya mshambuliaji kwanza, mshambuliaji anaweza kutoa payload inayofanya maombi ya HTTP kwa eneo hilo hilo.
4. Hata hivyo, mara mshambuliaji anapopata anwani ya IP ya mwathirika, wanakoma kujibu kivinjari cha mwathirika.
5. Kivinjari cha mwathirika, kinapogundua kwamba eneo halijibu, kinahamia kutumia anwani ya pili ya IP iliyotolewa.
6. Kwa kufikia anwani ya pili ya IP, kivinjari kinapita Sera ya Asili Moja (SOP), kuruhusu mshambuliaji kutumia hii na kukusanya na kuhamasisha taarifa.
Mbinu hii inatumia tabia ya vivinjari wakati anwani nyingi za IP zinatolewa kwa eneo. Kwa kudhibiti kwa makusudi majibu na kudhibiti uchaguzi wa anwani ya IP ya kivinjari, mshambuliaji anaweza kutumia SOP na kufikia taarifa kutoka kwa mwathirika.
Kumbuka kwamba ili kufikia localhost unapaswa kujaribu kuunganisha **127.0.0.1** katika Windows na **0.0.0.0** katika linux.\
Watoa huduma kama godaddy au cloudflare hawakuniruhusu kutumia ip 0.0.0.0, lakini AWS route53 iliniruhusu kuunda rekodi moja ya A yenye anwani 2 ambapo moja yao ni "0.0.0.0"
Unaweza kupata maelezo zaidi kuhusu mbinu za kupita zilizotajwa hapo awali na jinsi ya kutumia chombo kinachofuata katika mazungumzo [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ).
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) ni chombo cha kufanya [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding) mashambulizi. Inajumuisha vipengele muhimu vya kuunganisha anwani ya IP ya jina la seva ya shambulizi na anwani ya IP ya mashine lengwa na kutoa payloads za shambulizi ili kutumia programu dhaifu kwenye mashine lengwa.
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Pendekezo la kutuma ombi la awali kila wakati wakati seva za umma zinataka kufikia seva za ndani
Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
