Securing APIs with Open Standards provides tips for securing APIs from the Synack Red Team. It discusses using OpenAPI definitions to document APIs, embracing open box testing, and balancing security and adoption through developer relations. It also demonstrates how insecure user input validation can allow access to private data stored in AWS S3 buckets and how Salesforce record IDs can be brute forced to enable unauthorized access if not properly secured. The presentation emphasizes designing APIs with security in mind, adopting standards like OpenAPI, and balancing security testing with developer onboarding.
1. Securing APIs with Open Standards
Tips for making and breaking APIs that scale
from the Synack Red Team
2. Vitthal Shinde
Security Engineer, FICO
Synack Red Team
● Security Engineer (4+ Years)
● Builder | Breaker (∞)
Ryan Rutan
Sr. Director of Community
Synack Red Team
● Red Team Director (3+ Years)
● Community & DevRel (12+ years)
● Developer, Architect (20+ years)
● Hacker / Maker / Author (4L1f3)
#forkthislife
SPEAKERS
@SynackRedTeam @ryanrutan @VitthalS @0_1VitthalS
4. Security Through Obscurity (STO)
The belief that a system of any sort
can be secure so long as those
outside of its implementation group
is allowed to find out anything
about its internal mechanisms.
System security should NOT depend on the
secrecy of the implementation or its components.
See Also: https://en.wikipedia.org/wiki/Security_through_obscurity
5. Documentation … How Far We’ve Come
ERA API THEME(S) DOCUMENTATION
1990’s /cgi-bin & Subscription DBs &
“Page Scraping” DOM Wars
WoM/TXT/ZIPor RAR
Reverse Engineer It!
2000’s XML / XML-RPC / SOAP PDF - WSDL/UDDI - Doclets
2010’s REST/JSON + Code Generation PDF - WADL - ”Slate” - Swagger
2020’s Self Discovery (Metadata) - API
Gateways - Composite - Mesh
PDF - ”Slate” - iPaaS -
OpenAPI - Postman Bundles
6. API’s Must Be First-Class Citizens
- Indifference to Downstream Impact
- Non-Interoperable Services / Models
- i.e. Get by URI, have only Email
- Bolt-On API Strategies
- Not Understanding Client Use-Cases
- Picking the Right Framework
- Homogenizing Security Testing
- Obstacles to onboard new testers
7. API Design Security Implications
- Most Common Integration: IFTtT(x1)
- Increased Complexity & Costs
- Unnecessary Integration App Logic
- Try Injection / Logic Bugs
- Unnecessary PII Persistence
- Always Protect Storage
- Makes API Key Leaks More Potent
- Find Ext/Webhook Endpoints
- RoE: In-Scope?
8. OpenAPI Definition Driven Model Helps A Ton …
swagger.io/blog/api-strategy/benefits-of-openapi-api-development/
9. - OpenAPI to GraphQL - https://github.com/IBM/openapi-to-graphql
- Safety net to always try OpenAPI first! Remember: API Gateways
- Platforms Retro-Actively Releasing OpenAPI Descriptors
- Native OpenAPI Project Import into Burp, Postman & Zap
- OpenAPI Fuzzer - https://github.com/matusf/openapi-fuzzer
- Time saved compared to closed box enumeration is exponential
- Tip: Custom script options available for reliable & repeatable results
OpenAPI Third-Party Ecosystem is Thriving
10. Closing the Loop with Developer Relations
- Objective: Bolster Tech Adoption
- Focus:
- Communicate Use-Cases to Tech
Adopters
- Advocate for the Developer Experience
- Channel Tech Adopter Feedback
- Create Strong Community at Scale
- Works With:
- Marketing, Sales, Partners, Engineering,
Product, Support, Customer Success, …
see: TeePublic
11. Three Pillars of Developer Relations
Getting Started
(a.k.a TLDR;)
- Official Use-Cases
- Example Code
- Blogs, Videos
Training
(Documentation)
- Auto-Generated Assets
(Ideally Interactive)
- KB
Support
(How to Get Help)
- FAQ / KB / Contact
- Community / Collab
- VDP
Simple Video (<5 minutes) Interactive OpenAPI Docs FAQ + VDP + Contact
Simple “Developer Experience” In A Box
13. DevRel : HackRel - Two Sides of the Same Coin
DEVREL HACKREL
# of Developers # of Researchers
# of Use-Cases (Most Common Paths) # of Use-Cases (Most & Least Common Path)
# of Supported Integration Languages
- Java, NodeJS, Ruby, GoLang, etc…
# of Supported Automation Languages
- Python / Java, etc…
Time to First Hello World (TtFHW) Time to First API Scan (TtFAS)
Technical Support Process - Clear and Easy Vuln Disclosure Program - Clear and Easy
14. Open Box vs. Closed Box Pentesting Results
- Opportunity Cost for Security Researchers is High
- Cybersecurity gap means less researchers doing more
- Attractive targets are those that can be easily onboarded,
automated and streamlined.
Open Box
- Clearer Scope
- More Diverse Audience
- More Efficient + Attractive
- More Nuanced Research
- Higher Quality Baseline
- Tests Your API
Closed Box
- Opaque Scope
- Less Diverse Audience
- Less Efficient + Attractive
- Less Nuanced Research*
- Lower Quality Baseline
- Tests The Tester
15. What Does It Mean to
Secure Your APIs?
Proposal: Say “YES, I Secure My APIs!” if ALL are TRUE:
- Intentional design & development of APIs to solve use-cases
- Automated documentation and Dev/HackRel enablement artifacts
- Regular, diverse and objective security testing practices
- Curated & maintained index of public/private/protected APIs
16. Takeaways
- Embrace OpenAPI for All New
API Development
- Backport legacy API definitions
- Invest in Proportional &
Repeatable Dev/HackRel UX
- These experiences pay dividends
- Use Open Box Testing
Whenever Possible … Reap
the Awards of Your Efforts!
- Codify Your TTP with Open
API Tools & Scripts
- DevRel Experiences Pave
Roads To Test - Which Path?
- diff: Getting Started & Training
- Don’t Forget About Integration
Middleware Services
- API Keys Stored
In Source Code
- Ext / Webhook Registration
Takeaways
17. Securing APIs with Open Standards
Tips for making and breaking APIs that scale
from the Synack Red Team
Vitthal Shinde
Security Engineer, FICO
Synack Red Team
18. API Recon
● API Documentation
● Older API Documentation
● Developer portal
● Swagger UI
19. Swagger UI
- Common paths ?
https://twitter.com/nahamsec/status/1280246454884331520?lang=en
20. API Recon
● API Documentation
● Older API Documentation
● Developer portal
● Swagger UI
● GraphQL?…Introspection
27. API Recon
● API Documentation
● Older API Documentation leaking older working API calls
● Developer portal
● Swagger UI
● GraphQL?…Introspection
● Mobile application?.....Older versions of APKs, IPA
● WADL, WSDL files
● JS analysis
● Github, public repos….trufflehog
● Common endpoints…./api, /api/v1/, /api/v2/
● Verbose error messages
● Allowed methods….GET/POST/PUT/PATCH/DELETE
● Allowed Content Type ….JSON → XML
● Common parameters….param-miner
● FUZZ….FUZZ….FUZZ
28. Common API Security Vulnerabilities
● Broken Access Control/IDOR
● Sensitive Data exposure
● Mass Assignment
● Rate limiting
● Injection
● Authentication…JWT Vulns?
Vulnerable Application -
https://github.com/VitthalS/ivna
29. Demo/Case Study - Cloud Communication Company
How can I allow users to access objects in S3?
- By default, all objects are private — meaning only the bucket account owner initially
has access to the object.
- Create a presigned URL - Users can interact with objects without the need for AWS
credentials or IAM permissions.
What is presigned url?
- Temp. URLs to share objects inside the bucket
- Using the URL, a user can either READ the object or WRITE an Object (or update an
existing object).
30. Demo/Case Study - Cloud Communication Company
- Cloud based collaboration
solution
- Using API Gateway & S3
- Looks Secure ..?
31. Demo/Case Study - Cloud Communication Company
- User input used to
generate pre-signed
URLs
- Secure access of
full S3 bucket
32.
33.
34.
35.
36.
37. Impact Analysis
Access of full s3 bucket which stores application users sensitive data
such as Files, Documents, Images
Access of files which are marked as private.
Sensitive data such as username/password.
38. Takeaways
Never Trust User input
Document your APIs
Check for exposed APIs
Tip: Target is using AWS S3 to store files? Look for upload/download functionality which uses pre-
signed URLs. Manipulate API parameters to create presigned URL of root URL of bucket and get access
to full S3 bucket.
39. Demo/Case Study
Salesforce IDs
- 5003000000D8cuI
- 000000000000Abc
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)
https://help.salesforce.com/s/articleView?id=000324087&type=1
40. Demo/Case Study
Where are they used?
Every record, regardless of entity type, has a globally unique identification value in its
ID field which is generated at the time of record creation.
Record ID value will never change, even if the record is deleted and then undeleted.
- userId
- attachmentId
- documentId
- reportId
41. BOLA (IDOR) - Ticket creating portal
Background:
- Ticket creation application where users can create tickets, view them,....CRUD
- Users can add attachments to the ticket
- Application was built using salesforce and using graphQL for APIs
- Ids for creating cases, attachments, users, etc
Example :
5002z000002VEjcAAG
5002z000002VEjXAAW
5002z000002VEjNAAW
5002z000002VEWIAA4
42. Identify the pattern of created resources
Pattern :
5002z000002VE<<random_two_letter_or_number>>AA<<random_one_letter_or_number>>
46. What Next? …..We need
Impact
CRUD Operations on tickets
CRUD Operations on User
PII Leakage
47. Take-Aways
Don’t Rely on Ids….Its not a prevention against BOLA(IDOR)
Implement Authorization + Authentication properly
Implement Rate limiting
Don’t Expose sensitive info in response
Tip: : Come Across application built on Salesforce? Create as many resources as
possible to understand ID pattern and try to bruteforce them
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.
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.
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?
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
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
Reasons for these pitfalls are not always apparent, but a common response if that it
Allured by Interesting New Technologies
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
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 (
What’s important to realize here is that these assets, while created for Developers/Clients … these are also exceptional resources for Security Researchers
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.
Note: Least Common Paths (include APIs that are not referenced in the Getting Started Documentation
Closed Box (Lack of Options) - Open API with DevRel get
If you do all these, security through obscurity truly dies.
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 …
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.
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
[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.
[CLICK]
What if Application is using GraphQL?
[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]
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]
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.
[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
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.
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.
[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
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]
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).
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?
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]
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
I tried to list bucket , But permissions were in place, so decided to go back to API call
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.
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.
And creds
Lets look into the impact of this vulnerability
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.
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.
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)
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
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.
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.
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.
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
If you can observe in the screenshot, I was able to access applications tickets created by any user
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.
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.