Bug bounty a zodpovědné hlášení zranitelností: etika a proces odhalování bezpečnostních rizik

Co je bug bounty a zodpovědné hlášení zranitelností

Bug bounty program je strukturovaný způsob, jak motivovat bezpečnostní výzkumníky (whitehaty), aby vyhledávali a hlásili zranitelnosti výměnou za odměnu. V kontextu kryptoměn, tradingu a Web 3.0 se jedná především o chyby v chytrých kontraktech, backendech burz a mostů, v klientech uzlů, v peněženkách a v infrastruktuře orákul. Zodpovědné hlášení (CVD – Coordinated Vulnerability Disclosure) je proces, který nastavuje bezpečný komunikační kanál, jasné lhůty, bezpečnostní mantinely a princip „safe harbor“, aby se minimalizovalo riziko pro uživatele a co nejrychleji opravily chyby.

Proč je bug bounty kritické ve Webu 3.0

  • Finální finalita a neodvolatelnost transakcí: Po zneužití je škoda okamžitá a často nevratná.
  • Kompozabilita: Chyba v jednom protokolu může kaskádovitě ovlivnit další (DEXy, lending, trezory, mosty).
  • Nepřetržitá dostupnost: Chytré kontrakty jsou 24/7 na síti; okno útoku je trvalé.
  • Pokrytí audity není absolutní: Audity jsou bodové; bug bounty nabízí kontinuální „crowd-sourcingové“ testování.

Modely programů: VDP, bug bounty, soutěže a živé testování

  • VDP (Vulnerability Disclosure Policy): Otevřený kanál pro hlášení bez garantovaných odměn. Minimální standard pro každý projekt.
  • Bug bounty s odměnami: Stupnice odměn podle závažnosti; často s maximem pro kritické nálezy ohrožující prostředky.
  • Auditní soutěže: Časově omezené prohlídky kódu s více soutěžícími; vhodné pro nové releasy.
  • Live hacking/CTF: Řízené události, typicky off-chain komponenty, UI, API nebo testnetové nasazení.

Principy zodpovědného hlášení (CVD) v praxi

  1. Bezpečný kanál: PGP e-mail, specializovaná platforma nebo formulář s end-to-end šifrováním.
  2. Embargo a lhůty: Dohodnuté období (např. 7–30 dní pro kritické on-chain chyby, 30–90 dní pro off-chain).
  3. Safe harbor: Jasné prohlášení, že v dobré víře, s respektem ke scope a bez neoprávněného obohacení, nebudou právní sankce.
  4. Koordinace: Společná dohoda o čase veřejného zveřejnění po záplatě a nasazení mitigací.
  5. Minimalizace dopadu: PoC bez přesunu prostředků, bez DoS, bez úniku dat mimo nezbytné minimum.

Právní a etický rámec: safe harbor, povolené testy, zákaz exfiltrace

Projekty by měly publikovat „Safe Harbor Statement“, které pokrývá:

  • Autorizované cíle: Konkrétní kontraktní adresy, repozitáře a subdomény; testování na mainnetu vs. testnetu.
  • Zákaz aktivit: DoS, spam, sociální inženýrství, manipulace KYC, exfiltrace citlivých údajů.
  • Neoprávněné obohacení: Žádné převody cizích prostředků; v případě nutné eskalace jen „whitehat rescue“ s okamžitým vrácením.
  • Jurisdikce a sankce: Vyloučení zemí a subjektů podle sankčních seznamů; pravidla KYC při výplatě.

Scope: jak ho definovat ve Web3

  • On-chain: Kontrakty, proxy, inicializéry, upgrade mechanismy, multisignatury, timelocky, modulární trezory.
  • Off-chain: API, backendy, frontend, DNS, infrastruktura, CI/CD, build pipeline, distribuční kanály rozšíření peněženek.
  • Mosty a orákula: Relaye, pozorovatelé, validátoři, agregátoři cen, zdroje entropie.
  • Mimo scope (typicky): Třetí strany bez kontroly projektu, staré verze mimo produkci, testovací kontrakty bez aktiv.

Hodnocení závažnosti a odměn: od fondů v riziku po dopad na uživatele

V kryptokontextu se závažnost často váže na maximální ztráty a pravděpodobnost zneužití. Užívá se kombinace klasické škály (kritická, vysoká, střední, nízká, info) s kategoriemi dopadu specifickými pro DeFi.

Úroveň On-chain dopad Příklady Orient. odměna
Kritická Neomezené nebo významné odčerpání prostředků, trvalá ztráta custodie Reentrancy při výběru, obejití přístupu admina, nesprávná inicializace proxy 1–10 % z ušetřených prostředků (strop dle treasury)
Vysoká Částečné odčerpání, zmrazení aktiv, trvalá manipulace stavu Manipulace orákla, integer overflow/underflow, flash-loan price swing 5–6 cifer v USD dle TVL
Střední Omezené riziko ztráty, obcházení omezení Frontrunning, limitní obcházení, nesprávné limity, únik interních klíčů testnetu 4–5 cifer v USD
Nízká Malé riziko, zejména UX, menší úniky metadat Clickjacking, menší CSP chyby, nekonzistentní validace na frontendu 3–4 cifry v USD
Info Bez přímého dopadu Zastaralá dokumentace, slabé logování Symbolické

Proces pro výzkumníka: krok za krokem

  1. Nastudování pravidel: Scope, safe harbor, limity testování, kanály pro nahlášení.
  2. Lokální repro prostředí: Fork mainnetu, simulace transakcí, diffování stavu, unit/fuzz testy.
  3. Analýza: Čtení kódu, hledání invariantů, kontrola přístupů, tokenomika a okrajové případy.
  4. Bezpečný PoC: Testnet nebo lokálně, nulová interakce s cizími aktivy.
  5. Report: Faktický, reprodukovatelný, s jasnou trajektorií dopadu a návrhem mitigace.
  6. Koordinace: Reakce na otázky triage týmu, poskytnutí doplňujících důkazů, respekt embargo.

Struktura kvalitního reportu

  • Shrnutí: Jednou větou, v čem spočívá chyba a jaký má dopad.
  • Scope a verze: Kontraktní adresy, commit hash, síť, časový kontext.
  • Předpoklady a model hrozby: Co útočník potřebuje (kapitál, roli, oprávnění, MEV).
  • Kroky reprodukce: Detailní, deterministický postup, ideálně s testem.
  • Dopad a odhad ztrát: Maximální vyčíslitelná hodnota, sekundární efekty.
  • Návrh mitigace: Oprava, omezení, guardy, timelock nebo pauza.
  • Důkazy: Logy, transakční stopy v sandboxu, výsledky fuzzingu.
  • Zodpovědné chování: Potvrzení, že nedošlo k exfiltraci nebo zneužití.

Bezpečný PoC v kryptokontextu

  • Žádný přesun cizích prostředků: Testujte lokálně nebo na testnetu případně s nulovou hodnotou.
  • Fuzz a invarianty: Ověření, že oprava neporušuje kontrakty v jiných větvích toku.
  • Simulace mempoolu: Reprodukce frontrunningu a sandwich útoků bez dotyku mainnetu.

Typické zranitelnosti v chytrých kontraktech a DeFi

  • Reentrancy a cross-function reentrancy, nesprávný „checks-effects-interactions“ pořádek.
  • Nesprávné přístupy: owner-only funkce bez guardů, chybějící only-EOA, zneužitelné delegace.
  • Přetečení a podtečení, nesprávné použití bezpečných matematických knihoven.
  • Neinicializované proxy, chybějící initializer guardy, úniky práv při upgrade.
  • Manipulace orákla (TWAP, nízká likvidita), flash-loan zneužití cen.
  • MEV scénáře: frontrunning, sandwich, backrunning, griefing.
  • Podpisová logika: malleabilita, chybně definované noncis, replay mezi sítěmi.
  • Mosty: slabá verifikace důkazu, multi-sig s nízkým kvórem, neověření relayeři.
  • Další: nedostatečné limity, chybějící pauzovatelné mechanismy, časové závislosti.

Nástroje a metodiky pro Web3 výzkum

  • Analýza kódu: Slither, Mythril, semgrep-rules pro Solidity, ručně psaná revize invariantů.
  • Fuzzing a testy: Echidna, Foundry fuzz, property-based testy, invariantní sady testů.
  • Simulace a forky: Foundry a Hardhat mainnet-fork, skriptované scénáře a state-diffy.
  • Formální metody: Symbolické vykonávání, specifikace ve stylu „assert pre/post“ podmínek.
  • Monitoring: Nástroje na sledování mempoolu, on-chain alerting, heuristiky MEV.

Specifika L2, rollupů a mostů

  • Časové zpoždění: Challenge window u optimistic rollupů.
  • Mosty: Konzistence zpráv, ověřování důkazů, reorg-rezistence.
  • Klientské implementace: Různé VM a opcode, rozdíly v gas účtování.

Incident response a „whitehat rescue“

  • Pauza a timelock: Aktivace nouzových přepínačů, dočasné omezení funkcí.
  • Whitehat multisig: Předkonfigurovaný trezor pro rychlou záchranu aktiv a následné vrácení.
  • Post-mortem: Transparentní zpráva, audit oprav, aktualizace dokumentace a pravidel.

Metriky a správa programu

  • MTTR (Mean Time To Remediate): Průměrný čas od nahlášení po opravu.
  • Pokrytí: Procento kritických komponent v scope; počet unikátních výzkumníků.
  • Efektivita odměn: Poměrné náklady na „ušetřený“ kapitál.

Výplaty, KYC a treasury

  • Formy odměn: Stablecoiny, nativní tokeny, fiat; jasná pravidla zdanění a KYC dle jurisdikce.
  • Vesting a capy: Limit na kritické odměny vs. procento z ochráněných prostředků.
  • Transparentnost: Zveřejňování statistik vyplacených odměn po skončení embarga.

Časté chyby a anti-patterny v bug bounty programech

  • Příliš úzký scope bez nejrizikovějších modulů.
  • Nejasná pravidla hodnocení a nepředvídatelné odměny.
  • Pomalý triage a chybějící zpětná vazba, což demotivuje whitehaty.
  • Ignorování off-chain útoků (supply-chain, DNS hijacking, typosquatting).

Checklist pro projekt

  • Publikovaný VDP a bug bounty pravidla včetně safe harbor a embargo podmínek.
  • Přesný scope: adresy kontraktů, verze, repozitář, subdomény, kontakty.
  • Stupně odměn podle dopadu, příklady a maximální limity.
  • Bezpečný kanál hlášení, PGP klíč, SLA triage (např. potvrzení do 24–48 hodin).
  • Incident playbook: pauza, timelock, whitehat multisig, komunikace s komunitou.
  • Proces testování oprav: unit, fuzz, invarianty, audit po fixech.

Checklist pro výzkumníka

  • Přečtená pravidla a scope; respektování zákonů a safe harbor podmínek.
  • Připravené repro prostředí (fork, testnet, lokál), bez dotyku cizího kapitálu.
  • PoC s minimálním dopadem, jednoznačné kroky reprodukce.
  • Jasné vyčíslení dopadu a návrh mitigace; profesionální komunikace.
  • Respektování embarga až do veřejného zveřejnění po opravě.

Vzorek krátké šablony hlášení

  • Předmět: Kritická on-chain zranitelnost v modulu X (síť, adresa kontraktu)
  • Shrnutí: Jednou větou popište, co je problém a proč je kritický.
  • Scope: Adresa kontraktu, commit hash, verze.
  • Kroky reprodukce: 1…n (deterministické, s očekávaným výsledkem).
  • Dopad: Maximální vyčíslený zisk/ ztráta, sekundární efekty.
  • Mitigace: Doporučená oprava nebo guardy.
  • Potvrzení zodpovědného chování: Žádný