co je útok RCE (Remote Code Execution)?
vzdálené spuštění kódu se používá k odhalení formy zranitelnosti, kterou lze zneužít, když je vstup uživatele vložen do souboru nebo řetězce a celý balíček je spuštěn na analyzátoru programovacího jazyka. Toto není typ chování, které vystavuje vývojář webové aplikace. Útok vzdáleného spuštění kódu může vést k útoku v plném rozsahu, který by ohrozil celou webovou aplikaci a webový server. Měli byste také poznamenat, že prakticky všechny programovací jazyky mají různé funkce hodnocení kódu.
vyhodnocení kódu může také nastat, pokud povolíte vstupům uživatele přístup k funkcím, které vyhodnocují kód ve stejném programovacím jazyce. Tento typ opatření může být záměrně implementován za účelem získání přístupu k matematickým funkcím programovacího jazyka nebo náhodou, protože uživatelsky řízený vstup je navržen vývojářem tak, aby byl uvnitř kterékoli z těchto funkcí. Není vhodné provádět tento postup. Mnoho lidí považuje za škodlivé dokonce použít vyhodnocení kódu.
příklad kódu
podívejme se na příklad útoku na vyhodnocení kódu.
může se zdát jako lepší nápad mít dynamicky generované názvy proměnných pro každého uživatele a uložit jejich datum registrace. Toto je příklad toho, jak to můžete udělat v PHP
eval("$$user = '$regdate');As long as the username is controlled by the user's input, an attacker may create a name like this:x = 'y';phpinfo();//vygenerovaný PHP kód by se podobal tomuto:
$x = 'y';phpinfo();// = 2016';nyní můžete vidět, že proměnná je označována jako x, ale má hodnotu y. když útočník může proměnné přiřadit jinou hodnotu, bude moci vytvořit nový příkaz pomocí středníku (;). Nyní může vyplnit zbytek řetězce. Tímto způsobem nebude mít ve své práci žádné chyby syntaxe. Jakmile provede tento kód, výstup phpinfo se zobrazí na stránce. Vždy byste měli mít na paměti, že je možné v PHP a dalších jazycích s funkcemi, které mohou posoudit vstup.
uspořádání vzdáleného spuštění kódu podle původu
většina významných slabin RCE je způsobena určitými základními příčinami, které lze sledovat zpět do výchozího bodu. Seskupení vzdáleného spuštění kódu začátkem je zkoumáno následovně.
dynamické spuštění kódu
dynamické spuštění kódu je podle všech účtů nejrozšířenějším základním důvodem, který vyvolává útok na spuštění kódu. Mnoho programovacích dialektů je plánováno do té míry, že mohou produkovat kód s jiným kódem a okamžitě jej spustit. Tato myšlenka je úžasná, která řeší různé složité problémy. Ať už je to jakkoli, zlovolný útočník může tuto myšlenku ovládat, aby získal přístup a kapacity RCE.
obvykle kód vytvořený rychle závisí na určitém vstupu klienta. Kód obvykle obsahuje informace, které byly zapamatovány pro konkrétní strukturu. Když zhoubný agresor pochopí, že silný kódový věk bude využívat určité informace, mohlo by to vytvořit podstatný kód jako typ přístupu k oddělení aplikace. Pokud nebudou příspěvky klientů zkoumány, kód bude proveden podle svého cíle.
v okamžiku, kdy se rozhodnete pečlivě hledat, je dynamické provádění kódu odpovědné za dva druhy útoků založených na RCE; okamžité a obvodové.
Direct
při správě ilustrace přímého jedinečného provedení pocty si agresor uvědomí, že jejich zpětná vazba by byla využita k výrobě kódu.
nepřímé
aberantním způsobem se obává silného věku kódu s klientskými vstupy. Vstup klienta obvykle podléhá alespoň jedné vrstvě. Část vrstev může být zodpovědná za změnu příspěvku dříve, než skončí s dynamickým věkem kódu. Dodatečně, dynamický věk kódu může být následným dopadem, nikoli okamžitým využitím informací. To je důvod, proč nemusí být klientovi jasné, že dává informace, které vyplní jako blok struktury ve šrotu kódu, který by byl proveden vzdáleně.
Deserializace
Deserializace je neuvěřitelný návod k zobrazení současné okolnosti. Během deserializace by nemělo dojít k žádnému silnému věku kódu. Občas se jedná o situaci, ke které dochází, když serializovaný objekt obsahuje hrubá informační pole nebo objekty srovnatelného druhu. Věci se stávají více zmatenými, když jsou prvky článku serializovány. Deserializace by také zahrnovala určitý stupeň dynamického věku kódu.
mohlo by se zdát, že silné dialekty jsou jediné, které jsou ovlivněny serializací práce. Za předpokladu, že je to pravda, problém by byl velmi omezený. Ať už je to jakkoli, tato situace je velmi užitečná i ve statických dialektech. Je těžší dosáhnout statickým jazykem, ale rozhodně to není proveditelné.
realizace této myšlenky řídí zprostředkovatelské kapacity vytvořené deserializací. Věkové objekty za běhu jsou myslitelné s dynamickým věkem kódu. To znamená, že pokud budou informace, které budou dezerializovány, učiněny ve výzvě na dálku, zlovolný útočník by to mohl přikázat a upravit. Všude kolem plánovaných bitů kódu by se také mohlo seznámit s kaskadérským silným věkem kódu, aby bylo možné provést kapacitu, když je začleněna jako součást deserializace.
bezpečnost paměti
další základní důvod útoků RCE se ztotožňuje s bezpečností paměti nebo bezpečností API. Paměťová pohoda naráží na protiopatření kódu od získání základních částí paměti,které se nestaly. Je běžné očekávat, že nedostatek zabezpečení paměti by vedl k neoprávněnému přístupu k informacím. V každém případě pracovní rámec a zařízení závisí na paměti pro uložení spustitelného kódu. Metadata identifikující se spuštěním kódu jsou uložena v paměti. Přístup k této části paměti by mohl vyvolat ACE a RCE. Tímto způsobem, jaké jsou některé z důvodů problémů s pamětí?
nedokonalosti plánu produktu
nedokonalosti v konfiguraci produktu jsou typem slabosti paměti, ke které dochází tam, kde je chyba plánování v konkrétní skryté části. Občas, nedostatek část by mohla být kompilátor, překladač, virtuální stroj, nebo dokonce pracovní rámec část nebo knihovna. V této třídě jsou různé vady. Část včlenění;
přetečení vyrovnávací paměti
přetečení vyrovnávací paměti navíc zmiňuje jako přetečení vyrovnávací paměti, lze použít k narážce na základní a slavnou metodu, která se používá k přerušení paměti. Tento útok využívá konkrétní plán vady nebo chyby, aby zůstal v kontaktu s paměťovými buňkami, které jsou umístěny směrem k cíli paměťového polštáře. Podpora by se dostala zpět z autentického volání na veřejné API. Nicméně, cradle jen naráží na výchozí místo hrozba se používá k registraci skutečných paměťových míst konkrétního článku nebo čítače programu. Jejich oddělení od kolébky je pozoruhodné nebo lze nepochybně spekulovat. Zkoumání kódu při každém zpřístupnění nebo odstraňování problémů s prováděním celého programu za běhu může být užitečné pro agresora, který se musí podívat do relativních pozic.
to znamená, že povodeň kolébky by umožnila do určité míry změnit nedostupnou paměť. Kolébka může být nalezena v lokalizačním prostoru jednoho dalšího stroje a bude změněna voláním vzdáleného API. To umožní vstup do paměti vzdáleného počítače. Existuje mnoho přístupů k využití tohoto druhu přístupu při vytváření dvojitého obchodování RCE. Existuje celkové podezření, že za předpokladu, že je polštář povodeň slabost, rce-založené útok není z karet. To znamená, že majitelé kódu se spoléhají na to, že před útokem RCE okamžitě opraví své podpůrné povodně.
konstrukční nedostatky zařízení
útoky na blahobyt paměti mohou být také způsobeny vadami konfigurace zařízení. Nejsou tak normální jako programovací útoky a jsou mnohem těžší rozpoznat. Dosud, tento druh útoku velmi ovlivňuje rámec.
dopady chyby zabezpečení vzdáleného hodnocení kódu
útočník, který může úspěšně spustit útok založený na vzdáleném kódu v systému, by byl schopen provádět další příkazy využitím programovacího jazyka nebo webového serveru. V mnoha programovacích jazycích by útočník mohl systému přikázat psát, číst nebo mazat soubory. S napadeným systémem může být dokonce možné připojit se k různým databázím.
proč útočníci zahajují útoky RCE?
i když neexistuje žádný zvláštní důvod, proč se útočníci rozhodnou využít využití RCE k útoku na webovou aplikaci, neexistuje žádný zvláštní důvod. Je to jen to, že někteří škodliví považují za snadné využít tohoto spuštění kódu k získání přístupu k vašim systémům.
Jak Zabráníte Útokům Na Vzdálené Spuštění Kódu?
nejprve byste se měli vyhnout použití uživatelského vstupu uvnitř vyhodnoceného kódu. Nejlepší možností v této situaci by bylo zcela vyhnout se používání funkcí, jako je eval. Je to považováno za formu špatné praxe a lze se jí snadno vyhnout. Doporučuje se také, abyste nikdy nenechali uživatele upravovat obsah souborů, které mohly být analyzovány daným programovacím jazykem. Často to zahrnuje umožnění uživateli vytvořit název a přípony souborů, které chce nahrát nebo vytvořit ve webové aplikaci.
to jsou některé z věcí, které byste neměli dělat, abyste se vyhnuli útokům založeným na RCE. Patří mezi ně:
- dezinfekce vstup uživatele. Často je to obtížné dosáhnout, protože existuje velké množství předinstalovaných obchvatů a omezení.
- nechte uživatele rozhodnout nebo vytvořit příponu nebo obsah souborů, které mají být použity na webovém serveru. Musí používat mnoho bezpečných postupů při manipulaci s nahráváním souborů nebo riskovat, že důležité informace padnou do nesprávných rukou.
- předejte jakýkoli uživatelem řízený vstup do systémových zpětných volání nebo hodnotících funkcí
- aktivně zařaďte na černou listinu jakékoli speciální znaky nebo názvy funkcí. Tomu je třeba se vyhnout stejně jako dezinfekci vstupu uživatele. Je však neuvěřitelně obtížné jej implementovat.