2022 APIsecure_Securing APIs with Open Standards

Editor's Notes

• #4: This is a loaded question with many opinions and shades of gray in-between, many of which are valid, but a stark difference exists when determining how to achieve the end-goal. There are some norms that we can all agree on HTTPS or Encryption Using Passwords for Authentication Using Authorization Frameworks and implementing basics security concepts, such as least privilege. But then there is the age old question about documentation. To draw attention or not to draw attention … that is the question. The year is 2022 and it’s about time we stopped asking this question and all agree that documenting and cataloging your APIs in a good thing.
• #5: Let’s take a blast to the past to this little gem … Security Through Obscurity, or STO as some may know it. As a teenager, when I started my professional career back in the late 90s, I often heard this term thrown around in conference rooms and design reviews, and I wasn’t completely sure if people were just playing a joke on “the new kid”, or not, because it sounded absolutely non-sensical to me. (CLICK) It’s one thing for organizations like NIST to have a formal declaration saying that STO is bad, (which you would think wouldn’t be necessary)(CLICK) But it’s another if in today’s day and age that anyone can still believe that sticking your head in the sand or hiding things and hoping no one figures it out is a viable security practice. Let’s face it … Hackers are gonna Hack. If for no other reason, the introspection tools available to hackers these days, both good and bad, are light years ahead of when this belief originated and gained traction. We’re talking the differences between WarDialer and Nmap, Scanning memory dumps on a local machines vs. Burp scanning webapps, and Direct dial-up vs. modern day broadband I’m not sure if people realize it, but despite these evolutions, some organizations still embrace the notion of STO implicitly, when they opt to not invest in mature API design and documentation practices. In this presentation, we’ll talk about ways that open standards and documentation can help, not hurt, your API security posture, and how they, as a pentester, can be leveraged to create a more effective and thoughtful plans of attack and hopefully help stifle some subconscious STO tendencies in the process.
• #6: Let’s take a look to see how far we’ve come as it relates to Documentation … The 90’s were a wild west … Themes cgi-bin perl scripts … local subscription dbs (instead of service calls) … Page Scraping Documentation Argue that primary documentation was spread via word of mouth, on IRC or usenet, Most of the time you got a Text file of varying verbosity If you were lucky you got a ZIP or RAR file with images and supporting information But the tried and true mechanism, was reverse engineering it, which made this a very fun era! 2000’s Themes The rise of XML and subsequently XML-RPC and SOAP … This era was categorically a very RIGID, PAINFUL and LUCRATIVE time in API history =) Documentation PDF emerged in the late 1990s and really came on strong for API documentation … especially since it could be password protected. Java’s Doclet framework was one of the first mainstream interactions WSDL 2010’s Themes Code Generation - API Services are multiplying exponentially as they are getting easier to develop with less code Documentation 2020’s Themes Self-Discovery - API Gateways - Meshes Architectures are rapidly becoming more interconnected and complex Documentation How APIs are documented directly relates to their sustainability and securability … which is why PDFs (even if they are LaTeX generated) continue to be a poor solution Note: “Slate” a once cool pattern for documenting APIs starts to decline … because it inherently iPaaS - Documenting how your services are used but not how they should be tested OpenAPI continues to excel … and Postman Bundles are popular as well because they facilitate automation and tool support for testing at scale downstream. Key takeaway here … is that without a clear documentation strategy, how will anyone know their API security posture? Are they practicing STO, or are they just blissfully unaware? Transition … so how do we close the gap!? Rise of Metadata is apparent … putting that metadata to work for you extends beyond the runtime. The notion of how we operated in the 1990s is the same way some of us are operating now … We are collecting more and more meta-data about how our APIs are consumed, discovered and Services becoming more and more verbose, descriptive and discoverable … how are we harnessing that power?
• #7: Not Understanding Client Use-Cases An in the weeds example that I’ve seen on more than one occasion is a platform defer their API consumption to popular iPaaS venors Platforms that push customers to use iPaaS vendors for “easy integrations”, but have an API that leverages PATCH That’s just not my problem syndrome has consequences …. Bol-On Today, it’s easy to create classes with annotations … when you see an APIs that dont work together, you “Not My Problem” Syndrome Cascading problems when your API is integrated with someone else’s process/platform. Not Understanding the End-Client or Use-Cases ‘Not My Problem’ Syndrome “iPaaS” Readiness (Boomi, Zapier, IFTTT, …) Allow for X-HTTP-Method-Override Lacking Reflexive Verbosity API Key without Programmatic Revoke/Refresh (Manual UI) Not Choosing the Right Platform Start with OpenAPI - GraphQL - Understand why you want to go Base64 Hiding Private API Keys in Client Source Code
• #8: Wasting time and frustrating customers with atypical client scenarios SUPPLY CHAIN !!! You pivot from doing something like a Single Serverless End-Point … to standing up more complicated flows …. Potentially even low-resource VMs which are additional attack surfaces API Keys Leak Search for Webhook End-Points and List All Hostnames Port and Resource Path Information If you are lucky, Basic Authentication URL conventions RULES of Engagement Stop storing API Keys in your source code … obfuscated or otherwise. Reasons for these pitfalls are not always apparent, but a common response if that it
• #9: Reasons for these pitfalls are not always apparent, but a common response if that it Allured by Interesting New Technologies
• #10: Design Easy CRUD Interoperable Services Mocking Data Model / Service Congruence Use-Case Validation Framework definition driven approach Shifts more cycles to detailed design to reap downstream rewards in Testing and Documentation and External Ecosystem
• #11: Streamlining Adoption of New APIs by New People with Different Perspectives and TTP IMPORTANT WHEN IT COMES TO SCALE … Design: Swagger Editor Build: Swagger CodeGen & Annotations QA: Interactive Documentation & Automation Ecosystem: Conversion Tools - GraphQL Swagger YAML/JSON - < 5 Minutes Server Logs (Lucky) - Custom Grep FUZZ (
• #13: What’s important to realize here is that these assets, while created for Developers/Clients … these are also exceptional resources for Security Researchers
• #14: Slack - Simple API Interface, Open Source Tools, In-Product Navigation and Administration, Service Level Control for Tokens! Twilio - Simple API Interface, Gold-Standard Developer Relations, Product Support Google - Robust OAuth 2.0 Role Support … rare to see in the wild … exceptional documentation, training, community … and well it’s google Salesforce - Field level security, Theme here is that an investment in Developer Relations can: Make your API more secure … embrace stronger security practices without compromising adoption and education Let’s face it … up and to the right is golden … Sad face yellow means you run the risk of losing resources and priority Bottom left suggests design / use-case alignment may not be in place Top left is the danger zone where far too many APIs live today.
• #15: Note: Least Common Paths (include APIs that are not referenced in the Getting Started Documentation
• #16: Closed Box (Lack of Options) - Open API with DevRel get
• #17: If you do all these, security through obscurity truly dies.
• #18: Use Open API Frameworks With Tool Support (Documentation) Invest in Adapters / Shims for Legacy Solutions (where possible) Build Onboarding Materials for Core Use-Cases Invest In Your TtFHW / TtFAS Experiences Harness all the efficiencies and productivity of Open API Standards Invest in DevRel=>HackRel=>TechRel solutions By understanding the end-client and crafting an intentional developer experience, these materials can be used to onboard fresh perspectives. Making Things that scale is more than just uptime and performance, it also has to do with incremental sustainability, Don’t get scared of the light … walk into the light If you don’t do it for you … do it for your customers .. and the security researchers that will help you keep your platform secure! Look at the TLDR; experiences … then look at APIs not referenced in those … to see if any interesting data… if in the mainstream, expect better security … but also, expect easier to hide. Document your APIs … You’ll be glad you did! Otherwise, Security Through Obscurity Wins …
• #19: Hello everyone, I’ll be talking on tips for breaking APis that scale, so we're gonna go over some basic things about API security, I will walk you through my API recon methodology , we will briefly talk about some of the common vulnerabilities in API security, I will be showcasing my developed intentionally vulnerable application & APIs and then some of my unique bugs that I found while doing API Security testing. So little bit about me...uh...myself vitthal shinde....I am defending FICO as a security engineer, I am a synack red team member. My expertise are in Web, API, Mobile and Infrastructure security. and views are mine and do not represent my employer.
• #20: I will be walking you through my API recon methodology, some of you may or may not have idea about these recon techniques So where do we start as a BugBounty hunter or as a pentester ? we usually have a limited resources provided to get started on API testing To increase our attack surface we want to know as much as as possible API endpoints , messages , parameters being used and behaviour of them. Before starting the assessment I usually look at and get understanding of what are these API endpoints, ……How developers are handling versioning,........ what are the programming languages used and How to authenticate to the APIs. The more we know the better we can target our attack and easier it is. Okay, Lets get started, the first thing one should look for is….. [Click] …..API Documentation….. API documentation which gives us clear picture on how to use them, I have previously experienced where API documentation have more APIs which are hidden or used on server side in the applications so thats where we can get more vulnerabilities. [Click] We can look at the Older API documentations which have API calls which are still working and not removed, Developers releases new version of APIs by fixing security vulnerabilities in older ones, Lets say current APIs have prevention against IDOR attacks, wherein deprecated versions might not be protected and we can target them and exploit. [Click] One should look for developer portals which may have more info on API calls being used by the application. [CLICK] Swagger UI
• #21: [Click] [CLICK] We can Check if swagger ui is accessible on these kind of commons paths such as /api-docs, /swagger, we can fuzz for these API endpoints. Lets move on to next one.
• #22: [CLICK] What if Application is using GraphQL?
• #23: [CLICK] Check for graphql instance, there is a list of common endpoints on seclist , we can fuzz for those endpoints [CLICK] [CLICK] As you can see in the screenshot apollo graphql instance is running on path /explorer, which might leak some of the hidden API endpoints. We can Check if introspection is enabled ? Introspection is the ability to query which resources are available in the current API schema. [CLICK]
• #24: As in the screenshot, Given the API, via sending introspection query in the request, we can see the queries, types, fields, and directives it supports. So, if introspection is authorized on your target it’s a good news, you will have the possibility to see all useful information to inspect and go deeper on it. We can use tools like GraphQL Voyager to get response in readable format. [Click]
• #25: Okay/ what if introspection is disabled? Fuzz If introspection is disabled on your target (it should be in a safe world), this is a good opportunity to start finding out what they don’t want us to see. By default, GraphQL backend have a feature for fields and operations suggestions. If you try to query a field but you have made a typo, GraphQL will attempt to suggest fields that are similar to the initial attempt. Field suggestions is not a vulnerability, but from hacker’s side, this feature can be abused to gain more insight into GraphQL’s schema, especially when Introspection is not allowed.
• #26: [Click] We can increase our attack surface by looking at the mobile applications which may have different API calls from the standard Web application, Also you can find out more endpoints by digging into older versions of APKs, Ipa [Click] We can look for wadl, wsdl files and parse them using tools like wsdl parser to find out more endpoints. [Click] Next one is JS analysis
• #27: Okay, JS Analysis is a skill……. One can find out all the js files used in the application and feed it to linkfinder and similar tools or manually check them to identify API endpoints which may give us hidden API calls to increase our attack surface.
• #28: We can use github or public repos to recon and find out sensitive data such as API Keys via feeding repos to trufflehog like tools which may give you API keys, secrets, etc. As you can see in the disclosed report, jumbcloud API key of starbucks was leaked in github repo.
• #29: [CLICK] Usually APIs are hidden in common endpoints such as /api , /api/v1, v2 [CLICK] We can Check for verbose error messages thrown when we submit any malicious string in the request, we can dig deep based on that [CLICK] Documentation states only POST is allowed, check for other methods such as GET, PUT, PATCH, Delete. [CLICK] We can convert content type of request from jSON to XML and check for server response and XML related vulnerabilities. [CLICK] Okay, Now we have gathered alot of API endpoints, we can check common parameters and use tools like param-miner to find parameters based on request method, cookies, etc. [CLICK] Last golden Tip - FUZZ, FUZZ , FUZZ We can observe the server behaviour by fuzzing the headers, URLs, and body parameters
• #30: Most exploited vulnerabilities no longer come from web server misconfiguration or SQL injections or browser hacks, instead the majority of widely exploited vulnerabilities now come from application logic, access controls, and other non-conventional flaws. Common Vulnerabilities in API Includes, Broken Access Control/IDOR Sensitive Data exposure Mass Assignment Rate limiting Injection Authentication…JWT Vulns? To Play around them I have developed a ivna [Intentionally Vulnerable Nodejs Application & APIs], Please do check it out. We will be looking some of them in the following demo, Lets move into the interesting demo [CLICK]
• #31: So this is a demo/case study about a vulnerability which I found in cloud communication company. Before we move into the actual vulnerability let me give you all some basic context here Nowadays most of the companies are utilitizing aws s3 service to store files, so how we get access to our resources of application in a secure manner ? By default, all the objects stored in S3 buckets are private which means only bucket owner has access to all the resources/files in the S3 bucket. So to give a access to users data there comes presigned urls. So What are presigned urls ? These are temp. URLs to share files inside the s3 bucket. Using the URL, a user can either READ the object or WRITE an Object (or update an existing object).
• #32: So to brief about this redacted company, Its a cloud based collaboration platform where users can create private groups, add other users, share private documents with them. After testing many hours in the web application, I decided to check Mobile application, And discovered this vulnerability in Mobile applications API call, where API call of Web version was different and was not vulnerable. I may require your attention here please , so the flow of this application works as shown in picture, User access upload/download functionality and API call is triggered to get presigned URL to download/upload files, at the backend Lambda function is triggered and S3 APi is called to generate presigned URL of request object. And finally user can upload or download file using the presigned URL. S3 bucket used here was having correct read, write permissions. Everything looks great, secure right?
• #33: Lets look at the attacker's perspective here I observed that user input was used to generate presigned URLs, so if attacker observes upload/download functionality which is using presigned URLs, it calls the API end point to get presigned URL of requested object. What if attacker requests a presigned URL for root bucket, as presigned URLs are generated based on user input….. attacker can get access to full S3 bucket. We got secure access of full s3 bucket. Ok, enough of theory lets look this API Vulnerability into action. [CLICK]
• #34: Sorry for the bad quality, I have to redact everything for privacy reason. So, this is the API request which is getting triggered when user uploads his headshot, If you observe the url parameter in the body, which consist of presigned URL of s3 bucket. What next ? Let’s check for s3 buckets misconfiguration
• #35: I tried to list bucket , But permissions were in place, so decided to go back to API call
• #36: So, As I mentioned earlier what if attacker gives a root URL of bucket in the parameter of this API request, If you can observe here, I have requested presigned URL of root of the bucket and in the response we have received it. Lets try to access it.
• #37: After opening presigned URL from the response I was having access to full S3 bucket. One can look at the objects of bucket and again generate the presigned URL to get access.
• #38: And creds Lets look into the impact of this vulnerability
• #39: So looking at the impact, I was having access to full s3 bucket which stores all the files shared by user in group and documents. I showed a impact by accessing files which were marked as private, and sensitive data like admin creds.
• #40: So this was a misconfiguration where user input was used in the API call, so never trust the user input. You have to document your APIs and check for exposed APIs. So, Tip for hackers out there, if Target is using AWS S3 to store files? Look for upload/download functionality which uses presigned URLs. Manipulate API parameters to create presigned URL of root URL of bucket and get access to full S3 bucket.
• #41: https://help.salesforce.com/s/articleView?id=000324087&type=1 Okay, Lets move to another interesting demo/case study Before we move into the vulnerability let me give you a bit of context. So Salesforce uses Ids in the application and length of these Ids varies based upon API version API < 2.0 - 15-characters and case-sensitive API <= 2.0 - 15-character case-sensitive ID or the 18-character ID with the 3 extra characters appended, being case-sensitive. API 2.5 - 18 characters on the ID (case-insensitive)
• #42: Where these Ids are used? In every record Lets say you are a user in the application so application recognizes you as based on UserID……again if you upload a attachment it will be a attachmentId, etc. Okay, this demo is about IDOR vulnerability in ticket creating portal
• #43: So this application was a ticket creating portal where users can create ticket and admin users can view them for futher processing. As a user we can do CRUD operations on tickets, also we can add attachments to these tickets. Application was built using salesforce and using graphql for APIs Application was giving us these kind of Ids when tickets were created, if you look closely to them you may have already observed the pattern.
• #44: So Application was using this pattern where till CAPS E ID remains constant and then there are 2 random letter or number and again AA as a constant and 1 letter or number at the end.
• #45: Application was relying on these IDs and there was no authorization checks implemented. And access control issue was there throughout the application, After realising these IDs are constant, I replaced the ID of other users and I got access to the details of other users ticket. Okay, How can we mass leak the data and show impact.
• #46: Lets run a intruder by inserting the correct positions and clicking on start attack. As we have cracked the pattern we have set insertion points based on it
• #47: If you can observe in the screenshot, I was able to access applications tickets created by any user
• #48: Okay, What Other Impact we can show, We were able to perform CRUD operations on tickets, users and as shown in screenshot response leak users PII data such as email, address, phone, etc.
• #49: SO what are the key takeaways in this vulnerability. Don’t Rely on Ids….Its not a prevention against BOLA(IDOR) …….Implement Authorization + Authentication properly ………Implement Rate limiting and Don’t Expose unnecessary sensitive info in response And tip to all hackers out there is if you Came Across application built on salesforce, create as many resources as possible to understand ID pattern and try to bruteforce them Thank you.