Das Entdecken von neuen, unbekannten Schwachstellen macht Spaß, keine Frage. Eher unspaßig ist aber, was man dann als guter Pentester Mensch mit den gewonnenen Informationen anstellt. In diesem Blogpost beleuchte ich Probleme in der Kommunikation zwischen Pentester und Softwarehersteller und möchte auch ein paar Tipps an die Hand geben – für beide Seiten.
Im Rahmen unserer Labdays oder eines Pentest-Projekts kommt es schon mal häufiger vor, dass wir auf bis dato unbekannte Schwächen treffen. Die möchten wir dann gerne, sofern es auch der Kunde erlaubt, an die Hersteller melden und später dafür im Gegenzug Lobpreis und Ehr eine Veröffentlichung machen, um unsere Expertise zu demonstrieren.
Wir haben im Melden und Veröffentlichen etwas Übung und uns auch selbst eine Richtlinie zur verantwortungsvollen Veröffentlichung auferlegt:
Wir möchten keine Schwächen veröffentlichen, für die es keinen Patch gibt*. Und wenn es einen Patch gibt, dann sollen Admins Zeit zum Einspielen haben.
*Ausnahme: der Hersteller/Entwickler erkennt das Problem nicht an oder möchte es nicht beheben.
Die Kontaktaufnahme
Wenn erst mal eine Schwäche gefunden ist, dann möchte man sie auch vertraulich an die richtige Stelle melden. Folgende Fragen gilt es daher zu klären:
- An wen wenden?
- Wie macht man der-/demjenigen am anderen Ende klar, dass man nichts verkaufen und nur Gutes tun mag?
- Wie die Informationen sicher (verschlüsselt) von mir zum Empfänger bringen?
Viele Projekte/Hersteller/Entwickler haben dafür kein eigenes Kontaktformular oder keine eigene Kontaktadresse und kein öffentliches Schlüsselmaterial.
Manch eine/r möchte am liebsten aufgeben, weil es sehr mühsam sein kann, sein Problem immer und immer wieder zu schildern, bis man an der richtigen Stelle ist und sich so bis zum richtigen Kontakt durchzufragen. Das ist vielleicht der Ursprung von 0-days.
Der Wissenstransfer
Hat man den richtigen Ansprechpartner gefunden, so gilt es, diesem alle Informationen zur Verfügung zu stellen. Hier packen wir meist alle Protokolle oder Handlungsanweisungen in Form von neutralen Textdateien zusammen.
Beim Transfer sprechen wir zwar Klartext 🙂 bei der Übertragung wählen wir jedoch nie Klartext-Protokolle, sondern möglichst welche mit Ende-zu-Ende-Verschlüsselung. Der Austausch der Dateien kann dabei auf folgende Arten geschehen:
- per PGP- oder S/MIME verschlüsselte E-Mail*
- per (secuvera) Transferplattform
- per verschlüsseltem ZIP-Archiv (AES) via unverschlüsselter E-Mail**
* Nicht jede/r Gegenüber hat das im Einsatz bzw. verfügt über entsprechende Zertifikate.
** Der Austausch des Archivkennworts muss dabei über einen anderen Kanal (z. B. Telefon) erfolgen
Die Absicht zur Veröffentlichung
Niemand hat die Absicht, eine Mauer zu errichten!
Bei anderen Pentestern ist es schon vorgekommen, dass beim Anklang des Begriffs „Responsible Disclosure“ oder „Veröffentlichung“ durch das Gegenüber nach kurzer Verschnaufpause oder längerer Analysephase was von „Rechtsabteilung“ und „Verschwiegenheitsverpflichtung“ genannt wird. Kein feiner Zug in meinen Augen. Kam bei mir zum Glück auch noch nicht vor.
Liebe Hersteller, wir Pentester wollen doch damit keinen Streit vom Zaun brechen und auch keine vorschnelle Information öffentlich machen. Denn damit riskiert man ja schließlich, dass Nutzer der verwundbaren Software plötzlich mit heruntergelassenen Hosen nicht behobenen Schwachstellen dastehen. Wir wollen lediglich wenn Gras über die Sache gewachsen ist nach einer beiderseits als angemessen bewerteten Zeit über unseren Fund erzählen. Schließlich hat man sich die Mühe gemacht und Zeit investiert und Interessenten fragen gar in Angebotssituationen nach Veröffentlichungen von Schwachstellen bzw. Beispielen.
Den Pentester einbinden
Hat der Pentester ein Problem gemeldet, ist es nur fair, ihn auch über den weiteren Verlauf bis hin zur Behebung in Kenntnis zu setzen. Denn danach richtet sich ja schließlich die Zeitachse der Veröffentlichung.
Nicht selten kommt es vor, dass vermeintlich selbst entworfene Behebungen das Problem verschlimmbessern, weil das Problem nicht richtig verstanden wurde. Warum dann nicht jemanden Fragen, der sich vielleicht etwas besser damit auskennt? Man kann daher gerne auch die Chance wahr nehmen den Pentester um Rat zu fragen und in Ihn dadurch gleichzeitig in den Prozess einbinden.
Man muss dazu übrigens kein Projekt mit dem Pentster ins Leben rufen und dessen Leistungen einkaufen. Das wäre ja auch irgendwie unlauter, wenn der Pentester dadurch zu einem Auftrag gelangen würde.* Solange es sich um überschaubaren Zeitaufwand von wenigen Minuten für den Pentester handelt, ist dieser sicher gerne bereit, sich zu beteiligen.
* Im Umkehrschluss kann es vielleicht doch Sinn machen, zu einem späteren Zeitpunkt die betreffende Software/Komponente durch den meldenden Pentester im Rahmen eines Penetrationstestprojekts prüfen zu lassen. Denn schließlich ist ihr/ihm der Untersuchungsgegenstand bereits bekannt und es könnten sich dadurch Synergieeffekte ergeben
Den Bogen nicht überspannen
Man wartet nicht gerade auf Probleme, um diese zu lösen. Daher ist es weit verbreitet, solche auftretenden Sicherheitsprobleme auf die lange Bank zu schieben.
Die Ausreden Erklärungen, die manch ein Hersteller ins Feld führt, können mannigfaltig sein:
- Kunden möchten nur noch zwei Releases im Jahr erhalten, da das Einspielen der Patches Downtime bedeutet und Manpower bindet (
oh RLY?!) - Ach und der Releaseplan ist fest und das Problem muss hinten anstehen (
und das in Zeiten agiler Entwicklung🙂 )
Been there, done that. Sicherheitsprobleme sollten ernst genommen und außer der Reihe so schnell es geht (aber sorgfältig) behoben werden.
Pentester sind nicht blöd z. T. auch Entwickler oder haben langjährige Erfahrung, wie lange es in etwa brauchen kann, um eine Schwachstelle zu beheben. Der Zeitplan bis zum Disclosure ist nie willkürlich gewählt. Und er kann mit triftigen Gründen sogar verlängert werden. Wo wir wieder beim Stichwort „den Pentester einbinden“ wären.
Die Nutzer informieren
Aufgabe des Herstellers ist es, zu gegebener Zeit die betroffenen über das Problem zu unterrichten und die Behebung in Aussicht zu stellen. Klar ist das kein Spaß, einen Fehler zuzugeben, aber solange Software von Menschen entwickelt wird, so lange kann sie nunmal Fehler haben. Schweigen macht es nur noch schlimmer. Je nach Art der Schwachstelle besteht vielleicht sogar eine Pflicht zum Informieren von (Aufsichts)behörden.
Danke sagen
Man darf sich gerne beim Pentester (und dieser beim Hersteller!) bedanken, nachdem man ein Problem bzw. dessen Meldung und Problembehebung überstanden hat. Gerne auch öffentlich, sofern beide zustimmen.
Es dem Pentester leichter machen
Das Problem scheinen viele zu haben, die sich mit Bug-Hunting und Schwachstellensuche befassen.
Wie also das Melden von Schwachstellen vereinfachen oder in geordnete Bahnen lenken? Gibts da nicht was von Ratiopharm?!
Dabei bin ich auf ein Projekt gestoßen, das dazu einen Vorschlag in Form eines RFCs ( RFC5785 ) macht.
Die Idee ist standardmäßig eine Textdatei, in der die Angaben zum Melden von Sicherheitsproblemen einer Webseite / eines Produkts eines Herstellers an einem standardisierten Ort ( z. B. https://example.com/product/.well_known/security.txt ) zu hinterlegen.
Darin sind dann Kontaktinformationen, Schlüsselmaterial, Richtlinien und Danksagungen enthalten. Im RFC wird folgendes Beispiel genannt:
# Our security address
Contact: mailto:security@example.com
# Our PGP key
Encryption: https://example.com/pgp-key.txt
# Our security policy
Policy: https://example.com/security-policy.html
# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html
# Verify this security.txt file
Signature: https://example.com/.well-known/security.txt.sig
Kann man jetzt dafür oder dagegen sein. Bin mir auch nicht sicher, ob sich das durchsetzen wird und ob es umgesetzt werden wird. Aber das würde den Disclosure Prozess vielleicht doch etwas vereinfachen.
Fazit
Nichts ist einfach.
Hersteller sollten sich in diesen Zeiten gedanken über Schwächen und Meldewege machen.
Je einfacher einem Pentester/Forscher das Melden von Sicherheitsschwachstellen gemacht wird, desto höher ist die Wahrscheinlichkeit, dass Schwachstellen nach dem Fund auch tatsächlich an den Hersteller vorab einer Veröffentlichung auf einschlägigen Mailinglisten/Medien gemeldet werden.
(White-Hat-)Pentester möchten nichts böses. Sie wollen nur auf Probleme aufmerksam machen und zu gegebener Zeit nach der Problembewältigung etwas Anerkennung für Ihre Mühen.
Das führt beiderseits langfristig zu positiven Erfahrungen. Und die (Produkt-)Sicherheit wird auch nebenbei gesteigert. Es klingt so einfach und erscheint doch manchmal sehr schwer.