Im Januar 2017 wurde das sehr beliebte MongoDB Opfer einer Angriffstaktik, die für Angreifer mittlerweile recht vorhersehbar zu sein scheint: der Geiselnahme von Daten. Bei der anschließenden Untersuchung des Angriffs stellte sich heraus, dass die Angreifer größtenteils … nichts ausgenutzt hatten. Das Problem lag nicht an der Software, sondern an der Konfiguration. Die Standardkonfiguration , die größtenteils auf AWS ausgeführt wird, ließ die Datenbanken für jeden mit einer Internetverbindung zugänglich.
Hierzu zählte auch das mittlerweile berüchtigte CloudPets-Drama , bei dem (als privat geltende) Sprachnachrichten zwischen Kindern und ihren Eltern öffentlich für jeden zugänglich waren, der versiert genug war, sich entweder Zugang zur Datenbank (einer ungesicherten Instanz von MongoDB) zu verschaffen oder die Architektur der App und ihre Verwendung von Amazon S3 zu verstehen. Cloud Pets nutzte S3 zum Speichern von Profilbildern und Sprachaufzeichnungen und verzichtete dabei offenbar auf jegliche Art von Sicherheit, sodass diese für jeden mit der entsprechenden Referenz zugänglich waren.
Damit Sie nicht denken, ich hätte es auf CloudPets abgesehen, möchte ich darauf hinweisen, dass das RedLock CSI-Team kürzlich herausgefunden hat, dass „82 % der Datenbanken in öffentlichen Cloud-Computing-Umgebungen wie Amazon Relational Database Service und Amazon RedShift nicht verschlüsselt sind.“
[dramatische Pause]
Darüber hinaus „akzeptierten 31 % dieser Datenbanken eingehende Verbindungsanfragen aus dem Internet.“
Ich möchte außerdem darauf hinweisen, dass in den ersten Januarwochen 2017 über 27.000 MongoDB-Server kompromittiert wurden. Weit mehr als CloudPets wurde von diesem Vorfall durch die eigenen mangelhaften Sicherheitspraktiken getroffen. In einem Blog von MongoDB hieß es bei Bekanntwerden der ersten Angriffe: „Diese Angriffe sind durch die umfassenden Sicherheitsvorkehrungen, die in MongoDB integriert sind, vermeidbar .“ Sie müssen diese Funktionen richtig verwenden und unsere Sicherheitsdokumentation hilft Ihnen dabei. [Hervorhebung von mir]“
MongoDB war nicht unsicher, es war einfach überhaupt nicht sicher. Das Problem liegt nicht wirklich beim Produkt, sondern an den schlechten Praktiken derjenigen, die IoT und mobile Apps schnell über die Cloud in die Hände der Verbraucher bringen wollen.
Im Rechenzentrum – vor Ort – gibt es sowohl physische (Firewalls usw.) als auch betriebliche (Prozesse und Genehmigungen) Tore, die passiert werden müssen, bevor die Software auf die Welt losgelassen und zum Bereitstellen von Daten verwendet wird. Die Cloud verfügt konzeptbedingt über weniger physische Tore und – wie es leider oft den Anschein macht – weniger betriebliche Tore, die Apps passieren müssen, bevor sie der breiten Öffentlichkeit zugänglich gemacht werden. Die Reduzierung der operativen Tore ist der eigentliche Ausgangspunkt des Konzepts „Rogue-IT“ oder „Schatten-IT“. Die Beteiligten in den Geschäftsbereichen waren frustriert über die langen Vorlaufzeiten und Projektlaufzeiten, die sich über Jahre statt Monate erstreckten. Ursprünglich begannen sie, auf die Cloud umzusteigen, um die IT zu „umgehen“. Das bedeutete allerdings, dass sie auch die Betriebsschranken umgingen, die eingerichtet worden waren, um die Sicherheit und Leistung dieser Anwendungen zu gewährleisten.
Das ist kein Problem der Cloud, sondern ein Problem derjenigen, die die Cloud einführen. Denn es ist nicht nur die Masche, die uns seit zehn Jahren aufgetischt wird: „Die Bereitstellung der physischen Hardware dauert zu lange“, sondern auch die Masche: „Die IT-Genehmigungsprozesse dauern zu lange“, die den Geschäftspartnern, die einfach jetzt vor der Konkurrenz auf den Markt kommen wollen, wirklich auf die Nerven geht.
Dies wird durch die Teilnehmer einer 2017 von Arxan/IBM gesponserten Umfrage zum Thema Mobile- und IoT-Sicherheit bestätigt. Als Grund für die mangelnde Sicherheit von IoT- und Mobil-Apps nannten die Befragten den Druck auf die App-Entwicklungsteams. 69 % nannten die überstürzte Entwicklung von Mobil-Apps als Ursache für anfälligen Code und 75 % sagten dasselbe für IoT-Apps.
Derselbe Druck gilt auch für die Einrichtung und Sicherung der Datenbanken und des Cloud-Speichers, die die Dinge überhaupt erst nutzbar machen. Die gesamte Prämisse von Cloud Pets basiert nicht auf dem Spielzeug, sondern auf der Fähigkeit des Spielzeugs, Daten über das Internet zu senden und zu empfangen. Das heißt, sein Erfolg beruht darauf, dass eine dieser IoT-Apps so schnell wie möglich entwickelt und in der Cloud bereitgestellt wird, damit sie rechtzeitig zum Weihnachtstag erscheinen kann.
Entwickler sind nicht die einzigen, die für die Sicherheit der von ihnen bereitgestellten Anwendungen verantwortlich sind. Wer für die Bereitstellung der Cloud-Dienste zur Unterstützung dieser App verantwortlich ist – ob Datenbank, Dateifreigabe oder App-Dienste im Allgemeinen – muss einen Teil der Verantwortung für deren Sicherheit übernehmen. Das Gleiche sollten auch die Geschäftspartner tun, indem sie unrealistische Fristen setzen und minimale operative Verzögerungen bei der endgültigen Lieferung anstreben.
Ja, die IT muss die digitale Transformation annehmen und die betrieblichen Abläufe optimieren, die zu einer erfolgreichen – und sicheren – Produktlieferung an die Verbraucher führen. Doch Unternehmen und Entwickler können diese operativen Schleusen in der Cloud nicht einfach weiter umgehen und nicht nur die Verbraucher, sondern auch die Stakeholder in Unternehmen durch schäbige Sicherheitspraktiken, die auf „Standard“-Konfigurationen beruhen, gefährden. Dabei geht es nicht so sehr um Produkte als vielmehr um Prozesse. Es geht darum, sicherzustellen, dass Richtlinien umgesetzt und Konfigurationen korrekt sind, bevor Apps – und ihre Benutzer – vermeidbaren Angriffen ausgesetzt werden.
Wenn Sie einen peinlichen Zwischenfall vermeiden möchten, müssen Sie zunächst einige grundlegende Sicherheitsvorkehrungen treffen, indem Sie zumindest einige grundlegende Betriebskontrollen definieren (und durchsetzen), die vor der Markteinführung passiert werden müssen.
Unternehmen sind auf diese operativen Tore mehr denn je angewiesen, da die Migration produktivitäts- und gewinnsteigernder Apps in die öffentliche Cloud immer schneller voranschreitet. Und mit der zunehmenden Migrationsgeschwindigkeit steigen auch die Möglichkeiten für Angreifer, diese Risiken auszunutzen.