Abusing the Rules: Detect and Defend Against Business Logic Attacks in APIs by Nohé Hinniger-Foray

Yeah. Hello. Hi everyone. Uh welcome. Uh this is the last talk of the tech track. I hope you are not too tired. I'll try to make this as interesting as possible. Um so today we're going to talk about abusing the rules. Uh finding business logic attacks. Uh but I kind of focused on uh our latest research which is about vioded applications. Um so welcome. Oh Oh well. Why did it Okay, the clicker is not on my side. So, uh my name is Noi. I'm a research and development engineer at Escape. Um I lead the ASM project and uh basically my job is to automate discovery and pentesting. Uh I'm kind of at scale nerd. So I love to take stuff and

running at a large scale like internet scale and I do open source too. Um oh wow, the clicker is really buggy. Uh sorry for that. Okay, so what's escape? Escape is an automated uh pen testing platform and we do uh everything from discovery to security testing and we try to automate uh this process. Okay. So at escape we have a habit of uh pres uh doing research on exposed applications. We've published several reports. Today we are going to focus on the state of uh security of vcoded applications. Uh you can read the full report here. I will of course not have time to present everything in the report. So this will be like a synthetic

view of that. Uh but there it is. The clicker is really buggy. Um so first little introduction what is vip coding and how did we get to like from LLMs to vibe coding. Um so as you all know there has been like a big rise in uh adoption of LMS to generate code around 2023 uh with just like plain chatgbt or like tools in your browser where you were like outside of your ID you will just like prompt the LLM and then copy paste the code and run it wherever you want. Then we started to see some tools appearing inside of the ids. The first one being GitHub copilot and then some more advanced tools like cursor or clude

code which run directly close to your code. And this created a trend which is called like five coding which is um you just prompt the agent you never touch the code and you let the AI do everything on its own. uh and now we see a shift to full AI platforms like Lovable or B4 uh which brings it back out of the IDE and the idea is that you just have a chat interface but the platform will uh deploy the code for you. We'll deploy the front end the back end uh set up everything the infrastructure you need and basically just generate uh your application. So little question to the audience. How many of you do use LLMs or AI in your

day-to-day job? Yeah, basically almost everyone. And is it to code? Who does use it to code? Yeah, a lot of people do. Uh so you probably have the same gut feeling as I do. Uh the LMS they create weird results, bugs, hallucinations. Um and they do even when you supervise them. So probably fully AI generated code might be worse. Um also those platforms they lead to unreviewed code. It's completely obscure. You never see the code you're running and it's also created by less technical people. The the full appeal of those platforms is to bring everyone to develop code. Like probably some of you have experienced your CTO by coding something like hey I have the next billion dollar app. Let's

just ship it to prod and it's connected to your database and you're basically screwed. Um and those platforms uh what changed is that they can now generate the front end. This is kind of old but now they also generate your back end and your database. Um and this database and this infrastructure that it generates can handle sensitive data etc. So might be a problem that the AI is the only one in control. So we wondered there might be some security issues there. Uh and we wanted to test that. Oh wow. Yeah. uh on top of that uh there is a first catalyst which is there is a clear increase in API services uh count and complexity in

companies in general uh our previous re research identified that there is on average about 15,000 API endpoints per organization which is like that many uh entry points to your code and that many entry points for potential vulnerabilities also we found some extreme cases of organization having like 3,000 API services uh for a single organization multiplied by thousands of endpoints very large attack surface. Uh the second one okay uh sorry the second one is there is also an increase in attacks on those APIs. Uh this is a report by Kong and they basically forecasted that by the end of the decade there will be a thousand% increase in API attacks. So if we combine all of that, so our gut

feeling and those catalysts, we kind of get an explosive cocktail. Uh the companies they have more APIs and endpoints that they can track. Uh those APIs, they are more diverse and complex than ever and there is an increase in attacks and boom, VI coding on top of that there is no more human in the loop. Uh what could go wrong? And so that's what we wanted to test. So we started trying to pentest those vipoded applications. So first we have to discover them. How do how do we build a data sets of such applications? We needed a source. Uh our first source was lovable launched. It's like kind of um dashboard know like rankings of vipoded

applications where you can submit stuff that you made on the platform. So very easy to scrape uh good source of lots of applications. We combine that to other sources. We identified some fingerprints in the JS code that those uh frameworks like applications will inject in your JS code. So you are we are able to take that. We also enumerated the subdomains on which they deploy the applications and other techniques. And so in the end uh after filtering a bit we get 5,000 base targets to pentest. Uh we fed those 5,000 targets into the escape attack surface management um to perform even more discovery and security testing at scale. Basically uh this platform works as the following. We take assets which

can be like of very various types. U what interest us today are mostly host API services and web applications. We run that through scanners which can be of v various types too. So either ASM to do discovery or some D or business logic security testing to find vulnerabilities and those scanners will output assets so discovery and this creates a feedback loop and we can put those asect back into the scanners etc etc expanding the attack surface and it will report some vulnerabilities. Um let's take a look into one of those scanners which is the main one that we used in this research. It's our uh web application desk um because those were mostly web applications. So basically

how it works is that you get you take the application you start a browser you go to the application you crawl it uh with like some AI or different techniques to get into all the possible path and then we perform some injections and security checks uh to find issues. While we are doing that, we hook into the browser. So we are able to get all the JS sources of the the application and we also hook to every network call and from that we are able to run some passive checks uh to detect eventual secrets of personal information and uh we also are able to extract the APIs that those front ends use and uh to

reconstruct the schemas from the runtime uh requests and we also associate that to the authentication like we can extract the cookies or the the JWT session or whatever. So, uh after running that, oh yeah, we quickly discovered that um Lovable uses Superbase as default to generate their backends. Um for those who are not aware, Superbase is basically just a posgress as a service. Um and what they do is basically they generate your front end and then they call um Superbase via their LLMs and agents to configure your database and your API that is uh built on top of the database and they configure everything for you like the schema u the role level security which

is what you use uh in superbase to control which tables or objects are accessible on or exposed in the rest API and um this raised some concerns to because generating uh your schema from an agent is probably a bad idea. generating the access control is probably a bad idea too. And having used superbase myself from small some small projects, uh the RLS is easy to mess uh even if you are experienced and you know what you do, it's easy to just miss something and expose a table that you don't want to expose. And there has been a reported CVE on that which was that lovable was basically setting up the database with like everything is

accessible first and then trying to buy to like control um blacklist some of the tables which is like not what you should do. You should do the opposite of course. Uh so we'll try to see if we can identify this CV. Did they fix it? They told that they kind of fixed it but you'll see. Um so from this discovery we started with about 5,000 targets. We discovered 15,000 assets in total and out of which we extracted about 1.5 uh web apps that we want to pentest and about 500 superbase APIs. Uh I'll just explain why we filter those and how did we do that. Um basically uh for the front end a lot of those were just like

either landing page or broken or authenticated authenticated sometimes it was even just like join a waiting list or something like very we could not register um and so a lot of broken apps too like vipoded applications were really broken just like websites you go to the website it's just like 500 or you click on a button it doesn't work it just crashes the website lots of broken applications same for the the APIs. Uh we focused on the superbase APIs. So we removed the rest and we had a lot of dead APIs or broken APIs. So we focused on the green parts there. Then okay, now that we have those targets, how do we assess the business

logic security testing of those backends and those APIs? Um let me explain a bit how we do that at Escape. Um so this is the full scheme. We start with the lovable for a quick recap. We run it through the ASM scanner, the scanner that I presented and some other scanners to find some metad data stuff that could interest us. And from that we extract the superbase API and the JWT that is needed to connect to it that is usually hardcoded in the JS files and uh we construct the schema for it and then we are able to fit it in our uh security testing scanner. Um how do we do this testing? Basically our scanner it takes

uh an exposed service and a schema. Then we run our uh technology to find business logic flows and leaking data or uh secrets. Uh let me explain how this works and why it's hard to actually assess the business logic of applications. When you try to automate pentesting of APIs, you face two main problems. The the main one is that if you just randomly fuzz or you just try to brute force the API, you will not ever be able to get past the validation layer or very unlikely. You will just send requests and it will get rejected if the application is correct um because you do not know what to send to the API. Um and

that caused most of your request to be blocked and so you end up not testing the application itself or the business logic. to just test the network layer and the validation layer which is not interesting and which is where a lot of test tool fails. Um our solution for that it's a bit of a buzz word but sorry we use uh AIdriven semantic API exploration. Basically that means that we are able to quickly learn from the API and we are able to craft payload that will get through the validation layout to identify which of those payloads work and then reuse them uh to build exploits. I will come back to that later. The second problem is that even

if you are able to get past um this validation layer, it's basically impossible to explore every possible combination in the API. Like this is a classic problem uh when you try to break something. So what we do for that is we use reinforcement learning to build uh basically a tree of possible outcomes we are searching for in the API and we prune the branches that we are not interesting in. Um let's take a quick example on how we do that. It's very simplified but so you get the idea. Uh let's take a graphql mutation. I took graphql because it's just easier to represent than rest but basically it's the same. Uh we have um imagine like a hotel room booking

system. We have a mutation that is book room. You should pass it like a hotel ID which is an integer room type which is a string and a guest email which is a string too. The naive approach very naive approach would be to just generate random stuff and send it to the API. Of course, this will like never ever get to any code path if your API is not completely stupid. Um we send like one to three for the hotel ID random string random string. This only respects the schema like the primitive types but not the intended logic that you should send to the API. So what we do here is we combine what I mentioned before and we

basically use previous responses like imagine we have a query list hotels we are able to extract stuff from that from that like for instance the room type which is like an enm and we will reject it the ID2 we will list it reject it and the email which we might have created from some register root or login or whatever and then with this request we are able to actually craft a valid payload and get deep into the code path. Uh once we are able to do this, we basically just export the API, map all the possibilities, print the stuff that is not interesting and then build chain of attacks. So basically here very simple chain uh we register then we take

the email we could take the hotel ID room type from what I presented before inject the guest email and then boom we modify the request that was uh legitimate and successful and just try to inject stuff in this legitimate request which is much more likely to get uh deep into the API and actually find stuff. Um so the benefits of using that is that with a naive approach to dust you just basically test the network layer or the headers or whatever and you will have issues like hey some control security is missing which is not very valuable still why not but it's not what you want to test when you have pentesters. Um with this approach you are able to test very

complex business logic flows such as like tenant isolation. You create two accounts. You check okay yes I'm able to create this resource. Can I access it from the account B? Uh can I modify it from the account B? If it was created from the account A etc etc. Um so if you want to learn more we have an article on that too. It's very hard to explain it all in just uh a few words but this was a very simplified version of it. of course is much more complex and you can read that if you're interested. So the interesting part what did we find? Uh enough words. Let's go to the results of the findings. Just a

little disclaimer as I mentioned uh a lot of those applications were broken or untestable. Uh yeah vipoded applications are really broken. You can trust me on that. Um a lot of those were behind authentication. We are trying to automate authentication right now. We ran it a bit but just on a tiny portion of it. It's really hard to scale. Um, and also we run all of our scanners in a surface or production mode which means we made them as harmless as possible not to break stuff on the internet for people that did not that did not ask us to. Uh, so we disabled a lot of checks like very hard injections etc. And we disabled state altering operations like

post like delete user or stuff like that. But we still found quite a lot of stuff, quite a lot of nasty stuff. Around 35,000 vulnerabilities, uh, of which we identified 100 as critical and manually reviewed the critical and high ones, 2,000 high impact ones and a lot of secret leaks and personal data leaks too. Let me go a bit more in depth. Uh for the vulnerabilities we on the high ones we had SSRF zero click account takeover uh about 250 dependencies vulnerable uh with CVE. Um we reconfirmed the CV that I mentioned earlier. So they did not fix it. Um and uh we also confirmed a lot of broken access. Uh some file closure. This was

pretty weird because some people actually they generate this was really interesting to to find some people they will generate it but not deploy it on the bubble f because it's you have to pay. So they will just we like whack the code in their like home laptop and serve it on the internet so you can access like the g repository or stuff like that just like leaking stuff on the computer and uh a lot of misconfigured uh permission or broken access control which came from the RLS that I mentioned before. So our guess was pretty good to say that this was probably very vulnerable. Uh in the secrets we identified GitHub tokens um a lot of

OpenAI API keys too because they love to build LLM wrappers but who needs a back end when you can hardcode the key in the front end. It's so much easier. Uh so yeah they just like throw the API key in the front end make calls directly to chat GPT and ta you have a wrapper. Uh we also found some admin payments API tokens that were uh actually active. One of which was a stripe token and a lot of like passwords, JWT, blah blah blah. Um for the PII, we found medical records, ibands, phone numbers, uh emails, the whole package. Um let's deep dive in a few of those vulnerabilities. Uh the first of which uh it was an application that leaked all

of the uh GitHub application tokens. So you can basically steal the GitHub apps which can be very problematic. And this is related to the CV CVE that as I was mentioning it uses the same vector. Um which is basically just you bypass the level security by just passing you a select that is select everything in the table and tada. Um this one is a very nasty one. Uh it was a medical platform like connecting doctors to patients and with a certain chain of requests you were able to leak all of the doctor's info containing uh the full name, the birth date, the phone number, the license number which is like a medical license number. Uh the bank

Ian, the email, the password which is clear of course and uh you can see that this guy is a clinic. Uh this one was really really scary. And uh last one is zero click account takeover of basically every active session on the website. Uh so you are able just to dump the all the sessions of the users and you can just take the tokens. I didn't like impersonate someone and do whatever you want including the admin accounts of course. Um yeah. So to conclude um a lot can go wrong when you v code your front end but a lot more can go wrong when you v code your back end and your database so please don't do it um some mitigation

strategies this is very enterprise focused but first uh try to have a continuous mapping of your attack surface whether it's APIs but not only like your web applications or whatever uh either do it internally that's the best way just like map everything right from your code or if you cannot do that because you are a large enterprise you have a lot of teams just use some tool escape does that but a lot of applications does that too um do some continuous pentesting on it uh manual pen testing is amazing I always say that like no tool escape or any other tool will ever replace that but it's a very nice addition to just be able to start a scan right when you

deploy your code like from your CI/CD uh and to just get all the low hanging fruits and make sure not to deploy something too vulnerable on the internet. So do that. Um third uh try to apply some security by design. Uh this is everywhere too. It's a bit of a buzz word too but the shiftcliff security to try to just communicate with the developers uh to inform them about security to think about security right into the like prototyping phase or development phases. And last um please if you do use AI to generate your code I do too. It's great. It saves a ton of time, but review the code and do not vibe code like your access control layer

or your database schema. I beg you. So, thank you. Um, I hope you like the talk. You can give feedback with this QR code and if you have any question, I'll be happy to answer. >> Thank you. Thank you so much. We only have time for one quick question.

Thanks for the session. Um, you said that you gathered some targets from the internet. I'm just wondering about the legality and have you faced any issues because you didn't like that. >> As said the previous speaker, I should have bet on this question. It's always the first question of course. Uh, so basically TLDDR yes it's legal if as long as you disclose the stuff and you are not using what you find in like magicious ways. It also depends on the country where you perform that. But yes, this was done in a legal environment. Uh and no, we did not face um any issue. Uh the platform themselves, they probably didn't notice because it's just not that

much traffic. We tried to make it like not so aggressive. As I mentioned, we try to send as few requests as possible both for not destroying stuff and being fast and scalable. Uh this is like the full thing of scaling stuff to scan. Um and we disclose vulnerabilities but most of those company they never reply because you know if you just v code your application you won't ever just have an email to some of them reply but yeah most of them do not and don't care and a lot of applications were actually already pawned or pawned after that and tokens were like revoked or yeah thank you >> thank you. All right, let's give No round of

applause then.