Metamask Snap revisionsrapport for Qtum

Ledelsesoversigt

Qtum kontaktede Sayfer Security for at udføre penetrationstest på Qtums MetaMask Snap i 05/2024.

Inden vi vurderede ovenstående tjenester, holdt vi et kickoff-møde med Qtums 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 5 sårbarheder i systemet, ingen af ​​dem kritiske.

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 Qtum-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

Ingen metode til at fjerne tilføjede netværk

Beskrivelse

Koden implementerer muligheden for at tilføje yderligere netværk, hvilket udvider deres liste ud over standarden. Det blev dog bemærket, at der ikke er nogen måde at fjerne dem på, undtagen ved at geninstallere snappen. Denne funktionalitet var sandsynligvis planlagt, fordi der er en removeNetwork() funktion, men det er ikke muligt at kalde den fra offentligt tilgængelige metoder.

export const networks = {
    get: getNetworks,
    setCurrent: setCurrentNetwork,
    add: addNetwork,
    remove: removeNetwork,
};

Mitigation

Vi anbefaler at implementere denne metode, som det sandsynligvis var meningen.

Manglende bekræftelsesprompt for eksport af private nøgler

Beskrivelse

I de fleste kritiske funktioner på et øjeblik vises en dialogboks, som informerer brugeren om den handling, der udføres, og anmoder om deres godkendelse.

Denne sikkerhedsforanstaltning er dog ikke til stede i WalletExportPrivateKey-metoden, den der bruges til at vise den private nøgle på snapskærmen. Hvis den påkaldes ved en fejl, vil den straks vise den private nøgle.

Mitigation

Før du viser den private nøgle, skal du tilføje en bekræftelsesprompt, der anmoder om brugerens godkendelse.

Flere uimplementerede metoder

Beskrivelse

En stor del af de metoder, der er til stede i snappet, ser ud til at være ubrugte. Kun kedelpladen omkring dem eksisterer, men ikke nogen konkret logik.

Mitigation

Vi anbefaler, at du gennemgår de metoder, du gerne vil implementere i dit snap, og sikrer dig, at de alle indeholder egentlig logik. Det skal ikke være muligt for brugeren at kalde unødvendige metoder, som du ikke har tænkt dig at implementere.

Redundant kode

Beskrivelse

Under vores analyse har vi bemærket, at to RPC-metoder, EthRequestAccounts og EthAccounts, ser ud til at gøre det samme og returnere de samme værdier.

case RPCMethods.EthRequestAccounts: {
    const wallet = await getWallet();
    return [wallet.address];
}
case RPCMethods.EthAccounts: {
    console.log('RPCMethods.EthAccounts');
    console.log('request.params', JSON.stringify(request.params));
    const wallet = await getWallet();
    return [wallet.address];
}

I begge tilfælde henter disse metoder den aktive tegnebogs data ved at bruge getWallet() og returnerer derefter dens adresse. I øjeblikket er den eneste forskel, at EthAccounts logger, mens EthRequestAccounts ikke gør det.

Mitigation

Overvej enten at fjerne en af ​​metoderne eller at ændre den ene for at adskille den fra den anden

Tilbageværende TODO-kommentarer

Beskrivelse

Kodebasen indeholder flere TODO-kommentarer og også dele af kommenteret kode, som ikke længere bruges.

Selvom dette er acceptabelt i et testmiljø, bør det elimineres i produktionen. Sådanne kommentarer kan give en potentiel interessent værdifuld information om manglende funktionaliteter, sikkerhedsforanstaltninger og udvikleres tanker, som kan bruges til at profilere angreb.

Mitigation

Vi foreslår, at du fjerner kommentarer markeret som TODO og ubrugte kodefragmenter i din produktionsgren.