Testing and Hacking APIs INON SHKEDY

so hi guys today we are going to talk about API security the agenda is to understand the new battleground in API security and talk a little bit about API pentesting what is the required mindset in concepts for pen testing for api's and also about hunting for the hospital 10 for API which is a new project I'm one of the co-leaders together with everything alone from check marks and we will also see real examples for API bridges so just a few words about myself my name is Anand Shetty I'm the head of research soul security have seven years of research and fantastic experience and I've grown up with api's so what does it mean I started my career back in Israel it was a security consultant mostly for financial military and government organizations I used to be in the red team of the Israeli army yeah and as you can imagine in these types of companies I saw mostly aspx JSP and SCP with traditional concepts like multi page applications on Prem and the api's will more like a niche component in the application more like for b2b communication then I decided to leave Israel I bought a one-way ticket to the Silicon Valley in California and I started a new a new episode where I'm a security consultant for startups and t1 companies and I saw new technologies like Ruby on Rails le stelle no des with the new concepts like single page applications cloud CI CD and the most important part it's all these applications deeply rely on api's so before we even start talking about API security let's start understand let's try to understand what is the api's and how are they different than traditional applications so if you took a look at the traffic between the client and the server about five or ten years ago you could see something like that the client would request some aspx page for example default.aspx then the application server would communicate with the database you know to fetch data the server would filter out data and render a nice and visual HTML page that would be presented to the client to the user by the browser so what happens today in modern applications first of all you have more types of times you can you can find developers that use the API you can find IOT devices mobile devices together with modern web applications and on the other hand you can you can find more types of database including sequel no sequel Redis and internal micro services that are used to to fetch data so today if you take a look at a traffic between the clients and the server you can see that the clients would ask for very specific types of data or actions from the API and then application server would fetch or update data from the data sources and return to the client raw data in the form of JSON it's very different from a traffic perspective and if you think about it APR the more about the data and I would like to say that aps are kind of a proxy between the client and the databases it's a very big change so it has many implications in the security field there is good news and bad news like we like to do in Israel I would start with the good news the first point many of the traditional application vulnerabilities barely exist in api's if we talk about reflected XSS o CSRF many of them are solved that just by the use of authorization header instead of a cookie based authentication I mean in model application it's very rare to find sequel injections because the use of our realms environments and if we talk about path manipulation vulnerability like directory traversal many of them are solved just because companies decided to move to s3 and cloud-based storage the second point is traffic the traffic is very structured so it's easier to understand and to analyze the traffic let's move that the bad news so first of all there are more entry points the attack surface is much it is more exposed data and less obstruction alleles API is exposed the underlying implementation of the application also modern concepts like CA CD and the fact that you have so many types of clients it makes it really hard to keep on track with the API so all of these changes require a new mindset into if you're if you are pen gesture and you test api's it requires you to understand the new battleground and to to adapt yourself so just a few words about the Oh stop turn for api's project the API project actually follow us we are trying to differ we are trying to define the new battleground application security and we will talk we have a talk tomorrow I think it's around noon together with errors about it's a kickoff for this for this product you are more than welcome to to comment to give your feedback and the main pitfalls that we find today in API security its first of all access control problems authorization problems data filtering and rate limiting but from a tackle perspective it's it's really important to understand that exploitation today requires the better understanding of the app and vulnerabilities have become more logical so what is the new mindset first of all you have to be more curious about the API and to understand the data flow you should get to know the API better by asking questions about traffic and API calls and the second point always leave the traffic and you should do it yourself of duty stop using GUI in every task that you do in every step in the a pen test don't be afraid to generate API calls from from scratch because many times you get only the documentation of the API so how can you be API cares how can you be curious about the api's so stop being methodical stop looking for a simple injection you're in every parameter it's not a good approach for a parent testing for API and be more focused on their data flow and you can use my my methodology about the evaluation phases it includes three different phases about how to evaluate the api's high level evaluation drill down information and access control evaluation they lead you to better understanding of the app and it helps you to perform more efficient and faster a penetration test with verification so this is an API call from a some type of fair ride-sharing up and let's try to understand how can you understand the API better just from the API call so first of all you can understand its breadth base because it is is JSON you can understand that it has Kyle pooling feature it allows you to share the ride with other riders at the drill-down evaluation and first of all you can find trips and I'm sorry trips and users are represented by numbers by integers while driving impairments represented by duties which are their random strings you should ask yourself if is the more than one version of the API Oh does the in another very interesting point if you take a look at the JSON you can see that the payment options it's not just a string it's a string in southern an array so you could you can assume it has some feature that supports a payment splitting just just because it's inside an array and the next step is to find this splitting the feature you should also ask yourself if does the API support soap as well and just asking more most questions about the API what can you do it this step is to copy samples of each object so you have a better understanding of the relations between the resources in the API and also it's a good idea to just cause their elbows in the api's instead of sending a number in the trips Justin like some weird the combination of face like letters and numbers and to siege learn how the API handles ellos in the access control evaluation you can understand the two types of users in the app the first one it's drivers and the second is riders and also users access to other users which are the core idols you should ask yourself first of all if you take a look at the API response you can see that the name of the choroidal includes the first name and last name you should ask yourself if the last name of the core Idol should be exposed or is there a difference between a core Ida that we invited from your application or just a random Cal pudding core Idol or can one use it be a rider and a driver at the same time what would happen with the access control mechanism in this case or does the API support cookies authorization as well what can you do at this point is to identify the session label the session label is just a term that I made up but it's basically a generic name to describe every string that is used by the API to identify the user it might be a session ID in the cookies it might be authorization header or any type of token so after we understood it there is a new battleground and it requires a new mindset let's talk about how can you handful api's vulnerabilities the most common vulnerability today is a broken object level access control you probably know this vulnerability as either we decided to change the name because of many reasons I can elaborate it's a very simple vulnerability it allows one user to access an object that should be accessed only by other users but it should not have access to this object so for example you have an endpoint of down document and this API call to this endpoint contains a document ID parameters and if you just a legit user you would ask for your own documents for example 102 this is a document that belongs to me and if I change the document ID in the request I would be able to access documents of other users it's a very severe vulnerability they find it in every almost every API today and why is it so severe and it's so common in API is like the top one vulnerability because if you think about it it's really hard to implement a proper access control mechanism you should call like access control checks in objects almost in every function that you implement that access to that database by using input from the client it's a very spread out mechanism and some tips about how to find a idols and how to exploit them so first of all you should use the session label this like this token or this session ID that identifies the user in the app you can just log in as one user and have a short video just explain it so this is the OS juice shop it's a great app that allows you to practice API vulnerabilities and have two session labels the first one is a user one and the second one is for user two I'm logged in as user one adapt and I'm performing some some actions on the app and then I go to fiddler I found some API call I'm not sure if you can see but it contains an ID in the request a basket slash four and instead of you know trying to call the same API call from another client after like some GUI after like some GUI interaction you can just duplicate the request remove the session label and replace it with the session level of user two and then you can easily compare between the two responses and to see if it's the same if you decide the same data it makes it really easier to enter fester to define dials you should ask yourself if does the object have multiple representations like good and numbers and if you got some a full of excel-like sedation level you should try to enumerate small IDs many in many cases the access control mechanisms are implemented in some weed way and some objects available and some object or not so the second rule nobility which is kind of unique to api's it's the mass assignment a are you familiar with mass assignment who knows what it's assignment in the group audience okay so it's one of the vulnerabilities I find hard to explain but this line of code can I help you to understand basically it's when the developer decides to use a function that takes input from the client like the pound's user it came directly from the get parameter and it updates an object in the database just based on this input from the client and in many cases it allows the user to update properties inside these objects you should not have have accessed you and modern frameworks encourage developers to use these family functions it's really it's really common to find them in an API so let's assume that we have this endpoint to update a specific video file on the API and we found is vulnerable to I too must assignment it means that we can update every property of this object of this video object so it's not so easy to understand how to exploit the masked assignment because there are many properties that you can change in the object and in traditional application it was really hard to exploit math assignment because you need to some internal data about the properties and the properties names in the database but today in AP is you can just find another endpoint this exposes this data about this object in this case it's just a video file and you can see that this object this endpoint shows you that video file has a parameter of conversion powers and it looks like a part of a short command and because I found this I could exploit the math assignment feature to call to cause shell injection and as you can see I just change the conversion params it's it's some internal property that should be used only by the API only by the backend server and to update the property by using the massive sign vulnerability you should try to exploit math assignment with past oh and also with Putin patch and it's a good idea to use mass assignment to bypass other security mechanisms a a really cool example that I like to show ready to api's it's in a situation that you have to at you have one application server that runs two applications one of them is a legacy multi page application and the second one is a mobile application which is a mobile app a mobile API and the mobile API uses the authorization header while the legacy application uses cookie based authentication and the interesting part that they share the same the same authentication configuration so it means that API supports cookie based authentication and it usually leads to CSRF because if the developers choose to implement a authorization header authentication is based on the header they usually don't implement CSRF protections so ok so we have a CSRF let's exploit let's exploit it in order to change the user's email so I tried to use the endpoint of API flash v1 / update mo to update user email and then to reset his password but it requires me to enter the old password which is it's sad because I couldn't exploit it anyhow the endpoint of poot / mobile flash API slash user slash me that should be is just to to update a basic data about the user like first name and last name it's vulnerable to mass assignment so it means that I can I can update every property of the user so I actually can update the user email using the math assignment so the expectation would be to target a victim who uses the old applications it means that the cookie L stood in his browser to create a malicious HTML page and to exploit the CSRF and inside the CSRF payload I can use I can exploit the mass assignment in order to to update the users email I can send it to the victim and changing his MO and to his which is password it's a very common from the built-in api's it's a combination of CS or F and mass assignment and it's a good example how can you bypass this mechanism of enter old password in order to reset the users password another vulnerability which is very common API if it's improper data filtering the first part of this vulnerability which is very common to see the api's it's a client-side data filtering it's a very simple vulnerability basically the API exposes by design sensitive data about the users that the API should not expose so we have a mobile app it's called super safe app very promising name and it has a feature of viewing a profile of one user in this case it's Bob and you can find the public data about Bob like the fact he is a minion and his hobbies but if you take a look the traffic between the client and the API you can see something very interesting the API call to view on slash user slash profile slash seven one seven which is the idea of bob contains all the public data like user ID and the profile picture which is not very interesting but also the address is the address of bob which is PII is a very sensitive data so what happens is the developers choose to filter the data before it's showing to the club to the user itself so the mobile app would filter this data before showing it the the profile of Bob it's a very it's a very good idea to filter a sensitive data in the client side not a good approach from security perspective and it's very common api's how can you find this one ability first of all it be you should be curious about the API responses and to look for all the possible ways to access the specific resource so let's say that we have some feature that allows user to comment on articles in the website so if you take a look if you take a look here at this endpoint you can see that this endpoint exposes just basic data about the people who commented on this article like first name and the content of the comment but if you used the export feature it allows you to export an article you can see it returns more data including the email of the user so let's talk a little bit how can we expand the attack surface in a api's so many times when you test an API you got into a dead end and you don't really know how to proceed so the first thing that you can do is to find more endpoints how to communicate with the API is more entry points and I would like to see to say that the two types of endpoints the wet endpoints it means that you have an active time that can communicate with the API and you should find as much as possible you should say find as much as possible clients and different types of clients that communicate with the API in order to find more wet endpoints that you can actually see the traffic between the clients and the API you can use different clients for the API a mobile or web in the very interesting point it's many companies large companies many times have a different web application for mobile so if you access the API if you access the application from a browser on a mobile it would be a different application you can use old versions of the application if if we talk about APK if you talk about Android you can use the APK pure in order to download all the versions of the android apps or elk I've come to find all Java scripts of the application of the web application and there is the second type of endpoints I would like to call them a drying point if you can see only the documentation and you can't really see the traffic between the client you don't have an active time that communicates with these endpoints so we can assume how the input should look like you can use tools like J's can or just scan the strings inside the APK files and the IP ipi files the clients F files in order to find more dry endpoints it's not so easy to to work with dry endpoints because many times don't really know or understand which inputs should be sent to these endpoints but sometimes the server would return little arrows it allows you to to understand what should be sent also you can look forward for non documentation five like swaggy JSON API dogs so applications or to a point Waddell and another good idea something that you can do is to use website like by with total and the census just to find more hosts from the same domain and the Tron the same API what expound in many pencils that if two different hosts around the semi API many times they run with different configuration or maybe with the older version so sometimes if you use another in the Facebook for like like a few years ago some researchers found something in Facebook and it allowed him to perform brute force and username and password the fuses using the Samba API because in the better API they didn't implement the the brute force protection so many times API is I mean host like if you have some better QA or staging hast the Tron the same API sometimes they don't run the same security configuration or the same security mechanisms and it would be a good idea to always look for the most niche features so if it's the main the main page of the app many times it will not be vulnerable to two common vulnerabilities because because of bug bounties or because the developers thought about that but developers tends to to put less resources to think about let about security when it comes to some niche feature so you always try to look for these niche features and also also don't forget different different protocols it means many times it means different implementations so a model application might expose so elasticsearch graph QL and WebSockets and at the same time and you should test each one of them is a different application don't assume that they implement the same security mechanisms and also this is like a short list of interesting features it's tend to be vulnerable to do some types of attacks like export mechanism user management some users or custom views of the dashboard mm I would like to share with you a quick example so let's let's see a quick example for a real ap attack it was one of the biggest food delivery applications and the security team had done pretty good job with the API I hadn't found it something interesting for a couple of days and it was pretty sad about that I really wanted to find something interesting so the attack steps were to download an old version of the app and I found a really neat feature it was hidden deep inside the GUI it was to update the users phone number it was only available in the old version of the of the app and this process includes two steps the first one was to get confirmation code for the new number it was vulnerable to mask to a idle sorry and then using this code I could I should verify with these endpoints that the verify update number I should have sent the confirmation code I got using the SMS token in order to complete the process so it was an interesting vector but I couldn't really update and other users phone number because of the second step it wasn't vulnerable to either so after after some research I found something very interesting the confirmation code token I got in the SMS if from the SMS could be used for the login mechanism we found some endpoint that allowed me to to login with the code in with an SMS a code and I could use the code from the first feature to login with the second feature but the bad news is that the endpoint verifies the device good it was some a header that was sent together with every API call it means there is a double verification I couldn't really exploit it but if you think about it it sounds like a feature that might have been added recently to the API and so what I did I just scanned all the endpoints with the same URL structure I just change all the like from V 0.02 point 5 point 5 a oh sorry et URL and after I run the script I found that version 2.7 was exposed and didn't verify the device ID it was a very simple way to bypass this neck and and it means full account take over for this food delivery up this is the last slide and I just like to I think it's a good example how API is vulnerabilities require you to turn the stand the logic of the API it's not so easy to find it like good API from relatives but if you use the attack vectors like the known attack vectors for API and you understand logic if the API you can find very interesting stuff any questions any thoughts [Applause] [Music] [Applause]

Channel: OWASP Foundation

Views: 6,506

Keywords: owasp, Global AppSec Tel Aviv, appsec, AppSec, Global Appsec, OWASP

Id: Gc7EUjRsrSo

Length: 28min 18sec (1698 seconds)

Published: Fri Jul 05 2019