How to define entry points to solution: Building Threat Models and Attack Trees

In this article, the key takeaways of the two reports from the Testing Stage conference are represented. They deal with Security Testing and, in particular, with discovery of entry points, with scanners, and with attack trees.

This all is based on three properties of a system (confidentiality, integrity, access) and three states of information (storing, transferring, processing). Technique for detecting the entry points involves combining these system properties and information states. This technique can be applied to any system regardless whether it is a website or a desktop application.

First of all, it is necessary to divide the system into components. The level of detail depends upon schedule and budget. For example, we have here a desktop application. It communicates with OS that, in its turn, communicates with hardware. An attack can occur when transferring data between the OS and an external world: the request is intercepted and redirected back to the OS, however, to another place, which is under our control. As a result, we have conducted an attack on the information transferring process at the same time checking access to the information. In this case, it is even possible to check the confidentiality level depending on the request contents.

Here is an example of the attack tree of a web application, where we have the following components:

Based on the scheme above it is possible to build the following attack tree:

Then we need to recognize the easiest way to compromise our system. Here we mean not the shortest, but the simplest way from the point of view of attack realization. Then we determine the next one, which is more complex, and continue doing so until we get up to the most complex one. When choosing an attack, it is important to take into account where the information is stored and which confidentiality level it has. For example, if transaction data is stolen on the browser level, it is quite a shallow attack, but if it is stolen from the customer database, it is much more serious.

The software also was detailed by the reporter:

Speaking about testing components that communicate with our software, it also depends upon schedule and budget that we have at our disposal. However, the 3rd part applications can contain vulnerabilities that might affect our application. Moreover, the reporter noted that when the vendor stated that their application is 100% secure, it meant that it was protected from the scanners, which can be detected by it, but not from the manual attacks.

In addition, the reporter addressed an issue of secure and insecure comparison of strings that helps when brute forcing passwords.

A triangle of system characteristic dependencies, which I had never met before, was presented. The bottom line is that if there is a skew in one of the corners becomes, the other two will suffer. For example, if a product contains too many features, then it will contain a lot of security holes and will be unusable.

The reporter mentioned the IDA Pro tool that can help with code testing.

Workflow for Manual Security testing:

• Conduct a research about the company, code language, frameworks
• Perform exploratory testing of a product
• Conduct the business logic research
• Research useful info (tools, scanners, etc)
• Create Model
• Combine vulnerabilities
• Create custom payloads
• Analyze encryption
• Create tickets
• Evaluate risks of found vulnerabilities
• Create a report

Apriorit #CyberSecurity #Pentest #PenetrationTesting #SecurityTesting #WebAppHacking #WebAttack #Systemhacking #ethicalhacking #webtesting #Access #AttackProtection #ThreatModelling #VulnerabilitiesDetection #vulnerabilities #ManualTesting #AutoTesting #TestingWorkflow