Suuri panostuspalvelujen tarjoaja vaarantui. Hyökkääjä ohitti tarkastukset, kynätestit ja SOC 2 -kontrollit. Tässä kerrotaan, mikä todella meni pieleen ja miksi alkuperäisellä panostusarkkitehtuurilla on merkitystä 🧵

Syyskuun 8. päivänä hienostunut hyökkääjä lisäsi haitallista koodia Kilnin API:hen. Eräs instituutio ajatteli, että ne olivat paaluttomia. Sen sijaan he tietämättään siirsivät omaisuutensa hallinnan.

Ongelma? He allekirjoittivat sokeasti sarjoitettua transaktiohyötykuormaa, jota he eivät osanneet lukea. dApp vaarantui. Taustajärjestelmä sarjoitti hyökkäyksen. Heidän huoltajuusratkaisunsa ei nähnyt sitä. He hyväksyivät sen joka tapauksessa.

Kun laitokset luottavat ulkoisiin panostussovelluksiin, riski on seuraava: → Luotat taustajärjestelmään, jota et hallitse → Hyväksyt tapahtumat, joita et voi tulkita → Allekirjoitat epätäydellisessä kontekstissa Tietoturva ei ole vain tarkastuksia. Kyse on arkkitehtuurista.

Fireblocksin natiivipanostus eliminoi tämän riskin. ✅ Lähteellä kaapattu tarkoitus ✅ Panostuskohtainen käytäntömoottori ✅ Ihmisen luettavissa olevat hyväksynnät ✅ Suojattu enklaavin sarjoittaminen ✅ Ei raakatavuja. Ei sokeaa allekirjoitusta.

Jopa monimutkaisissa ketjuissa, kuten Solana, Fireblocks varmistaa, että jokainen panostustapahtuma heijastaa tarkkoja aikomuksiasi. Hyökkääjät eivät voi lisätä haitallisia komentoja. Arkkitehtuuri ei salli sitä.