Black and Blue APIs: Attacker's and Defender's View of API Vulnerabilities
- 1. Black and Blue APIs Attacker's and Defender's View of API Vulnerabilities
- 2. TABLE OF CONTENTS 01 Intro Quick background and such 03 Attacking APIs How to attack and what those attacks look like 02 Why Attacking APIs? What makes APIs interesting to attackers 04 Conclusion Key takeaways and your questions
- 3. Who is this guy? ● Reformed programmer & AppSec Engineer ● Noname Security - Distinguished Engineer, Noname Labs ● 14 years in the OWASP community ○ OWASP DefectDojo (core maintainer) ○ OWASP AppSec Pipeline (co-leader) ○ OWASP WTE (leader) ● 22+ years using FLOSS and Linux ● Currently a Go language fanboy ● Ee Dan in Tang Soo Do Mi Guk Kwan (2nd degree black belt) ● Founder 10Security
- 5. It’s All About the Data “Data is the new oil” Clive Humby British Mathematician “APIs are data pipelines” Matt Tesauro Your presenter
- 6. Even if you have a solid AppSec program App Sec Tooling API Sec Tooling SAST SCA DAST API Gateway API Inventory SDLC API Management API Specs WAF Threat Modeling Rate Limiting Anti-Bot Protection Developer Training App Inventory Service to Service Auth-n Anomaly Detection JWTs OpenID Connect OAuth2
- 8. Defining the 3 Pillars of API Security 1. API Security Posture a. Full inventory of all APIs b. Who is calling the API? What data is sent/received? Where did the call originate? 2. API Runtime Security a. Watching API traffic and understanding what is normal b. Anomaly detection and alerting 3. API Security Testing a. Assess the security state of APIs b. DAST, not SAST ideally tested early and often c. Feed results into the issue trackers used by dev teams
- 9. A better (security) definition of an API An API consists of 3 parts: (1) Hostname e.g. example.com, uat.bigcorp.com (2) Path e.g. /api/v2/users/all , /v1/cart/addItem (3) Method e.g. POST, PUT, GET, PATCH, DELETE, … GET to example.com/v2/users/all!= DELETE to example.com/v2/users/all POST to uat.example.com/v2/user/admin!= POST to example.com/v2/user/admin
- 11. Active Attacks Getting malicious with your API target
- 12. Attacks are grouped into the API Top 10 API-1 Broken Object Level Authorization (BOLA) API-2 Broken User Authentication API-3 Excessive Data Exposure API-4 Lack of Resource & Rate Limiting API-5 Broken Function Level Authorization API-6 Mass Assignment API-7 Security Misconfiguration API-8 Injection API-9 Improper Assets Management API-10 Insufficient Logging & Monitoring
- 13. Broken Object Level Authorization Attacker ○ Look at how API resources are structured ○ Change IDs within API calls ○ Can be names (non-numeric) ○ Make calls to other IDs/resources with your Auth-N method / token ○ Create something as user 1 ○ Try to access it as user 2 ○ Response differences ○ HTTP Response code (404 vs 405) ○ Time to respond ○ Length of response (rare) Defender ○ Detection requires fairly deep inspection of the API calls ○ WAFs will generally fail ○ Shaped like legit request with IDs swapped ○ Looking for BOLA can cause increased Auth-Z errors ○ 2 similar requests from the same client with different IDs can be found by ML ○ Posture - focus on most risky APIs Runtime - detect BOLA attacks Testing - Find BOLA early / pre-prod One user can access another user’s data or take actions for them
- 14. Broken User Authentication Attacker ○ Bruteforce credentials ○ No anti-automation on password resets or MFA/CAPTCHA ○ Password Spraying ○ Base-64 “protections” ○ Low entropy tokens ○ JWT weaknesses ○ Captured JWTs ○ None algorithm, no signature ○ Key mismatch, blank password, … ○ Cracking JWT secrets ○ jwt_tool Defender ○ Bruteforce attacks are noisy ○ Password spraying is very noisy ○ Ensure crypto is used correctly and carefully ○ JWT Best Practices RFC ○ Consider removing Auth-N from the API ○ Only get tokens through web app ○ Posture - identify Auth-N APIs Runtime -detect brute force, spraying, JWT manipulation Testing - identify poor practices early Using poor practices in authentication to attack APIs
- 15. As browsers and web apps get hardened… B r o w s e r I m p r o v e m e n t s M F A , C A P T C H A APIs
- 16. Excessive Data Exposure Attacker ○ Look for API responses that provide ‘extra’ information ○ Mobile app APIs tend to trust client to filter data ○ Look for ‘interesting’ responses ○ Profile pages ○ Linked users ○ Internal meta-data ○ Is the data expected part of a larger data object or DB row? ○ Can be time consuming to check all possible responses for excessive data Defender ○ Single requests can’t be distinguished from normal traffic ○ SAST can help here to avoid “to_json” or similar ○ Don’t rely on clients filtering data ○ Separate data objects for app and API ○ Posture - Shows sensitive data, large responses Runtime - Detect multi-request data scraping Testing - Find verbose responses early Sometimes developer productivity helps attackers too!
- 17. Lack of Resource & Rate Limiting Attacker ○ Add thousands of items, ask for a list ○ Lack of pagination ○ Denial of API use (client) ○ Fuzzing and bruteforce attacks can discover these ○ Modify requests, different client, different IP to bypass limits ○ CPU / Memory intensive requests ○ robots.txt or documentation ○ Other games to play ○ Switch cAsE ○ Null and other terminators ○ Encoding data ○ Too high to make a difference Defender ○ Some requests will look normal but with large responses ○ Unusual requests ○ Headers, encoding, terminators, … ○ Observability can show usage spikes ○ Many bypass methods stand out from normal traffic ○ Posture - Determine APIs needing limits Runtime - Detect anomalous traffic and respond Testing - Fuzzing request data can find some issues early Failure to provide limits is a recipe for DOS or worse
- 18. Broken Function Level Authorization Attacker ○ Focus on APIs with multiple roles/groups ○ Potential for expose backplane ○ Most things have an ‘admin’ ○ Try undocumented HTTP methods ○ PATCH, PUT, POST, DELETE (!) ○ Create items with one group/role ○ Interact with those items as a different role ○ Bruteforce / guess potential backplane operations ○ Experiment with headers, request data to access admin functions Defender ○ Affects APIs with 2+ roles, groups, privilege levels ○ Calls to unsupported methods that fail ○ Same client, different roles within a short period of time ○ Failures for backplane/admin paths ○ Unusual requests - headers, body ○ Posture - Determine APIs with groups, roles, privilege levels Runtime - Detect unusual, failing requests or changes in role from a client Testing - Conduct Auth-Z testing early Failure to restrict access by group or role leading to compromise
- 19. Mass Assignment Attacker ○ Look for requests that appear to be partial data ○ Make guesses at unsent items ○ Look at request/response difference between roles/groups/privilege levels ○ Guess / bruteforce multiple values at once (hail mary) ○ Error messages or required field messages can provide clues ○ Fuzzing can also find issues ○ Combine with Broken Function Level Auth-Z to change data for other users ○ Change email/contact details Defender ○ Requests stand out from normal requests with deep inspection ○ Large number of failed/invalid requests ○ Increased request size ○ Increased severity for APIs with different roles/groups/privileges ○ Posture - Focus on APIs with multi-roles or sensitive data Runtime - Requests with extra data, multiple failed/invalid requests Testing - Add additional, valid fields to discover early Why not accept more data, what could go wrong?
- 20. Security Misconfiguration Attacker ○ Check the basics ○ TLS config ○ Info leaks via headers, etc ○ Default credentials, EICAR ○ Use Recon and Discovery ○ Verbose errors ○ Purposefully make bad requests ○ Misconfigured framework settings ○ Debug mode ○ Intermediate devices ○ Determine if WAF, API Gateway, etc is in line ○ Call ‘internal’ functions with origin headers e.g. X-Remote-Addr Defender ○ Basic network vuln scanners can find the basics ○ Passive traffic monitoring can show header issues, API gateway bypass, many others ○ Client with many erroring or malformed requests ○ Posture - Show weak configuration e.g. API gateway bypass Runtime - Unexpected client traffic, multiple errors, malformed or anomalous requests Testing - Good for the basics, better if fuzzing is included in tests A little misconfiguration can go a long way
- 21. Injection Attacker ○ Place injection strings into ○ Tokens / API keys ○ Headers (esp API specific ones) ○ Query data ○ Data in request body ○ Recon/Discovery can help focus what types of injection to try ○ Error messages can also help ○ Many good online resources for injections ○ Fuzzing lists ○ OWASP Testing Guide ○ 2nd order injections Defender ○ Input validation AND output encoding ○ Many failed or malformed requests ○ Large number of errors or validation failures at API ○ Overly trusting of East/West API calls ○ Posture - Focus on APIs with sensitive data, East/West APIs Runtime - Surge in errors, failed, invalid or malformed requests, control characters in requests Testing - Attempt injections early in dev cycle Treat data like code and bad things happen
- 22. Improper Assets Management Attacker ○ You find many misconfiguration issues ○ Internal APIs are publicly accessible ○ API documentation is inaccurate ○ “Hidden”/undocumented APIs ○ Dev/New APIs in production ○ Legacy APIs are not decommissioned ○ API v minus 1 or more available Basically, your pen test was productive and easy Defender ○ Need to know all APIs (host, path, method) ○ Classify all data received and sent by APIs ○ API Gateway enforced, East/West traffic ○ Public vs internal APIs ○ Posture - Solved with solid posture management Runtime - Updates posture as environment changes Testing - Not particularly useful here Know what you have if you want to protect it adequately
- 23. Insufficient Logging & Monitoring Attacker ○ Fuzzing does not cause a reaction / blocking ○ Assumes control is in scope for testing ○ Attacks, especially blatant injections go unnoticed ○ Phone numbers never look like: <script>alert(XSS)</script> ○ Mostly, external testers / attackers can only infer the level of logging and monitoring Defender ○ No attacks are seen / noticed ○ Diagnosing API issues is difficult ○ Unplanned downtime or resource consumption ○ Posture - Determine the appropriate level of logging per API Runtime - Monitoring is what this provides, also can retain traffic for analysis aka quasi-logging Testing - Validate logging is working (at best) Change guesses to decisions with data
- 24. Bonus Material Things that didn’t fit nicely into the OWASP API Top 10
- 25. Structural vs Data Attacks Structural Attacks ○ Modifying the structure of a request ○ Repeating data structures ○ Adding non-printing characters e.g. spaces, tabs, null characters between data elements ○ Removing portions of the data structure ○ Messing with the structure of the request only - data provided is legit ○ QA / HTTP testing tools generally normalize the structure so won’t work ○ Custom craft HTTP requests (Python requests library) or use a local proxy like Zap or Burpsuite Data Attacks ○ Modifying the data in a request ○ Substituting fuzzing / injection data for legit data values ○ Providing unexpected or overly large / small data values ○ Structure of the request is not modified ○ What most fuzzing and injections attacks look like - changing data without changing the structure ○ QA / HTTP testing tools can be leveraged to automate these attacks 2 fundamental ways to be naughty with APIs
- 26. GraphQL - left as an exercise for the student Googling “GraphQL”
- 27. 04 Conclusion
- 28. Key Takeaways for API testers (1) Knowledge of how to test web apps prepares you for most of API testing If you need some help, look at the OWASP Testing Guide (2) Some special knowledge and tools are needed for parts of API testing More on this later (3) Gaps in AppSec controls coverage and framework shortfalls lead to security shortfalls API testing is likely to be “productive”
- 29. Key Takeaways for API testers and defenders https://owasp.org/www-community/api_security_tools
- 30. Key Takeaways for API defenders The existing AppSec program and controls have API Security gaps to fill Risk Posture Runtime Testing Broken Object Level Authorization Broken User Authentication Excessive Data Exposure Lack of Resource & Rate Limiting Broken Function Level Authorization weak weak weak
- 31. Key Takeaways for API defenders The existing AppSec program and controls have API Security gaps to fill Risk Posture Runtime Testing Mass Assignment Security Misconfiguration Injection Improper Assets Management Insufficient Logging & Monitoring weak
- 32. Sorry about the firehose Black and Blue APIs Audience
- 33. CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon, infographics & images by Freepik THANKS! Do you have any questions? mattt@nonamesecurity.com nonamesecurity.com