Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Doplňkové poznámky ke večerjší konferenci #HackerFest
říjen 21
Doplňkové poznámky ke večerjší konferenci #HackerFest

Jak zamezit spouštění PowerShell skriptů

Včera jste viděli množství PowerShell útoků. To v člověku automaticky vyvolává otázku - není tedy lepší ten PowerShell nějak zakázat?

Zaprvé není. Je to úplně jedno. Cokoliv uděláte v jazyce PowerShell, uděláte klidně přímo v C#. Zkompilujete a spustíte normálně ve formě exe. Ani tak vám to žádný antivirus nebude blokovat. Kdyby to chtěl blokovat, dělal by to i v případě PowerShellu. Důvod, proč to neblokoval, byl jedině ten, že to prostě blokovat nechtěl. Antiviry detekují jen a pouze známé binární signatury.

Například můj keylogger, co jsem napsal v PowerShellu, vlastně vůbec není v PowerShellu. Když se do něho podíváte, zjistíte, že je to celé v podstatě hlavně C# kód vložený dovnitř pomocí here-string. Pokud se tento kód spouští z jazyka PowerShell, stejně se musí zkompilovat.

PowerShell normálně ten text jen vyextrahuje a spustí na tom C# kompilátor (program csc.exe máte normálně jako součást instalace .NET frameworku). Vznikne DLL někde v tempu, tu si PowerShell zase načte zpět a takhle ji používá. Možno v klidu sledovat například pomocí process monitoru (procmon), který stáhnete ze SysInternals.

Všimli jste si během mé přednášky, že by to vadilo některému antiviru? Ten vznik DLL? Binární knihovny, která keylogeruje? Ne. Ani pod úplně obyčejným uživatelem.

Všimli jste si, že by antiviru vadilo, že jsem si ze sítě stáhl EXE soubor. Nebyl podepsán firmou Microsoft a přitom jeho popisek byl úplně přesně stejný, jako popisek všech Windows exe? Není to podezřelé?

Tak tolik asi k tzv. heuristice, kterou ty antiviry údajně dělají.

Zadruhé, pokud byste ho zakázat chtěli, musíte mít na paměti, že to moc nevynutíte. Rozhodně nestačí použít Set-ExecutionPolicy. Tohle nastavení se dá obejít přímo parametrem -ExecutionPolicy programu powershell.exe. Stačí tedy spouštět vaše skripty nepřímo z příkazové řádky, nebo z BAT.

Pokud se chcete zbavit i parametru -ExecutionPolicy, musíte ten zákaz udělat přes group policy z domény. Tam je to potom silnější. Nastavení najdete v počítačové části GPO objektu zde:

Computer Configuration - Policies - Administrative Templates - Windows Components - Windows PowerShell
Turn on Script Execution = Disabled

Nesmíte povolit podepsané skripty (allow only signed scripts). I obyčejný uživatel si může nainstalovat svoji vlastní důvěryhodnou autoritu a svůj vlastní podpisový (code signing) certifikát a jupí. Takže byste to museli úplně zakázat.

A to je stejně na nic. PowerShell příkazovou řádku si zločinec může spustit vždycky bez ohledu na politiku. Skript do ní prostě jenom překopíruje ze schránky a nikdo mu v tom bránit nebude. To byste museli zakázat úplně powershell.exe. Na to máte například Software Restriction Policies (SRP) už od Windows XP. Nebo na Enterprise edicích Windows je v podstatě stejný AppLocker (Application Control Policies).

Nakonec si uvědomte, jak jednoduché je stát se lokálním administratorem a prostě tahle nastavení z registrů vymazat. Při nejhorším offline.

Takže není cesta. Prostě zapomeňte. A začněte se chovat bezpečně. To byla taky ta zpráva, kterou moje přednáška měla udělovat.

Skrytá registrová hodnota a další poznámky

Zmiňoval jsem se také krátce o ukládání PowerShell skriptů v registrových hodnotách. Tak k tomu jen doplnění.

Ano, do řetězcové hodnoty v registrech od Windows Vista se vleze neomezeně :-) Omezeně jen hláškou "insufficient system resources", asi kvůli málo paměti? Na mé testovací virtuálce jsem do jedné registrové hodnoty vecpal 290 MB.

Nebo může ten skript nacpat rovnou do jména té registrové hodnoty. Jméno může mít až 16383 znaků. Jenom to musí založit až z PowerShell 3.0, protože dvojka uměla jenom 255 znaků na jméno hodnoty. Má to navíc pro útočníka pěknou vlastnost. Regedit hodnoty, jejichž jméno je delší než 255 znaků, prostě nezobrazuje. Stačí to udělat delší a nebude to vůbec přes regedit vidět.

Samozřejmě vzniká otázka, jak to tam hacker vloží, aby se v tom neobjevovaly speciální znaky. Případně, aby to nebylo možno na první pohled považovat za PowerShell. Ne že bych očekával od nějakého antiviru, že by se na to soustředil. Oni se většinou soustředí hlavně na BSOD, zátuhy, točení procesoru a mazání kdoví čeho.

Tak jak? Útočník to zkonvertuje na Base64 a má to. Bez mezer a většiny speciálních znaků, jenom US-ASCII znaky zapsatelné z klávesnice. Bleskovka zde:

[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('text, co nepujde jenom tak precist'))
# result: dGV4dCwgY28gbmVwdWpkZSBqZW5vbSB0YWsgcHJlY2lzdA==

Závěr

Ano, pochopili jste to dobře. Žádný antivirus vás neochrání před cíleným, ručně provedeným útokem člověka, který sedí u vás v síti a ví co dělá. Nevěřte řečem o heuristice. To je totální nesmysl.

A dávejte si prostě jenom pozor!

Comments

Re: Doplňkové poznámky ke večerjší konferenci #HackerFest

k těm neviditelným skrytým hodnotám (invisible hidden registry value) mám přímo příklad v PowerShellu: https://www.sevecek.com/Lists/Posts/Post.aspx?ID=523
ondass on 22.9.2015 16:33

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments