Sådan kunne Notional Finance V1-udnyttelsen få en gæld på 2^128 til at blive nul

Det rapporterede angreb mod Notional Finance var efter alt at dømme ikke et almindeligt tilfælde af for lidt stillet sikkerhed. Den påståede svaghed var en fejl i regnskabsføringen: En meget stor fCash-gæld blev oprettet ved grænsen 2^128 og blev derefter reduceret til nul, da protokollen indsnævrede værdien til uint128 i beregningen af fri sikkerhed. Når forpligtelsen på det kritiske tidspunkt stod som nul, kunne kontoen se solvent ud og hæve aktiver, den ellers ikke burde kunne få adgang til. 416

Den offentlige rekonstruktion bygger på on-chain-overvågning og rapportering fra sikkerhedsforskere – ikke på en offentlig post-mortem fra protokollen. Det er en væsentlig forskel: Pengestrømmene kan ses på blockchainen, men den endelige rækkefølge af kald, det fulde omfang og status på en eventuel afhjælpning var ikke bekræftet i den tilgængelige rapportering. 34

Regnskabsfejlen: En gæld, der blev vurderet til nul

Notional V1 repræsenterede fremtidige betalingsforpligtelser som fCash. Ifølge CertiKs offentlige alarm brugte angriberen to kald til mintfCashPair() til at oprette en gæld på -2^128. Under værdiansættelsen af den frie sikkerhed blev værdien angiveligt konverteret usikkert til uint128, hvilket afkortede den til 0. 16

I praksis var det beskrevne angrebsforløb:

1. Opret en ekstrem negativ fCash-position. Angriberen skabte en forpligtelse præcis i den størrelsesorden, hvor en indsnævring til et 128-bit usigneret heltal kunne fjerne gældens repræsentation. 416
2. Udløs sikkerhedsvurderingen. Escrow-kontraktens regnskab konverterede ifølge rapporterne gælden gennem en usikker uint128-nedkonvertering.
3. Lad gælden forsvinde i kontrollen. I stedet for at registrere en enorm negativ forpligtelse behandlede beregningen værdien som nul. 46
4. Passér hævekontrollen. Når gælden ikke indgik i regnskabet for fri sikkerhed, kunne kontoen tilsyneladende opfylde betingelserne for at hæve escrow-kontraktens likvide stablecoins. 46

Derfor beskrives hændelsen mest præcist som en fejl i indskrænkende typekonvertering og et brud på et regnskabsinvariant – snarere end blot som et generelt "integer overflow". Den afgørende rapporterede effekt var, at en negativ gæld blev til nul netop i den værdiansættelse, der skulle forhindre en hævning uden tilstrækkelig sikkerhed. 416

Hvad blev angiveligt drænet?

On-chain-rapportering opgjorde tabet til cirka 69.257 DAI og 1.650.824 USDC, svarende til omtrent 1,728 mio. dollar. Aktiverne blev angiveligt vekslet til cirka 689,2 ETH og derefter indsat i Tornado Cash. 215

Kontrakten, der blev identificeret i rapporteringen, var Notional Finance-escrowen på 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683. En rapport beskrev en forberedende transaktion fra en adresse, der sluttede på Ce38, kl. 23.58.47 UTC den 3. september 2026, efterfulgt cirka tre minutter senere af dræningstransaktionen tidligt den 4. september. 1723

Efterforskere knyttede offentligt to Ethereum-adresser til overførslerne:

• 0xC954…De69
• 0xDaCC…Ce38

Disse betegnelser er en on-chain-baseret efterforskningsmæssig sammenkædning – ikke en identifikation af en person, organisation eller endelig kontohaver. 11

Hvorfor ETH-ruten vanskeliggjorde genindvinding

Den rapporterede veksling fra DAI og USDC til ETH ændrede betingelserne for at følge og muligvis genfinde midlerne. Stablecoin-overførslerne var tydeligt sporbare på Ethereum, mens den efterfølgende veksling spredte værdierne ud i ETH. De rapporterede indbetalinger til Tornado Cash lagde derefter et privatlivslag ovenpå, der er designet til at sløre transaktioners oprindelse, destination og modparter. 229

Det gør hverken blockchainanalyse umulig eller dokumenterer, hvem der kontrollerede en senere udbetaling. Men den direkte, aktiv-for-aktiv-sporing fra den udnyttede escrow-kontrakt til en senere modtager bliver væsentligt mindre ligetil, når midlerne passerer gennem en mixer. 29

Det, der fortsat var ukendt

På tidspunktet for rapporterne havde Notional ikke udsendt en offentlig udtalelse om hændelsen. Derfor stod flere afgørende spørgsmål åbne:

• den endelige tekniske årsag og hele rækkefølgen af exploit-kald;
• om de rapporterede transaktioner dækkede alle berørte kontrakter, konti og aktiver;
• det endelige tab efter vekslinger, gebyrer og eventuelle efterfølgende overførsler;
• hvilke muligheder der fandtes for pause, opgradering, kompensation eller genindvinding; og
• angriberens identitet samt om de offentligt mærkede adresser var de eneste wallets under fælles kontrol. 3411

Den rapporterede årsag bør derfor ses som en stærk, foreløbig rekonstruktion – ikke som en erstatning for en revideret post-mortem eller en officiel hændelsesrapport.

Sikkerhedslæren for ældre DeFi-systemer

En ældre kontrakt er ikke lavrisiko, blot fordi den er gammel eller ikke længere er central i et produkts udviklingsplan. Hvis den fortsat opbevarer aktiver eller kan indgå i minting, afvikling, sikkerhedsvurdering eller hævninger, er den stadig en aktiv finansiel angrebsflade.

For protokolteams peger den rapporterede Notional V1-fejl på flere kontroller, der bør valideres samlet:

• brug kontrollerede, indskrænkende typekonverteringer, og afvis eksplicit værdier, der ikke kan repræsenteres sikkert;
• test signeret gæld, afvikling og sikkerhedsberegninger ved talgrænser som 2^128;
• kod regler for solvens og bevarelse af værdier som invarianter, og test dem på tværs af sekvenser med flere kald;
• undersøg, om privilegerede eller usædvanlige kald kan sætte minting, afvikling og hævning sammen i en utilsigtet rækkefølge; og
• begræns kaldere og kaldforløb, når en funktion kun er sikker i sin tiltænkte kontekst.

Det bredere mønster er velkendt i DeFi: En lille fejl i talrepræsentation eller autorisation kan udvikle sig til et totalt tab, når den når en hævefunktion med likvide aktiver. Det afgørende forsvar er derfor ikke kun at revidere enkelte funktioner, men at dokumentere, at systemets regnskabsinvarianter holder i enhver mulig sekvens af kald.