MetaMask Snap Audit Report For Polkadot

Management Summary

Polkadot contacted Sayfer Security in order to perform a security audit on Polkadot’s Metamask Snap application in August 2023.

Before assessing the above services, we held a kickoff meeting with the technical team and received an overview of the system and the goals for this research.

Over the research period of 2 weeks, we discovered 5 vulnerabilities across the snap’s codebase.

In conclusion, several fixes should be implemented following the report, but the system’s security posture is competent.

Risk Methodology

At Sayfer, we are committed to delivering the highest quality penetration testing to our clients. That’s why we have implemented a comprehensive risk assessment model to evaluate the severity of our findings and provide our clients with the best possible recommendations for mitigation.

Our risk assessment model is based on two key factors: IMPACT and LIKELIHOOD. Impact refers to the potential harm that could result from an issue, such as financial loss, reputational damage, or a non-operational system. Likelihood refers to the probability that an issue will occur, taking into account factors such as the complexity of the attack and the number of potential attackers.

By combining these two factors, we can create a comprehensive understanding of the risk posed by a particular issue and provide our clients with a clear and actionable assessment of the severity of the issue. This approach allows us to prioritize our recommendations and ensure that our clients receive the best possible advice on how to protect their business.

Risk is defined as follows:

Vulnerabilities by Risk

High – Direct threat to key business processes.
Medium – Indirect threat to key business processes or partial threat to business processes.
Low – No direct threat exists. The vulnerability may be exploited using other vulnerabilities.
Informational – This finding does not indicate vulnerability, but states a comment that notifies about design flaws and improper implementation that might cause a problem in the long run.

Severity
# of issues
High
0
Medium
2
Low
2
Informational
1

Approach

Introduction

Chainsafe contacted Sayfer to perform penetration testing on Polkadot’s Metamask Snap application.

This report documents the research carried out by Sayfer targeting the selected resources defined under the research scope. Particularly, this report displays the security posture review for the two MetaMask Snap applications and their surrounding infrastructure and process implementations.

Our penetration testing project life cycle:

01

Scope Overview

02

Technical Overview

03

Scope Validation

04

Threat Model

05

Security Evaluation

06

Security Assessment

Scope Overview

During our first meeting and after understanding the company’s needs, we defined the application’s scope that resides at the following URLs as the scope of the project:

Polkadot snap
Audit commit: 61787c6d2193e7ec6dee6cf3ecfae4b855717092
Fixes commit:

Our tests were performed in August 2023

Don’t let it be too late!

Start your audit with Sayfer

Scope Validation

We began by ensuring that the scope defined to us by the client was technically logical. Deciding what scope is right for a given system is part of the initial discussion. Getting the scope right is key to deriving maximum business value from the research.

Threat Model

During our kickoff meetings with the client we defined the most important assets the application possesses.

We defined that the largest current threat to the system is stolen user funds

Don’t let it be too late!

Start your audit with Sayfer

Security Evaluation Methodology

Sayfer uses OWASP WSTG as our technical standard when reviewing web applications. After gaining a thorough understanding of the system we decided which OWASP tests are required to evaluate the system.

Security Assessment

After understanding and defining the scope, performing threat modeling, and evaluating the correct tests required in order to fully check the application for security flaws, we performed our security assessment.

Issue Table Description

Issue title

ID SAY-??: An ID for easy communication on each vulnerability
Status Open/Fixed/Acknowledged
Risk Represents the risk factor of the issue. For further description refer to the Vulnerabilities by Risk section.
Business Impact The main risk of the vulnerability at a business level.
Location The URL or the file in which this issue was detected. Issues with no location have no particular location and refer to the product as a whole.

Description

Here we provide a brief description of the issue and how it formed, the steps we made to find or exploit it, along with proof of concept (if present), and how this issue can affect the product or its users.

Mitigation

Suggested resolving options for this issue and links to advised sites for further remediation.

Security Evaluation

The following tests were conducted while auditing the system

Information Gathering

Information Gathering Test Name
WSTG-INFO-01 Conduct Search Engine Discovery Reconnaissance for Information Leakage
WSTG-INFO-02 Fingerprint Web Server
WSTG-INFO-03 Review Webserver Metafiles for Information Leakage
WSTG-INFO-04 Enumerate Applications on Webserver
WSTG-INFO-05 Review Webpage Content for Information Leakage
WSTG-INFO-06 Identify application entry points
WSTG-INFO-07 Map execution paths through application
WSTG-INFO-08 Fingerprint Web Application Framework
WSTG-INFO-09 Fingerprint Web Application
WSTG-INFO-10 Map Application Architecture

Configuration and Deploy Management Testing

Configuration and Deploy Management Testing Test Name
WSTG-CONF-01 Test Network Infrastructure Configuration
WSTG-CONF-02 Test Application Platform Configuration
WSTG-CONF-03 Test File Extensions Handling for Sensitive Information
WSTG-CONF-04 Review Old Backup and Unreferenced Files for Sensitive Information
WSTG-CONF-05 Enumerate Infrastructure and Application Admin Interfaces
WSTG-CONF-06 Test HTTP Methods
WSTG-CONF-07 Test HTTP Strict Transport Security
WSTG-CONF-08 Test RIA cross domain policy
WSTG-CONF-09 Test File Permission
WSTG-CONF-10 Test for Subdomain Takeover
WSTG-CONF-11 Test Cloud Storage

Identity Management Testing

Identity Management Testing Test Name
WSTG-IDNT-01 Test Role Definitions
WSTG-IDNT-02 Test User Registration Process
WSTG-IDNT-03 Test Account Provisioning Process
WSTG-IDNT-04 Testing for Account Enumeration and Guessable User Account
WSTG-IDNT-05 Testing for Weak or unenforced username policy

Authentication Testing

Authentication Testing Test Name
WSTG-ATHN-01 Testing for Credentials Transported over an Encrypted Channel
WSTG-ATHN-02 Testing for Default Credentials
WSTG-ATHN-03 Testing for Weak Lock Out Mechanism
WSTG-ATHN-04 Testing for Bypassing Authentication Schema
WSTG-ATHN-05 Testing for Vulnerable Remember Password
WSTG-ATHN-06 Testing for Browser Cache Weaknesses
WSTG-ATHN-07 Testing for Weak Password Policy
WSTG-ATHN-08 Testing for Weak Security Question Answer
WSTG-ATHN-09 Testing for Weak Password Change or Reset Functionalities
WSTG-ATHN-10 Testing for Weaker Authentication in Alternative Channel

Authorization Testing

Authorization Testing Test Name
WSTG-ATHZ-01 Testing Directory Traversal File Include
WSTG-ATHZ-02 Testing for Bypassing Authorization Schema
WSTG-ATHZ-03 Testing for Privilege Escalation
WSTG-ATHZ-04 Testing for Insecure Direct Object References

Session Management Testing

Session Management Testing Test Name
WSTG-SESS-01 Testing for Session Management Schema
WSTG-SESS-02 Testing for Cookies Attributes
WSTG-SESS-03 Testing for Session Fixation
WSTG-SESS-04 Testing for Exposed Session Variables
WSTG-SESS-05 Testing for Cross Site Request Forgery
WSTG-SESS-06 Testing for Logout Functionality
WSTG-SESS-07 Testing Session Timeout
WSTG-SESS-08 Testing for Session Puzzling
WSTG-SESS-09 Testing for Session Hijacking

Data Validation Testing

Data Validation Testing Test Name
WSTG-INPV-01 Testing for Reflected Cross Site Scripting
WSTG-INPV-02 Testing for Stored Cross Site Scripting
WSTG-INPV-03 Testing for HTTP Verb Tampering
WSTG-INPV-04 Testing for HTTP Parameter Pollution
WSTG-INPV-05 Testing for SQL Injection
WSTG-INPV-06 Testing for LDAP Injection
WSTG-INPV-07 Testing for XML Injection
WSTG-INPV-08 Testing for SSI Injection
WSTG-INPV-09 Testing for XPath Injection
WSTG-INPV-10 Testing for IMAP SMTP Injection
WSTG-INPV-11 Testing for Code Injection
WSTG-INPV-12 Testing for Command Injection
WSTG-INPV-13 Testing for Format String Injection
WSTG-INPV-14 Testing for Incubated Vulnerability
WSTG-INPV-15 Testing for HTTP Splitting Smuggling
WSTG-INPV-16 Testing for HTTP Incoming Requests
WSTG-INPV-17 Testing for Host Header Injection
WSTG-INPV-18 Testing for Server-side Template Injection
WSTG-INPV-19 Testing for Server-Side Request Forgery

Error Handling

Error Handling Test Name
WSTG-ERRH-01 Testing for Improper Error Handling
WSTG-ERRH-02 Testing for Stack Traces

Cryptography

Cryptography Test Name
WSTG-CRYP-01 Testing for Weak Transport Layer Security
WSTG-CRYP-02 Testing for Padding Oracle
WSTG-CRYP-03 Testing for Sensitive Information Sent via Unencrypted Channels
WSTG-CRYP-04 Testing for Weak Encryption

Business logic Testing

Business logic Testing Test Name
WSTG-BUSL-01 Test Business Logic Data Validation
WSTG-BUSL-02 Test Ability to Forge Requests
WSTG-BUSL-03 Test Integrity Checks
WSTG-BUSL-04 Test for Process Timing
WSTG-BUSL-05 Test Number of Times a Function Can be Used Limits
WSTG-BUSL-06 Testing for the Circumvention of Work Flows
WSTG-BUSL-07 Test Defenses Against Application Mis-use
WSTG-BUSL-08 Test Upload of Unexpected File Types
WSTG-BUSL-09 Test Upload of Malicious Files

Client Side Testing

Client Side Testing Test Name
WSTG-CLNT-01 Testing for DOM-Based Cross Site Scripting
WSTG-CLNT-02 Testing for JavaScript Execution
WSTG-CLNT-03 Testing for HTML Injection
WSTG-CLNT-04 Testing for Client Side URL Redirect
WSTG-CLNT-05 Testing for CSS Injection
WSTG-CLNT-06 Testing for Client Side Resource Manipulation
WSTG-CLNT-07 Test Cross Origin Resource Sharing
WSTG-CLNT-08 Testing for Cross Site Flashing
WSTG-CLNT-09 Testing for Clickjacking
WSTG-CLNT-10 Testing WebSockets
WSTG-CLNT-11 Test Web Messaging
WSTG-CLNT-12 Testing Browser Storage
WSTG-CLNT-13 Testing for Cross Site Script Inclusion

API Testing

API Testing Test Name
WSTG-APIT-01 Testing GraphQL

Order audit from Sayfer

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    Security Assessment Findings

    RPC URLs are defined as wsRpcUrl while using HTTP

    ID SAY-01
    Status Open
    Risk Medium
    Business Impact It’s hard to determine the impact without a working demo. If the change is mistaken, it may break the snap, otherwise, this is a simple documentation/variable naming issue.
    Location packages/snap/src/configuration/predefined.ts:11,22,33

    Description

    The RPC URLs of individual protocols have been changed in the latest version of the snap. HTTP (http://) is used instead of WebSocket (wss://).

    This is unexpected, because the official Polkadot documentation indicates only websocket addresses in their resources. Additionally, in many places in the code, variable names still contain the ws prefix, such as wsRpcurl.

    predefined.ts:

    wsRpcUrl: 'https: /
    
    wsRpcUrl: 'https: /kusama-rpc.polkadot.io/'
    {...}
    wsRpcUrl: 'https: /westend-rpc.polkadot.io/'
    {...}
    wsRpcUrl: 'https: /rpc.polkadot.io/'
    

    Mitigation

    Make sure that the HTTP protocol is supposed to be used. If it is, change the official documentation to reflect this, and modify the relevant variable names.

     

    Conformations for Key Features are not Handled When Rejected

    ID SAY-02
    Status Open
    Risk Medium
    Business Impact If the user declines the transaction, nothing will be returned, which will end up with a JavaScript error, a generic undefined message, or nothing at all. This may cause undefined or unexpected behavior.
    Location – packages/snap/src/rpc/exportSeed.ts:14
    – packages/snap/src/rpc/substrate/sign.ts:33,53

    Description

    For key Snap functionalities (such as displaying the private key or signing of a message), dialogs are displayed for the user to confirm whether they are aware of what they are accepting. If the user confirms the transaction, it is executed. The converse, when the user rejects the transaction, is not handled at all.

    exportSeed(SnapsGlobalObject), notice how there is no else block

    if (confirmation) {
        const bip44Node = (await snap.request({
        method: "snap_getBip44Entropy",
        params: { coinType: kusamaCoinType },
    })) as JsonBIP44CoinTypeNode;
    

    signPayloadJSON(SnapsGlobalObject, ApiPromise, SignerPayloadJSON)

    if (confirmation) {
        const extrinsic = api.registry.createType('ExtrinsicPayload', payload, { version: payload.version });
        return extrinsic.sign(keyPair);
    }
    

    signPayloadRaw(SnapsGlobalObject, ApiPromise, SignerPayloadRaw)

    if (confirmation) {
        const signedBytes = keyPair.sign(hexToU8a(payload.data));
        return {
        signature: u8aToHex(signedBytes)
    };
    

    Unfortunately, since the automated tests did not work, we could not definitively verify and confirm this scenario.

    Mitigation

    Handle the else case, where the user rejects the transaction, in which case an appropriate error should be displayed.

     

    No Confirmation Dialogue when Sending

    ID SAY-03
    Status Open
    Risk Low
    Business Impact Without a confirmation dialogue, there’s a risk that a potential user will mistakenly execute a transaction sending funds to the wrong account.
    Location – packages/snap/src/rpc/send.ts:7-34

    Description

    When signing messages or displaying the private key, the snap displays a dialog box asking the user if they’re sure they want to proceed. However, no such confirmation dialogue is displayed when sending.

    Mitigation

    Implement a dialogue box asking the user to confirm the transaction.

     

    enablePolkadotSnap Returns an Error When Using the Default networkName

    ID SAY-04
    Status Open
    Risk Low
    Business Impact Non-compliance with business assumptions that Westend is the default network.
    Location – packages/adapter/src/index.ts:27-29

    Description

    It has been noticed that despite selecting Westend as the default network in snap/src/configuration/predefined.ts, if the adapter executes its only exposed function, enablePolkadotSnap(), without specifying config.networkName, then an error will be returned.

    This is inconsistent with Snap’s assumptions, described among others in the README.md of the adapter, which indicates that specifying a configuration will override the default one.

    packages/snap/src/configuration/predefined.ts; lines 13-22, 35

    
    export const westendConfiguration: SnapConfig = {
        addressPrefix: 42,
        networkName: "westend",
        unit: {
            decimals: 12,
            image: "https: /svgshare.com/i/L2d.svg",
            symbol: "WND",
        },
        wsRpcUrl: "wss: /westend-rpc.polkadot.io/",
    };
    [ .]
    export const defaultConfiguration: SnapConfig = westendConfiguration;
    

    packages/snap/src/configuration/predefined.ts; lines 27-29

    if (!config.networkName) {
    throw new Error("Configuration must at least define network type");
    }
    
    

    Mitigation

    Judging by the documentation and by the code in predefined.ts, this error should not be returned and Westend should be used. Conversely, Westend should not be set as the default and the documentation amended to reflect that.

     

    Non-Working Demo

    ID SAY-05
    Status Open
    Risk Informational
    Business Impact Having a working demo can both help users test out the functionality of the Snap, and help auditors greatly enhance their testing.
    Location

    Description

    According to the documentation, the command yarn install & yarn run demo should run a working demo of Snap, allowing you to install it and use the various features. Unfortunately, during installation, the browser console returned an error. Thus, the verification of Snap as a “living organism” was impossible}

    Mitigation

    We suggest bringing Snap to a usable state, and then conducting in-depth tests on real transactions with the Polkadot network.

    You can find more information about it on our Blog

    Sayfer’s blog focuses on web3, security, and vulnerability research. We believe that in the cybersecurity industry it’s crucial to stay up to date on the latest trends and advancements. Currently, our team of experienced researchers enjoys researching cutting-edge blockchain and web3 technologies.
    Contact us

    Keep In Touch

    Location
    Tel Aviv, Israel
    Messengers:
    Please feel free to contact us, we will be happy to respond!

      This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
      Skip to content