Buffer Overflow Mitigation & Recommendation Technique - Part V
- Secure Development Lifecycle (SDLC) - Part VI
Mitigation / Recommendation Techniques
Windows
Since, security have become the most important part from an organisation point of view. Security Measures must be taken to ensure our data are secure and is private. Below are some of the security measures that should be taken for the protection from the Buffer Overflow attack.
The following are the techniques that are discussed below:
DEP
ASLR
SafeSEH
Stack Cookies/GS protection
SEHOP
Follow SDLC
Data Execution Prevention (DEP)
Thus, to mitigate this Windows introduced DEP, a system-level protection that marks these memory locations as non-executable. In short, we need to remember that DEP will make it significantly harder to run exploits from the memory. For the Security purpose we should enable DEP from the Server side to protect the Server.
The following are the Configuration details on how to Enable DEP to safeguard from the attack:
-
Enable DEP using GUI
- Right click on My Computer --> choose Properties →Advanced System Settings--> click on the Advanced tab --> Settings under Performance.
Figure 1. System Properties
- Now click on the Data Execution Prevention tab and you will see two radio buttons.
Figure 2. Turning on DEP
- Here is where it can be a bit tricky. By default, DEP should be set to the first radio button and therefore only protect essential Windows programs and services. If the second radio button is selected, it will turn on DEP for ALL processes, not just Windows processes.
- Select the first radio button and restart the computer.
- Enable DEP using CUI
- We can turn on DEP by using command prompt too. To do this run command prompt with admin and type the following command:
- Always On - DEP will be on for all processes in Window and you cannot exempt any process or program from protection.
- To always turn off DEP, type the following command:
- Always Off - DEP will be completely turned off and no process or program, including Windows processes, will be protected.
Figure 3. Turning on and off DEP using Command Prompt
- Enable DEP in Visual Studio
- We can also enable DEP in our server side from Visual Studio 2016 which we used to create the Vulnerable Server. Click on Debug→ Vulnerable Server Properties.
Figure 4. DEP in Visual Studio
- Click on Linker → All Options→ Data Execution Prevention → Yes(/NXCOMPAT) as shown in above figure.
Enhance Address Space Layout Randomization (ASLR)
ASLR is a computer security technique which involves randomly positioning the base address of an executable and the position of libraries, heap, and stack, in a process's address space. The random mixing of memory addresses that are performed by ASLR means that an attack no longer knows at what address the required code (such as functions or ROP gadgets) is located. That way, rather than removing vulnerabilities from the system, ASLR attempts to make it more challenging to exploit existing vulnerabilities.
- Enable ASLR in Visual Studio
- To configure ASLR in Visual Studio, navigate to Debug → Vulnerable Server Properties -> Linker -> Advanced -> "Randomized Base Address"--> Yes (/DYNAMICBASE)
Figure 5. Enable ASLR
- /DYNAMICBASE modifies the header of an executable to indicate whether the application should be randomly rebased at load time by the OS. The random rebase is well known as ASLR (Address space layout randomization).
SafeSEH
Windows introduced the SafeSEH protection mechanism in which validated exception handlers are registered and stored in a table. The addresses in this table are checked prior to executing a given exception handler to ensure it is deemed “safe”. As a result, a POP+POP+RET address used to overwrite an SEH record that comes from a module compiled with SafeSEH will not appear in the table and the SEH exploit will fail.
SafeSEH is effective at preventing SEH-based exploits as long as the SEH overwrite address (e.g. POP+POP+RET) comes from a module compiled with SafeSEH. The good news (from an exploitability perspective) is that application modules are not typically compiled with SafeSEH by default. Even if most are, any module loaded by an application that was not compiled with SafeSEH can be used for your SEH overwrite.
Some additional protection was added to compilers, helping to stop the abuse of SEH overwrites. This protection mechanism is active for all modules that are compiled with /safeSEH.
- Enable SafeSEH in Visual Studio
- To turn on Safe SEH in Visual Studio navigate to Debug → Vulnerable Server Properties -> Linker -> Advanced ->Image Has Safe Exception Handler→ YES(/SAFESEH)
Figure 6. Turn on SafeSEH in Visual Studio
- When /SAFESEH is specified, the linker will only produce an image if it can also produce a table of the image’s safe exception handlers. This table specifies for the operating system which exception handlers are valid for the image.
Stack cookie /GS protection
The /GS switch is a compiler option that will add some code to function’s prologue and epilogue code in order to prevent successful abuse of typical stack based (string buffer) overflows. When an application starts, a program-wide master cookie (4 bytes (dword), unsigned int) is calculated (pseudo-random number) and saved in the .data section of the loaded module. In the function prologue, this program-wide master cookie is copied to the stack, right before the saved EBP and EIP. (between the local variables and the return addresses). During the epilogue, this cookie is compared again with the program-wide master cookie. If it is different, it concludes that corruption has occurred, and the program is terminated.
In order to minimize the performance impact of the extra lines of code, the compiler will only add the stack cookie if the function contains string buffers or allocates memory on the stack using _alloca. Furthermore, the protection is only active when the buffer contains 5 bytes or more.
In a typical buffer overflow, the stack is attacked with your own data in an attempt to overwrite the saved EIP. But before our data overwrites the saved EIP, the cookie is overwritten as well, rendering the exploit useless (but it may still lead to a DoS). The function epilogue would notice that the cookie has been changed, and the application dies.
- Enable Security Checks in Visual Studio
- To enable Security Checks in Visual Studio, go to Debug → Vulnerable Server Properties -> C/C++ → All Options → Security Checks→ Enable Security Check (/GS)
Figure 7. Enable Security Checks in Visual Studio
- The Security Checks helps to detect stack- buffer overruns, a common attempted attack upon a Program’s Security.
Structured Exception Handling Overwrite Protection (SEHOP)
SEHOP is a protection feature which guards against the most common technique for exploiting stack overflows on Windows for applications such as the RealPlayer media player. An exploit attack can control the execution flow of software toward the attacker's shellcode by using an overwrite exception handler function. The exception handler function address is stored in stack memory and can easily be overwritten when a stack buffer overflow exists. Windows operating systems include SEHOP, but some Windows Vista operating systems disable SEHOP by default. Memory Exploit Mitigation provides protection even if SEHOP in Windows is turned off. SEHOP attacks occur on 32-bit clients only.
Configuration/Recommendation
In Visual Studio 2017, Go to the Project tab in the Menu bar and click on Properties. The following are the overall configuration details that should be done to protect from the Buffer Overflow attack:
Table 1. Configuration Details of Visual Studio 2017
References:
Geeks For Geeks
Corelan
InfoSec Institute
Technopedia
LinuxJournal
No comments:
Post a Comment