Hello and welcome to the secure coding course. My name is Sonny Wear, and this is tthe e Threat modeling section, where we specifically look at the elevation of privilege card game. Now, first of all, some information about the game itself.
It was developed by Microsoft product manager Adam Show Stack,
and he actually has a full book on threat modeling, which is a very good read
if you are interested in getting into more details about it.
And so you confined his book on Amazon
now, in order to play the game, you really need to start with some sort of data flow diagram or architecture diagram of your system,
and it needs to have enough detail there
where implementation details are shown.
And this is mainly because you're going to be looking for flaws in the design or in the programming
Thio to basically exploit when going through the car deck in order to gain points.
Now, the card game rules are pretty simple.
Each team consists of 3 to 6 players. There's a deck of 84 cards.
There are six suits. Each suit is based on one of the letters have stride, so there's you know a suit for spoofing a suit for tampering, etcetera.
The cards are, as you would expect, there's numbers two through 10. There's an ace, a king, a queen and a Jack.
Now, as you go around in one turn,
the highest card is going to take the trick. Whoever starts the suit
and that is the case, unless someone has an elevation of privilege card.
So the elevation of privilege card can trump
any suit that is started for that round
and take the trick. Obviously, you're if you have an elevation of privilege card, you're gonna have to actually play it. You're gonna have to actually
determine where there is an elevation of privilege, vulnerability or or exploitation that can be done on the game board.
Mechanics. Here, you deal the cards clockwise. You're going to read your card
and announce your threat when it's your turn.
What you should be asking yourself internally is,
you know, is this threat applicable
if the player with that card cannot link the threat to the system designed that's being used
either because it's not applicable or because there may actually be a mitigation that is identified on the diagram
to address that threat, then
they would just The play would just proceed to the next player, and no point would be awarded.
Now, though, there are points awarded. The main goal behind this is obviously to identify bugs
identify security design flaws and security holes
within the architecture. Now, before you can actually start playing the game, you need to actually take some time to go through an architecture diagram.
Now what I'm showing on the screen is something that I have put together. I made this system up. It's it's not a real system,
however, it has a lot of features that are common for Web applications and backend systems.
And so what I've done is
I actually am describing
various aspects of the application. It's multiple tears,
as well as describing how some of the application code has been written. In other words, what techniques may have been used, for example, to authenticate user etcetera
in order to help facilitate the playing of the card game,
you really need to study
the picture for for a little bit of time to get an understanding of
of what all is actually implemented for this particular system. Now
I realize that I'm creating something here, fictitious. In reality, you would do something you know based on a real system,
and either you would have programmers at the table.
Designers at the table Business analysts are a conglomerate of different viewpoints that would know the particular aspects, in particular protections that maybe in place in the particular way, that something might be coated.
So let's take, for example, this password reset flaw so
you can see appear from the authentication authorization provider
that is used in the application server. That's over on the back end
that I've put in here a note that there's a password reset flaw. In other words, there's no prompt for the old password when the user goes to reset their password.
Now what that means is that
I'm pretending to be the coder or the designer,
and I know for a fact that this system has has this flaw.
What that means is, while the game is being played, this is a potential exploitation potential area that could be exploited by an attack. If you get the spoofing card,
then you could actually use this particular weakness,
spoof it and then you get a point And then, of course, the added dimension is you would add that to your dear it bug tracker or whatever your bug tracking mechanism is
in order to follow up with with that finding to see if it does indeed need to be mitigated redesigned.
So if we start looking at the cards and reading the particular attacks,
what we're going to do is, well, read a card, and then we'll see if we can find an exposure point back on our application are fictitious Acme Application. We'll just call it act me to in order to give it to a name.
So this particular card, the seven of spoofing, says an attacker can connect to a server or peer over a link that isn't encrypted okay or isn't authenticated either. One.
So back in our picture, we actually have an FTP account that's used course FTP. It's unencrypted,
and it's being used between the Web server and the database. Let's take a look at that.
If we go back to our picture,
we take a look at our Web server. We can see that there's a connection point between the Web server and this sequel data,
it says in the notes here that FTP runs on Port 21
the account's still uses a default password.
Everything is in clear text, and we don't have any kind of integrity check
that is being done, even when after the files were transferred.
So that's definitely an exposure point. We would give ourselves one point for finding that
and then move on to the next card.
So the next card that we see here is tampering. It says an attacker can alter information in a data store because it has weak ankles or includes a group which is equivalent to everyone
now on the picture. And I'm going to go back to the picture and show you we have our Web APP server actually connecting to cloud storage, and that connection is using a shared password. So this would definitely be an example of a weak ankle.
There's no type of authorization code being done or token or anything like that. Let's take a look at it on the picture, and it is connecting external to to the actual data center where this epic case resides. It's going outside of that
out into the Internet
to connect to this third party storage, and you can see the note here, it says uses hard coded password fixed key inside of AB code to connect to the cloud storage uses a shared key,
so we would give ourselves a point for finding that vulnerability and, of course, add add it to our bug tracking system.
And so as we returned to the deck,
we would continue to look at each particular suit and the type of vulnerability
either exploited or is being mitigated against in your system. So we've got repudiation,
and, of course, the elevation of privilege.
So one last thing to bear in mind if you're not familiar with what the mitigation strategies and technologies maybe
please refer to either this slide. Or
you can go back to the theory lecture that we just went through before this video and review those mitigation techniques