Evasive Maneuvers

Description APIs in real-world scenarios are often protected by multiple security layers that make exploitation far more challenging like Web Application Firewalls (WAFs) and rate-limiting mechanisms designed to detect and block malicious activities For example, WAFs might flag behaviors such as: Excessive requests for non-existent resources. High request volumes over a short period. Attempts at common attack techniques like SQL injection or cross-site scripting (XSS). Unusual patterns, like unauthorized access tests. Evade API Security Controls String Terminators Null bytes and other combinations of symbols are often such as null bytes (%00), are a commonly exploited weakness that can disrupt the operation of input validation filters. These special characters can signal the backend system to stop processing inputs prematurely, potentially bypassing security measures like: %00 0x00 // ; % ! ? [] %5B%5D %09 , `%0a` , `%0b` , `%0c` , `%0e` strategically placing these terminators within a request, particularly in areas like the URL path or POST body, attackers may be able to bypass input validation filters. Consider this example: POST /api/v1/user/profile/update { "uname": "hapihacker", "pass": "%00'OR 1=1" } In this case, a null byte (%00) preceding an SQL injection ('OR 1=1) might bypass the backend’s input validation, allowing the malicious payload to be processed Case Switching Many APIs are case-sensitive, meaning that a change in the capitalization of letters within a request may bypass certain controls like WAFs POST /api/myProfile POST /api/MyProfile POST /aPi/MypRoFiLe Encoding Payloads URL encoding converts special characters into a form that can slip past some WAFs, which only decode requests once. Take the following SQL injection payload: Encoded Payload: %27%20%4f%52%20%31%3d%31%3b Decoded: ' OR 1=1; A well-configured WAF might recognize this as a SQL injection and block it. However, by using double encoding: Double Encoded Payload: %25%32%37%25%32%30%25%34%66%25%35%32%25%32%30%25%33%31%25%33%64%25%33%31%25%33%62 Decoded: %27%20%4f%52%20%31%3d%31%3b The WAF might miss this attack, allowing the payload to pass through and be decoded later on the server side, triggering the SQL injection

3-API_PenTesting · 2024-09-20

Injection Vulnerabilities

Description Fuzzing APIs: is the process of sending various types of input to an endpoint to provoke an unintended response The payloads used for fuzzing include [symbols, numbers, system commands, SQL queries, NoSQL queries, hexadecimal, boolean statements,…..] You should attempt fuzzing against all potential inputs and especially within the following: Headers Query string parameters Parameters in POST/PUT requests After sending your fuzzing requests, search for: Verbose error messages Failures in request handling Indications that your payload bypassed security controls (e.g., SQL syntax errors, delays, or verbose error dumps) SQL Injection Meta characters characters that SQL treats as functions rather than data: for example, -- is a metacharacter that tells the SQL interpreter to ignore the following input because it is a comment ' '' ;%00 -- -- - "" ; ' OR '1 ' OR 1 -- - " OR "" = " " OR 1 = 1 -- - ' OR '' = ' OR 1=1 If an API endpoint does not filter SQL syntax from API requests, any SQL queries passed to the database from the API will execute. SQL injection, allows a remote attacker to interact with the application’s backend SQL database. With this access, an attacker could obtain or delete sensitive data such as credit card numbers, usernames, passwords, and other gems If the API authentication process uses a query like this: SELECT * FROM userdb WHERE username = 'hAPI_hacker' AND password = 'Password1!'; The query retrieves the values hAPI_hacker and Password1! from the user input. If, instead of a password, we supply the API with the value ' OR 1=1-- -, the SQL query might look like this: SELECT * FROM userdb WHERE username = 'hAPI_hacker' OR 1=1-- -; This would be interpreted as selecting the user with a true statement and skipping the password requirement, as it has been commented out. The query no longer checks for a password at all, and the user is granted access NoSQL Injection APIs often use NoSQL databases, which scale well with modern architecture. NoSQL injection techniques are not as well-known as SQL injections, making them a more likely discovery. Each NoSQL database has its own structure and querying methods, so payloads will vary. Here are some common NoSQL metacharacters for fuzzing: $gt {"$gt":""} {"$gt":-1} $ne {"$ne":""} {"$ne":-1} $nin {"$nin":1} {"$nin":[1]} {"$where": "sleep(1000)"} For example, the $ne operator stands for not equal It is used to select documents where the value of a field does not match the specified value OS Command Injection In OS command injection, rather than database queries, you’re injecting operating system commands. You’ll need to find an injection point where commands can be executed. Key places to target include: URL query strings Request parameters Headers Common Command Separators { | , || , & , && , ' , " , ; } Common OS Commands for Injection: Windows -> { ipconfig , dir , ver , whoami } Linux -> { ifconfig , ls , pwd, whoami } Injecting these commands after a command separator could allow attackers to retrieve system information or run unauthorized commands —

3-API_PenTesting · 2024-09-10

Server Side Request Forgery

Description SSRF is a vulnerability that takes place when an application retrieves remote resources without validating user input. An attacker can supply their own input, in the form of a URL, to control the remote resources that are retrieved by the targeted server. SSRF IMPACT Attackers can provide URLs that may: Expose private data. Scan the target’s internal network. Potentially lead to remote code execution on the target. SSRF Types In-Band SSRF: The server responds with the resources specified by the attacker. Example: If an attacker sends a payload like http://google.com, the server would request the page and return the information from Google to the attacker. Scenario: A URL is specified in the request, and the content of the URL is displayed back to the attacker in the response. Intercepted Request: POST api/v1/store/products headers... { "inventory": "http://store.com/api/v3/inventory/item/12345" } Attack: POST api/v1/store/products headers... { "inventory": "http://localhost/secrets" } Response: HTTP/1.1 200 OK headers... { "secret_token": "crapi-admin" } Blind SSRF: The server makes the request, but does not send the response back to the attacker. The attacker has to rely on external services (like a web server) to confirm that the server made the request. Scenario: The server makes the request, but does not provide feedback to the attacker. Intercepted Request: POST api/v1/store/products headers... { "inventory": "http://store.com/api/v3/inventory/item/12345" } Attack: POST api/v1/store/products headers... { "inventory": "http://localhost/secrets" } Response: HTTP/1.1 200 OK headers... {} Challenge: There is no visible indication that the attack was successful. You would need to provide a URL to a web server under your control to track whether the server made the request. Solution: Tools like Burp Suite Collaborator can help by setting up a web server to capture request details. Free tools like http://webhook.site can be used to verify if the server makes a request to your specified URL. Ingredients for SSRF When targeting an API for SSRF vulnerabilities, you will want to look for requests that have any of the following: Include full URLs in the POST body or parameters Include URL paths (or partial URLs) in the POST body or parameters Headers that include URLs like Referer Allows for user input that may result in a server retrieving resources Mitigation Isolate the resource fetching mechanism in your network Input Validation and Whitelisting DNS Filtering ( DNS resolution restrictions to block access to private IP addresses ) Metadata Access Protection Authentication and Authorization for Internal Services

3-API_PenTesting · 2024-09-06

Mass Assignment

Description. Mass Assignment vulnerabilities occur when an attacker can overwrite object properties they should not have access to. For this to happen, three conditions must be met: The API accepts user input in its requests. The requests can alter values not visible or accessible to the user. There are missing security controls that prevent unauthorized changes to data objects. A classic example of mass assignment is during user registration, where an attacker can add additional parameters to a request, like "isadmin": "true", enabling them to escalate their privileges to an administrator. If the API does not sanitize these inputs, the attacker can exploit the vulnerability and register their own admin account. Finding Mass Assignment Vulnerabilities To discover these vulnerabilities: Examine API documentation for interesting parameters, especially those tied to user account properties, critical functions, or administrative actions. Add these parameters to requests and test if they can be manipulated. Understand the API’s designed usage by studying the parameters typically used. Knowing the parameter names and conventions will help identify opportunities for mass assignment in different requests. Fuzz parameter values Testing Account Registration for Mass Assignment Let’s intercept the account registration request for crAPI Submit the form to create an account and make sure the request was intercepted with Burp Suite Send the intercepted request to Repeater. Before submitting any attacks, send a successful request to have a baseline understanding of how the API responds to an expected request The simplest form of this attack is to upgrade an account to an administrator role "isadmin": true, "isadmin":"true", "admin": 1, "admin": true Any of these may cause the API to respond in a unique way indicating success or failure. Use Intruder for Further Testing Set the attack type to cluster bomb and add payloads for positions 1 and 2. Review results for any unique findings. Fuzzing for Mass Assignment with Param Miner after install extention Right-click on a request to mine parameters using Param Miner Navigate to Extender-Extensions, select Param Miner, and check the Output tab for results If any new parameters are detected, insert them back into the original request and fuzz for results Other Mass Assignment Vectors use mass assignment to gain unauthorized access to other organizations POST /api/v1/register --snip-- { "username":"hAPI_hacker", "email":"hapi@hacker.com", "org": "§CompanyA§", "password":"Password1!" } If you can assign yourself to other organizations, you will likely be able to gain unauthorized access to the other group’s resources —

3-API_PenTesting · 2024-09-04

Improper Assets Management

Description. Improper Asset Management involves discovering unsupported and non-production versions of an API. API providers often release newer versions with updated paths, such as: api.target.com/v3 /api/v2/accounts /api/v3/accounts /v2/accounts Versioning can also be managed through headers: Accept: version=2.0 Accept api-version=3 It might also be set within query parameters or request bodies: /api/accounts?ver=2 POST /api/accounts with {"ver":1.0, "user":"hapihacker"} Earlier API versions, which may no longer receive updates or patches, often expose additional vulnerabilities. For example, if v3 fixed an injection flaw, earlier versions like v1 or v2 could still be vulnerable. Non-Production API Versions Non-production versions of an API, such as test or beta environments, may not be secured like production versions. Examples include: api.test.target.com api.uat.target.com beta.api.com /api/private /api/partner Discovering these non-production versions can lead to testing for additional weaknesses Finding Improper Assets Management Vulnerabilities finding interesting parameters in API documentation and then adding those parameters to requests Look for parameters involved in user account properties, critical functions, and administrative actions guess parameters or fuzz them in API requests that accept user input /api/v3/id —> not work /api/v1/id —> work

3-API_PenTesting · 2024-09-03

Broken Function Level Authorization

Description Broken Function Level Authorization (BFLA) focuses on performing unauthorized actions rather than just accessing unauthorized resources, as seen in BOLA. It often involves requests that execute actions for other users, either at the same privilege level (lateral actions) or at an escalated role (e.g., administrative actions). Key Aspects of BFLA: Resource ID: Identifies a unique resource. Requests Performing Actions: Look for requests that update, delete, or alter other users’ resources. Missing/Flawed Access Controls: Exploiting BFLA requires the absence or misconfiguration of access When hunting for BFLA: Focus on functional requests that involve creating, updating, or deleting resources. API methods like POST, PUT, DELETE, and GET with parameters, especially in administrative functions. Testing Approach: For BFLA, we use A-B-A testing to verify the impact on another user’s resources: User A performs a valid action. switch out to our UserB token User B attempts to alter User A’s resources. User A verifies if the action was successful. Scenario we have a function for updating video name,this function require authorization to access resources belong to given user: In the captured request we can see that UserA’s video is specified by the resource ID “757”. now let’s use UserB’s token and attemp to update the video name we requested to update UserA's video, the server issued a successful response. However, the successful response indicated that UserB updated the name to the video identified as 758, UserB’s video. So, this request does not seem to be vulnerable. We should investigate other request methods that can be used for this request. Replacing PUT with DELETE -> This is an admin function. Try to access the admin API now we dealing with admin api.So, what if we try udating the requesr to Delete /identity/api/v2/admin/videos/758 Success! We have now discovered an admin path and we have exploited a BFLA weakness by deleting another user’s video —

3-API_PenTesting · 2024-09-02

Broken Object Level Authorization

Description. Broken Object Level Authorization (BOLA): security vulnerability that occurs when authorization controls are lacking or missing, UserA will be able to request UserB’s (along with many other) resources Key Aspects of BOLA: Resource ID: The resource identifier specifies a unique resource (e.g., number) Requests that access resources. you will need to know the requests that are necessary to obtain resources that your account should not be authorized to access. Missing or flawed access controls. Absence of proper access controls, allowing unauthorized access to resources Authorization Testing Strategy When searching for authorization vulnerabilities the most effective way to find authorization weaknesses is to create two accounts and perform A-B testing. The A-B testing process consists of: Create a UserA account. Use the API and discover requests that involve resource IDs as UserA. Document requests that include resource IDs and should require authorization. Create a UserB account. Obtaining a valid UserB token and attempt to access UserA’s resources Checklist —

3-API_PenTesting · 2024-09-01

API Recon

Description API Reconnaissance Directory and Subdomain Analysis Look for API indicators in directory names like ```bash /api, /api/v1, /v1, /v2, /v3, /rest, /swagger, /swagger.json, /doc, /docs, /graphql, /graphiql, /altair, /playground. ``` Subdomains like ```bash api.target-name.com, uat.target-name.com, dev.target-name.com, developer.target-name.com, test.target-name.com can indicate web APIs. ``` Monitor HTTP Responses for statements like `{"message": "Missing Authorization token"}`. Third-Party Sources Leverage third-party sources like GitHub, Postman Explore, ProgrammableWeb API Directory, APIs Guru, Public APIs GitHub Project, and RapidAPI Hub for information on APIs. Passive Reconnaissance Google Dorking Utilize Google Dorking with queries such as ```bash inurl:"/wp-json/wp/v2/users" and intitle:"index.of" intext:"api.txt" ``` to find publicly available API directories and key files. GitDorking Search for files like swagger.json using GitDorking, and employ tools like Trufflehog for additional security checks. Shodan Use Shodan queries like hostname:"targetname.com" and "content-type: application/json" to identify APIs based on domain and content type. The Wayback Machine Check for differences between the API documentation. Later, when you are actively testing the API, make sure to test using old endpoints Active Reconnaissance: process of interacting directly with the target Nmap Use Nmap for active API reconnaissance with commands like nmap -sC -sV ip nmap -p- ip -> allportscan Amass ```bash amass enum -active -d domain name sudo nano ~/.config/amass/config.ini` to add keys or secret to amass amass enum -active -d target-name.com |grep api 3. `Directory Brute-force with Gobuster` ```bash `gobuster dir -u http://targetname -w wordlist` `$ gobuster dir -u http://targetaddress/ -w /usr/share/wordlists/api_list/common_apis_160 -x 200,202,301 -b 302` DevTool navigate network and press Ctrl+r to refresh to get api end point or url to interact with url press right click on it and choose copy as Curl then open Postman then click on import choose raw text then import it Kiterunner (kr) tool available for discovering API endpoints and resources ```bash kr scan HTTP://127.0.0.1 -w ~/api/wordlists/data/kiterunner/routes-large.kite` kr brute -w ~/api/wordlists` ``` ---

3-API_PenTesting · 2024-07-30

Intro To APIs

Description API (Application Programming Interface) is a set of rules and protocols that allows one software application to interact with another. APIs define the methods and data formats that applications use to communicate with each other, enabling different systems to work together seamlessly. They abstract the complex implementation details, allowing developers to use predefined functions to interact with the software components. Types of APIs: REST (Representational State Transfer) API: Uses standard HTTP methods (GET, POST, PUT, DELETE). Stateless, meaning each request from a client contains all the information the server needs. Data is usually exchanged in JSON or XML format. Example: https://api.example.com/users SOAP (Simple Object Access Protocol) API: Uses XML for message format. Operates with higher complexity and strict standards. Supports more extensive security features and transaction management. Example: https://api.example.com/soap/userService GraphQL API: Allows clients to request exactly the data they need. Single endpoint to query multiple resources. Developed by Facebook for more efficient data retrieval. Example: https://api.example.com/graphql Example Example of an API: Imagine you have an online bookstore, and you want to allow developers to access book information from your database. API Endpoint: https://api.onlinebookstore.com/books HTTP Methods: GET: Retrieve book information. POST: Add a new book to the database. PUT: Update information about a book. DELETE: Remove a book from the database. Example Usage: GET Request To get information about a specific book, you might use the following endpoint: GET https://api.onlinebookstore.com/books/1 Response: ```json { “id”: 1, “title”: “The Great Gatsby”, “author”: “F. Scott Fitzgerald”, “published_year”: 1925 } POST Request To add a new book, you might send a POST request with the book’s information: POST https://api.onlinebookstore.com/books Request Body: { "title": "1984", "author": "George Orwell", "published_year": 1949 } Response: { "message": "Book added successfully", "book_id": 2 } Summary: APIs are essential tools in modern software development, allowing different software systems to communicate and work together efficiently. There are various types of APIs, each serving specific purposes, from web interactions to database management and hardware communication. Understanding how APIs function and their different types can greatly enhance a developer’s ability to build robust and scalable applications.

3-API_PenTesting · 2024-07-28

Mostafa Ashraf

Contact

3-API_PenTesting