security.txt - So melden Sicherheitsforschende Schwachstellen sicher

Die Anzahl an Sicherheitsschwachstellen nimmt seit Jahren kontinuierlich zu und kaum ein Tag vergeht, an dem nicht eine neue, kritische Schwachstelle in den Medien präsent ist. Nicht nur die Anzahl, sondern auch der Umgang mit der eigentlichen Information hat sich in den letzten 30 Jahren grundlegend verändert.

Mit Aufkommen der ersten Strukturen und Security-Communities in den Neunzigerjahren wurden erstmals öffentliche Plattformen zur Diskussion von Informationssicherheit geschaffen. Sicherheitsforschende, die eine Schwachstelle gefunden hatten, meldeten diese dort, um Anerkennung in der Community zu finden. Im besten Fall waren die Betroffenen, egal ob Hersteller oder Organisationen, ebenfalls in diesen Communities präsent und bekamen so die Möglichkeit, diese zu beheben.

Bereits Anfang der 2010er Jahre wurden Informationen zu Schwachstellen zunehmend zu einem gefragten Gut, nicht nur für die Betroffenen, sondern auch für Kriminelle, sogenannte Threat Actors. Diese machten sich Schwachstellen zunutze, um die Betroffenen, deren Kunden oder beides anzugreifen. Gegipfelt ist dies mit dem Aufkommen von Ransomware: Die Daten der Opfer werden verschlüsselt, um danach den Schlüssel gegen Lösegeld zu erpressen.

Umso wichtiger ist es, dass Sicherheitsforschende, die eine Schwachstelle entdeckt haben und sie melden wollen, Hinweise zur Erreichbarkeit der Betroffenen bekommen. An dieser Stelle sei erwähnt, dass die Schwachstelle zum Zeitpunkt der Entdeckung bereits vorhanden ist. Der Sicherheitsforschende war nur die (hoffentlich) erste Person, die sie entdeckt hat.

Herausforderungen beim Melden einer Schwachstelle

Sollte jemand eine Schwachstelle in einer quelloffenen Software (Englisch: Free and Open Source Software (FOSS)) gefunden haben, ist die Meldung meist einfacher. Ein Großteil der quelloffenen Software ist auf öffentlichen Plattformen wie beispielsweise GitHub gehostet und verfügt über dokumentierte Kommunikationskanäle wie Mailinglisten, Foren oder Chat-Plattformen. Über diesen Weg kann eine Schwachstelle, größtenteils sogar vertraulich, gemeldet werden und so der Behebungsprozess angestoßen werden.

Bei proprietärer und kommerzieller Software ist der Meldeweg nicht immer so einfach zu finden. Während die Großen der Branche wie Microsoft, Google und Co gut dokumentierte Meldewege haben, sieht es bei kleineren Herstellern schon anders aus. Noch größer wird die Herausforderung, wenn es sich gar nicht um eine klassische Software handelt, sondern um eine Lücke in einer Plattform oder einem Infrastruktursystem.

Konsequenzen eines fehlenden Meldeweges

Sollte ein Sicherheitsforschender keinen Meldeweg finden und sein Bestreben einstellen, bleibt das eigentliche Problem bestehen und die Information bleibt verborgen. Im besten Fall findet niemand weiteres die Schwachstelle. Im schlechtesten Fall nutzt sie jemand mit krimineller Energie aus – heute sogar gesteuert durch künstliche Intelligenz (KI) – und erpresst die Betroffenen oder stiehlt gar deren Daten.

Alternativ kann der Sicherheitsforschende auch den Weg der vollumfänglichen Meldung wählen und alle Informationen zur Schwachstelle und möglicherweise auch deren Ausnutzung direkt im Internet oder auf sozialen Medien veröffentlichen (Englisch: Full Disclosure). Dies setzt die Betroffenen nun unter Zugzwang, die Lücke schnellstmöglich zu beheben, um zu verhindern, dass diese bei ihnen oder ihren Kunden ausgenutzt wird. Weitere Informationen zu den unterschiedlichen Meldewegen und wie aramido selbst mit gefundenen Schwachstellen umgeht, sind in unserem Blog beschrieben.

security.txt als Retter in der Not

Um den beschriebenen Konsequenzen einfach zu begegnen, kann eine sogenannte security.txt abgelegt werden. Dies ist eine kleine, aber feine Methode, um Sicherheitsforschenden den entscheidenden Hinweis zu Meldewegen zu geben. Wie der Name vermuten lässt, handelt es sich hierbei tatsächlich um eine einfache Textdatei. Diese wird in einem standardisierten Pfad auf der eigenen Website im Unterverzeichnis /.well-known/ abgelegt, also final unter /.well-known/security.txt. aramidos security.txt liegt beispielsweise hier: https://aramido.de/.well-known/security.txt.

Beispiel einer security.txt-Datei

# If you would like to report a security issue
# you may report it to us via PGP or S/MIME
# encrypted mail or via our contact form
Contact: mailto:security@aramido.de
Contact: https://aramido.de/kontakt
Contact: tel:+497214519910
Encryption: https://aramido.de/pgp/aramido.security.asc
Encryption: openpgp4fpr:960EC6FEAAD4858CF54C5E942A492C40E17B729F
Encryption: https://aramido.de/cert/aramido.security.pem
Preferred-Languages: de, en
Hiring: https://aramido.de/jobs
Canonical: https://aramido.de/.well-known/security.txt
Expires: 2027-03-25T00:00:00z

Das wichtigste Element der Datei ist die Angabe der Kontaktmöglichkeiten, die ein Sicherheitsforschender zum Melden einer Schwachstelle nutzen kann. Dabei kann es sich im einfachsten Fall um eine E-Mail-Adresse handeln, aber auch ein Webformular oder eine Telefonnummer sind möglich. Um sicherzustellen, dass die Kontaktinformation aktuell ist, wird ein Gültigkeitsdatum angegeben, meist ein Jahr nach der Erstellung. In diesem Intervall wird die Datei geprüft und das Datum wieder in die Zukunft gesetzt.

Formal ist die security.txt durch das RFC 9116 der Internet Engineering Task Force standardisiert. Die im letzten Abschnitt erwähnten Informationen sind dabei verpflichtend; folgende Angaben können optional ergänzt werden:

• Informationen, wie Meldungen verschlüsselt abgegeben werden können
• Bevorzugte Sprache der Meldung
• Weitere Links zu Richtlinien für Sicherheitsmeldungen, Job-Portalen und öffentlichen Würdigungen

Sollte immer eine security.txt veröffentlicht werden?

Ja. Sobald eine Domain in Benutzung ist, also die damit verbundenen Dienste genutzt werden – egal ob Website, E-Mail oder etwas anderes – raten wir aus Expertensicht dazu, eine security.txt zu erstellen und zu veröffentlichen. Wenn niemand etwas meldet, umso besser. Der umgekehrte Fall ist aus den oben beschriebenen Gründen viel schlechter.