After my previous disclosure with Windows defender and Windows Setup, this is the next one
First of all, why ? it’s because I can, and because I need a job.
In this blog
I will be disclosing about 8 0-day vulnerability and all of them are still
unknow to the vendors, don’t expect those bugs to be working for more than a
week or two cause probably they will release an emergency security patches to
fix those bugs.
Avast antivirus
a. Sandbox
Escape
So avast antivirus (any paid version) have a feature called Avast sandbox, this feature allow you to test suspicious file in sandbox. But this sandbox is completely different from any sandbox I know, let’s say windows sandboxed apps are running in a special container and also by applying some mitigation to their tokens (such as: lowering token integrity, applying the create process mitigation…) and other sandboxes actually run a suspicious file in a virtual machine instead so the file will stay completely isolated. But Avast sandbox is something completely different, the sandboxed app run in the OS and with few security mitigation to the sandboxed app token, such as removing some privileges like SeDebugPrivilege, SeShutdownPrivilege… while the token integrity stay the same, while this isn’t enough to make a sandbox. Avast sandbox actually create a virtualized file stream and registry hive almostly identical to the real one, while it also force the sandboxed app to use the virtualized stream by hooking every single WINAPI call ! This sounds cool but also sound impossible, any incomplete hooking could result in sandbox escape.
Btw, the virtualized file stream is located in “C:\avast! sandbox”
While the
virtualized registry hive exist in “H****\__avast! Sandbox” and it look like
there’s also a virtualized object manager in “\snx-av\”
So normally
to make any escape I should read any available write-ups related to avast
sandbox escape, and after some research it look like I found something: CVE-2016-4025 and another bug by google project zero.
Nettitude Labs covered a crafted DeviceIoControll call in order to escape from the virtualization, they noticed after using the “Save As” feature in notepad the actual saved file is outside the sandbox (in the real filesystem) and it look like it’s my way to get out
I selected their way by clicking on “Save As” and it don’t seems to be working because the patch has disabled the feature but instead of clicking on “Save As” I clicked in “Print”
By doing
that it look like we got another pop-up so normally I clicked print with the
default printer “Microsoft XPS Document Writer”
And yup we
will have a “Save As” window after clicking on Print
So clicked
on Save, I really didn’t expected anything to happen but guess what
The file was
spawned outside the virtualized file stream. That’s clearly a sandbox escape.
How ? it
seems look like an external process written the file while impersonating
notepad’s access token. And luckily since CVE-2020-1337 I was focused on learning the
Printer API by reading every single documentation provided by Microsoft, while
in other side. James Forshaw published something related to a windows sandbox
escape by using the Printer API here.
So I assume we can easily escape from the sandbox if we managed to call the Printer API correctly, so we will begin with OpenPrinter function
And of
course we will specify in pPrinterName the default printer that exist on a
standard windows installation “Microsoft XPS Document Writer”
Next we will
go for StartDocPrinter function which allow us to prepare a
document for printing and the third argument looks kinda important
So we will take a look in DOC_INFO_1 struct and there’s some good news
It look like the second member will allow us to specify the actual file name so yeah it’s probably our way out of Avast sandbox.
So what now,
we can probably see the file outside the sandbox, but what about writing things
to the file. After further research I found another function which work like WriteFile it’s WritePrinter
Then the
final result will look like this
Note: The
bug was reported to the vendor but they didn’t replied as usual
a. Privilege
Escalation
It was a bit hard to find a privilege escalation but after taking some time, here you go Avast, there’s a feature in Avast called “REPAIR APP” after clicking on it, it look like a new child process is being created by Avast Antivirus Engine called “Instup.exe”
Probably
there’s something worthy to look there, after attempting to repair the app. In
this case we will be using a tool called Process Monitor
And as usual
we got something that worth our attention, the instup process look for some non
existing directories C:\stage0 and c:\stage1
So what if
they exist ?
I created
the c:\stage0 directory with a subfile inside it and I took a look on how the
instup.exe behave against it and I observed an unexpected behaviour, instead of
just deleting or ignoring the file it actually create a hardlink to the file
we can exploit the issue but the issue is that the hardlink have a random name and guessing it at the time of the hardlink we can redirect the creation to an arbitrary location but unluckily the hardlink random name is incredible hard to guess, if we attempted who know how much time it will take so I prefer to not look there instead I started looking somewhere else
In the end of the process of hardlink creation, you can see that both of them has been marked for deletion, probably we can abuse the issue to achieve an arbitrary file deletion bug.
I’ve created
an exploit for the issue, the exploit will create a file inside c:\stage0 and
will continuously look for the hardlink. When the hardlink is created the poc
OpLock it until instup attempt to delete it, then the poc will move the file
away and set c:\stage0 into junction to “\RPC CONTROL\” which there we will
create a symbolic link to redirect the file deletion to an arbitrary file
Note: This bug wasn’t reported to the vendor.
PoC can be found here
McAfee Total Security
a. Privilege
Escalation
I already
found bugs on this AV before and got acknowledged by vendor
For
CVE-2020-7279 and CVE-2020-7282
CVE-2020-7282 was for an arbitrary file deletion issue in McAfee total protection and CVE-2020-7279 was for self-defence bypass.
The McAfee total security was vulnerable to an arbitrary file deletion, by creating a junction from C:\ProgramData\McAfee\Update to an arbitrary location result in arbitrary file deletion, the security patch was done by enforcing how McAfee total security updater handle reparse point.
But the most
important is C:\ProgramData\McAfee\Update is actually protected by the self
defence driver, so even an administrator couldn’t create files in this
directory. The bypass was done by open the directory for GENERIC_WRITE access
and then creating a mount point to the target directory so as soon the updater
start it will delete the target directory subcontent.
But now a
lot has changed, the directory now has subcontent (previously it was empty by
default),
After doing
some analysis on how they fixed the self defence bug. Instead of preventing the
directory opening (as it was expected) with GENERIC_WRITE they blocked the
following control codes FSCTL_SET_REPARSE_POINT and FSCTL_SET_REPARSE_POINT_EX from
being called on a protected filesystem component, I expected
FSCTL_SET_REPARSE_POINT_EX but no they did a smart move in this case, so if we
didn’t bypass the self defence we don’t have any actual impact on the
component.
So this is
it, this is as far as I can go… or no ?
a. Novel way to
bypass the self defence
This method
work for all antiviruses which the filesystem filter.
So how does the kernel filter work ?
The filesystem filter restrict the access to the antivirus owned objects, by intercepting the user mode file I/O request, if the request coming from an antivirus component it will be granted, if not it will return access denied.
You can read
more about that here, I already wrote some of them but
for some private usage so for the moment I can’t disclose them, but there’s a
bunch of examples you can find by example: here
So as far as
I know there’s 2 way to bypass the filter
1. Do a special
call so it will be conflicted by what the driver see
2. Request access
from a protected component
So the
special way was patched in CVE-2020-7279, the option that remain is the second
one. How can we do that ?
The majority of the AV’s GUI support file dialog to select something let’s take by example McAfee file shredder which open a file dialog in order to let you choose to pick something
While the file dialog is used to pick files it be weaponized against the AV, to better understand the we need to make an example code, so I had to look for the API provided by Microsoft to do that. Generically apps use either GetOpenFileNameW or IFileDialog interface and since GetOpenFileNameW seems to be a bit deprecated we will focusing in IFileDialog Interface.
So I created
a sample code (it look horrible but still doing the job)
After
running the code
It look like that the job is being done from the process not from an external process (such as explorer), so technically anything we do is considered to be done as the process.
Hold on, if the things are done by the process. Doesn’t that mean that we can create a folder in a protected location ? Yes we can
c. Weaponizing
the self-protection bypass
The
CVE-2020-7282 patch was a simple check against reparse points, before managing
to delete any directory.
There’s a simple check to be done, if FSCTL_GET_REPARSE_POINT
control on a directory return anything except STATUS_NOT_A_REPARSE_POINT the
target will removed else the updater will delete the subcontent as
“NT AUTHORITY\SYSTEM”
Chaining it together, I’ve an exploit which demonstrate the
bug, first a directory in C:\updmgr will be created and then you should
manually move it to C:\ProgramData\McAfee\Update an opportunistic lock will
trigger the poc to create a reparse point to the target as soon as the AV GUI
attempt to move the folder, the poc will set it to reparse point and will lock
the moved directory so it will prevent the reparse point deletion.
PoC can be found here
Avira Antivirus
Anyway it look like there’s a feature come with Avira Prime
called Avira System Speedup Pro, I can’t still explain why this behaviour exist
in Avira System Speedup feature but yeah it exist.
When starting the Avira System Speedup Pro GUI there’s an
initialization done by the service “Avira.SystemSpeedup.Service.exe” which is
written in C# which make it easier to reverse the service but I reversed the
service and things just doesn’t make any sense so I guess it’s better to show
process monitor output to understand the issue.
without even checking for reparse point. It’s extremely easy
to abuse the issue.
This time instead of writing a c++ PoC I’ll be writing a
simpler one as a batch script. The PoC in this case doesn’t need any user
interaction, and will delete the targeted directory subcontent.
PoC can be found here
1 Trend Micro Maximum security
I already discovered an issue in trend micro and it was
patched in CVE-2020-25775, I literally just found a high
severity issue on trend micro. But I was contracted for so I can’t disclose it
here.
Moving out, as other AV’s there’s a PC Health Checkup
feature, it probably worth our attention.
While browsing trough the component, I noticed that there’s a
feature “Clean Privacy Data” feature.
I clicked on MS Edge and cleaned, the output from process monitor was:
And as you see Trend Micro Platinum Host Service is deleting
a directory in a user write-able location without proper check against reparse
point while running as “NT AUTHORITY\SYSTEM” which is easily abuse-able by a
user to delete arbitrary files.
There’s nothing to say more, I created a proof of concept as
a batch script after running it expect the target directory subcontent to be
deleted.
PoC can be found here
MalwareBytes
I will using the same technique explained above to bypass the
self protection.
While checking for updates, the antivirus look for a non
existing directory
Hmmmm, let’s take a look
The pic shown above, show us that Malwarebytes antivirus
engine is deleting every subcontent of
C:\ProgramData\Malwarebytes\MBAMService\ctlrupdate\test.txt.txt and since
there’s no impersonation of the user and literally no proper check against
reparse point we can probably abuse that, by creating a directory there and
creating a reparse point inside
C:\ProgramData\Malwarebytes\MBAMService\ctlrupdate we can redirect the
file deletion to an arbitrary location.
The PoC can be found here
1 Kaspersky
The AV which I engaged with the most, about 11 bugs were reported and 3 of them were fixed.
For the moment I will be talking about a bug which I already disclosed here, this PoC will spawn a SYSTEM shell as soon as it succeed, the bug seems to be still existing on Kaspersky Total Security with December 2020 latest security patches, the only issue you will have is the AV will detect the exploit as a malware, you must do some modification to prevent your exploit from being deleting. Let’s I can confirm that the issue still exist.
One more thing
Another issue I discovered in all Kaspersky’s antiviruses
which allow arbitrary file overwrite without user interaction. I’ve already
reported the bug to Kaspersky but they didn’t gave me a bug bounty
They said that the issue isn’t eligible for bug bounty
because the reproduction of the issue is unstable, ain’t gonna lie I gave them
a horrible proof of concept but still do the job so I guess it should be
rewarded and since they wrote that they gave bounties. I won’t give bugs for
free like a foo.
So let’s dive inside the bug, when any user start Mozilla
Firefox, Kaspersky write a special in %Firefox_Dir%\defaults\pref while not
impersonating the user or not even doing proper links check, if abused
correctly it can be used against the AV to trigger arbitrary file overwrite
on-demand without user interaction.
A proof of concept is attached implement the issue, I’ve rewritten a new one which will trigger your needs on demand thanks me later.
PoC can be found here
Windows
First, if you’re not familiar with windows installer CVE-2020-16902,
it’s literally the 6th time I am bypassing the security patch and
they still don’t hire security researchers. I will be using the same package as
CVE-2020-16902
Microsoft has patched the issues by checking if c:\config.msi
exist, if not it will be used to generate rollback directory otherwise if it exist
c:\windows\installer\config.msi will be used as a folder to generate rollback
files.
A tweet by sandboxescaper mentioned that if a registry key “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders\C:\Config.Msi”
existed when the installation begin, the windows installer will use
c:\config.msi as a directory rollback files. As an unprivileged user I guess
there’s no way to prevent the deletion or create “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders\C:\Config.Msi”
And as usual there’s always something that worth our
attention.
When the directory is deleted, there’s an additional check if
the directory exist or not. Which is kinda strange, since the RemoveDirectory
returned TRUE
I guess there’s no need to make additional checks. I am
pretty sure that there’s a bug there, I managed to create the directory as soon
the installer delete and this happened
The installer did a check if the directory exist and it
return that the directory exist, so the windows installer won’t delete the
registry key “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders\C:\Config.Msi”
because the directory wasn’t delete.
In the next installation the C:\Config.Msi will be used to
save rollback files on it, which can be easily abused (I’ve already done that
in CVE-2020-1302 and CVE-2020-16902).
I’ve provided a PoC as c++ project to exploit the issue, it’s
a double click to SYSTEM shell, thank me later again.
