What are API Subdomains?
Subdomains of a website or web application that are reserved especially for hosting APIs (Application Programming Interfaces) are known as API subdomains. These subdomains are used to provide access to various functionalities and data through standardized interfaces, allowing developers to interact with the system programmatically.
A Simple Example
Suppose you have an online application that offers a wide range of features or services, such as a user profile, product listings, and a review system for a shopping website. You now want to design a custom interface that will allow other web applications (such as mobile apps or other websites) to communicate with these various sections of your website.
API subdomains function as distinct entry points into various sections of your application. You have different doors leading to different areas of your site rather than using the main entrance. For example:
You use the “products.example.com” door to view the products.
You use the “profiles.example.com” door to view user profiles.
You use the “reviews.example.com” door to read reviews.
A subdomain, or door, points to a distinct area of your website, and software can use these doors to connect to the exact area they require. It helps you stay organized and ensures that all the information and requests needed are sent to each section of your application.
As a result, API subdomains facilitate the separation and organization of the various programming interface functions on your website, which in turn facilitates their use and interaction with other applications
>> Discover & Test your Ransomware Attack Surface
Common Use Cases for API Subdomains
API subdomains are a versatile tool for managing, organizing, and distinguishing an API’s functionality. Here are some different ways API subdomains are commonly used:
- Versioning: Subdomains are used to identify various API versions.
For example:
v1.api.example.com for version 1 of the API.v2.api.example.com for version 2 of the API.
This enables developers to make changes while maintaining backward compatibility and using the version of the API that best meets their needs.
It could be helpful for hackers to locate these versions. For instance, if the application is using version 2 of the API, but version 1 is still accessible, and the developer chose to use version 2 of the API because of a vulnerability in version 1 of the API, then the attacker can use version 1 of the API to carry out malicious activities.
For example, if version 1 of the API is vulnerable and does not have appropriate access controls, allowing any user to view any user’s details by just changing the user ID, but version 2 addresses this problem, an attacker can take advantage of the vulnerability in version 1 to compromise the application. This vulnerability is called Broken Object Level Authorization Using Old API.
- Segmenting Services: Within an API ecosystem, subdomains can stand in for various services or microservices. For instance:
- For product-related endpoints, use products.api.example.com.Users.api.example.com refers to endpoints related to users.
- For payment processing endpoints, use payments.api.example.com. This facilitates independent service scaling, access management, and code organization.
- Access Control: Subdomains can be used to control access to specific parts of the API based on user roles or permissions. For example:
admin.api.example.com is the address for administrator-only administrative functions.
For publicly accessible endpoints, use public.api.example.com. This improves security by guaranteeing that only people with permission can enter certain areas.
An attacker may be able to take advantage of an API that is only accessible by administrators but has lax access controls or default passwords.
- Insufficient Authentication: Attackers may try to get around the API subdomain’s authentication mechanism by employing strategies like brute force attacks, password spraying, or session fixation if it is weak or poorly implemented.
- Insufficient Authorization Checks: An attacker may attempt to circumvent the authorization checks even in the absence of legitimate credentials. To increase their privileges, they might tamper with cookies, tokens, or session data.
- Privilege Escalation: Attackers might try to take advantage of holes in the system that let them increase their level of privilege within the program. For instance, if role-based access control (RBAC) is used by the API subdomain, they might try to change their role in order to access admin features.
- Load Balancing: You can use subdomains to split up API traffic among several servers or data centers. For example:
For a single server, use api1.example.com.
For an additional server, use api2.example.com. Inbound requests are routed to the correct subdomain by load balancers based on variables such as traffic volume and server health.
- Content Delivery: Subdomains are useful for serving various media or content kinds. For instance:
Images are served via images.api.example.com.
Videos are served via videos.api.example.com. Performance is enhanced and content delivery is optimized as a result.
- Testing and Development: Subdomains can be utilized for development and testing. For example:
To test new features, use test.api.example.com.
For debugging and development, use dev.api.example.com. This keeps the production environment unaffected while developers work on new features.
- External Integrations: Subdomains can be used to set up distinct endpoints for partner services or third-party integrations. For instance:
For partner-specific API endpoints, visit partners.api.example.com.
Use external.api.example.com to link your application with outside services. Integrations are kept manageable and separate as a result.
The specific requirements of the API, its architecture, and the organization’s needs for organization, security, and scalability all influence how API subdomains should be used.
-> [Request Demo] - Get the Hacker’s View Of Your Attack Surface
Why enumerate API Subdomains?
An attacker may be able to take advantage of API subdomain enumeration by revealing the subdomains connected to an API. Here are some vulnerabilities that can arise:
- Information Disclosure: Sensitive information about the API infrastructure, such as subdomains, endpoints, or versioning information, may become visible during the enumeration process. Attackers can use this information to comprehend the architecture of the system and find possible weak points or avenues of attack.
- Attack Surface Discovery: Attackers can obtain knowledge about the different entry points and functionalities provided by the API by identifying API subdomains. Their ability to map the attack surface and plan focused attacks against particular API endpoints or functionalities is aided by this.
- Brute-Force Attacks: Attackers may try to guess or brute-force API endpoint URLs after the subdomains have been enumerated in order to gain access to resources that are restricted or carry out illegal activities. Data breaches, unauthorized data manipulation, or even a total system compromise may result from this.
- API Misconfiguration: A misconfigured API subdomain with too many permissions, shoddy authentication, or insufficient rate limiting may also be found through enumeration. These configuration errors provide opportunities for unauthorized access, privilege escalation, and denial-of-service attacks.
In order to address these vulnerabilities, it is imperative to put in place appropriate security measures, including robust access controls, secure authentication protocols, input validation, and API activity monitoring and logging.
How to perform API subdomain enumeration?
An automated process is usually used in conjunction with manual methods to accomplish API subdomain enumeration. Here are some common steps to perform API subdomain enumeration:
Passive Reconnaissance: To begin, learn as much as you can about the intended website or web application. Search engines, public databases, and OSINT (Open-Source Intelligence) platforms are some examples of tools that can be used to locate publicly accessible subdomains linked to the API.
DNS Enumeration: Find subdomains by using DNS (Domain Name System) enumeration techniques. Sublist3r, amass, and dnsrecon are a few examples of useful tools for this process. These tools use a variety of methods to find subdomains, including zone transfers, brute-forcing, reverse DNS lookups, and search engines.
Certificate Transparency Logs: Look through the Certificate Transparency logs, which offer an accessible list of all SSL/TLS certificates that have been issued. Subdomains linked to issued certificates can be found with the aid of programs like certspotter and crt.sh.
Web Crawler: To find possible API subdomains, use a web crawler or a program like gobuster to scan the main website. Look for references or links to subdomains that are meant to host APIs only.
Brute-Force: Tools such as ffuf and wfuzz can be used for brute-forcing in order to guess and identify additional subdomains if there are indications of a pattern in subdomain naming conventions.
We will look at both active and passive methods of using amass for API subdomain enumeration in this blog.
-> (Request Demo) 10 X Pen Testing Frequency & 100% Asset Coverage
API Subdomain Enumeration Using Amass
Tool: Amass
Command: amass enum -d twitter.com | grep api
This command will enumerate subdomains for twitter.com and filter the subdomains that contain the term “api”.
You can also perform passive subdomain enumeration by using -passive in the amass command like this
amass enum -passive -d twitter.com | grep api
When using the “passive” command in Amass, it leverages various publicly available sources, such as search engines, OSINT platforms, and public databases, to gather information about subdomains associated with the target domain. This information is obtained passively, meaning it does not involve actively sending requests or performing scans directly to the target domain.
You can filter the live subdomains by using httpx like so:
amass enum -active -brute -w /usr/share/seclists/Discovery/DNS/Subdomain-wordlist.txt -d twitter.com | httpx -mc 200
Brute forcing Subdomains
Command:
amass enum -active -brute -w /usr/share/seclists/Discovery/DNS/Subdomain-wordlist.txt -d twitter.com
The above command will brute-force subdomains.
The -active command in Amass refers to an active reconnaissance method used for subdomain enumeration. When using this command, Amass actively sends DNS queries to discover subdomains associated with the target domain.
-> Hackers Won't Wait For Your Next Pen Test: Know Automated Continuous Pen Test
Conclusion:
Security researchers may find subdomains that have been abandoned or are no longer in use by using API subdomain enumeration. Subdomain takeover attacks, which can result in total control or unauthorized access to the impacted systems, may target these abandoned subdomains.
By: Firecompass Research Team – Vishal Vishwakarma
About FireCompass:
FireCompass is a SaaS platform for Continuous Automated Pen Testing, Red Teaming and External Attack Surface Management (EASM). FireCompass continuously indexes and monitors the deep, dark and surface webs using nation-state grade reconnaissance techniques. The platform automatically discovers an organization’s digital attack surface and launches multi-stage safe attacks, mimicking a real attacker, to help identify breach and attack paths that are otherwise missed out by conventional tools.
Feel free to get in touch with us to get a better view of your attack surface.
Important Resources:
