How do you perform a security test?

Ever wanted to perform a penetration test on a security system (website, application, mobile and etc.) and just didn’t know where to start?

These days, companies are very concerned about the security in their applications due to the increase in the number of disclosed vulnerabilities and exploits which can cause irreversible damage to one’s company.

So as part of the protection, applications and systems are put to a test that simulates a “real” attack but without damaging the company (testing for vulnerabilities without exploiting them).

So in this post, we will give out guidelines about that can help you in your tests!

Verify all assumptions

Avoid false negatives! – In particular, don’t take for granted any written documentation or “of course it is!” comments from technical staff. Always question what if an assumption turns out to be false. Better safe than sorry!

Avoid false positives! – This is also very true when using automated tools and scanners because they tend to produce a lot of false positives. Always double check!

Map all system components

Always prepare – Do NOT do security work on a project without mapping & understanding all of its components, at least at a basic level.

It is important to understand what is not relevant in order to avoid being distracted

So you should ask:

• What are the system’s boundaries?
• In particular, what is off-scope?

It is also very important to pay attention to sensitive points (system components which are likely to be more vulnerable) as well as common mistakes.

So lets provide some examples:

Using cryptography correctly

• Correct key length.
• Which cryptographic functions are exposed to outsiders.
• Chosen plaintext attacks (a particular case).
• Using cryptography correctly expands much further; there are cryptography check-lists online

Authentication

• Is my caller allowed to call me(a system component under consideration)?
• Should always be checked for any part of the system, except when a component allows anonymous callers.
• Authentication details: how is the authentication done? Is it done correctly?

Authorization

• Given that my caller is allowed to contact me, is it authorized to supply the particular content?
• Are the parameters valid?
• Is the timing valid? Correct point in the flow?

Extreme cases

• What do you do when something that you expect to find is missing?

Understanding the developers

It can be beneficial to try to understand the mentality of the code writer(s).

Often, components are more secure to begin with, and change with time to be less secure, commonly due to either:

• Lack of understanding in security.
• Functionality constraints which were solved by relaxing security.

Secure defaults – verify what the defaults are, especially at sensitive points. Secure defaults are a good place to dig for exploits.

Working technique

So, after we’ve presented some tips that can help in the overall penetration testing, let’s present some tips for better working technique

In short – Top-down, followed by bottom-up.

1. First overview the whole system, map its components.
2. Overview connections between system’s components. Write down any suspicious points or questions requiring further investigation for later clarification in an orderly manner. Answer these questions now only if it can be done on the fly, otherwise postpone them for later.
3. Drill down into each component, both design and code.
4. Carefully review all the points left behind. Make sure nothing has been accidentally left out.

Example for bottom-up

Suppose we found an interesting function. Consider who calls it, how it can be reached. Write down a back-trace call tree, and the system states or parameter values relevant to it.

Inspecting the system bottom-up should be done only after properly understanding it. At this point, it is very important not to rely on assumptions, design documents, presentations or such, in order to be able to think out of the box

Following the guidelines mentioned above can help achieve better results and asking the write questions when performing pen tests.

Feel free to read our other articels at: appsec-labs.com/portal

Suggested readings

If you’ve enjoyed this post and would like to know more, please consider read the following:

• Threads and Countermeasures – Document by Microsoft. Although this document is about application security, it does have several general chapters: see for example down till .NET on part 3; or at part 5, about code review. See also security checklists at the end.
• CERT C Coding Standard – A site that supports the development of coding standards for commonly used programming languages such as C, C++, Java, and Perl, and the Android™ platform