Postřehy z bezpečnosti: snadný výdělek bez práce – či ne?

Dnes
Doba čtení: 10 minut

Sdílet

Severokorejský uchazeč o práci
Autor: Root.cz s využitím Zoner AI
Týden započneme odhalením náborové kampaně severokorejských Chollimas – kdo by nechtěl peníze bez práce?! Dále opět zabrousíme do zranitelného AI, zmíníme React2Shell a navštívíme Indii a jejich nařízení.

Výhodná nabídka zaměstnání (zn. přes proxy)

O severokorejské skupině Lazarus již bylo dříve slyšet v souvislosti s různými technikami pašování kódu, krádežemi kryptoměn, ale také pokusy o infiltraci do západních společností.
Společné vyšetřování Mauro Eldritcha, NorthScan a ANY.RUN odhalila dlouhodobou aktivitu severokorejských IT rekruterů a jejich úsilí o průnik do západních společností, a to za účelem špionáže a výdělku. Těmto divizím se říká „Famous Chollima“ nebo také „WageMole“.

Investigace popsala několik strategií, kterými se útočníci pokoušeli oklamat náboráře v IT. Zneužívali k tomu vývojáře ochotné propůjčit svoji identitu a konektivitu. Důveřivce Severokorejci nabírali mimo jiné na Telegramu a GitHubu, kde více účtů spamovalo repozitáře s nabídkami spolupráce. Samozřejmě pod falešnou záminkou; vše je prezentováno jako přivýdělek pro vývojáře, za to, že za něj bude chodit na pohovory, absolvovat stand-upy apod.

Dokonce ani nemusí vykonávat žádnou práci, protože tu za něj bude dělat tým dalších lidí. Za tuto „spolupráci“ – propůjčení svojí identity – měli vývojáři dostat 20 až 35 %; více si vydělali, pokud jim oběti dovolili využití přímo jejich počítače. Za všechny aktivity přitom nesl odpovědnost vývojář-oběť, jehož identita byla takto využita. Většina výdělku byla poté tunelována zpět do Severní Koreje.

Eldritch jednu z těchto nabídek přijal a spolu s Heinerem García z NorthScan připravili plán k infiltraci této iniciativy. Kromě vytvoření falešné identity vývojáře z USA použili sandboxy služby ANY.RUN, která vytváří sandboxované virtuální systémy pro běh malware. Připravili tak farmu simulovaných laptopů – honeypotů, které následně sbíraly veškerou aktivitu útočníků. Tím mohli v reálném čase sledovat jejich postupy, nástroje a taktiku, a působit útočníkům potíže, či je frustrovat v jejich práci.

Zjistili, že operátoři se k počítači připojovali přes VPN Astrill, která byla použita i v jiných operacích skupiny Lazarus. Operátor si nastavili si svůj Chrome profil, což poskytlo další vhled do jejich operací, včetně Gmailu. Použity byly AI nástroje jako Simplify Copilot či AiApply pro automatizovaný průchod procesem interview, ale také Google Remote Desktop pro zajištění persistence nebo OTP klíčenky pro ukládání kódů obětí. Operátoři také pravidelně sbírali informace o stavu stroje a prostředí.

V průběhu jedné z relací na počítači dokonce operátoři ponechali otevřený Notepad s požadavkem na doplnění jejich čísla sociálního pojištění (SSN), bankovních spojení, ale také dokladu totožnosti. Deklarovaným cílem bylo, aby se nezasekly background checky v novém zaměstnání; reálným cílem mohla být krádež identity oběti.

Voňavé tajemství koncového šifrování

V bezpečnostní komunitě se běžně předpokládá [citation needed], že end-to-end encryption (E2EE), překládáno jako koncové šifrovánípředstavuje komunikaci šifrovanou mezi koncovými stanicemi tak, že k ní poskytovatel služby nemá přístup. Proto se tento pojem používá hlavně pro popis šifrování zpráv v instant messengerech typu WhatsApp či Signal.

Čas od času ale narazíte na interpretaci, že za E2EE lze považovat také běžné HTTPS mezi zařízením a serverem výrobce. Tam se ovšem jedná o šifrování při přenosu (encryption in transit), jelikož HTTPS server přirozeně musí mít k této komunikaci přístup, aby ji mohl dále zpracovat. V minulosti se o podobné zkreslení reality pokusil kupř. Zoom a musel za to zaplatit americké FTC.

Ale zpět do přítomnosti. Názornou ukázku světu předvedl startup Kohler s produktem Dekoda, jehož hlavním úkolem je sedět na okraji záchodové mísy, analyzovat obsah vylučovaných vzorků, a z výsledků této analýzy dělat další závěry o zdraví trávicího ústrojí a hydrataci jejího uživatele, kromě jiného. Vedle kamery obsahuje řešení také separátní čtečku otisků prstu k identifikaci uživatele, a samozřejmě mobilní aplikaci. Pro úplnost dodáme, že používání řešení vyžaduje zakoupení nejen produktu, ale také předplatného, a že je produkt dostupný ke koupi pouze v USA.

V propagačních materiálech, které poté přebrala další média, firma uváděla tvrzení, že data, která se sbírají a odesílají do cloudu, jsou chráněna právě koncovým šifrováním. Jenomže Simon Fondrie-Teitler zjistil, že se to jednak úplně neshoduje s tím, co mu firma sama řekla, když se ji pokusil kontaktovat, a k tomu ještě firma může (se souhlasem) odosobněné vzorky použít k dalšímu tréninku jejích AI modelů. K tomu do sbíraných dat ale potřebuje vidět, a to by s E2EE nebylo jednoduše možné.

K dnešnímu dni již Kohler na stránkách i v jejich Privacy Policy správně uvádí korektní pojmy. Otázkou, na kterou se ovšem zřejmě nedozvíme odpověď, zůstává, zda se jednalo o skutečné nepochopení významu E2EE, či šlo o záměrné využití marketingového klamu.

Nedůvěřuj (AI) a prověřuj (instrukce)

Není snad týdne, aby se v Postřezích neobjevil alespoň jeden případ nové zranitelnosti v AI nástrojích. Nicméně, stojí za to si připomenout, že škodit se dá i bez novátorských přístupů.

Prohlížeč Comet od Perplexity.ai má v sobě zabudovánu (placenou) funkci e-mailového asistenta, který je na základě vstupu uživatele schopen provádět všelijaké příkazy nad e-mailovou schránkou uživatele – tedy ve webovém rozhraní Gmailu či Outlooku. A právě ve funkci asistenta byl otestován útok, kdy stačí, aby si uživatel chtěl trochu ušetřit práci, a zadal AI agentovi v Comet příkaz typu “Prosím, projděte mé e-maily a dokončete všechny nedávné organizační úkoly”. Co by se mohlo pokazit?

Ukazuje se, že záleží na míře samostatnosti, důvěry v AI agenta, a kam všude dostane přístup. V testovaném případě se mezi e-maily nacházela zpráva, která uživatele vyzývala k organizaci jejich Google Drive, a dále k odstranění veškerých souborů v kořenovém adresáři. Zatímco člověk by se nad takovou instrukcí zřejmě alespoň pozastavil, AI agent ji bez okolků vykonal a o své činnosti podal zprávu. Vše jen na základě jasně čitelných instrukcí v e-mailu, který navíc uživatel ani nemusel otevřít. Stačilo, aby měl agent přístup k účtům uživatele v GMailu a Google Drive.

Velkou roli samozřejmě hraje provedení – pokud se zpráva tváří dostatečně autoritativně (a neskončí ve spamu), zvyšuje se tím šance na provedení reálně škodlivé akce. V tomto ohledu může být AI agent náchylnější k phishingu než poučený uživatel. K obraně doporučují výzkumníci jednak vylepšit daný model, ale také agenta, jeho konektory, a lépe prověřovat instrukce, které dostává a provádí.

Vývojová IDEstrofa

Zranitelnosti byly ovšem objeveny také v populárních vývojových prostředích (IDE). Bezpečnostní výzkumník Ari Marzouk popsal přes 30 zranitelností v prostředích jako GitHub Copilot, Cursor, Windsurf, Kiro.dev, Zed.dev, Roo Code, Junie, Cline, Gemini CLI, Claude Code, a dalších, ke kterým bylo vydáno 24 CVE.

Souhrnně je nazval IDEsaster. Využívají jednak klasických důsledků context hijacking (prostřednictvím prompt injection), ale také vzrůstajícího množství integrací s AI a funkcí v těchto agentech. Zjednodušeně se dá říci, že pokud IDE zpřístupní AI agentovi nějaké funkcionality, pak je třeba počítat s tím, že mohou být agentem využity – či v tomto případě zneužity.

Autor popsal tři základní způsoby zneužití, které buď zneužívají právě context injection, nebo zpracováním neověřeného vstupu od uživatele, např. stažením vhodně upraveného repozitáře a jeho otevřením v IDE se zapnutými AI nástroji.

Popsané případy jsou:

  1. Remote JSON schema (nad VS Code, JetBrains IDE, Zed.dev), může být využito k exfiltraci dat,
  2. Přepsání nastavení IDE (nad VS Code, JetBrains IDE, Zed.dev), může vést ke vzdálenému spuštění kódu,
  3. Pracovní prostor s více kořenovými adresáři – multi-root workspace (nad VS Code), obdobně jako u 2) může vést ke spuštění kódu.

U druhého a třetího případu je potřeba, aby měl AI agent povolené automatické úpravy souborů, což je ale prý ve výchozím nastavení zapnuto pro soubory uvnitř workspace.

Vývojářům, kteří taková IDE používají, autor radí používat AI agenty a AI IDE pouze nad důvěryhodným kódem, kontrolovat zdroje dat na skryté instrukce, připojovat se pouze k důvěryhodným MCP serverům (a chápat, zda se tyto MCP servery nepřipojují k dalším zdrojům dat, které mohou být nedůvěryhodné), a v neposlední řadě, nakonfigurovat prostředí tak, aby vyžadovalo potvrzení od člověka před každou akcí AI agenta, která by mohla být potenciálně riziková (human-in-the-loop, HITL).

Doporučení pro autory těchto IDE obsahují nejen tradiční bezpečnostní doporučení jako princip nejmenších privilegií, prompt hardening, sandboxing a řízení přístupu k externím zdrojům, ale také vždy předpokládat, že prompt injection je možný, a že agentovi se nedá věřit.

RCE v React Server Components

Přestože React je primárně framework pro tvorbu responzivních frontendů, lze s pomocí Server Components (RSC) některé akce provádět na straně serveru. A právě v těchto komponentách byla nalezena závažná zranitelnost CVE-2025–55182 (CVSS 3.1 Base Score 10, CVSS:3.1/AV:N/AC:L/PR:N/U­I:N/S:C/C:H/I:H/A:H). Dostala krásnou přezdívku React2Shell.

Jde o vzdálené spuštění kódu bez autentizace, a to v důsledku neošetřené deserializace vstupních dat směřujících na funkce na serveru (CWE-502: Deserialization of Untrusted Data). Zranitelnost lze ověřit či zneužít i jedním HTTP požadavkem. Není bez zajímavosti, že i prázdná aplikace v Next.js vytvořená s „create-next-app“ šla takto zneužít.

Zranitelné jsou verze Reactu 19.0.0, 19.1.0, 19.1.1 a 19.2.0, konkrétně balíčky react-server-dom-parcel, react-server-dom-turbopack, react-server-dom-webpack.
V přímém ohrožení jsou také uživatelé frameworků, které používají zranitelné balíčky, včetně Next.js 15.x a 16.x (App Router), jakožto také použivatelé RSC v dalších frameworcích (Vite, Parcel, React Router, RedwoodSDK, Waku…).

Oprava byla vydána v následujících verzích:

  • React: 19.0.1, 19.1.2, 19.2.1
  • Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

CISA již zranitelnost přidala do seznamu těch aktivně zneužívaných. Pro zájemce je dostupný Proof-of-Concept (hned několik), který spouští kód. Datadog také publikoval IoCs (indikátory kompromitace) – IP adresy, které aktivně útočily se škodlivým payloadem.

ShadowServer v sobotu publikoval, že jeho skenery již odhalily přes 77 tisíc zranitelných instancí Reactu, 88 z toho v ČR.

Není bez zajímavosti, že Cloudflare, při pokusu o ochranu svých zákazníků proti React2Shell, nechtěně shodil 28 % webového provozu chráněného jeho sítí, a to na 25 minut. Šlo o triviální chybu v kódu, pokoušejícího se dereferencovat nil, tentokráte v proxy verze FL1 – ta chyba se v ní skrývala mnoho let. V novější verzi FL2, psané v Rustu, se chyba naopak nevyskytla díky jeho silnému typování, který této třídě chyb předchází. 

Indie: bez SIM si už nenapíšete

Indické ministerstvo komunikací (Department of Telecommunications) zavedlo nová přísná pravidla, která se týkají komunikátorů a instant messengerů v mobilních aplikacích (tj. např. WhatsApp, Telegram, ale také Signal a další). Komunikátory, které účet unikátně navazují na indické telefonní číslo, mají tímto nařízeno v aplikacích zajistit trvalou vazbu přihlášeného účtu na používanou SIM kartou a nepovolit používání, aniž by byla tato specifická SIM karta vložená. Dále, v případě, že tato aplikace umožňuje používání i přes webový portál, pak webové přihlášení musí nejpozději po 6 hodinách vypršet, a uživatel poté znovu musí zařízení spárovat.

Zmíněná pravidla musejí poskytovatelé aplikací v Indii implementovat do 90 dní od platnosti nařízení, jak se píše v tiskové zprávě ministerstva. Ministerstvo tvrdí, že toto opatření zlepší bezpečnost sítě a dohledatelnost aktivit provedených pod danou SIM. Mobilní operátoři rozhodnutí přivítali, zatímco zástupci mobilních aplikací a Broadband India Forum naopak žádají, aby centrum implementaci zatím pozastavilo a přehodnotilo z důvodu mnoha rizik vč. legislativního overreache.

Totožné ministerstvo také údajně chtělo nařídit, tentokrát ale nejprve potají, aby výrobci smartphonů do svých zařízení začali instalovat státem vyráběnou bezpečnostní aplikaci Sanchar Saathi. Sanchar Saathi je jednak webový portál a také mobilní aplikace, která má primárně umožňovat kontrolu IMEI, reportování ztracených či odcizených telefonů, kromě jiného. Jenomže samotná aplikace vyžaduje mnohem více oprávnění, např. k posílání a čtení zpráv, čtení seznamu hovorů, přístupu k fotografiím a kameře…

Dle příkazu měli výrobci zajistit, aby aplikaci nebylo možné deaktivovat či jinak zablokovat její funkčnost, což ale později ministr zpochybnil. Příkaz se měl týkat alespoň společností Apple, Samsung, Vivo, Oppo a Xiaomi. Zdá se však, že indická vláda od tohoto plánu pod tlakem ustoupila, a instalace aplikace bude nadále dobrovolná.

Stručně

K zasmání / k zamyšlení

Me upon reading the latest directory traversal vuln report

O seriálu

Tento seriál vychází střídavě za pomoci pracovníků Národního bezpečnostního týmu CSIRT.CZ provozovaného sdružením CZ.NIC a bezpečnostního týmu CESNET-CERTS sdružení CESNET, bezpečnostního týmu CDT-CERT provozovaného společností ČD - Telematika a bezpečnostních specialistů Jana Kopřivy ze společnosti Nettles Consulting a Moniky Kutějové ze sdružení TheCyberValkyries. Více o seriálu…

Neutrální ikona do widgetu na odběr článků ze seriálů

Zajímá vás toto téma? Chcete se o něm dozvědět víc?

Objednejte si upozornění na nově vydané články do vašeho mailu. Žádný článek vám tak neuteče.


Autor článku

CESNET-CERTS je oficiální jméno bezpečnostního týmu sdružení CESNET, z. s. p. o. od ledna roku 2004. Jeho součástí je také Forenzní laboratoř FLAB. Články tvoří společně jednotliví členové týmu.