CEH: Threats and Defense Mechanisms: Understand steps for Testing Stack Overflow in OllyDbg Debugger

Any application development project should be managed in accordance with relevant standards for the industry in which the application will be used. Although project management, testing, development, and maturity models are outside of the scope of CEH, they play an important role in the development community.

At the very least, make sure every application meets these criteria:

No bypass of authentication is possible

No input from users that can exploit vulnerabilities

No “shrink wrap code” vulnerabilities

Shrink wrap code refers to shared program libraries and possibly to entire applications that are utilized in the creation of new products.

Dangerous functions

The most important technique in defending against buffer overflow vulnerabilities is to observe the best possible secure coding practices in the first place. In the language “C” strcpy() and strncpy() are considered vulnerable functions. Compilers exist that will root out the use of this and similar code; however, when programmers are used to a particular compiler they have worked with for 20 years and know how to keep it happy, it can be a hard political battle to get them to change. To be truthful, there must be a strong business case to even ask them; otherwise, the project deadline will be the priority.

“Bounds checking” or “input sanitizing” is the detail of making sure that a user’s first name should not be entered as 300 bytes (referring to our example). Whenever input is requested, codethat checks to see if the input meets certain criteria must be enforced . “Clean input” is defined as meeting certain constraints such as not being larger than what the malloc() (Memory allocation) function was that set up the variable size in the first place. Special characters must be properly rejected or escaped as well, meaning they are not to be processed by the interpreter but rather ignored or seen literally as just characters.

Canary bytes are placed by the programmer in the last four bytes of the variable space, also called the “stack frame.” These are checked to see if an attempt has been made to overwrite them, which would be the case in a buffer overflow exploit. This technique could also be used as a troubleshooting measure when debugging code.

Intrusion detection systems (IDS) can look for NOP sleds. However, there are many ways that a skilled and creative programmer can cause an application to do nothing for a while. The CEH exam will likely stick with 0x90 and not expect intricate knowledge of assembly bytes for various platforms, but in the real world it is important to note there is a constant game being played in this area between the good guys and bad guys. Automatic penetration testing tools have built-in noop generators for IDS evasion.

The CEH exam does not require you to be a programmer but it could show you some source code and ask about a few basics. Just to be sure, try to run the following example and look at the code carefully. If you have never written a line of C before, see if you can guess what each line means.

The opportunity from the point of view of the attacker is that clients often just accept a password from which the AES key material will be created. No matter how strong the AES implementation is, if a client application asks for a password that can be guessed then the attacker will have access.