Code of Conduct

We expect all researchers to adhere to ethical standards when participating in our Responsible Disclosure Program. This includes:

• Acting in good faith and avoiding harm to Techem, its customers, or its partners.
• Respecting privacy and confidentiality of any accessed data.
• Refraining from making threats or demands for compensation.
• Respect the Community Code of Conduct
• Respect the Intigriti Terms and Conditions
• Respect the scope of the program
• Not discuss or disclose vulnerability information without prior written consent (including PoC's on YouTube and Vimeo)

Our Commitment

• We will investigate and verify all legitimate reports.
• We will keep you updated on the progress of our investigation.
• We will work towards resolving valid vulnerabilities in a timely manner.

Legal Considerations

We will not take legal action against researchers who act in good faith and follow this policy. However, any violations of applicable laws or engagement in malicious activities will be subject to legal consequences.

We are happy to announce our program! We've done our best to clean up our known issues and now would like to request your help to spot the ones we missed!

Responsible Disclosure Policy

At Techem, we take the security of our systems, products, and customer data seriously. We recognize the importance of security researchers and ethical hackers in helping us improve our security posture. If you discover a security vulnerability, we appreciate your responsible disclosure to us.

If you identify a potential security issue in any of our systems, products, or services, we encourage you to report it responsibly by following these guidelines:

• Verify the vulnerability responsibly: Researchers may test and verify vulnerabilities but must avoid actions that could cause harm, such as data leakage, system disruption, or privacy violations. To conduct further verification, researchers should contact us, and we will collaborate on the validation process together.
• Provide a clear report: Include a detailed description of the vulnerability, steps to reproduce it, and any relevant supporting material (e.g., screenshots, proof-of-concept code).
• Respect confidentiality: Researchers must not publicly disclose the vulnerability at any time unless explicitly approved by Techem.
• Comply with laws: Ensure that your testing adheres to applicable laws and does not involve social engineering, denial-of-service attacks, or unauthorized access to third-party data.
• Limit testing to necessary actions: Avoid excessive requests or brute-force techniques that could impact service availability.
• Use responsible timing: Report vulnerabilities promptly and avoid testing during critical business hours if possible.
• Protect sensitive data: If you accidentally access user data, do not store, share, or exploit it—report it immediately and securely delete any copies.
• Be transparent and cooperative: Provide all relevant details and remain available for follow-up communication.

Prohibited Actions

• Physical Damage: Any testing or reporting that involves damaging, destroying, or opening the device will not be permitted.
• Radio Protocol Vulnerabilities: Researchers may analyze the radio protocol for vulnerabilities remotely, but should not interfere with or disrupt the device’s normal operation.
• Denial of Service (DoS): DoS attacks, including attempts to exhaust the device’s resources or communication channels, will not be permitted.
• Firmware and Software Outdatedness: Vulnerabilities that only exist in outdated software/firmware, which is no longer actively maintained or supported by the company.
• Physical Access: Attacks that require physical access to the device or the ability to compromise its physical security are not allowed.
• Radio Interference: Any attempt to introduce radio interference or exploit vulnerabilities in the radio frequency that would affect the operation of the devices is prohibited.
• Data or Settings Tampering: Tampering with device settings or the data stored on the device is not allowed. Any actions that jeopardize the proper provision of Techem's services (e.g., billing services), such as altering meter readings, are strictly prohibited.

Out of Scope

General

• In case that a reported vulnerability was already known to the company from their own tests, it will be flagged as a duplicate
• Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited
• Spam, social engineering and physical intrusion
• DoS/DDoS attacks or brute force attacks
• Vulnerabilities that only work on software that no longer receive security updates
• Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts
• 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
• Reports that state that software is out of date/vulnerable without a proof-of-concept

Application

• Wordpress usernames disclosure
• Pre-Auth Account takeover/OAuth squatting
• Self-XSS that can't be used to exploit other users
• Verbose messages/files/directory listings without disclosing any sensitive information
• CORS misconfiguration on non-sensitive endpoints
• Missing cookie flags
• Missing security headers
• Cross-site Request Forgery with no or low impact
• Presence of autocomplete attribute on web forms
• Reverse tabnabbing
• Bypassing rate-limits or the non-existence of rate-limits.
• Best practices violations (password complexity, expiration, re-use, etc.)
• Clickjacking without proven impact/unrealistic user interaction
• CSV Injection
• Sessions not being invalidated (logout, enabling 2FA, etc.)
• Tokens leaked to third parties
• Anything related to email spoofing, SPF, DMARC or DKIM
• Content injection without being able to modify the HTML
• Username/email enumeration
• Email bombing
• HTTP Request smuggling without any proven impact
• Homograph attacks
• XMLRPC enabled
• Banner grabbing/Version disclosure
• Not stripping metadata of files
• Same-site scripting
• Subdomain takeover without taking over the subdomain
• Arbitrary file upload without proof of the existence of the uploaded file
• Blind SSRF without proven business impact (pingbacks aren't sufficient)
• Disclosed/misconfigured Google Maps API keys
• Host header injection without proven business impact

Mobile

• Shared links leaked through the system clipboard
• Any URIs leaked because a malicious app has permission to view URIs opened
• The absence of certificate pinning
• Sensitive data in URLs/request bodies when protected by TLS
• Lack of obfuscation
• Path disclosure in the binary
• Lack of jailbreak & root detection
• Crashes due to malformed URL Schemes
• Lack of binary protection (anti-debugging) controls, mobile SSL pinning
• Snapshot/Pasteboard leakage
• Runtime hacking exploits (exploits only possible in a jailbroken environment)
• API key leakage used for insensitive activities/actions

Device & Hardware (and its backend services):

• Any physical damage or tampering with the device (including case opening, chip-off attacks, or any destructive testing)
• Side-channel attacks (e.g., power analysis, EM emissions)
• Attacks requiring custom hardware modifications or soldering
• Glitching or voltage fault injection attacks
• Attacks that require physical access to the device beyond normal user interactions
• Jamming or Denial-of-Service (DoS) attacks on the radio communication
• Attacks requiring a custom firmware flash or modification of the device firmware
• Replay attacks without demonstrating an actual impact (e.g., unauthorized billing modifications)
• Passive eavesdropping of encrypted radio transmissions without proof of decryption
• Theoretical cryptographic weaknesses without practical exploitation scenarios
• Open ports or banner grabbing without demonstrating a security impact
• Lack of security headers or cookie attributes without proven exploitation
• Generic misconfigurations in cloud environments (e.g., default settings without impact)
• API endpoints that do not handle sensitive data or lack authentication but have no exploitable risk

This program follows Intigriti's triage standards

Are there any rewards?

While we do not offer bounties for reported vulnerabilities, we deeply appreciate your contribution to securing our systems. As a token of our gratitude, we offer presents (e.g. merch, gift cards) in specific cases, such as high severity vulnerabilities, well written reports or innovative exploitation techniques.
Moreover, if a vulnerability also falls within the scope of one of our private programs, we will provide a bonus equivalent to the bounty amount, ensuring fair compensation for your efforts.