From the comment on Habré to vulnerability in Dr. antivirus Web
In the comments there was a discussion of whether this could be considered a vulnerability. But I was hooked by one author’s comment:
couldn’t it 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 that 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 company's products? I decided to take a look and, 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.
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 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 copying the drweb_eop_upd_dll.dll library to a folder on the desktop and I call version.dll one instance, cryptui.dll the other
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 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 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 bypass of the very signature verification that 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 once every half an hour and the expected time can be found in the logs)
2: 00-2: 14 apparently, having taken 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 copied files is the dwservice file.exe, which starts at the time of the update as NT AUTHORITY \ SYSTEM. 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 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 the answer that you can transfer the report in this appeal
05/20/2020 - I submit 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 fixes have been released.
This article in english. .