Hajszálon múlt: Súlyos hibát hárítottak el az XRP Ledger legújabb frissítésében
Az XRP Ledger (XRPL) egy tervezett frissítésében súlyos biztonsági hibát találtak, amely akár illetéktelen tranzakciók végrehajtását is lehetővé tehette volna, azonban a problémát még időben sikerült elhárítani.
A hírek szerint a hálózat egyik készülő frissítésében olyan kódhiba rejtőzött, amely bevezetése esetén jelentős anyagi kárt okozhatott volna a felhasználóknak. A fejlesztők azonban még azelőtt azonosították a problémát, hogy az a mainnetre került volna, így sikerült megelőzni egy komoly pénzügyi és bizalmi válságot.
Az XRPL Foundation február 26-i tájékoztatása szerint a sebezhetőséget a tervezett „Batch” frissítésben fedezték fel. Ez a funkció lehetővé tette volna, hogy a felhasználók több műveletet egyetlen, úgynevezett atomi tranzakcióba csomagoljanak.
A XRP Ledger hiba technikai háttere
A probléma gyökere a Batch tranzakciók hitelesítési logikájában volt. A kötegelt tranzakciók lényege, hogy több belső műveletet fognak össze: vagy mindegyik sikeresen lefut, vagy egyik sem. Ebben a modellben a belső tranzakciók nem rendelkeznek külön aláírással, a hitelesítést a külső, befoglaló tranzakció aláírólistája végzi. Ez a lista vált a biztonsági lánc leggyengébb pontjává.
A konkrét hiba egy ciklusellenőrzési logika alapjain nyugvó tévedés volt:
- Amikor a kód olyan aláíróhoz ért, amelynek a fiókja még nem létezett a főkönyvün, de a kulcs megegyezett ezzel a nem létező fiókkal, a rendszer azt automatikusan érvényesnek fogadta volna el.
- Emiatt a program leállította a lista további ellenőrzését.
- Egy támadó így létrehozhatott volna olyan kötegelt tranzakciót, amelyben egy általa kontrollált, még nem létező fiókot állít be aláírónak, megkerülve a valódi tulajdonos hitelesítését.
Ez a forgatókönyv a kriptovilág egyik legsúlyosabb kockázatát jelentette volna: egy támadó az áldozat privát kulcsai nélkül is képes lehetett volna kifizetéseket indítani vagy módosítani.
Gyors reagálás
Amint a hibát jelentették, a válaszlépések rendkívül gyorsan elindultak. A validátorokat arra utasították, hogy szavazzanak nemmel a Batch frissítés aktiválására.
Február 23-án megjelent a rippled 3.1.1 verzió, amely automatikusan nem támogatottként jelölte a hibás funkciót, ezzel megakadályozva annak aktiválását. A hibára utaló kódrészletek eltávolítása a következő napokban folytatódik.
Fontos ugyanakkor, hogy a 3.1.1-es kiadás inkább gyors kockázatcsökkentő lépés („tűzoltás”) volt: a sebezhetőség végleges javítását még nem tartalmazta, csupán blokkolta az aktiválást.
Miért lett volna különösen veszélyes?
Az időzítés különösen érzékeny volt. Az XRP Ledger jelenleg az intézményi felhasználás és a szabályozott pénzügyi integráció felé pozicionálja magát, miközben erőteljesen terjeszkedik a valós eszközök tokenizációja (RWA) és az intézményi DeFi területén.
A DeFiLlama adatai szerint az XRPL mintegy 50 millió dollárnyi lekötött értékkel (TVL) rendelkezik a DeFi-szektorban, míg az RWA-eszközök értéke megközelíti a 2 milliárd dollárt. Egy ilyen biztonsági incidens súlyosan megrendíthette volna a hálózatba vetett bizalmat, különösen egy olyan időszakban, amikor a projekt a megbízhatóságára és a szabályozói megfelelésre épít.
A helyzet kockázatát tovább növeli, hogy a Ripple Luxemburgban elektronikus pénzintézeti (EMI) engedélyt szerzett. Ez lehetővé teszi a vállalat számára, hogy elektronikus pénzt bocsásson ki és fizetési szolgáltatásokat nyújtson, amelyeket az úgynevezett „passporting” mechanizmus révén az EU több tagállamában is használhatnak bankok és fintech cégek a Ripple Payments rendszeren keresztül.
Ezzel párhuzamosan a vállalat az Egyesült Királyságban is megszerezte az EMI-licencet és a kriptoeszköz-regisztrációt az Financial Conduct Authority (FCA) felügyelete alatt, ami jól mutatja európai ambícióit.
Fokozott biztonság a jövőben
A javított változat, a BatchV1_1 már elkészült és jelenleg is tesztelés alatt áll. Ez a verzió már nem tartalmazza a korábban említett hibákat, és szigorúbb ellenőrzési mechanizmusokat vezet be.
Az eset után az XRPL egy szélesebb körű biztonsági útitervet is felvázolt. Ez magában foglalja az AI-alapú auditok szabványosítását és a statikus elemzések kiterjesztését, hogy a jövőben az ehhez hasonló logikai hibákat még a fejlesztés korai szakaszában kiszűrjék.
Bár az incidens végül sikeresen elhárult, mivel nem történt pénzvesztés, és a hálózat stabil maradt, az eset fontos figyelmeztetés. A blokklánc-rendszerekben a biztonsági ellenőrzések nem lehetnek másodlagosak: egyetlen apró hiba is súlyos következményekkel járhatna a hálózat jövőjére nézve.