BSidesROC 2023 Hacking and Defending APIs - Robert Wagner

going to need to just be aware of that it's like battery any I'll I'll I'll let them know all right folks I am pleased to present Robert Wagner who's going to be talking about hacking and defending apis take it away thanks hi everybody U yeah so um I'm Robert Wagner uh or Mr minion on what's left of Twitter um and anonos exchange as well um I'm an advisory or field ciso uh which means usually help other companies with their security strategies rather than internal strategies for my organization uh been doing infosec about 20 years now first job was third shift sock analyst um where uh we were doing 12-hour shifts and I was the only person

in the sock overnight like the whole building was dark except for the one closet where they put the sock uh I I'm a co-founder of hack for kids we teach kids about Internet safety security and ethics um I'm on the board of my local Issa in Chicago uh as you can tell from my f pictures I love dogs motorcycles and scuba and in fact for 14 years I had a motorcycle riding dog he was awesome uh and I'm also an honorary wolf pup dad these are some pups down in Lafayette Indiana that I've honorar adopted which means I got to go visit them and as you can tell I came with uh bacon soap uh

that day so um but getting on to what we're talking oh yes uh so this uh presentation was actually a um a collaboration between me and Corey here so Corey wrote a book called hacking apis and it is [ __ ] awesome it's a great book um he's got tons of experience in this spased as well and we got together because we wanted to do sort of a collaboration thing he had put together a bunch of slides about how to hack the IPA apis but we wanted to make something more interesting for the presentation so we took a red versus blue approach so Cory's a um a consultant for Moss Adams he can't come out to K as much because he's got to get

his billable hours up so I asked him hey is it okay we had done a keynote on this um last year at Devcon uh but I'm like why don't I take this out to the actual hacker cons too and he's like yeah go for it so um the red part of this presentation is his work uh and then I took the approach of okay this is how Cory hacks in I'm going to try and come up with every way I can to [ __ ] with him and put that in my slide so um that's the defensive part uh we're going to be basically walking through the OAS top 10 here and um one of the amazing things I

found as I started doing the research here is that uh everything we've learned in the last 20 years about web application we apparently lost from some sort of infosec labotomy cuz everybody has forgot every principle we've learned in the absc world the the the [ __ ] API world is the wild west out there every mistake in fact if you look at the vend diagram between um the OAS API top 10 and the uh web app API top 10 there is a lot of overlap I mean it's almost a circle uh there's that much overlap between what's going wrong in the API space and what's going what has been going wrong for 20 years in the web app

space this is actually good news how many people are just starting off their infosec career or trying to get an infosec career yeah so you can be a god or goddess in this space the way and and it's so much easier I mean the ways yeah the ways you can hack in here so much incredibly easier you usually get to the data faster um anyway and the the way you hack in is so stupid easy it's just incredibly simple how Corey can leverage just the same stupid mistakes that we've been making in this space so let's talk about that space and and where we're going so the very first um uh a API uh vulnerability in the API top 10 from

oasp is uh Bola broken object level authorization and uh and this is pretty simple it's it's just allowing access uh to things that folks shouldn't have be that they shouldn't really be authorized for so um uh think of it as um you know sort of the way you approach um domain access access to objects in your domain but the end points of the API are what that question here so when Cory goes to hack stuff he'll just create you know user a and he'll walk through everything he possibly can that that user has access to so he'll he'll be using uh you know burp or some sort of um uh interception proxy and he'll just walk

through and see what are all the end points I can get to and then he'll do a couple of different things he'll he he may go in and you know when he first went in he's going with something he's getting something back like API Resource One then he just goes and SE well what happens if I change the number or what if I change the number for the user ID all he's doing is just plugging in different variables for the potential end points there the other way he might do it too is he might um create user a walk through everything you can possibly do then create user B and give user B uh user A's token or something like that

and then see if he can access resources as well so pretty simple um there's there's nothing super uh complicated about this form of a attack the defense is against it um you know again going back to a lot of the stuff we've been talking about in infosec Forever you should have a freaking access policy period now we shouldn't blame the devs for this right it's not the dev's fault um as things especially started migrating to Cloud they were tasked with getting it done get stuff developed as fast as you can and we probably just didn't know all of this stuff was going on but it should have been in sex job to just sit with them and say Hey listen

let me tell you about the way people are going to abuse your app we've seen it before uh but we haven't had that conversation so as infosec people one of our biggest tasks here is to just create a bridge between security and the developers and and tell them about all this stuff all the ways that their app can be abused but when um when you uh when you create the policy it should be uh a policy that defines access much like a domain admin has been required to make uh access policies for years now right you're going to create groups you're going to sign them permissions but you're going to apply it not at the

um uh at the access level at the authentication level but at the authorization level for every object that's going to be a big task right that's going to be a lot of policy that gets created but that's the way that you approach this and you really have to do um a a least privilege access sort of policy where you're going to deny every everything other than what's explicitly allowed uh testing isn't hard I I just showed you some tactics on how you test for that that's pretty easy for the uh for a guide for your policy and and how to do correct authorization check out the two guides I've here have here from oasp and nist they're pretty robust as

far as the amount of detail that they go into on how to set up authorization uh and the other thing a lot of folks get confused especially the folks that are not in infos is they get a little confused between authoriz ation and authentication right um authentication is going to be just things like an API Gateway or even say like uh a uh a web application firewall in front of those apis those are [ __ ] they don't do anything yes still got to have them they're but they're not going to stop these types of attacks what they're going to be is just like a firewall is now right firewalls don't protect us from much unless they're not there and

then the World falls apart right everybody can just walk into your environment so you've got to help people understand the distinction there uh and why authorization for each object is so incredibly important so broken authentication uh is the second one in the uh OAS API top 10 um this uh this is that other aspect between authorization and authentication and this is just you know stupid user tricks here right um anything from no authentication to data that should require it like personal identification account information stuff like that all the way to week uh Json web tokens there's there's actually uh one of the settings for tokens uh for the algorithm that's literally none and if it's set To None they they it's

pretty much open access exposed private Keys we all know about that um these are the kind of things that happen in the space that make it pretty easy for someone like Corey to get in um the defens is against this uh this is really about um abusing the authentication flows so keep in mind that part of your authentication flow can literally be the uh I forgot my password thing right you may have great protections on the authentication path but you may have [ __ ] around the I forgot my password thing and just allow people to abuse I forgot my password and make thousands of requests until they head on the right thing or other stupid

things like that um really MFA is a a good solution here it's a good solution for everything why we're not fully deploying MFA in all organizations I mean it's it's not as expensive as some of the other things that we use in security for layered defense and it's one of the most effective things so just get it in there um uh and and remember again ooth API Keys they're they're not going to protect against this uh so last but not least Brute Force those authentication paths try and find out um on your own and there's plenty of automated tools that can do this for you what's going to be weak or non-existent for authorization uh for authentication

in these paths uh excessive data exposure so this this is you know again I don't want to get hard on the devs because they are really tasked with a completely different objective but this is them just being not lazy but we're going to call it lazy for sake of argument right here so this is them passing all the data they possibly could to you when you make a request so you may end up making a request like we've got down here where you're just asking for the account name of of Cloud Strife and maybe it's going to pass along the parameter that this is a user but then send everything else as well you know oh hey this you know this

is an admin and they don't require uh two- Factor authentication or whatever else a whole bunch of data here that really wasn't necessary as a response to this request um I've seen other stupid things like um a uh a uh security camera system where uh if you made a request for a a camera stream it would send you all the streams and then just expect the client side to filter out to the correct one based on the request you made and and a lot of this is um is based on the stupid process of allowing the client to actually do the filtering rather than on the the the server side so that's that's going to be a lot of our defenses right

I we we know this from oos this has been going on in the web app space forever um never ever ever allow the client to enforce policy that's just we we known this how are we still making the same mistake um checking responses for stupid things like sequential IDs which are guessable U more data that than the user is authorized for and um and so on and so on and a lot of the stuff will come up in the logs and logging in the cloud space is so freaking easy these days so first off log and second of all you you can check for this kind of stuff you can just do a couple of again just using

burp or something like that um run a get request see what kind of data you get back if you've getting a [ __ ] ton of data from just a user ID request you've got a problem there uh so um lack of resource limiting right this is um this is a a vulnerability that allow things like uh denial of service and and other things like that to happen uh so uh it it's also something that uh they can come up when um when uh you're looking at things like um uh the correct rate limiting is how some uh some apps will monetize right they they uh limit how much data you can get back from it unless you're

paying for lots of fast data so uh if you can f if you're finding out ways that you can kind of work around that rate limiting you're basically getting whatever service you should be paying for for free and this can uh lower the amount of um Revenue that can be made from that app uh so in in cases like um like Cory's a here we can see that he might be trying to abuse resource limiting instead to do a password reset so in this case uh if uh if there's supposed to be some sort of rate limiting here for doing a password reset via an API and there's no rate limiting on it he can just automate this and send

thousands of requests to the endpoint until he hits on the correct number that will authorize that password reset and then try to gain access that way uh defenses against this is resource thring um your sres can be your best friend in defense of this particular um vulnerability so uh reach out to them uh even Docker has rate limiting functions so work together pair with the sres um and find the built-in ways that already exist on how to limit uh this kind of um resource abuse and again logs here are a really good way to um not only only defend against this but start looking for the abuse every logging tool out there has at least the basic function of

standard deviation from the norm and that would something like that attack that we just showed that would show up like instantaneously in standard deviation of warm if you want to get a little fancier you can also check out tools like um the scipi or our project uh where they have some uh more advanced algorithms to start looking for outliers uh of the norm um using clustering algorithms and and something that takes it a little bit further than standard deviation from the norm but standard D should make things like that uh stand out like a sore thumb so you can check your logs pretty quickly for abuse of that vulnerability uh broken level uh authorization or baffa very similar to

Bola but instead of not having the correct authorization for a resource this is not having correct authorization for a particular function so in in Corey's attack here the example is is that um you're making valid requests uh to actually either um update an account or something like that but you shouldn't be able as user a to delete user B's account so there's not uh there's incorrect authorization for this delete command that's bad enough but if you're talking about financial uh apis a flaw like this could literally allow one account to transfer someone else's balance to their own account uh and and again um it's it's easy to check for it's it's easy it's not easy to fance it

is easy to check for um but again you're going to need an access policy first of all and educate the developers on what the things you're asking for in that policy actually mean um again A lot of times this shows up because people are trying to enforce on the client side instead of the server side we all know that's bad already um this is going to potentially show up in logs uh but you can use a different function here so if um if a field you know if a particular get request or a particular endpoint shouldn't contain certain values looking for rare and almost every logging tool out there has the the the function of

looking for a rare value for a field should surface some of this but in in in any event you know we've got basically people trying to be imposters for accounts that can do a lot of of particularly bad financial damage uh so Mass assignment Mass assignment it's it's it happens a lot um devs allow basically htps to bind um to the request and let you set variables within whatever data it is that you're accessing so um it gets used a lot in like registration and the problem is is that they've allowed the uh the function to actually Define things like whether or not this is an administrator through the actual request itself and and again

it's meant to ease flow make the app easier when you're trying to set up certain accounts or something like that um but it's it's far too easy to uh to abuse so you wouldn't necessarily see all these fields when you make your initial request but what an attacker like Corey will do is he'll start guessing he'll start saying hey you know is is there a field maybe called admin is there a is or a a field for password things that should just not be allowed in something like a a registration API but the devs put it there so that they could quickly create a administrative account or something like that so um so uh defense against this uh the attacker

looking for Clues they're taking stabs in the dark um so the best events against it is disabling Mass assignment in in the first place if you're at a large organization and this already already exists throughout a lot of your apps that's going to be a nightmare to fix you're going you got to do it you're going to have to put a process in place but until then um you can start doing things like restricting access creating um allow lists and block lists based on the parameter itself and that will help mitigate a lot of that mass assignment until you can get it out of the code uh but but if the devs have put it in there

to to begin with and you have it's and if it's all over the place because devs love to copy and paste it's going to be a long process uh so security misconfiguration uh this is a catch-all from uh OAS this is uh basically all the undefined stupid human tricks that we could possibly have in our space and and I was I was dumbfounded to see that D directory traversal was still one of the major problems here right we we shouldn't be seeing this kind of uh misconfiguration anymore so this is a essentially the uh the Murphy's Law of infosec as far as apis go basically anything that could go wrong will go wrong and who here is

successfully def defended against everything that could possibly go wrong in the organiz yeah it's impossible so what are we really talking about here we're talking about building for resiliency shit's going to happen you're going to forget to patch something um and someone's going to get access that way being able to detect um and mitigate is uh is just like in regular infosec processes is going to be your best friends here uh so again there's tons of Frameworks all around this uh we just need to apply it again to the API space which we haven't been for for quite some time now uh yeah really really um yeah how how did we oh my god um we've been

dealing with injection in web apps forever we know how to fix this problem um and yet it still exists all over the place um apis are wide open to it again it's like we just had a freaking lomy when it came to development um and we forgot to tell API developers anything that was learned from the whole web app space uh so um yeah bane of our existence absolutely you're going to have to test a lot on this but even better I mean we're at a perfect Junction what have we been saying about all the flaws that we've had in web apps for years is we need something sort of secure uh software development life

cycle right we need to bake it right in the problem with that up to date has been by the time we find SQL injection in a web app the devs are on to the next project they don't give a crap about what's going on right now they have to hit that next Target so uh and and and this shouldn't be a problem in this space though because we have the [ __ ] cicd pipeline they we can automate every function and every check for the devs at build you can check for SQL injection right at build you can build the check right into Postman and there it is you can you can check it right off the bat

even better we've been talking about creating secure code and function libraries forever now is the perfect time to do it get someone in there I mean what do devs do for like more than 70% of the job copy and paste right that that's the way you get product built fast so if you're going to copy and paste give them something secure to copy and [ __ ] paced it's it's not that difficult um so uh and then pentesters like Corey getting in there and just double-checking the work is great um so improper Asset Management uh again this uh this goes uh how many how many times do we see really great asset management in just network security yeah how many

cmdbs have you seen that are just like yeah that's spot on you're doing a good no yeah it doesn't happen so it's going to happen in the space as well building for resiliency is going to be key here um but in this space again it should be easier we have uh things being built in the cloud and ways to log every single bit of it um but what's going to happen here is um especially in the uh uh in the great egress from the corporate world during covid we have a a lot of developer sha persons that know about the fact that this API has version one 2 3 and so on uh you may be only using V3

but if you can still make calls to V1 and two and those versions had vulnerabilities in them attacker can still get through because there the the API is still going to function it's still going to do what it's supposed to do uh a lot of attackers are finding that going through GitHub where the flaw in the previous version is well documented we can't get devs to document [ __ ] but they're oh my God so so it's well documented what's wrong with version one of that API and if you go scanning through GitHub you can find and it's still available um uh in their app you can still get in using that vulnerability uh so how do we protect

against this yeah document your it's amazing how many times we've seen organizations that haven't documented the apis and there's no excuse for this there's automated tools to document the apis it can take again make it part of the build process anything that you can automate for the devs to make it easy for them to be part of the security process we've got to start moving that direction um robust Cloud uh change control and all that stuff all the things that we've learned from the past 20 or more years could be applied here and and automated if you can um finding apis that you didn't even know existed is a big problem too a lot of infosec

teams are really scared not about maybe undocumented IP apis and that you know there's not enough notes there or on what it does but literally they don't even know it exists so check out kit Runner um Katy Paxton fear uh Insider PhD has a great tutorial on how to use Kite Runner um and uh we'll talk a little bit about Kite Runner um uh in a couple slides as well um you shouldn't have to use it because it should be part of the build process to document all these apis and make sure that um the the business and security knows about it but at some point you're probably going to want to run a check anyway so um so and

API number 10 in is this surprise a surprise at this point no I mean I've been talking about logging being a level of Defense throughout this entire presentation uh and yeah we know what happens when you don't log so log your [ __ ] [ __ ] it's not that difficult um in in most Cloud Tools in most Cloud space there's plenty of facility for logs you just got to put it somewhere um and honest to God if if you're not enforcing logging of the apps let me come over to the organization and I'll I'll force whoever's giv you this problem to walk over all the Legos that I've just used in this presentation here

um it's it's it's it's a no-brainer so get it in place um so uh so a quick uh bit how much time have I got here oh yeah we're still doing good okay awesome um so a couple things to point out here uh that uh catches people off guard particularly Dev groups but sometimes security teams as well um and that's the danger of false positives uh and in particular false negatives in this space so a lot of folks will say oh yeah you know um we ran our vone scanner against the API um maybe they even ran a web app V scanner or a something like nessus or qualus with the web app checks turned on and they didn't find anything

well that's exactly what happened to the US Post Office uh they were they were uh rolling out a feature that um called informed visibility it would allow you to check like what mail you have coming and stuff like that uh and the API was a key feature of this uh this particular app uh and they published you know the the findings of the vulnerability assessment you can get it through this link here um but the results were hey yeah there's nothing app totally cool no vules found uh it's rock solid Go With It about a month later it was oncbs for security as yeah being exposing what was it 60 yeah 60 million um users uh the

identities of 6 million users so and if you check that report by the way there's not a single mention of apis in the entire assessment nothing about even though that was what was driving the whole whole new app um so and this is isn't the Inspector General who did the assessment it's not their fault right it was literally them not being aware that a standard vul scanner that we've all used for years is not up to this task because it doesn't understand the problems that can go on here with uh with apis it doesn't understand um some of the things that we saw where basically you're breaking the logic of the app Itself by letting it

having it do stuff that it should do for you um in this particular case with the app um you could do things like uh log in as yourself you create an account login and then do a search for addresses and it would give you back the details of who's living at other addresses if you put in the address of an apartment building it would give you the information on every person in that apartment building and let you see what mail they have coming and all yeah all the you the have you seen those scans that you can get yeah of what mail you're going to have delivered to your house um so um this this API space does not

fit the generic uh web scanner or vul scanner space at all um they in the in the report they stated that they were using um nessus and uh HP web inspect much better things like nicto OAS zap um even burp Suite Pro so if if we actually want to take a so you can check this stuff Yourself by the way so there's a lot of intentionally vulnerable apis that are kind of like you juice shop is for web apps um or uh or web goat a couple others that are out there uh so taking a look at the um this is the results of crappy which is one of those vulnerable apis and a standard this is a

Nessa scan uh against uh against crappy and you you can see the results back here yeah it's fine totally good let's go with it uh if you take it one step further and you do it with burp Suite we've got some findings here right so potential clickjacking vulnerability here better um but it's still missing some of the stuff if you do something even more uh specifically geared towards API pen testing and vulnerability scanning like OAS zap uh some of the results down here we're we're seeing that there's some actually potentially critical uh vulnerabilities in this so using the right tool for the job is uh is the message here but a lot you you talked to a lot of infos teams and

they'll say the somewhat of the same things that the uh um that the USPS did which is oh we scanned that stuff we're we're good we we know we're good we we didn't get back any vules at all um so defenses against those kind of problems right get get some real pen testing in if you have internal resources awesome if you have to go external you have to go external but this is going to be the only way for you to know for sure cuz those automated tools can take it so far but fuzzing some of the some of the requests and posts that you make still takes some human interaction um a human can kind of get results and go oh I can

now automate that based on what I found but they're going to have to find that first and then create custom autom aut automations um bug Bounty programs are another great way here and and for those again those of you that want to like get into this space you can really make a name for yourself just getting on um some of the bug Bounty programs like hacker one and finding API vaults you'll get some money out of it too which would be really cool but you can if you get good findings and you know you can um do even a talk on it provided whatever the contract says about your findings and and how much you can reveal but this is

a great way to get into this space um and get paid while you're doing it um uh the advantages of using both um are are particularly important because this is what allows you to not only look for the vulnerabilities but actually attack the business logic of the app which is usually the most um damaging when you break business logic and you actually do things like start transferring money or I I knew one um one uh uh red team for apis that were uh attacking they had an engagement with a large financial and what they found out with that Financial was if you went to do a currency exchange through through the web app there were all sorts of checks and

balances you could only do like exchange from one currency to another um above a certain amount like had' be $1,000 or something like that um and and a couple other checks to keep people from abusing the app but what they found was if they actually tried to do the exchange through the API there was no limit first off right they could do as many as they wanted for as small of an amount as they could and what they found was if they did very small amounts of exchange the app would Round Up in the person's favor not the bank's favor so running 10 million of those transactions means they incrementally got you know one 100th of

a cent but you run enough of those yay profit so um so it's things like that that you really need like a a pentester to try and break that logic of the app um so uh to test your own um you know certain there right now there's a bunch of those vulnerable apps out crap vampy vappy pixie um take your pick I think vampy is probably the most upto-date one at this point but run your vul scanner against it just to see right I mean if that's all you have is just a regular standard vul scanner just to prove the point if you need to uh but then get something like a was zap or something

like that and start not in production please but start trying to break uh the app's actual logic and see what you can mess around with um so just a few quick testing tips right um you're going to need to use the correct tools obviously um the OAS top 10 is going to be your guide and there's tons of information including Cory's book out there to do it and then you're going to need to start putting layers in there start leveraging some of these other tactics um so that you can cover all the different ways that this app could be attacked um and get it in get it right into that cicd pipeline um so some Discovery tips I

told you a little bit about Kite Runner Kite Runner is awesome how many folks at their organization have run into problems where like they can't run a new scanner without change management process that takes like six freaking months yeah right so um so if you can't get kite runner up and running right now I devised a we devised a clever little trick here so you can do something like download the word lists that Kite Runner uses to look for API endpoints and then actually just sniff The Wire feed that um stream into something that will uh basically search based on those word lists and you can uncover quite a few end points just by using that

process um so a little bit of packet capture uh uh and then you know running it through some sort of search Tool uh GP would be fine and seeing if you can match the words in the kite files to those packet captures um uh and then uh so I'm always fond of deception tactics uh and and and things like that so I've come up with a couple of ideas on how we can use deception in this space too um so one of the ways what with deception one of the things we really want to do is waste the attackers time right we want them to go down a rabbit hole that ends up being completely unproductive so what you

could do uh a lot of apis will have uh comment or response codes um that they'll send back so one of the things we could do is create a code to replace all the four uh 401 codes fourxx 5xx with a fake 200 so attacker thinks they've succeeded in getting the next step along that path um but create and and have it point to yeah okay yeah this is good and oh by the way there's also something else further down this path and just let them chug down that path not getting anywhere and then if you put a couple of alerts on that path being accessed because it really shouldn't cuz it it's not a legit

path you can quickly get um to uh to identifying that your API might be under attack um so that's a pretty clever way oh I thought I had a second one in here um another thing you could do is also put response codes that seem to indicate oh yeah um this isn't admin but it somehow indicates that you're very close to the admin path uh and then that will give the attacker um Sort of hope that they're getting closer and closer to some sort of admin account and again all you have to do is flag on someone trying to use that uh within the organization and now you've got uh uh basically a trip wire that shows that someone is

trying to create or access accounts that don't exist but you nobody should be actually trying to do that in the first place um so here's contact information for Corey and I um I'm doing good on time here so uh we can take a couple questions did anybody find a a good tip here that they didn't know about this space yeah okay good thank God because if that was all boring um I I would have failed you all um well if if nobody has any questions uh you know I'm going to be around um welcome to answer anything offline but uh thank you very much [Applause]