Windows Exploiting¶
Overview¶
In Windows exploitation, attackers often target various bugs and vulnerabilities to execute code or gain unauthorized access.
Types of Bugs:
- Out-of-bounds bugs/Buffer overflow (Stack and Heap): These occur when data is written beyond the allocated memory boundaries.
- Use after free: This happens when memory is accessed after it has been freed.
- Integer bugs, signedness bugs: These involve errors in handling integer values, such as overflow or incorrect type usage.
- Uninitialized memory: This occurs when variables are used without initializing them, leading to unpredictable behaviour.
- Null pointer dereference: This happens when the program tries to read or write to a null pointer, leading to crashes or vulnerabilities.
Attack Types:
- Code corruption attack: Involves directly modifying executable code to insert malicious code.
- Code-flow hijack attack: Alters the flow of execution, such as through Return Oriented Programming (ROP) or SEH overwrites.
- Data-only attack: Manipulates data without altering code or control flow, often to affect program logic.
- Information leak: Extracts sensitive information from memory, which can be used for further exploitation.
Stack canaries¶
Stack canaries are used to detect stack buffer overflows. Integrated into Visual Studio since 2002 (/GS flag), these are present in various Windows versions (XP SP2 and beyond). They help protect against overwriting return addresses on the stack.
General stack canary documentation: Stack Canary
Structured Exception Handler (SEH) Overwrites¶
SEH is a mechanism for handling exceptions. In SEH overwrite attacks, attackers exploit the handler located on the stack to execute arbitrary code. They overwrite the SEH with a pointer to their malicious code, taking control when an exception occurs. Mitigations like SafeSEH (whitelist of safe handlers), SEHOP (SEH Overwrite Protection), and dynamic SEH validations were introduced to prevent these attacks.
Ret2libc¶
This technique involves calling standard library functions directly to bypass security measures like DEP. Windows-specific details include the "stdcall" calling convention, where the callee cleans up the stack, and functions like VirtualProtect() are often targeted to change memory protections and execute payloads.
More details on the general concept of ret2libc can be found in our documentation on ROP.
Address Space Layout Randomization (ASLR)¶
Introduced in Windows Vista, ASLR randomizes the memory addresses used by system and application files to make it harder for exploits to predict the location of specific functions. Despite improvements in Windows 8 and later, challenges remain, such as incomplete implementation across all binaries and predictable addresses in some cases.
General documentation: ASLR & PIE
Heap Protections¶
Over the years, Windows has introduced several Heap protections. These include safe unlinking, heap hardening in Windows Vista, and additional improvements in Windows 8, such as guard pages and allocation order randomization, to make heap manipulation attacks more difficult.
Windows Version History of Mitigations¶
- Windows XP SP2: Introduced major mitigations like /GS and SafeSEH.
- Windows Vista: Added ASLR and heap protections.
- Windows 8: Enhanced ASLR and introduced more heap protections.
- Windows 10: Brought in Control Flow Guard (CFG) to prevent ROP attacks and improved kernel ASLR, along with other protections like Hypervisor-based security and enhanced protected mode for browsers.
Hypervisor-Based Security¶
Techniques like DeviceGuard, Credential Guard, and Hypervisor Code Integrity (HVCI) use virtualization to isolate and protect sensitive processes.
Control Flow Integrity (CFI)¶
Implemented with /guard:cf, this technique ensures the control flow of applications is valid, preventing many types of control flow hijacking attacks.
General documentation: CFI
Security Development Lifecycle (SDL)¶
Introduced by Microsoft as a response to early 2000s worms and attacks, SDL focuses on integrating security practices throughout the software development process. This includes threat modeling, secure coding practices, and regular security testing.\
Conclusion¶
While modern Windows versions have significantly improved exploit mitigations, they are not foolproof. Challenges like backwards compatibility, third-party software vulnerabilities, and user/administrator practices remain.