Attack modeling a forgotten password system

This Attack Model maps potential attack vectors in a typical forgotten password system. The goal is to catalogue exploitable attack vectors along with the related security controls.

The output from an Attack Modeling exercise is a single table with two columns, called the Attack Register.

Attack Surface Analysis

Sequence of events

Let’s take a look at a sequence diagram for a forgotten password system. This is the kind of doc that the engineering team should have on hand 😅 . If not in official documentation, a photo of a whiteboard will often do.

We can infer from this diagram that there is a trust boundary between user, App API, IdP and Email Service. We know the assets already, because they’re stated in the diagram’s actions. We know the entry and exit points because the data flows are included, and local OS or network layer access is a given.

The Attack Library

One of the key ways in which Attack Modeling differs from Threat Modeling is that we use a library of attacks and select which ones are relevant to the component we’re analysing. The reality is that there are few novel attack vectors, and we can get 99% of the way to a secure product by ensuring that it’s protected from known attacks.

Almost all web APIs play by the same rules and have similar attack vectors. Obviously there are outliers, but for the most part they all use HTTP and JSON, they all have a client and a server, there’s authentication, there’s forms to submit. The attack vectors are very transferable between products.

That means we can use a library of attacks and apply them to the problem. For application layer attacks, an easy one that everyone can access is included in Burp Suite. But you could construct your own library from wherever you like. It could be from past pentests, MITRE ATT&CK, or your favourite LLM. If you’ve done any amount of pentesting, you probably have a memorised attack library of hundreds of attacks.

Burp Suite’s Attack Library

This is just the top few attacks in Burp; the full list is comprehensive. The Burp list is a mix of attacks, vulnerabilities and missing security features - so not all of them describe exploitable issues - you’ll need to use your judgement on what to include.

Attack selection

To understand the attack surface, we need to think about which attacks from our attack library could be viable at each actor and at each message within the sequence diagram. For example, let’s look at the API.

Users will be accessing the API via a client browser or mobile app. They’ll submit their email address, new password and token in an HTTP POST. The API interacts with the IdP to update the users password, forwarding on the authentication data. From this analysis we know we need to think about the following attack categories at the API:

• Social engineering attacks against staff
• Hardware attacks against the hosting infrastructure
• Operating system attacks
• Network layer attacks
• Application layer attacks

For brevity, I’ll consider Social engineering, Hardware, OS and Network out of scope. If I was modeling the entire application, I would include those attack libaries.

Let’s stay laser focussed on the API application layer and attacks relevant to a forgotten password mechanism. In addition to understanding the design, we also know the proposed technology stack from our discussions with the engineers (you did talk with them, right?), so can rule in/out stack-specific attack vectors.

Attack Register

Attack Modeling is all about putting our hacker’s hat on, dipping in to our libary of attacks, and contextualising those attacks for the system being analysed. Using our attack surface analysis, I’ve come up with the following list - can you spot any attacks I’ve missed? I’ve also included the relevant security control/s for each attack.

Remember, these are for the API application layer only!

Prioritisation

Instead of a Risk column, I prefer a risk threshold - where all controls down to a selected row must be deployed. Anything below the threshold is a nice-to-have. This threshold line cuts the risk, impact and likelihood clutter from the Attack Register and makes it supremely understandable to engineering teams.

“But what if the security engineer leaves the org, and we don’t know why it was above the line!” I hear you say. As mentioned previously, there are few novel attacks. Every attack in the Attack Register should be understood by any security engineer working on the Attack Model.

By using a risk threshold line instead of risk ratings, there’s no need for your engineering teams to look up your security policies and risk rating definitions. The work is already done.

Conclusion

I hope this post clarifies what Attack Modeling is, as well as demonstrates how simple and effective it can be when deployed instead of Threat Modeling.

Give it a go - your software engineers will thank you!

-Gene