APIcalypse Now: Hunting APIs to Profit

And thank you everybody. Uh so today we're going to be talking about uh APIs and how we can hunt for API vulnerabilities and obviously how you can make money in the side by hunting and reporting API. So if you've been noticed before we have integrity uh outside so they have lots of API assets and basically if you can find vulnerabilities and APIs and go into platforms you can probably make money in the site alongside your regular job. So that's that's what the uh the presentation is going to be all about. Um so I'm Nathan and uh I also go by the handle at the binary board in most places online. I am currently a student

in University of Gway. is my home ground. Um and I'm doing my masters in information systems management. I um I also worked as a solutions engineer back in India. Um we did a lot of deception tech uh security services etc. I was a security startup that I worked on. I am also a dev uh but besides dev I'm an absolute security nerd. I believe that you have to build something to break it. So that's why I do sort of like the things. Uh I hold EJPT and CRTP. EJPT is the SH penation tester. CRTP is the red team professional. They also love to create content occasionally. Uh but I'm not very consistent. Uh but but

regardless of all this, if you want to find more information about me, you can head to my portfolio. It's theite.com. Um so with that being the agenda for today's session is going to be like this. We'll be talking about APIs, what they are, uh the classification, the types and the nuances of different APIs and obviously why hack APIs at first place. What's the difference between hacking an actual web application versus hacking API endpoints. Uh I'll also be talking about different API reconnaissance techniques. Uh passive reconnaissance techniques, active reconnaissance techniques. We'll also be diving into uh authorization vulnerabilities more specifically on Bola and BFLA what they are what what are the different ways you can test for

these vulnerabilities and obviously I have certain generic tips that I would want to share with you uh these tips you know they they have helped me a lot I I used to do a lot of bounty and all of these stuff so um these are things that I have practically gained through experience and they're they're absolutely cool one of the things that I really love about APIs is how creative it is. It's not, you know, you can't probably put a certain road map of sorts and then go through a step-by-step process. It's it's not really like that. It's really creative. So, I hope you really learned something. Um that that's absolutely cool throughout this presentation. Uh so to start with what

is an API? Now I I I absolutely refrain from giving any um technical jargon. I don't want to throw anything like that. I tend to keep my presentations as simple and as analogous as possible. Uh so you can think of an API as a middleware that's connecting to different software applications. So API by itself stands for application programming interface. But if you use this analogy that's shown on screen here, you can think of the API as a waiter. For example, let's say you're going to a restaurant and then you want to order food. Uh you're not going to go directly talk to the chef and say, "Hey, I want sushi." or hey, I want a fish and

sticks or whatever it is. You're going to there's a waiter that's going to come to you. You're going to place the order to him. He's going to uh uh he's going to, you know, get the information, pass the chef, and then he's going to bring the food to your table. That's how it works. That's basically how an API also integrates to different software applications. So, uh uh let's say the customer is software application one and the chef is software application two. If there needs to be a communication, if there needs to be a communication transfer between these two applications, you have an API that's sitting in between. So basically what the API does is it uh it basically receives a

request, it collects and then it processes a response then returns with that particular uh with that particular response for the request that you have sent. So that's basically the flow of an API. um when you probably go to Google and then if you search for classifications of APIs or types of APIs, you're probably not going to get the picture on the section that you see here. Um there are different types of APIs per se. Uh these are generally called as types of APIs. You have private APIs, partner APIs and open APIs. But I like to call them as classifications because types of APIs can be very different types from I I I generally like to call

the types of APIs from an architectural pattern and not from a um you know um uh from a base uh how it's defined of a pattern. So talking about classifications of APIs we have three different classifications. One is private uh we have partner and then we have open APIs. So the things for example if you go to platforms like rapid 7 or or rapid APIs and anything that you can like I I have I built a cool application a couple of days back and then I use this API called this meowofax API basically it's it it you know the the uh endpoint basically gives you all cat codes and then you can collect them process them and then put

them in your uh application wherever you want it. All of these things are open APIs. You don't have u it's basically out in the wild for everybody to use, everybody to access, etc. But let's say you're an organization and you have lot of different partners that's working with you and then you want to only share uh certain restricted data with them. Uh that's probably not safe to share with the open world. You have these partnered APIs. For example, it can be something that's related to a uh uh something that's you know something that's got to do with the financial data of of your client that you're working on or anything that only you can share with

the partners though. So those things those endpoints fall under the partner APIs uh bracket and then we have private APIs. Now private APIs are really cool because these are uh these are intended to be used only by the devs of that particular organization. You're not going to share this out with everybody else in the wild. uh and it's it's pretty hard to get access into private APIs, but partner APIs are really cool area to target. I don't think a lot of people target on partner APIs, but it's it's an absolutely cool interesting uh venue for anybody to hack on. With that being said, there are two different types of APIs. Now, uh again, I call them as types of APIs from an

architectural pattern or architectural structure uh field of view. So we have REST APIs and then we have GraphQL APIs. Uh REST APIs I think most of you would be familiar with this. You use the regular uh HTTP methods to access data. You have get put post options etc. Uh and the kind of data that the kind of response you get from a rest API is either JSON or plain text. Uh one of the cool things with rest APIs is um you have a defined structure or a pattern through which the request is being sent and through which the response is being sent. Um I'll also talk about why that's really cool in the upcoming slides. But

GraphQL is pretty uh I would say it's really different in terms of just looking at the request. I am absolutely I I haven't hunt much on GraphQL endpoints. It's really um but it's a it's a definitely an interesting area to approach. uh one of the speakers is going to talk about GraphQL APIs soon. So I definitely urge all of you to check with that. But uh again with GraphQL API endpoints you have a single request not multiple requests which often gives you different sets of data. That's the um I mean if you look at a bigger perspective that's difference between GraphQL and REST APIs and REST APIs. You have multiple endpoints giving you multiple sources of data. But then GraphQL it's

going to be one single endpoint and then based upon the query you give it's going to give you different types of data. Uh now coming into the main picture, why hack APIs at all? Now if you've looked at the recent statistics of API calls in the last couple of uh I I would say years, you have uh about 80% of the data that's going in through the internet as API calls. Um so you can look at this issue that that was posted in 2019 which says that 83% of the web traffic is API and then we have a lot of uh cyber criminals that's also actively targeting API endpoints and uh people don't generally hack on API endpoints. I mean

people as in I'm talking about the white hat industry you know people who are hack for the good they don't really target API endpoints because uh you don't have like a guey you don't have like a web interface of sorts where you can you know probably go click buttons and then it's going to give you some data and burp which you can tamper and then it's not going to work that way it's it's it's very intuitive it's very different you're going to do a lot of recon um and you're going to do a lot of CLA activities which may not be very intuitive at first place. But if you think about it in the backside, it's

it's really cool and it's really interesting. So again, one of the reasons why I think almost everybody in this room should go and hack APIs is because uh almost a huge population of the web traffic is being controlled by APIs and if you can help secure the API endpoints, then you are eventually making the digital space safe. So u that is why I think everybody should hack APIs. Now moving into the main idea, API recon. Recon basically is finding any data um that that can help you to uh sort of get you more data from that from that uh request that you're hunting on. Now, so you you can pretty much find uh you can you can there there are like

different techniques for you to perform reconnaissance uh from a from an absolutely no standpoint. uh you can look for uh API endpoints from API documentation. You can go and look for look out for keywords like API, swagger, open API. You can type all of these um words. For example, let's say you're hunting on say integrity. You can go integrity um in title API or you can do uh integrity plus API or you there are different Google docing techniques. You can check out them. or basically if you append the words like API swag or open API in Google or any other search engine you're probably going to get lot of API endpoints which you can collect uh and

then I really like to use I like whenever I'm hunting I absolutely love to use um a a a notebook of sorts like a virtual notebook I use obsidian and then I collect all of these endpoints and then put them all separately uh what I also love to do is I love to monitor all of the URLs while browsing so for example let's say you have a web application that you're hunting on, you're obviously going to proxy this request with, let's say, Burp or you have Ko recently that's come up or you have Zap if you prefer the free version. Um, and then you're going to collect all of these requests and probably going to

save all of them in one single place. Uh, but again with APIs, you're going to have lots of interesting subdomains, lots of interesting endpoints. So, what endpoint should I obviously target first? That's a question that I that I that I've that I've uh received uh by lots in the in in the past. Um, one of the things that I really recommend people check out is uh subdomains that starting with UAT DEF test because these are areas that again uh has a plethora of information and uh they're just interesting the kind of information they they they reveal is is very interesting and if you report them you're going to eventually get a really good payout. Now um as we talked about reconnaissance

we there are in from a body perspective we have active recon and then we have passive recon. What passive recon does is it doesn't allow you to hit the target end points by themselves. You're going to find more information about the target uh by any um any information that's available out in the wild without hitting the target by itself. So you can go to Google, you can go to GitHub, you can go to Shen, you can go to Bing, you can probably find information from any search engine. Um, or you can also use tools like Fauxa, you can also use tools like web archive. Any any any engine that can give you data about a target without you practically going

and hitting the data itself uh falls under the category of passive reconnaissance. Couple of interesting things that I love to do with Google is for example let's say I have a target uh let's say I am hunting integrity for today I would go uh and then type integrity space API first and then I would go do in URL WPJSON WP2V2 user so what that do does is it finds so if you look at WordPress endpoints they have this endpoint called as WPJSON and uh that endpoint it's absolutely cool they have uh again I don't really know how to specify that with an example. I'm really sorry about that. But if you go to that particular endpoint, you're going to get

lots of interesting data. So that's an area that you definitely want to check out. Um you can also look out for specific API versions. So for example, let's say that you found uh API v1. Uh for example, let's say you you're hunting on integrity and then you find uh API docs termed as API v1 integrity. Don't just stop at API v1 integrity. Go on and throw for more API versions. probably they have v1.1, v1.0.1, v2.1. Uh, and one of the things that I really love to do is for example, let's say you found API v2.1. Uh, don't just look what's what's ahead. Uh, always look what's what's come before because those those API docs are going to have lots of

lots of endpoints that were uh probably let's say deleted because they they they they had some sort of uh sensitive data. So what I generally like to do is um go on and go go go hunt for the previous versions of API endpoints which is really interesting. You can also um dock for interesting uh endpoints from GitHub. So always look out for extensions like JSON um because they obviously have uh some sort of um um um you know API endpoints I believe and you can also look out for files like spark.json JSON a pretty cool place. Um you can also do the same kind of talking on shenan um one of the things that's really cool is you can filter with

respect to content types. So if you have content types as application/station or application/xml you're obviously going to again find a lot of interesting API endpoints. So that's with respect to passive reconnaissance. But when it comes to active reconnaissance this is where things get really interesting. Again you can use different tools like gob buster kiter. Uh one of the things that I really love to do with mass is mass is pretty slow compared to other tools but it again does a lot of checks. Uh so you can uh technically let's say you have an API word list. uh I always love to you know create an API word list whenever I'm hunting on applications and then I maintain that word list um like

like it's like one gigantic platform or repository of endpoints and I'm going to test that with almost every um every single target that I'm hunting on. I call it the API brute word list. Um and then I use that with mas for every single target that I'm hunting on using the uh query using the uh command that you can see here. If you don't want to do uh brute force, you can also use kitenus quick scan. So kitener is again I don't think a lot of people use kitener recently. It's it's a tool that's developed by asset node. It's really interesting because kitener has this unique engine which sort of uh recurrently checks us for checks for

other API endpoints. For example, let's say you have API v1 user. It doesn't stop at API v1 user. It's going to go and probe and check if API v1 admin's available uh or if API user um API v2 user is available or if API v1 user/ particular usernames available etc etc. So it does all of these repetitive checks which makes it really really interesting. Um uh and one of the things with active recon is if you see the server that's responding uniquely to request for example to certain API parts always collect those information because that's like a uh that that basically gives you that that an API endpoint exists there. Uh so make sure that one

of the things that I really like to do is always collect all of these endpoints and just keep collecting them. note-taking is absolutely um wonderful here. Moving on to vulnerabilities by themselves. Um there are two specific vulnerabilities when it comes which is really interesting when we're talking about APIs and they are uh both authorization vulnerabilities. Authorization by definitions stands for you know you you let's say you uh you hit an endpoint which you don't have access to initially but let's say you do some sort of uh tweaks or you play certain quakes to that endpoint and then you if you are able to get some data from that endpoint which you're not able to which you shouldn't be able to access

at first place then you have an authorization vulnerability. Again there are two different types of authorization vulnerabilities. We have BOLO which stands for broken object level authorization and then we have BFLA which stands for broken function level authorization. Now BA now one of the ways in BOLA works is let's say you let me directly skip to the next slide. You can find bolas in u in different endpoints. For example, let's say you have a get request as API resource one. um whenever you see ids or whenever you see um uh any entity that's referring to a group or an organization you probably might find a boladar uh so if you let's say see requests like API resource one

if you see requests like post admin password reset account 90 uh you can go and tweak these id so for example let's say your ID is um user ID 90 and you are trying to reset your password I'm talking about the last example here. Uh think of other ways. Can you probably do uh admin password reset account 91? Can you do 89? Uh can you predict the ids of other people and can you try to reset the password on their behalf? So these are again uh really creative ways you can think about. So whenever you find all of these ids, try to tamper them. Uh try to basically give any ID that shouldn't exist there and see what sort

of response you're getting back. Um, and and eventually if you hit an ID that that doesn't belong to you, you're probably going to have a bola there. Uh, the testing strategy for Bola is is pretty uh pretty naive. It's pretty straightforward. What I generally love to do is create an account. Uh, use the API and uh discover any any resource that maps to user A. Document all of the uh document all of the resources that maps. Create another account user B. Um, and then you have that user's token. You have user A's request. Copy users B's token and then place it in user A. Check if you get the data back. If you do, you

have bola. That's a very uh simple testing strategy. You can, if you're using website, there are different plugins like authorize, authorize, all of these that you can use and uh they make it really cool. It's it's really easy. Um, couple of testing mechanisms. Um whenever you have API endpoints like let's say get API v1 user 22 you can tamper that request and look for other ids you can couple of other quakes that I always love to do is let's say you pass an integer by itself try to pass the integer as an id uh for example place as uh in in a block of ids if if you have account 222 try to place account 333 within blocks try to nest it

try to include multiple objects so these are various techn techniques that you can use uh to to basically just check how the API is responding to you and based upon that you can further tweak uh your requests like that. One of the other things that I haven't mentioned here uh I found a really cool bug recently. The way I found it was I had a similar endpoint. I had API v something user and that returned a 403 to me. So I placed a wild card after that. I didn't have an ID but then I did API v1 user/star which returned data for all users and that was a massive PII. Uh that was a really cool find was a

critical and so you can it's basically as creative as you get you know you're going to find lots of interesting vulnerabilities. So that's with Bola and BFLA stands for broken function level authorization. And now the difference between bola and bfa is in bola you're only looking for um post and put data. You're not actually trying to modify data by itself. But let's say uh you have the ability to delete another person's ID or delete another basically perform any crowd based uh crowd based method on on another person then you have eventually found BFL. the testing patterns pretty much the same. Um but but for Bola you do AB testing for BFLA you do ABA testing. Basically in ABA

testing what you do is you not only go um modify the resources but you also go back with the same user account A and then you check if that data has been modified or not. So pretty much the the other things are the same uh except that you play with methods when you're doing BFLA and you play with ids when you're doing uh BA. Uh couple of other miscellaneous bugs. Uh you can also look out for injection attacks. So again think of the most absurd cases that you can find. Uh for example, if you have ids, think about what would happen if you give a zero there. What would happen if you give a negative number there? What would

happen if you don't give a number at all? uh and then try to look at the uh responses. There's definitely going to be a difference in response. Always do a diff between the responses and try to find out how it's processing all of these different queries. You can also do mass assignment attacks. This is again really cool. Um so uh while I was hunting at one of other plat like one one other uh programs I found this uh parameter called assist admin and uh it was uh it was not assigned to that particular request but I just tried to use it and then I set it to true and it gave me admin access. So that's again um

a really cool uh file. So you can you can do things like that. You can also use serverside parameter polution. Um again basically what this means is inject different parameters in the URL and try to uh look at how how the uh response is paying for you. Um couple of other tips before I close off. You can always do a version checks. For example, one of the things like I talked about one of the things that I really love to do is look out for specific versions. So let's say if you have API v2 register check if API v1 exists. Um a tip um again like one of the ways you can probably also find uh previous versions

is copy that request go I mean copy that URL go paste that URL in web archive or look out for the previous versions of that uh endpoint and you're probably going to find uh previous versions of of that particular API which is going to give you more details. So utilize platforms like Kofa, Web Arcave, they're all really interesting. Uh and if you let's say if you've got an SSRF, don't stop there. Always look of possibilities for you to chain the vulnerability. If you've got an SSRF, think about how you can use that particular endpoint and then uh probably leverage cloud services or any internal applications that you have. So all of these would not only

give you a a a medium vulnerability but if but if you're able to you know probe further and access any company specific data you're eventually going to find a critical uh think of different ways in which you can authenticate APIs uh if you have API v3 think whether you have API mobile you have uh uh uh u can you authenticate yourself via some sort of magic links etc. Uh so again all of these things are bound to creativity. So as creative as you can get you're going to find more end points. Um I think that's that with me. I have written a guide on API um API hacking specifically. If you want that you can

check that out here. I obviously linked the uh contents out uh out somewhere in my socials. But if you want to find me in socials these are ways in which you can connect with me. I think I'm done, but u if you have any questions at all, please feel free to shout out. I'd be happy to answer them.