Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.

Fis

Protože jsem to trochu zprasil, tak pro velký úspěch ještě jednou:

Nedá se to provést ani z kódu dané aplikace (případně nějaké miniaplikace, kterou pustíte jednou a pak ji odstraníte)? Zejména pokud jste schopen spustit i nativní kód (řekněme načíst DLL knihovnu), měl byste mít přístup k příslušným API, abyste mohl upravit příslušná ACL tak, aby k nim uživatel, pod kterým běží webserver, ztratil přístup, který mu dát nechcete.

Netvrdím, že se jedná o zvlášť úžasné řešení, ale těm, kdo chtějí své aplikaci ubrat nějaké to oprávnění, by mohlo posloužit.

Hezký hack. Nezkoušel jsem. Vyzkouším a dám vědět, případně doplním do blogu.

Kdybyste možnost zápisu do www root nenazýval "critical vulnerability", ale spíše popsal možnost, jak podle vás vytvořit pro většinu aplikací bezpečnější prostředí, toto téma by asi vypadalo jinak (pokud by vůbec existovalo). Kritická zranitelnost podle mojí zkušenosti vypadá úplně jinak.

Primárně nejde jen o zápis, ale o zápis a spuštění. To je ten hlavní problém Azure, o kterém píši na blogu. A to je podle mne kritická zranitelnost.

Ten zbytek, to se spíše zvrtla diskuze. Ten vlastní zápis samozřejmě není critical, ale já bych to jako HIGH nebo minimálně MEDIUM nález v pentest reportu uvedl.


Fis

melo by to byt utazeno pokud mozno co nejvice
Zkuste být konkrétnější. A taky napište, kdo by pak takovou službu kupoval.

Zmíním jen termín "least privilege access control"

Nelze se spolehat na bezpecnost aplikace. To bysme potom mohli rici, ze aplikace se postara o veskerou bezpecnost.
Ano, aplikace se musí postarat o veškerou bezpečnost. Nelze nebezpečnou aplikaci obecně zabezpečit zvenčí – vždycky někdo vymyslí nějaký nový způsob, jak udělat aplikaci nebezpečnou. Ostatně, kdyby to šlo udělat z venčí, proč by operační systém vůbec umožňoval něco jiného? Napište ten váš operační systém, ve kterém nepůjde provozovat aplikace nebezpečným způsobem, a bude z vás miliardář.

Já s vámi souhlasím. Jenže co když to neudělá? Nebo v ní prostě bude nechtěná chyba? Viz chyba ve wodpressu, která se probírala i tady na rootu https://www.root.cz/clanky/utok-na-wordpress-pres-rest-api-tretina-webu-nema-posledni-zaplaty/? Aplikace prostě nejsou bez chyby. A nikdy nebudou. A když to někdo ví dříve, než se chyba odstraní, tak je průšvih na světě. To znamená, že je potřeba se bránit všemi dostupnými prostředky.

mnou uvadena zranitelnost, protoze je to konfiguracni chyba
Povolený zápis do databáze, který může mít úplně stejné důsledky, také považujete za konfigurační chybu?

Jak jsem již psal. Jak spustím takový kód, který jsem uložil do DB na straně serveru? To není tak jednoduché, jako spustit ten, co uložím přímo do www root.

Fis

Kromě toho mě napadá, že do vašeho www root můžu uložit nějakou phishingovou html stránku. S iframem nebo javascriptem a getem credentials někam jinam. Nebo spustitelný soubor. A linkovat na něj uživatele odkudkoliv. Když pak uvidí váš zelený certifikát, bez většího podezření, tak si klíďo píďo vyplní heslo. Nebo stáhne soubor a může takový soubor spustit.

andy

Já to pořád nechápu.

Citace
b) aplikace má úmyslně nějaký interface ke správě souborů, třeba fotek a spoléhá se, že OS zajistí práva na složky (je to nejjednodušší, jak to napsat a bude to typicky problém, když použiju knihovnu třetí strany, o které nic nevím)
c) v administračním rozhraní aplikace je úmyslně nejaký filebrowser pro adminy aplikace, aby mohli něco dělat na filesystému - tady pozor, admin interface běží třeba i na jiném portu a nemá k němi nikdo jiný než aplikační admin přístup.
d) není nijak omezen typ souboru, který můžu na filesystém uložit
Takže jestli dobře chápu, tak vaše řešení, aby můj web byl "bezpečnější" je mi tyhle aplikace zakázat...?

Citace
Všechny případy mi dovolí na web server do www root nahrát cokoliv, tzn. třeba i soubor s příponou .php (v případě .Net pak do wwwroot aspx, do wwwroot/bin dll s kódem), který pak můžu spustit.
Hele sorry, ale python má "eval" a "ctypes", když budu mít v aplikaci díru (pro začátek třeba SQL injection, můžu mít třeba dál stránky částečně generovaný z databáze atp.), tak aniž by moje aplikace měla právo zápisu na disk, tak případný útočník může:

Můžu třeba vyměnit část HTML, vrazit tam vlastní SCRIPT tag a odchytávat hesla
Můžu kompletně ukrást celý aplikační kód původní aplikace (což mi hrozně zjednoduší jiné kroky) - protože read-only přístup tam pořád je a když se mi podaří exploitnout nějakou chybu, která umožňuje čtení souborů...
Můžu kompletně vykrást databázi, protože přes SQL injection se daj dělat kouzla.
Můžu si začít provozovat svojí apku za cizí peníze
Ani v jednom případu nezjistím, kdo mi tam vlez, zápisy často nemají ani časovou značku.

Já pořád nechápu, kde je ta kritická chyba u toho Azure?

Citace
Hezký hack. Nezkoušel jsem. Vyzkouším a dám vědět, případně doplním do blogu.

Hack to není. Prostě pokud daný uživatel má oprávnění pracovat s ACL daného objektu (ať už mu to dovoluje samotné ACL, nebo je jeho vlastníkem a není přítomno OWNER SID), teoreticky může ACL upravit dle libosti.




Když to trochu přeženu, tak na mě působíte tak, že pro vás je kritickou zranitelností i např. vypnuté ASLR, protože pokud daná aplikace trpí nějakou jinou zranitelností, ASLR její zneužití může výrazně ztížit, ale ne mu zabránit docela.

andy

Citace
Jak jsem již psal. Jak spustím takový kód, který jsem uložil do DB na straně serveru? To není tak jednoduché, jako spustit ten, co uložím přímo do www root.
Tak vzhledem k tomu, že tady operuješ s existencí nějakých prehistorických aplikací, které něco zapisují na lokální FS, tak ti jednoduše odpovím aplikací, která má SQL injection chyby a posílá klientům kusy HTML z databáze, na kterých na výstupu nedělá sanitizaci (teda to je cizích slov)...easy...

andy

Citace
Primárně nejde jen o zápis, ale o zápis a spuštění. To je ten hlavní problém Azure, o kterém píši na blogu. A to je podle mne kritická zranitelnost.
Což je blbost, protože když tam mám zápis, tak můžu přepsat nějaký z těch node/python/zdrojáků a můžu si tam udělat co chci a žádný zákaz spuštění mě nezastaví. Při troše snahy se dostanu i na spustitelný kód (tomuhle se dá nějakým nastavením OS asi vcelku bránit), ale tak nějak bych řek, že to ani potřeba neni, tyhle jazyky toho umí docela dost...

Fis

Citace
Hezký hack. Nezkoušel jsem. Vyzkouším a dám vědět, případně doplním do blogu.

Hack to není. Prostě pokud daný uživatel má oprávnění pracovat s ACL daného objektu (ať už mu to dovoluje samotné ACL, nebo je jeho vlastníkem a není přítomno OWNER SID), teoreticky může ACL upravit dle libosti.

Je to hack Azure sluzby, ktera to v defaultu neumoznuje. Je to proste obejiti toho, co se MS snazi zakazat.

Fis

Když to trochu přeženu, tak na mě působíte tak, že pro vás je kritickou zranitelností i např. vypnuté ASLR, protože pokud daná aplikace trpí nějakou jinou zranitelností, ASLR její zneužití může výrazně ztížit, ale ne mu zabránit docela.

Pockejte, ted tomu nerozumim, ja psal, ze write je podle mne MEDIUM/HIGH, write/exec je CRITICAL co se tyce public folderu, jako je wwwroot.

A co se tyce ASLR, to je trosku neco jineho. Ty FS prava u muzou utoku zabranit zcela. Vypnute ASLR "jen" ulehci utok, prece jen se lip se pracuje, kdyz pointer ukazuje na stejne misto nez kdyz se pri kazdem ld zmeni. Ale i tak, pokud bych to nasel, tak bych to reportoval stejne jako write na www root. tzn MEDIUM az HIGH.

andy

Pockejte, ted tomu nerozumim, ja psal, ze write je podle mne MEDIUM/HIGH, write/exec je CRITICAL co se tyce public folderu, jako je wwwroot.

A co se tyce ASLR, to je trosku neco jineho. Ty FS prava u muzou utoku zabranit zcela. Vypnute ASLR "jen" ulehci utok, prece jen se lip se pracuje, kdyz pointer ukazuje na stejne misto nez kdyz se pri kazdem ld zmeni. Ale i tak, pokud bych to nasel, tak bych to reportoval stejne jako write na www root. tzn MEDIUM az HIGH.
Asi tomu nerozumím:
Citace
Vulnerabilities are design flaws or misconfigurations that make your network (or a host on your network) susceptible to malicious attacks from local or remote users. Vulnerabilities can exist in several areas of your network, such as in your firewalls, FTP servers, Web servers, operating systems or CGI bins.
Ok, takže mám aplikaci v pythonu, která nezapisuje na lokální FS, běží v Azure. Podle tebe je tam vulnerabilita, a to dokonce CRITICAL. Ok. Kde?

Fis

Což je blbost, protože když tam mám zápis, tak můžu přepsat nějaký z těch node/python/zdrojáků a můžu si tam udělat co chci a žádný zákaz spuštění mě nezastaví. Při troše snahy se dostanu i na spustitelný kód (tomuhle se dá nějakým nastavením OS asi vcelku bránit), ale tak nějak bych řek, že to ani potřeba neni, tyhle jazyky toho umí docela dost...

Tohle nechápu. Co je blbost? Píšu, že zápis a zápis + spuštění je obojí problém. Říkám od začátku, že write s www-data právama do wwwroot je prostě hazard.

Citace
Jak jsem již psal. Jak spustím takový kód, který jsem uložil do DB na straně serveru? To není tak jednoduché, jako spustit ten, co uložím přímo do www root.
Tak vzhledem k tomu, že tady operuješ s existencí nějakých prehistorických aplikací, které něco zapisují na lokální FS, tak ti jednoduše odpovím aplikací, která má SQL injection chyby a posílá klientům kusy HTML z databáze, na kterých na výstupu nedělá sanitizaci (teda to je cizích slov)...easy...

To je ale prece neco jineho. V tomhle pripade jsem nic nespustil, pokud tam teda neni nejak vyprasenej ten eval, o cemz jsem tu taky psal. Takhle muzu podstrcit neco klientovi, to jo, ale tezko treba ziskam connection string do databaze. Nebo v stáhnu aplikační kód. Nebo něco webconfig. Nebo master klíče pro šifrování states. Nebo vydoluju databázi (záleží na té SQL injectioně co tam bude, může být taky dost omezená, třeba jen na jednu tabulku) Nebo se tezko muzu snazit zbourat sandbox, ve kterem bezi cely web server (v pripade AppService). To prostě můžu udělat jen když ten server přímo spustí můj kód.

Citace
Všechny případy mi dovolí na web server do www root nahrát cokoliv, tzn. třeba i soubor s příponou .php (v případě .Net pak do wwwroot aspx, do wwwroot/bin dll s kódem), který pak můžu spustit.

Hele sorry, ale python má "eval" a "ctypes", když budu mít v aplikaci díru (pro začátek třeba SQL injection, můžu mít třeba dál stránky částečně generovaný z databáze atp.), tak aniž by moje aplikace měla právo zápisu na disk, tak případný útočník může:

Můžu třeba vyměnit část HTML, vrazit tam vlastní SCRIPT tag a odchytávat hesla
Můžu kompletně ukrást celý aplikační kód původní aplikace (což mi hrozně zjednoduší jiné kroky) - protože read-only přístup tam pořád je a když se mi podaří exploitnout nějakou chybu, která umožňuje čtení souborů...
Můžu kompletně vykrást databázi, protože přes SQL injection se daj dělat kouzla.
Můžu si začít provozovat svojí apku za cizí peníze
Ani v jednom případu nezjistím, kdo mi tam vlez, zápisy často nemají ani časovou značku.

Já pořád nechápu, kde je ta kritická chyba u toho Azure?

To co jsi popsal je čistě problém aplikace. A předpokládá hned dvě zranitelnosti. tzn. SQL injection a EVAL/CTYPES, což ve výsledku hodně pravděpodobně taky znamená user input validation. To, že to má "skoro" stejné konsekvence, to je jiná věc. Eval jde samozřejmě zneužít i bez SQL injection, pokud je to zprasený. Každopádně, obojí (resp. všechny tři) jsou jiné, ale stejně kritické zranitelnosti. Ale aplikační. Ne konfigurační / infrastrukturní.  Takže kdybys to napral na appservice, dostal  bys ode mně report ve smyslu:

Infrastructure-Configuration, WWWRoot permissions, write acccess, Medium
Application, User Input Validation, Critical
Application, SQL Injection, Critical
Application, Code injection, Critical
Infrastructure-Configuration, wwwroot permissions, execute permissions on uploaded files, Critical


Fis

Pockejte, ted tomu nerozumim, ja psal, ze write je podle mne MEDIUM/HIGH, write/exec je CRITICAL co se tyce public folderu, jako je wwwroot.

A co se tyce ASLR, to je trosku neco jineho. Ty FS prava u muzou utoku zabranit zcela. Vypnute ASLR "jen" ulehci utok, prece jen se lip se pracuje, kdyz pointer ukazuje na stejne misto nez kdyz se pri kazdem ld zmeni. Ale i tak, pokud bych to nasel, tak bych to reportoval stejne jako write na www root. tzn MEDIUM az HIGH.
Asi tomu nerozumím:
Citace
Vulnerabilities are design flaws or misconfigurations that make your network (or a host on your network) susceptible to malicious attacks from local or remote users. Vulnerabilities can exist in several areas of your network, such as in your firewalls, FTP servers, Web servers, operating systems or CGI bins.
Ok, takže mám aplikaci v pythonu, která nezapisuje na lokální FS, běží v Azure. Podle tebe je tam vulnerabilita, a to dokonce CRITICAL. Ok. Kde?

Ano, je tam. Protože to že ty tam jedeš svůj python neznamená, že tam někdo nepojede něco jiného v jiné konfiguraci. A to, že se ve tvém případě nedá zneužít neznamená, že tam ta zranitelnost není.

Je to jak kdybys řekl: Používám děravý XPčka. Ale dal jsem před ně firewall, takže ty zranitelnosti zmizely. Nezmizely. Jsou tam furt. A když se uklikneš v konfiguraci firewallu, až to budeš upravovat, protože tam budeš neco potřebovat povolit, třeba na jinej poč (a hodně typický scénář je: proč to kua nejede? Je to ve firewallu nebo v appce? Hm... dám si tam na chvíli any, any... a už to tam zůstane), tak hádej co se stane.

Fis

Ješte k té tvé python apce.... Jednou se třeba rozhodneš, že vydeployuješ další verzi, s novýma featurama. Dáš tam nějakou knihovnu třetí strany. Uděláš to na rychlo, pač tě zákazník bude tlačit. Zapomeneš na to, co o Azure víš. A publishnes to....

andy

Citace
To co jsi popsal je čistě problém aplikace. A předpokládá hned dvě zranitelnosti. tzn. SQL injection a EVAL/CTYPES, což ve výsledku hodně pravděpodobně taky znamená user input validation. To, že to má "skoro" stejné konsekvence, to je jiná věc
No ale to, co ty píšeš je taky problém aplikace - a předpokládá to taky několik zranitelností...

Jinak řečeno: když poběžím blbej wordpress s writable home adresářem, mám tam vulnerability Critical. Když to poběžím na systému bez writable home, mám vulnerability Medium.

A když tam nepoběžím blbej wordpress, ale něco bezpečného, co třeba ani na lokální FS nezapisuje, tak tam žádná vulnerability není. I přes writable home adresář. Což je v rozporu s tím, že ty tvrdíš, že tam vulnerability je a to ještě ke všemu CRITICAL. Takže bych předpokládal, že budeš schopen nějak nastínit (chtěl bych říct přímo napsat, když jsi ten hacker), jakým způsobem ten systém nabouráš, když je v tom systému podle tebe kritická vulnerabilita.