1. Einleitung

Die Sicherheit unserer Produkte und Dienste sowie der Schutz der uns anvertrauten Kundendaten haben für BlueRange höchste Priorität. Das gilt für die BlueRange Smart Building Plattform ebenso wie für die Gateways, die Mesh-Firmware und die Apps, die in Gebäuden unserer Kunden im Einsatz sind. Unabhängige Sicherheitsforschende leisten einen wertvollen Beitrag, indem sie Schwachstellen aufdecken, die andernfalls unentdeckt bleiben könnten.

Diese Richtlinie beschreibt, wie sich autorisiert nach Schwachstellen suchen lässt, wie uns Erkenntnisse gemeldet werden können und was im Gegenzug von uns erwartet werden kann. Wir schätzen die Mitarbeit all jener, die in gutem Glauben dazu beitragen, unsere Produkte für alle sicherer zu machen.

Die Richtlinie kann von Zeit zu Zeit aktualisiert werden; Datum des Inkrafttretens und Versionsnummer werden dabei entsprechend angepasst. Vor Beginn der Tests bitte die jeweils aktuelle Fassung lesen.

2.1 Einbezogene Systeme

Folgende Ressourcen fallen in den Geltungsbereich dieser Richtlinie:

• BlueRange Smart Building Plattform und die zugehörigen Dienste, die unter von BlueRange betriebenen Domains gehostet werden
• Von BlueRange unter *.bluerange.io betriebene Webanwendungen, Portale und öffentliche APIs
• BlueRange Gateway OS: das Betriebssystem-Image der BlueRange Gateways
• BlueRange Gateway Applikation: die auf den Gateways ausgeführte Software zur Anbindung der Mesh-Netzwerke an die Plattform
• BlueRange Mesh Firmware: die Firmware der BlueRange-fähigen Mesh-Knoten (Sensoren, Aktoren, Beacons, Leuchtenmodule), einschließlich der Bluetooth-Low-Energy-Kommunikation zwischen den Knoten sowie zwischen Knoten, Gateways und Apps
• BlueRange Apps, die in offiziellen App Stores veröffentlicht sind, u. a. die BlueRange Office App und die BlueRange Setup App
• Die BlueRange-Website und zugehörige Webseiten

Tests an Gateways und Mesh-Knoten sind nur an Geräten gestattet, die sich im eigenen Besitz befinden bzw. für die eine ausdrückliche Erlaubnis des Eigentümers vorliegt, und nur in einer eigenen, von produktiven Installationen getrennten Testumgebung.

2.2 Ausgenommene Systeme

Folgende Ziele sind im Rahmen dieser Richtlinie nicht für Tests autorisiert:

• BlueRange-Software und -Hardware, die von unseren Kunden, Partnern oder Dritten betrieben wird, insbesondere in Gebäuden installierte Gateways, Mesh-Netzwerke und Plattform-Instanzen
• Sonstige Systeme, Netzwerke oder Anwendungen unserer Kunden, Partner oder Dritter
• In unsere Produkte eingebundene Drittanbieterdienste (z. B. Identitätsanbieter, Cloud-Infrastruktur, Analysedienste) sowie Hardware und Firmware von Drittherstellern, etwa Leuchten oder Gebäudetechnik, in die BlueRange-Module integriert sind
• Physische Räumlichkeiten und Einrichtungen der BlueRange GmbH

Falls unklar ist, ob ein Ziel in den Geltungsbereich fällt, bitte vor Beginn jeglicher Tests an security@bluerange.io wenden.

3.1 Autorisierte Aktivitäten

Bei Einhaltung dieser Richtlinie sind folgende Aktivitäten ausdrücklich gestattet:

• Auswertung öffentlich zugänglicher Informationen zu unseren Systemen (z. B. DNS-Einträge, SSL-Zertifikate, öffentlich verfügbare Dokumentation und öffentlich verfügbarer Quellcode)
• Tests auf gängige Schwachstellen in Webanwendungen (z. B. Injection-Schwachstellen, Authentifizierungsmängel, Zugriffskontrollprobleme, Sicherheitsfehlkonfigurationen)
• Untersuchung von API-Endpunkten auf Sicherheitslücken
• Analyse von clientseitigem Code, der über unsere Webanwendungen ausgeliefert wird
• Sofern die betreffenden Artefakte von BlueRange stammen und auf legitimem Weg über offizielle Distributionskanäle bzw. mit eigener Hardware bezogen wurden:
  • Analyse von Gateway-OS-Images, Update-Paketen und der Gateway Applikation
  • Analyse der Mesh Firmware, einschließlich Reverse Engineering und Untersuchung der Update-Mechanismen (z. B. DFU)
  • Untersuchung der Funkkommunikation (Bluetooth Low Energy) und der Netzwerkkommunikation eigener Geräte
  • Reverse Engineering einschließlich Dekompilierung der BlueRange Apps

3.2 Voraussetzungen für die Autorisierung

Um im Rahmen dieser Autorisierung zu handeln, ist Folgendes erforderlich:

1. In gutem Glauben handeln: mit dem alleinigen Ziel, Sicherheitslücken zu identifizieren und zu melden
2. Schäden minimieren: Handlungen vermeiden, die die Verfügbarkeit von Systemen, die Datenintegrität, andere Nutzende oder den Gebäudebetrieb beeinträchtigen könnten
3. Funkreichweite beachten: Funkbasierte Tests so durchführen, dass keine fremden Mesh-Netzwerke, Gateways oder Geräte in Reichweite beeinflusst werden
4. Bei Entdeckung abbrechen: Sobald das Vorhandensein einer Schwachstelle bestätigt ist, weitere Tests einstellen und die Erkenntnisse melden; die Auswirkung nicht durch Zugriff auf weitere Daten, Systeme oder Geräte demonstrieren
5. Daten schützen: Nicht auf Daten anderer Nutzender zugreifen und diese nicht kopieren, verändern oder löschen; bei versehentlichem Zugriff auf solche Daten sofort abbrechen, die Daten nicht speichern oder teilen und den Vorfall im Bericht vermerken
6. Vertraulichkeit wahren: Keine Details zu Schwachstellen an Dritte weitergeben, bevor wir angemessen Gelegenheit hatten, das Problem zu beheben, und eine koordinierte Offenlegung vereinbart wurde

3.3 Untersagte Aktivitäten

Folgende Methoden und Verhaltensweisen sind unter keinen Umständen gestattet, auch nicht gegenüber einbezogenen Systemen:

• Jede Form von Social Engineering, Phishing, Vishing, Pretexting oder vergleichbaren Methoden gegenüber Beschäftigten, Kunden oder Nutzenden von BlueRange
• Physisches Eindringen oder Versuche, sich physisch Zugang zu Gebäuden, Räumen oder installierten Geräten zu verschaffen
• Tests an Gateways, Mesh-Netzwerken oder Geräten, die in Kundeninstallationen oder sonstigen fremden Umgebungen betrieben werden, einschließlich funkbasierter Angriffe aus der Nähe
• Denial-of-Service-Angriffe (DoS/DDoS), Störsender (Jamming) oder Tests, die auf eine Beeinträchtigung der Dienstverfügbarkeit abzielen
• Automatisierte Schwachstellenscans in einem Umfang oder einer Häufigkeit, die die Systemleistung beeinträchtigen könnten
• Zugriff auf, Herunterladen oder anderweitiges Abgreifen von Kundendaten, personenbezogenen Daten oder vertraulichen Geschäftsinformationen
• Verändern oder Löschen von Daten in jeglichen Systemen
• Einspielen manipulierter Firmware oder Konfigurationen auf fremde Geräte
• Hochladen von Schadcode, Hintertüren oder Mechanismen für dauerhaften Zugriff
• Versuche, ausgehend von einer entdeckten Schwachstelle auf weitere Systeme, Geräte oder Daten zuzugreifen
• Spam oder unaufgeforderte Massennachrichten
• Weitergabe von Zugangsdaten, Schlüsselmaterial, Schwachstellendetails oder Proof-of-Concept-Code an Dritte
• Öffentliche Offenlegung von Schwachstellen (auch als öffentliches Issue in einem Quellcode-Repository), bevor eine koordinierte Offenlegung vereinbart wurde

4. Rechtliche Position

Gegenüber Sicherheitsforschenden, die diese Richtlinie vollständig einhalten, verpflichtet sich BlueRange:

• Keine zivilrechtlichen Schritte einzuleiten für Aktivitäten, die im Einklang mit dieser Richtlinie durchgeführt wurden
• Keine Strafanzeige zu erstatten für Aktivitäten, die im Einklang mit dieser Richtlinie durchgeführt wurden
• In gutem Glauben zusammenzuarbeiten bei der Bearbeitung gemeldeter Schwachstellen
• Auf Anfrage eine Autorisierungsbestätigung auszustellen, damit Forschende ihren Status vor Beginn der Tests dokumentieren können

Diese Richtlinie stellt eine Autorisierung durch BlueRange als Herstellerin der in Abschnitt 2.1 beschriebenen Produkte und als Betreiberin der dort genannten Systeme dar. Wir haben sie in gutem Glauben erstellt, um Forschende zu schützen, die ebenfalls in gutem Glauben handeln.

Diese Richtlinie kann und wird jedoch keine Immunität vor strafrechtlicher Verfolgung gewährleisten. Sie kann außerdem keine Autorisierung für Systeme oder Geräte erteilen, die Dritten gehören oder von Dritten betrieben werden. Wir empfehlen daher dringend, alle Aktivitäten sorgfältig zu dokumentieren und bei Bedenken vor Beginn der Tests eine schriftliche Autorisierungsbestätigung bei uns einzuholen.

5. Verwendung personenbezogener Daten

Die im Rahmen der Schwachstellenmeldung übermittelten personenbezogenen Daten werden ausschließlich zur Untersuchung und Behebung der Schwachstelle verwendet und unterliegen den datenschutzrechtlichen Bestimmungen der Datenschutz-Grundverordnung (DSGVO) und des Bundesdatenschutzgesetzes (BDSG).

6.1 Meldung einreichen

Schwachstellenberichte bitte per PGP-verschlüsselter E-Mail senden an: security@bluerange.io

Unser öffentlicher PGP-Schlüssel ist unter keys.openpgp.org abrufbar. Der Fingerabdruck lautet: 60D903B0A3FF279A6EDA52AE72A169D9B8DB47E8.

Darüber hinaus pflegen wir eine security.txt.

Schwachstellen in öffentlich verfügbarem Quellcode bitte ebenfalls ausschließlich über diesen Weg melden und nicht als öffentliches Issue oder Pull Request.

6.2 Inhalt des Berichts

Damit wir das Problem rasch nachvollziehen und beheben können, bitten wir um folgende Angaben:

• Beschreibung der Schwachstelle und ihrer möglichen Auswirkungen
• Betroffene Komponente: Plattform, Gateway OS, Gateway Applikation, Mesh Firmware oder App, jeweils mit URL, Versionsnummer, Build bzw. Hardwaremodell, sofern zutreffend
• Testumgebung: verwendete Hardware, Konfiguration und gegebenenfalls Funkumgebung
• Schrittweise Reproduktionsanleitung
• Proof of Concept: Screenshots, Protokolle, Mitschnitte oder Codebeispiele, die die Schwachstelle belegen (ohne echte Nutzerdaten)
• Eigene Einschätzung zu Schweregrad und möglichen Auswirkungen
• Kontaktdaten für Rückfragen (pseudonyme Angaben sind möglich)
• Versehentlich eingesehene sensible Daten: Bei unbeabsichtigtem Zugriff auf personenbezogene oder vertrauliche Daten bitte das Gesehene beschreiben, ohne die Daten selbst aufzuführen

Berichte können auf Deutsch oder Englisch eingereicht werden.

6.3 Was der Bericht nicht enthalten sollte

• Keine tatsächlichen Kundendaten, personenbezogenen Daten, Zugangsdaten oder Schlüssel aus fremden Installationen beifügen
• Auf schadhafte Payloads, funktionsfähigen Exploit-Code oder manipulierte Firmware-Images verzichten, die bei unsachgemäßer Handhabung Schaden verursachen könnten

7. Reaktion und Offenlegung

Nach Eingang des Berichts bestätigen wir den Empfang innerhalb von fünf Werktagen und beginnen mit der Validierung und Einstufung der gemeldeten Schwachstelle.

Für die Behebung wird angemessene Zeit benötigt: Wir bitten um eine Frist von mindestens 90 Tagen ab der Erstmeldung vor einer öffentlichen Offenlegung. Dies gibt uns Gelegenheit, das Problem zu validieren und zu beheben, die Korrektur zu verifizieren und bei allen Kunden auszurollen. Da Updates für Gateways und Mesh-Knoten in laufenden Gebäudeinstallationen eingespielt werden müssen, kann in Einzelfällen eine längere Frist erforderlich sein; diese stimmen wir mit der meldenden Person ab.

Bei Bedarf setzen wir uns über die etablierten Kanäle mit der meldenden Person in Verbindung, um zusätzliche Informationen einzuholen. Über den Fortschritt der Untersuchung und Behebung wird informiert.

Wird die Schwachstelle bestätigt, vergeben wir eine interne BRVD-Kennnummer, die in der weiteren Kommunikation und in späteren Sicherheitshinweisen als Referenz dient.

Nach Behebung der Schwachstelle werden Zeitpunkt und Details der Offenlegung gemeinsam mit der meldenden Person abgestimmt.

8. Anerkennung und Vergütung

Wir betreiben derzeit kein monetäres Bug-Bounty-Programm. Die Einführung eines solchen Programms ist für die Zukunft nicht ausgeschlossen; diese Richtlinie wird in diesem Fall entsprechend aktualisiert.

Forschende, die im Einklang mit dieser Richtlinie eine bestätigte Schwachstelle melden, haben derzeit Anspruch auf:

• Öffentliche Anerkennung auf unserer Seite für Sicherheitshinweise (mit Zustimmung der meldenden Person)
• Namentliche Erwähnung in Sicherheitshinweisen zur gemeldeten Schwachstelle (mit Zustimmung der meldenden Person)
• Ein Dankesschreiben, das sich für berufliche Portfolios eignet (auf Anfrage)

Anhang: Beispiele für Schwachstellen

Die folgenden Beispiele sollen veranschaulichen, welche Arten von Schwachstellen in den Geltungsbereich dieser Richtlinie fallen und welche nicht.

Qualifizierende Schwachstellen

• Remote Code Execution, auch auf Gateways oder Mesh-Knoten
• SQL-Injection und andere Injection-Schwachstellen
• Fehler in der Authentifizierung oder Sitzungsverwaltung
• Umgehung von Autorisierungsmechanismen und Rechteausweitung
• Cross-Site Scripting (XSS) mit nachgewiesener Auswirkung
• Cross-Site Request Forgery (CSRF) mit nachgewiesener Auswirkung
• Offenlegung sensibler Daten
• Sicherheitsfehlkonfigurationen mit erkennbarer Auswirkung
• Server-Side Request Forgery (SSRF)
• Unsichere direkte Objektreferenzen
• Umgehung der Signaturprüfung oder Integritätsprüfung bei Firmware- und Gateway-Updates
• Schwächen in Verschlüsselung, Authentifizierung oder Schlüsselverwaltung der Mesh-Kommunikation, z. B. unberechtigtes Beitreten zu einem Mesh-Netzwerk, Replay-Angriffe oder das unberechtigte Auslösen von Steuerbefehlen per Funk
• Auslesbares Schlüsselmaterial, das über das einzelne Gerät hinaus nutzbar ist (z. B. für andere Geräte, Netzwerke oder Kunden)

Nicht qualifizierende Meldungen

Folgende Punkte gelten in der Regel nicht als qualifizierende Schwachstellen:

• Schwachstellen, die physischen Zugriff auf das Gerät eines Nutzenden erfordern, sofern sie keine Auswirkungen über dieses einzelne Gerät hinaus haben
• Schwachstellen in Anwendungen, Diensten, Hardware oder Firmware von Drittanbietern
• Social-Engineering-Angriffe
• Denial-of-Service-Schwachstellen sowie Störungen der Funkkommunikation durch Jamming (bitte dennoch melden; aufgrund der Testbeschränkungen sind sie im Rahmen dieser Richtlinie jedoch nicht anerkennungsfähig)
• Durch automatisierte Scanner identifizierte Probleme ohne nachgewiesene Ausnutzbarkeit
• Fehlende Sicherheitsheader ohne nachgewiesene Auswirkung
• Clickjacking ohne nachgewiesene sicherheitsrelevante Aktion
• Self-XSS (Skriptausführung nur in der eigenen Sitzung möglich)
• CSRF bei nicht sicherheitsrelevanter Funktionalität
• Offenlegung nicht sensibler Informationen, einschließlich bestimmungsgemäß öffentlich ausgesendeter Bluetooth-Advertising-Daten (z. B. Beacon-Kennungen)
• Offenlegung von Softwareversionen ohne zugehörige Schwachstelle
• Theoretische Schwachstellen ohne Proof of Concept
• Bereits bekannte oder zuvor gemeldete Schwachstellen