 Hey, thanks again for joining us here in the app sec village. Good morning. Good evening. Good afternoon or good night Depending on where you're at in the world kind of a little hard to tell right now since we're not all in one big room together But I've got another exciting talk for you The next talk in our agenda is going to be API and security top 10 a guided tour to the wild wild world We've got two speakers this time. We've got David so pus and Paulo Silva David leads a team of security researchers at check marks and as a co-founder of char 49 With more than 15 years of experience in pen testing and vulnerability research He has been acknowledged by companies like Google Yahoo eBay and Microsoft After retiring from his bug bounty hunting career David now focuses on the Internet of Things security and tries to learn new things each and every day Paulo since his first OWAS local event back in 2010 has been active in the community Contributing to several OWAS projects with over 15 years of professional experience as a software developer He is now focused on ethical hacking and security research with regular collaborations with companies like char 49 and check marks He's interested in programming languages dev sec ops and web mobile secure coding practices Please welcome David and Paulo Hello everyone and welcome to the API and security top 10 the guided tour to the wild wild world Before we start I would like to thank and appreciate the opportunity to be at Defcon even if he's in safe mode and Upset village for approving our research. So thank you Let's start Well, I will start by presenting who we are, okay We with a brief description of what APIs are The importance in today's software the differences from traditional haps Then we went through the OWASP API security top 10 talk a little bit about the project and our contribution to that project and then guns blazing on the API's wild wild world where we show real vulnerabilities on Modern web applications and describe a little bit about our findings We are well, my name is David so push I work for check marks since February 16 I'm currently the security team leader of a very talented group of researchers I'm chief operating officer of And co-founder of sharp 49. I was Bug bounty hunter a few time ago I have a Around 15 years in penetration testing and security research Nowadays, I'm playing more with breaking IoT devices specifically using the LE technology And focusing on modern web applications, of course and API Some of my work you can already see on Tech Ranch the register security week and threat post Sorry about the photo, but I use the pandemic filter I was in During it was during the quarantine in Portugal. So that's it. I think it was very appropriate to this event moving on to Paulo Hello, and thanks for watching. My name is Paul Sylv and it's a great pleasure to be presenting at DEF CON especially together with my friend David I used to define myself as a freedom enthusiast since I love everything related to free and open source software worldwide web or cross-countering and bikepacking. I Have more than 15 years a software developer. What is plenty of time to have done all sort of mistakes? Right now, I do ethical hacking and security research and since 2010. I'm a regular OASP volunteer I'm Currently I'm the OASP go secure coding practices project co-leader and main collaborator on OASP API security project Meanwhile, I'm used to fill the gap and deliver security awareness sessions in academia Before continuing the mandatory disclaimer hacking systems without permission is crime and We are not responsible for misuse of any information. We are about to disclose Let's talk a bit about APIs. I Like to look for definitions in the dictionary because words matter Nevertheless, I'm not expecting to find Definition for API in the dictionary but Something interesting about interface Defined as a common boundary of two bodies. In fact, we can think about APIs this way Common language that connected things talk in order to get work done APIs have a central role in today's software. They are the common ground among several types of devices and applications a generic language that all them know how to talk to exchange data and execute functions This is different from traditional web applications in many ways before we had web servers playing this central role Doing the heavy work answering client requests Gathering data from databases and other web services Glowing everything together computing the final HTML and returning it back to the client to be rendered Nowadays there are several types of clients behind web browsers We have smart bulbs wearables cars civil surveillance cameras, etc. Etc. Etc. Etc. All These clients use APIs to make their capabilities available to other clients and to communicate with each other Clients are now more powerful than they were before In modern web applications. There's a clear separation between front-end and back-end The front-end nowadays is a bunch of JavaScript and CSS providing rich user interfaces to collect data Send the data to several APIs Making it generally available to all clients regardless their type. I think this is a Pretty much about APIs and we should move on to the all-asp API top 10 with David So alas API security top 10 You may already Heard about alasp in its own words is a non-profit foundation That works to improve security of software What's top 10 is one of the flagship projects and most of you should already know it already It has played a enormous role to bring security awareness into organizations both to management and dev teams, but we have seen very specific API related issues popping up we should learn from past mistakes and Erres Yalon and Inon Scadi decided to start the alasp API security project to address API specific issues the document follows the same approach and popular wasp top 10 for readability purposes But it's 100% API oriented or contribute Vendors had been doing business as usual and there's no API specific data For a public call for data like other alasp projects. So we had to research There are several bug bounty programs that released for disclosure write-ups and We went there and even on some public information that we got hands on But we had to review it and pick only the API related issues So while reviewing the report and the write-ups, we start standardizing categorization and grouping things together After a few months, we were able to compute a statistical top 10 security risk of course was was using the alasp Risk rating methodology We drafted the first alasp API security top 10 and asked several entities Organizations and individuals with relevant upsec experience in the API field at least to get us some feedback The draft was published on Github and during the several months we worked with up a sec community to to get some feedback and Change a little things by the end of 2019 The final version was published and we're very happy with it Then we went wild to validate how accurate the wasp API security 10 top 10 2019 was so Hope you can have the opportunity to download it and see it API is in the wild wild world our research so Our focus was only on I profile web applications And of course focusing on the API We want to map all the vulnerabilities that we found on the wasp top 10 nine two thousand and nineteen so You may ask what was our biggest Problem if I can say that and And Yeah, it's it was the responsible disclosure because many companies didn't reply or just didn't care about security So that was the most Challenging issue that we encounter on our research. We tested eight APIs we discovered 28 API issues that we categorized on the on the your as you can see on the Right table We got a minimum CV SS 2.7 and a seven point seven max We found seven broken user authentication we Five with five issues we have broken object level authorization or Bola or X and also with five excessive that exposure Security misconfiguration was for Broken function level authorization three and also with three lack of resources and rate limiting three Finishing with one result on injection not so common anymore findings Moving on to Paul Okay, let's start with the broken object level authorization You may know this by I door or insecure direct object reference But while writing a last PPI security top 10 we decided to rename it since I door is not a very accurate name In this case we found two Exposed API's a graph QL and a rest one both vulnerable to broken object level authorization As you may know graph QL is not like Rests and you should ask for what you need and you will get exactly that nothing more nothing less This is valid for resources like profile, but also to their fields Of course, we can try to guess everything or use word lists But it becomes even more interesting if you find another vulnerability Like a security misconfiguration allowing you to query that information More details about the security misconfiguration specific to graph QL And it's specific section. You just have to wait a few more issues and we will get there By now, let's focus on the requests on the left side We are looking for a specific profile based on its on its slug The slug is public information since it's part of the user's public URL On the right side, we have the API response. We can see users public URL the slug and also Something that points the profile to be private, but nowadays we never know what private means We have several other properties, but there's another one the ID Which we will use with the rest API So we took the ID property we got from the graph QL API and we used it to request a user on the rest API We got additional information including billing information with full address and tax ID number At least this time API doesn't say that the user resource is private But note that both requests were anonymous. There was no authentication nor authorization I think this was a good warm-up. We can continue with David broken user authentication in this case SoundCloud our final objective was to get account takeover and we did it So on SoundCloud, which is already disclosed this issue I Can give you a brief description what we did so on user user account lockout Based on failed login attempt something that we don't see often in this case the API was API was rate limited so neither less it was possible to bypass and we will show you how So chaining the rate limited bypass with the user enumeration issue that we found We were able to accomplish the account takeover via credential stuffing attack This is a typical user enumeration scenario where we abuse the recover password mechanism We have a binary feedback Depending either the provider the mail belongs to a user account or not as you can see on the perp screenshot rate limiting bypass Was something fun because at least was the first time we saw it It was based on the user agent the device ID and signature So both device ID and signature was computed client side instead of reversing the JavaScript Logic we gather three different Combinations to be randomly picked by our brute force script After a first fix attempt, we will also use different EIPs by using Tor Forcing different as it nodes Rate limiting is very important of course and it should be very restrictive for authentication and points But it can also not Enough to prevent what the user account lockout does which should be implemented both authentication and rate limited So this is an example that we did With a single thread of POC running in an ordinary laptop for sure if you use concurrency or parallelism and cloud-based approach We have done it much faster for sure so in the end this is the Access token we can have and the account takeover is Completed to follow Let's talk about excessive data exposure This is probably one of my favorites finding We started with the user enumeration issue on the recovery password mechanism And later a security misconfiguration allowing us to leverage the the attack The recovery password required the user to provide its email address on the front end which then issues an API request to retrieve a list of available delivery Channels either email or phone the user can pick one on the front end and then one time password is Delivered so that it can Recover his password in this workflow. We noticed that URL including a JSON web token Were provided for each delivery method. So we took the phone URL and decoded the JSON web token then we found that The actual user phone number is included in the JSON web web token payload section Meaning that we can exchange user emails by phone numbers note that These API requests are anonymous since they are aimed to recover passwords we decided to Go further and do this for an arbitrary list of email addresses that we gathered from pastebin.com It had 169 email addresses and we got seven user accounts with email and phone number Meanwhile, we found a security misconfiguration In fact, we found an exposed error log file including some sensitive information, but the most interesting one was The location of some internal files. Luckily, these files were also Exposed and publicly accessible and this is how some of them look like they were mailing reports with valid user account emails And also the mailing subject. So Just by themselves, they were good enough to be used for a phishing campaign But we could even enrich it with the phone numbers complete the the info and drive some phishing or smishing attack API is tend to handle huge amounts of data and some of them also leak part of that data You may know meetup Meetup offers pro accounts which give you access to unlimited groups and targeted communications to members. You get several other features All of them for $30 per month per group And in fact, you also get access to free email addresses Regardless of what privacy settings you choose and what meetup says that they won't give your email address to anyone What we saw is that as long as you can issue an API request You will be able to retrieve email addresses from the API and We did this for 38,504 user profiles Just on the war the WordPress network. I Think it's quite huge Let's continue with the vids with lack of resources and rate limiting Well with lack of resources and rate limiting The final objective was user enumeration. So what we have is a improper rate limiting and In the end we got the user enumeration In this screenshot you can see because to be fair The meetup, which is the target add the rate limiting defined on It followed the best practice. You can see the x rate limit Custom response header But when we try to enumerate members we noticed that Something was strange We noticed that after a few Rate limit is to requests. It just got stuck. So I don't know if it was a bug on the server side or Something like that because it allows us to continue and did not lock our attempt to enumerate Just a small video Nothing fancy, but you can see that in the end after a few requests we we did found a lot of User Names that we could use Okay, so just simply enumeration including the username User location the profile photo and by the way you can see on the bio that it's the co-founder and former CTO of Meetup and PM on Facebook. So it was well, it was the number two. So I'm supposing it The idea was Very close to be the founder or something very important on the meetup But it just to show you that a simple if you don't control and test the the rate limited Protection You need to make serious you better testing it's not just put a header and didn't test in Forget it. You need to to control it. Okay, so to follow Let's talk about the second authorization issue in the OSP PI security top 10 broken function level authorization We began with broken object level authorization and you should expect something similar But instead of requesting Objects by their unique identifier. We're gonna ask APIs to execute functions either regular user or admin ones We're glad you stick with us until here because we didn't have the chance to talk about COVID-19 pandemic yet This pandemic among severe other severe consequences also created a new battleground conferencing tools and services By the way, this finding was yet another great job by our friends Jean-Maurice and Guillaume L'Opge Jean-Maurice is also presenting at DEF CON this year together with peter humbleen another friend of us And you should not lose the chance to watch their talk In addition to the audio and video features this conferencing tool also offers a user chat I think they know that users need a way to ask others whether They can hear them I'm not sure whether this is foolproof, but let's see what we found While joining the meeting we noticed an API request like the one on the left The response on the right returns a list of participants We don't know what the ticket code is But when we see an america identifier like the viewer code id we shortly test it So simply iterating over a viewer code id We got Exactly one thousand four hundred and ninety six email addresses from other meeting participants And we also got six hundred and seventy three phone numbers from the same participants Let's discuss security misconfigurations with David Security misconfiguration Well with security misconfiguration, we did found a couple of things, but please don't expect too much from here It's really a bunch of nothing we did found stack traces and one of them Not related to the stack trace one of the security misconfiguration was a graph QL introspection We Was a little bit it was I think was one of the first time That I I saw it in in production, but Let's see it in detail Okay, so stack trace on an end-all job exception. So this type of Vulnerability is like boring moving along Another stack trace, but this time with more style. It's an oj s an end-all exception Well, at least it's cleanup your own mess, right? Okay, finally something more clean You know that development tools should not be deployed in production, right? And yes, this is the graph QL introspection attack And please graph UL introspection Should be disabled in production like I said before This will give you the the the attacker the opportunity to get the structure Of your database and many more information. So devs Keep that in mind also Unique ID is base 64 of the skated. This is what We underlined on the burp screenshot By the way, base 64 is in coving and not of the skated But anyway, thanks for the detailed explanation Injection one of my favorite Sections of this presentation and guess what? We chain The vulnerabilities with cross-site scripting and cross-site request forgery and in the end. Well, yeah, we have the cool Cool Scenarios to present Guess what meetup all your meetup belong to us Um, what's the what was the the real objective? Well, uh, I used meetup and when I see a discussion Part where you could post some comments and messages to the to the group itself It immediately wanted me to pop up some alert box and Coming from a guy that Loves and keeps studying cross-site scripting attacks. It was Something that I would like to do The front end immediately won't allow it and sanitized most of the content that I posted So after a while and checking the burp proxy logs, I noticed that Some requests were being made to the api. So api did the job I did found A payload that immediately triggered what I wanted in this case the alert one And It's not the payload. It was not mine. Of course. I want to to thank gareth haze the Which compiled a Magnificent List on on parts figure. So check it out We don't have the original name for for the guy that created this payload, but it did the It was the starting point to to our attack So what we wanted to do, okay, let's be the organizer of the meetup. Let's steal a meetup group We noticed that even using the api we have some shards were removed sanitized or whatever, but Also, they were very easy to bypass. We just used eval and encoded in basis 64 We we wanted to create A payload that will trigger a vulnerable cross-site request Forgery endpoint that we found previous So he pointed to the Uh iFrame that submitted autosubmit form That allowed The authenticated Organizer to approve another user to co-organizer We have a video showing that So we have the drop the payload meetup That it's own By funky cat as you can see we have the discussion part pretty easy. It's default on most groups. So in members we have Funky cat as a leader organizer, uh, and david sopas as a regular member This david sopas is crazy. I don't know if it's malicious or not So we triggered our our poc, which is the payload And after the funky cat Reloads the page you will see a new comment In this case, it will be an empty Comment. It doesn't say anything. So funky cat will be like, oh Okay, this guy didn't post anything. That's weird. But when you check members, you can see that Now david sopas is the co-organizer All funny is that and he can do anything with it. He has almost the same options that Then the funky cat so Cool, right But we wanted more of course We are security Researchers we always want more. So give me some money. Please. I love this man by the way. Show me the money So we created a new poc You can see On on the bill ball account or the payments received The funky cat can collect use to meet up members or charge members for any meet up and anything. So you have also A box where funky cat can put his his paypal account But on your right side, you can see a messy co-request just copy pass from burb Where we use the api and trigger our payload the same way inserting in in the discussion part and when it triggered it will post the The payload on the discussion part and when the funky cat goes to his page and Refreshes the the the meetup group You will get a new message also, but again empty no problem at all But when the random fun meetup, yeah, that's a random names, okay So we go to settings payments receive and guess what? to Paypal account is now sending all your cash to evil hacker That's cool, right Moving to paul because this one is a huge thing I'm not sure whether this is gonna be huge, but regarding logging and monitoring This is what I believe happens most with apis Either they're not producing enough logging logs have not enough details or Simply api admins are doing nothing with them During our account takeover attempts. We never received an email saying that our testing account was under attack On the other hand our security advisories are always received with great surprise So we tend to assume that our activities were unnoticed and this is not how it is supposed to be logging and monitoring Should help organizations to mitigate the risk and act on a timely fashion It's time to wrap up this talk. We're gonna share our final thoughts We definitely think that apis are juicy They tend to handle huge amounts of data and they also leak some of that data We still see lots of user authentication issues They were common on traditional web applications and they are still common on apis The same way we see a lot of Authorization issues the api scope tend to be big and complex And authorization is not an easy task We have been watching the rising of graphql We still see rest apis as well as xml or jsnrpc apis But the number of graphql is increasing rapidly And graphql is a very recent technology and it brings specific security concerns Finally We from our experience organizations are still taking too long to answer for and fix vulnerabilities and This is something that we will keep working to improve with our research and Responsible disclosure We don't want to finish before leaving a special thanks to both checkmarks and char 49 For the great opportunity to presenting our research in defcon We are available to answer your questions. Feel free to reach us on twitter and keep safe and strong