Problém důvěrné databáze stavu speciálních žádostí
Co jsou to speciální žádosti, jak je jejich seznam potenciálně zneužitelný spekulanty a proč je třeba jej chránit, popisuje tento článek na Lupě
http://www.lupa.cz/clanek.php3?show=2243. NIC si to samozřejmě uvědomoval, a proto byl k seznamu přistup omezen. Žadateli se zobrazila pouze jeho žádost po zadání identifikátoru žádosti, přiděleného NICem a variabilního symbolu platby, rovněž přiděleného NICem. Obojí zasílá NIC žádali emailem. Bohužel, tyto údaje nebyly zvoleny, resp. vytvářeny, zcela šťastně. Na ukázku několik kousků autentizačních údajů:
spec.20020401-14:55:00.1 9000326222
spec.20020425-11:35:00.2 9000429125
spec.20020425-11:35:00.3 9000429226
spec.20020415-20:15:00.2 9000399131
spec.20020415-20:15:00.1 9000399030
spec.20020415-20:15:00.5 9000399434
spec.20020415-20:15:00.4 9000399333
spec.20020415-20:15:00.3 9000399232
Je vidět, že
- Identifikátory mají tvar spec.Datum-Hodina.PoradoveCislo
- Automat, zpracovávající speciální žádosti, běží několikrát za hodinu. Pořadová čísla se přidělují v rámci běhu, od jedničky.
Když tedy pro každý termín běhu automatu, kterých je za den pouhých 1440, vyzkoušíme pár pořadových čísel, získáme klíče databáze. Ideální bude, pokud dokážeme průběžně ověřovat, zda jsou klíče platné - vyzkoušíme poř. číslo 1 - pokud existuje, pokročíme 2, pokud ne, přeskočíme na další termín.
K autentizaci zřejmě slouží variabilní symbol. Ale.
- Je vidět, že rozhodně není náhodný.
- Při bližším pohledu je vidět, že je to prostě čítač, jež se s každou žádostí inkrementuje o 101.
K úspěšnému přečtení databáze zřejmě už stačí jen získat jeden pár identifikátor - var.symbol., postupovat výše popsaným triviálním algoritmem pro hledání klíčů a při každé "trefě" zvětšit zkoušený var.symbol o 101.
- Získat jednu dvojici je triviální - stačí podat žádost.
- Po delším zkoumání se zjistí, že některá čísla v posloupnosti var. symbolů chybí.
Důvodem je, že stejný čítač variabilních symbolů se používá i pro další operace, nejen seznam specielních žádostí.
Způsobí nám to jen drobné obtíže - počet pokusů se zvětší několikanásobně (podle toho, jakou část ze všech přidělených symbolů zaujímají spec. žádosti), nebo si můžeme pomoci pravidelným "vzorkováním" - občas vygenerujeme zbytečnou žádost, a získáme tak odhad, kolik žádostí celkem bylo přijato, a možný rozsah var. symbolů.
V praxi s použitím bashe, fetch a GNU textutils bylo možné ověřit přibližně jednu kombinaci za sekundu, a získání databáze bz tedy bylo prakticky dobře realizovatelné.
Děkujeme za naprostou vzornou reakci CZ-NICu na ohlášení chyby - potvrzení přijetí a potvrzení, že se daná věc prověří, dorazilo během několika hodin. Změna systému tak, že teď je k autorizaci potřeba i číslo účtu žadatele, trvala přibližně den. Provedená úprava zneužití problému činí velmi obtížným a navíc funguje zpětně (t.j. ani ten, kdo má údaje "navzorkované" díky žádostem v minulosti, teď nic nepřečte), stručně řečeno, problém řeší.
Další poznatky patří jsou spíše zajímavosti, žádné přímočaré bezpečnostní dopady nemají.
Potvrzování žádostí před jejich odesláním
Žádosti o změnu údajů domény, žádosti o převod a podobně se obecně musí potvrzovat, faxem, nebo dopisem s úředně ověřeným podpisem. Jak vyplývá z prvního popsaného problému se spec. žádostmi, čísla žádostí jsou dopředu jasná a je možné si dokonce celkem spolehlivě vygenerovat žádost předem určeného čísla. Stačí v přesný okamžik odeslat mail do automatického zpracování, a pokud si vybereme některý nepříliš využívaný "běh", bude žádost určitě první. Kuriosním využitím je potvrzení žádosti předtím, než byla odeslána. Notářem ověřený podpis z, řekněme, 10.1., žádosti, odeslané 13.1., administrativní kontrolou projde. (Pochopitelně, žádost musí existovat v okamžiku kontroly.)
