Vlákno názorů k článku Postřehy z bezpečnosti: vkládáme kód pomocí AtomBombingu od Ondřej Novák - Já ten bezpečnostní problém nechápu jako problém atomů,...
-
Já ten bezpečnostní problém nechápu jako problém atomů, ale jako problém APC, kde je třeba možné zavolat funkci v cizím vlákně, aniž by byla nějaká možnost v cílovém procesu se tomu bránit. Ve windows se dá najít spoustu jiných míst. Svého času cokoliv co prošlo kolem PostMessage, třeba WM_TIMER obsahuje pointer na funkci, kterou je třeba zavolat - mám pocit, že už to teď nejde, nicméně pokud nějaká aplikace si přes zprávy předává adresy funkcí, které má zavolat při dispatchingu, tak je velice snadné jí tam podstrčit vlastní zprávu z adresou funkce, kterou lze pak využít k injekci. Opět možnosti, jak by se aplikace mohla bránit jsou nulové.
Onehdy jsem APC používal k ukončení vláken v DLLMain, hodně podobným způsobem (článek z roku 2008)
http://bredy.novacisko.cz/?Jak-bezpecne-ukoncit-vlakno-z-DllMain/216
-
Martin DrábStříbrný podporovatel
Abyste mohl poslat APC cizímu vláknu, musíte na něj mít handle s oprávněním THREAD_SET_CONTEXT. Je pravda, že pokud zdrojová i cílová aplikace běží pod stejným uživatelem a na stejné integrity level, tak se to dělá poměrně těžko a nebude to zrovna bezpečné vzhledem k zachování funkčnosti programu. Vlákno je objekt jádra, tedy na něj platí bezpečnostní model.
Navíc, aby vlákno vykonávalo APC, musí se dostat do "alertable" stavu. Ne všechna vlákna v takovém stavu jsou.
Zasílání zpráv byl problém... a asi stále ještě je, i když se tam také věci zlepšily (UIPI). Na druhou stranu, posílat si zprávou adresy funkcí, které pak bez kontroly zavolám, mi nepřijde jako zrovna správné řešení, když je již známo, že ty zprávy mohou přijít skoro odkudkoliv. Ale stále jsou takové aplikace.
SetThreadContext/QueueUserApc jsou funkce notoricky známé pro provádění injekcí kódu (resp. jeho spuštění), takže pokusy o získání oprávnění THREAD_SET_CONTEXT neujdou pozornosti kvalitnějšímu IPS/IDS.
Doručení APC vláknu nejprve znamená spuštění rutiny v ntdll.dll, kterou si může aplikace modifikovat tak, aby věděla o každém APC a případně je dokázala filtrovat (podobně např. pokusy o sledování jí zasílaných zpráv či keylogging skrz Windows Hooks). Bránit se dá, ale není ani snadné ani dokumentované (resp. oficiálně dokumentované).
-
JA (neregistrovaný)
Vypada, ze vy dva tomu rozumite, tak wocode?
Vlozit kod do jineho procesu a zavolat jej je prece standardni injekce. Jak jsem spal vyse, tak jsem treba odregistrovaval klavesove zkratky uvnitr explorer.exe za behu.
Proc teda k tomu pouzivat atomy? Chapu dobre, ze tahle "zranitelnost" ma vlastne nulovou vahu a je aplikovatelna jenom na specialni ochranny SW jako EMET, ktery jej nedetekuji, ikdyz by mel a na normalnim PC se tedy problem neprojevi ..... -
Martin DrábStříbrný podporovatel
Explorer obvykle běží pod vaším uživatelským účtem a se stejným oprávněním, takže tam, alespoň v době XP, injekce nepředstavovala něco zajímavého. Fakt, že se jedná o trochu speciální proces z hlediska "bariéry" User Account Control, to trochu mění.
Jinak je to prostě způsob, jak dostat data do cizího procesu. Rozdíl oprototi klasickým technikám (napřed zapíšeme kód a pak jej spustíme) je max. v tom, že tady i samotné zapisování je realizováno spouštěním kódu v cílovém procesu. Extra zajímavé to není. Víc bych v tom nehledal.
-
Martin DrábStříbrný podporovatel
Bohužel ani na novějších verzích (vyjma Visty) to nedopadlo úplně tak, jak by bylo záhodno.
ČLÁNKY DO MAILU