[German]I just reported how the Store team has started repackaging Store apps. An executable .NET wrapper is slapped around the store apps, which smuggles telemetry and other code into the app. This is intended to simplify the installation of store apps and save a click. And by the way, the Microsoft strategists have also opened up a DLL hijacking gap that can serve as a gateway for malware.
Advertising
The App wrapper fail from Redmond
They just can't do it, at Microsoft! Or to put it another way: Microsoft and security is an oxymoron – I had just written something nasty about Microsoft in the article US cyber expert: Microsoft is a national security risk when the next chunk came to my view.
It has just come to light that the Store team has started repackaging Store apps. The apps are provided with an executable .NET wrapper that smuggles telemetry and other code into the app. I reported on this in the blog post Microsoft packs Store apps with telemetry wrapper and mocked this approach. However, I also provided an explanation of the technical facts from Rudy Huyn, Principal Architect Microsoft Store / Copilot / Windows at Microsoft.
Microsoft's "move" has pissed developers like Rafael Rivera because their apps are suddenly appearing in the store with a Microsoft installer and "other goodies". If I have understood correctly, the .exe installer makes it possible to install Microsoft store apps directly from a website. The installer then causes the actual app to be downloaded from the Microsoft Store, saving the user a click. This app installer is "necessary" because you want to save the user a click on the Install button.
Of course, you can agree with the assessment that Microsoft's click optimization solution is "the best invention since sliced bread". I have no problem with that, if that's what the world wants, fine. I still think it's a bit crazy to build a wrapper around something in order to distribute the result as an installable .exe file, which then downloads something from a store when executed that could also be done directly.
But never mind – just hope that the developers do something right for once in their lives. But hope dies last, as we all know, and at Microsoft anyway. Because they have implemented the next security vulnerability at the same time.
Advertising
DLL hijacking at its best
I confess, I didn't look at the details of the Microsoft solution at the weekend. But I really should have known better and checked the whole thing out from the perspective of DLL hijacking. Rafael Rivera seems to have done this briefly and points out the implications of the Microsoft installer wrapper in the following tweet.
It's the old problem: the developers don't know their business and have created a DLL hijacking helper of the finest kind with the App Installer Wrapper. All an attacker has to do is create their own files of the type ncrypt.dll, cryptsp.dll, cryptbase.dll, bcrypt.dll, msvcp140_clr0400.dll, profapi.dll, en\StoreInstaller.resources.dll, d3d9.dll, etc. within the download folder and wait. As soon as the installer is executed, it loads the relevant DLLs.
I didn't have a DLL available, so I created a file ncrypt.dll using a text editor and then saved it in the folder from which the .exe installer (here EarTrumpetInstaller.exe) is executed. The above dialog box is the error message that appears when I call it up because my .DLL was invalid and a fake. However, it shows that the installer is trying to call the DLL. Rivera has built a DLL file that responds with a small dialog box (see tweet above).
The approach is known as DLL hijacking: Windows searches in the folder of the executed program and in certain paths for the specified DLL library files. Only if nothing is found there does Windows look in its own system folders and load the libraries. However, this allows malware to exploit the mechanism by placing a corresponding DLL in the download folder. The DLL is then falsely loaded and executed by the executed (installer) program.
In the above tweet, Will Dormann refers to his blog post Carpet Bombing and Directory Poisoning, where he explains the background. Please never place any files in a download folder from which an installer is executed. You can also look at it a little differently: If the developers at Microsoft knew their job, they would have provided a fully qualified path to the system folders from which the DLL files required by the installer are to be loaded. But they didn't, instead relying on the Windows standards. What could possibly go wrong?
Advertising
