In the comments there was a discussion of whether this could be considered a vulnerability. But I was hooked by one comment by the author:
Could this be implemented, for example, in the form of a DLL that, when calling its API, would verify 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 such a check was very easy to get around.
The digital signature of the file corresponds only to the executable file itself, but a working program is not only an executable file. There are several ways to affect the operation of the program without changing the executable file: you can replace the libraries that are loaded or inject the code directly in memory.
I looked at the author’s profile: “Works in: Doctor Web.” But what if you look to see if the products that the author talks about are used in the products of this company? I decided to look and, a spoiler, found a vulnerability that could increase my privileges to system users of Dr.Web Security Space for Windows.
I do not understand Doctor Web products, so I took the first one that could be downloaded on the site – it was Dr.Web Security Space 12 for Windows. With the default settings, this product checks for updates every half hour. And a vulnerability was discovered in the update engine.
Below I offer a video of operation with a description of what is happening on the video with reference to time. There will also be a description of what exactly the vulnerability consisted of.
The demonstration takes place on Windows 10 x64 from a user without administrator rights.
0: 00-0: 12 through the Windows console I show 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 in the folder on the desktop is the drweb_eop_upd_dll.dll file (source codes and file are attached to the ticket)
0: 29-0: 34 show that in the folder C: ProgramData Doctor Web Updater etc there are 3 files
0: 34-0: 47 I copy the drweb_eop_upd_dll.dll library in the folder on the desktop and I call version.dll one instance, cryptui.dll the other
0: 47-0: 56 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 startup file from the folder on the desktop loads the nearby version.dll. This library creates the file C: ProgramData Doctor Web Updater etc drwupsrv.xml.new. The user has rights to create files on the C: ProgramData folder and deeper into the folder, so this is a legal operation. If you try to create such a file manually, then probably the Dr.Web protection mechanisms prevent such an operation. But in operation, the creation of the file takes place on behalf of drwupsrv.exe, which probably bypasses the internal checks and the file is created. In fact, this is a circumvention of the very signature verification, which is discussed at the beginning of the article.
1: 00-1: 22 show the created file and its contents. In a general sense, the file matches the contents of the file C: ProgramData Doctor Web Updater etc drwupsrv.xml, but all paths indicate the folder on the desktop (C: Users User Desktop dwtest)
1: 22-2: 00 nothing happens (at this stage I expect the software update process, which by default occurs every half an 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.
Among the files being copied is the dwservice.exe file, which is launched at the time of updating as an 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. The whoami team makes sure that the system rights are obtained.
A vulnerability report was sent to Doctor Web and, it seems, the developers corrected everything.
05/15/2020 – Contacting technical support with a request to provide a security contact.
05/20/2020 – I get an answer that you can transfer the report in this appeal
05/20/2020 – I transmit the report
06/14/2020 – I get an answer that the vulnerability has been fixed for version 12. Awaiting porting for version 11.
07/07/2020 – Developers confirm that patches have been released.