In einer digitalen Welt ist die IT-Sicherheit zentral. Trotzdem droht Strafe, wenn Hacker solche Lücken ehrenamtlich finden und melden. Von Philip Raillon.
Ich hab damals - halb ernst, halb sarkastisch - schon gesagt, dass man doch bitte froh sein soll, dass Leute, die sowas finden das dann auch direkt melden.
Wenn das weiterhin rechtlich problematisch ist, gibt’s es nur zwei Optionen:
Augen zu und durch - ignorieren, nix melden und wissen wie trivial die Lücke ist und wie schnell die gefunden wird
Anonym Public full disclosure, statt vertraulich dem Hersteller/Betreiber Bescheid geben.
Beides nicht gut. Und zum ersten Punkt: Angenommen durch die Lücke käme später jemand wirklich zu schaden - bspw. Hack eines Krankenhauses und irgendwelche Behandlungen verzögern sich/fallen weg/schlagen fehl/… - wäre das nicht melden der Lücke nicht irgendwie auch eine Mitschuld/unterlassene Hilfeleistung/…?
Ich verstehe auch nicht, warum von Sicherheitslücken betroffene Anbieter diese Hinweise nicht einfach dankend annehmen. Es trägt ja zur allgemeinen Sicherheit einer App bei. Stattdessen reagiert man so, als wäre man ertappt worden und versucht die Hinweisgeber durch ein Strafverfahren einzuschüchtern.
Am Besipiel der eletronischen Patientenakte sieht man aber ganz deutlich, dass das Aufzeigen von Sicherheitslücken durch Dritte als Störfaktor wahrgenommen wird, anstatt als wertvoller Hinweis. Die Hinweisgeber bringen Unruhe in das Gefüge, und das ist nicht gut, wo man doch froh ist, dass der Bums gerade eben so funktioniert.
Mit dieser Aussicht auf “Belohnung” kann ich mir auch gut vorstellen, wenn dann Option 3) angewendet wird: Die geleakten Daten direkt im Darknet verhökern.
Ich hatte vor ner Weile den Fall, dass ich eine API eines Onlineshops abfragen wollte für nen Alert, wenn ein bestimmter Preis unterschritten wird - also einfach ein GET auf den Endpoint, den auch das JS der Seite nutzt um die Artikel zu laden.
Ich hab im Script versehentlich statt https://example.com/product/$productID dann https://example.com/product/$productName aufgerufen - und der Produktname hatte bei meinen Tests zufällig ' im Namen. Aufgrund der resultierenden Fehlermeldung zum Syntaxfehler des SQL war klar, dass hier direkt ne SQL-Injection vorliegt.
Das war genau zu der Zeit als der Fall hier in den Medien war. Ich hab halt die Klappe gehalten und es ignoriert - zwei Monate vorher hätte ich vielleicht ne freundliche Mail geschrieben, aber zu der Zeit (und auch heute)? Egal. Wenn überhaupt - vorallem bei einer besonders leicht auffälligen Lücke wie hier - würde ich vielleicht der c’t oder jemandem beim CCC den Tipp geben, dass man bei dieser URL ja bloß nix anderes als nen int als ID verwenden sollte…
Ich hab damals - halb ernst, halb sarkastisch - schon gesagt, dass man doch bitte froh sein soll, dass Leute, die sowas finden das dann auch direkt melden.
Wenn das weiterhin rechtlich problematisch ist, gibt’s es nur zwei Optionen:
Augen zu und durch - ignorieren, nix melden und wissen wie trivial die Lücke ist und wie schnell die gefunden wird
Anonym Public full disclosure, statt vertraulich dem Hersteller/Betreiber Bescheid geben.
Beides nicht gut. Und zum ersten Punkt: Angenommen durch die Lücke käme später jemand wirklich zu schaden - bspw. Hack eines Krankenhauses und irgendwelche Behandlungen verzögern sich/fallen weg/schlagen fehl/… - wäre das nicht melden der Lücke nicht irgendwie auch eine Mitschuld/unterlassene Hilfeleistung/…?
Ich verstehe auch nicht, warum von Sicherheitslücken betroffene Anbieter diese Hinweise nicht einfach dankend annehmen. Es trägt ja zur allgemeinen Sicherheit einer App bei. Stattdessen reagiert man so, als wäre man ertappt worden und versucht die Hinweisgeber durch ein Strafverfahren einzuschüchtern.
Am Besipiel der eletronischen Patientenakte sieht man aber ganz deutlich, dass das Aufzeigen von Sicherheitslücken durch Dritte als Störfaktor wahrgenommen wird, anstatt als wertvoller Hinweis. Die Hinweisgeber bringen Unruhe in das Gefüge, und das ist nicht gut, wo man doch froh ist, dass der Bums gerade eben so funktioniert.
Mit dieser Aussicht auf “Belohnung” kann ich mir auch gut vorstellen, wenn dann Option 3) angewendet wird: Die geleakten Daten direkt im Darknet verhökern.
Ich hatte vor ner Weile den Fall, dass ich eine API eines Onlineshops abfragen wollte für nen Alert, wenn ein bestimmter Preis unterschritten wird - also einfach ein GET auf den Endpoint, den auch das JS der Seite nutzt um die Artikel zu laden.
Ich hab im Script versehentlich statt
https://example.com/product/$productIDdannhttps://example.com/product/$productNameaufgerufen - und der Produktname hatte bei meinen Tests zufällig'im Namen. Aufgrund der resultierenden Fehlermeldung zum Syntaxfehler des SQL war klar, dass hier direkt ne SQL-Injection vorliegt.Das war genau zu der Zeit als der Fall hier in den Medien war. Ich hab halt die Klappe gehalten und es ignoriert - zwei Monate vorher hätte ich vielleicht ne freundliche Mail geschrieben, aber zu der Zeit (und auch heute)? Egal. Wenn überhaupt - vorallem bei einer besonders leicht auffälligen Lücke wie hier - würde ich vielleicht der c’t oder jemandem beim CCC den Tipp geben, dass man bei dieser URL ja bloß nix anderes als nen int als ID verwenden sollte…