„Ursache des Lecks war ein Konfigurationsfehler bei einem Backup-Server. Es stand der Port 445 offen, der Zugriffe über das Netzwerkprotokoll SMB erlaubt. Deshalb konnte jeder Internet-Nutzer die von Buchbinder auf dem Server abgelegten Dateien herunterladen – insgesamt über 10 Terabyte. Ein Passwort war dafür nicht nötig. Man musste lediglich die IP-Adresse des Servers im Windows-Datei-Explorer eingeben, große Festplatten und ein paar Stunden Zeit zum Download investieren.“
Also wie doof muss man sich als Admin eigentlich anstellen. Sowas passiert doch nicht einfach aus Versehen… Lasst und mal etwas spekulieren.
Ich denke, da kommen mehrere Komponenten der Backup-Strategie zum Tragen, die einen solchen Leak möglich machen! Das kann man kaum an einem einzelnen Punkt festmachen!
Das SMB-Protokoll ist ein 30 Jahre alter Standard, den es in 3 Versionen gibt. Normalerweise wird dies in heterogenen Netzwerken für Datei und -Druckdienste in internen Domänen-Netwerken von MS eingesetzt, vor allem auch gerne bei Virtualisierungen in solchen Netzen, um verteiltes Speichern inkl. Failover-Clustering usw. einfach bereitstellen zu können.
Es wird ebengalls verwendet, um in Windows-Netzwerken, Verzeichnis-Freigaben zu realisieren. SMB wird oft auch als Dateisystem bezeichnet, was es aber nicht ist. SMB kann man mit dem NFS-Protokoll zur Bereitstellung von Laufwerken im lokalen Netzwerk vergleichen (z.B. NAS-Systeme / SAN-Systeme). Die SMB Versionen 1 & 2 sind relativ schwach in ihrer bereitgestellten Sicherheit! Erst ab Version 3 (Server 2016, Win 8.1 und 10) ist überhaupt eine Verschlüsselung standardmäßig mit an Bord.
Der „offene“ Backup-Server ist ein Cloudserver eines Drittanbieters im Internet und ist natürlich nicht im internen Buchbinder-Netzwerk integriert, sondern nur angebunden, quasi als verteilter Speicher, event. als Cluster…anscheinend mit einer alten SMB Version vor der dritten, da die Daten ja unverschlüsselt abgegriffen wurden. Der Inhalt der Backups bestand aus MSSQL-Datenbanken!!!
Die Backup-Dateien selber wurden als *.bak und *.log Dateien abgelegt.
Ich würde bei einer solchen Konstellation erstmal schätzen, dass KEINE Backup-Software bzw. kein Sicherungs-Management von Drittanbietern wie Veeam oder Acronis etc. genutzt wurde (was eindeutig hier von Vorteil gewesen wäre), da diese Produkte schon ganz andere Dateien beim Backup ablegen und weil diese Sicherungskonzepte wie ein eigenes Netzwerk im Netzwerk funktionieren und den Zugriff nicht einfach frei gegeben hätten!!
Der Kasus-Knacktus:
Naheliegend wäre in diesem Fall, dass die internen SQL-Server des Buchbinder Domänennetzwerks, die Sicherungen der Datenbanken über ihre eigenen Backup-Routinen durchgeführt haben !! Der SQL-Server legt dabei nämlich *.bak-Dateien an, inklusive der dazugehörigen *.log-Files !!
Das Prinzip dahinter wäre dann, dass der SQL-Server sich mit seinem Computerkonto aus der bestehenden Active Directory übers Internet am Cloud-Storage anmeldet und somit den Vollzugriff auf den Speicher erhält.
Da der Server ja kein Passwort für den Zugang eingeben kann wird eine solche Anmeldung erstmal intern über Richtlinienverteilung mittels GPOs innerhalb der Domäne konfiguriert. Die eigentliche Anmeldung am Cloud-Server wird dann normalerweise über Zertifikate automatisch während des Backup-Vorgangs realisiert.
Sollten also bei der Konfiguration des Computerkontos (SQL-Server) Fehler passiert sein (ein vergessener Haken an der entspr. Stelle reicht da aus!!) und / oder die Zertifikatsverwaltung bzw. die Verteilung an die Cloud beinhaltet Fehler oder wurde schlichtweg vergessen - soll’s ja geben, dann hat man den Salat sogar mit Dressing!!!
Der SQL-Server könnte sich dann unter Umständen problemlos an dem Cloud-Storage anmelden, OHNE das Authentifizierung stattfindet…Da zwischen beiden Servern auf Grund der übergeordneten Domäne eine bidirektionale Vertrauensstellung zueinander besteht, wird der Zugang noch einfacher gewährt!
Je nachdem, wie der Cloud-Server konfiguriert wurde, merkt dieser sich dann, dass Computerkonten (NICHT Benutzerkonten) ohne Authentifizierung Vollzugriff erhalten. Der Rest, wenn sich ein Fremder mit seinem Computer über die IP am Cloud-Speicher anmeldet, ist dann absolute Geschichte!
Peng - drin ist er !!
Ist eine Theorie meinerseits, die aber vollständig technisch fundiert ist ! Kommt sehr oft bei solchen Konstellationen zum Einsatz, überall auf der Welt bei kleinen und grossen Firmen.
Das war auch eine meiner Fragen. Wie kann es sein, dass man sich bei dieser Datenmenge und bei dieser Unternehmensgröße überhaupt an einen Dienstleister wenden kann, welcher einem ein so eigenartiges Backupkonzept empfiehlt?
Aber hälst du das wirklich für Wahrscheinlich? Höchstens, wenn die Buchbinder IT maßgeblich an der Konfiguration des Server beteiligt war. Ich kann mir einfach nicht erklären, wie so ein SMB Share public werden kann ohne das sich dabei jemand denkt „Mmmm, dass ist eventuell eine schlechte Idee das so einzustellen“. Und wieso ist so ein Backupserver eigentlich easy von jeder IP ansprechbar? Ich konfiguriere Backup Systeme für Kunden generell so, dass nur eine Kommunikation zwischen den benötigten Geräten stattfinden kann. Wie auch immer man das dann am Ende realisiert. Das wird auch bei denen möglich gewesen sein. Bei einem richtigen Drittanbieter, der solche Server für Unternehmen als Dienstleistung anbietet, wären da doch viel zu viele Kontrollinstanzen die sowas verhindern. Habe mal für einen mittelständischen IT Dienstleister gearbeitet. Dort wurden alle Aktionen bei größeren Kunden durch mehrere Leute begleitet und da wäre ein einzelner mit sowas niemals durchgekommen. Meine Vermutung ist eher, dass dieser Backup Server das Resultat einer zusammengesparten internen IT Infrastruktur, und fehlender Bereitschaft geschultes Personal einzustellen, ist. Hab schon viele solcher IT Lösungen im deutschen Mittelstand gesehen. Da zimmert dann der Typ, der sich gerade so am besten mit PCs auskennt, die Serverlandschaft zusammen und macht das ab dem Tag an hauptberuflich in der IT die es auch erst ab dem Tag gibt (So ist mein ehemaliger „Ausbilder“ zu seinem Posten gekommen).
Aber warum sollten die das tun? Du meinst damit also, dass die eventuell sogar ein korrektes Backup System verwenden, diese Sicherung aber getrennt davon gemacht wurde und dann dort gelandet ist?
Ich stimme dir grundsätzlich zu. Aber das scheint mir alles etwas zu unwahrscheinlich.
Naja. Also wir verwenden viele Produkte von synology oder ähnlichen Anbietern und ich sage es mal so. Selbst mit mittelmäßiger Erfahrung konfigurierst du so ein Teil nicht so dermaßen falsch. Wir wissen natürlich nicht, was das für ein Storage Server war und wie der genau verwaltet wurde. Aber ich denke jetzt auch nicht, dass Buchbinder da selbstgebastelte storage Server stehen hat. Allein schon wegen Gewährleistung, Service usw…
Genau daran hab ich bei dem ganzen Vorgang gedacht !! So ne interne IT mit eigenen Azubis usw., wo dann schon der Nachwuchs mit kruden Ideen und falscher fahmännischer Expertise ausgestattet werden !
Es ist kaum möglich, dass so ein Netzwerk insgesamt von einem Systemhaus administriert wird und die solche Fehler nicht bemerken. Die hätten vermutlich die komplette Infrastruktur schon von Grund auf anders angelegt!! Ich stelle mitr die IT-Abtlg. bei Buchbinder ungefähr so vor, wie in einer Behörde…
Sowas könnte durchaus passieren, wenn die Netzwerkstruktur inkl. Internetanbindung / Cloud von einer internen IT plus zusätzlich von aussenstehenden IT’lern gemanaged wird…Wenn der linke nicht weiss, was der rechte tut - auf Grund fehlender Doku usw. !?! Möglich wärs…kommt oft vor in der Praxis. Je größer die Firma, um so größer auch die Effekte (positiv sowie negativ)!
Natürlich, wer nicht ! Aber dafür bräuchtest du andere Protokolle und technische Voraussetzungen, die hier nicht genannt wurden z.B. ne Hardware-Firewall, die dann die Erkennung und Auswertung der erlaubten / verbotenen Verb. auswertet. Oder halt eine entsprechende Software. Von alle diesen Dingen ist ja nixx bekannt! Eine Identifikation über die MAC würde schon sinnvoller sein, wie das aktuelle Szenario ^^
Kenne ich auch zur genüge. Deswegen, siehe oben…
Stimme ich dir zu 142,659% zu!
Wenn die „Geiz ist geil - Mentalität“ die oberste Prio hat, kommt das aber vor…siehe auch oben bezüglich der kruden internen IT
Nein…der SQL hat doch ein eigenes Sicherungsprogramm…was aus dem ursprünglichen Standard Server-Backup aus dem Server-Betriebssystem kommt und natürlich genauso grottig ist.
Wenn man dann aus Sparsamkeit dieses nutzt, anstatt z.B. Veeam (leichter Fetisch) kannst du natürlich diese Backups fahren, dabei ist doch egal wohin! Kann doch auch in die Cloud sein. Ist ja auh wieder viel billiger als sich da fette SANs oder ähnliches hinzustellen! Es gibt sonst kaum noch Programme, die *.bak Dateien nutzen…erst recht keine Backup-Software!!
P.S.
Was mir bei dem Glaskugeln nebenbei einfällt. Eine günstige (wegen Geiz) aber auch, je nach Konfig, hochsichere Lösung, wäre das Lieblingsthema der Forum-Nutzer >>> VPN
Nur halt diesmal dafür eingesetzt, wofür es mal entwickelt wurde!
VPN-Tunnel zwischen Storage und SQL insgesamt hoch verschlüsselt inkl. Auth. durch Zertis aus eigener CA !! Läuft bei guter Konfiguration eine Ewigkeit ohne Probs und Wartung! Beisst sich auch eigentlich jeder die Zähne dran aus…Sollte dort das Minimum sein. Oder man macht weiter, frei dem Motto: WER BACKUP MACHT, IST FEIGE !!!
Ja darüber wissen wir nichts. Aber kann mir auch nicht wirklich vorstellen, dass es da keine HW Firewall gibt. Also warum sollte es keine geben?
Hatte ich anfangs irgendwie falsch verstanden. Verstehe. Mit Veeam hätten man vorallem auch direkt verschlüsselte Backups erstellen können…
Nene SMB ohne PW ins WAN zu hängen ist doch Industriestandard hatte ich jetzt gedacht. Wieder was gelörnt nä.
Wahrscheinlich haben die nem 1. Lehrjahrazubi die Aufgabe gegeben, die Backup Server für nen Mitarbeiter aus nem anderen Standort bereitzustellen. Wie er das machen soll, haben sie ihm dann wahrscheinlich nicht gezeigt
Oder es war ein Abschlußprojekt des Azubis für seine IHK-Prüfung! Wurde aber von der Internen auch nicht überprüft, weil der Azubi schliesslich seine praktische Prüfung bei der IHK mit Note 3,85 bestanden hatte…
Noch nichtmal eine Aufforderung / Warnung wegen der Passwörter etc.
Ist schon ne klasse Nummer das Ganze!
Diese betriebene NULL INFO - Politik macht die Firma Buchbinder im nachhinein jetzt nicht unbedingt vertrauensvoller!
Im übrigen verstossen die dort schon seit Jahren gegen sämtliche Datenschutzregelungen, wenn man jetzt mal nur über Datenvermeidung, Datensparsamkeit und die Aufbewarung von personenbezogenen Daten nachdenkt zum Beispiel…
Geht irgendwie alles gar nicht bei denen!!!
OK…aber ich glaube nicht, dass eine solche Lücke in einem Telekom Consumer-Router speziell in diesem Fall, den Braten nicht fett macht!
Abseits des Portstatus sind bei Buchbinder wohl andere Faktoren (siehe oben) für den Leak verantwortlich. Im übrigen wird über 445 eigentlich nur die reine Protokollkommunikation abgewickelt. Der Stream läuft ja schliesslich über andere Ports. Der Fall wird übrigens auch in vielen anderen Foren, welche sich mit AD-Infrastrukturen beschäftigen diskutiert. Es scheint wirklich so, dass im Unternehmen intern, desaströse Netzwerksicherheit betrieben wird, wenn man alle Aussagen dahingehend für voll nehmen kann.
Man kann nur hoffen, dass dieser Fall die Datenschützer der Behörden mal vollends auf den Plan ruft, um mal tiefgründig zu prüfen, was dort wirklich intern los ist!
Gemäß der Datenschutzgrundverordnung müssen wir über diese Datenverletzung
informieren.
…stimmt mich dabei nicht wirklich versöhnlich ! Naja, denn so wirklich gerne scheinen sie das nicht zu machen. OK, wer macht das schon als Wirtschaftsunternehmen - aber in diesem Fall mit solchen Ausmaßen, kann man nur sagen: „Selber schuld!“
Die Autovermietung Buchbinder laviert sich schweigsam durch die Folgen ihrer riesigen Datenpanne, die c’t und Die Zeit im Januar aufdeckten.
Die EU-Datenschutz-Grundverordnung (DSGVO) gibt strenge Regeln zum Umgang mit personenbezogenen Daten vor. Pflichten ergeben sich gerade im Nachgang von Schadensfällen, etwa, wenn Kundendaten wegen einer Sicherheitslücke ungeschützt abrufbar waren. Befolgt eine Firma diese Regeln nicht, drohen deftige Sanktionen.
Seitdem die DSGVO wirksam ist (Mai 2018), haben die Aufsichtbehörden bereits zu einigen kleineren Datenlecks Bußgelder verhängt. Keines davon ist vergleichbar mit der Panne beim Autovermieter Buchbinder, die c’t und das Wochenblatt Die Zeit Ende Januar veröffentlichten. Die Unternehmensgruppe speicherte über mehrere Monate regelmäßige Backups ihrer Firmendatenbank auf einem ungeschützten Server, die über das Dateisystemprotokoll SMB frei im Internet zugänglich waren.
Die Backups enthielten dem Augenschein nach die komplette MSSQL-Kundendatenbank zusammen mit über 9 Millionen Mietverträgen bis zurück zum Jahr 2003. Neben den Mietern waren auch Fahrer mit Name, Adresse, Geburtsdatum, Führerscheinnummer und -ausstellungsdatum sowie Mobilfunknummern und zuweilen auch E-Mail-Adressen aufgeführt. Hinzu kamen 5 Millionen Dateien mit umfangreicher Firmenkorrespondenz nebst eingescannten Rechnungen, Verträgen, Faxen, E-Mails und Schadensbildern von Autos. Verknüpfungen von Fahrern und Mietern ließen Rückschlüsse auf sensible Personengruppen zu. Zudem waren unter anderem Kontaktdaten von Unfallbeteiligten gespeichert.
Hier einmal der Link zum gesamten Zwischenbericht bei Heise, der den „Daten-Leak Skandal“ noch skandalöser wirken lässt:
wird eine solche Anmeldung erstmal intern über Richtlinienverteilung mittels GPOs innerhalb der Domäne konfiguriert. Die eigentliche Anmeldung am Cloud-Server wird dann normalerweise über Zertifikate automatisch während des Backup-Vorgangs realisiert.
