Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception/README.md

271 lines
21 KiB
Markdown
Raw Blame History

# Cache Poisoning en Cache Deception
{% hint style="success" %}
Leer & oefen AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Leer & oefen GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Ondersteun HackTricks</summary>
* Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)!
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
{% endhint %}
<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
\
Gebruik [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=cache-deception) om maklik te bou en **werkvloei te outomatiseer** wat deur die wêreld se **mees gevorderde** gemeenskap gereedskap aangedryf word.\
Kry Toegang Vandag:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
## Die verskil
> **Wat is die verskil tussen web cache poisoning en web cache deception?**
>
> * In **web cache poisoning** veroorsaak die aanvaller dat die aansoek 'n paar kwaadwillige inhoud in die cache stoor, en hierdie inhoud word vanaf die cache aan ander aansoekgebruikers bedien.
> * In **web cache deception** veroorsaak die aanvaller dat die aansoek 'n paar sensitiewe inhoud wat aan 'n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.
## Cache Poisoning
Cache poisoning is daarop gemik om die kliënt-kant cache te manipuleer om kliënte te dwing om hulpbronne te laai wat onverwags, gedeeltelik, of onder die beheer van 'n aanvaller is. Die omvang van die impak hang af van die gewildheid van die aangetaste bladsy, aangesien die besmette antwoord eksklusief aan gebruikers wat die bladsy besoek tydens die periode van cache besoedeling bedien word.
Die uitvoering van 'n cache poisoning aanval behels verskeie stappe:
1. **Identifikasie van Ongekykte Insette**: Dit is parameters wat, alhoewel nie vereis word vir 'n versoek om in die cache gestoor te word nie, die antwoord wat deur die bediener teruggestuur word, kan verander. Die identifikasie van hierdie insette is van kardinale belang aangesien dit benut kan word om die cache te manipuleer.
2. **Eksploitatie van die Ongekykte Insette**: Na die identifikasie van die ongekykte insette, behels die volgende stap om uit te vind hoe om hierdie parameters te misbruik om die bediener se antwoord op 'n manier te verander wat die aanvaller bevoordeel.
3. **Verseker dat die Besmette Antwoord in die Cache Gestoor Word**: Die finale stap is om te verseker dat die gemanipuleerde antwoord in die cache gestoor word. Op hierdie manier sal enige gebruiker wat toegang tot die aangetaste bladsy verkry terwyl die cache besoedel is, die besmette antwoord ontvang.
### Ontdekking: Kontroleer HTTP koptekste
Gewoonlik, wanneer 'n antwoord **in die cache gestoor is**, sal daar 'n **kopteks wees wat dit aandui**, jy kan kyk watter koptekste jy op hierdie pos moet let: [**HTTP Cache koptekste**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Ontdekking: Cache foutkodes
As jy dink dat die antwoord in 'n cache gestoor word, kan jy probeer om **versoeke met 'n slegte kopteks te stuur**, wat met 'n **statuskode 400** beantwoord moet word. Probeer dan om die versoek normaal te benader en as die **antwoord 'n 400 statuskode is**, weet jy dit is kwesbaar (en jy kan selfs 'n DoS uitvoer).
Jy kan meer opsies vind in:
{% content-ref url="cache-poisoning-to-dos.md" %}
[cache-poisoning-to-dos.md](cache-poisoning-to-dos.md)
{% endcontent-ref %}
Let egter daarop dat **soms hierdie soort statuskodes nie in die cache gestoor word nie**, so hierdie toets mag nie betroubaar wees nie.
### Ontdekking: Identifiseer en evalueer ongekykte insette
Jy kan [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) gebruik om **parameters en koptekste te brute-force** wat moontlik die **antwoord van die bladsy verander**. Byvoorbeeld, 'n bladsy mag die kopteks `X-Forwarded-For` gebruik om die kliënt aan te dui om die skrip van daar te laai:
```markup
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Ontlok 'n skadelike reaksie van die agtergrondbediener
Met die parameter/kop wat geïdentifiseer is, kyk hoe dit **gesanitiseer** word en **waar** dit **reflekteer** of die reaksie van die kop beïnvloed. Kan jy dit op enige manier misbruik (voer 'n XSS uit of laai 'n JS-kode wat deur jou beheer word? voer 'n DoS uit?...)
### Kry die reaksie in die cache
Sodra jy die **bladsy** geïdentifiseer het wat misbruik kan word, watter **parameter**/**kop** om te gebruik en **hoe** om dit te **misbruik**, moet jy die bladsy in die cache kry. Afhangende van die hulpbron wat jy probeer om in die cache te kry, kan dit 'n rukkie neem, jy mag dalk vir verskeie sekondes moet probeer.
Die kop **`X-Cache`** in die reaksie kan baie nuttig wees, aangesien dit die waarde **`miss`** kan hê wanneer die versoek nie in die cache was nie en die waarde **`hit`** wanneer dit in die cache is.\
Die kop **`Cache-Control`** is ook interessant om te weet of 'n hulpbron in die cache gestoor word en wanneer die volgende keer die hulpbron weer in die cache gestoor sal word: `Cache-Control: public, max-age=1800`
Nog 'n interessante kop is **`Vary`**. Hierdie kop word dikwels gebruik om **addisionele koppe aan te dui** wat as **deel van die cache-sleutel** behandel word, selfs al is hulle normaalweg nie gesleutel nie. Daarom, as die gebruiker die `User-Agent` van die slagoffer wat hy teiken, ken, kan hy die cache vir die gebruikers wat daardie spesifieke `User-Agent` gebruik, vergiftig.
Een meer kop wat met die cache verband hou, is **`Age`**. Dit definieer die tyd in sekondes wat die objek in die proxy-cache was.
Wanneer jy 'n versoek in die cache stoor, wees **versigtig met die koppe wat jy gebruik** omdat sommige daarvan **onverwagte** as **gesleuteld** gebruik kan word en die **slagoffer sal daardie selfde kop moet gebruik**. Toets altyd 'n Cache Poisoning met **verskillende blaaiers** om te kyk of dit werk.
## Exploiteringsvoorbeelde
### Eenvoudigste voorbeeld
'n Kop soos `X-Forwarded-For` word ongesanitiseer in die reaksie gereflekteer.\
Jy kan 'n basiese XSS-payload stuur en die cache vergiftig sodat almal wat die bladsy benader, XSS sal ervaar:
```markup
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Note dat dit 'n versoek na `/en?region=uk` sal vergiftig en nie na `/en` nie_
### Cache vergiftiging om DoS
{% content-ref url="cache-poisoning-to-dos.md" %}
[cache-poisoning-to-dos.md](cache-poisoning-to-dos.md)
{% endcontent-ref %}
### Gebruik van web cache vergiftiging om koekie-hantering kwesbaarhede te benut
Koekies kan ook op die antwoord van 'n bladsy weerspieël word. As jy dit kan misbruik om 'n XSS te veroorsaak, kan jy in staat wees om XSS in verskeie kliënte te benut wat die kwaadwillige cache antwoord laai.
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Let daarop dat as die kwesbare koekie baie deur die gebruikers gebruik word, gereelde versoeke die cache sal skoonmaak.
### Generering van verskille met afdelings, normalisering en punte <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Kontroleer:
{% content-ref url="cache-poisoning-via-url-discrepancies.md" %}
[cache-poisoning-via-url-discrepancies.md](cache-poisoning-via-url-discrepancies.md)
{% endcontent-ref %}
### Cache vergiftiging met pad traversering om API-sleutel te steel <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Hierdie skrywe verduidelik**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) hoe dit moontlik was om 'n OpenAI API-sleutel te steel met 'n URL soos `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` omdat enigiets wat pas by `/share/*` in die cache gestoor sal word sonder dat Cloudflare die URL normaliseer, wat gedoen is toe die versoek die webbediener bereik het.
Dit word ook beter verduidelik in:
{% content-ref url="cache-poisoning-via-url-discrepancies.md" %}
[cache-poisoning-via-url-discrepancies.md](cache-poisoning-via-url-discrepancies.md)
{% endcontent-ref %}
### Gebruik van verskeie koptekste om web cache vergiftiging kwesbaarhede te benut <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Soms sal jy **verskeie ongekeyde insette** moet **benut** om 'n cache te kan misbruik. Byvoorbeeld, jy mag 'n **Open redirect** vind as jy `X-Forwarded-Host` na 'n domein wat deur jou beheer word en `X-Forwarded-Scheme` na `http` stel. **As** die **bediener** al die **HTTP** versoeke **na HTTPS** **stuur** en die koptekst `X-Forwarded-Scheme` as die domeinnaam vir die omleiding gebruik. Jy kan beheer waar die bladsy deur die omleiding gewys word.
```markup
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
```
### Exploiting with limited `Vary`header
As jy gevind het dat die **`X-Host`** header gebruik word as **domeinnaam om 'n JS hulpbron te laai** maar die **`Vary`** header in die antwoord dui op **`User-Agent`**. Dan moet jy 'n manier vind om die User-Agent van die slagoffer te exfiltreer en die cache te vergiftig met daardie gebruikersagent:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Fat Get
Stuur 'n GET-versoek met die versoek in die URL en in die liggaam. As die webbediener die een uit die liggaam gebruik, maar die kasbediener die een uit die URL kas, sal enigiemand wat daardie URL benader, eintlik die parameter uit die liggaam gebruik. Soos die kwesbaarheid wat James Kettle op die Github-webwerf gevind het:
```
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](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
### Parameter Cloacking
Byvoorbeeld, dit is moontlik om **parameters** in ruby bedieners te skei deur die karakter **`;`** te gebruik in plaas van **`&`**. Dit kan gebruik word om ongekeyde parameterwaardes binne gekeyde te plaas en dit te misbruik.
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](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
Leer hier oor hoe om [Cache Poisoning-aanvalle uit te voer deur HTTP Request Smuggling te misbruik](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Automated testing for Web Cache Poisoning
Die [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) kan gebruik word om outomaties vir web cache poisoning te toets. Dit ondersteun baie verskillende tegnieke en is hoogs aanpasbaar.
Voorbeeld gebruik: `wcvs -u example.com`
## Vulnerable Examples
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS het die fragment binne die URL deurgegee sonder om dit te verwyder en het die cache-sleutel slegs met die gasheer, pad en navraag gegenereer (wat die fragment geïgnoreer het). So die versoek `/#/../?r=javascript:alert(1)` is na die agterkant gestuur as `/#/../?r=javascript:alert(1)` en die cache-sleutel het nie die payload daarin gehad nie, slegs gasheer, pad en navraag.
### GitHub CP-DoS
Die stuur van 'n slegte waarde in die content-type kop het 'n 405 gecacheerde antwoord geaktiveer. Die cache-sleutel het die koekie bevat, so dit was moontlik om slegs ongeauthentiseerde gebruikers aan te val.
### GitLab + GCP CP-DoS
GitLab gebruik GCP-buckets om statiese inhoud te stoor. **GCP Buckets** ondersteun die **kop `x-http-method-override`**. So dit was moontlik om die kop `x-http-method-override: HEAD` te stuur en die cache te vergiftig om 'n leë antwoordliggaam te laat terugkeer. Dit kan ook die metode `PURGE` ondersteun.
### Rack Middleware (Ruby on Rails)
In Ruby on Rails-toepassings word Rack middleware dikwels gebruik. Die doel van die Rack-kode is om die waarde van die **`x-forwarded-scheme`** kop in te stel as die versoek se skema. Wanneer die kop `x-forwarded-scheme: http` gestuur word, vind 'n 301 herleiding na dieselfde plek plaas, wat moontlik 'n Denial of Service (DoS) aan daardie hulpbron kan veroorsaak. Boonop kan die toepassing die `X-forwarded-host` kop erken en gebruikers na die gespesifiseerde gasheer herlei. Hierdie gedrag kan lei tot die laai van JavaScript-lêers van 'n aanvaller se bediener, wat 'n sekuriteitsrisiko inhou.
### 403 and Storage Buckets
Cloudflare het voorheen 403-antwoorde gecache. Pogings om S3 of Azure Storage Blobs met onakkurate Owerheidskoppe te benader, sou 'n 403-antwoord lewer wat gecache is. Alhoewel Cloudflare opgehou het om 403-antwoorde te cache, kan hierdie gedrag steeds in ander proxy-dienste teenwoordig wees.
### Injecting Keyed Parameters
Caches sluit dikwels spesifieke GET-parameters in die cache-sleutel in. Byvoorbeeld, Fastly se Varnish het die `size` parameter in versoeke gecache. As 'n URL-gecodeerde weergawe van die parameter (bv. `siz%65`) egter ook met 'n foute waarde gestuur is, sou die cache-sleutel met die korrekte `size` parameter saamgestel word. Tog sou die agterkant die waarde in die URL-gecodeerde parameter verwerk. URL-gecodeer die tweede `size` parameter het gelei tot sy weglating deur die cache, maar sy gebruik deur die agterkant. Om 'n waarde van 0 aan hierdie parameter toe te ken, het gelei tot 'n cachebare 400 Bad Request-fout.
### User Agent Rules
Sommige ontwikkelaars blokkeer versoeke met gebruikers-agente wat ooreenstem met dié van hoë-verkeer gereedskap soos FFUF of Nuclei om bedienerlaai te bestuur. Ironies, kan hierdie benadering kwesbaarhede soos cache poisoning en DoS inbring.
### Illegal Header Fields
Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spesifiseer die aanvaarbare karakters in kopname. Koppe wat karakters buite die gespesifiseerde **tchar** reeks bevat, behoort idealiter 'n 400 Bad Request-antwoord te aktiveer. In praktyk hou bedieners nie altyd by hierdie standaard nie. 'n Opmerkelijke voorbeeld is Akamai, wat koppe met ongeldige karakters deurgee en enige 400-fout cache, solank die `cache-control` kop nie teenwoordig is nie. 'n Uitbuitbare patroon is geïdentifiseer waar die stuur van 'n kop met 'n onwettige karakter, soos `\`, 'n cachebare 400 Bad Request-fout sou lewer.
### Finding new headers
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
## Cache Deception
Die doel van Cache Deception is om kliënte **hulpbronne te laat laai wat deur die cache met hul sensitiewe inligting gestoor gaan word**.
Eerstens, let daarop dat **uitbreidings** soos `.css`, `.js`, `.png` ens. gewoonlik **gekonfigureer** is om in die **cache** **gestoor** te word. Daarom, as jy toegang verkry tot `www.example.com/profile.php/nonexistent.js`, sal die cache waarskynlik die antwoord stoor omdat dit die `.js` **uitbreiding** sien. Maar, as die **toepassing** **herhaal** met die **sensitiewe** gebruikersinhoud wat in _www.example.com/profile.php_ gestoor is, kan jy daardie inhoud van ander gebruikers **steel**.
Ander dinge om te toets:
* _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_
* _Gebruik minder bekende uitbreidings soos_ `.avif`
Nog 'n baie duidelike voorbeeld kan in hierdie skrywe gevind word: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
In die voorbeeld word verduidelik dat as jy 'n nie-bestaande bladsy soos _http://www.example.com/home.php/non-existent.css_ laai, die inhoud van _http://www.example.com/home.php_ (**met die gebruiker se sensitiewe inligting**) gaan teruggegee word en die cache bediener gaan die resultaat stoor.\
Dan kan die **aanvaller** toegang verkry tot _http://www.example.com/home.php/non-existent.css_ in hul eie blaaiert en die **vertrouelijke inligting** van die gebruikers wat voorheen toegang verkry het, waarneem.
Let daarop dat die **cache proxy** moet wees **gekonfigureer** om lêers **te cache** gebaseer op die **uitbreiding** van die lêer (_.css_) en nie gebaseer op die content-type nie. In die voorbeeld _http://www.example.com/home.php/non-existent.css_ sal 'n `text/html` content-type hê in plaas van 'n `text/css` mime tipe (wat die verwagte vir 'n _.css_ lêer is).
Leer hier oor hoe om [Cache Deceptions aanvalle uit te voer wat HTTP Request Smuggling misbruik](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
## Automatic Tools
* [**toxicache**](https://github.com/xhzeem/toxicache): Golang skandeerder om web cache poisoning kwesbaarhede in 'n lys van URL's te vind en verskeie inspuitings tegnieke te toets.
## References
* [https://portswigger.net/web-security/web-cache-poisoning](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://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
* [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
* [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
* [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](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/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
\
Gebruik [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=cache-deception) om maklik te bou en **werkvloei** te **automate** wat deur die wêreld se **mees gevorderde** gemeenskap gereedskap aangedryf word.\
Kry Toegang Vandag:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
{% hint style="success" %}
Leer & oefen AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Leer & oefen GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Kyk na die [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
{% endhint %}
Reference in a new issue View git blame Copy permalink