Conference notes: API Security 101 (LevelUp 0x03 / 2019)

Hi, these are the notes I took while watching the “API Security 101” talk given by Andy Sadako on LevelUp 0x03 / 2019.

Links #

• Video

About #

This talk covers the basics of API security testing for hackers.

Overview of API attack vectors #

Common API security issues #

• API bugs are a common source of breaches mentioned in news
• Typically fall under these categories:
  • Access controls
    • Authorization
    • Authentication
  • Rate limiting
  • Input validation
  • Restricting HTTP methods
  • 3rd party API abuse
  • Other app logic errors

Access controls #

• Authentication = proving you are who you say you are (admin, guest, dev…)
• Authorization = granting access to resources you requested based on your identity

Pattern often followed by access control schemes #

• Client makes a request to something that requires authentication
• Server processes auth request, checks for things like:
  • If an account/session exists
  • If the requested resource is within access scope of the client
  • If any previous cookies or tokens were used in the request
  • If the route to the resource was valid
  • If any other conditions the server expects have been met
• If successful, server returns a token, session id, or other identifier to mark the session
• Further authenticated requests will follow a similar pattern throughout the session

Common ways to test for access control bugs #

• Enumerate potentially restricted endpoints ( Internal API endpoints, anything in the admin/dev/test scope)
• Modify session tokens (or putting junk data in them)
• Reuse older session tokens
• Attempt to bypass restrictions on access with IDOR
• Modify the request with additional parameters like &admin=True or &test=1
• Modify referrer headers that the app may expect: (i.e. spoof referer headers to make the app think you came from another part of the app)

Example of access control bug: Panera bread #

• Exposed API endpoint => complete access to client information (credit cards, usernames, email addresses…)
• Sequential numbering of client records => easy enumeration of the entire user database
• => tens of millions of client records leaked
• Source

Input validation #

• Important attack vector for bug hunters
• Input is anything that the server takes in (from the user, 3rd party apps or other internal mechanisms)

Common places to test in an API #

• Within the request header
• Parameter within the URL
• Parameters within the requst
• File uploads (PUT/DELETE requests)
• Different request methods

Input validation bugs #

Depending on the app’s architecture, specific parts of a request may be processed in unsafe ways (applies to any web app whether it’s an API or older app) including:

• Improper parameterization of requests within app logic
  • Are they just concatenating variables and input together and treating all input as trusted?
• Lack of input sanitization / escaping unsafe characters
• Improper handling of parameters
• Insufficient controls for data types passed (File upload bugs, Unicode bugs)
  • Can you pass a PDF, a ZIP file or Unicode? And is that properly handled?

Example of input validation bug: German eID System #

• Germany has an eID system for people to use their real-life identity online
• Requests to the German eID System required to be signed to be valid
• The app didn’t account for the same parameter occurring multiple times:

• If an attacker supplies multiple parameters named SAMLResponse, the signature is verified against the last occurrence of the parameter, while the SAML response that is processed further, will be taken from the first occurrence

• E.g.: &user=Andy&user=Sam => &user=Sam is used for signature but after that the app uses the first parameter &user=Andy
• => Attackers could change their identity entirely within the system
• Source & Video PoC

Fuzzing #

• Things you can fuzz for:
  • RCE (Remode Code Execution)
  • XSS
  • LFI/RFI
  • SQL/NoSQL injection
  • Request splitting
  • Deserialization
  • XXE & other templated language fun
  • Encoding errors with Junl characters, control character, emoji, Unicode points that don’t have any data associated with them (another thing that apps sometimes forget to include processing for), etc
  • File upload vulnerabilities
  • SSRF
• Tools you can use
  • Burp
  • Enumeration tools (Gobuster, Dirb…) and wordlists (Seclists & Github Awesome lists of fuzzing payloads and app parameters)
  • Custom scripts
• Protip: Speed up your fuzzing by making HEAD requests to API endpoints

Rate limiting #

• Doesn’t get as much attention as it should
• APIs are built to expect a high load and large amount of arbitrary requests
• This functionality of APIs can be abused to quickly enumerate an endpoint in unintentional ways

Common ways to test Rate limiting #

• Make a bunch of requests and see what happens: Check response headers to see if you get back any responses that are rate limiting tokens
• Make requests in varying states of authentication (because sometimes you’re only rate limited if you are at a certain access level):
  • as an unauthenticated user
  • as an authenticated user
  • as a developer
  • as a bot
  • with a deactivated account
  • with bogus credentials
• => an API with improperly implemented rate limiting can be used to make an abnormal amount of requests to enumerate the app & potentially cause other issues like DoS

Restricting HTTP methods #

• APIs are built to support a lot of different HTTP methods for different purposes (like inserting client records and modifying things with PUT & DELETE requests)
• Important to do when fuzzing an API: Determine what the app expects & what it supports
  • Some of these methods can be accessed unauthenticated & sometimes the scope of specific methods is too broad
  • => user is able to PUT, DELETE, POST, etc parts of the API that it shouldn’t
  • Basically you would be able to find undocumented features of the API with this
  • So it’s good to look at the API spec/documentation, see which methods are requested & compare them to which ones are actually allowed based on what the server tells you
• Even if these HTTP methods aren’t included in the app logic, if an app is lazy with this & has no logic to parse, weird things can happen

3rd party API abuse #

• Sometimes APIs call other APIs to achieve their goal
• The relationship between the target API & any 3rd party APIs in use is usually trusted in some way
• => Because there is an implicit trust between different APIs, in certain scenarios, either can be leveraged to access privileged resources

Common attack vectors #

• Request splitting: Making additional requests to 3rd party API through the target API
• SSRF: APIs that can resolve URLs can be tricked into making requests in the context of the server itself. Can lead to enumeration of private internal network, or gaining access to server metadata in a cloud environment
• Unhandled input from 3rd party: Can result in unexpected errors in the target app
  • Sometimes you might make a request to your 3rd party API that gives back data that was unexpected and causes unexpected outcomes withing the target API you’re testing

Examples #

Discord bug #

Concepts #

• Requests to the Discord API were rate limited only if authenticated
• The invite scheme for Direct Messages was the same as those for server invites. DM invite codes are only used internally and assume that a user is already authorized to be in a group DM if an invite is used
• 2 types of invite codes: invites for one-time use & invites that doesn’t expire
• Invite codes are 6 characters for temporary invite codes
• Two APIs available to test (old & new one)
  • Always ask yourself: Is there more than one API? (dev API, deprecated API that’s still available…)

Methodology #

• He wrote a script to enumerate invites
• Made requests to the API to see if an invite code was valid
• Sped up brute-forcing by making HEAD requests & reading if response was 200
• Made around 100 requests per second. Found about 1 valid invite per minute.
• Randomly generated invites rather than brute-forcing the entire keyspace
• Found that generated codes are used as seeds for future codes
• Enumerated temporary invites only, 6 characters

Example request #

Impact #

• Able to join private servers
• Able to join private group DMs

Duda Mobile bug #

Concepts #

• The Duda Mobile website templating service takes existing websites & turn them into mobile-friendly templates
• It has an API built in to process external links that are loaded & converted into a mobile safe format. It strips JavaScript & CSS and attempts to load the website into a preset theme
• Andy was able to get past filtering mechanisms to bypass JavaScript filtering (with onload directive & image tags)
• He could use a mobile site’s rendering API to load 3rd party APIs within the context of any website on their platform
  • I.e. it was possible to load arbitrary URLs into the template of the website
• This allowed for SSRF attacks made on Duda’s infrastructure: mobile.dudasite.com/site/<sitename>/default?url=<externalUrl>

Impact #

• Led to disclosure of private AWS keys & sensitive information in the production AWS account for the entire enterprise through SSRF
• Also able to load & potentially modify internal router configs by accessing internal IPs

Follow up #

Andy’s email address: blackhat[at]zipcar[dot]com.

Questions #

• Q: Is there any additional resources for reading about API hacking?
• A: OWASP, Google “API hacking”, random blog posts

See you next time!