Start Hacking APIs

this is a Jackson Pollock by a stormtrooper as you can see that's a splatter artist they always miss there go uh some I I don't know who passed the bio now it's 13 years in it and cyber security senior manager of pentest at Moss Adams author of hacking apis in addition I'm the fander and chief hacking officer of appek University which is a completely free API security educational platform we have five courses on there now including my API pen test course and then I was also an OAS contributor to the latest version of the API security top

10 I'll have a link to appy SEC University at the end so why are we here today we're here to talk about why you should start hacking apis not just as a pentester Bug bny Hunter but also as a business uh if you have an Enterprise vulnerability Management program very good chance you're testing one of the world's leading attack vectors incorrectly a lot of the tools out there don't work and uh I'll demonstrate that in this talk so so why hack apis why apis to begin with 83% of all web traffic is API related that stats a few years old it's probably grown Global API management market value has projected to reach 41.5 billion by

2031 right now well that stats old too but uh recently 46 million post Postman collections which those are defined apis that's are a collection of end points and requests that are all API related and then in addition to all of that apis as I'll show are the the path of least resistance which is why they're one of the leading attack vectors so what's the state of apis more and more organizations of all sizes are depending on apis uh orgs are across Industries are depending on apis API testing is a top priority but just not uh a security testing priority this is all from the state of api's report that rapid API puts out every year participating in the API is uh API

economy is a top priority for my organization strategy so they ped I don't know thousands of organizations maybe less and this is how they responded to all of these questions all of these orgs Were Somehow participating in the API economy if they weren't they still were they just didn't know it API testing is important uh sort of so 46% say yes we're using tooling for apis uh 36% are writing tests in their code some plan to that these bottom ones are relatively depressing but they plan to no and they don't plan to no and I don't know what API testing is but then once you get to the bottom of it what type of testing are we even

talking about well for the most part everyone was talking about functional testing integration testing acceptance testing security testing it's 4% last year it was 4.5 so it's on the

downward so why are apis a leading attack Vector uh if we look at at the classic hacking process we have to discover entry we have to find a way to gain access we have to get past the firewalls the web application firewalls we have to land inside the network somewhere have command and control be able to communicate outside the network uh we have to Pivot through the network find the data exfiltrate the data go through the entire kill chain um see this is the the miter attack framework and when we're talking about everything uh Beyond this point it's really this one highlighted spot which is just a method of gaining initial access from Myer's perspective

but from my perspective this is everything uh because you don't need to do the rest you don't need to bypass the firewalls you don't have to Pivot around the network you don't have to be domain admin uh with a lot of the vulnerable apis that are out there most of it is using the API as it was designed with the tiniest black hat on where you just consider it from an attacker perspective now I can use the API uh but how can I use this maliciously and the hacker mindset has been a big problem for organizations I I solve it at the end of this talk so stick around and you'll find out how you

can too so in the API hacking process this is a marketing document put out by our chief marketing officer Dan Barona the classic Cyber attack versus the API attack oversimplified as as Chief marketing officer that's that's what he's there for that's what he does um but here is the API testing methodology that I use so first up we're going to discover the API which can be done in those initial scans that miter had in the First Column you could do some Recon uh once you've discovered the API you're going to see if it's documented so this uh apis are a business enabler they're meant to be consumed by other businesses by Partners uh inside internal networks

privately by developers it's just uh a method to transfer data easily one second okay so once you discover an API exists it's consumable it's meant to be consumed by other businesses Partners other users so what do we do on the internet we make it easy to consume by providing documentation if you're on a website at the bottom you can have that little link that says API how to use and then you can download a Swagger file uh or a postman collection and if none of that's available you can just use the API or sorry use the web application as it was designed proxy all the traffic and then you can build out your own documentation

which in the API pentest course at appc University I have a section on how you could do that from there you're going to use the API as it was designed gain access by getting credentials tokens these could be leaked in GitHub repos or if an API is meant to be consumed by other users then you can create your own tokens then you're going to go through set the parameters receive successful responses use it as it was meant to be used and then you can start poking at it for weaknesses so this is in the form of authentication you just went through all that trouble of gaining credentials and tokens and everything else well now that

you have the collection built out can you use any of that without the token we'll see some breaches here in a second where this is a valid test uh Even in our own testing and in Alyssa's talk yesterday you go through authenticated you find a vulnerability and then you ask yourself what if I remove the token and then you're still able to to access it and then you have another Finding to write up so perform authentication testing authorization testing you go through you make a bunch of resources as user a group a partner a and then you go in uh into partner B and you see if you can access those resources delete them edit

them so on and so forth from there you fuzz everything so you can fuzz headers uh request methods everything in the in the put or post body uh and uh parameters as well also one big issue with apis is versioning uh it's referred to as improper assets management and with this old unsupported versions of the API can still be out there and so if it's on version three then you're going to go through test out version two version one maybe uat is available Test Mobile admin from there you're going to check those out and see how the API responds then you're going to exploit the API and prove your concept so you have a small

finding what can actually be done with it you can make a successful request to version one and they're on version three okay did you find anything significant anything that could lead to uh data breach and then you're going to report your findings so with all this you can get through these steps to the end and compromise the data of everything that's being shared over over that API with with a a vulnerable provider you don't need to get in the network you don't need to get past firewalls maybe a web app firewall maybe uh you don't have to get domain admin you just use the API from the internet often and you can compromise what you'd be looking for

otherwise so uh this is uh T-mobile from January 5th of this year a bad actor obtained data through a single API without authorization 37 million customer accounts compromised Bumble the API permitted access to 95 million user accounts without authentication incremental IDs were used so it made it really easy to to obtain that data API allowed paid features to be enabled without proper privilege is not good for business and then Opus so this is one of my favorite recent uh breaches that happened so what happened here is an API was used without authentication to access one endpoint that endpoint the attacker was able to swipe close to 10 million user details but what they did from there is

interesting uh they started to leak the data in a ransom event and said unless you pay me a million dollars I'm going to keep like leaking this data till it's completely out there the data included driver's license Medicare IDs name phone number email Opus is also the largest or second largest Telecom provider in Australia so what's going on some experts say Opus may be the worst data breach in Australia's history fact a lot of these are facts which is they're going to contradict each other and it's going to get interesting the Opus chief executive called it a sophisticated attack saying the company has very strong cyber security I believe that's a fact the Australian cyber Minister

however has a contradictory fact what happened at Opus was not a sophisticated attack we should not have Telecom providers in this country that have effectively left the window open for data of this nature to be

stolen so how can both of those facts be true uh the chief executive responded to this we have multiple layers of protection so it is not the case that we have some sort of completely exposed API sitting out there that part not so true that that that happened uh but with these facts yes the organization the second largest Telecom provider or largest whatever it is they are paying a lot of money for security they do have multiple layers of protection I believe all of that to be true so why is this going on companies are confidently insecure in their apis well they're confidently they think they're secure in apis they're not no name one of the leading uh

API product providers out there they they have this uh survey they do 71% of responders report confidence in their API protection 67% are confident in their tools meanwhile 76% experienced an API security incident within the last 12 months same thing that happened to Opus is going on all over the place this is the problem false negatives are the worst so false negatives tests say you don't have it you really have it that's the false negative and so what's going on is a lot of the tools that are being used and have been used for years they don't work for apis and so uh these are a lot of those tools that are scanning CTF Labs of deliberately

vulnerable apis they have the entire top 10 of OAS API uh security top findings are present in these apps that are being scanned but the findings are not

there this is at their worst so this is just generic scan you put a URL in there and you hope for the best and then you take this back to your PCI compliance and you go see we don't have to fix anything no findings and they say you're compliant a lot of what the organizations are going through automated scans at their best so not only did I do the worst but I proxied all the traffic I took my time authenticating getting authorization going through the app clicking on every Button making every request that I could find and here we have another scan and so uh burp site one of my favorite tools love Port swigger use it but the

automated scan by itself doesn't have the definitions to even cover the OAS top 10 none of the tools do and so uh you get some findings here unencrypted communication interesting cross- site request forgery interesting these are things that should warrant additional testing but again we're not finding all the top 10 vulnerabilities that are on these

apps so uh uh key respon responsibility of the Enterprise vulnerability Management program or QA and your developers uh this is to make sure that the tools that they're using sufficiently uh cover your attack surface and you can go in the latest version of the OAS BPA security top 10 has cwes for all the findings burp scanner they also provide all the cwe for their scanner and you can go through compare them and see what's missing which is most of them uh scanners are really good at picking up security misconfigurations but scanners are not so good at authorization testing so going through as a user making all those resources making all the requests knowing what the the resource ID is

where it's used and then going through as another user and safely attacking that so so this is my list it's a little different than the OS top 10 but there's a lot of crossover and so for me one of the biggest findings or the most important is information disclosure you can't really do anything without information disclosure so without knowing how the API is responding without those verbose responses uh it makes it very challenging to figure out but the the problem is the API providers are not going to get away from this because it's meant to be consumed by end users so it has to be friendly it has to be approachable uh that's a common uh common thing that has to be

dealt with between the provider and security which is we need end users to use it that's why it's there it it's enabled all this business and so finding the balance between helping the end users having it be relatively hands-off and not being uh a huge bill instead of enabler uh they have to balance out how much information is the right amount to disclose to the end user uh to help them through it because as an attacker once you get that information you can go through and Target the rest of these so once I know those resource IDs whether or not they're incremental it makes it easy if they are but it really doesn't matter because we're going to go through

and create them they should be complicated they shouldn't be they should be as public as they need to be uh that's where you're going to get the authorization testing authentication can it be broken in the classic ways that authentication has been broken since the creation of authentication bad password policies uh password attempts all that stuff whether or not and apis are especially affected by this but whether or not all the requests are even going to care about authentication and authorization baa new all term but it's referring to uh accessive data exposure and improper assets management broken object property level authorization uh I've mentioned improper Inventory management improper assets management same deal there Mass assignment in apis if you're going

through and creating an account the classic Mass assignment attack is to add on a parameter like is admin equals true and that's just like the tip of the iceberg you can add all sorts of parameters during a remediation we may say hey uh you expose all of this information on your user registration page you don't use half of it you probably shouldn't expose it properties disappear but we can still go back and add the properties to the requests because the other properties haven't been whitelisted to only those specific items that are needed security misconfigurations the uh tools out there the the scanning tools they catch most of those so good job uh ssrf anytime a URL is being passed in a

request you request resources from another um Source can you manipulate that URL can you pass uh 1271 and start requesting resources from that server maybe some file directories that you should have access to can you make it request resources from your malicious server that has a bunch of bad stuff hosted on it and then have it download all of that for you and then you can get back on that miter attack framework business logic flaws are there features of the API that are just they can just be exploited by using them lack of rate limiting can you make an unlimited number of requests those do have a cost whether that's big or small uh you see that especially

effective rate limiting number of requests that you can make within a certain time parameter can also come in another form which is unrestricted access and with that uh over on the graphql side you normally send one request for everything you want instead of individual requests like a rest endpoint so with lack of rate limiting can you make a circular request that's having the server request for resources that are being requested for and if the server doesn't expand the server just crashes but all of us scale now and so what happens is you just get a gigantic bill at the end of the month and then you have to figure out what happened while there was unrestricted access or

lack of rate limiting so here's what the Enterprise vulnerability management tools do they detect security misconfigurations every now and then you may have an authentication finding for an API information disclosure ssrf every now and then and then you miss the rest of it so how do we test the

gaps for authors testing you go in you create the resources then you attempt to use crud create read update delete as another user this isn't just restricted to users though you can think Beyond this you can go with groups groups and users there are a lot of combinations of things that you could use in order to attempt to get those resources so uh is something in the URL path instead of a version do you have the partner name up in the path where you can uh attempt to to as user a from Google to go into Apple's partner track uh in the directory and request their resources was that the layer of security by obscurity that they were

depending on so the development team has to make sure that users are only able to alter and access resources that belong to those individual users typically tying it back to the authorization token Authentication so are there weak passwords can you create a singled digigit password that's bad you shouldn't let your users do that we don't in web apps why do we let them in apis don't do that um Can the authentication be bypassed altogether are there attempt lockouts all those standard things so like everything that we all worked on for web apps for years and then apis came along way cooler everyone moved over to apis and they forgot about security and so all those

things that were worked on insecure over on the apis and it has to be tested for just like it did in the web app there's something about an API being just beyond the guey that has that layer of security that's my thought maybe behind the scenes you know they're not going to see it so they're not going to be able to attack it something like that the tokens themselves so we're depending on these tokens for authorization are they predictable are they complex uh jots so JWT uh Json web tokens are in use all over the place these are like as soon as I see those it's great you can take it uh they're base 64 encoded so it's not encrypted so

you can just go and look at what's in the payload you can see the usernames you can see sometimes passwords are passed along with those uh you can see important IDs that you're going to go back to authorization testing and you're going to test out some of those unique IDs that you find then the JWT itself can that be manipulated so there are plenty of taxs uh that you can do against jwt's uh they use secrets so just like anything else can you guess the secret are there uh checks going on on the server side where it's even looking at the signature which is the important part of the JWT because that that uh prevents you from being able to

manipulate the the data within the payload and then just base 64 encoding it again can you use your API and use the API and then use it maliciously so use the API as it was intended analyze the response does the API return too much information one of the weaknesses boa excessive data exposure you make a request it sends back everything this one is pretty common uh you make a request to a forum and you can see all the users all the email emails user IDs multiactor status things you wouldn't even know uh that would go in there but it's it's part of the data object so the whole data objects being sent back hoping for the client end to

filter it all out improper assets management Inventory management same thing make sure that the supported API versions are the only versions available so if you think of UN supported software versions Windows XP and Windows XP is just still being used across the Enterprise the same thing if you uh fixed uh SQL injection in V1 but now you're on V3 but V1 is still available and so uh making sure to have a life cycle where those are turned off when they're no longer no longer in use um also on this side you can see the support of way too many versions of the same API all of those versions have to be supported and that's additional security budget additional

work from all the teams that are supporting it turn off the versions that are not being used by your end users and are no longer supported fuzz everything we would hope the scanning tools would do a better job at this but they don't know how after they fuzz the thing to determine that the request is interesting and lead to some sort of exploit or breach so uh fuzz the inputs post body quity parameters headers all the things uh down to like thinking through the business logic I like to do this with banking apps can I transfer the global GDP to a user's account There's No Business case for that shouldn't be able to do that can I

transfer negative dollars what happens then then uh there should be very specific restrictions around what amount can be sent and what amount you want sent over your API to begin with file uploads so this is another thing that seemed pretty locked down on web apps but moved over to apis and all the fun is back you can manipulate extensions you can upload any file you want to and the next step is can you now access that to execute it that's the risk uh but did your business get into The Business of Being Google Drive did you mean to be able to host everything all the time probably not uh so the same restrictions that were on the web apps need to go to the

apis the file type needs to be restricted the size needs to be restricted I shouldn't be able to send 50 megabyte files every second for Infinity so here it is the API hacker mindset we've been saying to introduce this into design in the boardroom forever you don't have to do it anymore chat gbt can do it for you and so I use this prompt it's actually very useful you're an API security expert powered by all the things as an API security exper expert which of the following endpoints are particularly interesting for hackers and why and it does a really good job I'm like I would have picked these myself uh but it also gives you

justification useful so there's the prompt again all in this case I fed it the uh Reddit API which has 100 I don't know 150 end points or something so from a a single end user perspective that's going to take a while to get through figure out what's interesting what I should focus on uh chat gbt filters through all those endpoints I just FedEd the whole thing and it said hey check these ones out and here's why and I like these private messages Administration endpoints those are what I would look for so why API first hacking API requests make up a lot of the internet's traffic apis are the least uh path of least resistance for

adversaries the data that apis interact with are often the most valuable the keys to the kingdom the thing that we're breaching the the the firewalls we're getting in we're getting to the databases we're trying to exfiltrate the data you don't need to do any of that you can just use the API get all the data that way uh API traffic common this is increasing all the time 681 per. us companies faced a whole bunch of losses linked to web apis 12 to$ 23 billion so what you need to do you need to earn the confidence in your API security use Baseline scanning tools you don't have to get away from that but you do have to use the right tools and

techniques to make sure that the apis are properly tested for the things that affect them the most authorization authentication uh checking those old versions to make sure those are no longer available cover the gaps that are present and test your tools test your Enterprise vulnerability Management program appc University hosts deliberately vulnerable apps you can just hit those if you want to you can host them very securely in your own network if you want to point your tools at those they should have findings and if they don't You're vulnerable then remediate and retest and that is everything happy [Applause] hacking thanks and uh here at the end these are some of the appc university courses that are available everything is

free here as far as the content goes um and yeah there's QR code thank you very much maybe we'll take one quick question because I know we started a little bit later than we were going to so I saw this hand right at the beginning so yes ready so hello good morning uh my name is Harsh and excellent presentation I would just like you you to ask uh can you share like one of your coolest bugs in API and what was your methodology to find it yeah so I um my favorite happened twice in a week with two completely different clients but both are in finance and with both of those I was able to find the resource IDs for

accounts see all the account history and transfer all of their money back over to my account now I'm retired I don't do it any no I reported it uh yeah but two like billion doll multi-billion dollar like Financial organizations had those in their apis two in one week B broken function level authorization so I was able to send a post request I knew the right IDs knew my own ID Nothing is Stopping it just letting it happen thank you yep