Detecting Business Logic vulnerabilities in automated App Sec with Bar Hofesh

Speaker 1: All right. So. Hi, everyone. As we all get used to the working from home situation and the whole Corona thing, a bit of I’m sorry about section. If you hear children’s play around or if you hear all kinds of noises. Sorry. Nothing I can really do about it. But I’ll try to be to talk clearly and to get my message across. And if anyone has any questions, then I’ll be happy to answer those. Know a bit about me. A father of two. I’m the CTO and co-founder of NeuraLegion. I’m a devsecops enthusiast. I love open source. By the way, about the application. Amazing. The moment I saw that it was open source, I was really proud being an Israeli and having the government create such an amazing app very soon and really pushing it to GitHub with MIT license. That was amazing. I’m a hardcore Linux user and it was Arch. I’ve been doing cybersecurity researching for something like 15 years, basically breaking stuff over IRC. I’ve been a developer for a bit more than six years, played around in it for eight years and played around with DevOps. And if you want to hear me rant about all kinds of things or just very interesting tweets, then you can follow me on Twitter at. So this talk that we’re going to have today is about business, logic, vulnerabilities, the difference between standards, vulnerabilities and of course, why and how can we automate that? So before we begin, I really want to set the terminology. Um, what is a business logic? Vulnerability. So when we speak about business logic, vulnerability, and we’re going to have a slide specifically for that, but there are a lot of different concepts, concepts and conceptions and ideas about what exactly is a business. And to be honest, that’s part of the problem in automating that. But again, we’ll get there shortly. So what is the business logic for? Let’s take one example and consider it. We’re on a website. Let’s say eBay, Amazon. We want to buy a few things and we’re adding a few items to our cart and go into the checkout. But one minute before we press the checkout, we just remember that we promised the Ori to buy him a new scarf. All right. So we want to be very good friends with Ori. So we go back to the item selection and we’re adding a new scarf. Going back to the checkout, we suddenly noticed that even though that we have this new scarf in our items, the total that we need to pay hasn’t changed. Now, Tom will say this is a bag that will say this is a vulnerability. The system will most likely say this is vulnerability. And of course, the developers will say it’s a bug. But in the end, that’s a business logic vulnerability. Why? Because no one thought about the situation where after calculating the total ones, someone will add another item either in a new tab or even just going back and forth. But that creates an interesting scenario that hasn’t been thought of and has security based security based impacts. Now, why is it harder to catch than a classic vulnerability? So let’s say we’re looking for an SQL injection. We don’t really need to work that hard, right? We just go even if we really want to go deep and have a huge coverage, we’ll just go with each and every parameter, go each value, and just try to inject our token or our payload. That’s may succeed or may not, but it’s very easy to verify. Right? We injected our payload. Do we see any kind of SQL SQL errors being reflected? Do we get some kind of sleep action going on? But in the end there is a predefined scenario. We don’t care if the parameter is the phone number, if the parameter is the user ID. We don’t care if you’re in a car or a shopping website or we don’t care. It’s one pre-defined scenario for one specific test. And this is why it’s much harder to get and find business logic vulnerabilities than standard classic vulnerabilities, because you need to take into consideration the context. Um, so let’s talk a bit about why it can’t be, why it can’t be automated. Um, so. There are different I think one of the most I think one over. Yeah, we’re good. My bad. All right. So why it can be automated so you can seen are very cute to me that from one side you input it minus one. And saying that minus one is not the business logic for ability. But on the other hand, if I right now use that minus one to extract all the bitcoins from an exchange for example then. All right. We still got your bitcoins. What’s the point here? The point here is that defining exactly what a business logic vulnerability is or what isn’t is something that is very hard to do. For example, most of you, I guess, will agree that my cart checkout scenario was a business logic vulnerability. You know, it’s a no brainer. But let’s take a look at the lower left part of the screen, the checkout call. So in the end, when I do my request, I send something like that to the server, giving it some kind of an array with the items they want to buy and the total debt that I got. Some of you would say that if I can change the total here, that means that it’s just an injection or maybe not even an injection, just some kind of client side issue because the server doesn’t store doesn’t store the information on each side. And maybe it’s not the business business logic, vulnerability, but when we look at it from afar or one step back and we actually look at the whole picture that we understood the context and that we manipulate the context to our advantage, then that’s a business logic, vulnerability. And that’s one of the problems in automating that there are many different definitions. It’s difficult to generalize, saying, All right, so or we got one example that we were happy with this shopping cart, but how do we take this logic of adding items and going to verify the total in the checkout to something like a bank or something like a health care provider? There is no there is no relevance between one case to the other. So it’s very hard to create one generalized logic to really, really reuse over and over to create automation. Now, another point is that a lot of experts in the field say that to detect business logic, you need human smarts or basically you need a human to look, understand context and then react on that context to understand how to manipulate and abuse the system. And of course, it requires requires understanding of the correct flow of the system. So if I don’t know how the system should behave, then getting into a situation where the system behaves in a non-standard way or I manage to trick the system is something that I can’t do unless I know how the system actually works. So that’s one part of automation that’s also really hard to achieve because that means that we need to have some kind of full documentation or a full knowledge of each and every application that we’re going to test. Um, and then and only then, we can actually test for what’s not standard, what behaves differently. So what are the missing pieces to achieve automation? One is, of course, flow based attacks, flow based attack surface analysis. So understanding that we’re not only talking about parameters and parameters values in like our SQL injection example, it’s not about finding all the parameters and know how to inject each and every one of those. It’s about understanding the flow being used. For example, we have a form that we need to fill. All right. It could be a contact us, it could be a register, it could be all kinds of things. But in the end, there is some kind of logic being made here. We, as a human can read something and react to it, but an automated machine can’t do that. Um, the other thing is, of course context, context driven testing methodology that really connects with the former point about what’s the right way to browse the target, or at least the right way to react to the flow. Um, do we go to this page first and then do we get to that page? Do we need to fill this form and then go and fill this other form? Do we have a multi step selection? Do we have all kind of logics that are very obvious for us humans, but are very hard to generalize in code form? Of course we need real, real time response understanding. That means not just analyzing the response statuses to analyze or reject the body, but really get an understanding about what’s the difference between this response and this response. All right. The body is different. They have different HTTP codes. But but what what is the difference? Is this one a failure? And if so, why did it fail? Is this one a success? And if so, where are we now? Where do we go to? And the last thing and that’s something that’s very relevant is you need a lot of data and really, I mean, a lot I’m trying to generalize Something like that means you need some kind of of a sample and a deep analysis sample from multiple applications. And I’m talking about tens of thousands of them for the first stage, because only then you can really start to create the similarities, filter out the similarities, and start building links between between them. So let’s see what happens when we just try to attack in the classic way. So it doesn’t really matter what our water transport logic or transport technologies. Let’s say we have an XML or a JSON and we want to inject an SQL query. We don’t care what’s there. We just want to add to that or replace that with our SQL injection. I don’t care about the value being a phone phone number. I don’t care if it’s a string or an integer. It doesn’t matter to me if the target value of that parameter is being saved unsanitized into the database of the application. That’s it. Right. And then I know what how to behave and what to expect. Now. What if we don’t want to just inject an SQL injection, let’s say, in that application, the developer did an amazing job. Every input is secured. You can’t inject anything. And not even that. The developer was very happy that he added some kind of protection there, multifactor authentication or just a more secure flow. Instead of putting a username. Right now we’re putting our sorry, instead of putting a password, we will put our username and then a phone number and then we’ll get the OTP. Sounds legit. Now the problem is that the server doesn’t save this information but gets it from the user. If we try SQL injections, if we try any of the classic attacks on that, it won’t work. But what if we take a step back, look at the situation, and use our human smarts to try and understand what’s going on? So we’re giving the server a phone number. All right. What if I can change the phone number and the username and then get back the OTP to my phone? But to whoever user I want to log in as. So just by understanding that there is a difference between different parameters and that’s taking into consideration both names and values and types, I can get much more a much broader attack surface and also be actually actually getting the possibility to analyze and do a business logic based attack. Because I can see farther, I know it’s not just this one parameter, this just this one value. It’s a whole flow. Now. All right, All right. We get that issue. We understand why automating the business logic detections and why it’s really hard to automate. But how do we automate, right? This talk is about automation of business, logic, vulnerability. So what do we do? Of course, if any of you weren’t living in a cave since 2015, then you heard about AI machine learning and all that buzz. So we created some kind of experiment using those technologies to automate business logic, vulnerability detection. Now, the reason I’m going with AI here and not machine learning and I. Is that our very esteemed chief scientist told me that NLP specifically is not under machine learning, it’s under AI. It’s a different branch. So we’re going to be right with our thermal terminology. It’s not a buzzword. We’re actually talking about AI here. So what’s different technologies did we use for those experiments? So first of all, genetic algorithms, decision trees, reinforcement learning, natural language processing and a bit more. Now there is a link here that goes into an open source project that we’ve been working on for, I think around two years, maybe a bit more that has most of our most of our understandings, ideas and innovation in an open source way that can allow each and every one of you to play around with with the algorithms, with different different data sets and try to see what can you what you can achieve. So I’m going to share that afterwards as well. But keep in mind that that you have that here. So now let’s see a bit of a demo. Sadly, this demo is a video, so I’ll try to show it via the screen share. But if anyone has an issue, just let me know. Um. I’m sorry. All right. So our target is a Bitcoin exchange, In this case, the fuzzing engine that uses the the algorithms run and try to find some kind of a vulnerability. We still don’t know which vulnerability because nothing is very defined in the sense of business logic, vulnerabilities we don’t have. Again, it’s not like a SQL injection that we can just say, All right, do I see any kind of problematic response? But it’s more about making the system do something unexpected, making it behave differently. So the father started running just generating random data. It knows that it should be an integer because of analysis and it gets to some kind of an input. Uh, trying to play around and then running an op. And specifically the response says that the amount of the amount that you’re trying to withdraw is basically more than what you have is more than you currently have. Using context analysis in this case and on the whole page, we know that we you can see on the upper right side, we have zero bitcoins available. So we know that it’s more than what we currently have and we currently have zero. So All right, let’s try and put zero. That’s also the logic of the father using that. It really reacts to what the server or the application tells it and reruns. The analysis amount must be must be greater than zero. Nope. The most basic phrases what makes what makes it obvious for us also makes it obvious for the engine must be greater then that’s math. So we know it has to be larger than the zero. But we know that that it has to be lower than one. So more than zero. Lower than one. Decimal points using a predefined range attack behavior. If it goes into the median and deep into the median, trying to produce some kind of an unexpected behavior, running deeper, deeper, generating more and more payloads, just following the same logic until it detects some kind of a different behavior, in this case, baseline deviation. So the system reacts in one way, then it reacts totally differently. And we know that we broke something or that we achieved a new and new branch, and that’s something that we can automate. The next example in this case, something a bit more interesting. I think we saw an application that generates a PDF PDF report. You give it two dates from two and then it generates this PDF with an entry for each hour of every day. The father, using again NLP, detected that first of all, using a very standard regex and structure analysis. It’s understood that there’s a data object. All right, we got a date object and running NLP. It’s understood that there is a range, so we know that there is a range. We know that the value of this range is playing between two dates and then we know how to how to classify what’s going on. The context we decided or the father automatically decided to go into its range logic attacks in this case not going for the median but going to on a range extension, in this case, extending the range and taking the date from 1000 years to the past. This obviously created the denial of service attack against the target, which tried to create a few terabytes of PDF, all with images footers. And, you know, it’s an interesting finding because if you look at it, typically it’s just a role playing with dates. But actually automating that understanding the context is what’s interesting. So what’s next or where do we want to take this experiment further? Of course we want to add more and more generic cases. The generic cases are range attacks are add more items, duplicate items, all kinds of things that we can really add that after that will be can be used generically just because it’s a very general concept. The other thing is to add more type detections. We know that we have the phone numbers, we know that we have IDs and emails and we know that we have integers. But there are more, there are more structures, there are more types, and the more we can add and analyze, the more we can actually abuse. And the third point is, of course, unleash that on the unaware population and, you know, birth Skynet. But we think jokes aside, that’s where we’re going to take that. And if anyone wants to jump on the Skynet project, they are more than happy to play around with it and share with us what they found. So thank you, everyone. You know, stay safe with all the Corona things and I hope you enjoyed my talk.