 |
| Image By OWASP |
Finding a proven pattern to find defects early in your cycle saves not just money but also the time required to patch those defects. Threat modeling is a tested and proven method to meet this objective. This procedure evaluates the vulnerabilities that can potentially exist in a target under observation. The vulnerabilities may or may not exist, but assuming that they do and then proceeding with the Software development Life Cycle is a pro-active way of securing your applications.
Prioritizing the area that needs more focus in order to reduce the attack surface is the primary aim of this model. This assessment is done as an iterative process which comes in to picture when new modules are added in to the application. The end result of this assessment is the security profile of that particular application under observation.
Threat modeling categories
Threat modeling has three major categories according to how it is implemented in action: end-point- centric, design-centric, and asset-centric.
An end-point-centric threat model basically deals with the attacker perspective of looking at the application. We know that an attacker initially studies the target completely such that he would have complete available information to carry out an attack successfully. The development team then sits together and speculates the way in which an attacker might penetrate their product. Based on this assessment, they come up with defenses to those attack vectors. Design-centric threat modeling deals with the design process of the application. Vulnerabilities do not only exist in code; faulty design can also allow attackers to find loopholes in the application and use it to their advantage. The design is processed based on inputs from various members and then a final draft is made.
Asset-centric threat modeling deals with the information that is passed to and from the application. Attackers have great affinity towards finding sensitive information with which they can perform successful social engineering, thereby gaining access to the target. This phase deals with all such possibilities where the team decides the manner in which sensitive information is handled within the application.
In this article, I shall explain about a famous security engineering pattern called the STRIDE model. The acronym STRIDE stands for:
1. Spoofing
2. Tampering
3. Repudiation
4. Information Disclosure
5. Denial of Service attacks
6. Elevation of privilege
In this article, I shall show you an in-depth analysis of each item mentioned in the STRIDE model.
Spoofing:
In simplest terms, spoofing refers to an action by a person/device who claims to be the one which they are not. Various known cases of spoofing includes DNS Spoofing, IP Spoofing, MAC Address spoofing, Email spoofing, SMS Spoofing and Biometric spoofing. In all these cases, the only common thing is that there are one or several forms of impersonation.
DNS Spoofing attacks, in other words, are also called as Man-in-the-middle attacks. Every DNS transaction begins and gets incremented by 1. The spoofed packet of the attacker should reach the victim before the legitimate response reaches him, thus poisoning the DNS Cache. This kind of vulnerability is very rare to find these days and can be prioritized to be very low in your threat modeling.
IP spoofing is a classic example of masking one’s identity when performing an attack. Proxy servers and zombie systems are generally used by attackers when they carry out full-fledged attacks.
Another all-time favorite attack of most attackers is Phishing. When performing a phishing attack, Email Spoofing and SMS spoofing come into the picture. This is done in order to gain the trust of the victim to get him to click the malicious link that is craftily sent to him.
Bio Metric spoofing is only a recent threat vector. Biometric traces are left behind whenever a person speaks, walks, or touches, making it one of the most challenging areas of security. Tampering:
Information sent from a sample Machine ‘A’ traverses over an N number of machines. In this situation, there is every possibility that a message sent from ‘A’ may not reach the destination in the same form as it was at its source. A classic example is the use of the Tamper Data plugin in Firefox. The plugin has the ability to successfully tamper the checkout request coming from e-commerce sites and manipulate it according to the needs of the attacker. Another example is that of a proxy agent like burp, which can see as well as manipulate requests from the original sender before it reaches the intended destination.
Repudiation:
If an application cannot handle validations and internal transactions such that it fails to log all of the user actions, then any attacker can take advantage of this design flaw. He can cause transactions to happen and leave no trace since the application could not handle the user actions judiciously.
For example, suppose the attacker is successful in finding a window through which he can perform actions anonymously (due to the flaw in the design/implementation), then all the transactions done by the attacker is not handled by the code, which results in dirty entries in the database, and thereby making the entire database invalid (since it now contains dirty data from the attacker). In such scenarios of repudiation attacks, we can conclude that most of the entries in logs or other storage spaces are misleading and invalid and would need to be cleaned up.
Information Disclosure:
There has been a recently discovered bug in Internet Explorer – mouse tracking vulnerability. This is a classic example of information disclosure. An attacker can exploit this vulnerability by tracking mouse events and using it to their advantage to visit crafted links and scripts, thereby gaining full access to the system. A design flaw can also induce this kind of vulnerability in an application. One example I can recollect is that of a Drupal vulnerability, which as a result of design flaw revealed sensitive information to the attacker.
Denial of Service:
One of the major attributes of Information Security in the CI5A (Confidentiality, Integrity, Accountability, Availability, Authorization, Authentication and Anonymity) is Availability. Denial of Service attacks lead to the unavailability of a machine or a device. This kind of attack affects the performance of the network and might also lead to unavailability of certain services.
The most basic forms of DoS attacks are to consume the bandwidth of the target. Another is purposefully causing configuration errors such that the service is disrupted. An attacker can also place some obstacles of communication (be it physical or digital) to carry out a DoS attack.
The evolution of DoS attacks to DDoS poses a serious threat to enterprises. Distributed Denial of Service (DDoS) attacks are implemented by multiple devices/individuals attacking a single target. This reduces the time needed to perform the attack and it is very effective. In such a scenario, it’s very difficult to trace it back to the attacker when millions of devices attack a single target. For a deeper understanding of keeping your network secure, check out the CCNA training course provided by Intense School.
Escalation of Privilege:
As you are aware, the highest rights in a Windows system are given to SYSTEM and not to the Administrator. As an attacker, I would always like to have the highest access rights on the victim such that I can fulfill my tasks successfully without any issues of access control. This also comes in to picture as a result of a design flaw which allows the attacker to successfully penetrate the system.
STRIDE in Threat modeling
After a brief explanation of what STRIDE is all about, let’s see its role in Threat modeling. When you begin the process of threat modeling, the entire team should sit together and enumerate all the various kinds of attacks that can be possible on the application that you are trying to secure. Following the STRIDE model where in you start from S and end at E gives a solid sense of direction as well as a definitive pattern to form a model. Once discussion is over, the points that have been discussed are documented on the individual modules of the application. This is a defensive way of securing your program, where you know the kinds of attacks that you can expect and you program accordingly to counter each attack.
A brief scenario of threat model includes:
Let me try to enumerate a threat model for a login page with a search input in it. S: Spoofing identity through SQL injection
Spoofing cookies through Cross site scripting in the Search tab ….. And so on
T: Tampering of login credentials on the wire
Observe the GET/POST requests
R: Repudiation of data by stealing a session
I: Encrypting login credentials so that they aren’t disclosed
D: Trying to Fuzz the input and see if it leads to any crash
Trying to send numerous login requests such that bandwidth is consumed
… And so on
E: Escalation of privilege can take place if there is an SQL injection/Cookie hijacking vulnerability.
This is just an example and not the real threat model document. In corporate when you submit a threat modeling documents you need to adhere to various norms and condition specific to each organization.
This article is just a starting point to find security defects early in your software development life cycle. As you gain experience, exploratory testing can be combined with this methodology to yield maximum results in this regard.
Article By Karthik of InfoSec Institute
