CVE-2019-0730 : Detail

CVE-2019-0730

7.8
/
High
A01-Broken Access Control
69.84%V3
Local
2019-04-09
18h15 +00:00
2019-04-17
00h06 +00:00
CVE.org
NVD
Notifications for a CVE
Stay informed of any changes for a specific CVE.
Notifications manage

CVE Descriptions

An elevation of privilege vulnerability exists when Windows improperly handles calls to the LUAFV driver (luafv.sys), aka 'Windows Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2019-0731, CVE-2019-0796, CVE-2019-0805, CVE-2019-0836, CVE-2019-0841.

CVE Informations

Related Weaknesses

CWE-ID Weakness Name Source
CWE-264 Category : Permissions, Privileges, and Access Controls
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.

Metrics

Metrics Score Severity CVSS Vector Source
V3.0 7.8 HIGH CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Base: Exploitabilty Metrics

The Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component.

Attack Vector

This metric reflects the context by which vulnerability exploitation is possible.

Local

A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. In some cases, the attacker may be logged in locally in order to exploit the vulnerability, otherwise, she may rely on User Interaction to execute a malicious file.

Attack Complexity

This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability.

Low

Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.

Privileges Required

This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

Low

The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.

User Interaction

This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component.

None

The vulnerable system can be exploited without interaction from any user.

Base: Scope Metrics

An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges.

Scope

Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports.

Unchanged

An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same.

Base: Impact Metrics

The Impact metrics refer to the properties of the impacted component.

Confidentiality Impact

This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability.

High

There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.

Integrity Impact

This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.

High

There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.

Availability Impact

This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability.

High

There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

Temporal Metrics

The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability.

Environmental Metrics

 [email protected]
V2 4.6 AV:L/AC:L/Au:N/C:P/I:P/A:P [email protected]

EPSS

EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.

EPSS Score

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

EPSS Percentile

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.
EPSS First.org

Exploit information

Exploit Database EDB-ID : 46713

Publication date : 2019-04-15 22h00 +00:00
Author : Google Security Research
EDB Verified : Yes

Windows: LUAFV Delayed Virtualization MAXIMUM_ACCESS DesiredAccess EoP Platform: Windows 10 1809 (not tested earlier) Class: Elevation of Privilege Security Boundary (per Windows Security Service Criteria): User boundary Summary: The LUAFV driver reuses the file’s create request DesiredAccess parameter, which can include MAXIMUM_ACCESS, when virtualizing a file resulting in EoP. Description: The LUAFV is an enabled by default file system filter driver introduced in Windows Vista to support old applications which write to administrative locations such a System32 by virtualizing file access when certain criteria are met. The initial criteria is the process’ token needs to have the VirtualizationEnabled flag set to TRUE. This is done automatically for certain process types for app-compat but can be changed through NtSetInformationToken as long as the VirtualizationAllowed flag is also TRUE. This is the case for all normal users, even on Windows 10 1809. Outside of the token enable flag the file being opened must also meet a set of criteria: 1) The file being opened is in one of a number of protected locations. 2) The file can’t be owned by TrustedInstaller, but must have an ACE which grants the administrator full access. 3) The file name must not have one of a number of banned extensions, such as .exe. 4) The caller must be denied one of a set of write accesses when opening the file. If the file is virtualized a copy of the real file or directory is placed in the user’s VirtualStore inside %LOCALAPPDATA%, however for performance reasons (presumably) the driver won’t always do the copy immediately. If a caller’s file creation request meets the four criteria for a file which already exists, but a copy does not currently exist in the VirtualStore then the driver enables Delayed Virtualization on the file. This results in the file being opened with the requested access rights with the original file opened with read only access. If a caller only uses the handle for read operations then those requests are serviced by the original file. If the caller makes a “write” request such as writing to the file or mapping the file writable then the virtualization kicks in, generating the file in the VirtualStore, opening that new file for the original write access and modifies the FILE_OBJECT’s context to now read and write to the new virtualized file. The original FILE_OBJECT can’t be replaced (unlike if the store file already exists which can be dealt with using a reparse operation from the filter) therefore many of the original properties of the “fake” file handle persist such as the granted access. The vulnerability occurs in this process because during the initial filter process in LuafvPostCreate where delayed virtualization is setup the driver stores the SecurityContext->DesiredAccess as the requested access. This captured access is then used in LuafvPerformDelayedVirtualization when opening the newly created store file. As it’s possible to specify MAXIMUM_ACCESS as the DesiredAccess this results in the “fake” FILE_OBJECT’s handle access being set to FILE_ALL_ACCESS. When opening the store file MAXIMUM_ACCESS could result in a lower set access of access rights, however as the original FILE_OBJECT’s handle can’t be changed the caller can now pass file operations to the “fake” file and the driver will redirect them to the store file without further checking. Meaning if only read access was granted on the store file the user could bypass that and write to it. You can’t just pass MAXIMUM_ALLOWED on its own during file creation as the driver wouldn’t see that as meeting criteria 4. So you also need to also pass one of the banned write access rights in DesiredAccess. However for the exploit to work this must also be granted on the store file so redirecting the create to an arbitrary location (using say a mount point) isn’t sufficient. However there’s two important things to observe: 1) As long as using the FILE_OPEN_IF disposition DELETE is a considered a banned write access. 2) A hardlink to a non-writable file can be created as a normal user. As long as the user has FILE_DELETE_CHILD on the directory containing the link then they’ll also be granted DELETE on the target file. Therefore we can exploit this by doing the following: 1) Enable virtualization on the token (this works in 32 or 64 bit processes) 2) Open an existing file which would meet the rest of the virtualization criteria and isn’t currently virtualized with MAXIMUM_ALLOWED | DELETE as the access mask and FILE_OPEN_IF as the disposition. 3) Once opened the handle’s granted access will be FILE_ALL_ACCESS. 4) Create the target virtualized directory in %LOCALAPPDATA% and add a hardlink to a file to write to as the target virtualized name. 5) Perform an operation on the “fake” file handle to cause virtualization to occur, such as sending an FSCONTROL. The driver will try and virtualize the file, notice the file already exists and then open the hardlink with MAXIMUM_ALLOWED | DELETE. As DELETE is allowed this will return a read only handle with DELETE access. 6) Write to the “fake” file handle, as the handle has write access this will pass through the initial system call layers. The driver will then forward the request to the virtual file which was opened only for read but will complete successfully allowing the caller to modify a file they can’t normally write to. Fixing wise the new store file should be opened with the matching granted access on the original “fake” file handle. That way there can be no mismatch between the access granted on the “fake” handle and the backing virtual store file. It would also be interesting to know how often file virtualization is needed on modern systems and whether you could just remove it entirely. These operations can’t be done from any sandbox that I know of so it’s only a user to system privilege escalation. Proof of Concept: I’ve provided a PoC as a C# project. It will overwrite an existing file on the disk with arbitrary contents. 1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build. 2) As a normal user run the PoC and pass the path to a file to overwrite on the same drive as the virtual store. To prove it works the file should not be writable by the user normally. Note that the file needs to be shareable for write access otherwise it’ll fail due to the sharing violation. Expected Result: The virtualization operation fails. Observed Result: The virtualization operation succeeds with the string “FAKE CONTENT” written to the file. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46713.zip

Products Mentioned

Configuraton 0

Microsoft>>Windows_10 >> Version -

Microsoft>>Windows_10 >> Version 1607

Microsoft>>Windows_10 >> Version 1703

Microsoft>>Windows_10 >> Version 1709

Microsoft>>Windows_10 >> Version 1803

Microsoft>>Windows_10 >> Version 1809

Microsoft>>Windows_7 >> Version -

Microsoft>>Windows_8.1 >> Version -

Microsoft>>Windows_rt_8.1 >> Version -

Microsoft>>Windows_server_2008 >> Version -

Microsoft>>Windows_server_2008 >> Version r2

Microsoft>>Windows_server_2008 >> Version r2

Microsoft>>Windows_server_2012 >> Version -

Microsoft>>Windows_server_2012 >> Version r2

Microsoft>>Windows_server_2016 >> Version -

Microsoft>>Windows_server_2016 >> Version 1709

Microsoft>>Windows_server_2016 >> Version 1803

Microsoft>>Windows_server_2019 >> Version -

References

https://www.exploit-db.com/exploits/46713/
Tags : exploit, x_refsource_EXPLOIT-DB