Ineluctable weakness of logical vulnerabilities

So I will be presenting a talk on intellectual weaknesses of logical vulnerabilities. Although I have tried to keep it as less technical as possible but there will be a couple of findings to explain or just to relate to the findings or a particular set of vulnerabilities that I am trying to explain in this talk.

So a brief introduction about me, I work as an associate security consultant for Security Compass and my interest areas are basically web, IoT and mobile applications. And I have been doing bug bounty hunting for some time now and being featured in the following all the films which includes EFF, General Motors, HTC, Sony and some other companies. I have been an active contributor to the Wearlist and OWAF and Delhi Null chapter and regularly delivering talks there. So that's a brief introduction about me. Talking about the age data for the day or for my talk specifically, so I would try to cover why logical vulnerabilities exist even after all the hype that is bent around it. Apart from that, the importance of this research and what exactly is a business logic

flaw and then there are two cases which are like an example for the business logic flaws. One of them being time restriction bypass and another being product work quantity manipulation. So just running through it, there will be a lot of use of this word ineligible. Just to clarify, it's just to quantify the effect that a logical bug ability could have in a web or any other application. So, in-electable in terms means inescapable, something which we can't avoid. And talking about the logical bug, whenever a developer writes code, he or she is always focusing on how the stuff will... somebody can actually write a code which is not logically exploitable. Things will become more clear as we will move on with the talk. So this is just a

brief overview of what a logical bug is. And a logical bug is even more difficult to find than a generic bug if we talk about SQL injection or a cross-site scripting attack and similar attack. So these logical bugs are much more difficult to detect and even more difficult to mitigate because every application is specific and each application has a different set of logic applied to it. and thus it leads to a different set of logical vulnerability in the same. So, just to quantify the fact that they are difficult to find that they cannot be detected using any tool or a vulnerability scanner because there is no specific pattern that can be provided for tool or an AI machine even to let them understand what exactly to look for.

So, in terms of input validation attacks or in terms of CSRN or in terms of any other attack type, you can actually train or you can provide a regex pattern or something of that sort for a tool to identify a particular attack, but in terms of a logical vulnerability, that is not possible. So yeah, a logical vulnerability is a zero day by itself and it remains a zero day forever because till the time somebody goes ahead and reports it and it actually gets remediated in the whole logic of the application, it will remain a zero day. So weaknesses in human logic is inevitable. Nobody can say that I applied a logic and it's full proof. There is no way to bypass a particular restriction or

to bypass the way the application is meant to be working. So,

what exactly I am trying to highlight through this research is like, as I already covered, these are difficult to detect but at the same time they have a high potential impact on the application and the business they are being used for. And we see a lot of resources such as OWASC, WSC, testing methodology, testing guides, which are there for generic or legacy security vulnerabilities, but there aren't many for logical vulnerabilities as such. So if we stay there, there isn't enough information. We are nowhere trying to say that there is no information at all. But compared to the generic vulnerabilities, these resources are less. And also you can't say that a particular vulnerability will be found in a particular type of technology or a type of

application because it really depends on what kind of logic is being implemented in that particular functionality or application as well. So they are more complex because they are specific to each application and you can't really say there will be generate tests. These vulnerabilities will be difficult to write if we try to categorize it or if we try to write a testing methodology for the same. So for each specific test or for each specific logic there will be a specific case that has to be tested. What is the approach of this research is basically the patterns that I found during testing a lot of their applications and while exploring business logic flaws So, the emphasis was to find a

pattern to relate to and to use it in further research so that if we come across an application say which is of a particular type say a financial application we kind of know that this particular application will be interacting with some sort of tables, data and we can see it might be fetching some data from some pre-populated forms and there can be a particular logic that is in such kind of applications. And just to simplify things, the human brain is kind of wired in a way that it will always commit the same logical flaws or if I say same logic will be applied to applications whenever a same set of developer or a same set of technology is being used. So, yeah.

So intent is to highlight the fact that we need not always go and hunt for zero day vulnerabilities or look for cryptographic issues to break a particular algorithm or a mechanism. It's just another way of finding a vulnerability and if it can impact the business as much a cryptographic flaw does, it hits as much as worth it. So we can rather look forward to find same pattern of logical flaws that exist in various applications of the same type. which will eventually reduce our effort and increase the impact that the particular kind of vulnerability will have. So, just I was mentioning about a financial application, similar could be a case wherein you find a flaw which could be like a logical DOS or, yeah, it can be a logical DOS

which you found in an e-commerce application. So you can just go ahead and find similar flaw in other e-commerce applications as well because the, like,

I can quote or unquote these applications because these are not included in my presentation. So if you go ahead and see how exactly Flipkart works or how exactly Amazon works, they both work on the same funda that you go ahead and add items and the amount is calculated then you proceed to a payment gateway, right? And what if to intercept in between and find a logical flaw there. When I say a logical flaw, it could be somewhere like the application might be taking a negative value or something. The idea is to just replicate same sort of vulnerability in same set of application or same sort of application. So yeah, enough of this hypothesis and I started researching about the patterns of logical flaws and the results

that I found were amazing and I was able to report a number of vulnerabilities in publicly available applications. So we would rather move to that part just to make the talk much more interesting. So the first finding was it was found in an online footwear store wherein the store was a leading footwear manufacturer and you can go ahead and place an order to receive a product at your address. And so there is a quantity parameter at the checkout page so you can just go ahead and purchase a particular set of shoe or a slipper or something and there is a quantity parameter which says like how many value of this order you want to purchase. So it could be

like this is a screenshot just to clarify things in a better way. So there is a quantity parameter as you can see. So this item is priced at 399 INR and then you can go ahead and give a negative value to the quantity parameter. which eventually results in the order amount of minus 399. Although there will be a lot of counter argument that if you place an order and you are being charged negatively, how will that order get processed? That's where the whole beauty of this finding lies in. So you go ahead and add a product with a negative value or a negative quantity and then you go ahead and add a product with a positive value. So there is another product that has been

added with a quantitative one. So which cost like $14.99. So you should have been paying for these two products something like $18.98. And the logic would have been like $3.99 plus $1.499. And this is where the whole flow lies in. So as you can see, both the prices have been mentioned. First one is in negative, second one is in positive. And if you go ahead and try to make the payment, or checkout using these two products in your cart, the actual amount becomes Rs. 1100 which is like minus 399 plus 1499. So you are actually getting a product less than the price it was intended to be sold for. And although you won't be getting the first order, right, because it's in negative quantity. So when the order processing

will be done, anybody will be able to see like we can't deliver a minus one product, right. but you are still getting a product at a lesser value. And just to clarify this, this order was actually successfully placed and processed because generally e-commerce platform have a 30 days of audit period. So suppose I place an order today, they will be having a audit on the previous orders after 30 days by which they have already shipped the order. So there is not much that can be done. And since this all is done at the client side, There is nothing being hacked, there is nothing being compromised, so nobody can come and tell you that you have done something illegal. The application itself allowed negative values, right? I

didn't do anything. I didn't actually go ahead and steal somebody's password or something of that sort. This is just a manipulation. And just to brief on the technicalities, this was not possible through the UI. So you just have to intercept the request and change the positive parameter to a negative value and it will get processed. At the same time, this could have been detected at the payment gateway but it would not because if you try and process an order with just a negative value, like you are trying to place an order for minus 390 rupees, the payment gate will decline in because they are set with a parameter wherein only positive values are accepted. But in this case, the payment gateway will just get the quantity which is

like 1100 rupees and so on. there will be no negative attached to it. So it will go through for sure. A similar vulnerability was reported in one of the entertainment companies that have a facility wherein you can go ahead and book cruise. So you go ahead and make a reservation and you end up paying for the reservation that you have done at the end of your trip. So what eventually you can do is like this, this was a case of negative and positive manipulation. That particular application allowed just negative transactions to be possible and since this was not based in India so there were lesser number of limitations or second factor authentication in place. So you can actually stay

on a cruise for a month and at the end of the cruise trip you can eventually do like a negative value for your stay. So if you are paying 100 dollars for 30 for a day for 30 days which will be like 30 to like whatever amount, 100 into 30 that is. So you just set a negative value. So after the end of your trip, you are being charged through your credit card and your credit card will be charged in a negative amount, which eventually means some money will be deposited in your account rather than being debited. And I know there will be a counter argument that the company can come back to you and say that you are being negatively charged, please refund the

money and all that things. but at the first place they should not have been possible. There is always a past incident methodology that comes into picture. There may be a legal action and all sorts of that things, but at the first place security should be proactive measure and not a reactive one. So that's how these attacks propagate and they are successful. So what could have been the fix for this particular vulnerability that I was showing in the footwear company? is that the application should never be programmed to accept a negative or a zero value because why would somebody go ahead and order a shoe with quantity negative? That's defined logic, right? And that's why logical flaws are formed.

And there is never a logical reason for a user to enter these kind of values. So this application implemented a check on the client side but they missed out on implementing a check on the server side. So that's how this attack was successful. Talking about the impact, this is one of the global foodwear brand and they have like a 25 hundred crore revenue. Out of this 70% comes through online. These are some data just to quantify the effect or the impact that the company might have faced due to this vulnerability.

So, yeah, it could have been like a ton of users placing these orders and then getting those products completely. not making any money at the same time losing their products and losing out on the operational costs for shipping those items at no cost. So it could have been like a 45 lakh loss in a month or something and this is just an indicator figure. It could vary depending upon the size of the business that is operating or the region they target their audience in. Right. So yeah. Moving ahead, there is a similar vulnerability which was found in another e-commerce platform. I think I have just gone through the slides and I have already covered this one because the

same bypass was possible in another e-commerce platform. Just making this evident that this vulnerability does not exist out of the blue in one of the applications. possible flaw in the logic that is being implemented on the e-commerce platform. So it kind of becomes more difficult to identify and at the same time does have a much more grave impact for people to take care of. So yeah, and this was a, the earlier one was an Indian e-commerce portal. This is a global e-commerce portal and they were getting around a monthly revenue of what is and what if this attack was known to say 100 people or the current user base of this application they could have suffered a loss of

9 million dollars. These are just indicative figures and I am not trying to exaggerate the facts but if a person knows it how quickly this fact can circulate it's a very well known fact. We all know about the domino and uber promotional codes and those bypasses. things could happen in case of these e-commerce portals as well. So, yeah, this was the second one, like the product quantity manipulation. And then I have another one, which is like the time restriction bypass. So, there is a reported sports broadcasting network that allows you to go ahead and watch streams for different games, for different leagues. And you can actually go ahead and watch online live telecast. Also, this

finding is a bit older compared to the recent one that we showcased earlier. So this might not go through now, but this kind of impacted a very large business and they have to come out in public and declare that they suffered from something of this sort. So they had a feature which allowed you to go ahead and see a 15 minute review, review telecast for a sports event for free. without paying anything and if you need to watch the content or you need to continue watching that content you need to go ahead and subscribe to their subscription package that's what their business depends upon so the flaw was that the like if I open this website in my browser and I started

at say 2 pm right now so it should allow me ideally to watch the content till 2.15 pm But the flaw remains in the fact that the browser or the application was supposed to check the system time and not the server time. So you could actually go ahead and set your time after starting the stream as yesterday or like 10 days back and then go ahead and continue watching the stream. So what it will check is like today is 27th October and it will see okay I will set a deadline or a reminder for the application to terminate the telecast at 2.15 pm 27th October but your system time is like 24th October. So you will still get like 3 days of live streaming and that's like

without paying anything. So and if you just shift the date by a day you still end up watching it for more than 24 hours which should not be ideally possible and it allows like the whole purpose of this preview feature was just to entice the user to watch the content for 15 minutes and then go ahead and make the purchase. and made that business profitable but it actually ended up doing the opposite and the user was able to watch the live stream without any buffering or any of those hazards without sharing out a single penny.

So this was something out in the wild and the timer, like if we talk about the fix, what should have been in place or what should have been done in order to prevent this sort of thing from happening is that the timer should have been set according to the server time and not the client time or like the client's machine time or the user's machine time. And it should create a session like that is why I mentioned that this was a finding which was reported like more than three years back. So at that time not every application was going ahead and creating a session for every user or they were not tying the user with a session token or a session value. So in that case,

the mapping of the timeout would have been much more easy to implement and to validate as well. So, yep, talking about the impact, so this subscription package like for a particular code, for a particular link costs around 5500 and which is like 73 euro. And like by just simply using this trick, this doesn't involve any sort of technical skills. This is just a simple way a normal computer user interacts with the computer system and they can just modify their time. They don't need to do anything. They don't need to do any hack or such. And they still end up making a loss for the company in terms of revenue by say 5000 something rupees. And just imagine we are just talking about a single

user. Just imagine 100 users using the same trick to bypass the time restriction the losses could be. like the grouping figures mentioned in red on the screen. And this is again just an indication of the loss that the company could have suffered through this flop. They might have or they might not have. They might have suffered in a bigger number through this vulnerability, but yeah, this is all in white. So we can't really predict on the exact amount of loss that they suffered. Talking about another vulnerability, This is a popular mobile puzzle game. So this was at the time of reporting the most popular game on Facebook. So yeah, Facebook does have a online gaming portal that you see in your sidebar now. So

this game was based on a parameter called life. So you can go ahead and play the game, say up to five times. After this five times, there is a cool down period in which you get a life, but you have to wait for like 24 hours. So either you wait for those lights to come back after 24 hours and you can continue playing or you can just go ahead and purchase a package for like 50 or 100 INR and just continue playing. You might get another life to continue with the game. But the whole concept of this game was to make the user or the person playing the game a bit more frustrated because when you have cleared 5 levels you always have the

tendency to go on to the 6th level. You just want to continue with the game at the right moment itself. You don't want to wait for another 24 hours. And this enticing frustration that develops in a user forces that particular user to go ahead and purchase which kind of create the whole business for such companies, for such gaming companies. But there was a bypass possible in this time-diction. restriction and they support some loss. We would look at the like what exactly the flaw was if we are talking in terms of the technicalities. So the device was checking the time and date set in the device and not through a server or the server time again similar to the previous company's implementation

So, this was possible only on a mobile device and not on a web application, that's why it specifically mentioned that an Android device or an iPhone. So if you start a game today and the application will keep checking your system time to see if your life should expire and should you be getting a new life in the game. So it completely relied on the device time settings or the current time.

And obviously the user can go ahead and change the time and date settings of their own device and get some more lives possible to continue playing with it. So the same trick can also bypass the 24 hours time restriction like they have. Like you can't get a live, a new live after clearing the 5 levels or after exhausting your current limit of 5 lives. So you can just go ahead and preset your time to a previous date or time and you can just go ahead and play this game. Also to mention the fact that this game also is like if you need a life there are multiple ways one of them being you can go

ahead and purchase a life another way is like sending your friends requests and this is still evident in a lot of Facebook games. So either you go ahead and purchase a life or you just go ahead and invite your friends. What happens eventually is like you send this invite to 10 of your friends There might be 8 people who might not be playing the game, there might be 2 people who are already playing the game. So this is how the business actually indirectly markets its product. So you will end up sending it to your friend and he or she will start playing that game and this is how the business grows. But in this case if somebody is able to bypass the time restriction there is no need

to trouble your friends or whoever it is on Facebook for accepting the game request. because you can actively go ahead and bypass this. So again, the fix we have seen already in couple of vulnerabilities already. So there is not much to explain there. Then there is, like, this was at that time the most addictive online game ever. And it still remains one of the most addictive game of all time in terms of number of users it had, because it had like 500 million downloads and they were making up.

So, it really depends on the fact that what if people stop buying lives, what if people stop buying their paid services inside that particular game because that's where the whole business lies in, right? And there is nothing much that the company could do until the point this is detected or this is being reported to a security business. They had approximately 63,000 daily gain installations and active users of more than 25 lakhs. So just consider even if you multiply it by 50 or 100 rupees INR, it will still be a very, very big figure for a company to lose on. And especially for a company which relies completely on such a business model, it would be a huge impact.

So we have already seen the time restriction bypass.

I will just go through these slides.

So yeah, there are these resources if you want to go ahead and read more about logical vulnerabilities or like top 10 business logic attacks. or is there a change sheet for it if you are testing an application specifically for a business logic flow or if you are doing a business logic flow assessment for a particular organization, you can go ahead and refer to these resources. And just a small disclaimer that since a few of these vulnerabilities that I demonstrated, they are still active, so I refrain from using the exact name of the internet application or the organization. So, yeah, so it's just a hint that you can still go ahead and find for these vulnerabilities. These are not 100% fast and these

are still available in the wild. It's just that a company A would have remediated it, but company B might still be having it in their application. So, yeah, talking about what all you can take home from my presentation, this is what I have tried to put up, is kind of what best effort I could put across. So all logical bugs are not safe but you still get an idea of a couple of bugs and you can actually whenever next time you will be playing a game or you will be doing an online transaction on a e-commerce portal your mind will trick you into checking this. I think so because this is a very interesting field and doesn't require much of a technical involvement but yeah you can still go

ahead and find if there is something of this sort that exists. And as I mentioned, any logical flaw is a zero day vulnerability forever and the human logic will always be like in a same approach to the human brain works and it won't change. It can just get enhanced but it can never really change because whenever you have an implementation of a e-commerce checkout portal, you will always apply mathematics on it and who knows you can still get lucky with it. So there are some more critical and relevant logical bugs that could happen in the presentation but they are still in the reporting phase and they are still not being accepted. So that's why I

have not included them but yeah you are free to go ahead and research more in detail in depth about the same thing. I think I still have some time. The hack was not possible to UI.

So, I kind of get that question but just to simplify it's not even that critical or complex to replicate. It's just that we interact with the browser, right? We open another application, we click on buttons, we enter some text and do a lot of stuff. But when we are testing an application, we just apply a proxy in between the web browser and server, which is like installing a proxy suite on your system and intersecting those requests. So every request will contain some information that goes, like parameters, like the product quantity, the product value, or the user name, or

So it doesn't require any sort of cross-site scripting attack or something of that sort to succeed. It's just a parameter that goes in the request which is like quantity equal to one. You just go ahead and replace it with minus one and just send it to the server and you get a response and the attack proceeds. So there is not much of a prerequisite that is required. It's a simple attack.