Mit dem Einsatz dieser Software habe der Beschuldigte nach Einschätzung des Amtsgerichts gemäß §202a StGB eine ausreichend hohe Hürde überwunden, um sich strafbar zu machen.

Konkret ging es wohl um die Verwendung des weitverbreiteten Datenbank-Administrationstools phpMyAdmin, in das der Angeklagte das entdeckte Passwort eingegeben hatte, um auf die Datenbank von Modern Solution zuzugreifen

Ich finde es immer wieder erschreckend, wie unwissend die Leute sind, die solche Sachen entscheiden. PMA hat die Überwindung der Hürde "Passwort" doch nicht möglich gemacht. Die Hürde "Passwort" wurde in dem Moment wirkungslos, als es von der Betreiberfirma überall im Klartext verteilt wurde. 🤦

you are viewing a single comment's thread
view the rest of the comments

[–] aard@kyu.de 17 points 9 months ago* (last edited 9 months ago) (1 children)

Deswegen informiert man Betriebe in Deutschland durch ein einfaches drop database via VPN ueber ihre Sicherheitsprobleme.

Denn jetzt ist das Unternehmen nicht nur gezwungen, die Sicherheitslücke zu schließen, sondern muss auch alle Kunden darüber informieren, dass ihre Daten von einer nicht berechtigten Person eingesehen wurden. (Ohne Kenntnis, dass jemand die Daten tatsächlich gesehen hat wären sie dazu nicht verpflichtet.)

In der beschriebenen Situation ist davon auszugehen dass die Daten auch von anderen abgegriffen wurden die den Betreiber nicht informiert haben - solange er das nicht ausschliessen kann (was jemand der so ein Problem hat eher nicht koennen wird) bin ich der Meinung dass die Datenschutzbehoerden informiert werden sollten, auch wenn die Formulierung in der DSVGO das nicht direkt so hergibt. Es ist im heutigen Internet einfach unrealistisch anzunehmen dass es da keinen Zugriff gab - und ich hoffe dass die Rechtsprechung in den naechsten Jahren auch in die Richtung gehen wird.

[–] elvith@feddit.de 7 points 9 months ago (1 children)

Welche Optionen hat man aktuell denn laut der Rechtslage (sofern es kein BugBlunty-Programm o.ä. gibt)? Ich mein... ich hab schon Sicherheitslücken gefunden und gemeldet, ohne explizit danach gesucht zu haben...

Lücke melden - man wird verklagt
Lücke nicht melden - (schwerwiegende) Probleme werden nicht behoben, wenn sie einfach zu finden sind, werden die munter ausgenutzt
Veröffentlichung über Dritte - ist ja hier schief gegangen, zurück zu Punkt 1
Anonyme Full Disclosure - blöde für den Hersteller und vermutlich auch die betroffenen, deren Daten abgesaugt werden könnten, aber sorgt potentiell am ehesten für einen Fix. Wenn man es richtig anstellt, keine Spur, keine Klage. Geld hätte man ggf eh nie gesehen

Mich würde nicht wundern, wenn 2 und 4 in Zukunft zunehmen...

[–] aard@kyu.de 6 points 9 months ago (1 children)

Ich persoenlich hab inzwischen die Schnauze voll (aktuell ist glaub ich noch eine Anzeige gegen mich offen) - ich mach in Zukunft nur noch direktes full disclosure. Falls es danach aussieht als ob persoenliche Daten betroffen sind, und ich die Moeglichkeit habe die zu loeschen wuerde ich selbiges (natuerlich nicht zu mir verfolgbar) vor disclosure tun.

[–] elvith@feddit.de 6 points 9 months ago

Meine (wenngleich harmlos verlaufenen) Highlights bislang - für nix davon war ein Hacking-Tool nötig

Webseite mit Doku, beim Verwenden der Suche gibt's ab und an komische SQL Fehler. Auf einen Verdacht hin halt mal nach Suchbegriff' UNION SELECT * FROM TabelleGibtsNicht;-- gesucht und... ups... Fehlermeldung, dass die Tabelle nicht existiert...
Hersteller einer Software schickt uns die neue Version. Ich beschwere mich, dass sie vergessen haben die Jar für die API der neuen Version mitzuliefern. Antwort: Ja, passiert. Wir verwenden die auch intern in Komponente X, kopiere dir einfach die API.jar aus diesem Ordner und nimm die. Hab mich gewundert, warum die plötzlich so groß ist. In die IDE rein geladen und gesehen, dass da einige Klassen sind, die da nicht hin passen. Beim rumklicken in der IDE listet mir die die Inhalte der Jar und da liegen plötzlich der komplette Sourcecode und andere Daten und Dokumente in der JAR, die ich definitiv nicht haben sollte. Mit den älteren Versionen verglichen: Ja, der offizielle Build ist sauber. Die API für die eine Komponente liefert das aber schon seit über einem Jahr so aus. Da ist irgendein Buildprozess Amok gelaufen und hat gefühlt das komplette Home Verzeichnis des Entwicklers mit reingebaut.
Andere Software, anderer Hersteller, Java-Webapp. Unser Sicherheitsscanner meldet verwundbare Komponenten im Tomcat webapps Ordner der Anwendung. Er hatte dort die pom.xml usw. gefunden und analysiert. Hab mich gewundert und reingeschaut. Blöderweise waren darin für Build Steps Passwörter für Fileshares, Systeme und Codezertifikate enthalten (die Zertifikate selber zum Glück nur als Pfad zur Datei angegeben) und ein paar andere interessante Dinge