Vzdálené spuštění kódu (rce), vysvětleno: co to je a jak tomu zabránit

vzdálené spuštění kódu (RCE) je třída bezpečnostních chyb/zranitelností softwaru. Zranitelnosti RCE umožní škodlivému herci spustit libovolný kód podle svého výběru na vzdáleném počítači přes LAN, WAN nebo internet. Rce patří do širší třídy zranitelností libovolného spuštění kódu (ACE). S tím, jak se internet stává všudypřítomným, ačkoli, dopad zranitelností RCE rychle roste. Rce jsou nyní pravděpodobně nejdůležitějším druhem zranitelnosti ACE.

protože tomu tak je, chtěli jsme se podrobněji podívat na různé typy zranitelností RCE a možná protiopatření.

klasifikace RCE podle původu

většina, ne-li všechny, známých zranitelností RCE má malý počet základních příčin.

dynamické provádění kódu

dynamické provádění kódu bývá nejčastějším útočným vektorem vedoucím k RCE. Většina programovacích jazyků má nějaký způsob, jak generovat kód s kódem a spustit jej na místě. Jedná se o velmi silný koncept, který pomáhá řešit mnoho složitých problémů. Škodlivá třetí strana ji však může snadno zneužít, aby získala schopnosti RCE.

často je kód generovaný za běhu založen na nějakém vstupu uživatele. Více často než ne, kód obsahuje tento vstup v nějaké formě. Škodlivý herec, který si uvědomuje, že dynamické generování kódu využije daný vstup, by mohl poskytnout platný kód jako vstup k útoku na vaši aplikaci. Pokud uživatelské vstupy nejsou prověřeny, bude tento kód proveden na cílovém počítači.

obecně řečeno, dynamické provádění kódu způsobuje dvě hlavní třídy zranitelností RCE: přímé a nepřímé.

Direct

v případě přímého dynamického spuštění kódu si škodlivý herec uvědomuje, že jejich vstup by byl použit při generování kódu.

nepřímý

nepřímý případ se opět scvrkává na dynamické generování kódu včetně uživatelských vstupů. Vstup uživatele však prochází jednou nebo více vrstvami. Některé vrstvy mohou dokonce transformovat tento vstup dříve, než skončí s dynamickým generováním kódu. Také dynamické generování kódu může být vedlejším účinkem a ne primárním použitím vstupu. Jako takový, to není opravdu zřejmé, že uživatel poskytuje vstup, že vstup bude použit jako stavební blok v kódu úryvek, které mají být provedeny na vzdáleném počítači.

Deserializace

Deserializace je velmi dobrým příkladem tohoto scénáře. Zdánlivě žádné dynamické generování kódu by se mělo stát na deserializaci. To je vlastně případ, kdy serializovaný objekt obsahuje pouze datová pole primitivních typů nebo jiné objekty tohoto druhu. Věci se však komplikují, když jsou metody/funkce objektu serializovány. Deserializace pak bude obvykle zahrnovat nějakou formu dynamického generování kódu.

možná si myslíte, že dynamické jazyky jsou jediným místem, kde má serializace funkcí smysl. Problém pak bude mít omezený rozsah. Ale je to užitečný scénář ve statických jazycích, také. Je to poněkud těžší dosáhnout ve statickém jazyce, ale zdaleka ne nemožné.

poměrně často se implementace skládá z objektů / funkcí generovaných deserializací proxy. Generování objektů / funkcí za běhu je případ dynamického generování kódu. Pokud tedy data, která mají být deserializována, pocházejí z požadavku vzdáleného počítače, mohl by je škodlivý herec upravit. Pečlivě vytvořené serializované úryvky kódu mohou být injikovány, které podvádějí dynamické generování kódu, aby je provedly, když jsou vyvolány jako součást deserializace.

bezpečnost paměti

další příčina zranitelností RCE souvisí s bezpečností paměti. Bezpečnost paměti znamená zabránit kódu v přístupu k částem paměti, které inicializoval nebo nedostal jako vstup. Intuitivně můžete očekávat, že nedostatek bezpečnosti paměti povede k neoprávněnému přístupu k datům. Operační systém a základní hardware však používají paměť k ukládání skutečného spustitelného kódu. Metadata o provádění kódu jsou také uložena v paměti. Získání přístupu k tomuto druhu paměti by mohlo mít za následek ACE a případně RCE. Jaké jsou tedy hlavní důvody problémů s bezpečností paměti?

chyby návrhu softwaru

chyby návrhu softwaru jsou typem chyby zabezpečení paměti, kde je chyba návrhu v některé základní součásti. Častěji než ne, to by byl kompilátor, interpret, nebo virtuální stroj, nebo potenciálně jádro operačního systému nebo knihovny. Do této třídy patří řada různých nedostatků. Budeme se podrobněji zabývat tím, co je pravděpodobně nejběžnější.

přetečení vyrovnávací paměti nebo přetečení vyrovnávací paměti

přetečení vyrovnávací paměti (také známé jako přetečení vyrovnávací paměti) je poměrně jednoduchá a dobře známá technika, která narušuje bezpečnost paměti. Využívá konstrukční chybu nebo chybu pro zápis do paměťových buněk, které sledují skutečný konec paměťové vyrovnávací paměti. Samotná vyrovnávací paměť je vrácena z legitimního volání do veřejného API. Vyrovnávací paměť však slouží pouze jako výchozí bod pro výpočet adres fyzické paměti hodnot soukromého pole / člena nějakého čítače objektů nebo programů. Jejich relativní poloha k vyrovnávací paměti je buď dobře známá, nebo by mohla být odhadnuta. Zkoumání kódu, pokud je k dispozici, nebo ladění provádění programu za běhu může pomoci škodlivému herci získat relativní pozice.

takže přetečení vyrovnávací paměti umožňuje modifikovat paměť, která by měla být podle návrhu nepřístupná. Tato vyrovnávací paměť může být umístěna v adresním prostoru jiného počítače a může být upravena voláním vzdáleného API. To umožní přístup do paměti vzdáleného počítače. Je zřejmé, že existují různé způsoby, jak použít tento typ přístupu při instrumentaci RCE. Obecně se předpokládá, že pokud existuje chyba zabezpečení přetečení vyrovnávací paměti, je možné rce. Majitelé kódu by tedy měli opravit přetečení vyrovnávací paměti co nejdříve, ještě předtím, než se objeví skutečný útok RCE.

rozsah

přetečení vyrovnávací paměti se často zaměřuje na kód C / C++, protože tyto jazyky nemají zabudované kontroly velikosti vyrovnávací paměti. Mnoho dalších populárních rámců a technologií končí pomocí knihoven C / C++ hluboko pod povrchem, které je automaticky činí zranitelnými vůči tomuto druhu útoku.

uzel.js je toho dobrým příkladem, protože kromě toho, že je založen na C/C++, JavaScript runtime také umožňuje nativní doplňky C / C++. Z tohoto důvodu může útočník pečlivě sestavit požadavky na uzel.JS server způsobit přetečení vyrovnávací paměti a tím upravit systémovou paměť na postiženém počítači, což způsobuje spuštění libovolného kódu.

hardwarové konstrukční nedostatky

zajímavé je, že k porušení bezpečnosti paměti může dojít také kvůli chybám návrhu zabezpečení hardwaru. Zatímco méně časté a těžší je najít, takové zranitelnosti mají obvykle extrémně vysoký dopad.

Deflecting rce attacks

zatímco výsledek každého rce útoku je stejný, pokud jde o útočníka provádějícího kód, vektory útoku jsou velmi odlišné povahy. Blokování všech z nich vyžaduje značné úsilí. Úsilí navíc roste spolu s technologickým zásobníkem. Všechny útočné vektory popsané v tomto příspěvku jsou technologicky agnostické. Všechny implementace jsou specifické pro technologii, ačkoli, a tak jsou obranné mechanismy.

tradičním přístupem šetřícím čas je tedy sledování síťového provozu pro podezřelý obsah namísto sledování každého koncového bodu pomocí specifické technologie. Tuto úlohu obvykle provádí brána firewall webové aplikace (WAF). I když to šetří čas, přichází také za cenu—WAF je úzkým hrdlem výkonu sítě a postrádá všechny základní informace dostupné ve skutečném koncovém bodě nebo na úrovni aplikací a uživatelů. Analýza provozu WAF tedy nikdy nemůže být dokonalá. Heuristika je nevyhnutelná bez úplných dat, takže se buď neobjeví všechny hrozby, nebo se objeví falešně pozitivní, nebo nejčastěji obojí.

pohyb uvnitř aplikace: Sqreen přístup

Sqreen řeší tyto nedostatky WAF bez zvýšení nákladů na vývoj pro koncového uživatele přesunutím viditelnosti uvnitř aplikace, čímž přináší úplnější ochranu pomocí rašple specifické pro technologii a WAF v aplikaci. Sqreen RASP a WAF běží uvnitř skutečné webové aplikace, API nebo microservice přijímající síťový provoz. Nevyžaduje však žádnou úpravu kódu. Používá přístrojové body specifické pro každou technologii (např. JVM API pro Javu, V8 API pro uzel.js, atd.) upravit kód před spuštěním za běhu. Je tedy schopen sledovat a upravovat systémové a síťové události a zároveň mít plný kontext všeho, co se děje uvnitř aplikace.

Sqreen tak může zjistit, že aplikace používá komponenty se známými problémy s bezpečností paměti. To může také detekovat skutečné uživatelské vstupy, které dělají to na dynamické spuštění kódu událostí. Přirozeně se jedná o vynikající přístup k detekci a prevenci rce ve srovnání s tradičním WAF, který má přístup pouze k síťovému provozu.

balení

je zřejmé, že RCE je velmi silný útočný vektor. Ale, naštěstí, je možné se bránit proti útokům RCE, také. Výše uvedené informace mohou skutečně pomoci při budování vaší obranné strategie. Pokud Vás zajímají další útočné vektory a podrobnosti, podívejte se na naše předchozí příspěvky na SQL injection, XXE a LFI.