Ja tomu atombombingu teda nerozumim .... cim se to lisi od klasickeho a hojne pouzivaneho injectingu???
Jde tam snad o nejake zvyseni prav nebo neco? Kdyz jsou dva procesy spustene stejnym uzivatelem, tak je tak nejak asi normalni, ze ten druhy ho muze napadnout. Tak to snad funguje vsude ne? DLL injecting, ze se prepise nejaka funkce je snad zcela bezna pro kazdy antivir, kazdou druhou systemovou utilitu atd ......
Prece tohle funguje uplne univerzalne snad u vsech systemu ne? Minimalne v naprosto trivialni forme, ze dany proces zavru, modifikuju binarku a znova pustim .... kdyz jsou ty procesy pustene se stejnym opravnenim, tak je to vzdy o duvere ..... kdyby si takhle mohl proces zvysit opravneni injektovanim do procesu s vyssim opravnenim, to by jářku problém byl, ale hadam, ze tohle neni ten pripad, proto tomu nerozumim wocojakomajit? Podarilo se mi kdysi zcela regulerne nainjektovat 64bitovy podepsany explorer.exe pro odregistrovani hotkeys (ktere jsem chtel pouzit ve vlastnim programu) na W8.1. Tak fakt nevim, jestli jsou nejake enterprise nastroje (jako EMET), ktere tohle hlidaji a tohle jim proste unikne, to muze byt mozna spatna zprava pro nejake adminy nejakych super zabezpecenych koncovych terminalu v nejake paranoidni firme, ale bezneho cloveka se to vubec netyka .....
Tato "zranitelnost" mi nepřijde hodná jejího jména. Na tom technickém blogpostu jsou zajímavé věci, které s ní tolik nesouvisí – jak spustit kód v cizím procesu. Ale tam v zásadě nejsou žádné nové informace.
Pokud používám pro vykonání kódu v cizím procesu funkce jako QueueUserApc (NtQueueApcThread) či SetThreadContext (NtSetContextThread), bezpečnostní SW to zachytí. Navíc obě (popř. všechny čtyři) tyto funkce vyžadují příslušná oprávnění k cílovému vláknu daného procesu (pokud je nemám, mám smůlu).
Závěr je takový, že se může jednat o způsob, jak do cizího procesu dostat data, ale není vyřešen hlavní problém – jak spustit v cizím procesu kód (který. mj. ta data nějakm rozumně nakopíruje).
Jen do globální tabulky vložíš data. Pak musíš cizí proces přimět, aby je odtamtud vytáhnul, udělal spustitelnými a spustil. Na to ho musíš mít pod kontrolou, mít na to práva. Není to chyba ani zranitelnost, jak to podávají ti, kteří netuší o co jde.
Když můžeš proces ovládat, tak ho můžeš ovládat. WOW :)
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
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é).
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 .....
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.
Mozna hloupy dotaz ale neda mi to:
Jestli to dobre chapu Atom tabulky ve widlich jsou velmi podobny mechanizmus, jaky vyuziva XServer - XAtoms. Zde slouzi sice primarne ke komunikaci mezi klientem a XServerem, ale da se sekundarne vyuzit i ke komunikaci mezi jednotlivymi XClienty (napr. Window managery, nebo desk pagery a pod... jsou vylozene postaveny na tomto principu ). Myslim, ze se to da primo vyuzit nejen k prenosu dat ale i jako jista forma RPC.
Me osobne se tento mechanizmus hodne libi, ale kdyz tak ctu ten clanek, rikam si, zda neni mozne podobne zneuzit mechanizmus AtomBombingu i v tomto pripade?