Metamask Snap revisionsrapport for Sei

Ledelsesoversigt

Sei kontaktede Sayfer Security for at udføre penetrationstest på Seis MetaMask Snap i januar 2024.

Inden vi vurderede ovenstående tjenester, holdt vi et kickoff-møde med Sei tekniske team og fik et overblik over systemet og målene for denne forskning.

I løbet af undersøgelsesperioden på 2 uger opdagede vi 3 sårbarheder i systemet.

Som konklusion bør flere rettelser implementeres efter rapporten, men systemets sikkerhedsposition er kompetent.

Efter en gennemgang fra Sayfer-teamet bekræfter vi, at alle sikkerhedsproblemerne nævnt i denne rapport er blevet løst af Sei-teamet.

Risikometodologi

Hos Sayfer er vi forpligtet til at levere penetrationstest af højeste kvalitet til vores kunder. Det er derfor, vi har implementeret en omfattende risikovurderingsmodel for at evaluere alvoren af ​​vores resultater og give vores kunder de bedst mulige anbefalinger til afbødning.

Vores risikovurderingsmodel er baseret på to nøglefaktorer: IMPACT og SANDSYNLIGHED. Påvirkning refererer til den potentielle skade, der kan følge af et problem, såsom økonomisk tab, skade på omdømme eller et ikke-operativt system. Sandsynlighed refererer til sandsynligheden for, at et problem vil opstå under hensyntagen til faktorer som kompleksiteten af ​​angrebet og antallet af potentielle angribere.

Ved at kombinere disse to faktorer kan vi skabe en omfattende forståelse af den risiko, et bestemt problem udgør, og give vores kunder en klar og handlekraftig vurdering af problemets alvor. Denne tilgang giver os mulighed for at prioritere vores anbefalinger og sikre, at vores kunder får den bedst mulige rådgivning om, hvordan de beskytter deres forretning.

Risiko er defineret som følger:

Sikkerhedsvurderingsmetode

Sayfer bruger OWASP WSTG som vores tekniske standard ved gennemgang af webapplikationer. Efter at have fået en grundig forståelse af systemet besluttede vi, hvilke OWASP-tests der kræves for at evaluere systemet.

Sikkerhedsvurdering

Efter at have forstået og defineret omfanget, udført trusselsmodellering og evalueret de korrekte test, der kræves for fuldt ud at kontrollere applikationen for sikkerhedsfejl, udførte vi vores sikkerhedsvurdering.

Beskrivelse af problemtabel

Udgavetitel

Beskrivelse

Her giver vi en kort beskrivelse af problemet og hvordan det opstod, de trin, vi tog for at finde eller udnytte det, sammen med proof of concept (hvis det er til stede), og hvordan dette problem kan påvirke produktet eller dets brugere.

Mitigation

Foreslåede løsningsmuligheder for dette problem og links til anbefalede websteder for yderligere afhjælpning.

Sikkerhedsvurderingsresultater

[L] Funktioner vender tilbage ved fejl uden at kaste en fejl

Beskrivelse

Når du ringer til signDirect og signAmino handlere, hvis account or account.privateKey ikke eksisterer, afsluttes programmet uden at returnere en fejlmeddelelse. Selvom dette ikke udgør en trussel fra et sikkerhedsperspektiv, vil brugeren ikke modtage nogen nyttig feedback, der forklarer, hvorfor snappet mislykkedes.

• src/api.ts:30, 65

if (!account?.privateKey) return;

Mitigation

Når programmet fejler, skal det altid returnere en fejlmeddelelse og vise den til brugeren.

[I] Ubrugt funktion

Beskrivelse

getWallet funktion i snapWallet.ts kaldes ikke af nogen RPC-handler defineret i snappet. Derudover findes der allerede en identisk funktion med samme indhold i kernepakken.

Mitigation

Eksistensen af ​​denne duplikerede metode ser ikke ud til at tjene nogen funktionalitet. Det kan sikkert fjernes.

[I] Manglende dokumentation

Beskrivelse

Snappen ser ikke ud til at have nogen form for teknisk dokumentation, der forklarer de enkelte RPC-metoder, deres anvendelse eller de funktionelle krav, som koden skal opfylde. Det er god praksis at have en beskrivelse af hvert indgangspunkt, der stilles til rådighed for brugerne til brug.

Mitigation

Vi foreslår at oprette teknisk dokumentation, der angiver beskrivelsen af ​​hver RPC-handler, samt beskriver metoderne til at kommunikere med dem fra dApp-niveau.