Guidelines

• Provide a detailed description of the environment from which you tested (Android or Apple, Device information, Version of the App, tools used, … )
• Provide detailed but to-the point reproduction steps
• Include a clear attack scenario, a step by step guide in the PoC is highly appreciated
• Remember: quality over quantity!

General

'Responsible disclosure' (Tier 0) and rewarding “Bug Bounty” (Tier 2) for researchers provide an additional way for us to improve, where required, and we hope you help us be fast at it as well.
If and when researchers like you notify us of any security threats before going public with the information this is a win-win. This gives us a chance to fix the issue before people with bad intentions become aware of it, and it provides you with a bounty for the work you put into it for Tier 2 Domains.
Please be aware and respect the domains and impacts in scope as indicated. Although domains in Tier 0 are by default not eligible for a Bounty, we can still decide to make you an “itsme® Besti” (with corresponding award as “Bonus for Excellence in Security Testing on itsme®”). Decisive factors there are quality of reports, final impacts to our services and efforts invested by the researcher(s).

Main Interest

We are particularly interested, but not limited to, find out how one can exploit our solution to:

• Gain unauthorized/privileged access to specific code or elements in the itsme® App
• Extract sensitive personal data like the transaction details by using the itsme® App
• Extract sensitive personal data like Name / Birth-date / Location / Nationality, the kind of information we call “Core Identity Data”
• Compromise PIN as entered by the user in the itsme® App
• Compromise the Cryptographic operations in the itsme® App up to generation of a successful operation for a random user
• On top: Exploits for a vulnerability that could have an impact on the itsme® services via the assets / URL’s under Responsible Disclosure (Please note: Tier 0, no Bounty, but limitless gratitude is your reward)

The Scope excludes the use of other web-sites or resources

Examples of such as (non-exhaustive):

• Redirects to other, third party sites for enrolment ("Identity Registrars", Banks), further information or usage of itsme ("Service Providers"): The scope of this project is EXCLUSIVE to the sites hosted by / exploited by Belgian Mobile ID. None of our partners or customers should be impacted by the subject of this Bug Bounty Project.

• Using the BLOCK-function of the https://my.itsme.be/en/block pages is out-of-scope, as it constitutes a Denial-Of-Service against other users of the itsme services

• https://brand.belgianmobileid.be/

• As well as other Belgian mobile ID / itsme externally hosted URL’s or resources on Github, Wetransfer, Office365, Google, as well as the (Apple and Google) Stores hosting the itsme app.

Specific App exclusions from earlier, internal BMID security validations

• Bypassing Root- or Hook-detection on Android is currently out-of-scope: BMID is aware of the possibility to circumvent the root-detection, and is currently/constantly working to catch up in this cat-and-mouse game.
• Redirects over TLS with insecure handling of possibly sensitive data. BMID is working on improvements in securing these redirects.

• Exposure of API keys for external app tracking (eg. Google Firebase)
  

• "Simple" App Repackaging, adding separate code (App Code itself not impacted)

General

• Physical or social engineering attempts: this includes phishing attacks against employees and more specifically also social engineering/phishing of the itsme enrolment process at IDRs (banks)
• Best practices concerns
• Highly speculative reports about theoretical damage. Be concrete.
• DDoS or unrealistic Brute Forcing Attacks
• MSISDN/account enumeration via enrolment Pages or Block/re-activation error messages
• Publicly accessible itsme login pages - These generally have low security impact
• Reports that state that software is out of date/vulnerable without proven exploitable risks
• Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue in the context of our App

Infrastructure

• Open ports without an accompanying proof-of-concept demonstrating vulnerability
• Recently discovered zero-day vulnerabilities found in in-scope assets within 14 days after the public release of a patch or mitigation may be reported, but are usually not eligible for a bounty.
• Weak SSL configurations and SSL/TLS scan reports (this means output from sites such as SSL Labs)
• Missing or incorrect DMARC/DKIM/SPF records

Below you can find some examples of every criticality so it's clear what you can expect when you are reporting a vulnerability to us:

Exceptional

• itsme® database access for random users via manipulation of the itsme® App

Critical

• Access / compromise to a (1) itsme® Users’ Cryptographic Key-material: able to generate successful itsme® Transactions (Cfr. OWASP Top10 Mobile Risks - M5)
• Acquire (other) sensitive data of an itsme® user (Cfr. OWASP Top10 Mobile Risks - M2)
• Vertical privilege escalation (Cfr. OWASP Top10 Mobile Risks - M6)
• Change Core ID information of a user (e-mail address is not Core ID information: excluded … )
• Access to all user data or access to a targeted user

High

• Reverse Engineering (Cfr. OWASP Top10 Mobile Risks - M9): More specific, De-obfuscation of critical code from the App: make distinction with access to users crypto material
• Executing successful transactions with a copied itsme App instance (eg. running on emulator)
• Access to users PIN information after App-capture (Cfr. OWASP Top10 Mobile Risks - M4)

Medium

• Improper Platform Usage (Cfr. OWASP Top10 Mobile Risks - M1)
• Insecure Communication (Cfr. OWASP Top10 Mobile Risks - M3)
• App Code Tampering (Cfr. OWASP Top10 Mobile Risks - M8)

Low

• Poor Code Quality (Cfr. OWASP Top10 Mobile Risks - M7)
• Stack Trace of the itsme application

Swag

Special rewards will be considered on top of bountys like swag (promotional material). Well written reports combined with high criticality will be rewarded with additional “itsme®” material promoting your skills and the way you helped itsme® even more secure. Details will be determined based on the actual submission, and your suggestions.

Can we receive test accounts for employers?

No: The testing is done either with an “itsme®” application which us not yet initialised, or which is configured with your itsme® credentials (go here: https://www.itsme.be/en/get-started While doing this please use an @intigriti.me address so we can trace the test accounts.