[English]Sie können es einfach nicht, die forschen Entwickler von Microsoft, die coole Ideen umsetzen! Ich hatte gerade berichtet, wie das Store-Team damit begonnen hat, Store-Apps neu zu packen. Es wird ein ausführbarer .NET-Wrapper um die Store-Apps geklatscht, der Telemetrie und weiteren Code in die App schmuggelt. Soll die Installation von Store-Apps vereinfachen und einen Klick sparen. Und so ganz nebenbei reißen die Microsoft-Strategen noch eine DLL-Hijacking-Lücke auf, die als Einfallstor für Malware dienen kann.
Die Stümper aus Redmond
Sie können es einfach nicht, bei Microsoft! Oder anders ausgerückt: Microsoft und Sicherheit ist ein Oxymoron – gerade noch hatte ich im Beitrag US-Cyber-Experte: Microsoft ist nationales Sicherheitsrisiko a bisserl was Böses über dieses Microsoft geschrieben, da fällt mir der nächste Brocken vor die Füße.
Der „geniale Schachzug“ mit dem App-Wrapper
Gerade ist aufgeflogen, dass das Store-Team damit begonnen hat, Store-Apps neu zu packen. Die Apps werden mit einem ausführbaren .NET-Wrapper versehen, der Telemetrie und weiteren Code in die App schmuggelt. Ich hatte im Blog-Beitrag Microsoft packt Store-Apps mit Telemetrie-Wrapper über diesen Sachverhalt berichtet und mich dabei über diesen Ansatz mokiert. Ich hatte aber auch die Erklärungen des technischen Sachverhalts von Rudy Huyn, Principal Architect Microsoft Store / Copilot / Windows bei Microsoft nachgeschoben.
Der „Move“ Microsofts ist Entwicklern wie Rafael Rivera sauer aufgestoßen, weil deren App plötzlich mit einem Microsoft-Installer samt Beifang im Store auftauchen. Und mir schoss die Chip.de-Geschichte durch den Kopf, die Software aus dem Internet abgreifen, mit einem „Installer“ verpacken und den Leuten unterschieben. Mit dem Installer kommt dann bei unachtsamen Zeitgenossen unerwünschte Software auf das System – man spricht von Potentially Unwanted Software (PUP), die von Sicherheitslösungen wie dem Defender geblockt werden kann.
Cool, genial oder einfach nur übergriffig?
Mein Blog-Beitrag Microsoft packt Store-Apps mit Telemetrie-Wrapper greift den Sachverhalt auf, ist aber nicht überall auf Beifall gestoßen. Oliver hat sich hier darüber ausgelassen. Und der Kollege von deskmodder.de hat sich in diesem Kommentar darauf zurückgezogen, dass ich in meinem Blog-Beitrag „einer falschen Einschätzung“ unterlegen bin.
Wenn ich es richtig verstanden habe, wird durch den .exe-Installer die Möglichkeit geschaffen, dass man die Anwendungen nun direkt von einer Webseite installieren kann. Der Installer bewirkt dann, dass die eigentliche App aus dem Microsoft Store heruntergeladen wird und der Benutzer einen Klick spart. „Notwendig“ wird dieser App-Installer, weil man dem Nutzer einen Mausklick auf eine Schaltfläche Installieren sparen will.
Man kann sich natürlich der Einschätzung anschließen, dass die Klick-Optimierungslösung von Microsoft „die beste Erfindung seit geschnitten Brot“ darstellt. Da habe ich keine Probleme mit, wenn alle Welt das will, bitte schön. Ich halte es zwar immer noch für hinrissig, einen Wrapper um irgend etwas zu basteln, um das Ergebnis dann als installierbare .exe-Datei verteilen zu können, die bei der Ausführung dann etwas aus einem Store herunterlädt, was man auch direkt erledigen könnte.
Aber egal – nur sollte man die Hoffnung haben, dass die Entwickler einmal im Leben etwas richtig machen. Aber die Hoffnung stirbt bekanntlich zuletzt und bei Microsoft sowieso. Denn die Leute haben gleich die nächste Sicherheitslücke mit implementiert.
DLL-Hijacking vom Feinsten
Ich gestehe, ich habe mir die Details der Microsoft-Lösung am Wochenende nicht angeschaut. Aber eigentlich hätte ich es besser wissen müssen und das Ganze aus dem Blickwinkel des DLL-Hijacking mal prüfen sollen. Rafael Rivera hat das wohl kurz gemacht und weist in nachfolgendem Tweet auf die Implikationen des Microsoft Installer-Wrappers hin.
Es ist das alte Problem: Die Entwickler beherrschen ihr Geschäft nicht und haben mit dem App-Installer-Wrapper einen DLL-Hijacking-Helper vom Feinsten gebastelt. Ein Angreifer muss im Download-Ordner lediglich eigene Dateien der Art ncrypt.dll, cryptsp.dll, cryptbase.dll, bcrypt.dll, msvcp140_clr0400.dll, profapi.dll, en\StoreInstaller.resources.dll, d3d9.dll, etc. ablegen und warten. Sobald der Installer ausgeführt wird, lädt dieser die betreffenden DLLs.
Ich hatte keine DLL zur Verfügung, habe daher mal eine Datei ncrypt.dll per Texteditor fabriziert und dann in den Ordner gespeichert, aus der .exe-Installer (hier EarTrumpetInstaller.exe) ausgeführt wird. Obiges Dialogfeld ist dann die Fehlermeldung, die beim Aufruf erscheint, weil meine .DLL halt ungültig und ein Fake war. Es zeigt aber, dass der Installer versucht, die DLL aufzurufen. Rivera hat eine DLL-Datei gebaut, die sich dann mit einem kleinen Dialogfeld meldet (siehe obiger Tweet).
Das Ganze ist unter dem Begriff DLL-Hijacking bekannt: Windows sucht im Ordner des ausgeführten Programms und in bestimmten Pfaden nach den angegebenen DLL-Bibliotheksdateien. Erst wenn diese dort nichts gefunden werden, schaut Windows in den eigenen Systemordnern nach und lädt die Bibliotheken. Das ermöglicht Malware aber den Mechanismus auszunutzen, indem eine entsprechende DLL im Download-Ordner platziert wird. Die DLL wird dann fälschlich vom ausgeführten (Installer-)Programm mit geladen und ausgeführt.
Will Dormann weist in obigem Tweet auf seinem Blog-Beitrag Carpet Bombing and Directory Poisoning zum Thema hin, wo er die Hintergründe erklärt. Man möge bitte nie irgendwelche Dateien in einem Download-Ordner, aus dem ein Installer ausgeführt wird, platzieren. Man kann es auch etwas anders sehen: Wenn die Entwickler bei Microsoft ihren Job beherrschen würden, hätten sie einen voll qualifizierten Pfad zu den Systemordnern angegeben, aus denen die vom Installer benötigten DLL-Dateien zu laden sind. Hat man aber nicht, sondern verlässt sich auf die Windows-Standards. Was soll schon schief gehen?
Aber was rege ich mich auf – halten wir es doch wie Oliver hier meint: „Wenn ihr sonst keine Probleme habt… Das schlimmste überhaupt Denkbare, ja gar Unverstellbare (für so manche…) habt ihr gar nicht erwähnt: Ihr müsst Windows nutzen, und es wird tatsächlich Code von Microsoft ausgeführt (der lokale Installer u. v. m.), wenn ihr Software unter Windows installiert. Noch dreister: das gilt sogar für selbst heruntergeladene Installer – außerhalb des Store.“ Wo er Recht hat, hat er Recht – und sein Ratschlag „Herrje, nehmt doch einfach Linux und gut ist“ hat unfreiwillig etwas komisches und einen wahren Kern.
Immer wieder schön zu sehen, dass Du bei einem Thema nicht nur dran bleibst, auch wenn die ganze Welt das offensichtlich als weniger wichtig erachtet als Du, sondern es auch nicht an den – aus meiner Sicht notwendigen und berechtigten – Spitzen vermissen lässt, wenn mal wieder jemand deutlich zu überheblich daherkommt.
Danke dafür.
Eben, freut mich auch das Günter sich nicht unterbuttern lässt.
>“einer falschen Einschätzung“
>
Das war eine Dreistigkeit von den Leuten auf der anderen Seite! Es wurde hier alles im Blog belegt und den Installer zu analysieren ist leicht:
[https://github.com/icsharpcode/ILSpy]
Store Apps meide ich wie das Weihwasser ;-P
genauso wie Programme welche meinen mich bevormunden zu müssen und keine benutzerdefinierte Installation zu bieten. Auch Programme die lediglich automatische Updates bieten und Abo Software ebenso.
ich entscheide wann wo und wie!
Beim Abo gibt es lediglich zwei Ausnahmen; Banking Software und Virenschutz.
Store Apps habe ich nur Disney, Amazon Prime, Netflix, Hulu, Paramount+ und WOW, da diese auf dem Desktop im Browser lediglich kastriert funktionieren.
(Danke ContentMAFIA, not!)
Und das wird sich auch nie ändern!
/edit/
Store Apps sind an sich schon ein Risiko, da vollkommen außerhalb deiner Kontrolle!
>Programme welche meinen mich bevormunden zu müssen und keine benutzerdefinierte Installation zu bieten
>
Da rege ich mich nicht mehr drüber auf und komme mit dem Holzhammer namens NTFS junction
So kann ich das alles auf eine Daten-SSD umleiten die unerziehbare Apps wie Signal Desktop lehrt die Daten da abzulegen, wo ich sie haben will.
[https://superuser.com/questions/343074/directory-junction-vs-directory-symbolic-link/1291446#1291446]
Junctions sind so ziemlich IN ALLEM überlegen.
Ja, da hast du recht.
Beispielsweise Umgebungsvariablen, die selbst Microsoft manchmal ignoriert.
Z.B. die Umgebungsvariablen TMP und TEMP.
Da gibt es immer noch Anwendungen etc., die trotz gesetzter Umgebungsvariablen ihre Temp-Dateien stur in C:\Windows\Temp und/oder in C:\Benutzer\\AppData\Local\Temp schreiben anstatt sich an die Werte in den o.g. Umgebungsvariablen zu halten.
Oh ja! Musste beim lesen schon schaufen, wegen so Spielchen habe ich schon viele Stunden verloren :(
So unterschiedlich können die Ansichten sein. Apps die nicht aus dem Store sind kommen mir nicht auf den PC. Die Installation ist einfach und vor allem werden alle Apps automatisch aktualisiert. Und zwar ohne dass ich etwas machen muss! Früher hatte ich immer veraltete Versionen und sicher auch deswegen Viren eingefangen. Heute ist bei mir immer alles aktuell und ich habe keine Viren mehr. Tut der Sicherheit gut und spart mir viel Zeit. Für mich eine totale Bereicherung. Wer nicht will hat Pech gehabt. Niemand zwingt dich zu deinem Glück!
Glaube mir, der Store ist kein Glück. Er ist natürlich Segen für die Bequemen, die sich sonst keine Gedanken machen, was sie diese Bequemlichkeit am Ende kostet. Ich finde es allerdings amüsant, dass Du Deine Virenproblematik auf veraltete Software zurückführst und nicht etwa auf Dein Verhalten als Benutzer.
Eben, winget und chocolatey sind die besseren Stores und in Communityhand teils.
Diese Beiträge lese ich mit Vergnügen und lehne mich zurück, während ich den ganzen Tag mit Manjaro (ja unter Linux ist auch nicht alles perfekt :-) ) arbeite.
Ich bedaure immer nur meine armen Kunden, welche auf den Kram, von Microsoft & Co angewiesen sind.
Vom Grundgedanken her war der MS Store gar nicht schlecht. Weil wer kümmert sich schon bei klassisch installierten Anwendungen um Updates, wenn der Hersteller keine automatische Update Funktion integriert hat. Aber die Umsetzung war oder ist halt mal wieder kacke bei Microsoft.
Wobei sich vermutlich am Ende ger nicht so viel ändert. Bisher wurde man per Deeplink direkt zum Store umgeleitet um von dort die Installation durchzuführen. Und im Store gibt es Telemetrie ohne Ende. Jetzt wird man nicht mehr zum Store umgeleitet und der Download übernimmt die Telemetrie. Also der Punkt war vorher kacke und ist jetzt kacke, da ändert sich nicht viel.
Jetzt kommt halt noch DLL-Hijacking dazu. Entweder mit der heißen Nadel gestickt, oder irgendwelche Praktikanten am Werk
Da sind wir wieder beim Thema: „Soll es stabil, schnell und sicher sein? Oder darf es ein Produkt von M$ sein?“
Standard-Problem von M$ Produkten: erstmal alles offen machen und wenn was passiert ist der Anwender Schuld und wenn man alles absichern möchte, dann bitte nur mit einer teureren Lizenz.
Mal sehen was der Troll so schreibt :-)
Wie kann man nun gezielt eingreifen bzw. Dateien austauschen, um der Sache wieder Herr zu werden?
Den Download-Ordner sollte man mit Applocker sperren.
Runtergeladene Dateien muss man dann manuell in einen per Applocker freigegebenen Ordner kopieren, um installieren zu können. Dieser Install-Ordner sollte absolut leer sein, bevor man das zu installierende Programm dort reinkopiert.
Genauso sollte man alle Temp-Ordner und alle per Standardbenutzer beschreibbare Ordner mit Applocker sperren.
Diese „offenen“ Ordner kann man mit der „dummy.cmd“ von Stefan Kanthak anzeigen lassen. In Windows 7 gibt es erstaunlich viele solcher offenen Ordner.
www[.]borncity[.]com/blog/2021/04/05/windows-sicherheit-tester-unter-den-lesern-fr-ein-batch-script-gesucht/
Im Laufwerk C sollte man außerdem noch dem Standardbenutzer die Rechte entziehen, neue Ordner und Dateien anzulegen (via Dateisystem-Sicherheitseinstellungen). Das hilft gegen gefälschte „Mock“-Ordner mit einem Space im Namen („Windows „, „Program Files (x86) „), die vom Betriebssystem wie eigene Systemordner behandelt werden, also mitsamt Ausführungsberechtigung, was man verhindern muss.
Anleitung, um Windows 7 Ultimate zu härten:
pastebin[.]com/H4JD3UGv
Die Standard-Sicherheitseinstellungen von Windows sind katastrophal und man muss da nachträglich manuell alles verriegeln, was geht, sonst ist man offen wie ein Scheunentor.
Die Dateierweiterung .hta (HTML-Application) verknüpft man am besten auch noch mit einem Texteditor.
Falls man OneNote nicht benutzt, dann diese Dateierweiterungen ebenfalls auf Texteditor umbiegen (.one, .onepkg, .onetoc, .onetoc2), um die Malware-Schleuder abzuschalten.
Äh … Nee. Andersrum.
Du setzt Applocker ein und es ist ALLES per Default blockiert, was nicht erlaubt ist. Applocker ist ein Allowlisting Tool.
Bevor du alle Stellen findest, die du blockieren musst, definierst du nur die Stellen, die erlaubt sind.
Es gibt da aber ein Problem:
Der Applocker erlaubt diese Ordner:
„Windows“
„Program Files“
„Program Files (x86)“
Innerhalb dieser Ordner gibt es in Windows 7 aber Unterordner, in denen der Standardbenutzer Schreibrechte hat, was eigentlich nicht sein darf.
Dort könnten sich Schädlinge einnisten.
Diese Ordner muss man deswegen nochmal extra in Applocker sperren, damit die Schädlinge nicht ausgeführt werden können, falls sie es in diese Ordner geschafft haben.
In Windows 10 hingegen hat Microsoft das Problem entschärft.
Lass mal die dummy.cmd auf einem Windows 7 laufen, dann siehst du, wo man überall reinschreiben kann, obwohl das nicht erwünscht ist.
Problem Nr.2:
Mit den „Mock“-Ordnern (Space im Namen von Ordnern, die ohne dieses Space wie OS-Ordner heißen) kann man den Applocker umgehen, weil er den Namen falsch interpretiert und dann als „erlaubt“ wertet.
Es sei erlaubt in diesem Zusammenhang an
„KNOWNFOLDERID“ zu erinnern.
Das sind die magischen Zahlen, die man z.B. in Treiber.inf Dateien sieht, die zum Installieren von Software versendet werden sollten, um unabhängig von irgendwelchen obscuren Sprachen zu sein.
Wenn ich mir manche aktuelle .inf ansehe scheint das nicht mehr so gemacht zu werden…)
Schlecht allerdings, wenn einer Malware gelingt diese Pfade in den tiefen des Windows verankert, zu ändern.
Dann landen alle neuen Installationen in dem neuen Verzeichnis, das U.U. falsche Rechteeinstellungen hat.
Wer prüft schon nach, welche Pfade darin stehen und womit?
das ist so nicht richtig. applocker erlaubt die Pfade nur, wenn du die Standard Regeln integrierst.
zusatzlich solltest Du
a) die Erlauben Regel für Admins gg das System tauschen
b) die pfade excludieren in denen der CO Rechte hat.
https://www.gruppenrichtlinien.de/artikel/applocker-oder-software-restriction-policies-loecher-im-sicherheitszaun
Beides reicht nicht: (vererbbare) Zugriffsrechte für „Creator Owner“ alias S-1-3-0, „Creator Group“ alias S-1-3-1, „Creator Owner Server“ alias S-1-3-2 sowie „Creator Group Server“ alias S-1-3-3 werden beim Erzeugen NEUER Dateisystemobjekte angewendet; wird dagegen eine vorhandene Datei als HARDLINK in eines der schreibbaren Verzeichnisse gelegt, dann gelten deren unveränderte (Voll-)Zugriffsrechte, wie von meinem (auch in https://skanthak.homepage.t-online.de/SAFER.html gezeigten) Batch-Skript https://skanthak.homepage.t-online.de/download/SAFER.CMD demonstriert.
… NTFS Rechte anpassen, sodass der CO und ff keinerlei Rechte mehr hat.?
Würde per GPO Sicherheitseinstellungen\Dateisystem mit der gpttmpl.inf gehen.
Korrekt; allerdings kann das die Funktion von Windows(-Komponenten), die diese Zugriffsrechte erwarten, ETWAS stören. Zudem musst Du die GPO nach jedem Update erneut anwenden lassen. Ausserdem musst Du dann zwei Richtliniensätze pflegen: eine für SRP/SAFER bzw. AppLocker, und eine für die NTFS-Zugriffsrechte.
Ausnahmen (DENY-Regeln) in der SRP/SAFER bzw. AppLocker-Richtlinie sind die einfachere Lösung.
Vermutlich hat Microsoft den Store und UWP-Apps nur deshalb erfunden, um bewusst inkompatibel zum immer besser werdenden WINE in Linux zu werden, damit die Kunden weiterhin an Windows gebunden bleiben.
Mal eine kurze Frage als Linux-Anfänger: Sollte ich besser WINE nehme oder z.B. Virtualbox, um nur auf Win-Plattformen verfügbare Software auch unter Linux nutzen zu können?
Vielleicht hat da jemand einen Tipp für mich.
Mit WINE braucht man weniger RAM und weniger Rechenleistung als mit einer VM.
Es laufen aber nicht alle Programme mit WINE, etwa Adobe Photoshop oder CAD.
In solchen Fällen kommt man um eine VM nicht herum.
Dann allerdings wäre KVM (mit QEMU und VirtIO-Treibern) eine Alternative zu Virtualbox, weil KVM bereits in jedem Linux-Kernel integriert ist, man also keine zusätzliche Software braucht.
Vielen Dank. Das schaue ich mir alles mal an.
Da hätte ich bitte auch gleich eine Frage dazu. „Verseucht“ man sich mit WINE nicht irgendwie die Linux Installation. Gibt es da Sicherheitsschranken, Vorkehrungen, dass ein Windowsprogramm dann nicht im Linuxbereich manipulieren kann? (laso jetzt abgesehen von Userrechten)
Wenn du zum Beispiel eine Ransomware mit WINE in Linux startest, dann kann die mit deinen Userrechten auch den Inhalt in deinem Home-Ordner verschlüsseln oder löschen.
Wenn du dieses Risiko nicht eingehen willst, dann kann man bottles benutzen. Das ist WINE in einem flatpak-Container mit eingeschränkten Rechten.
Als low cost-Variante kann man im dosdevices -Ordner auch z: durch einen gleichnamigen Link ersetzen, der auf einen „ungefährlichen“ Ordner oder drive verweist – bei mir geht es auf eine RamDisk, die ich gerne zum Austausch verwende.
z: zeigt unter Linux bei mir auf /
In Wine config setzt man dann mit „link to“ auch gerne die Ordner auf andere Verzeichnisse, dann kommt man da schon nicht mehr so schnell in empfindliche Bereiche -> s. Ramsomware in Bolkos Beitrag.
Direkt angeklickte EXEs werden übrigens durch ein Script abgefangen, ich muss sie manuell über einen rechter-Mausklick-Kontexteintrag mit wine starten. Latürnich ist das total unbequem, aber man gewöhnt sich dran ;)
notify-send -t 10000 „Warnung: Exe-Datei würde geöffnet, dies wurde abgefangen!“ %f
Danke euch beiden, für die Infos. Das muss ich mir dann einmal genauer ansehen. Meist fehlt mir ja nichts aus der Windowswelt. Aber es gibt immer eine ausnahme zB die Logitech Fernbedienung. Wenn ich die einmal umprogrammieren muss, dann schaut es schlecht aus. Wenn es überhaupt noch supportet wird. Der Verkauf wurde ja auch schon beendet.
Danke!
Warum?! Wie kann das sein, DLL Highjacking ist jetzt wirklich schon ein alter Hut und dennoch immer noch ein Thema bei Microsoft. Wenn das bei alter Software passiert ok ist durchgerutscht und noch nicht entdeckt, aber bei neuer Software?!
Solche Dinge wären super einfach mit automatisierten Tests herauszufiltern und zu vermeiden…gibt da scheinbar keine Prozesse dafür bei MS.
Zitat:
„Es wird ein ausführbarer .NET-Wrapper um die Store-Apps geklatscht“
—
Der Wrapper wird nicht um die Store-App geklatscht, sondern es ist ein Installer, der die eigentliche App gar nicht enthält, denn diese wird aus dem Store runtergeladen.
Man erkennt es am Größenunterschied zwischen App (groß) und dem neuen Installer (klein).
Das meinte Deskmodder mit „einer falschen Einschätzung“ .
Eigentlich ist der neue Installer eine Alternative zur Store-App, wobei ersterer nur eine einzige App anbieten kann und letzterer alle Apps anbietet.
Na tolle Wurst – und wozu braucht Microsoft einen Installer, wenn es ein Link a la
ms-windows-store://pdp/?ProductId=9PGJGD53TN86
auch tut?
Solange nur Windows auf der Kiste laeuft oeffnet das den Windows Store exakt fuer das in ProductId angegeben Programm (hier WinDbg von MS) – egal aus welchem Browser.
„Potentially Unwanted Software (PUP)“ Der gängige Fachbegriff ist eigentlich „Potentially Unwanted Application (PUA)“, so findet man das in jeder mir bekannten Antivirensoftware als eigene Kategorie. Und aus der Abkürzung PUP kann man wohl nur „Potentially Unwanted Programm“ bilden, aber den Begriff nutzt auch niemand.
Das mit dem DLL-Hijacking ist natürlich ein grober Anfängerfehler, der MS eigentlich nicht passieren dürfte.
also ich kenne und nutze beide Abkürzungen sowohl PUP, als auch PUA. „Potentially Unwanted Software“ hätte ich aber so auch noch nicht ausgeschrieben.
In „Malwarebytes ADW-Cleaner“ und im „EmsiSoft Emergency Kit“ heißt es „PUP“.
Diese Store-Apps erinnern irgendwie an die Windows 7-Gadgets bzw. auf deutsch „Minianwendungen“. Da wurde auch erst erzählt, wie toll das alles wäre, bis einer eine „schwerwiegende Sicherheitslücke“ fand und diese dann ruckzuck eingestellt wurden. Nur, das die Store-Apps nicht eingestellt werden.
Die Store-Anwendung selbst ist ja auch nicht unsicher(er als vorher), nur der Downloader dazu, der sie aus dem Store herunterlädt.
1) NIEMAND mit mehr als einer Hirnzelle verbricht ausführbare Installationsdateien, sondern erstellt Installations“pakete“ im Standardformat der Zielplattform, für Windows *.MSI oder *.MSIX: Anfängerfehler wie DLL-Hijacking bleiben dann aussen vor: siehe u.a https://skanthak.homepage.t-online.de/!execute.html
2) nur BLUTIGE Anfänger verwenden beim Bauen ihres Schrotts NICHT LINK.exe /DEPENDENTLOADFLAG:2048: siehe o.g. Web-Seite sowie https://skanthak.homepage.t-online.de/snafu.html
3) @Guenter: Du hast doch mein komplettes Minenfeld
Hatte tief in der Nacht wohl nur die Win7-Variante auf einer Disk – da tat sich nichts. Muss mir das mal wieder neu ziehen – und die Ausnahme definieren, so dass der Defender nicht dazwischen grätscht.
Hm.. Warum knallt MS jetzt in jede App eine Telemetrie hinein, sie haben doch schon Windows mit Telemetrie. Sie bekommen doch sowieso schon alles mit…
Ein bisschen erinnert mich der Vorgang den sie hier nachbauen (ohne Telemetrie) an Installationen unter Desktop Linux (wie zB Mint / Ubuntu etc), die sind auch per einfachem Click aus dem Browser möglich – wenn man das will (!) …
Die Telemetrie ist seit mindestens Mai 2016 in NET eingebaut (seit „.NET Core RC2“ bzw seit „.NET Core 1.0 RTW „).
Alle Programme, die das NET-SDK seitdem benutzen, senden Telemetrie, wenn man das nicht manuell abschaltet.
„.NET Core telemetry was first announced in the .NET Core 1.0 RC2 and .NET Core 1.0 RTW blog announcements“
devblogs[.]microsoft[.]com/dotnet/what-weve-learned-from-net-core-sdk-telemetry/
Da steht allerdings „announced“ und es bezieht sich überspezifisch auf „Core“.
Eventuell kann diese Telemetrie also auch schon vorher enthalten gewesen sein, nur eben ohne „Ankündigung“ und auch in anderen Varianten statt „Core“.
Dann ist ja an der Ausgangsnachricht nicht mal die Telemetrie was neues, Herr Born, Sie lassen auf ihre letzten Tage/Wochen/Monate/? nach!
Bleibt DLL-Hijacking bei einer download.exe.