[English]Hoh hoh, Leute, wir können heute das zweite Türchen im Adventskalender öffnen und schauen, was Microsoft so schönes dahinter versteckt hat, um Administratoren zu erschrecken. Heute finden wir den AppX-Installer, der in Windows 10 und Windows 11 zum Installieren von Anwendungen und Apps verwendet wird. Hier ein kleiner Überblick, warum man das Wörtchen Trusted Apps nicht so ganz wörtlich nehmen soll. Denn der zugehörige Installer kann durchaus Malware auf das System spülen (Emotet nutzt das aktuell bei Angriffen), die Apps aber wegen eines gravierenden Design-Fehlers als Trusted ausweisen.
Anzeige
Eigentlich hatte ich nicht vor, einen Sicherheits-Adventskalender zu veranstalten. Aber nachdem ich für meine deutschsprachige Leserschaft die Überraschung Microsoft Defender Version 1.353.1874.0 meldet fälschlich Trickbot/Emotet hinter das erste Türchen gepackt habe, ist mich gestern ein weiterer Fall angesprungen. Ich habe den mal hinter das zweite Türchen gepackt.
Windows 11 und die Trusted Apps
Mir ist der Fall gestern auf Twitter vor die Füße gespült worden. Ein Benutzer erhielt eine E-Mail, die den Trojaner Emotet verteilen sollten – wie der nachfolgende Tweet verdeutlicht. War glücklicherweise ein Administrator, der ein Windows Testlabor auf einem Host betreibt.
Soweit so häufig erlebt. In einer Mail wurde das Opfer angesprochen, dass man da hart gearbeitet und nun ein Update verfügbar habe. Die Mail enthielt dann einen Link, um etwas aus dem Web herunter zu laden. Und ab da wird es interessant, wenn man sich den Hut des normalen Anwenders, der irgendwann mal kurz geschult wurde, nur auf vertrauenswürdiges zu klicken, aufsetzt.
Anzeige
Der Link in der E-Mail führt dann auf eine windows.net-Webseite, die eine PDF-Vorschau mit dem Bericht verspricht (siehe vorhergehender Screenshot). Der Administrator, der den Fall auf Twitter dokumentiert hat, konnte bereits an Hand der Verweisziele erkennen, dass da was nicht koscher war. Aber so arbeitet der normales Anwender selten – der klickt auf Preview PDF. Nun soll der Dropper für die Emotet-Malware aktiv werden, indem dem Benutzer ein Installer als Download untergejubelt wird. Aber halt, wir sind ja in Windows 11, dem sichersten Windows aller Zeiten. Das weist so etwas doch sicher ab. Der Nutzer bekommt also die Seite des AppX-Installers wie in nachfolgendem Tweet angezeigt.
Der in den Tweets gezeigte Screenshot legt schon das gesamte Drama offen. Das Fenster behauptet, die Adobe PDF-Komponente installieren zu wollen. Und weil der Benutzer hoffentlich geschult wurde, nicht alles, was bei drei auf den Bäumen ist, anzuklicken, schaut der sich die Informationen im Fenster an. Da steht, dass die Komponente von Adobe käme und die Version 1.2.0.0 habe. Was aber viel wichtiger ist: Es erscheint ein Logo und ein Link Trusted App mit grünem Häkchen. Die angebotene App ist also scheinbar sicher. Nur wenn der Nutzer auf den Link Trusted App klickt, bekommt er den in obigem Tweet sichtbaren Hinweis Publisher Identity check. Dieser weist im aktuellen Fall RU, Sankt-Petersburg, BITBITE LLC aus, der als verifizierter Publisher gilt.
Im Fenster wird aber der unsignierte, willkürliche Name aus den Metadaten des App-Installationsprogramms und nicht der Name der Entität, für die das Zertifikat der digital signierten App ausgestellt wurde, angezeigt. Nur diese Signatur würde Aufschluss geben, ob die App für Adobe Inc. signiert wurde. Dazu schreibt Brian in Pitsburg:
Die Tatsache, dass der Name des Herausgebers, den man auf den ersten Blick sieht (es sei denn, man klickt auf die Details der "vertrauenswürdigen App"), der unsignierte, willkürliche Name in den Metadaten des App-Installationsprogramms ist und nicht der Name der Entität, für die das Zertifikat ausgestellt wurde, ist einfach verblüffend.
Genauso wie die schreckliche Verwendung der Bezeichnung "Trusted App" für einen Installer, der keinerlei Überprüfung, Analyse oder Reputationsprüfung durchlaufen hat.
Schreckliche Sicherheitsdialoge sind für mich der frustrierendste Aspekt von Windows/Office-Sicherheit. Und zwar genau deshalb, weil es im Grunde keine Barriere oder Kosten gibt, um sie zumindest bis zu einem gewissen Grad zu verbessern. (Und bei mehr als einer Milliarde Rechnern sind solche Verbesserungen von Bedeutung.)
Will Dormann hat es hier in mehreren Tweet auch noch aufgegriffen. Wie meint ein Nutzer dazu: Was zum Teufel [macht] Microsoft?! Wie kann so etwas Grundlegendes nicht bei mindestens einem Meeting auffallen? Geschweige denn bei der Entwurfsprüfung oder sonst wo. Was für ein Witz. Nun ja, habe ich euch nicht eine schöne Überraschung von Microsoft hinter das zweite Türchen des Sicherheits-Adventskalenders gepackt? Ob es morgen eine weitere Überraschung gibt? Wer weiß … ich weiß es jedenfalls noch nicht – we will wait and see.
PS: Kevin Beaumont hat es in diesem Tweet präzisiert. Die Emotet-Gang missbraucht weiterhin zwei Dinge: Den AppX-Installer in Windows 10/11, der das Ganze als Trusted ausweist. Und das http://windows.net Hosting, auch bekannt als Azure File Hosting. Und dort gehostete Dateien werden weiterhin nicht zeitnah gelöscht, wenn dort Malware abgelegt wird. Im obigen Fall sind die gefährlichen Downloads nach vielen Stunden auf Grund einer Abuse-Mitteilung gelöscht worden, so wie ich es mitbekommen habe.
Die Kollegen von Bleeping Computer haben die Geschichte hier aus Sicht des Emotet-Installers aufbereitet, ohne das Beef hinter dem Thema "Trusted App" aufzugreifen.
Artikel des Security-Adventskalenders
1. Microsoft Defender Version 1.353.1874.0 meldet fälschlich Trickbot/Emotet
2. Windows 10/11: Falle beim "trusted" Apps-Installer; Emotet nutzt das
3. Beispiele für Viren-Mails nach Übernahme eines Exchange-Servers
4. Phishing-Angriffe von Staatshackern über neue RTF-Template-Injection-Technik
5. BSI-Empfehlung: Reagiert nicht auf SPAM-Mails
6. Android App Barcode Scanner Lite mit Trojaner – öffnet zufällige Webseiten
7. Cyberangriff auf SPAR-Lebensmittelgeschäfte in Yorkshire/England
8. Excel XLL-Addins für Malware-Installation missbraucht
9. Hellmann Logistics Opfer eines Cyberangriffs
10. Cloud-Dienste über USB-over-Ethernet-Schwachstellen angreifbar
11. Malware in Android Apps am Beispiel von GriftHorse
12. Azure Privilege Escalation durch Missbrauch der Azure API-Permissions
13. Phishing-Angriffe auf deutsche Kunden nutzen QR-Codes, um Bankdaten zu stehlen
14. Mirai Botnet Moobot zielt auf Hikvision-Kamerasysteme
15. Windows, TPM, MEM, und Intune: Hürden beim Motherboard-Wechsel
16: Häufige Login-Versuche an Routern (FRITZ!Box)
17: Insides zu Irelands Public Healthcare Ransomware-Fall
18: Sennheiser legt Kundendaten über alte Cloud-Instanz offen
19: Analyse, wie TeamTNT Docker-Hub-Konten kompromittiert
20: CPUID Enumerator and Decoder: Virenfrei, aber von Virustotal geflaggt
21: Google Play Protect: Bei Android-Sicherheitstests im Sommer 2021 durchgefallen
22: Tipps für mehr Schutz gegen Smishing-Attacken
23: BSI warnt: Erhöhte Bedrohung durch Ransomware-Angriffe zu Weihnachten
24: Google Zweifaktor-Authentifizierung (2FA), was man wissen sollte
Anzeige
Ist jemandem bekannt ob diese Installation mit den Standardrechten eines Benutzers möglich ist oder wären in einem solchen Fall für die Installation mindestens lokale Administratoren-Rechte erforderlich?
Gruß Singlethreaded
Wenn das um APPX-Pakete geht, die kann ein User ohne Adminrechte installieren.
Auf die ganz Schnelle habe ich nichts zu side-by-install gefunden – aber bei UWP Apps aus dem Store sind keine Administrator-Berechtigungen erforderlich – das Zeug wird lokal installiert. Und wenn man es schafft, eine Malware lokal zu installieren, sind Mimikatz & Co. nicht weit.
Die Kollegen von Bleeping Computer haben offenbar ein Beispiel in die Finger bekommen und durchgetestet. In diesem Artikel beschreiben Sie die Details, die ich aus Aufwandsgründen weggelassen habe (und weil es mir um das Thema "Trusted Apps" allgemein ging).
Anschließend wird die Malware bei jedem Login des Benutzers ausgeführt.
Die von jedem nicht völlig merkbefreiten Windows-Administrator seit 20 Jahren konfigurierbaren Softwarebeschränkungsrichtlinien (siehe https://skanthak.Homepage.t-online.de/SAFER.html) verhindern das Ausführen ausserhalb geschützter Verzeichnisse wie C:\Windows\ und "C:\Program Files\" abgelegter DLLs und anderer Dateien.
Die Software-Restriction-Policies helfen aber nicht bei Modern-Apps, die kann man nur mit Applocker sperren.
Können wir die nächsten Kalendertürchen bitte einfach zu lassen? Ich würde den Microsoft-Adventskalender gerne zurückgeben. Ist ja anscheinend mangelhafte Ware.
Nö, mit Rückgabe ist nicht, das Ding ist ja jetzt benutzt ;-). Ob ich es aber bis zum 24.12. durchhalte, weiß ich nicht – ist so eine spontane Spielerei und spinnerte Idee gewesen – aber nun sehe ich sicherheitstechnisch einfach saure Gurkenzeit – nix los auf der Gass. Vielleicht sollte ich mal in meiner Halde "musst Du unbedingt drüber bloggen" graben – vielleicht ist da noch was zu finden :-).
Das zeigt sehr gut, wei kaputt das ganze Windows Ecosystem ist. dazu gehören auch Anwendungen wie Adobe Viewer. Grundsätzlich benutze ich keinen Adobe Viewer. Manchmal bin ich aber aus blödsinnigen restriktionen der IT dazu gezwunden. Zusätzliche Apps oder gar JS und ähnlichen Schnickschnack ist abgewählt. Wenn hier ein Link auf ein pdf Dokument nicht auf eine simple .pdf Datei zeigt, weg damit. Doch genau solche referenzen erzeugt das völlig falsch designte Ecosystem rund um Windows. Es ist einfach broken by design.
Absolut richtig. Das passiert, wenn Sicherheit immer erst im Nachgang implementiert wird und bei jeder Gelegenheit der Bequemlichkeit Vorrang gegeben wird.
Zitat: "Hoh hoh, Leute, wir können heute das zweite Türchen im Adventskalender öffnen und schauen, was Microsoft so schönes dahinter versteckt hat, um Administratoren zu erschrecken."
Genau so kommt mir das häufig vor :-)
Brad Duncan ist der "WireShark-Guru" von PaloAlto, einer IT-Security-Firma:
https://www.malware-traffic-analysis.net/index.html
https://isc.sans.edu/forums/diary/TA551+Shathak+pushes+IcedID+Bokbot/28092/
und
https://unit42.paloaltonetworks.com/
Danke, war mir entglitten.
Lässt sich der AppX-Installer nicht "einfach irgendwie" deaktivieren (ohne "Nebenwirkungen"?), so dass Applikationen auf diesem Weg nicht mehr installiert werden können?
Der Installer ist auch für Updates da, und es gibt garantiert ein paar vorinstallierte APPX, wo du froh bist, dass sie sich trotz gesperrtem Store regelmäßig aktualisieren…
Hab mal ein wenig rumgesucht, u.a. "BlockNonAdminUserInstall" in Kombination mit "AllowAllTrustedApps" & "AllowDevelopmentWithoutDevLicense" sollte dort helfen können, "BlockNonAdminUserInstall" gibt es aber offenbar erst ab Version 2004:
– https://docs.microsoft.com/en-us/windows/msix/group-policy-msix
– https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.Appx::BlockNonAdminUserInstall
Ohne "BlockNonAdminUserInstall" lassen sich AppX-Pakete wohl nur aus dem Store installieren.
Wenn der Store deaktiviert ist sollte AppX-mäßig wohl alles "dicht" sein.
Ich persönlich benötige den Store ohnehin nicht und habe den auch zum Teil inklusiver aller AppX-Pakete deinstalliert.
Das ist genau was passiert, wenn die Anwender genügend aufgeklärt sind, würden sie sich im Klaren sein, wenn einem eine Aktualisierung für eine Anwendung per E-Mail angeboten wird: Zum mindesten erst die E-Mail als sehr Suspekt melden und gleichzeitig Rücksprache mit den Admins halten. Falls nicht sofort oder gar nicht möglich, die originale Website des Anwendungsanbieters besuchen und suchen, ob eine Aktualisierung bevorsteht, oder nicht. Falls ja, immer die Aktualisierung direkt vom Anbieter beziehen. Das kann sowohl mit Windows als auch mit anderen Betriebsystemen passieren. Eine Tür wird sich immer öffnen lassen.
Bitte einmal den Beitrag *inklusive* des verlinkten Twitter-Postings lesen:
Hier wird keine "Aktualisierung für eine Anwendung per E-Mail angeboten", sondern es handelt sich um eine der üblichen Maschen:
Es wird eine E-Mail mit einem Link zu einem Dokument verschickt. Beim Aufruf dieses vermeidlichen "Dokuments" erhält der Anwender eine Meldung, dass dazu ein Programm / Plugin / Reader installiert bzw. aktualisiert werden müsse wobei es sich aber um einen Malware-Dropper handelt.
Das Problem ist jedoch, dass diese schädliche AppX-Applikation ist mit einem gültigen Zertifikat signiert ist und kann als solche offenbar mit User-Berechtigungen installiert werden!
Mea culpa. Nochmals sorry für die irreführende Erklärung meinerseits.
Der Vorposter hat ja schon was geschrieben. Die Mär mit dem "aufgeklärten Anwender" kann ich nicht mehr hören. Stelle dir selbst mal die Frage, wie oft Du auf einer https-Seite im URL-Feld des Browsers die Zertifikatekette auf Herz und Nieren prüft, bevor Du auf der Seite aktiv wirst …
Und noch was: Wenn Größen aus der Sicherheitsszene wie Brad Duncan, Kevin Beaumont oder Will Dormann über den Sachverhalt diskutieren, ist das ein "dicker Hund" und kein Pippi-Fax a la "wäre der Anwender besser aufgeklärt und hätte nachgedacht". Ich mein ja nur …
Das mit dem Prüfen der URL in der Mail ist nicht so ganz einfach… Habe gerade so eine HTML-Mail analysiert, die hat die eigentliche URL in einem kodierten Javascript versteckt… Aber gut, wenn man Leute hat, die inzwischen so gut sensibilisiert sind, dass sie den Braten riechen. ich mein, ist schon plump, wenn man auf eine Webseite gelockt werden soll, um dort ein FAX abzurufen… (kam das vom Gesundheitsamt… *scnr*)
Hallo,
ist die im Standard nicht vorinstallierte Store-App "App-Installer" (https://www.microsoft.com/de-de/p/app-installer/9nblggh4nns1?activetab=pivot:overviewtab) Vorrausetzung, damit die Schadsoftware über den Browserlink "ms-appinstaller:?source=badlink.appinstaller nachgeladen werden kann?
Wie schaut es bei euch aus, ist die Store-App "App-Installer" im Standard bei euch auch nicht installiert oder doch?
Wenn nicht, könnte der Einfallsweg über die Linkverknüpfung "ms-appinstaller:" ins Leere laufen, da das der Browser / Betriebssystem für den Pfad „ms-appinstaller:" keine zugehörige App finden kann.