Skip to content

security.txt

Kennt ihr noch die Datei robots.txt, die auf verschiedenen Webseiten hinterlegt sind? Dahinter stand der Robots Exclusion Standard und die verschiedenen Bots sollen zuerst die Seite ausweren, bevor sie eine Webpräsenz indexieren. Daneben entstand auch die Idee für eine humans.txt und mit dem “Erschaffen” des .well-known-Verzeichnisses auf dem Webserver gibt es eine ganze Reihe Dateiformate zur Information oder für andere Zwecke.

Seit April 2022 gibt es nun den RFC 9116 für die Datei security.txt. Diese soll anderen helfen, Sicherheitslücken an die richtige Stelle zu melden. Denn oftmals steht das Problem, dass eine Schwachstelle gefunden wurde und es vielleicht unklar ist, wohin diese zu melden ist.

Mail wäre natürlich eine mögliche Wahl. Im besten Fall existiert sogar eine E-Mail-Adresse namens security@. Aber sehr häufig ist dies nicht der Fall. Mails an info@ oder ähnliche Adressen landen eher im Nirwana oder werden mit Standardtextbausteinen beantwortet. Daher ist ein gezielter, standardisierter Weg gut.

Der RFC 9116 definiert hierfür eben die Datei security.txt, die im Unterordner .well-known einer Webpräsenz liegen muss. Die Datei selbst muss über HTTPS erreichbar sein. Ein korrekter Pfad wäre also https://example.com/.well-known/security.txt.

Doch was darf da drin stehen? Naheliegend sind Kontaktinformationen. :-) Spezieller Informationen, an die man Informationen zu Schwachstellen melden kann. Hierfür ist der Eintrag Contact: gedacht. Dieser muss in der Datei enthalten sein und sollte die Kontaktmöglichkeiten in absteigender Reihenfolge enthalten. Daneben benötigt die Datei zwingend ein Ablaufdatum. Eine Minimalversion der Datei kann also so aussehen:

Contact: mailto:security@example.com
Expires: 2023-05-01T12:13:24+02:00

Weiterhin könnt ihr in der Datei Informationen zu einer Policy hinterlegen, welche Sprachen ihr sprecht, ob ihr Leute einstellt, wer in der Vergangenheit Lücken meldete und einen Verweis zu einem Schlüssel machen. Eine erweiterte Version der Datei sähe also so aus:

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

Hier sind mehrere Kontaktmöglichkeiten genannt. Es gibt eine Policy. Die Leute sprechen Deutsch und Englisch und ihr bekommt Infos über andere, die etwas gemeldet haben. Am Schluss findet sich auch ein PGP-Schlüssel. Optimalweise würde der über Web Key Discovery bereit gestellt. Aber das ist ein Thema für einen anderen Beitrag. ;-)

Schließlich könnt ihr den Eintrag auch noch mittels OpenPGP signieren. Dann sähe meine obige Datei so aus:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.19

[Viele Zeichen, die gpg auswerten kann]
-----END PGP SIGNATURE-----

Wenn ihr also eine Schwachstelle gefunden habt, dann lohnt es sich nach der Datei zu schauen und die dort genannten Kontakte anzusprechen. Ich habe mal ein wenig gegraben. Bei den großen, bekannten Seiten, wie Google, Facebook, Twitter, GitHub usw., fand ich jeweils eine solche Datei. Seiten aus dem Microsoft-Universum wie auch viele chinesische Seiten haben keinerlei solche Informationen.

Ansonsten ist das Bild recht gemischt. Während beispielsweise Facebook und WhatsApp eine security.txt anbieten, hat Instagram keine, obwohl alle zum selben Konzern gehören.

Unter andere namhaften Seiten fand ich nichts bei

  • Reddit
  • Wikipedia
  • Zoom
  • Netflix
  • Stackoverflow
  • Apple
  • und weiteren

Hier ist also noch ein wenig Arbeit zu tun. Wenn die Datei auch bei euch oder eurem Arbeigeber fehlt, sprecht die doch an und bittet die, diese Informationen bereitzustellen (und natürlich bei Bedarf zu aktualisieren).

Siehe auch:

Update: Ich hatte übersehen, dass das Expires:-Feld auch ein Pflichtfeld ist und habe die obige Beschreibung ergänzt. Vielen Dank an Jürgen für den Hinweis!

Einbindung von Flickr doch konform zur DS-GVO

GDPR
GDPR & ePrivacy Regulations von Dennis van der Hejden. Original bei Flickr

Vor kurzem stellte ich mir hier im Blog die Frage, ob man noch Bilder des Dienstes Flickr einbinden kann. Nach meiner Prüfung kam ich zu dem Schluss, dass dies nicht mehr der Fall ist und entfernte die Bilder aus meinem Blog.

Heute hielt ich einen Workshop, der u.a. auch die Datenschutz-Grundverordnung zum Thema hatte. Dort fragte mich ein Teilnehmer, ob denn das Land Thüringen eine korrekte Datenschutzerklärung (DSE) hat. Der folgende Abschnitt brachte mich dann doch ins Staunen:

Flickr

Innerhalb unseres Onlineangebotes können Funktionen und Inhalte des Dienstes Flickr eingebunden sein. Flickr ist ein Foto- und Bilder-Dienst des amerikanischen Unternehmens SmugMug Inc. (67 E. Evelyn Ave, Suite 200
Mountain View, California, U.S.)Wenn Sie selber Flickr aktiv nutzen und ein Bild oder Video veröffentlichen, können wir ihn ebenfalls sehen, wenn Sie ihn jedermann zugänglich gemacht haben oder wenn wir Ihnen über Flickr folgen. Ebenfalls können wir Ihre Angaben auf Flickr sehen, wenn thueringen.de Ihrem Profil folgt. Einzelheiten zur Verarbeitung der Daten bei Flickr und den Sichtbarkeitseinstellungen entnehmen Sie bitte den Datenschutzbedingungen von Flickr bzw. Oath (ehemals Yahoo): policies.oath.com/ie/de/oath/privacy/index.html  

Das heißt, das Land Thüringen ist der Meinung, rechtmäßig Flickr-Bilder einbinden zu können. Wie kann das sein?

Weder Flickr noch Yahoo! noch eine der anderen Firmen steht bisher auf der Privacy-Shield-Liste. Und die Datenschutzbedingungen von Flickr gaben doch bisher auch nichts her. Aber: Unter anderen ist das Datenschutzcenter von Oath mit verlinkt. Dort steht gleich am Anfang:

Für Produkte oder Dienste von Oath, auf die ohne Anmeldung bei einem Account zugegriffen wird, gilt diese Datenschutzerklärung für diese Produkte und Dienste ab 25. Mai 2018.  

Flickr gehört mit zu Oath. Also gelten diese Bedingungen auch für Flickr. In der DSE steht drin, dass die Oath (EMEA) Limited in Dublin diese Dienste bereitstellt und damit wohl Verantwortlicher im Sinne der DS-GVO ist. Also werden die Daten von einem Unternehmen mit Sitz in der EU verarbeitet und die DS-GVO möchte ja den freien Verkehr personenbezogener Daten fördern (oder zumindest nicht einschränken).

Weiterhin erklärt Oath, dass sie die Standardvertragsklauseln der EU-Kommission verwenden bzw. nur Daten mit Unternehmen austauschen, die nach Privacy Shield zertifiziert sind.

Insgesamt scheint die Datenschutzerklärung den Anforderungen der Art. 13 und 14 DS-GVO zu entsprechen. Und auch inhaltlich ist es jetzt so, dass man wohl doch bedenkenlos Bilder von Flickr in seinem Blog einbinden kann.

Neues TLS-Zertifikat

Der Webserver hat seit heute ein neues Zertifikat. Ich bin jetzt von CAcert auf Let’s Encrypt umgestiegen. Bei den Übernauten ist die Einrichtung sehr einfach. Nachdem die Befehle uberspace-letsencrypt, letsencrypt certonly und uberspace-prepare-certificate eingegeben wurden, war alles fertig.

Wenn ihr das Zertifikat prüfen wollt, hier ist der SHA-256-Hash:

B8:8A:B3:34:0E:5F:97:6A:88:F0:A7:E7:91:73:F4:50:42:29:0A:73:07:54:68:2D:96:EB:36:29:BB:FC:58:A8

Lenovo-Laptops mit SuperFish-AdWare

Die aktuellen Nachrichten über Wanzen in Festplatten oder geknackte SIM-Karten hören sich auf der einen Seite sehr bedrohlich an, auf der anderen Seite werden viele dies abtun, als Verschwörungstheorie oder »Betrifft-mich-nicht«. Doch dann war von Barbies zu lesen, die alles mithören und ins Internet übertragen und Samsung warnt, vor seinen Fernsehgeräten nichts Privates zu erzählen. Im letzteren Fall werden die Daten im Klartext übertragen und damit kann jeder mithören, was vor dem gerät erzählt wird. Der große Lauschangriff mal ganz anders.

Ansicht des Zertifikats im Zertifikatsmanager
Detailansicht des Zertifikats von Chris Palmer (@fugueish)
Lenovo reiht sich nun ebenfalls in die Liste der Hersteller ein, die offensichtlich wenig auf die Privatsphäre der Käufer geben. Verschiedene Medien (The Next Web, Forbes, Heise, ZEIT Online, Golem u.a.) meldeten, dass Lenovo auf Laptops die Software SuperFish Visual Discovery vorinstalliert. Dies ist Adware, d. h. sie blendet Werbung auf Webseiten ein. Dies wird dadurch bewerkstelligt, indem ein Schnippsel JavaScript geladen wird und die unerwünschten Inhalte überträgt. Doch damit gaben sich die Hersteller der Software nicht zufrieden. In die vorab installierten und damit vertrauenswürdigen Zertifikate wurde auch ein Zertifikat eingefügt. Immer wenn nun eine verschlüsselte, sichere Webseite besucht wird, kommt das Zertifikat nicht von der ursprünglichen Webseite, sondern von der SuperFish-Software. Damit kann die Software den verschlüsselten Datenverkehr mitlesen und diese Daten auch manipulieren. Dieser so genannte Man-in-the-Middle-Angriff ist eine klassische Angriffstechnologie und dient in der Regel nicht guten Zwecken.
Code zur Installation des Zertifikats
Code, der versucht, das Zertifikat in verschiedenen Browsern zu installieren (via @supersat)

Die EFF beobachtet seit längerem den Status von Zertifikaten mit dem SSL Observatory und meldete, dass sie in dem Datensatz 44.000 dieser SuperFish-Mitm-Zertifikate fanden. Das Bild links zeigt ein wenig Quellcode. Demnach versucht die Software ihr Zertifikat in verschiedene Browser zu importieren. Das erklärt auch, warum u.a. auch Firefox betroffen ist. Denn im Gegensatz zu Google Chrome nutzt dieser nicht die Zertifikatsverwaltung von Windows.

Robert Graham hat neben anderen Forschern das Zertifikat aus der Software extrahiert und in kurzer Zeit das Passwort ermittelt (Das Passwort »komodia« liefert dann auch den Hinweis auf den Komodia SSL Digestor). Wie er schreibt, benötigte er keine Spezialkenntnisse. Ein geschickter Angreifer kann dies ebenfalls tun. Damit lässt sich dann auch für Dritte sämtliche verschlüsselte Kommunikation brechen. Aber der Superfish Software scheint auch der Status fremder Zertifikate egal zu sein. In einer Diskussion auf Hacker News berichtete jemand, dass die Software beliebige (auch ungültige) fremde Zertifikate akzeptiert. Ähnliches geht auch mit fakehost.lenovo.com oder CanIBesuperFished.com. Insgesamt reißt die Software damit ein riesengroßes Loch in die Sicherheit der Rechner. Mich erinnerte das spontan an den Fall von Sony, die auch Malware auf die Rechner installieren.

Was lässt sich nun gegen die Infektion tun? Die Software selbst ist in der Liste der installierten Programme von Windows zu finden und kann dort einfach deinstalliert werden. Allerdings bleiben eine Reihe von Einträgen in der Registry und das Zertifikat noch erhalten. Hier ist dann Handarbeit angesagt. Dazu müsst ihr den certmgr von Windows öffnen und das Zertifikat entfernen. Bei der EFF gibt es eine Schritt-für-Schritt-Anleitung, wie das zu tun ist.

Lenovo hat mittlerweile reagiert und einerseits ein schönes Statement bei Twitter abgegeben:

Daneben gibt es eine Veröffentlichung, die den Vorfall klar als Vulnerability mit hohem Impact benennt. Die Veröffentlichung hat auch eine Liste der Produkte, die betroffen sind.

Wie funktioniert eigentlich Heartbleed

Lest ihr regelmäßig Bugreports oder Meldungen über Schwachstellen bei SSL/TLS? Wie fühlt ihr euch so? Zur Erinnerung:

SSL added and removed here!
Ausschnitt aus einer Folie aus dem MUSCULAR-Programm der NSA

Das heißt, drei Monate in Folge gab es schwere Sicherheitslücken in Software zur Verschlüsselung. Ganz unwillkürlich fühlt man sich an die Folien aus dem NSA-Programm MUSCULAR erinnert.

Die letztgenannte Schwachstelle ist vermutlich die bislang schwerste. Denn damit ist es möglich, den Arbeitsspeicher eines Computers auszulesen. Dies funktioniert sowohl auf der Seite des Servers wie auch beim Clientprogramm. Dazu ist es notwendig, dass das Programm OpenSSL verwendet und eine Erweiterung von SSL namens Heartbeat aktiviert hat. Dies ist beispielsweise bei Android in der Version 4.1.1 der Fall. Mozilla Firefox hingegen nutzt die NSS-Bibliothek und ist nicht betroffen. Die Webserver nutzen hingegen recht oft die OpenSSL-Bibliothek und sind damit betroffen, falls die Version 1.0.1 bis 1.0.1f von OpenSSL verwendet wird. Sollte jemand von euch die Software nutzen, so upgraded auf mindestens 1.0.1g oder deaktiviert Heartbeat in OpenSSL. Gerade letzteres kann man aus meiner Sicht problemlos tun. Denn bisher fand ich keinen sinnvollen Anwendungsfall für Heartbeat.

Doch wie funktioniert diese Lücke eigentlich? Heartbeat (RFC 6520) ist eine Erweiterung für TLS. Ein Teilnehmer einer Verbindung sendet beliebige Daten an den Empfänger. Dieser antwortet mit einer Kopie dieser Daten und zeigt somit, dass die Verbindung noch steht und alles in Ordnung ist. Das Problem dabei ist, dass in einer Anfrage zwei Längenfelder vorhanden sind. Ein Angreifer sendet einfach ein Byte Daten und behauptet, er hätte 64 kB gesendet. OpenSSL liest nun die 64 kB aus dem eigenen Puffer und sendet die Daten zurück an den Angreifer. Der Angreifer kann den Angriff immer und immer wieder starten und erhält so eventuell immer wieder ein neues Stück Arbeitsspeicher (siehe Kommentar von Florian Diesch). Bruce Schneier hat mit seinen Worten vollkommen recht:

Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.
https://www.schneier.com/blog/archives/2014/04/heartbleed.html

Ich hatte in meinem 30C3-Vortrag schon ein OpenSSL-Beispiel reingenommen. Das sollte zeigen, wie kompliziert es sein kann, mit der Software sicheren Code zu schreiben. Auch andere sind, über die Codequalität gestolpert. Daher sind Leute gefragt, die einen detaillierten Blick auf OpenSSL werfen und die Software verbessern. Dazu zählt auch die bessere Lesbarkeit des Codes oder gute Dokumentation.

Wenn ihr wissen wollt, ob ihr betroffen seit, schaut lokal auf die OpenSSL-Version, nutzt die Zeile openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep ‘server extension “heartbeat” (id=15)’ || echo safe oder verwendet den Testservice von Lutz Donnerhacke oder Filippo Valsorda.

Weiterlesen:

Passwort und Nutzername im Dump der Daten von Yahoo! Mail

Firefox 27 mit TLS 1.2

Jetzt ist der Zeitpunkt gekommen, an dem ich meine Anleitung zu sicheren SSL-Einstellungen löschen kann. Der aktuelle Firefox ist in der Version 27 erschienen. Wie angekündigt, unterstützt der Browser nun standardmäßig TLS 1.1 und 1.2. Damit werden die TLS-Einstellungen über about:config hinfällig. Die Seite How’s my SSL zeigt den Firefox mit Standardeinstellungen als Probably OK an. Sogar Seiten mit AES im GCM-Modus werden korrekt verschlüsselt.

Neues SSL-Zertifikat für kubieziel.de

In den letzten Beiträgen thematisierte ich die Verschlüsselung von Webseiten. Meine eigene Webseite läuft seit längerer Zeit über SSL/TLS. Das alte Zertifikat lief Ende Januar 2014 aus. Daher war es Zeit für eine Erneuerung. Das neue Zertifikat stammt von CACert. Vermutlich erzeugt das bei vielen eine Warnung im Browser. Daher solltet ihr unbedingt das Root-Zertifikat von CACert importieren. Dann funktionieren auch diese Seiten im Browser.

Mit dem neuen Zertifikat kommt ein neuer Fingerprint: 80:5B:82:22:9C:62:11:69:2E:92:69:9D:60:D1:DD:D3:C3:8C:D1:1A

Durch das fehlende Root-Zertifikat im Browser bewertet SSLLabs die Seite nur noch mit einem F. Bliebe der Fakt unberücksichtigt, würde die Webseite wieder ein A bekommen. Continue reading "Neues SSL-Zertifikat für kubieziel.de"

tweetbackcheckcronjob