8.2 KiB
Kuboresha Ujumbe wa Kichwa
Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!
Njia nyingine za kusaidia HackTricks:
- Ikiwa unataka kuona kampuni yako inayotangazwa katika HackTricks au kupakua HackTricks kwa PDF Angalia MPANGO WA KUJIUNGA!
- Pata swag rasmi ya PEASS & HackTricks
- Gundua Familia ya PEASS, mkusanyiko wetu wa kipekee wa NFTs
- Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
- Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.
Pata udhaifu unaowezekana zaidi ili uweze kuzirekebisha haraka. Intruder inafuatilia eneo lako la shambulio, inafanya uchunguzi wa vitisho wa kujitokeza, inapata masuala katika mfumo wako mzima wa teknolojia, kutoka kwa APIs hadi programu za wavuti na mifumo ya wingu. Jaribu bure leo.
{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}
Kuboresha Ujumbe wa Kichwa (H2C)
HTTP2 Juu ya Nakala Wazi (H2C)
H2C, au http2 juu ya nakala wazi, inatofautiana na kawaida ya uhusiano wa HTTP wa muda mfupi kwa kuboresha uhusiano wa HTTP wa kawaida kuwa wa kudumu. Uhusiano ulioboreshwa hutumia itifaki ya binary ya http2 kwa mawasiliano endelevu, tofauti na asili ya ombi moja la HTTP ya nakala wazi.
Shida ya kudukua inatokea wakati wa kutumia proxy ya kurudisha. Kawaida, proxy ya kurudisha huprocess na kupeleka maombi ya HTTP kwa seva ya nyuma, ikirudisha jibu la seva ya nyuma baada ya hapo. Walakini, wakati kichwa cha Connection: Upgrade
kipo katika ombi la HTTP (mara nyingi huonekana na uhusiano wa websocket), proxy ya kurudisha inadumisha uhusiano wa kudumu kati ya mteja na seva, kurahisisha kubadilishana endelevu inayohitajika na itifaki fulani. Kwa uhusiano wa H2C, kufuata RFC kunahitaji uwepo wa vichwa vitatu maalum:
Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings
Mkazo unatokea wakati, baada ya kuboresha uhusiano, wakala wa nyuma unakoma kusimamia maombi ya kibinafsi, ukidhani kazi yake ya kuelekeza imekamilika baada ya kuanzisha uhusiano. Kufaidika na H2C Smuggling kunaruhusu kuzunguka sheria za wakala wa nyuma zinazotumiwa wakati wa usindikaji wa ombi, kama vile kuelekeza kulingana na njia, uthibitishaji, na usindikaji wa WAF, ukidhani kuwa uhusiano wa H2C umefanikiwa kuanzishwa.
Wakala Dhaifu
Mkazo unategemea jinsi wakala wa nyuma unavyoshughulikia vichwa vya Upgrade
na mara nyingine Connection
. Wakala wa nyuma zifuatazo kwa asili hupeleka vichwa hivi wakati wa kupitisha wakala, hivyo kuwezesha H2C smuggling:
- HAProxy
- Traefik
- Nuster
Kwa upande mwingine, huduma hizi kwa asili hazipeleki vichwa vyote wakati wa kupitisha wakala. Walakini, zinaweza kuwekwa kwa njia isiyofaa, kuruhusu kupeleka bila kuchuja vichwa vya Upgrade
na Connection
:
- AWS ALB/CLB
- NGINX
- Apache
- Squid
- Varnish
- Kong
- Envoy
- Apache Traffic Server
Ufisadi
Ni muhimu kutambua kuwa seva zote hazipeleki vichwa vinavyohitajika kwa kuboresha uhusiano wa H2C kwa kufuata viwango. Kwa hivyo, seva kama AWS ALB/CLB, NGINX, na Apache Traffic Server, kati ya zingine, kwa asili zinazuia uhusiano wa H2C. Walakini, ni muhimu kujaribu na toleo lisilofuata viwango la Connection: Upgrade
, ambalo halijumuishi thamani ya HTTP2-Settings
kutoka kwa kichwa cha Connection
, kwani baadhi ya nyuma zinaweza kutofuata viwango.
{% hint style="danger" %}
Bila kujali njia maalum iliyotengwa katika URL ya proxy_pass
(kwa mfano, http://backend:9999/socket.io
), uhusiano ulioanzishwa unatumia chaguo-msingi http://backend:9999
. Hii inaruhusu mwingiliano na njia yoyote ndani ya kielelezo hicho cha ndani, kwa kutumia mbinu hii. Kwa hivyo, kutoweka kwa njia katika URL ya proxy_pass
haizuizi upatikanaji.
{% endhint %}
Zana h2csmuggler na BishopFox na h2csmuggler na assetnote hufanikisha jaribio la kuzunguka ulinzi uliowekwa na wakala kwa kuanzisha uhusiano wa H2C, hivyo kuruhusu upatikanaji wa rasilimali zilizolindwa na wakala.
Kwa habari zaidi kuhusu mkazo huu, haswa kuhusu NGINX, tazama rasilimali hii iliyodeta.
Websocket Smuggling
Websocket smuggling, tofauti na kujenga handaki ya HTTP2 kwa kielelezo kinachopatikana kupitia wakala, inaanzisha handaki ya Websocket ili kuzunguka vizuizi vya wakala na kurahisisha mawasiliano moja kwa moja na kielelezo.
Skenario 1
Katika skenario hili, mteja mbaya anayetaka kupata upatikanaji wa API ya REST ya ndani isiyopatikana anashambulia kielelezo cha nyuma kinachotoa API ya Websocket ya umma pamoja na API ya REST ya ndani isiyopatikana. Shambulio linatokea hatua kadhaa:
- Mteja anaanza kwa kutuma ombi la Kuboresha kwa wakala wa nyuma na toleo sahihi la itifaki ya
Sec-WebSocket-Version
katika kichwa. Wakala, kwa kutoshughulikia kichwa chaSec-WebSocket-Version
, anaamini ombi la Kuboresha ni sahihi na kulipeleka kwa kielelezo cha nyuma. - Kielelezo cha nyuma kinajibu na msimbo wa hali
426
, ukionyesha toleo lisilo sahihi la itifaki katika kichwa chaSec-WebSocket-Version
. Wakala wa nyuma, bila kuzingatia hali ya jibu la kielelezo cha nyuma, unaamini kuwa tayari kwa mawasiliano ya Websocket na kupeleka jibu kwa mteja. - Kwa hivyo, wakala wa nyuma unadanganywa kuamini kuwa kuna uhusiano wa Websocket ulioanzishwa kati ya mteja na kielelezo cha nyuma, wakati ukweli ni kwamba kielelezo cha nyuma kilikataa ombi la Kuboresha. Hata hivyo, wakala unadumisha uhusiano wa TCP au TLS wazi kati ya mteja na kielelezo cha nyuma, kuruhusu mteja kupata upatikanaji usiozuiliwa wa API ya REST ya faragha kupitia uhusiano huu.
Wakala wa nyuma walioathiriwa ni pamoja na Varnish, ambao hawakuchukua hatua kushughulikia suala hili, na wakala wa Envoy toleo 1.8.0 au chini, na toleo jipya limebadilisha mfumo wa kuboresha. Wakala wengine pia wanaweza kuwa hatarini.
Skenario 2
Skenario hili linahusisha kielelezo cha nyuma chenye API ya Websocket ya umma na API ya REST ya umma kwa ukaguzi wa afya, pamoja na API ya REST ya ndani isiyopatikana. Shambulio, lenye utata zaidi, linajumuisha hatua zifuatazo:
- Mteja anatuma ombi la POST kuanzisha ukaguzi wa afya API, likijumuisha kichwa cha HTTP cha ziada
Upgrade: websocket
. NGINX, ikifanya kazi kama wakala wa nyuma, inaona hii kama ombi la Kuboresha la kawaida kwa msingi wa kichwa chaUpgrade
pekee, ikipuuza vipengele vingine vya ombi, na kulipeleka kwa kielelezo cha nyuma. - Kielelezo cha nyuma kinatekeleza ukaguzi wa afya API, kufikia rasilimali ya nje inayodhibitiwa na mshambuliaji ambayo inarudisha jibu la HTTP lenye msimbo wa hali
101
. Jibu hili, mara tu linapopokelewa na kielelezo cha nyuma na kupelekwa kwa NGINX, linadanganya wakala kuamini kuwa uhusiano wa Websocket umewekwa kutokana na uthibitisho wake wa msimbo wa hali pekee.
Onyo: Utata wa mbinu hii