There was a discussion in the comments as to whether this could be considered a vulnerability. But I was hooked on one comment by the author:
Could this be implemented, for example, in the form of a DLL, which, when called by its API, would check the digital signature of the calling program?
The fact is that just before that, I researched several programs that relied on digital signature verification in the same way. And this check was very easy to get around.
The digital signature of a file only matches the executable itself, but a running program is not just an executable. There are several ways to influence the operation of the program without changing the executable file: you can replace libraries that are loaded or inject code directly into memory.
I looked at the author's profile: "Works in: Doctor Web". But what if you look to see if this company's products use the check that the author is talking about? I decided to look and, spoiler, found a vulnerability that allows you to elevate your privileges to the system user Dr.Web Security Space for Windows.
Intelligence service
I don't understand Doctor Web products, so I took the first one that I could download on the website - it was Dr.Web Security Space 12 for Windows. At default settings, this product checks for updates every half hour. And a vulnerability was found in the update mechanism.
Below I offer an operation video describing what happens in the video with a reference to time. There will also be a description of what exactly the vulnerability was.
Operation video
The demo runs on Windows 10 x64 from a user without administrator rights.
0: 00-0: 12 show through the Windows console that the current user is not an administrator
0: 12-0: 24 show the installed version of Dr.Web Security Space
0: 24-0: 29 drweb_eop_upd_dll.dll file is located in the folder on the desktop (source codes and the file are attached to the ticket)
0: 29-0: 34 I show that there are 3 files in the C: \ ProgramData \ Doctor Web \ Updater \ etc
folder 0: 34-0: 47 I copy the drweb_eop_upd_dll.dll library in the folder on desktop and one copy I call version.dll, another - cryptui.dll
0: 47-0: 56 I copy the file C: \ Program Files \ Common Files \ Doctor Web \ Updater \ drwupsrv.exe to the folder on the desktop, next to the dll ...
0: 56-1: 00 run the copied file
The drwupsrv.exe executable file from the folder on the desktop loads the version.dll located nearby. This library creates the file C: \ ProgramData \ Doctor Web \ Updater \ etc \ drwupsrv.xml.new. The user has rights to create files to the C: \ ProgramData folder and deep down, so this is a legal operation. If you try to create such a file manually, it is likely that Dr.Web's security mechanisms prevent such an operation. But in operation, the file is created on behalf of drwupsrv.exe, which probably bypasses internal checks and the file is created. In fact, this is a bypass of the very signature verification that is discussed at the beginning of the article.
1: 00-1: 22 am demonstrating the created file and its contents. In a general sense, the file has the same content as the file C: \ ProgramData \ Doctor Web \ Updater \ etc \ drwupsrv.xml, but all paths point to a folder on the desktop (C: \ Users \ User \ Desktop \ dwtest)
1: 22-2 : 00 nothing happens (at this stage I am waiting for the software update process, which by default happens every half hour and the expected time can be found in the logs)
2: 00-2: 14 apparently, taking the created configuration file, the updater sees that there are no Dr.Web software files in the C: \ Users \ User \ Desktop \ dwtest folder, it starts copying the software files there.
The copied files include the dwservice.exe file, which is launched at the time of the update as the NT AUTHORITY \ SYSTEM user. This file loads the cryptui.dll library, which was in the C: \ Users \ User \ Desktop \ dwtest folder. The library code simply launches the interactive console, which is visible on the screen. Use the whoami command to make sure that the system rights are obtained.
Summary
The vulnerability report was sent to Doctor Web and, it seems, the developers have fixed everything.
Timeline:
05/15/2020 - Contacting technical support with a request to provide a security contact.
05/20/2020 - I receive an answer that it is possible to submit a report in this appeal
05/20/2020 - I transmit a report
06/14/2020 - I receive an answer that the vulnerability has been fixed for version 12. Awaiting porting for version 11.
07/07/2020 - The developers confirm that the fixes have been released.
This article in english.