 Hello everyone and welcome to our talk about securing open source through threat modeling. My name is Daniel Prismant. I'm a principal researcher at the Prisma Cloud Core Research Team at Prolator Networks. And I specialize at low-level reverse engineering, exploitation and such. And also I like driving, hiking, that's my ND Miata at the track. All right, and I'm Aviv. As you can see, I'm a proud dog owner. This is Liz, you're over there. I'm the research team lead at Prisma Cloud Wasp at Prolator Networks. So my job is basically the team job is to create some new detections and make some great accuracy results for our Wasp products. And I'm specializing in vulnerability research in the cloud ecosystem. So I'm working with Kubernetes, Docker, Ransyn, just cloud vendors and everything that is in the ecosystem. Okay, so let's go over, we'll quickly cover the agenda. We'll start about threat modeling. What is it? Why to use it? Why you should care? We'll go over to how actually to start with threat modeling. We'll go over to supply chain attacks. What is it? A few examples why it's important. Then we'll provide some possible mitigations in terms of automatic tools, pros and cons, what they are good for, what their problems are. And then we'll go over to conclusion to some this talk. And this talk might be a little bit all over the place for some people. That's because there are a lot of topics that we think are important when you once start with threat modeling, and we try to touch a little bit about everything. So we are going to take to talk a little about many different topics. We hope you will leave this talk knowing something new and you will enjoy. We'll grab this one. Okay, we got it. So let's start with what is threat modeling? And basically threat modeling is a structural approach of identifying and prioritizing potential threats to a system. So basically, if I'm a vulnerability researcher, and I'm trying to find vulnerabilities in some applications or system, most chances that I'll use threat model. If I'm a nation who tries to hack into some other nation, I use threat model. If I'm a white hat, which that's why we're here today, I will use threat modeling in order to find threats in my application. So I could fix it before a black hat will find this and exploit it. So this is threat modeling. And this method could be applied by basically anyone with a sense of coding. It could be engineers, it could be architects, of course, security experts. But basically, anyone could start to do so. And in this talk, we'll try to give you the basics for threat modeling so that you could go home later and start to do it yourself in order to secure your organization, your community, your code base, your applications, your deployments and just everything. So that's the main point for threat modeling. And the next question would be, why should we do threat modeling? Because it takes so much time and you need to gain some knowledge on the way. And we're also so busy, and this is another task that we need to do. So maybe we shouldn't do it. But as you can see, in the reason here, I just give you some examples of five vulnerabilities, remote code execution vulnerabilities. I guess some of you know all of them. And I bet most of you know, look for Cheryl. And all of those vulnerabilities just allow attackers to compromise servers, just exploit it and do whatever they want. They could manipulate your data using those vulnerabilities. They could crush your applications and just do everything they want. So I don't want to pinpoint to anyone, but if someone would have threat model, those libraries that has those vulnerabilities, then they would have found those vulnerabilities, fixed them earlier, and then they wouldn't be so much impact as those vulnerabilities had in the reason here. So that's why you were basically here. Okay, let's start with threat modeling 101. And the way I see threat modeling have some levels. And the first thing I want to touch is that the fact that security isn't obvious. Now, personally, me as someone who started in reverse engineering, I always cared a lot about security, even before I coded anything. But over the years, I realized many people even say most developers don't really care about security. They don't think about it. Their code is efficient. It looks good. It's readable. And that's enough for them. And I actually did a small survey before this talk with many of my friends, whom are developers, not in the security field. And most of them said just that, dude, my code is efficient. It works. It has almost no bugs. It's readable. I don't care about security. I don't think about it. So the way I see it, the beginner level is just knowledge and awareness. Don't actually do security. Just be aware that your code could be vulnerable. Some might try to exploit it. And not just the basic of security. The basic vulnerability is stuff like that. I will get into details in a minute. Then you have the next level intermediate, where maybe you use some external resources like pentesters or other security experts to externally check your code. And then you have the advanced, where you are either in-house or you hire externally security researchers that will manually review your code. So let's start with details about threat modeling in the beginner level. And like I said, I think the most important thing is just be aware that the code you write could be vulnerable, that it could be exploitable. And I split this point into two. The first one is be aware that the external libraries use, even if your code is perfect and it has zero vulnerabilities, if you use external libraries which most do, those can make your code vulnerable. Your code could be perfect, but if you use external code with vulnerabilities, it will make your code vulnerable as well. And then there is your own code which could maybe be vulnerable. Maybe you didn't create or ended the buffer properly and it will make your code vulnerable. So those are two things. There is the part that the code you write that you need to make sure it's vulnerabilities free and the fact you use external libraries that are up to date without known vulnerabilities, stuff like that. Then there is just knowledge about security concepts, security best use cases, stuff like that. Use after free, buffer overflow, all the basics. And after you learn it a little bit, try actually practice exploiting it. It makes a huge difference when you move from just knowing the concept to actually try to exploit the basic things, a few CTFs, a few basic challenges. It will drastically increase awareness to those security concepts. And then there is the habit of just checking for new security issues. And I'm not just talking about security issues in the code you use. If you use like OpenSSL library, don't just check OpenSSL, but read about security issues in general. You will learn about new security vulnerabilities, new attacks that happen, and it will increase your awareness significantly. All of those will just improve the idea of the code you write has consequences, maybe not now, maybe not in a year, but it could be at some point to be exploitable. Then we go to the intermediate level. And like I said, it's using external services, like pen testers, using external tools that automatically search for issues, search for misconfigurations, stuff like that, maybe have in-house red team that will constantly look for issues in your code. Then we have the advanced level, which is basically having in-house security researchers. And you can see all the big companies like Apple or Microsoft, they all have those teams with hundreds of security researchers that constantly tries to break the code of the company. The idea, the logic is, we'll find the issues in-house before they're exploitable outside by an external attacker. So you manually search for vulnerabilities in the code. You use fuzzing or other advanced tools to search for vulnerabilities. And you regularly review the use of external libraries and code. All the code, all the libraries you use, which are not developed in-house, make a habit to regularly check them for new updates, for new vulnerability issues, for new bugs. Some of the times bugs will be reported. They won't be reported as a security issue, the vulnerability, but this bug can be exploited. And attackers constantly search for those bugs. Maybe one of them will be exploitable. And I want to touch a little bit about intermediate versus advanced. The way I see it, there is a huge difference between searching for new issues, searching for new zero days, the unknown versus exploiting known vulnerabilities. One day, using automatic tools to search for all the known misconfigurations, which is, to be honest, most of the attacks, most of the attacks happens using known vulnerabilities. That's one of the issues, known vulnerabilities, that all of those cases could be avoided if, for example, the library would get updated on time. But still, there is a difference. There is a difference between using known attacks and trying to find new things. All right, so Daniel just talked about all of the levels of threat modeling. And in this session, we'd like to give you the tools to start do it by yourself. So the following slides will be about how to practically do threat modeling. It's going to be really general and abstract, but it will give you the first push in order to understand how to do so. So let's start and see how can we threat modeling. And specifically, if your developers, maintainers, architects, or anyone that is involved in some applications, I guess these slides will be perfect for you. So you can understand that. So the first step is to set clear objectives. So we need to decide what we want to identify as a security issue. So for example, if I'm a bank, then I guess my biggest concern will be sensitive data leakage. So my objective will be to find and mitigate possible sensitive data leakage vulnerabilities. If I'm a real time application, then my focus would be on a dose or outage or anything that could crush my application. So that I want, I want that my clients would be working in real time. So that's my concern. And as a general rule, we want to also mitigate possible application takeover because this is like the Holy Grail. This is like the worst case. And if someone takes over our application, and when I mean takeover, I mean remote code execution in which the attacker gets full control over the server, over the application, and then he would be able to do anything he wants. So we need to identify the security objectives. And afterwards, we need to set a timeframe for the work. Now, this one is really important because in this field, you can threat model for hours, for days, or in some cases, for years, you can go so much deep, and it really doesn't end. So you need to set a timeframe for your work and to decide how deep you want to dive on each project on each threat model. Okay, so after we decided about the objective and the timeframe, the next step would be to gain a deep understanding of how the application works. So if you want to find a vulnerability in something, you first need to understand how it works. And it includes how it interacts with the ecosystem because in many cases, you can find vulnerabilities just in the interaction. It could be with a database or with another server and just anything that it interacts with. And after you understand how everything works, the next step would be to understand use cases and use usage scenarios in your applications. So we want to understand all of the processes within the application and not just the general idea of how everything works. And this will be really important, as you will see in the next slide. And in order to ease this process, my best advice to you is just to use existing design documents. If you have them, it could be really helpful because you don't need to investigate anything. Everything is just laying over there for you to use. But that's not always the case. And if you don't have those design documents, there are other ways to make it work for you. And you know, each of us is an individual and each of us learn in a different way and understand things in a different way. So for some people reading the code of the application can work. For some creating data flows would work. For some creating data schemes or just deployment diagrams, there are so many ways. Just speak the one for you or just combine some in order to understand everything and create those use cases and usage scenarios. So after we got those usage scenarios, now is the time to ask what can go wrong in each scenario. And for me, it's like the fun part. I don't know why, but I like it. And the way to define what could be the weaknesses, usually for beginners and for new to the field would be to look at some online resources, public resources. There are so many great resources out there that could really help. And for example, we have CWE, which is a community developed list of software and hardware weaknesses. It contains over 600 weaknesses types. I want to say that it includes everything, but I'm not sure this database for sure is like the closest thing to cover just everything. And in the end, you want to make a list of all of the use cases and another list for and for each use cases, you would want to enumerate the relevant weaknesses. So you would have a big list and for each use case, you will have another list. And you don't want to go over 600 weaknesses and see if they're relevant for each use case. So I guess like the big tip in here is just to use the list of the top 25 most common dangerous weaknesses by CWE. It's a list that they publish every year that includes the top 25. So this one would include the vast majority of threats and will give you the best coverage. So for example, we have out of bounds rights, we have cross-site scripting, XSS, and SQL injection. Now, there are other lists that are relevant to other applications. So for example, if you're writing a web application, you can use the OWASP top 10. And this list includes the top 10 weaknesses for web application. It is maintained by OWASP. And as you can see, those are the 10 big ones. And if you go to their website, you can see the description for each one of them. And they have really a lot of useful information for threat-moduling web application. If you are threat-moduling OWASP API top 10, sorry, if you're threat-moduling API, you can use the OWASP API top 10. So this is for APIs, API endpoints. And it is really similar to OWASP top 10, but there are a lot of different differences between those lists. As you can see, we have a mass assignment, broken object-level authorization, and on and on and on. So the fourth option would be Stride. Now, Stride is a threat-modul for identifying security issues. But for this talk, we'll only use the weaknesses that they use. It was developed by Microsoft. And the main question in Stride is what can go wrong? So for example, if we take a scenario where a customer transfers his money to another customer, so what could go wrong? Maybe he would transfer it to a different account, maybe a phishing attack would be happening, like tempering. So this is the main point for each scenario. And for beginners, I guess it's a good place to start with, because it has only six categories, which are really fun to use. So after we have the big list of scenarios and the big list of weaknesses for each scenario, now is the time to see if there are any vulnerabilities in the code. Now, this is the truly research work, and you'll need to go for each scenario, for each weakness, and just check and do your verification. And in this point, I guess, you could use an expert to help you for this one. And the first time, Sierra will understand how to do so. And again, everyone do it in a different way. I like just to go over the code and read it. It takes a lot of time, but I guess brings the best results. And that's pretty much it, how to threat model in general. Okay, I would like to talk a little bit about supply chain attacks. As I see, this is like this is an open source summit and supply chain attacks are bound with open source projects. In my opinion, many of the supply chain attacks that happened during recent years happened on open source projects. So let's start with what is actually supply chain attack. Supply chain attack is usually related to a cyber attack that targets the less secured parts of the supply chains. So we can have outdated libraries. We can have legacy elements code that isn't getting updated anymore. And even more extreme, we can have supply chain attacks in firmware or hardware. For example, take security cameras, SOCs. Security cameras, SOCs serve hardware piece. It's a hardware piece that usually and regularly gets vulnerable. People find vulnerable piece of code on in those things all the time. But the the development process of those things is really slow. Most security cameras use SOCs from years ago with tons of known vulnerabilities, vulnerabilities that are easy to exploit. Sometimes those vulnerabilities even have like walking exploits online that one doesn't even need to know anything about coding or security. They can just download the exploit and use it. And those devices, those products are vulnerable because they are using a vulnerable part, even if they don't know that. Let's go into details about outdated libraries. Attackers constantly search for devices that use vulnerable libraries. They are easy to exploit servers, containers, IoT devices. This is this is like a big one. Most IoT devices are vulnerable in some way in one way or another. Personal computers. This usually recently gets maybe slightly less popular as computers are being pushed updates, even if the user doesn't choose to updates himself and etc. And vulnerable libraries are almost always outdated. And I will explain what I mean. When a library gets vulnerable, someone reports a vulnerability or maybe a critical vulnerability is found in the wild, usually the maintainers update the library. Obviously, there are some exceptions. A product or library can get to the point of end of life, which at this point, they are officially not being maintained anymore. And even that, even that case has exception. Take Windows XP, for example. Microsoft said Windows XP is is achieved is end of life. They won't update it anymore. They won't maintain it anymore. And then the internal blue vulnerability happened. It was discovered by the NSA. And it was leaked and used by WannaCry. And Microsoft decided to update and patch this vulnerability despite the fact Windows XP was legacy and they said they won't update anymore. So every rule is an exception. Something very important to understand is you are not the target usually of attacks of outdated libraries. Attackers, they just search for a target. If it's not a targeted attack, they just search for a target. They spray and spray. They search for vulnerable targets. They will hack it. They will attack it. And maybe they will hit the jackpot and this target would be valuable. And there are also very effective tools for this task, like Shodan, which if one knows how to use it, can search for vulnerable instances online that are open to the internet. So don't think I don't have anything valuable in my website. I'm like, maybe I'm a small, small company that designed websites. I have 10 employees. And why would anyone want to hack me? You can be not a target. You can just be a target. Let's give an example of an outdated library, OpenSSL, widely used library. It even has a standalone application that use that library. And it is used by the majority of HTTPS websites online. And I give OpenSSL as an example, because it's critical vulnerabilities are being found with OpenSSL regularly. Like every few years, the recent, the last time was a few, few months ago, they announced a new critical vulnerability is found. It's a great example because everyone uses OpenSSL. When a critical vulnerability in OpenSSL is found, it affects millions and millions of websites and the clients of those websites. So millions of people. Heartbleed, for example, is a vulnerability found in OpenSSL a few years ago. It was a high severity vulnerability caused information leak. It was found and reported by Google. And the CRA, which is the Canadian Revenue Agency, took over six hours after the vulnerability was patched, after a fix was released to patch their servers. During that time, obviously, attackers that also read the OpenSSL release statement search actively for vulnerable, for vulnerable instances that they can hack instances that are late or slow to update. And hundreds of social insurance numbers of Canadian citizens leaked because they took six hours to patch their servers. And this could easily be avoided. They knew beforehand, and I'm not like I'm not flaming Canada. This could just be avoided because OpenSSL, good guy OpenSSL, even announced the announcement. They tell you a few days before they actually release the patch that they are about to release a patch. And I ran a few searches before this talk. And to these days, there are almost a quarter million servers online that are still vulnerable to harm. Let's talk a little bit about legacy code. I couldn't find like an accepted description of what legacy code is. But I think most will consider legacy code to be code without tests, maybe. Code that one is not comfortable of changing because maybe they don't know exactly what each line of code does. Code you might struggle to understand and you just use it as black box. It just works and you don't care. And it almost always be code that isn't being maintained regularly or code that isn't supported anymore. And pieces of code like that is an absolute goldmine for attackers because it's usually an old piece of code. They can actively search it for known attacks. Maybe this piece of code using an old library, which is known to be vulnerable. And there are automatic tools that you will feed them a legacy. You will feed them a code and it will search for known vulnerabilities. So one doesn't even need to be an expert or verse engineer or something like that and just use most of the time automatic tool to find critical vulnerabilities in pieces of code like that. And I just said automatic tools and I want to touch about this subject a little bit. A possible solution, a possible mitigation to most of the scenarios I describe in this talk are automatic tools. And it is hard to maintain a vulnerability free environment at scale. Maybe if you have like 10 containers, it is easy to make sure those 10 containers are vulnerability free that you use all the latest version of all the applications you use. But it gets harder and harder if you have like hundreds or thousands of containers or instances in your environment. But it is easy to do for automatic tools because as your environment scale, you can scale accordingly your automatic tools are processing power. And most attacks will happen by leveraging known vulnerabilities. The attacks that happen with like critical new zero day that discovered by like some hacking group, those are the minority. Most attacks will happen leveraging known vulnerabilities, known issues, known misconfigurations. And all of those could easily be avoided if the misconfiguration would fix the known attacks would get updated, the application would get updated to the latest fixed version, stuff like that. And automatic tools can really help. In those, in those instances, they will tell you what to do. They will tell you what vulnerabilities are critical or less critical and such. And those things, those tools, they don't even need to be that clever. They could be just dummy automatic tools. Let's take for example, common traditional anti viruses from years ago. They just, they started by just comparing hashes or strings that will compare filenames or will, they will run some hashing function on the entire file and will compare it against a known database. But it was dummy, but it was a very effective because back then attackers didn't obfuscate their viruses. They just created the same binary which attacked again and again. And those traditional anti viruses were really good against that despite, despite being not very smart. Scanning used libraries for vulnerabilities. It is again, something that is very simple for an automatic tools to do. It will just scan all your vulnerabilities or all your libraries, sorry, in your environment and will scan online those libraries for known vulnerabilities, for known updates that contain critical, abstract critical parts. Checking dangerously misconfigured components, their best practices for components. There are benchmarks for those things. Automatic tools can scan your entire environment and search for heavily misconfigured components that could be security issues. And the last part, it's getting a bit complicated. I wouldn't call it, it's not a simple thing to do, but comparing pieces of code against known, known vulnerable pieces of code online of open sources. So something automatic tools can do is break apart your piece of code, take part of it and compare it online and maybe find that this piece of code is associated with an open source project that was found vulnerable. I also want to touch a bit about problems with security products because not, not all great with those. They are known to not prioritize that well. They will just, there are tools online. There are tools that organizations sell you that will do all the things I just said and it will, it will spam you with like thousands of layers that your entire environment is, is vulnerable to so many things and you wouldn't know how to prioritize. You can't fix thousands of, thousands of layers of critical vulnerabilities. So they're not really good at prioritizing yet. I hope it will improve in the future. They have, they have false positive. They may, maybe they will alert you about a critical vulnerability that isn't actually, that your environment isn't actually vulnerable to overwhelming amount of a layer. I already touched that. And it can be hard to configure from the moment you start using an automatic tools until the moment you're actually getting value from it. It could be a long time configuring an automatic tools like that security product like that to an environment with thousands of instances. This can, this can get pretty hard. All right. So we are gonna, we all gonna go home today. And if I can give you like three things that I want you to take from here, like takeaways, it will be those three. So the first thing is that threat modeling is not an art, but a structure structured approach that anyone could apply. If you take the time and build your knowledge base, anyone could do so. And even if you do it just for a little while, you can find and mitigate like the vast majority of issues. So that's the first point. The second thing is that automatic tools could help identify some of the issues, not only threat modeling, but some other things, like in runtime environments and in your code. But as Daniel said, there are some, some issues with those tools. So combining both approaches could really, could result with the best outcome for you. And I hope that we raise your awareness about security in this session. And if you have any questions, we'll be happy to reply. Thank you.