I remember one case where we did a threat modeling workshop for a product that consists of a rich client that allows editing of objects (e.g. contract, a file, a master data record, source code …). These objects are managed by the server and the server keeps track of all these changes and maintains the appropriate version history. To keep track of the changes each object gets a temporary unique identifier, which is assigned to the object in scope. With the identifier the server can verify and manage versioning.
From a pure functional view point any unique identifier serves the purpose. But in threat modeling we are not thinking in proper working solutions but we want to know how we can break things. Let’s switch the perspective from a developer to a hacker. Where the developer might think uniqueness is key and helps to achieve the objective of consistent versioning, the hacker in us thinks: Hey, there is an identifier, what can I do with it to do something unexpected?
It is easy to observe identifiers if you have access to the system as a normal business user. In our case we just need to touch a few objects in a row, it does not even matter if these objects hold sensitive information (let’s look at that later). It turned out that the identifiers are based on a sequence. The server just incremented the identifier by one with each request. As said, that is perfectly fine for the pure functional use case. But for the hacker in us it is an interesting hook. A sequence gives at one hand a clear view on the history of identifiers and allows on the other hand a simple prediction of upcoming identifiers.
Let’s look what happens if we change the identifier to an identifier that already has been used. How will the system behave in this case? It might be possible to overwrite an object that already was created. The same is true for an identifier yet to be used; you could change the identifier to the current value plus one to interfere with the work the next edit job is doing.
What can go wrong here? If the identifier is the sole barrier for consistency, an attacker can tamper with the records in the system. Depending on the object type this might allow anything between nuisance and criminal fraud.
On the basis of this abstract information we cannot conclude on that. In addition, we are not yet sure if the identifier in use is just an optimization, and tampering with the identifier is not working as the server does different other checks and will figure out that something is going wrong or simply will not allow any attempt to manipulate files or objects in that way.
But hey, we are in a threat modeling workshop, we do not start analyzing the server behavior ourselves, we just ask the developers in the room. And the question is as simple as that: What happens if an attacker is manipulating the identifier by incrementing it or using by using a past value?
And be sure, there will be silence for a moment, the developers will think about it. If they actually work on that for quite a while, you might get the answer fast. If the team is only responsible for the client, they might need to check with someone else or dive into that deeper later on.
But we found a potential vulnerability. Now all we need to do is to figure out how high the risk of the respective threat is and consider the need and cost of a mitigation.
Typically, I avoid discussing the mitigations in detail. But in this case there is a standard cure. Identifiers that have potential security relations (confidentiality, integrity…) should be based on cryptographically secure random numbers (be sure to use a secure random function). Having that in place, the chance of guessing or predicting and thus tampering with the identifier is basically gone.
What is my conclusion? Successful threat modeling requires a different perspective (how can I break it), curiosity (what can I do with that, even if it is not immediately an attractive hacking target), and then you just need to raise a few simple question – e.g. What happens if I increment the identifier manually on client side by one?
In my threat modeling workshop, the threat did not really materialize as the surrounding framework prohibited a feasible materialization of a successful attack. Is it worth attacking your identifiers? Let me know, happy to discuss your scenario with you.
