Příčiny a dopady SSRF zranitelností

Útok, při kterém útočník přiměje nějakou serverovou službu k odeslání požadavku na jinou serverovou službu a k následnému přeposlání odpovědi útočníkovi, se nazývá Server Side Request Forgery (SSRF). Podstatou útoku je obvykle tvůrcem softwaru nezamýšlená interakce s interními, neveřejnými APIs, nevyžádaná interakce s API třetích stran nebo exfiltrace dat ze systému pomocí vynucení interakce s API pod kontrolou útočníka. Článek rozebírá příčiny a dopady zranitelnosti serverů na tento útok.

 

SSRF zranitelnosti              Protocol smuggling               DNS Rebinding                Základní/Blind SSRF         API

 

Úvod

S nástupem (zejména REST) API a microservices do světa běžných webových aplikací je často vyřízení uživatelského požadavku zajištěno pomocí množství dalších volání veřejných a neveřejných služeb a následnou kompletací uživatelské odpovědi z takto získaných informací.

Dochází-li k těmto voláním ve webovém prohlížeči uživatele, což je typické pro moderní web 2.0 aplikace, pokrývají bezpečnostní aspekty takové orchestrace, koncepty tzv. Cross- -Origin Resource Sharing a Same-origin Policy, které stanovují pravidla a omezení interakce s APIs na různých doménách.

Dochází-li ale k voláním na straně aplikačního serveru, nelze se spolehnout na žádný obdobný standard chování a veškeré bezpečnostní aspekty musí ošetřit vývojář aplikace. A právě zde často vzniká prostor pro výskyt zranitelností třídy SSRF. Server-Side Request Forgery se dá označit jako schopnost útočníka vhodně sestavenými uživatelskými požadavky zneužít funkce aplikačního serveru nebo ovlivňovat požadavky následně vygenerované aplikačním serverem na další služby.

Podstatou útoku je obvykle tvůrcem softwaru nezamýšlená interakce s interními, neveřejnými APIs, nevyžádaná interakce s API třetích stran nebo exfiltrace dat ze systému pomocí vynucení interakce s API pod kontrolou útočníka. Útok je obvykle ještě závažnější, protože aplikační server zajišťující koordinaci komunikace je typicky z pohledu provozovatele již důvěryhodným serverem, a tedy není striktně svázán pravidly firewallů ani síťovou segmentací. Zcela specifických rozměrů pak nabývají SSRF zranitelnosti u aplikací provozovaných na IaaS (Amazon AWS, Google Cloud atp.), kde i řízení platformy samotné je často umožněno pomocí volání interních APIs. Ty se tak stávají častým a dobře zdokumentovaným cílem SSRF útoků.

Podstata SSRF zranitelností

Webové aplikace často využívají externí požadavky pro komunikaci se službami třetích stran. Implementace této komunikace je nejčastějším zdrojem SSRF zranitelností, zejména pokud je komunikace ovlivněna uživateli. Jako příklad lze použít nahrávání externích obrázků z uživatelem kontrolované URL. Aplikační server po obdržení takového URL provede HTTP GET požadavek na uvedené URL a pokusí se obrázek stáhnout. Pokud je výsledkem takového GET požadavku opravdu (binární) obrázek, vše proběhne dle očekávání a uživatel se může těšit ze zobrazeného obrázku.

Rozhodne-li se takový požadavek uživatel provést miliónkrát, může tím zahltit nebo signifikantně zatížit zdrojovou službu obrázků. Pro provozovatele aplikace je nepříjemnou zprávou, že veškeré požadavky na získání obrázku potečou ze zdrojových IP adres provozovatele (vznikají na aplikačním serveru provozovatele), nikoli z IP adresy útočníka. V lepším případě představuje tato situace pro provozovatele reputační riziko (nezamyšleně se stane zdrojem DoS útoku), v horším případě může mít taková situace i právní dohru.

Mnohem zajímavější situace nastává, rozhodne-li se útočník místo URL obrázku uvést jiné zajímavé URL, např. URL management API. IaaS prostředí takové požadavky typicky automaticky obohatí o autorizační tokeny odpovídající rolím/ skupinám předmětného objektu v IaaS prostředí, takže se aplikační server nezamyšleně může opravdu dostat k interním datům z management API. V závislosti na kvalitě validací na aplikačním serveru pak mohou být tyto externí data exfiltrována až k útočníkovi ať už přímo v odpovědi na požadavek útočníka, či tzv. out-of-band např. ve formě „obrázku“ na profilové stránce.

Orchestrace na straně aplikačního serveru se nemusí omezovat na HTTP GET metody (které by správně nikdy neměly měnit stav), ale lze generovat i požadavky s dalšími HTTP metodami – typicky POST, ale často se objeví i PUT či DELETE, které už ke změně stavu typicky vedou.

Typické příčiny vzniku SSRF zranitelností

Je nutno zdůraznit, že v mnoha případech tvůrce aplikace vůbec nevnímá SSRF jako potenciální riziko, zvláště jedná-li se o triviální operace, např. zmíněné získání obrázku z URL. Historie již mnohokrát ukázala, že právě SSRF zranitelnosti mohou vést ke kompletnímu převzetí kontroly nad platformou útočníkem, viz např.:

• Shopify – ROOT přístup ke kubernetes instancím [1],
• GitLab CI [2].

Neméně obvyklou situací je jakýsi falešný pocit bezpečí vzniklý na základě nedokonale implementované filtrace povolených URL, které se mohou stát cílem na aplikačním serveru generovaných požadavků.

Parsování URL je chronicky nekonzistentní napříč technologiemi a může lehce selhat. (Prezentováno do detailu na BlackHat 2017 – Orange Tsai/A New Era of SSRF – Exploiting URL Parser in Trending Programming Languages! [3]

Poměrně zajímavou kategorií jsou pak SSRF zranitelnosti druhého řádu, kdy jsou sice cílové URL tvůrcem aplikace generovaných požadavků striktně filtrovány, ale není tomu tak u kódu třetích stran, typicky knihoven pro zpracování uživatelských dat, např. obrázků, Office dokumentů, PDF dokumentů, dat strukturovaných v XML apod. Komplexní moderní datové formáty totiž často využívají nebo alespoň dovolují využít vnější datové entity.

Poslední zmiňovaná kategorie SSRF zranitelností je pak dobrým příkladem nutnosti ošetřit u backendů moderních webových aplikací nejen příchozí, ale i odchozí síťovou komunikaci. S ohledem na dynamiku IaaS prostředí a typickou provázanost moderních aplikací na API třetích stran pak už nelze mluvit o stavovém filtrování trafficu na konkrétní IP adresy (které se můžou často měnit), ale spíše o nutnosti „next-gen“ firewallů pracujících s entitami typu služba.

Atypické je, že technicky vzato k SSRF dochází i jako k doprovodnému efektu většiny závažných server-side zranitelností:

• SQL injection – většina SQL jazyků obsahuje prostředky pro komunikaci s externími datovými zdroji,
• Code injection – útočník využije zranitelnosti k provedení vlastního kódu generujícího externí požadavky,
• XXE/XPath injection – pomocí referencí na externí entity, Server-Side Template Injection – pomocí referencí na externí entity,
• Server-Side Includes injection,
• Deserializace/Unmarshalling – exploitace závisí na tom, zda aplikace umožňuje zpracování tříd, které implementují nebezpečné funkčnosti (tzv. gadgety). Gadgety vedoucí k SSRF jsou velmi běžné a využívají se jako jedna z metod testování/detekce nebezpečné deserializace.

U mnoha z těchto zranitelností SSRF figuruje jako mezikrok při exploitaci (XXE [4], Deserializace [5]).

Zneužití SSRF zranitelností

SSRF zranitelnosti samy o sobě nesou jen nejasný impakt. Na závažnosti jim dodává fakt, že útok přichází z důvěryhodného zdroje v rámci infrastruktury aplikace. Takovému zdroji jsou pak dostupné i neveřejné služby. Tyto služby typicky neimplementují autentizaci, nevyužívají šifrované připojení a vystavují aplikační prostředí bez typických hranic a omezení veřejně dostupných rozhraní.

Služby často zneužívané při SSRF:

• Redis – čtení/zápis dat,
• SMTP – interakce s SMTP serverem,
• LDAP – čtení záznamů,
• Jenkins, Confluence, Jira – zneužití známých zranitelností; tyto služby obsahují řadu zranitelností umožňujících SSRF nebo vzdálené vykonání kódu; řetězením SSRF zranitelností může útočník odhalit další dostupné části intranetu nebo získat lepší kontrolu nad generovanými požadavky [6],
• Cloud metadata API – čtení tokenů a metadat asociovaných s instancí, eskalace/zneužití získaných privilegií v rámci cloud infrastruktury.

Některé z těchto služeb nevyužívají pouze HTTP protokolu, při SSRF zranitelnostech útočníci využívají pro přemostění tohoto omezení tzv. Protocol smuggling.

Protocol smuggling

Proces emulace protokolu pomocí jiného protokolu – tato technika umožňuje exploitovat SSRF zranitelnosti, které nejsou běžně považované za prakticky zneužitelné. Využívá vlastnost klientských implementací některých protokolů, kdy je uživatelský vstup bezkontextově začleněn do komunikace se serverem dané služby (např. uživatelské jméno a heslo v případě LDAP klienta), a zároveň obvyklou vlastnost serverových implementací vyjít vstříc uživateli a ignorovat drobné nebo větší odchylky klientské komunikace od specifikace daného protokolu.

Útočník tak může využít např. LDAP klienta pro komunikaci s vhodnou SMTP službou tak, že jako cílovou službu uvede hostname a port SMTP serveru a do uživatelského jména pak vloží řídící příkazy SMTP protokolu. Bude-li LDAP klient dostatečně laxní při validaci uživatelského vstupu, dokáže útočník vložit např. jako uživatelské jméno sadu smysluplných SMTP příkazů. A bude-li zároveň SMTP služba vstřícná k chybám v použitém protokolu a jednoduše zahodí nečekané vstupy, v tomto případě ve formě iniciace LDAP komunikace, a začne zpracovávat až validní příkazy SMTP protokolu (které se v datovém toku záhy objeví jako uživatelské jméno), podaří se útočníkovi provádět validní interakci s SMTP serverem pomocí LDAP klienta.

Byť není protocol smuggling 100% spolehlivá metoda, šance útočníka na úspěch jsou poměrně velké, zejména jedná-li se o textové protokoly.

Další příklady protokolů zneužívaných k smugglingu:

• Gopher [7],
• DICT [8],
• TLS Poison při zahájení HTTPS připojení [9].

U každého z příkladů útočník získává možnost do spojení iniciovaného při SSRF injektovat arbitrární znaky včetně nových řádků a emulovat tak validní komunikaci různých protokolů.

Příklady protokolů, které bývají cílem smugglingu:

• Memcached [10],
• Redis,
• FastCGI,
• Zabbix,
• MySQL,
• Syslog [11].

Ukázka smugglingu memcached protokolu – pozornosti by neměla uniknout sekvence znaků %0D%0A, která reprezentuje znaky nového řádku a umožňuje do výsledné komunikace vložit odsazený, syntakticky validní příkaz v memcached protokolu [12].

Útoky na server-side klienty

Často opomíjenou variantou SSRF zranitelností jsou útoky na klientské programy/knihovny ne-webových protokolů. Každý server-side klient, kterým je schopen útočník iniciovat vnější připojení, představuje další potenciálně zranitelný kód, jehož vstupy útočník kontroluje.

Mezi známé vektory útoků patří např.:

• JDBC ovladače [13],
• MySQL klienty [14],
• Prohlížeče na straně serveru (časté např. využití prohlížečů v headless režimu při generování PDF z HTML [15]).

NTLM relaying

NTLM (NT LAN Manager) je sada protokolů, které využívají služby k autentizaci po síti. Jednou z dlouhodobě relevantních technik při kompromitaci infrastruktur je Pass-the- -Hash (PtH). PtH využívá vlastnosti NTLM protokolu – konkrétně faktu, že při autentizaci po síti je klientem zasílán pouze hash hesla, ne heslo samotné – k autentizaci ve jménu uživatele bez znalosti jeho hesla v otevřeném textu.

Obvykle bývá technika PtH využita k laterálnímu pohybu v síti za asistence Man-in-the-Middle útoku (útočník se v rámci sítě vydává za legitimní službu) nebo pomocí NTLM hashů nalezených na již kompromitované stanici.

Z hlediska exploitace SSRF je tato technika relevantní díky faktu, že některé implementace klientů ve webových aplikacích automaticky provedou NTLM autentizaci vůči serverům, které ji od klienta vyžádají. Touto záludnou vlastností oplývá např. implementace URLConnection v jazyku Java.

Pomocí jakékoli SSRF zranitelnosti tak útočník může zranitelného Java klienta nasměrovat na svůj server. Automatickou NTLM autentizací, kterou klient provede, posléze zneužije k přihlášení útočník. Více informací nalezne čitatel např. v přednášce z konference HITBSecConf z roku 2018, která se uskutečnila v Dubaii. [16]

DNS Rebinding

DNS Rebinding je technika používaná útočníkem k zmatení filtrů založených na procesování URL. Útočník je schopen pomocí speciálního DNS serveru pro jednotlivé server-side požadavky změnit IP adresu, kterou reprezentuje doménové jméno. Pokud aplikace konstruuje požadavky na základě domény, útočník je tak schopen změnit cílový server požadavků během vykonávání kódu.

Tato technika je obzvláště účinná při útocích na server-side browsery, jelikož dovoluje útočníkovi obejít Same- -Origin Policy tak, že různé komponenty webové stránky (např. Javascript) získává browser sice z jedné domény (čili v souladu se SOP), ale fakticky z nesouvisejících IP adres. Pomocí DNS rebindingu může útočník v rámci stejného Originu (reprezentovaného doménou) komunikovat jak s vnějšími, tak s vnitřními IP adresami. [17]

Náprava zranitelností

Hlavní zásadou při nápravě a prevenci SSRF zranitelností je pracovat s předpokladem, že inicializace síťových spojení/ generování požadavků ve vnitřních serverech na základě nedůvěryhodného vstupu je pokaždé nebezpečná.

Pokud je účelem funkčností generovat externí požadavky na základě nedůvěryhodného vstupu, měla by být izolovaná v rámci svého okolí v síti nebo provozovaná s přístupem k rozhraním ekvivalentním postavení uživatele, který arbitrární vstup vkládá.

Funkčnosti, které cíleně vykonávají vzdálené požadavky, nejsou jediným zdrojem SSRF zranitelností. SSRF není problém řešitelný jednou konkrétní bezpečnostní hranicí/kontrolou. SSRF zranitelnosti a jejich dopady mohou záviset na patchovací politice organizace, architektuře systémů v rámci L2/L3 síťové segmentace a obecně na bezpečnostní politice, kterou organizace v rámci napadených systémů implementuje.

Jedinou efektivní obranou proti exploitaci SSRF zranitelností je přísné aplikování principu nejnižších privilegií a dobré bezpečnostní praktiky:

• Co největší míra segmentace i v rámci interních sítí.
• Využití autentizace pro všechny vnitřní služby.
• Přísná pravidla u firewallů, jak pro příchozí, tak odchozí traffic.
• Pravidelné instalace aktualizací.

Závěr

Byť SSRF útoky prošly značnou evolucí, zůstávají relevantní zejména díky implicitní důvěře nebo obecně laxnímu přístupu k bezpečnosti, který vede k ponechání zneužitelných cílů v dosahu útočníků. Proto bychom je neměli zbytečně podceňovat a snažit se aplikovat zmíněné principy a ověřené bezpečnostní postupy.

 

 

 

 

 

 

Použité zdroje:

[ 1 ] hackerone. SSRF in Exchange leads to ROOT access in all instances https://hackerone.com/reports/341876

[ 2 ] hackerone. SSRF in CI after first run https://hackerone.com/reports/369451

[ 3 ] BlackHat 2017-Orange Tsai/A New Era of SSRF https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf).

[ 4 ] Timur Yunusov. Alexey Osipov. XML Out-Of-Band Data Retrieval. Blackhat EU 2013, https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf

[ 5 ] Zhang. Wang. Li. Chai. New Exploit Technique in Java Deserialization Attack. Blackhat EU 2019. https://i.blackhat.com/eu-19/Thursday/eu-19-Zhang-New-Exploit-Technique-In-Java-Deserialization-Attack.pdf

[ 6 ] Honoki.net. From blind XXE to root-level file read access. 12 Dec 2018, https://honoki.net/2018/12/12/from-blind-xxe-to-root-level-file-read-access/

[ 7 ] Github. Gopherus. https://github.com/tarunkant/Gopherus

[ 8 ] SSRF bible. Cheatsheet. 26 Jan 2017. https://cheatsheetseries.owasp.org/assets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet_SSRF_Bible.pdf

[ 9 ] The Daily Swing. John Leyden. When TLS hacks you: Security friend becomes a foe. 7 Aug 2020. https://portswigger.net/daily-swig/when-tls-hacks-you-security-friend-becomes-a-foe

[ 10 ] Orange blog. How I Chained 4 vulnerabilities on GitHub Enterprise, From SSRF Execution Chain to RCE! http://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html

[ 11 ] ONsec: web applications security. Vorontsov. Golovko. SSRF attacks and sockets: smorgasbord of vulnerabilities. http://2012.zeronights.org/includes/docs/Vorontsov%20Golovko.pdf

[ 12 ] Orange blog. How I Chained 4 vulnerabilities on GitHub Enterprise, From SSRF Execution Chain to RCE! https://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html

[ 13 ] NVD. CVE-2020-13692 Detail. https://nvd.nist.gov/vuln/detail/CVE-2020-13692

[ 14 ] acunetix. Adminer 4.6.2. file disclosure vulnerability. https://www.acunetix.com/vulnerabilities/web/adminer-4-6-2-file-disclosure-vulnerability/

[ 15 ] hackerone. SSRF in Exchange leads to ROOT access in all instances https://hackerone.com/reports/341876

[ 16 ] HITBSecConf2018 – Dubai. NTLM Relay is dead, Long Live NTLM Relay https://conference.hitb.org/hitbsecconf2018dxb/materials/ D2T2%20-%20NTLM%20Relay%20Is%20Dead%20Long%20Live%20NTLM%20Relay%20-%20Jianing%20Wang%20and%20Junyu%20Zhou.pdf

[ 17 ] Owning The Clout Through SSRF and PDF Generators. Sadeghipour. Brocious. https://docs.google.com/presentation/d/ 1JdIjHHPsFSgLbaJcHmMkE904jmwPM4xdhEuwhy2ebvo/htmlpresent

[ 18 ] Medium. Extend the Attack Surface of PHP Deserialization Vulnerability via Phar. Knownsec 404 Team. 23 Aug 2018. https://medium.com/@knownsec404team/extend-the-attack-surface-of-php-deserialization-vulnerability-via-phar-d6455c6a1066