Fórum Root.cz

Hlavní témata => Windows a jiné systémy => Téma založeno: Fis 20. 05. 2017, 06:47:54

Název: Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 20. 05. 2017, 06:47:54
Přestože se chvástají, jak jedou podle bezpečnostních best practices a standardů a chlubí se jak jsou PCI DSS compliant, neumí zabezpečit svoje web servery a mají tam díru jak vrata. Ale prej je to baj dyzajn... Více zde:
http://fis-cz.blogspot.cz/2017/05/ms-azure-appservice-vulnerability.html
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: . 20. 05. 2017, 11:38:58
TLDR verze
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Sten 20. 05. 2017, 12:05:30
Líbí se mi ty jeho odhady, jak by to mělo být hodnoceno a že útočníka nepůjde odhalit, protože … všechny jeho kroky jsou někde zalogované, ale bude těžké najít korelaci? LOL.

Ten odkaz na „Based on industry standards and best practices“ v PCI DSS oddílu 6 jen ukazuje, že autor vůbec netuší, o čem píše, protože to se týká způsobu vývoje aplikací, ne jejich nasazení.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 20. 05. 2017, 16:08:17
Líbí se mi ty jeho odhady, jak by to mělo být hodnoceno a že útočníka nepůjde odhalit, protože … všechny jeho kroky jsou někde zalogované, ale bude těžké najít korelaci? LOL.
Ten odkaz na „Based on industry standards and best practices“ v PCI DSS oddílu 6 jen ukazuje, že autor vůbec netuší, o čem píše, protože to se týká způsobu vývoje aplikací, ne jejich nasazení.


1. Prosím nevyjadřuj se k něčemu,čemu rozumíš asi tak jako koza petrželi.

2. Zajímalo by mě, jak bych chtěl najít útočníka, který provede takovou akci přes ANONYMNÍ proxy, když jediné co najdeš v logu IIS bude, že z nejakého veřejného IP této anonymní proxy NĚKDO vydeployoval aplikaci s oprávněním IIS účtu pouřitého pro ANONYMNÍ přístup z webu.

3. Bože, co prosímtě víš o PCI DSS standardu? Viděl jsi ho z vlaku nebo jsi jen někde slyšel, že to existuje?

   6. Develop and maintain secure systems and applications.

      SYSTEMS AND APPLICATIONS! Doufám, že víš co to znamená.

      6.1 Ensure that all system components and software are protected from known vulnerabilities by
            having the latest vendor-supplied security patches installed. Deploy critical patches within a
            month of release.

      Znovu. ALL SYSTEM COMPONENTS!

      6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.
      Risk rankings should be based on industry best practices and guidelines. Ranking vulnerabilities is
      a best practice that will become a requirement on July 1, 2012

     K tomu už nemám co bych dodal.

Tahle zranitelnost je rozhodne znama zranitelnost a je to minimalne kategorie OWASP 2010/13/17 A.5. Security Misconfiguration.

Kromě toho nejsou velmi pravděpodobně compliant s:

2.2 Develop configuration standards for all system components. Assure that thees standards address all know security vulnerabilities and are consistent with industry-acceptes system hardening standards.

Jenže já jejich konfigurační standardy neviděl! Klidně je můžou mít v pořádku. Jen je nedodržovat.

Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 20. 05. 2017, 16:09:56
TLDR verze
  • Na vašem aplikačním serveru můžete provozovat vaši aplikaci, která bude mít přístup k vašim zdrojům.
  • Pokud provozujete aplikaci umožňující nějaký průnik, může útočník využít této její vlastnosti/zranitelnosti k průniku.
  • Autor je etický hacker přes 10 let a již držel holku za ruku. Prý.

Nemám problém s přístupem ke zdrojům. Mám problém s tím, k jakým zdrojům. A holku jsem za ruku nikdy nedržel, nemám na to čas.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: čumil 20. 05. 2017, 18:05:32
TLDR verze
  • Na vašem aplikačním serveru můžete provozovat vaši aplikaci, která bude mít přístup k vašim zdrojům.
  • Pokud provozujete aplikaci umožňující nějaký průnik, může útočník využít této její vlastnosti/zranitelnosti k průniku.
  • Autor je etický hacker přes 10 let a již držel holku za ruku. Prý.
rekni mi jak jeho sexualní zivot koreluje s tim ze ma m$hit zkurveny produkty ?
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Sten 20. 05. 2017, 18:29:59
2. Zajímalo by mě, jak bych chtěl najít útočníka, který provede takovou akci přes ANONYMNÍ proxy, když jediné co najdeš v logu IIS bude, že z nejakého veřejného IP této anonymní proxy NĚKDO vydeployoval aplikaci s oprávněním IIS účtu pouřitého pro ANONYMNÍ přístup z webu.

Nic takového se v tom blogu nepíše. Naopak se tam píše ta blbost, na kterou jsem odkazoval: of course, the IP address can be visible somewhere in the log, but probably not with the action performed so correlation will be hard

3. Bože, co prosímtě víš o PCI DSS standardu? Viděl jsi ho z vlaku nebo jsi jen někde slyšel, že to existuje?

   6. Develop and maintain secure systems and applications.

      SYSTEMS AND APPLICATIONS! Doufám, že víš co to znamená.

      6.1 Ensure that all system components and software are protected from known vulnerabilities by
            having the latest vendor-supplied security patches installed. Deploy critical patches within a
            month of release.

      Znovu. ALL SYSTEM COMPONENTS!

      6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.
      Risk rankings should be based on industry best practices and guidelines. Ranking vulnerabilities is
      a best practice that will become a requirement on July 1, 2012

Chápu, že člověk, který PCI DSS četl poprvé, a navíc zastaralou verzi ;), si nevšiml, že oddíl 6 pokračuje dál a to odkazované „based on industry standards and best practices“ se objevuje v 6.3, které se týká vývoje aplikací.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: . 21. 05. 2017, 00:34:26
rekni mi jak jeho sexualní zivot koreluje s tim ze ma m$hit zkurveny produkty ?
Ten blogísek nepopisuje žádnou vadu Azure. Autor nemá ponětí o čem píše, pouze se ztrapňuje a vůbec si to neuvědomuje.
Ten poslední bod byl jen takový vtip. Takový ten, co se nevysvětluje, protože když nechápeš, tak nepochopíš.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: čumil 21. 05. 2017, 01:06:45
rekni mi jak jeho sexualní zivot koreluje s tim ze ma m$hit zkurveny produkty ?
Ten blogísek nepopisuje žádnou vadu Azure. Autor nemá ponětí o čem píše, pouze se ztrapňuje a vůbec si to neuvědomuje.
Ten poslední bod byl jen takový vtip. Takový ten, co se nevysvětluje, protože když nechápeš, tak nepochopíš.
ale ja ho chapu, o to vic mi prijdes jako kreten :)
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 08:03:22
rekni mi jak jeho sexualní zivot koreluje s tim ze ma m$hit zkurveny produkty ?
Ten blogísek nepopisuje žádnou vadu Azure. Autor nemá ponětí o čem píše, pouze se ztrapňuje a vůbec si to neuvědomuje.
Ten poslední bod byl jen takový vtip. Takový ten, co se nevysvětluje, protože když nechápeš, tak nepochopíš.

Proc vzycky nekdo, kdo necemu nerozumi takhle hrozne machruje a sam si neuvedomuje, ze se strasne ztrapnuje?
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 08:05:22
Mimochodem, tahle dira co tam je patri do kategorie hned za ty, kde jsou prihlasovaci udaje admin/admin
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Filip Jirsák 21. 05. 2017, 11:10:13
Proc vzycky nekdo, kdo necemu nerozumi takhle hrozne machruje a sam si neuvedomuje, ze se strasne ztrapnuje?
Jediný z celé diskuse, na koho mi tohle tvrzení sedí, jste vy. A začalo to hned prvním příspěvkem, který je podle mého názoru jen komentářovým spamem – bombastický titulek, a pak nic, žádný dotaz ani doložené tvrzení, jenom odkaz na vlastní blog. Asi ten blog nikoho nezajímá, tak je potřeba přivést nějaké návštěvníky, které zajímá, co je to zase za nesmysl, že?

Mimochodem, nějak jste zapomněl vysvětlit, proč si myslíte, že Azure AppService je typ služby, kde by tohle mělo být ošetřeno provozovatelem služby a ne autorem aplikace. Normálně se totiž poskytují oba typy služeb – někdo vám poskytne čistý hardware nebo VPS a je zcela na vás, co si s tím uděláte. Máte na daném počítači roota nebo administrátora a je na vás, abyste si to zabezpečil. A nebo jsou na druhém konci škály služby, kdy vám někdo poskytuje nejčastěji konkrétní aplikaci (třeba GMail nebo Office365), a vy ji používáte jako uživatel – přičemž veškeré zabezpečení je na provozovateli té aplikace. Nevím, jak jste přišel na to, že Azure AppService má blíž k tomu druhému – podle mne bude obecný webový server vždy patřit do té první kategorie, tudíž je na tom, kdo tam nasazuje nějakou aplikaci, aby si zajistil, že je ta aplikace bezpečná – nejde vytvořit takový obecný web server, který zabrání nasazené aplikaci v čemkoli nebezpečném.

A k té poznámce na konec, jak jste nepochopil, jak funguje autoaktualizace webových aplikací, třeba WordPressu – pokud má ta aplikace umět zaktualizovat sama sebe, vždy musí mít právo na serveru přepsat soubory aplikace, které jsou „spustitelné“ webovým serverem. To je přece princip aktualizace – že původní aplikaci nahradíte novou verzí.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: nobody65534 21. 05. 2017, 12:19:16
Ja to taky nechapu. Navic Microsofti bug bounty program se vztahuje i na Azure, tak jim to bezte nareportovat, ne?
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: citanus006 21. 05. 2017, 14:29:16
A k té poznámce na konec, jak jste nepochopil, jak funguje autoaktualizace webových aplikací, třeba WordPressu – pokud má ta aplikace umět zaktualizovat sama sebe, vždy musí mít právo na serveru přepsat soubory aplikace, které jsou „spustitelné“ webovým serverem. To je přece princip aktualizace – že původní aplikaci nahradíte novou verzí.

Akutualizace se da resit jen doplnovanim souboru, nemusi se prepisovat vubec nic. Implmentovano a provereno na tisicich nasazenich. A funguje o tak uz roky roukouci a ano jedna se o webovou aplikaci.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Filip Jirsák 21. 05. 2017, 14:45:08
Akutualizace se da resit jen doplnovanim souboru, nemusi se prepisovat vubec nic. Implmentovano a provereno na tisicich nasazenich. A funguje o tak uz roky roukouci a ano jedna se o webovou aplikaci.
V mém komentáři nešlo ani tak o přepisování souborů, ale o změnu chování aplikace. Je celkem jedno, jestli tu změnu implementujete bez přepisování existujících souborů nebo dokonce bez zápisu souborů na disk (protože změny uložíte třeba do databáze).

Navíc pokud si řešíte routování v aplikaci kompletně po svém, pořád je tu možnost chyby v té routovací části aplikace, kterou bez změny souboru neodkážete opravit. Takže můžete aktualizovat velkou část aplikace, ale ne celou aplikaci.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 14:56:52
...

Ach jo. Docela mě mrzí, že vaše povědomí o bezpečnosti je takové jaké je. Jen doufám, že neprovozujete žádné webové služby. Nebo aspoň takové, kde byste mohl svým zákazníkům spíše uškodit. Nebo s tímhle přístupem raději žádné.

Jediný z celé diskuse, na koho mi tohle tvrzení sedí, jste vy. A začalo to hned prvním příspěvkem, který je podle mého názoru jen komentářovým spamem – bombastický titulek, a pak nic, žádný dotaz ani doložené tvrzení, jenom odkaz na vlastní blog. Asi ten blog nikoho nezajímá, tak je potřeba přivést nějaké návštěvníky, které zajímá, co je to zase za nesmysl, že?

Podle vás jsem měl obsah sdělení přepsat sem?

Primárním účelem bylo varovat všechny, kdo
a) chce provozovat v Azure aplikaci na App Service, aby věděli, že pokud si nezabezpečí svoji aplikací tím, že ji napíšou správně (a věřte, že to nejde a vždy se najde nějaká chyba), aby si by byli vědomi toho, že pomocí téhle zranitelnosti budou útočníci schopni v rámci daného oprávnění IIS udělat úplně všechno. Vykrást databázi, bezpečnostní klíče i vlastní  kód aplikace. A bohužel, mnohem hůře, vydeployovat si svou aplikaci a např. phishovat hesla.
b) použili nějakou službu, klidně Azure, přesně jak říkáte, pouze výpočetní výkon a tam si nakonfigurovali vše podle potřeby.
c) upozornit na to, jak Microsoft reaguje na oznámení o bezpečnostních hrozbách. Což už ostatně udělal nedavno Google a bylo z toho docela haló.
s mým blogem to nemá nic společného. ten blog jsem založil jen kvůli tomu, abych tam zveřejnil tuhle zranitelnost. To až potom jsem se rozhodl přidat tam i další příspěvky.
d) zjistit, kolik lidí má o takovou informaci zájem a kolik si jí zhruba přečete. I kdyby to mělo mít 1% dopad na povědomí o výše uvedeném nebo zvýšení povědomí o bezpečnosti obecně, je to pro mě obrovský úspěch.


Mimochodem, nějak jste zapomněl vysvětlit, proč si myslíte, že Azure AppService je typ služby, kde by tohle mělo být ošetřeno provozovatelem služby a ne autorem aplikace. Normálně se totiž poskytují oba typy služeb – někdo vám poskytne čistý hardware nebo VPS a je zcela na vás, co si s tím uděláte. Máte na daném počítači roota nebo administrátora a je na vás, abyste si to zabezpečil.

A proč bych vás měl vodit za ručičku. Vy neumíte číst? Nebo použít Google? Zjevně ano, když reagujete na něco, o čem, zase - jako jiní reagující, nic nevíte a předem si nic nezjistíte. App Service je služba typu SAAS. To je software as a service. I když v tomhle případě je to mnohem více, zahrnul bych to do téhle kategorie. To znamená, že o komplet podvozek se vám stará provozovatel. Nicméně, u takového typu služeb máte jen minimální možnost, jak něco nakonfigurovat. A vězte, že tam rozhodně nemáte roota. Výhoda této služby je, že skutečně jen deployujete aplikaci a nemusíte se starat o instalaci, konfiguraci, ale hlavně zabezpečení a aktualizace celého toho ansáblu, který je k provozu vašeho businessu potřeba. Provozovat webovou aplikaci na vlastním železu nebo pouze na "železu" typu VPS, který jste zmínil obrovská zodpovědnost se spoustou zbytečné práce kolem, o které když nic nevíte, tak to dopadne přesně tak, že máte 777 na wwwroot, default admin admin a spoustu otevřených věcí, protože se vám to prostě jinak rozjet nepovedlo nebo jste to na něco zapomněl  nebo jste to tam zapomněl, což je u profesionálů mnohem běžnější (i přes to, že se leckdy mají řídit konfiguračními standardy a interními předpisy firem. Ale jsou to taky jenom lidi, že?)

Nevím, jak jste přišel na to, že Azure AppService má blíž k tomu druhému – podle mne bude obecný webový server vždy patřit do té první kategorie, tudíž je na tom, kdo tam nasazuje nějakou aplikaci, aby si zajistil, že je ta aplikace bezpečná – nejde vytvořit takový obecný web server, který zabrání nasazené aplikaci v čemkoli nebezpečném.

Opět. Další. Nic o tom nevíte a píšete. Proč si o tom nejdříve něco nepřečtete, nevytvoříte si v Azute free účet a nevyzkoušíte si to, než začnete teoretizovat? Azure není obecný web server. A jak jsem na to přišel? Asi tak, že jsem si s tím hrál a přečetl jsem si spoustu dokumentů jak o funkčnosti, tak o zabezpečení. A věřte, že je to moc pěkné čtení. Asi tak jako když vám šmejdi nabízí hrnce. To se taky pěkně poslouchá.

Citace
A k té poznámce na konec, jak jste nepochopil, jak funguje autoaktualizace webových aplikací, třeba WordPressu – pokud má ta aplikace umět zaktualizovat sama sebe, vždy musí mít právo na serveru přepsat soubory aplikace, které jsou „spustitelné“ webovým serverem. To je přece princip aktualizace – že původní aplikaci nahradíte novou verzí.

Já to právě, a asi i boužel, chápu moc dobře. Jenže ta autoaktualizace musí být spuštěná z důvěryhodných zdrojů, důvěryhodným uživatelem a ideálně odděleně od "nedůvěryhodného" (nebo raději méně důvěrného, aby mě zase netahal někdo za slovíčko). Správně je to tak, že autoupdate proces běží pod separátním účtem, stáhne si co potřebuje a aktualizuje wwwroot. Ale zase nemůže dělat vůbec nic jiného. Tzn. nemůže kamkoliv na internet a nemůže si dělat co chce na disku. Ale ze všeho nejsprávnější je, že žádný autoupdate není. Protože nejdříve by se měla udělat revize a testování aktualizace ze všech pohledů, než se vůbec nasadí. Na wordpressu je o tom celý ansábl dokumentů, jak to dělat správně a bezpečně. Já to nečetl. Nemám ho rád. A naštěstí jsem ho nikdy nemusel deployovat nebo s ním něco dělat.

Mimochodem, přečetl jste si ten dokument, na který odkazuji v blogovém příspěvku? Hardening WordPress? Víte, ono to není o tom, že si přečtete půlku informací (nebo vlastně spíše žádné, ty se obvykle hledají, až když clověk neví jak dál), stáhnete si worpress, vyklikáte si tři volby v instalátoru a považujete svojí práci hotovou. Když to chcete brát vážně, je potřeba to nastudovat komplet. Že to je moc práce? Souhlasím. Nebo spousta let praxe.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 14:59:08
Ja to taky nechapu. Navic Microsofti bug bounty program se vztahuje i na Azure, tak jim to bezte nareportovat, ne?

Víte, ono vás to po dvou měsících komunikace s MSRC a Bounty přestane bavit. Zvlášť, když odpovídají, jak odpovídají. Kluci z Project Zero to vydrželi jen týden.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: andy 21. 05. 2017, 15:04:49
Zkus mi osvětlit ten problém - vzhledem k tomu, že ta webová aplikace může být v PHP, node, pythonu apod., tak si může na tom systému dělat v rámci svých práv co chce celkem bez ohledu na to, jestli má někam zápis nebo ne. Mohl bys mi zkusit vysvětlit, v čem je ten problém?

Ssouhlasím s tím, že je lepší, když ta webová aplikace nemá právo zápisu pomalu nikam; ale je docela rozdíl v "je to best practice" a "je to díra".
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 15:58:43
On jde spíš o to, co je "security best practice". Asi se shodneme na tom, že best practice není první návod na rozběhnutí něčeho, který najdu na webu.

Napsal jsi to naprosto správně. Aplikace si může dělat co chce v rámci svých práv, což v případě Linuxových serverů jsou "většinou" práva uživatele/skupiny webdata, na IIS pak IUSR_něco nebo networkservice nebo impersonifikovaného uživatele (je tam toho víc, už jsem to dlouho neklikal, tak si to nepamatuju).

To co může ta PHPková, ale klidně i nativní, CGIčková aplikace dělat se řídí právě těmihle oprávněními. Protože pod nimi běží např. apache, v tom třeba interpret PHP a pak teprve ta apka. A tyhle práva by, jak zase správně píšeš, měly být co možná nejomezenější. Proč?

Obecně. Je jedno, jestli to je PHP nebo nativní kód. A je úplně jedno, jestli to je webová apka nebo server od tlustýho klienta použvajícího ke komunikaci úplně jiný protokol (typicky RMI, RPC a pod.). mail server nebo cokoliv jiného. Vždycky pod tím běží nějaký operák, který se stará o přidělení zdrojů danému procesu. Prostě jakmile je to vyzadekený na síť, existuje hrozba, že se to někdo pokusí napadnout a čím víc práv ten daný server bude mít, tím víc práv bude mít i ten útočník a tím pádem, tím větší škodu může napáchat. Kromě toho, ve větších prostředích, né když s něco postavím sám, je problém s tím, že i admin může něco provést. Proto se dělí role na admina OS, admina Web server a admina aplikace.

V čem je problém konkrétně u Azure? Těch problémů je, hypoteticky, víc.

Předpoklady pro zneužití téhle díry jsou (jsou to jen základn příklady):

Vždy je předpoklad, že zapisuje na lokální filesystém (jinak bych tam nemohl jako útočník nic nahrát, že ;)

a potom:

a) aplikace je děravá, tzn. nějakým způsobem, třeba pomocí get/post parametrů jsem ji schopen manipulovat
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

tyhle požadavky se dají velmi snadno splnit. Ještě 5 let zpátky je splňovala každá druhá apka.

Zneužití:

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.

Dopady:
Můžu třeba vyměnit originální apku a odchytávat hesla
Můžu kompletně ukrást celý aplikační kód původní aplikace (což mi hrozně zjednoduší jiné kroky)
Můžu kompletně vykrást databázi (protože si zjistím connection stringy)
Můžu si začít provozovat svojí apku za cizí peníze
Ani v jednom případu nezjistím, kdo mi ty soubory na disk zapsal. Vlastně ano, byl to www-data user nebo iis iusr_ něco. A to je samozřejmě špatně.

Ochrana:
nemít zápis práva na www root
typicky se zápisová práva pro web-data skupinu nastavují jen na vybrané složky nebo soubory mimo wwwroot (třeba /var/log/apache/něco nebo /tmp/www/files) - tohle je léta uznávaný "security best practice" a každý web server, když ho vydeplojuji, má dnes takto práva nastavená. Vy co updatujete Wordpress automaticky, že jste to museli nějak prasit, aby vám to fungovalo?



Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 16:05:51
Já tam napsal jiný slovo než "vyzadekený" :D To mě hodně pobavilo :D
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Tomas2 21. 05. 2017, 17:17:08

aneb řečeno, vadí ti, že obrazy na Azure nejsou secured by default a potřebuješ k tomu admina, aby daný stroj dal do pořádku? Dobrej objev...
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 17:37:10

aneb řečeno, vadí ti, že obrazy na Azure nejsou secured by default a potřebuješ k tomu admina, aby daný stroj dal do pořádku? Dobrej objev...

Uz jsem to psal... U AppService nejde nic takoveho udelat explicitne. Je to sluzba ber jak je. Neni tam nic jako moznost nastaveni prav.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Filip Jirsák 21. 05. 2017, 18:11:42
Ach jo. Docela mě mrzí, že vaše povědomí o bezpečnosti je takové jaké je. Jen doufám, že neprovozujete žádné webové služby. Nebo aspoň takové, kde byste mohl svým zákazníkům spíše uškodit. Nebo s tímhle přístupem raději žádné.
Tahle fáze je vždycky zábavná. Přijde někdo, kdo předvádí znalosti, jako by si právě přečetl knížku „Učebnice něčeho pro zelenáče“, a začne se pohoršovat nad tím, jak to všichni kolem dělají špatně. Přičemž obvykle není schopen to podpořit žádnými argumenty a protiargumenty ostatních nechápe, protože to v učebnici pro zelenáče nebylo.

Podle vás jsem měl obsah sdělení přepsat sem? Primárním účelem bylo varovat
Ono by vám to jedině prospělo, kdybyste měl jednou větou zformulovat, v čem je problém.

Jinak by asi bylo dobré uvědomit si, že tohle je diskusní fórum. Na diskusním fóru se diskutuje, neslouží k varování. Diskutovat se dá třeba o tom, jestli to, co vy považujete za chybu, je opravdu chyba. Jenže to byste musel napsat, že to a to považujete za chybu z toho a toho důvodu.

chce provozovat v Azure aplikaci na App Service, aby věděli, že pokud si nezabezpečí svoji aplikací tím, že ji napíšou správně (a věřte, že to nejde a vždy se najde nějaká chyba)
Nikoli. „Zabezpečit aplikaci“ v tomto případě znamená zajistit, aby s její pomocí útočník nemohl zapsat na server soubory, které by mohl server nebo klient interpretovat. To není zas až tak těžké, resp. programátor se musí trochu snažit, aby takovou chybu vůbec vyrobil. Pokud takovou chybu někdo vyrobí, je to proto, že na bezpečnost úplně kašle – a pak bude mít v aplikaci nejspíš ještě spoustu jiných bezpečnostních chyb, před kterými ho server zachránit stejně nemůže.

Ostatně je to vidět i na vás, kdy jste si sice uvědomil riziko interpretace kódu na serveru, ale úplně jste pominul riziko interpretace kódu (např. JavScriptu) na klientovi.

aby si by byli vědomi toho, že pomocí téhle zranitelnosti budou útočníci schopni v rámci daného oprávnění IIS udělat úplně všechno. Vykrást databázi, bezpečnostní klíče i vlastní  kód aplikace. A bohužel, mnohem hůře, vydeployovat si svou aplikaci a např. phishovat hesla.
Ne pomocí téhle zranitelnosti, pomocí té chyby v aplikaci. Víte, jak řeší WordPress ty autoaktualizace, když web server nemá práva zápisu do souborů webu? Vyžádá si od váš přihlašovací údaje pro FTP přístup a aktualizuje se přes něj. Ve vašem pojetí je FTP přístup „zranitelnost serveru“, přes kterou může útočník získat kontrolu nad serverem a v rámci jeho oprávnění udělat úplně všechno. Ano, je to tak, a proto se přístup k FTP drží v tajnosti a proto se neumožňuje komukoli zapisovat do souborového systému web serveru.

Ano, je rozumné umožnit správci serveru zakázat uživateli, pod kterým běží ten server, zápis do souborového systému. Pokud to aplikace nepotřebuje, může si to její správce nastavit jako další vrstvu ochrany – třeba jako hashování hesel. Ale není to primární ochrana. Když zakážete zápis do souborového systému, a nějaká aplikace ho bude potřebovat, bude si příslušná data místo toho ukládat do databáze – a jsme tam, kde jsme byli, když to bude napsané špatně, umožní to útočníkovi spouštět kód v kontextu webového serveru nebo prohlížeče.

upozornit na to, jak Microsoft reaguje na oznámení o bezpečnostních hrozbách
Poslali vás do háje? To by byla adekvátní reakce na někoho, kdo sotva pochytil nějaké základy, a hned sebevědomě tvrdí, že tam mají vážnou chybu, a nenechá si to vysvětlit.

s mým blogem to nemá nic společného. ten blog jsem založil jen kvůli tomu, abych tam zveřejnil tuhle zranitelnost. To až potom jsem se rozhodl přidat tam i další příspěvky.
Naopak, váš původní komentář je čistě jen propagace toho vašeho příspěvku na blogu. Z obsahu toho „diskusního“ příspěvku jsme se nedozvěděli nic, akorát pod čarou se dalo tušit, že zase další zelenáč zavítal do oblasti bezpečnosti, zaregistroval nějaký úplný základ a na jeho základě učinil objev, se kterým se hned musí pochlubit – místo aby se pokorně snažil to celé pochopit. Po rozkliknutí odkazu (udělal jsem to, až když tady byly nějaké komentáře – ráno jsem ten příspěvek rovnou nahlásil jako spam a odkaz jsem ani nerozklikával) se tušení potvrdilo.

zjistit, kolik lidí má o takovou informaci zájem
K informaci to má hodně daleko. Aby to byla informace, musel byste se oprostit od představy, že jste objevil bezpečnostní díru, a místo toho pro ostatní zelenáče popsat, že dovolit uživatelům vytvářet na serveru obsah je vždy rizikové. A že jedním z rizik je, když uživatelům dovolíte na server nahrávat soubory – že je pak potřeba si ověřit, jak je server nakonfigurovaný a co s těmi soubory bude dělat – na základě jejich umístění, názvu, obsahu.

kolik si jí zhruba přečete
Právě proto jsem na ten odkaz původně neklikal. Musíte si ale uvědomit, že když lidé klikají na odkaz, nevědí ještě, co je na cílové stránce. Takže když si přečtou to, co jste v úvodním komentáři napsal, mohou se řídit jenom tím – takže na odkaz kliknou ti naivnější, kteří si myslí, že je to o bezpečnostní díře v Azure AppService, a pak na to klikne ta většina, která se chce pobavit tím, co zase vyplodil někdo, kdo umí změnit obrázek na ploše Windows, tak už si o sobě myslí, že je bezpečnostní odborník.

I kdyby to mělo mít 1% dopad na povědomí o výše uvedeném nebo zvýšení povědomí o bezpečnosti obecně, je to pro mě obrovský úspěch.
Ano, kdyby tohle způsobilo zvýšení povědomí o bezpečnosti, byl by to opravdu nečekaný úspěch. Zatím to ale vypadá, že pro zvýšení průměrného povědomí o bezpečnosti můžete nejvíc udělat tak, že se budete sám vzdělávat.

A proč bych vás měl vodit za ručičku. Vy neumíte číst? Nebo použít Google?
Nejde o to, abyste za ručičku vodil mne. Jde o to, že kdybyste se to pokusil vysvětlit, třeba by vám došlo, že toho o problému zas tak moc nevíte a že si to nejdřív musíte lépe nastudovat.

Zjevně ano, když reagujete na něco, o čem, zase - jako jiní reagující, nic nevíte a předem si nic nezjistíte.
No, pokud jde o úroveň znalostí, jste v této diskusi na chvostu vy. Jsou tu i jiní diskutující, kteří jsou v obraze podstatně lépe než vy.

App Service je služba typu SAAS. To je software as a service. I když v tomhle případě je to mnohem více, zahrnul bych to do téhle kategorie. To znamená, že o komplet podvozek se vám stará provozovatel. Nicméně, u takového typu služeb máte jen minimální možnost, jak něco nakonfigurovat. A vězte, že tam rozhodně nemáte roota. Výhoda této služby je, že skutečně jen deployujete aplikaci a nemusíte se starat o instalaci, konfiguraci, ale hlavně zabezpečení a aktualizace celého toho ansáblu, který je k provozu vašeho businessu potřeba.
Jenže provozovatel se stará o vše od úrovně webového serveru níž. Samotná webová aplikace už je vaše starost, a to včetně zabezpečení. Tam vám provozovatel SaaS žádným způsobe nepomůže a musíte prostě počítat s tím, že veškerá práva, která máte jako provozovatel aplikace, můžete chybami ve vaší aplikaci zpřístupnit i útočníkům. Když v té aplikaci budete mít chybu SQL injection, může útočník manipulovat s databází – a není to chyba provozovatele webového serveru, ale chyba vaší aplikace. A když tam budete mít chybu file injection, je to zase chyba vaší aplikace.

máte 777 na wwwroot
Což nutně nemusí být chyba.

První pravidlo bezpečnosti je, že neexistuje žádná obecná bezpečnost, kterou buď máte nebo nemáte. Vždy se jedná o zabezpečení konkrétní aplikace, kterou musíte zabezpečit tak, aby dál poskytovala služby, které poskytovat má. Pokud ta aplikace má umožňovat nahrávání souborů na server, je samozřejmě obtížnější to zabezpečit – ale pokud to dělat má, tak je holt potřeba se tomu zabezpečení věnovat.

default admin admin
To je úplně něco jiného, k tomu není žádný důvod a pokud je tohle přístupné z venku, není to žádné zabezpečení. To, že může webový server zapisovat soubory, které může následně číst a případně interpretovat, samo o sobě žádná chyba není.

Opět. Další. Nic o tom nevíte a píšete. Proč si o tom nejdříve něco nepřečtete
Vy jste s tím začal.

Azure není obecný web server.
Ne? Vy tam nemůžete nahrát libovolný soubor, který od následně bude servírovat klientům? Už jen to samo o sobě by na funkci „obecný web server“ stačilo.

A jak jsem na to přišel? Asi tak, že jsem si s tím hrál a přečetl jsem si spoustu dokumentů jak o funkčnosti, tak o zabezpečení. A věřte, že je to moc pěkné čtení. Asi tak jako když vám šmejdi nabízí hrnce. To se taky pěkně poslouchá.
Pak byste si měl také přečíst nějaké základy. Třeba o tom, že za bezpečnost každé aplikace je zodpovědný její autor, a nikdy není možné zabezpečit aplikaci jenom tím, že pro její vytvoření nebo provoz použijete nějaké nástroje. Ty nástroje vám mohou pomoci (např. když se pro přístup k SQL databázi standardně používá binding parametrů a ne skládání stringů), ale nikdy bezpečnost nevyřeší za vás.

Já to právě, a asi i boužel, chápu moc dobře. Jenže ta autoaktualizace musí být spuštěná z důvěryhodných zdrojů, důvěryhodným uživatelem a ideálně odděleně od "nedůvěryhodného" (nebo raději méně důvěrného, aby mě zase netahal někdo za slovíčko).
Ne, bohužel to asi nechápete vůbec. Autoaktualizace znamená, že a aplikace aktualizuje sama sebe, s těmi oprávněními, které má jako webová aplikace, a dělá to automaticky, bez zásahu uživatele. Ano, je to šílené, je to berlička pro situace, kde neexistuje rozumná správa software, ale bohužel se tenhle mor z Windows šíří i na jiné systémy.

Správně je to tak, že autoupdate proces běží pod separátním účtem, stáhne si co potřebuje a aktualizuje wwwroot.
Ano, jenže to už pak není autoupdate (kdy aplikace aktualizuje sama sebe), ale běžný update správcem aplikací.

Protože nejdříve by se měla udělat revize a testování aktualizace ze všech pohledů, než se vůbec nasadí. Na wordpressu je o tom celý ansábl dokumentů, jak to dělat správně a bezpečně. Já to nečetl. Nemám ho rád. A naštěstí jsem ho nikdy nemusel deployovat nebo s ním něco dělat.
WordPress obvykle neprovozují lidé, kteří by byli schopní dělat nějaké testy před nasazením. Tam je úspěch to, že se to zaktualizuje dost rychle samo, takže těch nezabezpečených WordPressů není tolik, kolik by jich mohlo být. Ano, autoaktualizace jsou velmi špatné řešení, ale pořád výrazně lepší, než neaktualizovaný WordPress. To, že se prosadil zrovna takhle děravý systém, mne vůbec netěší, ale když už to tak dopadlo, je potřeba aspoň minimalizovat škody.

Mimochodem, přečetl jste si ten dokument, na který odkazuji v blogovém příspěvku? Hardening WordPress?
Pořád mne fascinuje, že si někdo přečte jeden článek někde na webu, a hned se považuje za experta.

Máte to napsané i v tom vlastním zápisku. „standard 755/644 respectively“ Víte, co znamená pro vlastníka adresáře práva 755? Důležitá je ta sedmička, a ta říká „právo pro čtení, zápis a procházení adresářů“. Pro soubory ta šestka znamená „čtení a zápis“. Víte, kdo je typicky vlastníkem těch souborů WordPressu? Uživatel, pod kterým běží webový server. V případech, kdy to tak není, musíte pro adresáře, do kterých WordPress dělá upload, nastavit práva jinak, aby tam mohl i ten webový server zapisovat. Což se v té příručce pro zelenáče nedozvíte, tam je jenom ten úplně nejjednodušší postup. Víte, co to celé znamená? Že ty webové servery, na kterých běží WordPress, jsou typicky nakonfigurované právě tak, jako Azure AppService – tedy že uživatel, pod kterým běží web server, má právo zápisu do oblasti, odkud web server servíruje obsah a odkud také spouští skripty. Díky tomu bylo třeba docela snadné do WordPressu naprogramovat tu autoaktualizaci nebo instalaci pluginů přes webové rozhraní, díky tomu se WordPress může „instalovat“ (ona je to spíš konfigurace) přímo přes webový prohlížeč. Ono by to šlo i bez toho, ty soubory by se ukládaly do databáze a interpretovaly odsud, ale to by jednak omezilo kešování na straně webového serveru, ale hlavně by to bylo ještě náchylnější na bezpečnostní díry, než současný WordPress. Takže díky za ta práva -w- na těch webových serverech.

Víte, ono to není o tom, že si přečtete půlku informací (nebo vlastně spíše žádné, ty se obvykle hledají, až když clověk neví jak dál), stáhnete si worpress, vyklikáte si tři volby v instalátoru a považujete svojí práci hotovou. Když to chcete brát vážně, je potřeba to nastudovat komplet. Že to je moc práce? Souhlasím. Nebo spousta let praxe.
Teoreticky to máte zmáknuté dobře. Tak teď ještě abyste se tím začal řídit.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Sten 21. 05. 2017, 18:24:03
Milý pane odborníku, Azure App Service není SaaS. SaaS je služba, kdy vám někdo pronajme hotový software provozovaný na jejich infrastruktuře. Takové služby nabízí třeba GitHub či Atlassian. Rule of thumb je, že k tomu software nemáte zdrojáky a nestaráte se o aktualizace. Azure App Service je PaaS. To je docela zásadní rozdíl, co se týče nároků na zabezpečení.

PCI DSS nevyžaduje, aby aplikace neměla možnost měnit své chování či se aktualizovat. Pojem „security best practice“ se v PCI DSS oddílu 6 nevyskytuje vůbec, nejbližší podobný termín „industry standards and best practices“ se týká jen vývoje, a to nejspíš protože je to tak abstraktní pojem, že je prakticky nevymahatelný.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Filip Jirsák 21. 05. 2017, 18:28:38
Vždy je předpoklad, že zapisuje na lokální filesystém (jinak bych tam nemohl jako útočník nic nahrát, že ;)
To je chybný předpoklad. Pokud ta aplikace bude zapisovat do databáze, může vzniknout úplně stejný problém. Typický příklad je script injection – třeba diskusní fórum, kde bude moci útočník vložit do svého příspěvku javascriptový kód, který se následně provede v kontextu diskusního fóra všem, kteří se na příslušnou webovou stránku podívají. A samozřejmě – v závislosti na aplikaci – v té databázi může být uložen i kód, který může provádět server. Doufám, že nebudete dál hájit svůj přístup a tvrdit, že v tom případě nemá Azure AppService povolit ani zápis do databáze.

a) aplikace je děravá, tzn. nějakým způsobem, třeba pomocí get/post parametrů jsem ji schopen manipulovat
Pak je potřeba tuhle chybu opravit.

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
Buď k tomu mají přístup jen důvěryhodní lidé, a u těch se předpokládá, že škodit nebudou. A samozřejmě je nutné zabezpečit, že se k tomu rozhraní nedostane nikdo nepovolaný. Naopak, kdyby web server nepovoloval zápis souborů, budou tyhle funkce b) až d) úplně k ničemu.


tyhle požadavky se dají velmi snadno splnit. Ještě 5 let zpátky je splňovala každá druhá apka.
Což je problém těch aplikací a je nutné jej opravit v té aplikaci. Na úrovní webového serveru to není řešitelné – jak jsem psal výše, když aplikaci zakážete zapisovat do souborového systému, upraví to programátor tak, aby to zapisoval do databáze, a udělá tam úplně tu stejnou chybu.

nemít zápis práva na www root
To není ochrana, je to pojistka pro případ, kdy primární ochrana (v aplikaci) selže. A často tahle pojistka není použitelná. Např. byste asi marně hledal veřejný PHP webhosting, kde web server nemá právo zápisu do adresářů, odkud se servíruje obsah – protože by si uživatelé stěžovali, že jim tam nefunguje spousta aplikací.

tohle je léta uznávaný "security best practice" a každý web server, když ho vydeplojuji, má dnes takto práva nastavená.
Tohle si můžete nastavit na svém serveru, když víte, jaké požadavky má aplikace, kterou tam budete instalovat. Na veřejném hostingu je to neprůchozí.

Vy co updatujete Wordpress automaticky, že jste to museli nějak prasit, aby vám to fungovalo?
Vždyť to máte napsané v závěru toho vašeho blogového zápisku. Standardní právo write pro vlastníka, tedy pro webový server. Funguje to tak na každém veřejném PHP webhostingu. Takové ty vaše větičky o tom, jak byste se měl dovzdělávat, už si jistě doplníte sám.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 19:20:19
Milý pane odborníku, Azure App Service není SaaS. SaaS je služba, kdy vám někdo pronajme hotový software provozovaný na jejich infrastruktuře. Takové služby nabízí třeba GitHub či Atlassian. Rule of thumb je, že k tomu software nemáte zdrojáky a nestaráte se o aktualizace. Azure App Service je PaaS. To je docela zásadní rozdíl, co se týče nároků na zabezpečení.

Mate samozrejme pravdu. Ruka byla rychlejsi nez myslenka. Je to PaaS. To ale neznamena, ze to, za co ma odpovednost provozovatel bude zabezpeceno jinak nebo mene. Konkretne u App Service nemate moznost cokoliv managovat a nastavovat opravneni, tzn. melo by to byt utazeno pokud mozno co nejvice. Nelze se spolehat na bezpecnost aplikace. To bysme potom mohli rici, ze aplikace se postara o veskerou bezpecnost.

PCI DSS nevyžaduje, aby aplikace neměla možnost měnit své chování či se aktualizovat. Pojem „security best practice“ se v PCI DSS oddílu 6 nevyskytuje vůbec, nejbližší podobný termín „industry standards and best practices“ se týká jen vývoje, a to nejspíš protože je to tak abstraktní pojem, že je prakticky nevymahatelný.

Budeme tedy slovickarit. Krome toho, ze PCI DSS je jenom a pouze bezpecnostni standard (provoz a vyvoj z ostatnich hledisek je ciste vase vec, pokud dodrzite bezpecnostni pozadavky). Pozadavek 6 standardu 3.2 (aby me tu zase nekdo neobvinil, ze pouzivam starsi, nicmene stale platny standard) rika: Develop and maintain secure systems and applications. Dale v pozadavcich (a poznamkach) pak je presne to co pisete, industry best practices a best practices. Protoze je PCI DSS bezpecnostni standard a pozadavek 6 je o "secure" systems & applications,  industry best practices a best practices = je rozhodne mysleno jako security best practices.

O te nevymahatelnosti byste se mohl chvili zkusit hadat s auditorem. Vy totiz mate podle PCI DSS standardu (hlavne pozadavek 2, ale v podstate se jedna o vsechny pozadavky) povinnost presne zdokumentovat a prokazat na zaklade jakych best practices a guides a standards provadite jake cinnosti a take to na vyzadani predvest. A to ze to tak nedelate se prokaze velmi rychle. Pro systemy a jejich konfiguraci se casto pouziva CIS, pro vyvoj SW treba OWASP, pro penetracni testovani treba NIST nebo take OWASP. Uznavaji se take konfiguracni standardy a hardening guides vyrobcu jednotlivych produktu. Jako je prave treba hardening guide k WordPressu.

Pozadavek 6 se vztahuje hlavne k aplikacim, to ano, ale k systemum take. On se tak nejmenuje jen tak nahodou. Jinak systemum jako takovym se venuje hlavne bod 2, do ktereho by pravdepodobne spadla i mnou uvadena zranitelnost, protoze je to konfiguracni chyba.  Pozadavek 2 o konfiguracnich standardech a jejich dodrzovani, jenze uz jsem psal vyse, ty nejsou verejne k dispozici, takze neni mozno zjistit, jestli a jak je porusen. U pozadavku 6 je to vcelku jasne. Proste neudrzuji secure systems.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Filip Jirsák 21. 05. 2017, 19:48:37
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.

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ář.

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?
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Martin Dráb 21. 05. 2017, 20:20:07
Citace
Konkretne u App Service nemate moznost cokoliv managovat a nastavovat opravneni, tzn. melo by to byt utazeno pokud mozno co nejvice

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.

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.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 20:57:22
Tahle fáze je vždycky zábavná. Přijde někdo, kdo předvádí znalosti, jako by si právě přečetl knížku „Učebnice něčeho pro zelenáče“, a začne se pohoršovat nad tím, jak to všichni kolem dělají špatně. Přičemž obvykle není schopen to podpořit žádnými argumenty a protiargumenty ostatních nechápe, protože to v učebnici pro zelenáče nebylo.

Víte, řekl bych to takhle, až budete mít naježděno dopředu to co já nacouváno.... Dělám bezpečnost přes 10 let, z toho 4 roky ve finančním sektoru, zhruba 250 Web App pentestů, 50 infrastrukturních a pár dalších zajímacých. Předtím 8 let praxe admina od sítí přes os až po aplikace. A ještě předtím něco málo profesionálního developmentu v Delphi a PHP. Obecně je programování tak trochu i můj koníček, takže tomu se více nebo méně věnuji vlastně pořád, v různých jazycích od c po javascript. Takže abych to uzavřel, řekl bych, že o tom vím jen o malinkou píď víc než kdybych si jen přečetl knihu "42 for Dummies".

Ono by vám to jedině prospělo, kdybyste měl jednou větou zformulovat, v čem je problém.

Jinak by asi bylo dobré uvědomit si, že tohle je diskusní fórum. Na diskusním fóru se diskutuje, neslouží k varování. Diskutovat se dá třeba o tom, jestli to, co vy považujete za chybu, je opravdu chyba. Jenže to byste musel napsat, že to a to považujete za chybu z toho a toho důvodu.

To, co předvátíte je pouze zbytečné pruzení. V blogu jsem to jednoznačně vysvětlil, ve fóru nalinkoval a očekával diskuzi. No a teď o tom diskutujeme, že? Takže účel svetí prostředky. Na blogu jsem varoval, na fóru o tom diskutujeme.

Nikoli. „Zabezpečit aplikaci“ v tomto případě znamená zajistit, aby s její pomocí útočník nemohl zapsat na server soubory, které by mohl server nebo klient interpretovat. To není zas až tak těžké, resp. programátor se musí trochu snažit, aby takovou chybu vůbec vyrobil. Pokud takovou chybu někdo vyrobí, je to proto, že na bezpečnost úplně kašle – a pak bude mít v aplikaci nejspíš ještě spoustu jiných bezpečnostních chyb, před kterými ho server zachránit stejně nemůže.
Ostatně je to vidět i na vás, kdy jste si sice uvědomil riziko interpretace kódu na serveru, ale úplně jste pominul riziko interpretace kódu (např. JavScriptu) na klientovi.
tomuhle v kontextu k tomu co jsem napsal vůbec nerozumím. Napsal jsem (jinými slovy), že pokud zprasím apku, tak mě AppService nezachrání. Přesto že by měla. Můžete mi vysvětlit, jak se vztahuje Stored XSS k deploymentu vlastní aplikace na server? Mícháte hrušky a jablka. Bavíme se primárně o zranitelnosti "DEPLOYMENT ČEHOKOLIV NA SERVER", který má nějaké předpoklady. Jako třeba připojení k síti. Nebo děravou apku. A proč to můžu udělat? Protože tomu server nezabránil. To, že tomu primárně nezabránila aplikace, to je jiná zranitelnost. A může to být 100+1 různých druhů zranitelostí, proč tomu aplikace nezabránila. Také to nemusí být zranitelnost, ale feature aplikace, která se spoléhá na zabezpečení podvozku. Těch vektorů je zde mnogo.

Ne pomocí téhle zranitelnosti, pomocí té chyby v aplikaci.
Ne. Přesne pomocí zneužití této chyby se to povede. Kdyby tam nebyla, nevydeployuju nic. I kdyby padaly trakaře a aplikace byla zprasená až do aleluja. Správce serveru se prostě nemůže spoléhat na to, že to vývojář nezprasí. A musí udělat všechno proto, že kdyby to vývojář zprasil, tak aby utočník udělal co nejmenší škodu. Jenže v případě téhle zranitelnosti je škoda skoro maximální. S velmi velkou pravděpodobností, že bude totální, protože dávám útočníkovi možnost útočit i na případný sandbox nebo přímo OS.

Víte, jak řeší WordPress ty autoaktualizace, když web server nemá práva zápisu do souborů webu? Vyžádá si od váš přihlašovací údaje pro FTP přístup a aktualizuje se přes něj. Ve vašem pojetí je FTP přístup „zranitelnost serveru“, přes kterou může útočník získat kontrolu nad serverem a v rámci jeho oprávnění udělat úplně všechno. Ano, je to tak, a proto se přístup k FTP drží v tajnosti a proto se neumožňuje komukoli zapisovat do souborového systému web serveru.

Nevím, jak to funguje s FTP přístupem, ale kdybych to navrhoval, tak cca takto: Ten updater, který updatuje Worpress běží pod jiným uživatelským účtem, než standartní web, vůbec není vystavený na web, běží ideálně na jiném serveru mimo web serverovou DMZ a jediné co může je stáhnout aktualizace z předem definovaného zdroje, ideálne přes HTTPS, FTPS nebo SFTP tak, aby byla zajištěná bezpečnost dat při přenosu s možností oveření zdroje aktualizací aplikace pomocí serverového certifikátu a pak instaluje aplikace do toho web rootu. To znamená, že k updateru nikdo, kromě admina nemůže. Ale stejně, jak jsem psal. Autoupdate není idální řešení. Aktualizace by se měly před nasazením otestovat. Jak z funkčního, tak z bezpečnostního hlediska. Ve většině prostředí také schválit jako změna.

Ano, je rozumné umožnit správci serveru zakázat uživateli, pod kterým běží ten server, zápis do souborového systému. Pokud to aplikace nepotřebuje, může si to její správce nastavit jako další vrstvu ochrany – třeba jako hashování hesel. Ale není to primární ochrana. Když zakážete zápis do souborového systému, a nějaká aplikace ho bude potřebovat, bude si příslušná data místo toho ukládat do databáze – a jsme tam, kde jsme byli, když to bude napsané špatně, umožní to útočníkovi spouštět kód v kontextu webového serveru nebo prohlížeče.

Pokud webová aplikace požaduje zápis do wwwroot, tak je to chyba v designu. Typicky, aplikace může zapisovat pouze do logů a nějakého tempu. Nikdy rovnou tam, co je znovu přístupné z webu. Validace toho, co tam můžu zapsat je samozřejmostí. Také by nikdy neměl být nastaven atribut Execute na takto zapsané soubory. Plus spoustu dalších věcí.

Pokud bude aplikace zapisovat data do SQL, tak se mi s velkou pravděpodobností nepodaří takové soubory na serveru vůbec zpustit. Jak bych to asi udělal? Pokud tedy někdo není blázen a nepoužívá nerozumně třeba PHP eval. S čímž už jsem se samožřejmě také párkrát setkal.

Poslali vás do háje? To by byla adekvátní reakce na někoho, kdo sotva pochytil nějaké základy, a hned sebevědomě tvrdí, že tam mají vážnou chybu, a nenechá si to vysvětlit.

Víte, s vámi je těžká práce. Nejste chopen pochopit, o co tady běží. Až se nahackujete aspoň na tři servery, dejte mi vědět. Ok? Jejich reakce byla taková, že jsem jim musel 3x vysvětlit o co běží, pak se 2 měsíce nikdo neozval a pak, když jsem pohrozil, že to zveřejním, odpověděli, že to je by design. Tak to mě zvedlo ze židle a proto to šlo ven. By design to být může, podle best practices (a to podle worpress hardening guide i jejich vlastních - prosím otevřete tehnle tehnle link, než zase napíšete nějakou hloupost - https://codex.wordpress.org/Hardening_WordPress#File_Permissions) to rozhodně není.


Citace
Spousta zelenáčů. neschopnosti, neznalosti, amatérismu...

Samozřejmně. Máte pravdu. Udělal jsem reklamu svému blogovému příspěvku. O tom se hádat nehodlám. Proč jsem to udělal jsem vám už vysvětlil. Ten zbytek komentovat nebudu, za to mi, takový amatér jako vy nestojí.

máte 777 na wwwroot
Což nutně nemusí být chyba.

Což samozřejmě z bezpečnostního pohledu je chyba naprosto zásadní.

První pravidlo bezpečnosti je, že neexistuje žádná obecná bezpečnost, kterou buď máte nebo nemáte. Vždy se jedná o zabezpečení konkrétní aplikace, kterou musíte zabezpečit tak, aby dál poskytovala služby, které poskytovat má. Pokud ta aplikace má umožňovat nahrávání souborů na server, je samozřejmě obtížnější to zabezpečit – ale pokud to dělat má, tak je holt potřeba se tomu zabezpečení věnovat.

Naopak. Obecná bezpečnost existuje a má svá pravidla. To že je neznáte neznamená, že neexistují. Pár úplně těch nejzákladnějších: Co nemusí ven, zůstane uvnitř. Co není potřeba, není nainstalováno. Co není potřeba, je zakázáno. Co je potřeba, to se povolí, pokud to má svůj business důvod, je riziko akceptovatelné nebo lze dopady snížit na akceptovatelnou úroveň.

Azure není obecný web server.

Ne? Vy tam nemůžete nahrát libovolný soubor, který od následně bude servírovat klientům? Už jen to samo o sobě by na funkci „obecný web server“ stačilo.
Ne. Azure AppService opravdu není jen obyčejný obecný webový, lépe řečeno aplikační server. Je to služba se spoustou dalších věcí. Ale z vašeho pohledu se to tak může jevit.

...

Správně je to tak, že autoupdate proces běží pod separátním účtem, stáhne si co potřebuje a aktualizuje wwwroot.
Ano, jenže to už pak není autoupdate (kdy aplikace aktualizuje sama sebe), ale běžný update správcem aplikací.

Prosím? Takže když dám do cronu skript, který je dodáván s aplikací, tak je to aktualizace správcem aplikací. To je pro mne novinka. To jsem nevěěl.

Protože nejdříve by se měla udělat revize a testování aktualizace ze všech pohledů, než se vůbec nasadí. Na wordpressu je o tom celý ansábl dokumentů, jak to dělat správně a bezpečně. Já to nečetl. Nemám ho rád. A naštěstí jsem ho nikdy nemusel deployovat nebo s ním něco dělat.
WordPress obvykle neprovozují lidé, kteří by byli schopní dělat nějaké testy před nasazením. Tam je úspěch to, že se to zaktualizuje dost rychle samo, takže těch nezabezpečených WordPressů není tolik, kolik by jich mohlo být. Ano, autoaktualizace jsou velmi špatné řešení, ale pořád výrazně lepší, než neaktualizovaný WordPress. To, že se prosadil zrovna takhle děravý systém, mne vůbec netěší, ale když už to tak dopadlo, je potřeba aspoň minimalizovat škody.

Konečně jste uhodil hřebíček na hlavičku. To je poprvé, co s vámi souhlasím. Krásné místo pro hackery.

Pořád mne fascinuje, že si někdo přečte jeden článek někde na webu, a hned se považuje za experta.

Asi myslíte hardening guide k word pressu. Vsadil bych si, že jste doteď ani netušil, že něco takového existuje.

Máte to napsané i v tom vlastním zápisku. „standard 755/644 respectively“ Víte, co znamená pro vlastníka adresáře práva 755? Důležitá je ta sedmička, a ta říká „právo pro čtení, zápis a procházení adresářů“. Pro soubory ta šestka znamená „čtení a zápis“. Víte, kdo je typicky vlastníkem těch souborů WordPressu? Uživatel, pod kterým běží webový server. V případech, kdy to tak není, musíte pro adresáře, do kterých WordPress dělá upload, nastavit práva jinak, aby tam mohl i ten webový server zapisovat. Což se v té příručce pro zelenáče nedozvíte, tam je jenom ten úplně nejjednodušší postup. Víte, co to celé znamená? Že ty webové servery, na kterých běží WordPress, jsou typicky nakonfigurované právě tak, jako Azure AppService – tedy že uživatel, pod kterým běží web server, má právo zápisu do oblasti, odkud web server servíruje obsah a odkud také spouští skripty. Díky tomu bylo třeba docela snadné do WordPressu naprogramovat tu autoaktualizaci nebo instalaci pluginů přes webové rozhraní, díky tomu se WordPress může „instalovat“ (ona je to spíš konfigurace) přímo přes webový prohlížeč. Ono by to šlo i bez toho, ty soubory by se ukládaly do databáze a interpretovaly odsud, ale to by jednak omezilo kešování na straně webového serveru, ale hlavně by to bylo ještě náchylnější na bezpečnostní díry, než současný WordPress. Takže díky za ta práva -w- na těch webových serverech.

Tady máte pravdu, ale jen do určité míry. Azure není správně nakonfigurován. Víte proč? Protože ten updated content spustím! tzn. má 777 (nebo něco podobného). Já osobně jsem i proti zápisu do www root (nebo jiné publikované složky) přímo tou službou publikovanou na web. Je to prostě nebezpečné. Ta databáze je mnohem mnohem, mnohem lepší. Nebo nějaký temp  pak background taskem profiltrovaný obsah zpět do wwwroot. Ale rozhodně ne nikdy na přímo. I když z provozního hlediska to nemusí být ideální. Ale tak už to holt chodí, co je bezpečné se špatně spravuje.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 21:00:57
Citace
Konkretne u App Service nemate moznost cokoliv managovat a nastavovat opravneni, tzn. melo by to byt utazeno pokud mozno co nejvice

Citace
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.

Citace
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 se spíše zvrtla diskuze. Ten vlastní zápis není critical, ale já bych to jako nález v pentestu jako HIGH uvedl.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 21:19:16
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.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 21:40:05
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.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 21. 05. 2017, 21:46:08
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.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: andy 21. 05. 2017, 23:11:04
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?
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Martin Dráb 21. 05. 2017, 23:11:13
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.


Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Martin Dráb 21. 05. 2017, 23:17:31
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.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: andy 21. 05. 2017, 23:18:25
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...
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: andy 21. 05. 2017, 23:35:05
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...
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 22. 05. 2017, 00:47:06
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.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 22. 05. 2017, 01:09:11
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.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: andy 22. 05. 2017, 01:48:44
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?
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 22. 05. 2017, 02:06:12
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

Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 22. 05. 2017, 02:13:04
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.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 22. 05. 2017, 02:21:02
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....
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: andy 22. 05. 2017, 02:23:31
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.
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: andy 22. 05. 2017, 02:33:29
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íš. publishnes to....
Aha, takže chápu správně, že říkáš, že z titulu writable home adresáře tam dneska žádnou vulnerabilitu nemám? Ale až tam jednou vrazim zabugovanou verzi, tak tam bude?

Mně to přijde, že tady popisuješ stav, kdy máš aplikaci děravou jako cedník, a považuješ za strašnou tragédii, že ti poskytovatel infrastrukury pár těch děr nezacpává...
Název: Re:Microsoft neumí zabezpečit web servery... Mají díru v Azure AppService.
Přispěvatel: Fis 22. 05. 2017, 02:44:17
@andy

Pochop, že zranitelnosti se nehodnotí podle toho, jestli jsou před nimi jiné nebo ne. Nebo jestli je provedeno nějaké mitigační opatření.

Příklad. Mám zranitelnost SQL injection. Je to critical. Dám před to aplikační firewall, kterým to odfiltruju. V apce je díra furt. SQL injection, Critical. Na tom se nemění zhola nic. Dokud se to neopraví v apce. Že jí aktuálně nemůžu zneužít? To ale přece neznamená, že tam není. Jen jsem snížil riziko jejího zneužití. Ale to riziko tam pořád je, to nezmizelo. A za nějakých okolností prostě může jít zneužít.