Können Downloads umgeleitet oder manipuliert werden?

[Rampage 2]

Mahlzeit,

Ich habe mich schon immer gefragt, ob Downloads von *vertrauenswürdigen Websites* umgeleitet oder manipuliert werden können - also dass der User letztendlich eine *andere* Datei runterlädt, die aber den exakt gleichen Dateinamen hat! Sind Viren oder Trojaner dazu fähig?

Ein Beispiel:

Ich will mir einen Nvidia-Treiber runterladen und klicke mich bis hier durch:

http://de.download.nvidia.com/Windows/320.18/320.18-desktop-win8-win7-winvista-64bit-international-whql.exe

Ist es möglich, dass diese Download-Adresse umgeleitet wird (ohne dass sich die sichtbare Link-Adresse ändert) *oder* dass z.B. durch Viren eine andere Datei (mit gleichen Dateinamen und ungefähr gleicher Dateigröße) an dieselbe Linkadresse gesetzt wird. Ich habe wenig Ahnung über IT-Sicherheit - also sorry, falls meine Frage irrational oder unsinnig klingt;)

R2

[sei laut]

Die Programme sind mit einem Zertifikat signiert, bzw. wenn diese nicht signiert sind, würde Windows eine Meldung ausgeben.
Wenn da was manipuliert wurde, hast du in jedem Fall eine Datei mit einem ungültigen Zertifikat, Windows fragt dann nach, ob du dem Vertrauen willst.

Die Datei könnte theoreitsch schon auf dem Downloadserver manipuliert vorliegen (ein noch nicht entdeckter Einbruch z.B.), dein Computer kann aber natürlich durch einen Trojaner auch eine "falsche" Seite aufrufen. So funktioniert oftmals dann Pishing oder Banking-Trojaner.

Aber wie gesagt, der nVidia Treiber ist signiert. Meckert da Windows, ist was faul. ;)

[Rampage 2]

Die Programme sind mit einem Zertifikat signiert, bzw. wenn diese nicht signiert sind, würde Windows eine Meldung ausgeben.
Wenn da was manipuliert wurde, hast du in jedem Fall eine Datei mit einem ungültigen Zertifikat, Windows fragt dann nach, ob du dem Vertrauen willst.

Die Datei könnte theoreitsch schon auf dem Downloadserver manipuliert vorliegen (ein noch nicht entdeckter Einbruch z.B.), dein Computer kann aber natürlich durch einen Trojaner auch eine "falsche" Seite aufrufen. So funktioniert oftmals dann Pishing oder Banking-Trojaner.

Aber wie gesagt, der nVidia Treiber ist signiert. Meckert da Windows, ist was faul. ;)

Gibt es außer Signaturen noch andere Möglichkeiten, die Integrität einer Datei nachträglich zu prüfen?

[looking glass]

Ja kann man, z.B. durch transparente Proxys, was im Grunde eigentlich keine "böse Technik" als solche ist, man kann das z.B. hinter Loadballancern machen, um auf verschiedene Server zu verteilen, oder der Provider minimiert dadurch die Netzbelastung (indem er z.b. die 1000 meist aufgerufenen YT Videos im Cache hält).

Ach und Signaturen sind auch nur bedingt sicher, auch diese Zertifikate wurden schon gefälscht, bzw. es gab einen Generalschlüssel, um die Zertifikate zu erzeugen. Dateigröße und namen sind lächerlich einfach hinzubekommen, schwieriger wird es MD5 und SHA Kollisionen der Checksummen hinzubekommen (handelt sich um errechnete Werte die eine Datei eindeutig erkennbar machen).

[Hades11]

hab letztens von der offiziellen hp Seite aus den Druckertreiber downloaden wollen. Beim ersten versuch kan eine sehr kleine "Setup.exe" die mir norton sofort als Virus enttarnt hat. beim 2. klick auf die selbe schaltfläche, ohne die seite neu geladen zu haben kommt dann der Download des korrekten treibers (mit sehr umständlicher bezeichnung).
ich würde es also nicht generell ausschließen dass Downloads manipuliert werden können. Windows hat - im übrigen - keine meldung über fehlende zertifikate gemacht, aber was sicherheit angeht würde ich mich sowieso nicht zu sehr auf win verlassen

edit: falls es jemanden interessiert es war der treiber für: hp Deskjet f4210 Win7 64bit

[Rampage 2]

Ja kann man, z.B. durch transparente Proxys, was im Grunde eigentlich keine "böse Technik" als solche ist, man kann das z.B. hinter Loadballancern machen, um auf verschiedene Server zu verteilen, oder der Provider minimiert dadurch die Netzbelastung (indem er z.b. die 1000 meist aufgerufenen YT Videos im Cache hält).

Ach und Signaturen sind auch nur bedingt sicher, auch diese Zertifikate wurden schon gefälscht, bzw. es gab einen Generalschlüssel, um die Zertifikate zu erzeugen. Dateigröße und namen sind lächerlich einfach hinzubekommen, schwieriger wird es MD5 und SHA Kollisionen der Checksummen hinzubekommen (handelt sich um errechnete Werte die eine Datei eindeutig erkennbar machen).

Es ist aber doch so, dass, wenn die Original-Datei (die sich auf dem authentischen Download-Link befindet) durch eine gefälschte Datei ersetzt wird (welche sich dann ebenfalls auf dem selben Download-Link befindet), dann ALLE Benutzer betroffen sind, oder? Das heißt, nicht nur *ein* User sondern *alle* User laden dann die gefälschte Datei runter? Worauf ih hinaus will: Ist es unmöglich, eine gefälschte Datei gezielt NUR bestimmten Usergruppen unterzujubeln?

Zu "verschiedenen Servern": Gibt es bei GetRight so eine Funktion und wie heißt sie?

[looking glass]

Natürlich kann man den unechten Download nur an bestimmte Nutzer ausliefern, solang man sie identifizieren/klassifizieren kann, ist das nur eine Verknüpfung zweier Techniken.

[Rampage 2]

Wie kann ich folgende Dateien prüfen?

python-3.3.2.amd64.msi

Opera_1215_int_Setup.exe

Opera_1215_int_Setup_x64.exe

[Ferengie]

In dem teuschen Internetknotenpunkten wurde extra Router vor 3? Jahren ersetzt, die den Datenstrom spiegeln können - Speku: damit wahrscheinlich Dienste "passgenaue" Dateien schicken können, für Schwachstellen bei OS, Browser usw. .. also nach meiner Meinung ja.

[Milchkanne]

Egal wo der Angreifer sitzt, ein Download kann immer manipuliert sein:
1) Trojaner bereits auf dem Rechner -> Alles nach belieben möglich. Der Sinn ist zwar zweifelhaft, weil der Trojaner ja auch so alles runterladen kann.
2) Der Angreifer hat den Webserver kompromittiert -> Dateien können gezielt auch nur bestimmten Nutzern untergejubelt werden. Wenn du jetzt an die NSA denkst, die können (bei hinreichendem Interesse) auch jede Signatur fälschen. Checksummen (MD5, SHA1 usw.) sind schon schwieriger, aber die frage ist, woher bekommst du die passende Checksumme? Meist auch vom Server, daher ist das Nutzlos. Wenn dein Kumpel die am Telefon vorliest, könnte das helfen...
3) Der Angreifer sitzt irgendwo dazwischen (beim Provider,...) -> Prinzipiell alles möglich wie bei 2), aber deutlich aufwändiger, da dynamischer auf die wünsche des Surfers eingegangen werden muss, Verschlüsselungen (HTTPS) müssen evtl. gebrochen werden (per MITM mit gefälschtem Zertifikat). Hier hilft im Prinzip nur das Server Zertifikat unabhängig Prüfen zu können (z.B. Chrome Whitelist) und zu hoffen, dass die NSA nicht ohnehin die Private Keys haben.

[Lokadamus]

Ist es möglich, dass diese Download-Adresse umgeleitet wird (ohne dass sich die sichtbare Link-Adresse ändert) *oder* dass z.B. durch Viren eine andere Datei (mit gleichen Dateinamen und ungefähr gleicher Dateigröße) an dieselbe Linkadresse gesetzt wird. Ich habe wenig Ahnung über IT-Sicherheit - also sorry, falls meine Frage irrational oder unsinnig klingt;)Es gibt eine Webseite, die verschiedene Programme als Download anbietet. Hier lädt man zwar eine große Datei mit passendem Namen herunter, aber enthalten ist nur ein Werbeding (Adware) und ein Link auf die gewünschte Datei, welche noch einmal heruntergeladen wird.

Ansonsten lässt sich der Datenverkehr auch manipulieren.
Per Proxy lassen sich auch einfache Sachen auf Webseiten verändern. So kann man auch einfach Microsoft durch Mickysoft austauschen. Allerdings gehen danach die Links nach Microsoft nicht mehr. ;)
http://www.pcwelt.de/ratgeber/Fiddler-So-manipulieren-Sie-Daten-zwischen-Browser-Server-334894.html und das sollte man auch einmal lesen:
http://www.heise.de/newsticker/meldung/Ruby-Update-schuetzt-vor-Man-in-the-Middle-Angriffen-auf-SSL-Verkehr-1902563.html

[duty]

ich glaube ja ? hatte es gestern Nacht mehrfach versucht ein Free Cam Programm auf Chip.de runter zu laden ca. 8 MB groß,
aber das was auf dem Rechner kam hatte nur ca. 822 kb und hatte die Endung Chip Loader, davor eine Anleitung man soll die Daten Freihabe aktiveren und das Programm gleich als Ausführen starten :confused:
das ganze kommt mir doch recht spanisch vor ....
ich hatte auch am WE da öfters bei dieser Seite genau das gleiche Firefox konnte ich nicht runter laden,
mir kommt es bald so vor das diese Seite Viren und Trojaner Verseucht ist oder war?
ich hatte mir dann von der Hersteller Seite das runter geladen da stimmte dann wieder alles ,
mache jetzt um diese Seite einen großen bogen kein bock auf Schadcode?
gibt ja noch andere Web Seiten wo man sich Free Software runter laden

[Grestorn]

Die Tatsache, dass ein Treiber signiert sein muss, hilft gegen Viren nicht. Denn ein normales Setup-Programm wird ja auch ausgeführt, wenn es keine Signatur hat. Und das reicht ja schon, um den Rechner zu infizieren. Man läst eine Datei vom Server im Glauben, es würde sich um einen Treiber handeln, startet das Setup und das war's dann.

Das hat nichts mit mangelnder Sicherheit in Windows zu tun, das gilt für alle Systeme - zumindest so lange das jeweilige OS es zulässt, unsignierte Programme zu starten. Und das gilt für praktisch alle aktuellen Betriebssysteme.

[Lokadamus]

Die Tatsache, dass ein Treiber signiert sein muss, hilft gegen Viren nicht.Ein Virus hat die Überprüfung auch schon umgangen, indem es einen Testmodus aktiviert hat.
http://www.heise.de/newsticker/meldung/64-Bit-Rootkit-spioniert-Onlinebanking-aus-1247509.html

[Spasstiger]

Die MD5-Checksumme ist doch schon ein sehr guter Anhaltspunkt für die Datenintegrität. Häufig werden die Checksummen seitens der Anbieter auch veröffentlicht. Z.B für eine der genannten Dateien:

python-3.3.2.amd64.msi - 5129376df1c56297a80e69a1a6144b4e (http://www.python.org/download/releases/3.3.0/)

[Rampage 2]

Die MD5-Checksumme ist doch schon ein sehr guter Anhaltspunkt für die Datenintegrität. Häufig werden die Checksummen seitens der Anbieter auch veröffentlicht. Z.B für eine der genannten Dateien:

python-3.3.2.amd64.msi - 5129376df1c56297a80e69a1a6144b4e (http://www.python.org/download/releases/3.3.0/)

Diese Summe ist schonmal falsch - sie gehört Version 3.3.0;)

Version 3.3.2: 2477b4bd8e9a337705f7b5fda8b3b45f

Aber das ist auch nicht das Problem: Das Problem ist, ob ich dem Herausgeber vertrauen kann - woher soll ich wissen, ob die Checktools nicht kompromittiert wurden oder die Checksumme selbst?

(siehe Posting von milchkanne)

[Rampage 2]

Also,

Aus aktuellem Anlass und um die Diskussion aus diesem Thread (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11939734) hier weiterzuführen, habe ich diesen alten Thread ausgegraben:wink:

Aktuell bin ich mit diesem Problem konfrontiert:

gpg --verify /home/knoppix/Downloads/gnupg-2.2.13.tar.bz2.sig /home/knoppix/Downloads/gnupg-2.2.13.tar.bz2

gpg: Signatur vom Di 12 Feb 2019 17:16:57 CET
gpg: mittels RSA-Schlüssel 249B39D24F25E3B6
gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel
gpg: Signatur vom Mi 13 Feb 2019 09:25:29 CET
gpg: mittels RSA-Schlüssel 2071B08A33BD3F06
gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel


gpg --import < /home/knoppix/Downloads/Import/Public.gpg

gpg: /root/.gnupg/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel 249B39D24F25E3B6: Öffentlicher Schlüssel "Werner Koch (dist sig)" importiert
gpg: Schlüssel 2071B08A33BD3F06: Öffentlicher Schlüssel "NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>" importiert
gpg: Schlüssel 04376F3EE0856959: Öffentlicher Schlüssel "David Shaw (GnuPG Release Signing Key)" importiert
gpg: Schlüssel BCEF7E294B092E28: Öffentlicher Schlüssel "Andre Heinecke (Release Signing Key)" importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 4
gpg: importiert: 4


gpg --verify /home/knoppix/Downloads/gnupg-2.2.13.tar.bz2.sig /home/knoppix/Downloads/gnupg-2.2.13.tar.bz2

gpg: Signatur vom Di 12 Feb 2019 17:16:57 CET
gpg: mittels RSA-Schlüssel 249B39D24F25E3B6
gpg: Korrekte Signatur von "Werner Koch (dist sig)" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
gpg: Signatur vom Mi 13 Feb 2019 09:25:29 CET
gpg: mittels RSA-Schlüssel 2071B08A33BD3F06
gpg: Korrekte Signatur von "NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06


Arbeitsumgebung:

Ich habe wie gewohnt meine Knoppix Live-CD (Knoppix-Version 7.7.1, Linux-Kernel 4.7.9, Debian-Version 9.8) gestartet und danach aufgefrischt ("aptitude update", "aptitude build-essential") sowie ein für GPG erforderliches Paket ("aptitude install libusb-1.0-0-dev") bezogen.

Um die aktuellste Version von GPG (2.2.13) installieren zu können, muss ich zuerst dessen Installations-Pakete mithilfe der älteren, auf Knoppix enthaltenen, GPG-Version (2.1 irgendwas) verifizieren.


Das Problem:

Zuerst wollte ich mit GPG die Datei "gnupg-2.2.13.tar.bz2" mittels dessen Signaturdatei "gnupg-2.2.13.tar.bz2.sig" (Beide von der gleichen Quelle heruntergeladen) verifizieren...

gpg --verify /home/knoppix/Downloads/gnupg-2.2.13.tar.bz2.sig /home/knoppix/Downloads/gnupg-2.2.13.tar.bz2

... und da kam auch die erste Fehlermeldung "Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel".

Also als Nächstes den öffentlichen Schlüssel von der offiziellen Quelle besorgt (https://www.gnupg.org/signature_key.html) (einfach die gesamte Blockkette inkl. "Begin"- und "End"-Zeilen kopiert, in eine Textdatei eingefügt, die Textdatei zu "Public" umbenannt und dann in eine GPG-Endung umgewandelt) und dann von GPG importieren lassen:

gpg --import < /home/knoppix/Downloads/Import/Public.gpg

Anschließend den ersten Befehl zur Verifizierung erneut ausgeführt:

gpg --verify /home/knoppix/Downloads/gnupg-2.2.13.tar.bz2.sig /home/knoppix/Downloads/gnupg-2.2.13.tar.bz2

Als Ergebnis kam diesmal die Meldung, die ich im am Anfang dieses Postings eingefügten Code fett markiert habe...


Die Frage ist: Was habe ich falsch gemacht?

Hier steht (https://www.gnupg.org/download/integrity_check.html), dass dieser Fehler auch dann auftreten könne, wenn man die Schlüssel noch nicht als "vertrauenswürdig" markiert hat - die andere Möglichkeit ist, dass sie gefälscht seien.

If you instead see:

[...]

then you have a copy of our keys and the signatures are valid, but either you have not marked the keys as trusted or the keys are a forgery. In this case, at the very least, you should compare the fingerprints that are shown to those on the signing keys page (https://www.gnupg.org/signature_key.html). Even better is to compare the fingerprints with those shown on our business cards, which we handout at events that we attend.


Bitte um Unterstützung...

R2

[lumines]

Mal unabhängig von deinem Problem: Ein aptitude bzw. apt upgrade auf einer Live-CD frischt dein System nicht wirklich auf, weil du die Dienste manuell neu starten musst. Für Sicherheitspatches auf den Kernel oder andere systemnahe Software musst du auch rebooten, was mit einer Live-CD natürlich nicht funktioniert, weil du dann wieder die Updates verlierst.

Zum Problem: GPG ist leider unglaublich komplex und ich google auch jedes Mal die Optionen. Grundsätzlich ist es aber so, dass GPG erst einmal nicht allen importierten Schlüsseln traut. Man muss die erst manuell markieren, wenn man (auf welche Art auch immer) sichergestellt hat, dass die Schlüssel auch wirklich zu derjenigen Person gehören. Wirklich etwas falsch hast du eigentlich nicht gemacht, es ist einfach nur das gesamte Schlüsselmanagement, das dabei relativ komplex ist und noch aus den 90ern stammt. Leider ist GPG eben das, womit die meiste freie Software heute signiert wird. Wohlgemerkt aber nicht alle, OpenBSD hat mit signify (https://www.openbsd.org/papers/bsdcan-signify.html) eine deutlich einfachere (https://man.openbsd.org/signify) Alternative für die Signaturen ihrer Releases.

Ich bin bei dem Schlüsselmanagement von GPG auch kein Experte. Alles weitere daher nur Halbwissen und nur eine kurze Anleitung, wie man das so rein mechanisch abtippen kann.

Erst einmal würde ich das Paket dirmngr nachinstallieren, womit man sich die Keys automatisiert von den Keyservern runterladen kann.

Wenn du das erste Mal die Signatur verifizierst, sollte das hier dabei rauskommen:

$ gpg --verify gnupg-2.2.13.tar.bz2.sig gnupg-2.2.13.tar.bz2
gpg: Signature made Tue 12 Feb 2019 05:16:57 PM STD
gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6
gpg: Can't check signature: No public key
gpg: Signature made Wed 13 Feb 2019 09:25:29 AM STD
gpg: using RSA key 031EC2536E580D8EA286A9F22071B08A33BD3F06
gpg: Can't check signature: No public key

Die lange Zeichenfolge ist der Fingerprint. Damit kannst du dir die Schlüssel von einem Keyserver automatisiert runterladen:

$ gpg --keyserver keys.gnupg.net --recv-key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6

$ gpg --keyserver keys.gnupg.net --recv-key 031EC2536E580D8EA286A9F22071B08A33BD3F06

Das sollte dann dabei herauskommen:

$ gpg --list-keys --fingerprint
/home/username/.gnupg/pubring.kbx
-----------------------------
pub rsa2048 2011-01-12 [SC] [expires: 2019-12-31]
D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
uid [ unkown] Werner Koch (dist sig)
sub rsa2048 2011-01-12 [A] [expires: 2019-12-31]

pub rsa2048 2014-10-29 [SC] [expires: 2020-10-30]
031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06
uid [ unkown] NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>
sub rsa2048 2014-10-29 [E] [expires: 2020-10-30]

Wie man jetzt sicherstellt, dass man diesen Schlüsseln traust, ist natürlich jedem selbst überlassen. Hier kannst du mehr dazu lesen: https://www.gnupg.org/gph/en/manual/x334.html

Praktisch kannst du das so editieren (für den ersten Key):

$ gpg --edit-key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6
gpg>

Bei der Aufforderung gibst du "trust" ein und wählst dann die Stufe, die du haben willst.

Generell ist das alles aber auf einer Live-CD relativ witzlos, weil du ja immer deinen Keyring verlierst. Du willst das irgendwo persistent haben. Ansonsten wäre es sicherheitstechnisch nicht viel besser als einfach nur jedes Mal die Prüfsummen zu checken.

[Rampage 2]

Mal unabhängig von deinem Problem: Ein aptitude bzw. apt upgrade auf einer Live-CD frischt dein System nicht wirklich auf, weil du die Dienste manuell neu starten musst. Für Sicherheitspatches auf den Kernel oder andere systemnahe Software musst du auch rebooten, was mit einer Live-CD natürlich nicht funktioniert, weil du dann wieder die Updates verlierst.


Zum Ersten: lassen sich die betroffenen Dienste nicht durch einen Befehl in der Konsole automatisiert neustarten? Das sollte eigentlich möglich sein...:|

Zum Zweiten: Ich hatte, glaub' ich, erst kürzlich mehrfach gelesen, dass man (mittlerweile) auch bei einer Live-CD die Updates, Sicherheitspatches und sonstige Änderungen am OS separat auf einer Festplatte oder externem Datenträger speichern kann - nach einem Neustart wird der veränderte Anteil des OS wieder in die Live-CD eingespeist. Also der unveränderte Teil auf der Live-CD und der veränderte Teil (Updates, Upgrades, OS-Veränderungen, neue Programmversionen, Sicherheitspatches, usw.) auf einem separaten Datenträger. Oder so ähnlich... so ungefähr habe ich das verstanden:wink:

Die Frage ist natürlich, ob das auch für Änderungen am Kernel oder OS-Dateien gilt? Wenn ich mich nicht falsch erinnere, werden bei Linux - im Gegensatz zu Windows - Änderungem am OS selber noch während der aktuellen Session direkt übernommen, ohne das ein Neustart erforderlich wäre. Auch das habe ich, glaub' ich, erst kürzlich bei einem Artikel über Linux gelesen...

Aber beide Behauptungen sind ohne Gewähr - es könnte auch sein, dass ich mich falsch erinnere oder die Artikel falsch interpretiert habe:wink:


Grundsätzlich ist es aber so, dass GPG erst einmal nicht allen importierten Schlüsseln traut. Man muss die erst manuell markieren, wenn man (auf welche Art auch immer) sichergestellt hat, dass die Schlüssel auch wirklich zu derjenigen Person gehören.


Wie man jetzt sicherstellt, dass man diesen Schlüsseln traust, ist natürlich jedem selbst überlassen. Hier kannst du mehr dazu lesen: https://www.gnupg.org/gph/en/manual/x334.html


Aber genau das ist doch das Kernproblem: wenn man den Prüfsummen nicht vertraut, dann kann sich mit den GPG-Signaturen absolute Sicherheit darüber verschaffen, dass die angebotenen Prüfsummen wirklich die echten Prüfsummen sind - so habe ich es von deinen früheren Postings verstanden. Hier ein Auszug von einem anderen Thread von mir, meine Frage und deine Antwort:


2.) Und woher soll ich wissen, ob nicht auch die Prüfsummen präpariert sind? Manche Websites geben zusätzlich zum Downloadlink auch einen Link für die Prüfsummen(-datei) an oder zeigen die Prüfsumme direkt auf der Seite an.

Wenn der Angreifer in der Lage ist, mich an einen präparierten DL-Link oder eine präparierte DL-Seite abzuleiten (so dass ich nicht die saubere Datei, sondern dessen präparierte Version downloade...), dann ist er mit Sicherheit auch in der Lage, die Prufsummen selber zu vertauschen - so sehe ich auf der präparierten DL-Seite gar nicht erst die wahre Prüfsumme, sondern dessen präparierte Version.

Wenn ich dann einen Prüfsummenabgleich machen will, wird es natürlich keinen Alarm geben, weil die Prüfsumme der präparierten Datei identisch mit der der präparierten Prufsumme ist - die echte Prüfsumme habe ich ja gar nicht erst zu Gesicht bekommen...



Deshalb werden die Prüfsummen meistens mit einem langlebigen Schlüssel signiert oder die Downloads sind direkt signiert. Die Signatur muss man dann manuell validieren. Man sollte natürlich vorher den öffentlichen Schlüssel aus einer sicheren Quelle bezogen haben. Meistens wird das heute alles mit GPG gemacht.


Das mit "sicherer Quelle" kannst du gerne etwas erläutern - obwohl ich die Antwort schon vermute... wenn es die erwartete Antwort ist, dann hat sich meine Befürchtung bestätigt.

Wenn dem so ist, dann läuft es auf Dasselbe hinaus wie mit den Prüfsummen - die Signaturen/Schlüssel selber könnten ebenfalls für den User "angepasst" sein.

Allerdings sehe ich auch Hoffnungsschimmer: (wieder ein Auszug)


Wie soll das denn gehen? Das OS muss die Signaturen/Zertifikate ja erstmal irgendwo herunterladen, um damit einen Signaturabgleich machen bzw. die Authentizität der Prüfsummen bestätigen zu können - und die heruntergeladenen Sigs/Certs könnten gefälscht sein, wenn die Webseite/Webserver/Absender selber kompromittiert ist oder eine dritte Partie sonstwie mit dem Absender interferiert...



Dein Betriebssystem kommt zusammen mit haufenweise Root-Zertifikaten. Unter anderem natürlich auch von Microsoft.



Das könnte in der Tat ein beständiger Schutz sein oder wenigstens gefälschte Sigs/Schlüssel/Zerts als Solche entlarven:P


Erst einmal würde ich das Paket dirmngr nachinstallieren, womit man sich die Keys automatisiert von den Keyservern runterladen kann.

Wenn du das erste Mal die Signatur verifizierst, sollte das hier dabei rauskommen:


[...]



gpg: Can't check signature: No public key[/CODE]


Die lange Zeichenfolge ist der Fingerprint. Damit kannst du dir die Schlüssel von einem Keyserver automatisiert runterladen:


Ich hab ja auch zuerst den Public Key importiert (manuell, über die Konsole, aus einer Datei in die ich den Zeichenblock aus der offiziellen GnuPG-Seite hineinkopiert hatte) und erst dann die Verifikation durchgeführt - dann war die Fehlermeldung in deinem Zitat auch Geschichte;)

Zum Fettgedruckten: ist es nicht sicherer, die Keys manuell über die Kommandozeile zu importieren (nachdem man sie vorher selber von der jeweiligen Webseite bezogen hat) ? Beim automatisierten Download wird der Schlüssel ja auch automatisch, ohne zukünftige Benutzeraufforderung aktualisiert (nehme ich mal an...) und deswegen fortan auch vom Benutzer nicht jedes Mal geprüft - das könnte es einem Angreifer leichter machen, dem Benutzer modifizierte Keys unterzujubeln...

Allerdings gebe ich dir Recht, dass das schnell unpraktisch werden kann...


Praktisch kannst du das so editieren (für den ersten Key):

$ gpg --edit-key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6
gpg>
Bei der Aufforderung gibst du "trust" ein und wählst dann die Stufe, die du haben willst.


Hab ich mittlerweile alles schon gemacht... zuerst jeden der Schlüssel einzeln signiert - das Blöde ist, dass man auch nur fürs Signieren einen eigenen Schlüssel erstellen muss, was ich dann auch gemacht habe. Da ich nur am Signieren interressiert bin (um, ultimativ, die Integrität von Dateien und deren Prüfsummen sicherzustellen), habe ich mich für "RSA (sign only)" entschieden - Option "4" war das, glaub' ich.

Nachdem ich alle Schlüssel einzeln signiert hatte, habe ich sie dann alle einzeln beglaubigt/vertraut (mit "trust", wie du schon beschrieben hast). Da ich mir aber über die Echtheit immer noch nicht sicher sein kann, habe bei allen Schlüsseln jeweils die Vertrauensstufe "marginal" ausgewählt.

Da nun alle Schlüssel von mir signiert und beglaubigt wurden, klappte auch endlich die Verifizierung der Datei ("gnupg-2.2.13.tar.bz2", mittels "gnupg-2.2.13.tar.bz2.sig") ohne dass GPG eine Warnung ausspuckte.



Generell ist das alles aber auf einer Live-CD relativ witzlos, weil du ja immer deinen Keyring verlierst. Du willst das irgendwo persistent haben. Ansonsten wäre es sicherheitstechnisch nicht viel besser als einfach nur jedes Mal die Prüfsummen zu checken.


Das stimmt. In der Tat ist es sehr nervenaufreibend für mich, nach jedem Neustart das ganze Prozedere wiederholen zu müssen:mad:

R2

[lumines]

Zum Ersten: lassen sich die betroffenen Dienste nicht durch einen Befehl in der Konsole automatisiert neustarten? Das sollte eigentlich möglich sein...:|

Grundsätzlich ja, aber dafür müsstest du zum Teil auch die Sessions und grafische Oberfläche neu starten.

Zum Zweiten: Ich hatte, glaub' ich, erst kürzlich mehrfach gelesen, dass man (mittlerweile) auch bei einer Live-CD die Updates, Sicherheitspatches und sonstige Änderungen am OS separat auf einer Festplatte oder externem Datenträger speichern kann - nach einem Neustart wird der veränderte Anteil des OS wieder in die Live-CD eingespeist. Also der unveränderte Teil auf der Live-CD und der veränderte Teil (Updates, Upgrades, OS-Veränderungen, neue Programmversionen, Sicherheitspatches, usw.) auf einem separaten Datenträger. Oder so ähnlich... so ungefähr habe ich das verstanden:wink:

Die Frage ist natürlich, ob das auch für Änderungen am Kernel oder OS-Dateien gilt? Wenn ich mich nicht falsch erinnere, werden bei Linux - im Gegensatz zu Windows - Änderungem am OS selber noch während der aktuellen Session direkt übernommen, ohne das ein Neustart erforderlich wäre. Auch das habe ich, glaub' ich, erst kürzlich bei einem Artikel über Linux gelesen...

Also bei Userdaten funktioniert das, aber Systemdateien wären mir neu.


Aber genau das ist doch das Kernproblem: wenn man den Prüfsummen nicht vertraut, dann kann sich mit den GPG-Signaturen absolute Sicherheit darüber verschaffen, dass die angebotenen Prüfsummen wirklich die echten Prüfsummen sind - so habe ich es von deinen früheren Postings verstanden. Hier ein Auszug von einem anderen Thread von mir, meine Frage und deine Antwort:

Das mit "sicherer Quelle" kannst du gerne etwas erläutern - obwohl ich die Antwort schon vermute... wenn es die erwartete Antwort ist, dann hat sich meine Befürchtung bestätigt.

Wenn dem so ist, dann läuft es auf Dasselbe hinaus wie mit den Prüfsummen - die Signaturen/Schlüssel selber könnten ebenfalls für den User "angepasst" sein.

Prüfsummen liefern dir eben nur Integrität, aber keine Authentizität.

Die GPG-Schlüssel sind meistens sehr langlebig und das ist ein gewisser Vorteil.

Nur ein Beispiel: Du nimmst die Schlüssel des Debian-Release-Teams in deinen Keyring auf und hast (auf welchem Weg auch immer) überprüft, dass die echt sind. Damit kannst du dann die sicherstellen, dass die Debian-ISOs, die du von irgendwo runterlädst, wirklich vom Debian-Release-Team stammen und von keinem Dritten manipuliert worden sind. Der große Clou ist aber, dass eine Debian-Installation selbst einen eigenen Debian-Keyring mit weiteren Schlüsseln vom Debian-Projekt mitbringt. So werden dann alle Updates und Pakete automatisch validiert, dass die auch wirklich entweder vom Release-Team oder den Maintainern stammen.

Du hast damit praktisch mit der einen gecheckten ISO dein Vertrauen für die restliche Software in Debian gebootstrapt, wenn man das so sagen kann. Anstatt Software aus wildfremden Quellen zu beziehen und nicht wirklich zu wissen, ob die modifiziert wurde, traust du jetzt nur noch den Debian-Maintainern (man wird nicht einfach so Debian-Maintainer) und dem Release-Team. Sogar bei einem gehackten Webserver, auf dem Debian seine Software lagert, würde dich das nicht in Gefahr bringen, weil dein System solche Pakete einfach nicht installieren würde.

Das könnte in der Tat ein beständiger Schutz sein oder wenigstens gefälschte Sigs/Schlüssel/Zerts als Solche entlarven:P

Genau dafür ist es gedacht. Wenn sich eine Certificate Authority schädlich verhält, wird die von den Betriebssystemen und Browsern gekickt. Das ist schon vorgekommen, von daher ist das keine theoretische Prozedur.

Manche Software bringt auch ein eigenes Bundle von Zertifikaten mit und ignoriert das des Systems. Wenn z.B. ein Programm nur mit den Servern des Herstellers kommuniziert, gibt es keinen Grund mehr Zertifikatsstellen zu trauen. Das machen viele Messenger so für ihre Transportverschlüsselung.

Ich hab ja auch zuerst den Public Key importiert (manuell, über die Konsole, aus einer Datei in die ich den Zeichenblock aus der offiziellen GnuPG-Seite hineinkopiert hatte) und erst dann die Verifikation durchgeführt - dann war die Fehlermeldung in deinem Zitat auch Geschichte;)

Kann man auch machen. Kommt am Ende alles auf das gleiche Ergebnis.

Zum Fettgedruckten: ist es nicht sicherer, die Keys manuell über die Kommandozeile zu importieren (nachdem man sie vorher selber von der jeweiligen Webseite bezogen hat) ? Beim automatisierten Download wird der Schlüssel ja auch automatisch, ohne zukünftige Benutzeraufforderung aktualisiert (nehme ich mal an...) und deswegen fortan auch vom Benutzer nicht jedes Mal geprüft - das könnte es einem Angreifer leichter machen, dem Benutzer modifizierte Keys unterzujubeln...

Allerdings gebe ich dir Recht, dass das schnell unpraktisch werden kann...

Aktualisiert werden die eigentlich nicht. Manchmal werden neue veröffentlicht, aber die können natürlich mit den alten signiert sein. So hat man immer eine vertraute Kette.

Klar, automatisiert von einer Webseite runterladen birgt ein gewisses Risiko. Es ist im Grunde Trust on First Use. Wahrscheinlich sollte man sich persönlich treffen und Schlüssel austauchen. Passiert natürlich eher selten, man braucht aber irgendeinen Anfangspunkt.

Hab ich mittlerweile alles schon gemacht... zuerst jeden der Schlüssel einzeln signiert - das Blöde ist, dass man auch nur fürs Signieren einen eigenen Schlüssel erstellen muss, was ich dann auch gemacht habe. Da ich nur am Signieren interressiert bin (um, ultimativ, die Integrität von Dateien und deren Prüfsummen sicherzustellen), habe ich mich für "RSA (sign only)" entschieden - Option "4" war das, glaub' ich.

Nachdem ich alle Schlüssel einzeln signiert hatte, habe ich sie dann alle einzeln beglaubigt/vertraut (mit "trust", wie du schon beschrieben hast). Da ich mir aber über die Echtheit immer noch nicht sicher sein kann, habe bei allen Schlüsseln jeweils die Vertrauensstufe "marginal" ausgewählt.

Da nun alle Schlüssel von mir signiert und beglaubigt wurden, klappte auch endlich die Verifizierung der Datei ("gnupg-2.2.13.tar.bz2", mittels "gnupg-2.2.13.tar.bz2.sig") ohne dass GPG eine Warnung ausspuckte.

Es ist leider auch unnötig kompliziert. Wird wahrscheinlich nicht das letzte Mal sein, dass man sich das anguckt.

Generell ist es aber sehr praktisch, weil GPG einfach fast überall vorinstalliert oder mindestens sehr einfach zu installieren ist. Bei allen Linux-Distributionen sowieso, weil das Paketmanagement auf GPG aufbaut und bei Windows 10 mittlerweile auch, weil das Linux-Subsystem es benutzt.

Es liefert auch nette weitere Funktionen, z.B. kann man mit GPG relativ einfach Dateien symmetrisch verschlüsseln (unterstes Beispiel): https://www.gnupg.org/gph/en/manual/x110.html

Eigentlich will man von GPG weg, weil es einfach in vielen Fällen kompletter Overkill ist, aber weil es überall entweder direkt dabei oder einfach zu installieren ist, kann es ziemlich nützlich sein wenigstens ein paar einfache Sachen damit machen zu können.

Das stimmt. In der Tat ist es sehr nervenaufreibend für mich, nach jedem Neustart das ganze Prozedere wiederholen zu müssen:mad:

R2

Ich würde Debian einfach fest installieren. Wenn ich mich richtig erinnere, kann man über die Installationsroutine auch sehr einfach eine vollverschlüsselte Installation einrichten.

[Rampage 2]

Auf dein Posting gehe ich später ausführlicher ein, aber im Moment stecke ich wieder fest:

Wenn ich versuche, die .asc-Datei "firefox-65.0.2.tar.bz2.asc" (heruntergeladen von der offiziellen FF-Seite) in GnuPG zu importieren...

gpg --import firefox-65.0.2.tar.bz2.asc
...bekomme ich jedes Mal diese Fehlermeldung:

gpg: no valid OpenPGP data found
Dabei funktioniert derselbe Befehl (oder alternativ auch "--import-key") bei den anderen Schlüsseln einwandfrei. Die Dateiendung zu ".gpg" oder gar einfach zu ".txt" umzuwandeln und es dann erneut zu versuchen, hat nichts gebracht. Und ja, manchmal muss man vorher unnötige Zeilen aus der Schlüsseldatei selbst entfernen - auch das habe ich versucht und hat ebenfalls nichts gebracht...:mad:

R2

[lumines]

Das ist eine direkte Signatur der Datei.

Du musst erst den öffentlichen Schlüssel vom Mozilla-Release-Team runterladen: http://gpg.mozilla.org/pks/lookup?op=get&search=0x61B7B526D98F0353

Danach kannst du wieder mit gpg --verify wie normal auch die Signatur mit der Datei vergleichen.

[Rampage 2]

Du musst erst den öffentlichen Schlüssel vom Mozilla-Release-Team runterladen: http://gpg.mozilla.org/pks/lookup?op=get&search=0x61B7B526D98F0353


Hatte mich schon gewundert... denn den öffentlichen Schlüssel konnte ich auf den gängigen Mozilla-Seiten nicht finden und sogar beim Googeln konnte ich keine eindeutige Website/Quelle identifizieren, die *offiziell* für Mozilla Public Keys zuständig ist - immer noch nicht!

Anscheinend kann man Mozilla-Schlüssel ausschließlich von Keyservern (oder über die Kommandozeile) beziehen - die Frage ist nur, wie soll man ein Schlüssel beziehen (suchen) wenn man dessen genauen Namen schon nicht weiß!? :|

(WOHER weißt du denn die genaue Bezeichnung des Schlüssels, den du in deinem letzten Posting verlinkt hast? :|)

-----------------------------------------

Davon abgesehen, stehe ich vor einer anderen Frage:

Private Schlüssel - diese sollen ja unbedingt vertraulich bleiben. Ich habe auf meinem Live-Betrieb erneut nach einem Neustart einen eigenen Schlüssel erzeugt - der öffentliche Teil ist ja nicht so kritisch, aber der private Teil muss unbedingt geschützt werden.

Im Moment ist mein Live-Betrieb vom Internet abgetrennt und das Gerät ist schon seit Tagen ununterbrochen am Laufen, weil ich mir die Strapazen nach einem Neustart (erneut Schlüssel anlegen...) nicht ein weiteres Mal antun will:P

Ich will aber damit jetzt online gehen - inwiefern besteht da die Gefahr, dass Fremde an den privaten Schlüssel gelangen könnten? Welche Vorsichtsmaßnahmen sollte man treffen? Ich spiel nämlich mit dem Gedanken, meinen Schlüsselbund (inkl. Private Key) zu exportieren - um es auf meinem eigentlichen Rechner weiterverwenden zu können...

R2

[lumines]

Hatte mich schon gewundert... denn den öffentlichen Schlüssel konnte ich auf den gängigen Mozilla-Seiten nicht finden und sogar beim Googeln konnte ich keine eindeutige Website/Quelle identifizieren, die *offiziell* für Mozilla Public Keys zuständig ist - immer noch nicht!

Anscheinend kann man Mozilla-Schlüssel ausschließlich von Keyservern (oder über die Kommandozeile) beziehen - die Frage ist nur, wie soll man ein Schlüssel beziehen (suchen) wenn man dessen genauen Namen schon nicht weiß!? :|

(WOHER weißt du denn die genaue Bezeichnung des Schlüssels, den du in deinem letzten Posting verlinkt hast? :|)

Ehrlich gesagt habe ich nur einmal kurz gegooglet und der gleiche Key ist scheinbar auch bei allen halbwegs aktuellen Releases im KEY Verzeichnis dabei: https://ftp.mozilla.org/pub/firefox/releases/65.0/KEY

Private Schlüssel - diese sollen ja unbedingt vertraulich bleiben. Ich habe auf meinem Live-Betrieb erneut nach einem Neustart einen eigenen Schlüssel erzeugt - der öffentliche Teil ist ja nicht so kritisch, aber der private Teil muss unbedingt geschützt werden.

Im Moment ist mein Live-Betrieb vom Internet abgetrennt und das Gerät ist schon seit Tagen ununterbrochen am Laufen, weil ich mir die Strapazen nach einem Neustart (erneut Schlüssel anlegen...) nicht ein weiteres Mal antun will:P

Die einfachste und sicherste Lösung wäre, dass du es fest installiert.

Ich will aber damit jetzt online gehen - inwiefern besteht da die Gefahr, dass Fremde an den privaten Schlüssel gelangen könnten?

Die Gefahr ist nicht größer oder geringer als bei jeder anderen Datei auf deinem Rechner auch. Man sollte natürlich zeitnah Updates einspielen.

Den öffentlichen Teil kannst du beliebig verschicken und dafür ist er auch gedacht. Muss man natürlich nicht, aber mit dem öffentlichen Schlüssel können andere Leute Dateien verschlüsseln, die nur du mit deinem privaten Schlüssel als Gegenstück dazu entschlüsseln kannst. Du musst mit der anderen Person praktisch nur einmal die öffentlichen Schlüssel austauschen und schon hat man einen Weg auch über einen langen Zeitraum Daten sicher auszutauschen. GPG wird deshalb unter anderem auch von vielen Leuten zur Kommunikation per E-Mail benutzt.

Ob man das wirklich macht (wie gesagt, GPG ist den meisten Leuten zu komplex), ist natürlich eine andere Frage. Es gibt aber auch andere interessante Anwendungen, z.B. ein Passwortmanager basierend auf GPG: https://www.passwordstore.org/

Welche Vorsichtsmaßnahmen sollte man treffen? Ich spiel nämlich mit dem Gedanken, meinen Schlüsselbund (inkl. Private Key) zu exportieren - um es auf meinem eigentlichen Rechner weiterverwenden zu können...

Du kannst den privaten Schlüssel optional mit einer Passphrase schützen. Mit dem gpg-agent kann man den Schlüssel für z.B. die Länge der Session entschlüsselt im Speicher lagern, damit man die Passphrase nicht jedes Mal eingeben muss.

Ich bin mir aber gerade gar nicht so sicher, ob der exportierte Key dann noch eine Passphrase hat.

[fezie]

Du könntest dir zB. auch einen Yubikey zulegen. Und dann den GPG Key dort speichern.
Dann kommt keiner mehr an den privaten Schlüssen ran.
Und zum benutzen musst du dann halt jedesmal den Yubikey einstecken.

[Rampage 2]

Natürlich kann man den unechten Download nur an bestimmte Nutzer ausliefern, solange man sie identifizieren/klassifizieren kann, ist das nur eine Verknüpfung zweier Techniken.

Durch "Zufall" bin ich auf eine Idee gekommen, wie man dieses Problem umgehen kann - da ich erst vor ein paar Tagen Windows 10 auf unserem Laptop (den Neueren) neuinstalliert habe, musste ich natürlich auch das Anti-Viren Programm ("Kaspersky Total Security 2019") neu einrichten. Dabei fiel mir auf, dass "Kaspersky Secure Connection" anscheinend ein echter VPN-Service ist - bisher hatte ich das Programm ignoriert bzw. wollte es erst ausprobieren, wenn ich dazu die Gelegenheit hatte.

Da es - wie im obigen Zitat erklärt - leider auch möglich ist, modifizierte Downloads nur für bestimmte User unterzujubeln, sollte doch die Verschleierung der echten IP-Adresse ebendiese Klassifizierung unmöglich machen, oder etwa nicht?

Eigentlich will ich KSC nicht verwenden, weil es eher unsicher ist (die Infrastruktur selber ist von HotSpotShield... und deren Firmensitz ist in den USA; allerdings nutzt Kaspersky seinen eigenen "modifizierten Client" - ob es dadurch doch sicherer ist?), sehr wenige Server zur Verfügung stehen und kein Killswitch vorhanden ist. Aber ich kann mich einfach nicht von dem Gedanken lösen - vermutlich, weil es in meiner Lizenz schon enthalten ist und auch ansonsten SEHR billig ist (nur 5€ pro Monat für unbegrenztes Volumen). Ich habe eine Angewohnheit, Dinge auch nutzen zu wollen, wenn ich sie habe... :redface:

R2

[lumines]

Wenn der Webserver TLS und HSTS aktiv hat, bringt dir ein VPN keinen wirklichen Mehrwert und ein gehackter Webserver kann dir so oder so ein schädlich modifiziertes Programm ausliefern. Da hilft dir ein VPN genau so wenig.

Generell wärst du wahrscheinlich auch sicherer unterwegs, wenn du Kaspersky runterwirfst und einfach den Windows Defender benutzt.

[Rampage 2]

und ein gehackter Webserver kann dir so oder so ein schädlich modifiziertes Programm ausliefern. Da hilft dir ein VPN genau so wenig.

Es ging ja darum, die Malware nur bestimmten Usern unterzujubeln - dazu muss man diese User anhand ihrer IP identifizieren und/oder klassifizieren können. Und genau das soll ein VPN ja vereiteln...

Du hast aber Recht, wenn die modifizierte Datei für *alle* User bestimmt ist bzw. die echte Datei ersetzt hat... dann spielt der User/die IP keine Rolle mehr und JEDER, der den DL-Link anklickt, erhält die gefälschte Version, ja!


Generell wärst du wahrscheinlich auch sicherer unterwegs, wenn du Kaspersky runterwirfst und einfach den Windows Defender benutzt.

Wir sind uns doch einig darüber, dass KAV/KIS/KTS fähiger als WD ist? Kaspersky und Bitdefender bekommen schon seit Jahren konsistent Höchstwertungen. Ich hatte mir erst gestern den englischsprachigen Wikipedia-Artikel über Kaspersky durchgelesen - lies du es auch durch... zahlreiche Sachen wurden von Kaspersky entdeckt!

R2

[lumines]

Es ging ja darum, die Malware nur bestimmten Usern unterzujubeln - dazu muss man diese User anhand ihrer IP identifizieren und/oder klassifizieren können. Und genau das soll ein VPN ja vereiteln...

Man kann dich auch auch einfach anhand deines Browser-Fingerprints identifizieren, was sowieso zuverlässiger ist. Dafür braucht man keine IP.

Wir sind uns doch einig darüber, dass KAV/KIS/KTS fähiger als WD ist? Kaspersky und Bitdefender bekommen schon seit Jahren konsistent Höchstwertungen. Ich hatte mir erst gestern den englischsprachigen Wikipedia-Artikel über Kaspersky durchgelesen - lies du es auch durch... zahlreiche Sachen wurden von Kaspersky entdeckt!

Virenscanner sind generell ein sicherheitstechnisches Anti-Pattern. Der Windows Defender wird wenigstens bald gesandboxt, von daher ist er noch das geringere Übel.

Diese Studie über die Praktiken von Sicherheitsexperten gegenüber normalen Nutzern ist IMHO noch immer sehr relevant: https://www.usenix.org/system/files/conference/soups2015/soups15-paper-ion.pdf

Wohlgemerkt tauchen Virenscanner bei den befragten Experten nicht in den Top 5 auf, sondern nur bei Leuten, die keine tieferen Kenntnisse über Rechnersicherheit haben:

https://2.bp.blogspot.com/-BYD2O7mTI9E/VbB5_O_OdFI/AAAAAAAAAGs/NMkvxIUuq_8/s1600/Beutler_Google_Security-practices-v6.png

https://abload.de/img/screenshot2019-03-18a5ij3r.png

Man beachte auch, wie groß der Unterschied bei Software Updates ist. Die Nicht-Experten messen Sicherheitsupdates praktisch keine Bedeutung zu, während die befragten Sicherheitsexperten sie an erster Stelle sehen.