Jak jsme našli závažnou zranitelnost v systému Wordpress

Technologii Wordpress asi není nutné dlouze představovat. Je to tzv. content management system, díky kterému můžete vytvořit blog nebo e-shop během několika minut až hodin. Podle analýzy Kinsta běží na systému Wordpress cca. 40% webů a neustále se jeho popularita zvyšuje (pro porovnání - statistiky pro rok 2011 uvádějí, že to bylo 13.1% webů). V roce 2021 to je tedy více než 455 miliónů webů. Můžeme tedy říct, že najít a využít závažnou zranitelnost v tomto systému je velmi dobrý vektor útoku.

Závažnost útoku

V rámci kyberbezpečnosti je jedním z hlavních faktorů závažnost útoku. Tady se používá metodika s názvem CVSS verze 3.1. Spektrum skóre je od 0.1 do 10, kde se závažnost zranitelnosti označuje podle následovné metodiky:

Závažnost	Skóre
Low	0.1 - 3.9
Medium	4.0 - 5.9
High	6.0 - 8.9
Critical	9.0 - 10.0

Čím má zranitelnost vyšší závažnost, tím bývá zpravidla dopad jejího zneužití destruktivnější, a to jak z pohledu finančního (únik dat, nedostupnost severu), tak i reputačního.

Zranitelnosti Wordpressu za rok 2021

Můžeme říct, že tento rok byl z pohledu počtu zranitelností v systému Wordpress méně aktivním. Tabulka níže zobrazuje počet nalezených zranitelností v systému Wordpress v průběhu let od roku 2004.

Za tento rok bylo zatím publikováno celkem 8 zranitelností spojených se systémem Wordpress. A jenom jedna nová byla označena podle NVD NIST původně jako Critical, pozděj však byla upravena na High. Má kódové označení CVE-2021-44223 a o tom, jak ji našel Kamil, si nyní povíme.

Technické detaily

Pro technické detaily v angličtině se určitě podívejte na původní stránku nálezu, kde Kamil podrobně popsal v jeho článku jak zranitelnost využil.

Postup útoku

Všechno to začalo nápadem, kde může být nová zranitelnost typu podvržení repozitáře (název útoku dependency confusion supply chain attack). V srpnu 2021 začal Kamil pracovat na novém vektoru útoku, nyní ne ve formě podvržení JavaScript balíků, ale Wordpress pluginů. Kamil si všimnul, že velké množství Wordpress stránek používá interně vyvíjené pluginy nad rámec těch, které jsou veřejně dostupné. Výhodou Wordpressu je, že každý člověk může vytvořit a zařadit svůj plugin do této enormní databáze. Vytvořené pluginy jsou poté posuzovány a v případě splnění kritérii jsou zařazeny do tohoto seznamu.

Kritéria pro přijetí pluginu na review do Wordpressu jsou následující:

• Plugin nemá víc než 100 instalací
• Neobsahuje zakázána slova (značky, rezervovaná slova, známé pluginy, prefix wp-, …)
• Nemá žádnou viditelnou zranitelnost v kódu a názvy funkcí v kódu jsou dostatečně originální

Také platí, že pokud je vydána vyšší verze pluginu než máte aktuálně na serveru, tak vám nabídne jeho aktualizaci. Těm, kteří mají zapnuty automatické aktualizace, se plugin aktualizuje bez zásahu administrátora. V praxi to znamená, že pokud mám svůj plugin ve verzi 2.4.9. a nabídne se aktualizace na verzi 8.5.1., tak vám bude tuto aktualizaci systém nabízet.

Kamil se rozhodl vytvořit důkaz funkčnosti tohoto útoku pomocí svého pluginu, který před pár lety naprogramoval a nasadil na svém Githubu mimo databáze Wordpress pluginů. Po mírných úpravách, navýšení verze a komunikaci tam a zpátky mezi Wordpress vývojáři měl Kamil v řádech dnů plugin na oficiální stránce Wordpressu. A útok (exploitace) mohl začít.

Nyní se jen muselo počkat na požadavek ze serveru Wordpress na Kamilův web, aby si sám zažádal o update. To nastalo v průběhu několika hodin po zveřejnění nové verze pluginu v databázi Wordpressu.

Exploitace byla dokončena, další pokračování ve formě reportování chyb.

Nahlášení zranitelnosti provozovatelům webů

V době, kdy tato zranitelnost nebyla veřejná začal Kamil testovat weby na platformě HackerOne, spolu s jeho kolegou v žebříčku TOP 5 hackerů a dali vědět desítkám klientů, kteří měli tuto zranitelnost na webu. Většina to ocenila, ale našli se i tací, kteří si nedokázali představit využití tohoto typu útoku.

Tuto zranitelnost je stále možné najít na velkém množství webů v rámci ČR. Kamil oslovil ty, které měli validní formu security.txt souboru. Ze všech to byl konkrétně jeden web, který už tuto zranitelnost opravil.

Jak se bránit tomuto útoku

Pokud máte interní pluginy tak bude nejlepší je nazvat rezervovaným jménem, případně ho dát se standardním prefixem (začátkem jména pluginu) ve formátu wp-, což jsou rezervované názvy pro Wordpress pluginy a nikdo jiný si je nemůže nárokovat. Také je možnost nastavit hodnotu Update URI: false v rámci pluginu a zabráníte možnosti změny adresy pluginu na podvrženou z Wordpress knihovny pluginů.

Post mortem

Zranitelnost byla prezentována veřejnosti na konferenci OWASP Czech Chapter v Praze v den kdy byla zranitelnost představena světu. Na konferenci jsme měli rovnou dva přednášející - kromě Kamila jsem prezentoval i já (Filip) další verzi přednášky Hacking 101. Přednásky budou k dispozici v krátké době, článek pak aktualizujeme.

A co na to tým Wordpress? Odpověď z jejich strany na sebe nenechala dlouho čekat. Ze dne na den začali lidi předkládat velké množství pluginů - problém byl tak velký, že pár dní po uveřejnění zranitelnosti vydal Wordpress článek s prosbou, aby lidé netestovali postupování pluginů jiných lidí.

Pravdou však zůstává, že Wordpress má tento špatný design práce s pluginy už několik let a zatím nebyl vyřešen. Nyní jsou však vývojáři nuceni upravit způsob, jakým se nové pluginy dostávají do veřejné databáze Wordpress pluginů.

Závěr

Od analýzy zranitelnosti až po její zveřejnění uplynuly více než 2 měsíce. Může se zdát, že to je práce na několik hodin, opak je však pravdou - Kamil práci na této zranitelnosti věnoval několik desítek hodin. Stálo to však za to, výsledkem je bezpečnejší Wordpress a tim i celý internet :)