Zákazníci Azure, jejichž pravidla brány firewall spoléhají na Azure Service Tags, věnujte pozornost: Mohli byste být ohroženi kvůli zranitelnosti zjištěné Tenable Research. Zde je to, co potřebujete vědět, abyste zjistili, zda jste ovlivněni, a pokud ano, co byste měli okamžitě udělat, abyste ochránili své prostředí Azure před útočníky.
Společnost Tenable Research objevila chybu zabezpečení v Azure, která útočníkovi umožňuje obejít pravidla brány firewall založená na značkách Azure Service Tag falšováním požadavků z důvěryhodných služeb. Zákazníci, kteří spoléhají na tato bezpečnostní pravidla brány firewall, jsou touto chybou zabezpečení ohroženi. Měli by přijmout okamžitá opatření ke zmírnění problému a zajistit, aby byli chráněni robustními vrstvami ověřování a autorizace.
Tato chyba zabezpečení byla původně objevena ve službě Azure Application Insights, ale my a centrum Microsoft Security Response Center (MSRC) jsme nakonec zjistili, že se týká více než 10 dalších služeb Azure. V každém případě by útočníci měli přístup k dalším interním a soukromým službám Azure.
V komunikaci Tenable Research s MSRC o této chybě zabezpečení MSRC vysvětlilo, že Azure Service Tags mají bezpečnostní omezení.
„Servisní štítky nejsou dostatečné k zabezpečení provozu k zákazníkovi původu bez ohledu na povahu služby a provoz, který může odesílat. Vždy je nejlepším postupem implementovat autentizaci/autorizaci pro provoz a nespoléhat se pouze na pravidla brány firewall,“ stojí v jedné ze zpráv, které MSRC zaslal Tenable Research.
Zranitelnost
Více služeb v Azure umožňuje zákazníkovi vytvářet webové požadavky. Některé dokonce umožňují uživatelům přidat záhlaví k požadavku a změnit metody HTTP. To je součástí zamýšlené funkčnosti těchto služeb. Například protože funkce Azure Application Insight Availability Tests testuje dostupnost aplikací nasazených klienty, klienti vyžadují plnou kontrolu nad požadavkem k vytvoření funkčního testu.
Tato funkce však může otevřít dveře pro zlomyslného aktéra, aby dosáhl dopadu podobného dopadu zranitelnosti SSRF (server-side request forgering). SSRF umožňuje útočníkovi způsobit, aby aplikace na straně serveru zadávala požadavky na nezamýšlené umístění, ať už interní nebo externí, což útočníkovi mimo jiné umožňuje dosáhnout/odhalit zdroje, které byly dříve nedostupné.
Když služba uživatelům udělí možnost řídit požadavky na straně serveru a služba je přidružena k Azure Service Tags, může to být riskantní, pokud zákazník nemá další vrstvy ochrany.
Dopad
Tato chyba zabezpečení umožňuje útočníkovi řídit požadavky na falšování na straně serveru a vydávat se tak za důvěryhodné služby Azure. To útočníkovi umožňuje obejít síťové ovládací prvky založené na servisních značkách, které se často používají k zabránění veřejného přístupu k interním aktivům, datům a službám zákazníků Azure.
Co jsou Azure Service Tags?
Azure Service Tags zjednodušují izolaci sítě v rámci Azure seskupením konkrétních rozsahů IP IP služeb Azure. Tyto značky lze použít k definování pravidel zabezpečení sítě a konzistentní aplikaci těchto pravidel na více prostředků Azure. Azure Service Tags v podstatě poskytují pohodlný způsob správy řízení přístupu, jako jsou pravidla brány firewall nebo konfigurace skupiny zabezpečení sítě (NSG).
Pokud například jako zákazník chci povolit síťový přístup ke své soukromé službě Azure API Management Service a pouze ze samotné služby nebo jiné služby, kterou v Azure používám, mohu to udělat dvěma způsoby, pokud mají tyto služby přidružené Servisní štítky:
- Mohu specifikovat rozsahy IP služeb, které chci povolit.
- Mohu použít servisní značku přidružené služby, servisní značku „ApiManagement“, abych povolil pouze mým službám správy rozhraní API přístup k mé správě rozhraní API.
Druhá možnost je pohodlnější, takže lze bezpečně předpokládat, že si ji vybere mnoho – možná většina – zákazníků. Obě možnosti však mohou zákazníky vystavit riziku zranitelnosti, kterou popisujeme.
Technické podrobnosti – příklad Azure Application Insights
Azure Application Insights je služba monitorování a analýzy, která pomáhá vývojářům v reálném čase zjišťovat, diagnostikovat a chápat problémy ovlivňující jejich webové aplikace a služby.
Azure Application Insights má přidruženou značku služby s názvem „ApplicationInsightsAvailability“.
Funkce Application Insights Availability umožňuje vytvářet testy dostupnosti pro vaši aplikaci nebo počítač.
Při vytváření nového testu pomocí Azure Application Insights se záměrem jej použít pro interní síťovou aplikaci nebo počítač, Azure zákazníkům doporučuje, aby použili servisní značku, která umožní službě Application Insights Availability pouze monitorovat a přistupovat k vaší interní aplikaci nebo počítači přes port. 80 nebo 443:
Naivní uživatel se bude řídit radami a použije servisní značku „ApplicationInsightsAvailability“ na své soukromé aktivum v konfiguraci sítě Azure aktiva, přičemž se bude snažit dosáhnout izolace sítě. V zákulisí je povolena sada IP přidružených k agentovi Application Insights Availability.
Zajímavou částí je kombinace použití servisního štítku a funkce služby, která uživatelům umožňuje řídit požadavky na straně serveru:
Útočníci mohou zneužít funkci „test dostupnosti“, „klasického testu“ nebo „standardního testu“. Obě funkce podporují vlastní hlavičky a změnu metody HTTP. Útočníci mohou odesílat požadavky pomocí funkce testů dostupnosti služby Application Insights Availability. Díky tomu mohou přistupovat k interním službám obětí mezi nájemci, kteří slepě důvěřují značce Application Insights Availability Service Tag ve svém pravidle brány firewall. Útočníci to mohou využít k přístupu k interním rozhraním API, která jsou nyní odhalena ve službě oběti, protože odhalené porty jsou 80/443, které obvykle hostují webová aktiva.
Útočníci mohou přidávat vlastní hlavičky, měnit metody a přizpůsobovat své požadavky HTTP, jak chtějí.
Ověření konceptu
Níže uvádíme kroky, které by útočník podnikl, aby zneužil tuto chybu zabezpečení ve službách Azure App Services.
Řekněme, že uživatel nasazuje interní službu Azure App Service, tento uživatel chce, aby jeho služba App Service využívala možnosti Azure Application Insights, ale přesto zůstala izolovaná. Uživatel se toho pokusí dosáhnout použitím omezení přístupu, aby povolil pouze značku ApplicationInsightsAvailability Service:
Útočník se pokusí o přístup k interní službě App Service a dostane zakázanou odpověď:
Útočník zneužije popsanou zranitelnost ve funkci testů dostupnosti Application Insights k předstírání identity služby Application Insights a úspěšně přistupuje k interní službě App oběti. Útočník může také zobrazit odpověď a přidat vlastní hlavičky, které jsou dostupné prostřednictvím funkce „standardní test“:
Dotčené služby – varianty zranitelnosti
Po analýze zabezpečení a důvěryhodnosti Azure Service Tags prostřednictvím služby Application Insights a nahlášení našich zjištění MSRC jsme společně s MSRC našli další varianty problému ve více než 10 službách Azure.
Oceňujeme odhodlání a práci MSRC v této záležitosti.
Možnosti a rizika se u každé služby liší. Patří mezi ně:
- Azure Application Insights
- Azure DevOps
- Azure Machine Learning
- Azure Logic Apps
- Azure Container Registry
- Zátěžové testování Azure
- Správa Azure API
- Azure Data Factory
- Azure Action Group
- Azure AI Video Indexer
- Azure Chaos Studio
Společným jmenovatelem v těchto různých scénářích je tato nebezpečná kombinace: služba, která má přiřazenou servisní značku a také umožňuje uživatelům řídit požadavky na straně serveru.
Jak se těmto útokům bránit
Nejprve analyzujte síťová pravidla ve vašem prostředí Azure pro každou přidruženou službu, vyhledejte použití servisních značek a filtrujte dotčené služby. U dotčených služeb předpokládejme, že tato aktiva jsou veřejná.
Chcete-li tyto prostředky chránit, přidejte k nim vrstvy ověřování a autorizace. Přesně jak radil MSRC:
„Servisní štítky nejsou dostatečné k zabezpečení provozu k zákazníkovi původu bez ohledu na povahu služby a provoz, který může odesílat. Vždy je nejlepším postupem implementovat autentizaci/autorizaci pro provoz, než se spoléhat pouze na pravidla brány firewall.“
Zadruhé, při konfiguraci síťových pravidel služeb Azure mějte na paměti, že značky služeb nejsou vodotěsným způsobem, jak zabezpečit provoz vaší soukromé služby. Zajištěním zachování silné síťové autentizace se uživatelé mohou bránit další a zásadní vrstvou zabezpečení. V takovém případě by i útočník využívající zranitelnost k dosažení cílového koncového bodu měl velké problémy se zneužitím tohoto přístupu.
Služby Azure, které jsme uvedli v tomto blogu, jsou zranitelné. I k dalším službám neuvedeným na tomto blogu doporučujeme přistupovat se zdravou dávkou skepse a ověřit si, zda služba nemá nebezpečnou kombinaci popsanou v tomto blogu.
Zdroj: Tenable
