7
Sicherheitslücke entdeckt: Millionen Kundendaten im Internet frei zugänglich - oder auch nicht?
Um es gleich vorwegzunehmen, die Focus-Redakteure haben aus meiner Sicht auf genaue Recherchen verzichtet. Einige Behauptungen werden hier frei interpretiert und Zahlen aus dem Zusammenhang gerissen. Das Originaldokument stammt von drei CISPA Studenten in Saarbrücken und bezieht sich auf "einen" oberflächlichen Portscan und "einem" Test mit einer Datenbank "eines" französischen Börsenhändlers. Wie man dann eine Story an das Volk bringt, zeigt der F-Artikel. Es fängt schon im ersten Satz an:
Die F-Redakteure haben dabei wohl übersehen, dass es keine Sicherheitslücke ist, wenn die zuständigen Administratoren, die Datenbankserver falsch konfigurieren. Es geht hier um die MongoDB und diese hat bekanntlich per Default einen IP Zugangsschutz eingeschaltet (das Netzwerkinterface ist an den lokalen Port gebunden). So steht es im Handbuch und natürlich kann man auch einen Passwort Zugangsschutz mit zwei Befehlen aktivieren, aber es sieht so aus, als wäre das nicht passiert. Ist das bereits eine Sicherheitslücke? Eher ein menschlicher Fehler und weniger ein Problem der Software.
Ah, jetzt dämmert es dem F-Redakteur dann doch und nimmt seinem ersten Satz erst einmal den Schwung heraus.
Ups, jetzt ist es wieder eine Lücke. Ja was denn nun?
Gehören die 40.000 Datenbanken jetzt zu den "vielen Suchtreffern"? oder ist es die Gesamtzahl der betroffenen Datenbanken. Hier die Auflösung: Diese Zahl stammt aus der Dokumentation der drei CISPA Studenten in Saarbrücken und ist ein einfacher Scan nach dem Default-Port von MongoDB. Ob das jetzt betroffene Datenbanken sind, kann man an dieser Stelle überhaupt nicht feststellen.
Wieder eine neue hohe Zahl in den Raum geworfen ohne genaue Angaben. Laut der Dokumention der Studenten wurden bei einem Test auf eine Datenbank zirka acht Millionen Adresseinträge frei zugänglich gefunden, davon waren eine halbe Million Daten von deutschen Kunden.
Jetzt haben sie tatsächlich mal die genaue Zahl genannt: "die Datenbank eines deutschen Online-Händlers". Im Rest des Beitrags geht es um Tausende, um Millionen und jetzt ganz konkret ist es "eine" Datenbank. Aber halt, war es nicht ein französischer börsennotierter Internetdiensteanbieter und Mobiltelefonbetreiber? Von einem deutschen Online-Händler und Zahlungsinformationen habe ich in der original Doku nichts gelesen.
Ehrlich, ich halte diesen Action-Journalismus für sehr gefährlich. Die Menschen werden damit geblendet, ganz zu schweigen von der Rufschädigung für die Software.
Aber bleiben wir beim Thema. Das was man der MongoDB hier wirklich vorwerfen könnte, ist alleine die Tatsache, das sie per default "nur" einen IP Zugangsschutz aktiviert (IP-Adresse ist an das lokale Netzwerk gebunden). Wenn ein Admin aber weder eine Firewall noch ein Passwort für eine Datenbank davor schaltet und zusätzlich das lokale Binden an das Interface ausschaltet, ist das keine Sicherheitslücke, sondern ein Versagen der IT-Verantwortlichen. Aus dieser Sicht macht der Beitrag natürlich Sinn und hier sollten sich alle MongoDB Admins (die wir übrigens auch im Einsatz haben) mal Gedanken machen und ihre Sicherheit prüfen. Von einer gefährlichen Sicherheitslücke zu sprechen und mit irgendwelchen Zahlen ohne Zusammenhang einen reißerischen Beitrag zu machen, halte ich für schlechte Presse.
Die FAZ hat übrigens auch darüber berichtet. Ihr Text war zwar erheblich sachlicher, aber auch sie reden über eine "hochgefährliche Sicherheitslücke": http://www.faz.net/aktuell/technik-motor/computer-internet/sicherheitsl .... In heutigen Zeiten muss dieses Keyword wohl in einen Beitrag rein.
Hier die original Dokumentationen der drei Studenten: http://cispa.saarland/mongodb/
Gruß
Frank
http://www.focus.de/digital/internet/deutschland-ist-massiv-betroffen-s ...
Studenten aus Saarbrücken haben eine schwerwiegende Sicherheitslücke im Internet entdeckt ..
Die F-Redakteure haben dabei wohl übersehen, dass es keine Sicherheitslücke ist, wenn die zuständigen Administratoren, die Datenbankserver falsch konfigurieren. Es geht hier um die MongoDB und diese hat bekanntlich per Default einen IP Zugangsschutz eingeschaltet (das Netzwerkinterface ist an den lokalen Port gebunden). So steht es im Handbuch und natürlich kann man auch einen Passwort Zugangsschutz mit zwei Befehlen aktivieren, aber es sieht so aus, als wäre das nicht passiert. Ist das bereits eine Sicherheitslücke? Eher ein menschlicher Fehler und weniger ein Problem der Software.
Ursache sei eine falsch konfigurierte frei verfügbare Datenbank-Software, auf der weltweit Millionen von Online-Shops und Plattformen ihre Dienste aufbauen.
Ah, jetzt dämmert es dem F-Redakteur dann doch und nimmt seinem ersten Satz erst einmal den Schwung heraus.
Die Lücke betrifft nach Erkenntnissen der Studenten am Kompetenzzentrum für IT-Sicherheit (CISPA) knapp 40 000 Datenbanken.
Ups, jetzt ist es wieder eine Lücke. Ja was denn nun?
Bei vielen Suchtreffern sei der Zugang weder geschlossen noch in irgendeiner anderen Form abgesichert gewesen.
Gehören die 40.000 Datenbanken jetzt zu den "vielen Suchtreffern"? oder ist es die Gesamtzahl der betroffenen Datenbanken. Hier die Auflösung: Diese Zahl stammt aus der Dokumentation der drei CISPA Studenten in Saarbrücken und ist ein einfacher Scan nach dem Default-Port von MongoDB. Ob das jetzt betroffene Datenbanken sind, kann man an dieser Stelle überhaupt nicht feststellen.
Stichprobe bringt halbe Million deutscher Adressen
Wieder eine neue hohe Zahl in den Raum geworfen ohne genaue Angaben. Laut der Dokumention der Studenten wurden bei einem Test auf eine Datenbank zirka acht Millionen Adresseinträge frei zugänglich gefunden, davon waren eine halbe Million Daten von deutschen Kunden.
Die Datenbank eines deutschen Online-Händlers inklusive Zahlungsinformationen hätten sie ebenfalls ungesichert vorgefunden.
Jetzt haben sie tatsächlich mal die genaue Zahl genannt: "die Datenbank eines deutschen Online-Händlers". Im Rest des Beitrags geht es um Tausende, um Millionen und jetzt ganz konkret ist es "eine" Datenbank. Aber halt, war es nicht ein französischer börsennotierter Internetdiensteanbieter und Mobiltelefonbetreiber? Von einem deutschen Online-Händler und Zahlungsinformationen habe ich in der original Doku nichts gelesen.
Ehrlich, ich halte diesen Action-Journalismus für sehr gefährlich. Die Menschen werden damit geblendet, ganz zu schweigen von der Rufschädigung für die Software.
Aber bleiben wir beim Thema. Das was man der MongoDB hier wirklich vorwerfen könnte, ist alleine die Tatsache, das sie per default "nur" einen IP Zugangsschutz aktiviert (IP-Adresse ist an das lokale Netzwerk gebunden). Wenn ein Admin aber weder eine Firewall noch ein Passwort für eine Datenbank davor schaltet und zusätzlich das lokale Binden an das Interface ausschaltet, ist das keine Sicherheitslücke, sondern ein Versagen der IT-Verantwortlichen. Aus dieser Sicht macht der Beitrag natürlich Sinn und hier sollten sich alle MongoDB Admins (die wir übrigens auch im Einsatz haben) mal Gedanken machen und ihre Sicherheit prüfen. Von einer gefährlichen Sicherheitslücke zu sprechen und mit irgendwelchen Zahlen ohne Zusammenhang einen reißerischen Beitrag zu machen, halte ich für schlechte Presse.
Die FAZ hat übrigens auch darüber berichtet. Ihr Text war zwar erheblich sachlicher, aber auch sie reden über eine "hochgefährliche Sicherheitslücke": http://www.faz.net/aktuell/technik-motor/computer-internet/sicherheitsl .... In heutigen Zeiten muss dieses Keyword wohl in einen Beitrag rein.
Sicherheitslücke hin- oder her, ich rate allen MongoDB Administratoren die Config-Datei zu bearbeiten (/etc/mongodb.conf) und den Wert "bind_ip" an das lokale Interface zu binden (bind_ip = 127.0.0.1). Braucht man Remotezugriff von einem entfernten Server sollte man unbedingt die Firewall so konfigurieren, dass nicht jeder auf Port 27017 zugreifen kann. Ein Passwort auf die Datenbanken zu setzten ist auch kein Fehler 
Hier die original Dokumentationen der drei Studenten: http://cispa.saarland/mongodb/
Gruß
Frank
http://www.focus.de/digital/internet/deutschland-ist-massiv-betroffen-s ...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 262958
Url: https://administrator.de/forum/sicherheitsluecke-entdeckt-millionen-kundendaten-im-internet-frei-zugaenglich-oder-auch-nicht-262958.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
7 Kommentare
Neuester Kommentar
Naja, Du reitest ganz schön auf dem aus Deiner Sicht falsch angewendeten Begriff Sicherheitslücke herum
http://de.wikipedia.org/wiki/Sicherheitsl%C3%BCcke_(Software)
Der einleitende Satz lautet zwar:
"Eine Sicherheitslücke ist im Gebiet der Informationssicherheit ein Fehler in einer Software, durch den ein Programm mit Schadwirkung (Malware) oder ein Angreifer in ein Computersystem eindringen kann."
Dadurch ist die Definition starr auf einen Programmfehler ausgerichtet, ähnlich Deiner Interpretation.
Weiter unten steht allerdings:
"Sicherheitslücken entstehen unter anderem durch den unzureichenden Schutz eines Computers vor Angriffen aus dem Netz (beispielsweise mangels Firewall oder anderer Sicherheitssoftware) sowie durch Programmierfehler im Betriebssystem, Webbrowser oder anderen Softwareanwendungen, die auf dem System betrieben werden."
Die Definition gefällt mir besser. Auch durch falsche oder unzulängliche Konfiguration entstehen Sicherheitslücken. Ich würde das nicht nur auf Programmfehler eingrenzen.
Klar, focus formuliert reißerisch wie immer. Wenn letztendlich aber möglichst viele schlampige MongoDB-Admins auf ihre mangelnde Professionalität aufmerksam gemacht werden, dann haben die Artikel was gebracht.
http://de.wikipedia.org/wiki/Sicherheitsl%C3%BCcke_(Software)
Der einleitende Satz lautet zwar:
"Eine Sicherheitslücke ist im Gebiet der Informationssicherheit ein Fehler in einer Software, durch den ein Programm mit Schadwirkung (Malware) oder ein Angreifer in ein Computersystem eindringen kann."
Dadurch ist die Definition starr auf einen Programmfehler ausgerichtet, ähnlich Deiner Interpretation.
Weiter unten steht allerdings:
"Sicherheitslücken entstehen unter anderem durch den unzureichenden Schutz eines Computers vor Angriffen aus dem Netz (beispielsweise mangels Firewall oder anderer Sicherheitssoftware) sowie durch Programmierfehler im Betriebssystem, Webbrowser oder anderen Softwareanwendungen, die auf dem System betrieben werden."
Die Definition gefällt mir besser. Auch durch falsche oder unzulängliche Konfiguration entstehen Sicherheitslücken. Ich würde das nicht nur auf Programmfehler eingrenzen.
Klar, focus formuliert reißerisch wie immer. Wenn letztendlich aber möglichst viele schlampige MongoDB-Admins auf ihre mangelnde Professionalität aufmerksam gemacht werden, dann haben die Artikel was gebracht.
Hi @Trontur,
ich bin da ganz bei dir, wenn es darum geht, auf die mangelnde Konfiguration der MongoDB Admins hinzuweisen. Das habe ich auch so geschrieben. Für mich ist es dann eine Sicherheitslücke, wenn es ohne Fehlkonfiguration im System Fehler oder Lücken gibt, die man zum Ausspähen oder Hacken der Software ausnutzen kann. Eine Fehlkonfiguration eines Admins kann keine allgemeine Sicherheitslücke der Software darstellen. Das würde im Umkehrschluss bedeuten, das z.B. auch jede MySQL Datenbank, die kein Passwort gesetzt hat eine potentielle Sicherheitslücke von MySQL darstellt. Ich glaube Oracle wäre nicht erfreut wenn man Morgen über tausende MySQL Sicherheitslücken berichten würde, wo der Admin das default Root Passwort nicht gesetzt hat. Ich wette ich würde bei einem Scan auf den Default-Port der Mysql auch einen passenden Kandidaten finden (und auch eine große Anzahl von möglichen Kandidaten).
Kommt noch dazu, das die meisten News-Berichte wirklich falsch sind. MongoDB hat per Default einen guten Zugangsschutz. In der Standard-Konfiguration ist MongoDB an das lokale Interface (127.0.0.1) gebunden. Es kann also niemand, außer das lokale Interface, auf die MongoDB zugreifen. Man braucht kein Passwort um die DB abzusichern. Das machen viele andere Linux Programme genau so und da wird es bisher nicht als Sicherheitslücke verkauft (z.B. NFS).
Was bleibt also? Ein oder evtl. mehrere Admins haben die Default-Einstellung aktiv umgangen und die Datenbank falsch konfiguriert. Sie haben keine Firewall eingesetzt und die Standard-Sicherheit aktiv ausgehebelt. Das haben drei Studenten herausgefunden und darauf aufmerksam gemacht. Die Dokumentation von ihnen erklärt den Vorgang ganz genau und sie präsentieren auch gleich eine Lösung dazu. Der Scan von ca. 40.000 Hosts in dem Dokument ist eine reine Spekulation, da sie letztendlich nur einen einzigen Host überprüft haben (was sie rechtlich schon nicht durften, das ist aber ein anderes Thema). Ob die anderen 39999 Hosts jetzt ein Passwort oder einen anderen Zugriffsschutz aktiviert haben, lässt sich überhaupt nicht feststellen. Genau das sagen sie selbst in ihrer Dokumentation.
Der Großteil unserer Presse stellt das aber also globale Sicherheitslücke das Internets und der Software dar. Das ist nicht nur übertrieben, sondern auch schlichtweg falsch. Die News werden nur noch abgeschrieben und nicht mehr überprüft. Recherche ist mittlerweile anscheinend ein Fremdwort für diese Redaktionen. Es wird reißerisch Panik und Angst beim User geschürt, ohne auf die Fakten zu achten.
Wäre aber schön, wenn die Beiträge auch korrekt wären. Und das mit den "vielen" Admins ist eine reine Spekulation und basiert nicht auf Fakten.
Gruß
Frank
ich bin da ganz bei dir, wenn es darum geht, auf die mangelnde Konfiguration der MongoDB Admins hinzuweisen. Das habe ich auch so geschrieben. Für mich ist es dann eine Sicherheitslücke, wenn es ohne Fehlkonfiguration im System Fehler oder Lücken gibt, die man zum Ausspähen oder Hacken der Software ausnutzen kann. Eine Fehlkonfiguration eines Admins kann keine allgemeine Sicherheitslücke der Software darstellen. Das würde im Umkehrschluss bedeuten, das z.B. auch jede MySQL Datenbank, die kein Passwort gesetzt hat eine potentielle Sicherheitslücke von MySQL darstellt. Ich glaube Oracle wäre nicht erfreut wenn man Morgen über tausende MySQL Sicherheitslücken berichten würde, wo der Admin das default Root Passwort nicht gesetzt hat. Ich wette ich würde bei einem Scan auf den Default-Port der Mysql auch einen passenden Kandidaten finden (und auch eine große Anzahl von möglichen Kandidaten).
Kommt noch dazu, das die meisten News-Berichte wirklich falsch sind. MongoDB hat per Default einen guten Zugangsschutz. In der Standard-Konfiguration ist MongoDB an das lokale Interface (127.0.0.1) gebunden. Es kann also niemand, außer das lokale Interface, auf die MongoDB zugreifen. Man braucht kein Passwort um die DB abzusichern. Das machen viele andere Linux Programme genau so und da wird es bisher nicht als Sicherheitslücke verkauft (z.B. NFS).
Was bleibt also? Ein oder evtl. mehrere Admins haben die Default-Einstellung aktiv umgangen und die Datenbank falsch konfiguriert. Sie haben keine Firewall eingesetzt und die Standard-Sicherheit aktiv ausgehebelt. Das haben drei Studenten herausgefunden und darauf aufmerksam gemacht. Die Dokumentation von ihnen erklärt den Vorgang ganz genau und sie präsentieren auch gleich eine Lösung dazu. Der Scan von ca. 40.000 Hosts in dem Dokument ist eine reine Spekulation, da sie letztendlich nur einen einzigen Host überprüft haben (was sie rechtlich schon nicht durften, das ist aber ein anderes Thema). Ob die anderen 39999 Hosts jetzt ein Passwort oder einen anderen Zugriffsschutz aktiviert haben, lässt sich überhaupt nicht feststellen. Genau das sagen sie selbst in ihrer Dokumentation.
Der Großteil unserer Presse stellt das aber also globale Sicherheitslücke das Internets und der Software dar. Das ist nicht nur übertrieben, sondern auch schlichtweg falsch. Die News werden nur noch abgeschrieben und nicht mehr überprüft. Recherche ist mittlerweile anscheinend ein Fremdwort für diese Redaktionen. Es wird reißerisch Panik und Angst beim User geschürt, ohne auf die Fakten zu achten.
Wenn letztendlich aber möglichst viele schlampige MongoDB-Admins auf ihre mangelnde Professionalität aufmerksam gemacht werden, dann haben die Artikel was gebracht.
Wäre aber schön, wenn die Beiträge auch korrekt wären. Und das mit den "vielen" Admins ist eine reine Spekulation und basiert nicht auf Fakten.
Gruß
Frank
Für mich ist es dann eine Sicherheitslücke, wenn es ohne Fehlkonfiguration im System Fehler oder
Lücken gibt, die man zum Ausspähen oder Hacken der Software ausnutzen kann. Eine Fehlkonfiguration eines Admins kann
keine allgemeine Sicherheitslücke der Software darstellen. Das würde im Umkehrschluss bedeuten, das z.B. auch jede MySQL
Datenbank, die kein Passwort gesetzt hat eine potentielle Sicherheitslücke von MySQL darstellt. Ich glaube Oracle wäre
nicht erfreut wenn man Morgen über tausende MySQL Sicherheitslücken berichten würde, wo der Admin das default Root
Passwort nicht gesetzt hat. Ich wette ich würde bei einem Scan auf den Default-Port der Mysql auch einen passenden Kandidaten
finden (und auch eine große Anzahl von möglichen Kandidaten).
Kommt noch dazu, das die meisten News-Berichte wirklich falsch sind. MongoDB hat per Default einen guten Zugangsschutz. In der
Standard-Konfiguration ist MongoDB an das lokale Interface (127.0.0.1) gebunden. Es kann also niemand, außer das lokale
Interface, auf die MongoDB zugreifen. Man braucht kein Passwort um die DB abzusichern. Das machen viele andere Linux Programme
genau so und da wird es bisher nicht als Sicherheitslücke verkauft (z.B. NFS).
Lücken gibt, die man zum Ausspähen oder Hacken der Software ausnutzen kann. Eine Fehlkonfiguration eines Admins kann
keine allgemeine Sicherheitslücke der Software darstellen. Das würde im Umkehrschluss bedeuten, das z.B. auch jede MySQL
Datenbank, die kein Passwort gesetzt hat eine potentielle Sicherheitslücke von MySQL darstellt. Ich glaube Oracle wäre
nicht erfreut wenn man Morgen über tausende MySQL Sicherheitslücken berichten würde, wo der Admin das default Root
Passwort nicht gesetzt hat. Ich wette ich würde bei einem Scan auf den Default-Port der Mysql auch einen passenden Kandidaten
finden (und auch eine große Anzahl von möglichen Kandidaten).
Kommt noch dazu, das die meisten News-Berichte wirklich falsch sind. MongoDB hat per Default einen guten Zugangsschutz. In der
Standard-Konfiguration ist MongoDB an das lokale Interface (127.0.0.1) gebunden. Es kann also niemand, außer das lokale
Interface, auf die MongoDB zugreifen. Man braucht kein Passwort um die DB abzusichern. Das machen viele andere Linux Programme
genau so und da wird es bisher nicht als Sicherheitslücke verkauft (z.B. NFS).
Im aktuellen Fall scheint es aber doch so zu sein, dass die MongoDBs nicht (nur) am lokalen Interface angebunden, sondern von außen erreichbar sind, oder?
Und wenn man ein DBMS ungeschützt öffentlich erreichbar macht, ist das für mich eine durch unprofessionelle Konfiguration erzeugte Sicherheitslücke.
Der Großteil unserer Presse stellt das aber also globale Sicherheitslücke das Internets und der Software dar. Das ist
nicht nur übertrieben, sondern auch schlichtweg falsch. Die News werden nur noch abgeschrieben und nicht mehr
überprüft. Recherche ist mittlerweile anscheinend ein Fremdwort für diese Redaktionen. Es wird reißerisch
Panik und Angst beim User geschürt, ohne auf die Fakten zu achten.
nicht nur übertrieben, sondern auch schlichtweg falsch. Die News werden nur noch abgeschrieben und nicht mehr
überprüft. Recherche ist mittlerweile anscheinend ein Fremdwort für diese Redaktionen. Es wird reißerisch
Panik und Angst beim User geschürt, ohne auf die Fakten zu achten.
Ja, auch ich wünsche mir mehr Präzision und Faktentreue in der Berichterstattung. Allerdings geht der "durchschnittliche" (Online-)Redakteur täglich unter in der Informationsflut und hat oft nicht die Zeit, bis in's kleinste Detail zu recherchieren. Zumal der "durchschnittliche" User selten bis gar nicht bereit ist, für gehaltvollere Informationen im Netz auch zu bezahlen.
Hi @Trontur,
1) Wir reden hier von einer einzigen Datenbank, nicht von mehreren. Mehrere Datenbanken wurden laut Dokumentation der Studenten nicht geprüft.
2) Per Default ist der Interfaceschutz bei der MongoDB an, d.h. der eine Admin, hat den Interfaceschutz aktiv herausgenommen. Warum - keine Ahnung.
3) Wenn ich den Passwortschutz der MySQL aktiv rausnehme, befinde ich mich im gleichen Zustand wie die MongoDB ohne Interfaceschutz.
4) Ich sehe da immer noch keine Sicherheitslücke vom Programm. Der Fehler liegt, wie so oft, beim User. Wenn man aktiv den Schutz einer Software heraus nimmt oder deaktiviert ist das gleich eine Sicherheitslücke in der Software? Die Logik dazu erschließt sich mir nicht.
5) Die hier so oft angesprochenen 40.000 Hosts sind reine Spekulation, es gibt mangels Prüfung keinen Beweis, dass diese ebenfalls betroffen sind oder keinen Schutz haben. Es ist ein simpler Portscan auf das "Vorhandensein" des MongoDB Ports. Es steht damit noch nicht einmal fest, das hinter dem Port wirklich eine MongoDB läuft.
"Falsch" sollten die Informationen dazu aber trotzdem nicht sein.
Gruß
Frank
Im aktuellen Fall scheint es aber doch so zu sein, dass die MongoDBs nicht (nur) am lokalen Interface angebunden, sondern von außen erreichbar sind, oder? Und wenn man ein DBMS ungeschützt öffentlich erreichbar macht, ist das für mich eine durch unprofessionelle Konfiguration erzeugte Sicherheitslücke.
1) Wir reden hier von einer einzigen Datenbank, nicht von mehreren. Mehrere Datenbanken wurden laut Dokumentation der Studenten nicht geprüft.
2) Per Default ist der Interfaceschutz bei der MongoDB an, d.h. der eine Admin, hat den Interfaceschutz aktiv herausgenommen. Warum - keine Ahnung.
3) Wenn ich den Passwortschutz der MySQL aktiv rausnehme, befinde ich mich im gleichen Zustand wie die MongoDB ohne Interfaceschutz.
4) Ich sehe da immer noch keine Sicherheitslücke vom Programm. Der Fehler liegt, wie so oft, beim User. Wenn man aktiv den Schutz einer Software heraus nimmt oder deaktiviert ist das gleich eine Sicherheitslücke in der Software? Die Logik dazu erschließt sich mir nicht.
5) Die hier so oft angesprochenen 40.000 Hosts sind reine Spekulation, es gibt mangels Prüfung keinen Beweis, dass diese ebenfalls betroffen sind oder keinen Schutz haben. Es ist ein simpler Portscan auf das "Vorhandensein" des MongoDB Ports. Es steht damit noch nicht einmal fest, das hinter dem Port wirklich eine MongoDB läuft.
Allerdings geht der "durchschnittliche" (Online-)Redakteur täglich unter in der Informationsflut und hat oft nicht die Zeit, bis in's kleinste Detail zu recherchieren. Zumal der "durchschnittliche" User selten bis gar nicht bereit ist, für gehaltvollere Informationen im Netz auch zu bezahlen.
"Falsch" sollten die Informationen dazu aber trotzdem nicht sein.
Gruß
Frank
4) Ich sehe da immer noch keine Sicherheitslücke vom Programm. Der Fehler liegt, wie so oft, beim User. Wenn man aktiv den
Schutz einer Software heraus nimmt oder deaktiviert ist das gleich eine Sicherheitslücke in der Software? Die Logik dazu
erschließt sich mir nicht.
Schutz einer Software heraus nimmt oder deaktiviert ist das gleich eine Sicherheitslücke in der Software? Die Logik dazu
erschließt sich mir nicht.
Wie bereits geschrieben neige ich zu der umfassenderen Definition, die im Wikipedia-Artikel aufgeführt ist:
"Sicherheitslücken entstehen unter anderem durch den unzureichenden Schutz eines Computers vor Angriffen aus dem Netz (beispielsweise mangels Firewall oder anderer Sicherheitssoftware) sowie durch Programmierfehler im Betriebssystem, Webbrowser oder anderen Softwareanwendungen, die auf dem System betrieben werden."
Wenn eine Datenbank im Internet hängt, deren möglicherweise sensible Datensätze durch fehlerhafte Konfiguration unautorisiert für potentiellen Missbrauch erreichbar sind, dann fällt das bei mir unter "unzureichender Schutz eines Computers vor Angriffen aus dem Netz" und ist damit eine Sicherheitslücke.
Es ist aber vollkommen OK, wenn wir nicht einer Meinung sind
Man kann das Kind nun nennen wie man will, eigentlich ist das völlig unwichtig. Vielleicht pass ja der Begriff "Sicherheitsproblem" besser. Das kann dann eine Sicherheitslücke z.B. durch ein Programmfehler sein, oder eine Konfigurationsproblem durch den Admin.
Wie auch immer, dass ist alles nur "Wortspielerei". Fakt bleibt: Die meisten Artikel zu diesem Sicherheitsproblem/dieser Sicherheitslücke sind einfach nur falsch und maßlos übertrieben. Das ganze Problem hat weder was mit der MongoDB Software zu tun, noch sind die hier genannt Zahlen bewiesen oder überprüft. Es ist nur "ein" einziges System, was den Beweis liefert. Das hier von den Studenten entdeckte Problem existiert bei jeder Datenbank, wenn sie falsch konfiguriert ist oder die Sicherheitsmechanismen ausgeschaltet wurden.
Richtig wäre aus meiner Sicht eine News wie z.B. "Französisches Großunternehmen hat ein großes Sicherheitsproblem: 8 Mio Kundendaten sind frei im Internet verfügbar - IT Admin schämt sich". Das wäre die Wahrheit und das wurde auch bewiesen (naja, bis auf das mit dem Admin).
Mittlerweile haben die mir bekannten Newsdienste ihren Titel übrigens angepasst und das Wort "Sicherheitslücke" herausgenommen. Leider sind die meisten News aber weiterhin falsch oder ungenau. Hier ein paar schöne Beispiele journalistischer Kunst:
so, genug. Ich denke jedem ist klar, was ich meine.
Gruß
Frank
Wie auch immer, dass ist alles nur "Wortspielerei". Fakt bleibt: Die meisten Artikel zu diesem Sicherheitsproblem/dieser Sicherheitslücke sind einfach nur falsch und maßlos übertrieben. Das ganze Problem hat weder was mit der MongoDB Software zu tun, noch sind die hier genannt Zahlen bewiesen oder überprüft. Es ist nur "ein" einziges System, was den Beweis liefert. Das hier von den Studenten entdeckte Problem existiert bei jeder Datenbank, wenn sie falsch konfiguriert ist oder die Sicherheitsmechanismen ausgeschaltet wurden.
Richtig wäre aus meiner Sicht eine News wie z.B. "Französisches Großunternehmen hat ein großes Sicherheitsproblem: 8 Mio Kundendaten sind frei im Internet verfügbar - IT Admin schämt sich". Das wäre die Wahrheit und das wurde auch bewiesen (naja, bis auf das mit dem Admin
).Mittlerweile haben die mir bekannten Newsdienste ihren Titel übrigens angepasst und das Wort "Sicherheitslücke" herausgenommen. Leider sind die meisten News aber weiterhin falsch oder ungenau. Hier ein paar schöne Beispiele journalistischer Kunst:
- Focus: "Datenbank-Fehler bei MongoDB" - ein Datenbank-Fehler? Wirklich? Eher ein Konfigurationsfehler, aber was solls.
- Focus: ".. darunter womöglich solche von Ebay, Expedia oder Foursquare." - liebes Focus Team, nur weil diese Firmen MongoDB benutzen, heißt das nicht automatisch, dass die Datenbanken dieser Firmen falsch konfiguriert sind. Genau das meinte ich mit Action-Journalismus.
- Focus: Hier noch ein angeblicher Satz von den Saarbrücker Forscher: "Halten sich die Betreiber bei der Installation blind an die Leitfäden und bedenken nicht entscheidende Details, stehen die Daten schutzlos im Internet" - Was sind denn die entscheidenden Details? Wer sich blind an das Handbuchs des Entwicklers hält (Betreiber?) hat einen Zugangsschutz für die MongoDB. Wäre dann das Detail, diesen Zugangsschutz auszuschalten? Fragen über Fragen schlagen bei diesem Beitrag auf mich ein .. (aua)
- FAZ: "... wegen eines Fehlers in einer Datenbank-Software gelesen und manipuliert werden." - sollte wohl eher ".. wegen eines Konfigurationsfehlers in einer DB" heißen. In der MongoDB Software selbst liegt das Problem nicht.
- FAZ: "..Rechtlich wäre es kritisch, in eine größere Anzahl von Datenbanken zu schauen, daher beschränkten sich die Studenten auf die Validierung ihrer Hypothese.." - steht nicht auf das Ausspähen von Daten hier in Deutschland 3 Jahre Haft und das egal ob mit einem oder mehreren Ausspähversuchen: § 202a. Die Formulierung finde ich sehr kritisch.
- n-tv: "Deutsche Studenten finden über eine Suchmaschine Zehntausende ungesicherte Datenbanken im Netz" - die Anzahl der ungesicherten Datenbanken wurde weder bewiesen noch gezählt.
- n-tv: "Die Lücke betrifft nach Erkenntnissen der Studenten am Kompetenzzentrum für IT-Sicherheit Cispa knapp 40.000 Datenbanken" - was wieder nicht bewiesen und reine Spekulation ist.
so, genug. Ich denke jedem ist klar, was ich meine.
Gruß
Frank
Tja, Action ist bei "Cyber" immer dabei. In der jüngsten Cyberwar-Doku fährt ein Pentester mit dem Kamerateam auf eine grüne Wiese, um "nach mehrstündiger Suche" auch nur ein Shodan-Ergebnis zu präsentieren. Ich finde es aber gut, mal die banalen Fehler eindrücklich (!) zu thematisieren, denn ich bezweifle, dass die größten Datenabflüsse auf Heartbleed und Co. beruhen.
Losgelöst vom konkreten Fall ist die Kernaussage "Millionen Kundendaten im Internet frei zugänglich" sicher nicht falsch. Die Studenten haben hier die Spitze des Eisbergs entdeckt. Wir entwickeln seit sechs Jahren Lösungen zur OSINT-Aggregation, und mein Eindruck ist, dass viele IT-Verantwortliche Daten für ausreichend geschützt halten, die sie nicht nach zwei Tagen über Google finden.
Um mal mein persönliches "Highlight" (das ich nennen kann) aus 2014, nur Deutschland, zu nehmen: Die Filiale einer überregionalen Wirtschaftsprüfungsgesellschaft bzw. ihr Dienstleister stellte ein komplettes Datenlaufwerk per FTP ins Netz (ich vermute zu Migrationszwecken).
Die Relevanz rein quantitativ zu beurteilen (ob eine oder 40.000 Datenbanken), ist nicht ganz einfach, denn typisch für solche Fehlkonfigurationen ist, dass sie meist relativ kurz erhalten bleiben. Das ist einerseits positiv, andererseits "rollt" das Phänomen damit durch verschiedene Datenbestände. Eine Konfiguration, die sich der sorglose IT-Dienstleister für wenige Tage erlaubt, reicht in jedem Fall, um z.B. ein Jahrzehnt archivierte Buchführung zu finden und herunter zu laden (die besagte Kanzlei hatte es auch auf populäre FTP-Suchmaschinen geschafft). Der Anteil der von Fehlbedienung Betroffenen an den Nutzern einer bestimmten Lösung ist daher bei der Betrachtung über einen längeren Zeitraum deutlich höher als es die Momentaufnahme dieses Dienstes vermuten lässt.
Was die rechtliche Seite angeht: § 202a StGB setzt eine Zugangssicherung voraus. Beim Betrachten von Daten, die erkennbar unfreiwillig veröffentlicht sind, stellen sich m.E. datenschutzrechtliche Probleme, die davon abhängen, wann ich das erkenne bzw. ob ich von vornherein nach solchen Daten gesucht habe. Das Vorgehen der Studenten ist daher schon plausibel.
Grüße
Richard
Losgelöst vom konkreten Fall ist die Kernaussage "Millionen Kundendaten im Internet frei zugänglich" sicher nicht falsch. Die Studenten haben hier die Spitze des Eisbergs entdeckt. Wir entwickeln seit sechs Jahren Lösungen zur OSINT-Aggregation, und mein Eindruck ist, dass viele IT-Verantwortliche Daten für ausreichend geschützt halten, die sie nicht nach zwei Tagen über Google finden.
Um mal mein persönliches "Highlight" (das ich nennen kann) aus 2014, nur Deutschland, zu nehmen: Die Filiale einer überregionalen Wirtschaftsprüfungsgesellschaft bzw. ihr Dienstleister stellte ein komplettes Datenlaufwerk per FTP ins Netz (ich vermute zu Migrationszwecken).
Die Relevanz rein quantitativ zu beurteilen (ob eine oder 40.000 Datenbanken), ist nicht ganz einfach, denn typisch für solche Fehlkonfigurationen ist, dass sie meist relativ kurz erhalten bleiben. Das ist einerseits positiv, andererseits "rollt" das Phänomen damit durch verschiedene Datenbestände. Eine Konfiguration, die sich der sorglose IT-Dienstleister für wenige Tage erlaubt, reicht in jedem Fall, um z.B. ein Jahrzehnt archivierte Buchführung zu finden und herunter zu laden (die besagte Kanzlei hatte es auch auf populäre FTP-Suchmaschinen geschafft). Der Anteil der von Fehlbedienung Betroffenen an den Nutzern einer bestimmten Lösung ist daher bei der Betrachtung über einen längeren Zeitraum deutlich höher als es die Momentaufnahme dieses Dienstes vermuten lässt.
Was die rechtliche Seite angeht: § 202a StGB setzt eine Zugangssicherung voraus. Beim Betrachten von Daten, die erkennbar unfreiwillig veröffentlicht sind, stellen sich m.E. datenschutzrechtliche Probleme, die davon abhängen, wann ich das erkenne bzw. ob ich von vornherein nach solchen Daten gesucht habe. Das Vorgehen der Studenten ist daher schon plausibel.
Grüße
Richard
1
