Virtuální záplatování

• Vrstva pro vynucení zabezpečení, která zabraňuje pokusu o zneužití známé zranitelnosti
• Vrstva zabezpečení analyzuje a zachycuje útoky, čímž se škodlivý provoz nedostane do aplikace
• Spočívá v tom, že skutečný kód aplikace zůstane neměnný, ale pokus o zneužití zranitelnosti nebude úspěšný

Proč neopravit kód

• V reálných situacích vzniká mnoho scénářů, kdy aktualizace kódu není snadná
  • Nedostatek zdrojů - vývojáři jsou na jiných projektech
  • Software třetích stran - kód nemůže uživatel upravovat
  • Outsourcovaný vývoj - změny by vyžadovaly nový projekt
• Úpravy na úrovni kódu a virtuální záplatování se vzájemně nevylučují (mohou být prováděny současně)

Hodnota virtuálního záplatování

Minimalizace doby opravy

• Oprava zdrojového kódu vyžaduje čas
• Účelem je co nejrychleji zmírnit dopad identifikovaných zranitelností

Redukce plochy útoku

• Minimalizace vektoru útoku
• V některých případech je možné dosáhnout 100% snížení plochy útoku
• 50% redukce za 10 minut je lepší než 100% redukce za 48 hodin

Nástroje

• Existuje celá řada různých možností, které lze použít
• Zprostředkující zařízení - WAF, IPS
• Web server pluginy - ModSecurity
• Filtr aplikační vrstvy - ESAPI WAF
• Podívejte se na příklady virtuálního záplatování pomocí nástroje ModSecurity WAF

Metodologie

1. Nepřistupujte k záplatování nahodile
2. Dodržujte konzistentní a opakovatelný proces
   1. Příprava
   2. Identifikace
   3. Analýza
   4. Vytváření virtuální záplaty
   5. Implementace a testování
   6. Zotavení

Příklad veřejně známé zranitelnosti

• SQL injection

WordPress Shopping Cart Plugin for WordPress
/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php
reqID Parameter prone to SQL Injection.

• Wordpress plugin (nákupní košík) obsahuje chybu, která umožní provést SQL injection útok
• Problém je způsoben tím, že /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php neprovádí správnou kontrolu vstupu zadaného parametru reqID
• To umožní vložit nebo zmanipulovat SQL dotazy a manipulaci s libovolnými daty nebo jejich zveřejnění

Přípravná fáze

1. Proveďte úkony, nastavte procesy a frameworky virtuálního zabezpečení ještě před tím, než budete muset řešit nějaký bezpečnostní incident

• Během napadení není ideální navrhovat a instalovat firewall a další software
  • Čas hraje zásadní roli, proto je vhodné vše připravit a zprovoznit v klidu, než k incidentu dojde

Monitorujte zranitelnosti

1. Přihlaste se k odběru newsletterů dodavatele software nebo knihovny
   • Tím zajistíte, že budete informováni v případě, že dodavatel zveřejní informace o zranitelnosti

Autorizujte virtuální záplaty

1. Urychlete procesy správy a autorizace standardních záplat (záplaty je potřeba implementovat rychle)
2. Zařaďte proces virtuálních záplat do stejné skupiny s aktualizací antivirů nebo IDS
   • Urychluje to proces autorizace a testování

Nasaďte nástroje v předstihu

1. Získejte souhlasy s instalací nového software v předstihu (než dojde k incidentu)
2. Nainstalujte např. ModSecurity a připravte ho pro spuštění / aktivaci

• Je lepší mít všechny nástroje připravené, nainstalované a jen je aktivovat v případě potřeby

Rozšiřte a auditujte logy

• Standardní formát CLF neposkytuje dostatečné údaje pro reakci na incidenty

1. Zajistěte přístup k
   • URI požadavku (včetně query stringu)
   • Úplné hlavičky požadavku a odpovědi (včetně cookies)
   • Úplné tělo požadavku a odpovědi

Identifikační fáze

• Nastává, když se organizace dozví o zranitelnosti

Proaktivní identifikace

• Organizace sama vyhodnotí svou pozici v oblasti zabezpečení
• Dynamické hodnocení aplikací - penetrační testování nebo spuštění automatických nástrojů s cílem identifikace chyb
• Code review - manuální a automatické prostředky k analýze kódu za účelem identifikace chyb

1. Nespoléhejte se na oznámení o zranitelnostech od třetích stran

Reaktivní identifikace

• Kontakt s dodavatelem - dodavatel odhalí zranitelnost
• Zveřejnění zranitelnosti - úroveň ohrožení se zvyšuje s tím, jak se o zranitelnosti dozvídá více lidí
• Bezpečnostní incident - útok je v plném proudu (nutnost okamžité nápravy)

Analytická fáze

1. Určete použitelnost virtuálního záplatování
   • Ideální pro chyby typu injection, nemusí však poskytovat dostatečnou ochranu proti jiným kategoriím útoků
   1. Proveďte důkladnou analýzu základní chyby
   2. Zjistěte, zda má nástroj pro virtuální záplatování odpovídající schopnosti a detekce
2. Využijte systém pro sledování chyb
   1. Zadejte informace o zranitelnosti do systému pro sledování chyb (např. Jira)
3. Ověřte název zranitelnosti
   1. Zjistěte CVE název nebo identifikátor, případně přidejte vlastní, pokud jste zranitelnost identifikovali proaktivně
4. Určete úroveň dopadu
   • K úniku informací nemusí být přistupováno stejně jako k SQL injection
   1. Pochopte úroveň kritičnosti
5. Určete verzi software, kterého se zranitelnost týká
   1. Zjistěte, které verze jsou zranitelné, abyste určili, zda se vás týká
6. Uveďte, jaká konfigurace je nutná ke zneužití zranitelnosti
   • Některé zranitelnosti se mohou projevit pouze při určitém nastavení
7. Najděte exploit nebo vytvořte PoC
   • Mnoho oznámení o zranitelnostech obsahuje zdrojový kód, který ukazuje, jak zranitelnost demonstrovat
   1. Stáhněte a analyzujte tento kód

Fáze vytváření virtuálních záplat

1. V žádném případě neblokujte legitimní provoz - žádné false positives
2. Nepřehlédněte útoky, ani když se útočník snaží vyhnout detekci - žádné false negatives
3. Dbejte na minimalizaci jednoho ze zmíněných pravidel
4. Uvědomte si, že nemusíte implementovat kompletní opravu chyby

• Virtuální záplatování je o snižování rizik

Ruční vytváření virtuálních záplat

Allow list zabezpečení

• Poskytuje nezávislý mechanismus pro ověřování vstupů
• Určuje vlastnosti platného vstupu a zamítá vše, co nevyhovuje

1. Definujte pravidla pro každý parametr na každé stránce aplikace

Příklad

1. Ověřte, jaké jsou očekávané a běžné vstupní hodnoty
   • Pokud jste v přípravné fázi implementovali logování, neměl by to být problém

• V následujícím případě má parametr reqID obsahovat pouze celočíselné znaky - záplata může vypadat takto

##
## Verify we only receive 1 parameter called "reqID"
##
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'"
  SecRule &ARGS:/reqID/ "!@eq 1"

##
## Verify reqID's payload only contains integers
##
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "!@rx ^[0-9]+$"

• Záplata zkontroluje vstupní hodnotu a zabrání zadávání jiných znaků než celých čísel

1. Dbejte na správné přiřazení pravidel a jejich sledování v bug tracking systému

• Pro více informací si přečtěte dokument o best practices ve virtuálním záplatování

Block list zabezpečení

• Založen na pravidlech, která detekují známé a konkrétní útoky, které nepovolují

Příklad

http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1

• Útočník přidává jeden znak ' a na konec přidává SQL dotaz
• Můžeme tedy použití uvozovek zakázat

SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "@pm '"

• Block list lze obvykle implementovat rychleji, ale úniky jsou stále možné
• Allow list poskytuje lepší ochranu, ale často jde o manuální proces, který se špatně škáluje

Pozor na specifické záplaty pro dané exploity

• Pokud například autorizovaný test identifikoval zranitelnost XSS, použil následující payload

<script>
  alert('XSS Test')
</script>

• Nebylo by vhodné implementovat záplatu, která by blokovala pouze tento případ
  • Může to však poskytnout okamžitou ochranu, ale dlouhodobá hodnota je velmi nízká

Automatizovaná tvorba virtuálních záplat

• S rostoucím počtem záplat může být ruční tvorba neproveditelná

1. Využijte automatizované procesy, které automatické XML reporty převádějí do virtuálních záplat

OWASP ModSecurity Core Rule Set (CRS)

• Obsahuje skripty pro automatický převod výstupu XML z nástrojů (jako je OWASP ZAP) do ModSecurity virtuálních záplat

ThreadFix virtuální záplatování

• Zahrnuje automatizované procesy převodu XML na virtuální záplaty

Import do WAF

• Mnoho WAF má možnost importování XML z DAST a automaticky upravit profily ochrany

Implementační a testovací fáze

1. Použijte jinou aplikaci než prohlížeč pro testování záplat
   • cURL, wget
   • Lokální proxy server (OWASP ZAP)
   • ModSecurity AuditViewer

Testovací kroky

1. Implementujte virtuální záplaty pouze v logovacím módu (místo implementace jen logujete)
   1. Zajistěte, že nebudete blokovat běžný uživatelský provoz
2. Opakujte test, pokud byla zranitelnost identifikována konkrétním nástrojem nebo týmem
3. Vraťte se do fáze analýzy a zjistěte, jak problém lépe vyřešit, pokud se opakované testování nezdaří

Zotavovací fáze

Aktualizujte ticketing systém

1. Sledujte záplaty v rámci běžných procesů správy záplat
2. Vytvořte tickety s change requesty, čímž existenci zdokumentujete
   1. Zaznamenejte názvy a ID pravidel

• Aktualizace pomáhá určit metriky “doba do opravy” pro různé zranitelnosti

Pravidelně opakujte hodnocení

1. Pravidelně ověřujte, zda můžete odstranit předchozí záplaty a software nebo knihovnu aktualizovat

Reportujte a testujte

1. Spouštějte reporty, abyste zjistili, zda a kdy došlo k aktivaci některé z virtuálních záplat

Kam dál

Checklisty

• Konfigurace
• Správa závislostí
• Architektura