Kommentare zu folgendem Beitrag: Der DeepSeek-Leak: Nutzerdaten und API-Schlüssel ungeschützt im Netz
Unklar ist jedoch, wie lange die Daten bereits frei zugänglich waren.
Clickhouse ist ein Open-Source-System für das Spaltendatenbankverwaltungssystem für schnelle Analyseabfragen in großen Datensätzen. Es wurde von Yandex entwickelt und wird häufig für die Echtzeitdatenverarbeitung, die Protokollspeicherung und die Big-Data-Analyse verwendet, was eine sehr wertvolle und sensible Entdeckung angibt.
Durch die Nutzung der HTTP -Schnittstelle von Clickhouse haben wir auf den /Play -Pfad zugegriffen, der die direkte Ausführung willkürlicher SQL -Abfragen über den Browser ermöglichte. Ausführen einer einfachen „show table“- Query gab eine vollständige Liste der zugänglichen Datensätze zurück.
Unter ihnen stach eine Tabelle heraus: log_stream, die umfangreiche Protokolle mit hochempfindlichen Daten enthielt .
Die Tabelle log_stream enthielt über 1 Million Protokolleinträge mit besonders enthüllten Spalten:
-
Zeitstempel - Protokolle aus dem 6. Januar 2025 !!!
-
span_name - Verweise auf verschiedene interne Deek -API -Endpunkte
-
String.Values - PlainText -Protokolle , einschließlich Chat -Historie , API -Schlüssel, Backend -Details und operative Metadaten
-
_Service - Zeigt an, welcher Deepseek -Dienst die Protokolle generiert hat
-
_Source - Enthüllung des Ursprungs von Protokollanforderungen , enthält Chat -Verlauf, API -Schlüssel, Verzeichnisstrukturen und Chatbot -Metadatenprotokolle
Demnach standen die frei zugänglichen Datenbanken mindestens seit 3,5 Wochen so im Internet!!
23 Tage sind in der IT wohl eher als kleine Ewigkeit zu bezeichnen!!
Allerdings wie immer muss man sowas erstmal finden.
Interessant fand ich eher das „Sicherheitsberatungsfirmen“ da gleich erstmal das große Hacken angefangen haben als die Deepseek News kam.
Mietet uns wir wissen wie sicher geht.
Typischer Anfängerfehler alles mögliche in Logdateien zu schreiben.
Wieso die Datenbank ungeschützt war wundert mich auch etwas und wieviel Schuld hat dabei der Anbieter? Wird imo zu selten hinterfragt.
Reihenweise findet man immer wieder offene Cloud Datenbanken.
Sollte im Benutzer Interface gar nicht möglich sein die offen zu schalten.
Das ist mal wieder ganz großes Kino. Entwickler halten sich gerne einmal für Götter der IT. Verstehen Code aber nicht das Backend dahinter und genau das wird hier auch gelaufen sein.
Dev kann coden hat aber von Security 0,00% Ahnung im Thema Backend Security.
Habe es selbst schon x-mal erlebt. Ich habe auch schon mit Möchtegern Hardcore Webentwicklern Diskussionen zum Thema XSS etc. Führen müssen. Und warum der DB Port nach extern ebenso wie SSH und FTP weitergeleitet werden sollten. Die installieren sich da irgend eine Kiste und legen los.
Schlampig…einfach nur schlampig.
Allerdings muss man sagen das Cloud maximal intransparent ist.
Bei einer DB auf Linux reichts einen Port zu sperren. Bei Cloud eben nicht. Da muss der Zugriff zwischen Apps gewährleistet sein die aber auf unterschiedlichen Rechnern laufen. Deshalb sag ich, die Konfigurationslösungen der Anbieter müssen sicher sein.
Aber zwischen „sollte“ und „ist“, gibt es halt genügend Spielraum! 
Ich erinnere mich noch an den Vorfall mit Elasticsearch / Kibana, bei dem das Netz voll war mit offenen DBs. Damals war das durch simple Benutzerfehler vonstatten gegangen.
Da war irgendwas, dass man beim Abspeichern seiner Arbeiten im CP einen Haken entfernen musste, anstatt einen zu setzen, was von vielen Admins schlichtweg nie gesehen wurde und somit dauernd offen im Netz abgelegt wurde!
Den Punkt das Apps Zugriff auf den internen Port der Datenbank benötigen, ist doch kein Argument. Das regelt man heutzutage mit API Zugriffen. Und da lag hier ja das Problem…Ich habe lediglich darauf hingewiesen wie schlampig man mit dem Thema IT-Security generell umgeht.
Das liegt m,ittlerweile auch oft daran, da viele der genutzten Tools eine eierlegende Wollmilchsau sind. Der Admin oder sein Hilfssheriff brauchen von den 85 Features aber nur eins oder zwei für ihre Aufgaben! Die anderen 83 Funktionen werden nicht beachtet und werden in der Standard-Konfiguration einfach mitgeschleppt. Tjaaa, nun kommts drauf an, was der Tool-Dev als Stasndardwerte jeweils gesetzt hatte…Haken rein, Haken raus war ja das Elasticsearch-Argument!!
Vor allem ist bei Firmern eine VPN-Verbindung über die eigene FW-Appliance heutzutage noch Standard, um ins eigene Netz zu kommen. Zwei Zugriffspunkte vorne und hinten mit nem Tunnel. Na…ich würde einfach vor dem Eingang oder hinter dem Ausgang auf den Kollegen Schnürschuh warten und dort die Daten abgreifen bzw. den Übergabepunkt für meinen Payload setzen!
Bitkom hatte mal ermittelt, dass diese Art der Firmenzugänge in über 45% falsch oder unzureichernd konfiguriert sind. Nach dem Motto, fällt erst auf, wenn die Gateprotect getasuscht werden muss… 
1 „Gefällt mir“
Das hast du auch was falsch gelesen. Ich sagte ja das das in der Cloud nicht der Fall ist, mit dem Port.
Und da lag hier ja das Problem…Ich habe lediglich darauf hingewiesen wie schlampig man mit dem Thema IT-Security generell umgeht.
Naja du hast auf den Entwickler gezeigt. Und ich meinte die Konfiguration sollte passiv sicher sein, sprich durch den Anbieter, weil komplex und intransparent.
Verstehen Code aber nicht das Backend dahinter
Das Backend in der Cloud ist für den Entwickler eine Blackbox. Noch dazu kann sich das dauernd ändern. Es ist eigentlich grad der Sinn der Cloud damit nichts ! zu tun zu haben.
1 „Gefällt mir“