Ein Logbuch:Spezial zur letzten dicken Sicherheitslücke in der Luca App
Ja, wir können es ja auch nicht mehr hören, aber um der Chronistenpflicht gerecht zu werden, müssen wir halt ein weiteres darstellen, warum die Luca App nicht nur aus prinzipiellen Gründen (hilft nicht bei der Bekämpfung der Pandemie) sondern auch wegen konkreter Sicherheitsmängel nicht die Karte ist, auf die wir setzen sollten. Wir sprechen heute mit Markus Mengs, der sich die "Integration" der Luca App mit den Gesundheitsämtern mal genauer angeschaut hat und ein paar schaurige Entdeckungen gemacht hat.
Für diese Episode von Logbuch:Netzpolitik liegt auch ein vollständiges Transkript mit Zeitmarken und Sprecheridentifikation vor.
Bitte beachten: das Transkript wurde automatisiert erzeugt und wurde nicht nachträglich gegengelesen oder korrigiert. Dieser Prozess ist nicht sonderlich genau und das Ergebnis enthält daher mit Sicherheit eine Reihe von Fehlern. Im Zweifel gilt immer das in der Sendung aufgezeichnete gesprochene Wort. Formate: HTML, WEBVTT.
Transkript
Shownotes
Prolog
- songtexte.com: Songtext von Die Fantastischen Vier – Das letzte Mal Lyrics
Feedback
- logbuch-netzpolitik.de: Kommentar von Ekkehard
- logbuch-netzpolitik.de: Kommentar von Dr.-Ing. Düsentrieb
Vorstellung Mame82
Vorgeschichte Luca
Umgang mit Theresa Stadler
- arxiv.org: [2103.11958] Preliminary Analysis of Potential Harms in the Luca Tracing System
- twitter.com: Tweet von annalist
- hz.de: Leserbrief: Luca-App mit erheblichen Sicherheitsrisiken
Luca-Probleme
- ccc.de: CCC | Luca-App: CCC fordert Bundesnotbremse
- zeit.de: Ulrich Kelber: “Gesundheitsämter wollen nicht überhäuft werden mit Daten”
- digikoletter.github.io: Gemeinsame Stellungname zur digitalen Kontaktnachverfolgung
Video-Serie
Tracking
- lucatrack.de: LucaTrack
- lucatrack.de: Presseinfo
- youtube.com: 07/10 Rekonstruktion Bewegungsprofile: Analyse der Kommunikation (vor Check-In) – YouTube
Schlüssel-Anhänger: LucaTrack II
- youtube.com: 12 Luca: Sicherheitslücke in Schlüsselanhängern erlaubt unbemerkte Manipulation fremder Kontaktdaten – YouTube
- youtube.com: Neue Luca Lücke: Fremde Schlüsselanhänger einchecken, Kontakdaten für Gesundheitsamt beliebig ändern – YouTube
Code Injection
- youtube.com: Luca App: Nutzer greift Gesundheitsamt an und stiehlt Daten bevor er Ransomware schickt – YouTube
Vorgeschichte
Wie genau funktioniert der Angriff?
- youtube.com: 36C3 – Hirne Hacken – YouTube
Presseberichte
- zeit.de: Luca-App: Hacker können Gesundheitsämter über die Luca-App angreifen
- br.de: Erneut Sicherheitslücke bei Luca-App | BR24
- spiegel.de: Luca-App bereitet Hackern den Weg in die Gesundheitsämter – Sicherheitslücke vorgeführt – DER SPIEGEL
Reaktion von Luca
- twitter.com: Tweet von Linuzifer
- twitter.com: Tweet von Linuzifer
- luca-app.de: Hinweis auf einen potentiellen Missbrauch des luca-Systems – luca
Reaktion Community
- twitter.com: Tweet von Peng
- linksfraktion.de: Gravierende Luca-App-Sicherheitslücke wird zur Gefahr für Gesundheitsämter – Fraktion DIE LINKE. im Bundestag
- twitter.com: Tweet von FBeye71
- twitter.com: Tweet von Linuzifer
- twitter.com: Tweet von metronaut
- twitter.com: Tweet von Linuzifer
- twitter.com: Tweet von Linuzifer
- twitter.com: Tweet von Linuzifer
- twitter.com: Tweet von WeingutSanders
- twitter.com: Tweet von hmans
Empfehlungen
- twitter.com: Tweet von CYxChris
- twitter.com: Tweet von andreasdotorg
Hi, long time listener and first time commenter ;) Ihr haut ja echt raus. Vielen Dank für die vielen hochwertigen Podcasts :)
lieber linus liber timmy
die folgen mit gaesten immeerr ein genuss
dsnke
Zu der Luca CSV Injection
Ihr sagt ja, luca sollte die Daten prüfen bevor sie in die Datenbank geschrieben werden. Ich bin mir nicht sicher, ob ich das richtig verstanden habe, aber diese Daten (Name, PLZ, usw) werden doch lokal vom Nutzer verschlüsselt richtig? Wie würde man dann die Prüfung dieser Daten sinnvoll ohne Entschlüsselung durchführen?
Man könnte z.B. einen Verschlüsselungsalgorithmus verwenden, der nur auf alphanumerischen Zeichen funktioniert, statt auf ASCII. Aber da müssten die ja nachträglich ihren kompletten crypto stack anpassen. Was wäre so die beste Lösung für dafür?
Und natürlich kann man dann auf der Seite der Entschlüsselung beim Gesundheitsamt relativ easy prüfen, aber ich hatte euch jetzt schon so verstanden, dass es eigentlich so sein müsste, dass die API solche Daten gar nicht erst annimmt.
Die Validierung muss einfach lokal in der App (vor der Verschlüsselung) passieren.
Das hilft nicht, weil der Server nicht prüfen kann, ob das, was du ihm da schickst, „validiert“ ist.
Das muss zwischen Entschlüsselung und Erstellung der CSV-Datei geschehen.
Doch das hilft, denn das verhindert erst mal das Problem an der Quelle. Wenn du das umgehen willst, muss ein deutlich höhrer Aufwand betrieben werden.
Was du vorschlägst ist natürlich zusätzlich sinnvoll, wenn nicht sogar die wichtigere Stelle.
Was mich aber auch zu der Frage bringt: Wie bitte soll das wirksam Ende-zu-Ende-verschlüsselt sein, wenn das auf den Servern vom Hersteller entschlüsselt wird? Dann haben die doch da Zugriff auf die Daten und mitnichten nur die Gesundheitsämter. Oder habe ich hier einen Denkfehler?
Ich meinte aufgeschnappt zu haben, dass die Entschlüsselung im Browser des Gesundheitsamts stattfindet.
Meine Vermutung ist, dass auch dort erst die CSV-Datei für den Download generiert wird.
Der Aufwand für das Umgehen ist eben nicht besonders hoch, weil ich, anstatt die manipulierten Kontaktdaten mit der App zu verschlüsseln und abzuschicken, das auch mit jedem anderen Tool machen kann – und dann kann da eben auch alles mögliche drinstehen.
(Deshalb ist die Antwort mit „React“ auch so lustig, weil das vermutlich nur eine Validierung bei der Eingabe per App ist.)
Wenn du in deiner Applikation Daten verarbeitest, die von außen kommen (input), um sie dann wieder auszugeben (output, verschieden je nach Ausgabekontext z.B. HTML, Filedownload etc), musst du für security folgendes tun:
1) Input validieren (an der Stelle an dem du den Input kontollierst)
2) Output encoden/escapen (um unerwünschte Interpretation im Zielcontext zu vermeiden, z.B. Auslösen von Aktionen im Parser der den Output verarbeitet)
Am Beispiel Luca (ich beschränke mich auf Postleitzahl als Input und CSV als Ausgabe Kontext … bsp für weiteren Ausgabekontext wäre HTML zur Darstellung im Frontend):
Der Input (Postleitzahl) kann z.B. validiert werden, indem man prüft, dass Eingabedaten nur 5-stellige Ziffern sind (semantik). Man könnte auch prüfen, ob die Postleitzahl überhaupt gültig ist (in Deutschland vergeben, im System nutzbar etc).
Wo die Input Validierung stattfinden muss dürfte auch klar sein. Könnte man in der App machen, dann kann sie aber vom Nutzer umgangen werden, bevor die Daten verschlüsselt werden. Luca hat hier erst im Frontend des Gesunheitsamtes die Kontrolle, nachdem die Daten entschlüsselt wurden. Dort prüfst du also ob die Postleitzahl eine Postleitzahl ist.
Dann kommt der Output, in diesem Fall CSV. Hier musst du also alles encoden/escapen was im Kontext von CSV anders interpretiert werden könnte, als eine Postleitzahl (die Input Valudierung hat dass sogar schon weitestgehend gemacht). Trotzdem musst du dich fragen, ob die PLZ dann als Zahl mit führenden Nullen oder doch lieber als String in die CSV Datenzelle soll. Nehmen wir mal an es soll ein String werden, dann sorgst du z.B. dafür, dass Zeichen die den String in CSV terminieren (“ oder ‚) escaped werden, so dass sie nicht als Steuerzeichen interpretiert werden (von CSV parsen). Das gleiche würdest du z.B. mit Zeichen tun, die neue Zellen öffnen neue Tabellenzeilen anfangen usw usw
So macht man das, wenn man nicht Luca entwickelt
Also ich hätte nen Vorschlag, wie sich das Problem fixen liesse: Nexenio druckt die Daten einfach aus und faxt sie ans Gesundheitsamt, wo sie dann wieder abgetippt werden :-P
Ihr habt es mehrfach angerissen, aber ich denke es ist hilfreich sich nochmal vor Augen zu führen, das es beim ‚Sanitizen‘ von Daten zwei Aspekte gibt. Einer für Datenqualität, einer für Sicherheit bei der Ausgabe.
Validität: Machen die Daten Sinn? z.B. eine PLZ ist ein String aus 5 Zahlen, das Geburtsdatum ein parsebares Datum in der Vergangenheit, eine spezifische Text-Beschreibung hat max. 200 Zeichen, … All das macht man typischerweise beim Input, um fehlerhafte Eingaben gleich zu erkennen und den User darauf hinweisen zu können (das ist ja i.d.R. keine Absicht). Außerdem sollen Daten ja ggf. in einer Datenbank schon in bestimmten Formaten gespeichert werden (als Integer, Datetime, …), um damit sinnvoll arbeiten zu können, wozu sie ohne Verlust der Information interpretiert/transformiert werden sollen.
Escaping/Encoding: Wie müssen die Daten im spezifischen Kontext aufbereitet werden, um korrekt verstanden zu werden? Das passiert dann typischerweise beim Output, weil nur da der Kontext bekannt ist. Dieselben (!) Daten können – unbearbeitet – im einen Kontext gefährlich, im anderen valide Information sein. Im Fall von Luca denke man z.B. an HTML (Dinge, die im Browser angezeigt werden) und CSV (Dinge, die in Excel angezeigt werden).
Natürlich sind die Angriffe auf das, was beim Output passiert, deutlich erschwert, wenn der Input schon auf valide Daten beschränkt wird. Aber zum einen gibts valide Fälle für breiten Input, zum anderen ist es nie hinreichend.
(Ich weiß, ihr wollt die Entwickler nicht mit dem Fingerpointing auf Excel davon kommen lassen – ich auch nicht.)
Ich höre gerade zum ersten mal von CSV Injections in Excel und bin – mal wieder – entsetzt über dieses „Feature“. (Microsoft-Bashing entfernt, s.u.) Ich empfinde schon das Auswerten von (ungefährlichen) Formeln beim Darstellen von CSV-Inhalten als Bug.
Wie kommt man darauf, in einem solchen allgemein verwendeten Format davon auszugehen, der Inhalt könne überhaupt Excel-spezifische Syntax enthalten, die als solche beabsichtigt ist?
(Ich entschärfe meinen Beitrag gerade ein wenig, weil LibreOffice das genauso handhabt.)
Es hat wohl einen Grund, dass diese Lücke im xlsx-Format nicht funktioniert. Werden die Zellen dort als „keine Formel“ markiert, oder hat man bei Luca in diesem Format daran gedacht, Formeln zu escapen? Oder hat man zum Generieren der xlsx-Files ein Tool genutzt, dass das (zufällig) automatisch richtig macht?
Eure Zwischenbemerkung zum undefinierten Ziel der LucaApp fand ich nochmal äußerst erhellend und bemerkenswert konstruktiv.
Man hätte das Feature „Gästeliste“ (ohne Verifikation) ganz leicht abbilden können. (App zur Generierung eines QR-Codes mit Kontaktdaten, dieser wird am Eingang gescannt und lokal gespeichert.)
Man hätte verifizierte Kontaktdaten leicht abbilden können: Signatur vom Bürgerbüro drauf. Will man verhindern, dass Leute fremde Handys vorzeigen, muss man ein Foto integrieren oder Ausweise abgleichen. (Wobei der Angriff, die Daten einer anderen, vertrauten Person zu hinterlegen, schon relativ unwahrscheinlich ist.)
Den als Vorteil zur Corona-Warn-App beworbenen „Zwang“ zur Teilnahme mit korrekten Daten hätte man übrigens auch so gehabt.
Den ganzen Ärger hat man sich eingetreten, weil die Daten einerseits über den Server laufen müssen, dann aber E2E-verschlüsselt sein sollen, um die Datenschutz-Probleme zu beheben.
Jede Form der Verifikation kann damit nur noch beim User (also dem Angreifer) oder dem Gesundheitsamt stattfinden. Und damit fällt schon mal die wirkliche Verifikation weg.
Einfacher Test für alle diese Systeme, den man ganz ohne technisches Verständnis selbst machen kann (gilt auch für Tickets, Fahrscheine auf dem Handy etc.):
Kann ich ein fremdes Handy vorzeigen, und was passiert dann?
Eine sehr interessante Sendung über weitere Schwachstellen von Luca. Das gesamte Projekt Luca scheint mir eine einzige Farce zu sein. Angefangen von qualitativ schlechter Programmierung, deren Schicksal schon durch eine unsaubere Konzeptionierung gesegnet war, bis zu einem schon schockierenden Umgang von neXenio, die jegliche Warnmeldung ignorierten und verharmlosten.
Markus Mengs und vielen anderen Person muss man in diesem Zusammenhang danken, dass sie wertvolle Zeit aufbringen und sich für IT-Sicherheit einstzen. Einen kleinen Kritikpunkt an Herrn Mengs und seiner gesamten Ausführung. Während seiner Ausführung ist es mir mehrmals schwer gefallen, zu folgen, weil er mit Sprüngen zu schnell im Detail ist und der Weg unklar. Anders: er ist nicht der geborene Erklärer für die Masse ;-)
Bleibt gesund!
Die Frage die sich mir stellt ist: Was soll denn das Gesundheitsamt tun, wenn diese Warnung aufploppt? Die Datei nicht öffnen? Dann können Sie ihre Arbeit nicht tun und die Leute nicht warnen/informieren! Das Gesundheitsamt hat schlicht und ergreifend keine Wahl!
Die Schuld liegt hier ganz klar bei der Luca-App bzw. deren Hersteller, die allein tragen die Verantwortung für dieses Problem.
Ich finde die Kritik an der Aussage der Luca-Entwickler*innen zu Luca-App Sicherheitslücken teilweise etwas undifferenziert. Ich teile den Ärger über die öffentliche Kommunikation und das offensichtliche (ja wirklich dilettantische Anfänger*innen-) Fehler gemacht wurden, wie die fehlende Validierung der Nutzerdaten (wenn wie in anderen Kommentaren angemerkt auch nicht so einfach umsetzbar bei verschlüsselten Daten)
ABER: Die Möglichkeit der Remote Code Execution durch Einfügung von Excel-Formeln nicht als Sicherheitslücke zu bezeichnen (und den Entwickler*innen der Luca-App hier alleine die Schuld zuzuschieben) halte ich für unsachlich (no offense!), denn eine Remote Code Execution Schwachstelle in einem Tabellenkalkulationsprogramm ist sehr wohl eine (wie ich finde eklatante) Sicherheitslücke (wieso müssen Formeln zur Kalkulation von Summen etc. Random Code ausführen können?!) und hier sehe ich die Schuld unabhängig ob die Luca-Entwickler*innen selber eine Schwachstelle in ihrer App haben (was sie haben), bei den Entwickler*innen von Microsoft Excel.
Lange Rede kurzer Sinn: Insofern ist die Aussage von Luca, dass es sich dabei (auch) um eine Schwachstelle in Microsoft Excel handelt nicht 100%ig falsch.
Viele Grüße Seb
Das sehe ich anders. Wenn du mit deiner Software eine andere bespielst, die dein Kunde dann verwendet, dann hast du dafür sorge zu tragen, dass die übergebenen Daten dem gewünschten Anwendungszweck entsprechen. Im Gegensatz zum Endkunden kann und muss man vom Entwickler erwarten, dass er sich mit den Problemen eines solchen Kontextwechsels beschäftigt. Die Validierung von Eingaben ist auch keine Kür sondern Pflichtprogramm.
Ich denke, dass Microsoft den ganzen Spaß als Feature und nicht als Schwachstelle sieht. Der Nutzer wird ja schließlich gefragt. Wie willst du hier den schwarzen Peter weiter schieben?
Zum ersten Punkt: Ich habe nie etwas anderes behauptet und habe mehrmals darauf hingewiesen, dass ich dies auch als Schwachstelle sehe. Bitte nochmal genau lesen.
Zum zweiten Punkt: Schon klar das Microsoft das Feature sieht, ändert aber nichts daran, dass es eine unnötige Schwachstelle ist.
Der Aussage meines Postings war aber der, dass diese beiden Punkte trotzdem unabhängig sind.
Ich denke ich habe dich schon richtig verstanden, mein erster Absatz läuft aber darauf hinaus, dass die App-Entwickler für das Sicherheitsproblem verantwortlich sind und eben nicht Microsoft. Es hilft hier auch nichts auf Microsoft zu zeigen, denn die können das Problem im Gegensatz zu den Luca-Leuten nicht einfach beheben.
Meine Aussage ist, dass man es gar nicht unabhängig betrachten muss, da das Problem ganz klar durch Luca ermöglicht wird. Die Schwäche von Excel war schon vorher bekannt und wäre auch mit einer neuen Version nicht zu beheben, denn die müsste erst mal in allen Gesundheitsämtern ankommen. Dazu kommt, dass andere Tabellensoftware offenbar ähnlich arbeitet, also ist das Verhalten vermutlich beabsichtigt und kein ungewolltes Fehlverhalten.
Es ist schon richtig hier mit dem Finger nur auf Culture4life/Nexenio zu zeigen, denn das Problem ist schon lange bekannt und wäre einfach zu verhindern gewesen. Wer für diese Programme exportiert muss das auf dem Schirm haben.
Okay, ich denke hier kommen wir mit unseren Meinungen nicht auf einen gemeinsamen Nenner. Denn ich sehe es schon so, dass Microsoft dafür verantwortlich ist, dass ich Programmcode durch Formeln ausführen lassen kann und ich hoffe doch sehr dass die Einschätzung ob etwas eine Sicherheitslücke ist oder nicht in Zukunft nicht davon abhängig gemacht wird, ob die Entwickler*innen des Programms dies selber als Schwachstelle ansehen (das war nämlich die Kritik an Lucas Statements mit unter). Es ist daher ein schwaches Argument zu sagen, solange Microsoft dies nicht als Schwachstelle ansieht oder weil viele Programme es so machen, ist es keine Sicherheitslücke. Selbst wenn es ein beabsichtigtes Verhalten ist, kann es trotzdem eine (in meine Augen unnötige) Sicherheitslücke sein. Erinnert mich stark an Internet Explorer und Active X Zeiten.
Zitat:
> Meine Aussage ist, dass man es gar nicht unabhängig betrachten muss, da das Problem ganz klar durch Luca ermöglicht wird.
Das Problem der Remote Code Ausführung wird allgemein durch Microsoft ermöglicht. Das dies genau in diesem Fall auftritt ist die Kombination aus der Schwachstelle in Luca und der in Excel. Gäbe es einer dieser beiden Probleme nicht, wäre das Problem nicht aufgetreten, denn es lässt sich auch nicht abstreiten das ohne das oben genannte Verhalten von Excel das Problem gar nicht bestehen würde, denn selbst wenn es bei Luca diese Sicherheitslücke nicht mehr geben würde, besteht das genannte Problem in Excel auch weiterhin. Abgesehen davon ist CSV ein plattformübergreifendes Format. Der Logik von dir folgend müsste man jetzt also sämtliche Sicherheitslücken in sämtlichen Tabellenkalkulationen und Programmen die irgendwann mal ein CSV File lesen könnten bei Auslieferung eines CSV-Files berücksichtigen.
Anderes Beispiel:
Wo würden wir hinkommen wenn man jede Sicherheitslücke in Microsoft Windows bei der Entwicklung seiner Programme durch Workarounds irgendwie beheben und auf dem Schirm haben muss, wenn das grundliegende Problem einfach durch einen Patch des OS behoben werden könnte. Ich finde, dass ist eine merkwürdige Verantwortungsverschiebung. Ich würde es verstehen, wenn es so wie bei MySQL und MySQL-Injections eine dem Format inhärente Schwachstelle wäre, aber CSV != Excel. Ganz abgesehen davon würde dann jede*r Entwickler*in mit dem halben Bein im Knast stecken, wenn man auf einmal für Sicherheitslücken in anderer Software verantwortlich gemacht werden würde und mit haften würde. Diesen Anspruch hab ich sonst auch noch nicht beobachten können.
Zitat:
> Wer für diese Programme exportiert muss das auf dem Schirm haben.
Da stimme ich dir zu, wenn das so von Luca empfohlen wird. CSV ist aber auch kein Excel, aber nochmal meine Aussage ist kein Widerspruch dazu. Man muss es auf dem Schirm haben und das hatte Luca nicht, das stimmt und das habe ich als Schwachstelle oben kritisiert. Ändert immer noch nichts an dem Programmverhalten von Excel. Und ich würde sagen es ist Security Best Praxis keine Ausführung von beliebigen Code zuzulassen. Das ist so ziemlich das Gegenteil von Validierung.
Du vergisst hier, dass es gewolltes Verhalten ist „Formeln“ in Tabellenkalkulationen ausführen zu können. Das als Sicherheitslücke zu bezeichnen geht zu weit, ohne diese Funktionalität wären die Programme kaum noch so gut einsetzbar. Über das konkrete Verhalten beim Import lässt sich streiten, das finde ich auch absolut schlecht gelöst.
Dein Beispiel trifft es doch genau, das Problem bei der Luca-App ist genau das gleiche wie bei SQL-Injections, darum kann ich deiner Ausführung direkt vor dem Beispiel auch in keinster Weise folgen.
Aber du hast recht, ich glaube es ist alles gesagt und wir haben einfach verschiedene Auffassungen davon wie weit die Verantwortung eines Hersteller hier gehen soll.
Man muss es einmal ganz klar sagen: Der eigentliche Skandal besteht darin, Rohdaten einer .csv-Datei *defaultmäßig* als Code zu interpretieren.
Die Analogie zu SQL-Injection passt einfach nicht, denn hier werden Code und Daten ständig miteinander kombiniert und man muss sich halt darum kümmern, sie auseinanderzuhalten
Bei .csv-Dateien hingegen sollte sich niemand darum kümmern müssen: die Interpretation enthaltener Daten als Funktionen ist in der absolut überwiegenden Zahl der Fälle unerwünscht und schädlich. Ein Feature das keiner will (bei nativen Excel-Dateien mag es anders sein).
Da die Dinge aber nun mal sind wie sie sind (Microsoft ist eine Bürde für uns alle), liegt die Verantwortung für csv-Injection trotzdem bei den Luca- Entwicklern. Und ihr Umgang damit bleibt eine Katastrophe. Darin würde ich auch die eigentliche Kritik sehen.
Viele Grüße
Man könnte auch statt einer CSV Datei gleich eine Excel Datei ausgeben bei der der Typ der Zellen gleich als Text definiert ist. Bzw ich glaub wenn man einen Zellenwert mit “ oder so anfängt wird’s nur als Text erkannt, d.h. einfach das davor hängen bevor CSV generiert wird? Natürlich kann man trotzdem immer noch = verbieten. Hab weder Excel noch LibreOffice installiert. Generell bin ich kein Fan von Tabellenkalkulationen. Diese ganze dynamische Typisierung und alles in eine riesige Tabelle zwängen ist für mich sowas von verrückt. Siehe auch das Gen SEPT5.
Mit diesen Genen haben sie das Excel Problem damit gelöst, dass sie die Gene umbenannt haben! https://www.theverge.com/2020/8/6/21355674/human-genes-rename-microsoft-excel-misreading-dates
CSV ist ein Format für Text in Tabellenform. Wenn Microsoft diese Daten als Excel Formeln interpretiert ist das meiner Meinung nach eine Sicherheitslücke in Excel.
Verstehe nicht, warum Microsoft das nicht beheben will. Wenn ich Microsoft Formeln in meiner Datei haben will, dann speicher ich es als Excel Datei und nicht als CSV.
Natürlich muss Luca aber auch Sicherheitslücken von beteiligten Systemen beachten und entsprechende Workarounds implementieren. Es war daher auch eine Sicherheitslücke in Luca.
Hallo Tim, hallo Linus:
kleiner Hinweis zu den automatisch generierten Transkripten. Das HTML Transkript ist falsch verlinkt oder nicht verfügbar: In der verlinkten HTML-Datei steht lediglich „episode-transcript-html“.
WEBVTT funktioniert dagegen.
Oha, da ist was kaputt. Danke für den Hinweis.
Hallo, erstmal herzlichen Dank für die Fülle an Folgen in letzter Zeit. Fühlt sich an wie Weihnachten. Ich hätte eine Frage im Zusammenhang mit den Transkripten. Mit welcher Software erstellst du die denn, Tim?
Derzeit mit wit.ai via auphonic.com
Hie geht es zwar um SQL Injection und nicht um CSV Injection, aber ich musste spontan dran denken: https://xkcd.com/327/
Ich muss doch nicht einmal bösen Code einschleusen.
Würde es nicht reichen einfach als Telefonnummer und Mailadresse z.B. =C3 einzugeben, damit in der Zelle die Handummer der Person über mir in meinem Datensatz anzuzeigen und eine andere Person angerufen wird und ich ggf. weiter fröhlich infiziert die Restaurants besuche?
Ja.. gut.. Also 31.05.2021, 20:25 Uhr, 2 Tage nach veröffentlichung, ist das verlinkte video ( https://www.youtube.com/watch?v=xTljfac-0ag – Code Injection Luca App: Nutzer greift Gesundheitsamt an und stiehlt Daten bevor er Ransomware schickt – YouTube ) wieder von der Veröffentlichungsplattform verschwunden „, weil es gegen die Community-Richtlinien von YouTube verstößt.“
Interessant. Ich bitte sehr drum woanders zu veröffentlichen (sowieso eigentlich immer, und youtube nur für redundanz, wenn auch sichtbarere, zu nutzen) damit ich mir das anschauen kann. Was da los?
Wenn ich das richtig verstehe, ist neXenio eine Ausgründung aus dem Fachbereich von Prof Dr. Christoph Meinel, wo eigentlich auch in die Richtung Security geforscht wird. Schade das nichts davon in dem Endprodukt gelandet ist.
neXenio empfiehlt ja den Mitarbeitern beim Gesundheitsamt die Warnung von Excel nicht zu ignorieren, sondern sorgfältig zu prüfen. Wie war das: „Öffnen Sie nur Dateien aus vertrauenswürdigen Quellen…“? Falls der Mitarbeiter nun diesen Podcast gehört hat, weiß er ja, dass er neXenio nicht trauen kann und öffnet dann die Datei nicht. Wäre das jetzt die konkrete Empfehlung von neXenio für diesen Fall, dann sollte man sie fragen, wie dann die Software funktionieren soll, wenn die Daten gar nicht verwendet werden können.
Oder empfiehlt neXenio dem Mitarbeiter der Quelle zu vertrauen? Dann würden sie ja empfehlen, potentiell Schad-Code auf den Systemen des Gesundheitsamtes auszuführen.
Vielleicht gibt es noch eine dritte Variante und neXenio rät dazu die Luca Software gar nicht zu verwenden. So könnte man den Mitarbeitern im Gesundheitsamt wertvolle Zeit sparen.
Also neXenio, was ist es nun, was soll der Mitarbeiter im Gesundheitsamt nun tun?
1.) Warnung beherzigen und Datei nicht öffnen.
2.) Warnung ignorieren und eventuell Schadsoftware ausführen
3.) Luca erst gar nicht verwenden
Bei 1 und 3 sollten wir uns das Geld für Luca sparen. Bei 2 muss ich an „Vorbereiten des Ausspähens und Abfangens von Daten“ – den Hackerparagraphen denken.
Hab ich noch eine Option vergessen?