Wise (ex-TransferWise)

Description

We are committed to ensuring a safe and secure service for our customers and we value the work done by security researchers in improving the security of our products. We are committed to working with this community to verify, reproduce, and respond to reported vulnerabilities. We encourage the community to participate in our responsible reporting process. Expectations When participating in our responsible reporting process, you can expect us to: Work with you to understand and validate your report, including a timely triage of your submission by our partner, Bugcrowd Work to remediate discovered vulnerabilities in line with our internal vulnerability management policy (from 1 to 180 days depending on severity) Keep you informed when the issue is fixed; and If eligible, reward you accordingly Wise employees are not allowed to participate in your program Third-party bugs If issues reported to our bug bounty program affect a third-party library, external project, or another vendor, we reserve the right to forward details of the issue along to that party without further discussion with you (the researcher). We will do our best to coordinate and communicate with you throughout the process. However, these bugs will not be rewarded. House Rules To benefit from the knowledge of security researchers, we encourage responsible disclosure of vulnerabilities in our platform. To avoid confusion between legitimate security research through the Bugcrowd program and a malicious attack, we ask that you attempt, in good faith, to: Play by the rules. This includes following our disclosure policy, including Bugcrowd’s standard disclosure terms and any other relevant agreements; Handle the confidentiality of details of any discovered vulnerabilities according to our Disclosure Policy; Report any vulnerability you’ve discovered promptly, provide details of the vulnerability, including information needed to reproduce and validate the vulnerability and if applicable, a Proof of Concept; Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope; Avoid violating the privacy of others, disrupting our systems, destroying or modifying data not belonging to your test account, and/or harming user experience; If a vulnerability provides unintended access to data: limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept (PoC); and cease testing. Submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), sensitive data, or proprietary information; Although usage of automated vulnerability discovery tools is allowed, you should exercise common sense and avoid overly broad scans that initiate a huge amount of needless requests. This might result in us rate-limiting or blocking you, or closing your testing account. Do not simply send us a scanner's default output - focus on specific finding and clearly demonstrate impact (PoC). When scanning, use your Bugcrowd testing account (authenticated scans) or make it clear with the User-Agent header that you are a researcher. As we're seeing legitimate attacks, this information is useful for us for triage; You should only interact with test accounts you own; Do not engage in extortion; Use the official Bugcrowd channel to discuss vulnerability information with us; Safe-harbour Compliance We consider activities conducted consistent with this policy to constitute “authorized” access under anti-hacking laws. To the extent your activities are inconsistent with certain restrictions in our Acceptable Use Policy, we waive those restrictions for the limited purpose of permitting security research under this policy. We will not bring a claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. We will not pursue civil action or initiate a complaint to law enforcement for accidental, good faith violations of this policy. You are expected, as always, to comply with all applicable laws. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please reach out to us directly before going any further. PGP Fingerprint: C8A1 9A40 C078 006A 4FD2 5F88 EC52 91DC 8DC2 8D45 PGP key published at: pgp.mit.edu mailto: soc [@] wise.com Disclosure Policy This program does not allow disclosure. Although we have chosen to adopt a non-disclosure policy, this is temporary. In the meantime, you MUST not release information to any third party (and the public) about vulnerabilities found and/or remediation measures implemented. Priority Modelling This program adheres to the Bugcrowd Vulnerability Rating Taxonomy for the severity rating and prioritization of issues. Responsible Disclosure Guidelines We will investigate legitimate reports and make every effort to quickly correct any vulnerability. To encourage responsible reporting, we will not take legal action against you nor ask law enforcement to investigate you providing you comply with the following Responsible Disclosure Guidelines: Provide details of the vulnerability, including information needed to reproduce and validate the vulnerability and a Proof of Concept (POC) Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our services Do not modify or access data that does not belong to you This program adheres to the Bugcrowd Vulnerability Rating Taxonomy for the rating/prioritization of issues.

Targets

Access When registering for an account at https://wise.com for testing purposes, use your @bugcrowdninja e-mail, i.e. @bugcrowdninja.com . You can also use alias emails when multiple accounts are required for testing, i.e. [email protected]. Do not use any other e-mails, unless testing for a specific bug that requires this. Avoid creating excessive amount of users. Accounts and / or IPs that violate this guideline can be blocked. Focus Areas We are constantly updating our services to make transfer of funds low-cost, fair, easy and fast. We rolled out critical functionalities to meet these targets and we would like to get more eyes on them. Please pay more attention on the following areas: Multi-User Access Wise offers a feature for business accounts that enables multiple people to access one account. We call it Multi-User Access (MUA). Please focus on the possible misuses of this feature set, such as: Managing users (inviting/removing users and changing roles) Bypassing role-based permissions, or Interacting with unauthorized accounts (profiles) To test this feature, you need to create a Wise for Business account under your testing account. The business account name should clearly identify that this is created for testing purposes, e.g. Test Business Account or My Business Testing Account. If you need your testing business account to be verified for deeper testing, get into the full business account onboarding process by having yourself verified using real documents (i.e. uploading real IDs). Once successfully verified, you will still be bound by its legitimate use set out in our acceptable use policy ( https://wise.com/terms-and-conditions ). If you run into any issues that have no security impact, please redirect your reports to our help page ( https://wise.com/help/ ). Wise API Our API is a less-seen, but critical part of our infrastructure offering. You can find the API docs at https://api-docs.wise.com and our sandbox testing environment at https://sandbox.transferwise.tech . We’re encouraging researchers to read our API documentation and to find API misuses that could significantly affect our business or our customers. Multi-factor Authentication Wise offers two types of multi-factor authentication (MFA): SMS and app-based authentication. We would like you to identify possible security issues with our MFA workflow, such as device registration and deactivation and bypass vectors. SMS and SIM vulnerabilities, like those publicised around SS7, are out of scope because we wish to test our implementation and not the underlying infrastructure. In order to test app-based authentication, you should set up SMS authentication first and then upgrade to app-based authentication via the settings menu on the iOS or Android apps. SCA support for EEA customers On 14 Sept 2019, the Strong Customer Authentication (SCA) requirement of the EU Revised Directive on Payment Services (PSD2) went into effect. This requirement ensures that payment service providers within the European Economic Area implement MFA on electronic payments. In compliance, we recently rolled-out application-wide (web, mobile) changes affecting all customers with borderless accounts with country of residence within the EEA. The following functionalities will now require a password or biometrics (mobile app) to proceed: Downloading of statements Sending money Profile obfuscation when the user is inactive for X minutes (currently, 5 mins) Revealing PIN or card details Users who created their account via Facebook / Google within EEA are now required to set a password; this password will be used for confirmation when any of the above actions are triggered. We are interested in application misuses that circumvent PSD2/SCA protections we have in place. Wise Card Wise has its own debit card - the Wise Card. We would love to have some attention on card management, account services (statement of accounts), and the card freeze features. To test these features, you should set up your own Wise account and have a card issued to you. This involves having a verified Wise account and signing up to our multi-currency account offering. The Wise card is only available in selected countries at the moment - see the full list of countries supported here . Clarifications About Scope Reports classified as P5 do not qualify for a monetary reward. Focus on impactful findings: how does this affect confidentiality, integrity or availability of Wise or customers? Minor misconfigurations or missing best-practices with low impact typically do not qualify for a reward. Out of Scope The following types of submissions will not be accepted and will be marked as "Out of Scope": Missing SPF / DMARC records on domains that are not used for sending mail (verify that the domain sends e-mail first) Email spoofing where SPF / DKIM / DMARC is configured, but recipient ignores validation failures Denial of Service attacks due to excessive amount of requests Attacks against customer support; through contact forms or methods (e.g. https://wise.com/help/contact or phone lines) Vulnerabilities only affecting unsupported browsers or platforms (unsupported meaning the vendor has declared end-of-life) API keys that are designed to be public. Some 3rd party vendors we adopt use public API keys to identify the customer (for example: as customer ID, for submitting crash reports). When finding a vendor API key, please check from the vendor's documentation how the key should be used and secured; and whether our implementation violates those guidelines. If the key is used only to identify the request sender; but does not grant any unauthorized access, the finding is out of scope. Submissions relating to the following HTTP Security Headers: X-Frame-Options - this header is deprecated and replaced by CSP; we won't be implementing it X-XSS-Protection header Any other missing HTTP security header, unless accompanied by a impactful PoC Sample secrets (private keys, passwords) in GitHub repositories, if the included documentation clearly states this to be a sample/unused password; or it's clear from the code these secrets are only used during automated testing (CI) Self-XSS, or XSS attacks that require local access Physical attacks against Wise premises or employees Attacks that require a rooted / jailbroken phone to work; or attacks that require an already compromised system (debugger installed, memory dump possible). If a client device is already compromised to that level, meaningful protection of our processes is not feasible. Available typosquatting / punycode / unicode identifiers (such as domain names, e-mail addresses); or identifiers with the name " Wise " in them. For example: unregistrered domain name this-is-wise-testing-site.com ; or unclaimed S3 bucket name tr4nsferwis3-staging . Reports typically state phishing risk, but we can't claim every conceivable variation of the name. Reports can still be accepted, if the identifier is in actual use by our production systems (hijacking - with a PoC) Attacks that depend on a man-in-the-middle actor in the network path, IF a 3rd party CA is installed to the system Default output of security scanners, without any specific accompanying proof-of-concept attack Findings related to publicly exposed prometheus endpoints KYC related reports Public reports or databases of leaked credentials (which we proactively monitor), unless the credentials belong to a Wise employee and the researcher demonstrates a successful login to a Wise internal system Findings that require a clear proof-of-concept with impact The following categories of findings are usually rejected or qualified as a P5 unless the submission includes a working and impactful proof-of-concept, affecting availability, confidentiality or integrity. Please include a specific proof of concept that clearly demonstrates significant impact. For example, it is not enough to say that due to a missing X-Frame-Options header, clickjacking might be possible - you would need to submit a proof-of-concept abuse that is specifically crafted to target Wise; more than an on the page; requires minimal interaction; and clearly demonstrates significant effect for the victim. Internal DNS / IP / path (file or class) disclosures Descriptive error messages (stack traces, application errors) Clickjacking due to lax framing source policies (CSP frame-ancestors ). Reports without a PoC that directly impacts customers (disables 2FA, sets up a transfer...) will be rejected as out of scope Missing best practices in TLS configuration (ie TLS1.2 support; BEAST attack; weak cipher suites enabled) Not stripped EXIF metadata on files, such as images and PDF-s - unless having a serious and clear impact. For example: author name on a stock image - no impact; GPS coordinates on a profile photo uploaded by another customer - valid impact Broken links to any destination that can be hijacked (example: link to an expired domain from our blog). Unless the link is similar enough to Wise.com and can be considered phishing risk; this would be a P5. Attacks against our Android/iOS apps that require a malicious (other) application on the device, if there is no feasible defense we could implement Missing Secure ; HttpOnly ; or SameSite flags for cookies not used for secret storage Fingerprinting / banner / version disclosure CSRF attacks against publicly available forms Issues relating to browser "autocomplete" and "save password" functionality Data leakage issues from local devices due to Cache-Control: private header Information disclosure for non-sensitive information Missing best-pracices without a realistic attack scenario Common findings that are not bugs If you have enabled 2FA and you are not asked for it during 2nd login, please check if you have “Remember Me” checkbox enabled on login screen. This sets a cookie about using trusted device. Rate limiting and DDoS concerns - while no service guarantees 100% protection and we are open to any valid finding, please keep in mind, that we use Cloudflare rate limiting and DDoS protection service. So your initial test might show no rate limiting, but it kicks in from certain threshold, based on our risk assessment. Credentials in Github repos - while we discourage using passwords and especially leaving them in configuration files, we do keep some sample passwords in our public repos. If the password is called “password”, “changeit”, “secret” or similar easy phrase, please read the full code and try to understand if this is really a mistake or maybe left there as an example or placeholder. Findings about sample passwords in GitHub repositories are not valid. Not asking for password / 2FA on account deactivation Webhook functionality making requests to external IPs / domains Ability to log in after account creation, without verifying the e-mail first Notes Avoid submitting the same underlying issue multiple times. For example, if the same issue exists in our testing and production site, send both with one submission Some of the pay-in methods incur a transaction charge. Should the researcher chose to use them, Wise won't be able to refund these charges. Pay-in using bank transfers will result in no extra charges for the researchers. Test transactions should be less than £20 or equivalent in value. Unless you plan to test by actually transferring funds between your test accounts, the transactions should be cancelled through the UI (and money marked as "not sent") once the flow has been completed. We have layered protection and not all our security checks happen synchronously and seen in the front end. There are background verification and fraud checks regarding monetary transactions, so we encourage you to do a PoC and verify if you can actually bypass our procedures. Many Android researchers like to use Drozer to initially evaluate the attack surface of the app. Please submit a PoC including details and not just the output after running the tool. We also need the environment configuration that was used (e.g. Virtual and the Android version).

Sandbox environment (in scope)

This environment is a development sandbox for Wise partners. It closely mirrors production but does not require KYC, making testing potentially easier. Please note that testing here is subject to the same restrictions as the live production environment (particularly concerning automated testing). Any findings exclusive to this environment will likely be rated P5 (Informational).