Notional Finance gehackt: aanvaller steelt $1,73 miljoen via overloopfout

Het gedecentraliseerde leenprotocol Notional Finance is op 4 september 2026 het slachtoffer geworden van een aanval waarbij de aanvaller ongeveer $1,73 miljoen wist te stelen. Het beveiligingsbedrijf SlowMist analyseerde het incident volledig en wijst een integer overflow in de onderpandberekening aan als oorzaak. Door een fout in de typeconversie kon de aanvaller een ongedekte positie openen die het protocol als veilig beschouwde.

In het kort:

• Aanvaller exploiteert een overflow in de onderpandberekening van Notional Finance en steelt $1,73 miljoen.
• De fout zat in de functie die verplichtingen naar ETH omrekent: een waarde van -2^128 werd door typeafkapping omgezet naar 0.
• SlowMist raadt aan om resultaten van abs() te valideren en SafeCast te gebruiken bij dergelijke berekeningen.

Hoe de aanval verliep

De aanvaller begon met het uitrollen van hulpcontracten en het instellen van goedkeuringen via setApprovalForAll op de ERC-1155 handelscontracten van Notional Finance. Daarna volgden twee strategisch gekozen overdrachten.

De eerste overdracht betrof een fCash-paar met een bedrag van 1 bij een vervaldatum van 4 september 2026. Dat bedrag was zo klein dat het bij omrekening naar ETH naar nul afrondde, waardoor de onderpandcontrole zonder problemen doorging. De tweede overdracht gebruikte een bedrag van uint128.max, maar bij een andere vervaldatum: 3 december 2026. Doordat de twee verplichtingen in verschillende categorieën vielen, werden ze niet bij elkaar opgeteld en kon een overflow via SafeMath niet optreden.

Bij de controle van het vrije onderpand telde het systeem de twee verplichtingen op, wat uitkwam op -2^128. Bij de omrekening naar ETH werd dat getal door een typeafkapping naar 0 verkort, zodat het protocol het account als financieel gezond beoordeelde. De aanvaller splitte vervolgens de grote positie over twee hulpcontracten, die daarna de receiver-fCash ontvingen.

In een tweede transactie sloot de aanvaller beide posities af, verhoogde daarmee de contante saldi in de Escrow en trok ten slotte de winst op.

Technische oorzaak: typeafkapping zonder controle

Volgens SlowMist ligt de kern van het probleem in de functie ExchangeRate._convertToETH. Die voert een uint128(balance.abs()) uit in Solidity 0.6.x zonder te controleren of het resultaat binnen het geldige bereik valt. Wanneer de verplichting -2^128 is, wordt de absolute waarde 2^128, wat bij afkapping naar het 128-bits type simpelweg 0 oplevert. Het protocol ziet dan een onderpandsaldo van minimaal nul en staat de positie toe, terwijl er in werkelijkheid geen dekking is.

Een vergelijkbare fout, waarbij een onjuiste berekening van saldi tot onterecht verlies leidde, deed zich eerder ook voor bij Reddio, dat 925 ETH verloor door een dubbeltellingslek in zijn vaults.

Aanbevelingen van SlowMist

SlowMist stelt dat een geslaagde typeconversie nog geen correcte waardebepaling garandeert. Het beveiligingsteam adviseert om elk resultaat van abs() te weigeren dat boven type(uint128).max uitkomt, SafeCast te gebruiken en grenswaarden zoals uint128.max en -2^128 expliciet te testen.

De bredere les die SlowMist trekt: een onderpandsaldo van nul of hoger betekent niet automatisch dat het onderpand ook daadwerkelijk aanwezig is. Protocollen die met vaste breedte rekentypes werken, lopen risico als extreme invoerwaarden niet vooraf worden afgewezen.