"Any updates??" - aka the LocalTapiola Bug Bounty Microblog

• 1 September 2021: We have revised our scope

• 4 June 2021: We have streamlined our policy.

The LocalTapiola bug bounty program

We want to hear about any security vulnerabilities in our services. We offer monetary rewards for eligible security vulnerability reports that are disclosed to us in a coordinated way. This policy contains the the rules that need to be followed to ensure that your security research does not cause security risk to other users or their data, and to decrease the likelihood that your research would be flagged as a malicious intrusion attempt by our monitoring.

We expect all reporters to be professional in their manners, have the ability to submit a quality report and have a decent understanding of our business and how our bug bounty program works. We run our program in universal English and expect all reports to be submitted in English. Subpar English skills (talking plainly through Google Translate) will most likely lead to mutual disappointment as we will most likely not find a common understanding. Explaining business impacts require good report writing skills.

The Scope

We approach our scope holistically. Hence and therefore we divide our scope into three categories.

Category I - Critical

Category I includes our main targets with the most serious business impact. A Category I target is explicitly listed on the scope page with a severity rating of Critical. Reports adhering to our basic ground rules and carrying serious criticality and impact can expect short response times and more than fair bounties.

Category II - High

Category II includes secondary targets with a lower business impact than Category I. A Category II target is explicitly listed on the scope page with a severity rating of High.

Category III

Category III is the catch-all category. Within Category III you are allowed to report on various findings with various impact. While we accept submissions on almost everything, it does however NOT imply that our bounty policy is lean - please read carefully through the criticality and impact -section. We may also add targets to our out of scope list at will. Always check the scope before submitting!

Category III includes everything within

• *.tapiola.fi

• *.lahitapiola.fi

• *.lahitapiolarahoitus.fi

Please do note that Category III DOES NOT INCLUDE TARGETS EXPLICITLY LISTED AS OUT OF SCOPE ON THE SCOPE PAGE (https://hackerone.com/localtapiola/scopes). If you submit a report against a target listed as out of scope, you will be banned from the program. No questions asked, no answers given.

In addition, services that are clearly shared SaaS services (albeit potentially branded as LocalTapiola) are EXPLICITLY OUT OF SCOPE even though not explicitly listed as such. You do NOT have our permission to hack shared SaaS services. DO NOT target these services in any way. You may be liable to criminal prosecution and face legal actions.

Our bounty policy

Qualified security vulnerabilities will be rewarded based on severity and impact.

We want to be fair in our bounties - similar reports will be awarded in a similar manner. We assess all reports based on business risk - criticality - and impact. Threats and threat models change constantly - therefore we reserve all rights to make bounty policy changes and apply said bounty policy at our discretion. Changes in bounties will never be retrospective. Our bug bounty program is constantly evolving.

We aim to "bounty-on-triage" - that is, make bounty decisions as soon as possible. The time to resolve issues can take a significant time (weeks - months) and we want to be fair to the reporters regarding time spent and payouts.

A few basic ground rules

• You must be the first reporter of a vulnerability

• The vulnerability must be in scope (ie. the report domain must exactly match the target you choose )

• We decide when and where a report is disclosed

• We may add a bonus for finding flaws related to PII - when properly reported we usually do.

• We interpret and reserve the right to interpret this policy and apply it as we see fit

Internal pivoting, scanning, exploiting, or exfiltrating data from internal LocalTapiola systems is prohibited. Do not exploit vulnerabilities more than you need to prove your point. Do not steal data and do not use malicious or destructive payloads. Don't break the law.

Speculative reports, pure scanning tool results, best practices and copy-paste bountybegging reports will brutally and ruthlessly be closed as n/a. Don't waste our time and we won't waste yours.

If you, against all odds, report something that is out of scope, we expect the report to have exceptional impact.

Criticality and impact

We are keen on business impact. That means we assess all reports based on how it affects the business, not how technically cunning the vulnerability is. A well written report is always preferable. Reports should not contain copied text directly from Wikipedia or scanners. If you feel that is needed, it most likely means the report has no real business impact. Reward amounts will vary based upon the severity of the reported vulnerability. The bigger the potential impact on users and customer data, the bigger the reward will be. The following factors affect the reward:

• customer scope (how many customers are potentially affected)

• internal users scope (how many users are potentially affected)

• systems extent (how many systems are potentially affected)

• authentication requirements (prerequisites for exploiting)

• difficulty of exploitability (additional requirements for exploiting)

• exploitability time window (limitations to exploiting)

• classification of data affected (privacy related)

Client-side vulnerabilities requiring (potentially complex) social-engineering and interaction from the end user do not typically result in a big reward.

Regarding duplicates

Nobody likes duplicates. This is how we work with them: When we mark a report as duplicate, we link it to an existing report. Sometimes a report is not publicly disclosed. If that is the case, you have to trust us. We know what we are doing.

Reports that are most likely to be dismissed or not eligible for bounty

• Best-practices -based reports

• Reports with very low business value (nonexistent risk, very low impact, ...) or reports that are purely theoretical

• It is not worth reporting self-exploitation or self-xss - there will be no bounties

In addition, these reports will be closed as n/a (if no significant business impact is shown):

• SPF/DKIM/DMARC related

• SSL/TLS best practices related

• Clickjacking or any kinds of http-header-issues - including host-headers

• Cookie nonsense, secure cookies, httponly etc.

• 404 or other error pages including stacktraces

• Anything that requires MitM:ing (or requires interfering with end-user traffic)

• DoS, DDoS or missing ratelimits

To sum it up - we appreciate reports where vulnerabilities have a proof of (minimal) exploitation included. We appreciate reports around issues that carry significant business value to us.

Rewards

Rewards may range from $50 up to $50,000. Rewards are NOT based on vulnerability classifications nor technical gimmicky trickery. Rewards are based on business impact. Not all targets are equally valuable.

In some cases, rewards may be consolidated into a single payout. For example, multiple reports of the same vulnerability across different parameters of a resource, or demonstrations of multiple attack vectors against a fundamental framework issue. If you report several issues that are duplicates in different parts of the service (e.g., the same code running on different nodes or platforms), or part of a larger issue, these may be combined into one and only one reward may be paid.

Rewards may be reduced or declined if there is evidence of abuse or breach of the LocalTapiola Bug Bounty program rules.

Additional details and outliers

Versions numbers and CVE-codes

We run a number of off the shelf products, commercial as well as open source. We do not accept reports purely based on CVE numbers and copy-pasted information from any CVE-database or scanning tools. As this usually involves scanning for version numbers, we do not accept reports with no (almost) other information than a version number. Patching and fixing for these kinds of vulnerabilities are part of our normal updating and patching cycles and we will not award any bounties for these kinds of reports. Having said this, we do NOT exclude reports that rely on known vulnerabilities nor findings which are very much business oriented and have a proven PoC against either our data or customers, regardless of how the vulnerability has been found (through a known CVE or based on finding a version number).

Vulnerabilities in 3rd party commonly used and widespread libraries

We accept reports on vulnerabilities and flaws found in 3rd party commonly used and widespread libraries which we are using in our services and applications. However, we strongly encourage to report these findings upstream directly to the author of the affected libraries. We regard these findings as "heads-up" warnings and our bounty policy is strict - the bounty for a vulnerability in a common 3rd party library that we will eventually fix and/or patch is always $100 USD - awarded on triage. In the name of making the Internet a safer place and in the case where the reporter does not want to handle the upstream reporting to the authors of the library, we reserve the right to do so ourselves.

About our customers privacy and how we handle the GDPR

Our bug bounty program is an additional strategic component in our ICT risk management process. As such, the bug bounty program also falls under the umbrella of security testing. Security testing engagements occasionally run into live production data which may or may not contain PII (personally identifiable information). Whenever PII data is encountered during testing, we expect and require any and all persons involved to handle that data with utmost care. Showing or proving the existence of a flaw does likely not require any data dumps - so even if possible, no dumping of PII data is allowed. Ever. Any exfiltrated PII data must immediately be deleted and any testing that might result in further PII being revealed must be halted. Do not store PII data. PII data samples, if needed in the report, should be properly obfuscated before posting. This includes submitting reports that contain your own data. In the case where PII data is posted in a report we will redact that information as soon as possible. If after the redaction the report is unintelligible, it will not be processed.

Legal

In connection with your participation in this program you agree to comply with all applicable local and national laws.

You may not participate in this program if you are a resident or individual located within a country appearing on any U.S. or E.U. sanctions list.

Vulnerabilities obtained by exploiting LocalTapiola users or employees are not eligible for a bounty and will result in immediate disqualification from the program.

LocalTapiola has never given permission/authorization (either implied or explicit) to an individual or group of individuals to extract personal information or content of LocalTapiola customers and publicize this information on the open, public-facing Internet without customer consent, nor has LocalTapiola ever given permission for programs or data belonging to LocalTapiola to be modified or corrupted in order to extract and publicly disclose data belonging to LocalTapiola.

LocalTapiola reserves the right to discontinue this reward program and change its terms at any time without prior notification. All decisions regarding reward payments are final. The rules of this reward program or any communication related thereto do not provide or imply any obligations to LocalTapiola of any kind.

Thank you for helping keep LocalTapiola and our customers safe!