What is IMDS (Instance Metadata Service)?
In cloud environments, metadata services provide crucial information about the instances, such as configurations, settings, and credentials needed for applications. In Microsoft Azure, the Instance Metadata Service (IMDS) is a critical component that provides metadata about the virtual machines (VMs) running in the Azure environment.
Azure IMDS allows you to access information about VM instances, such as:
- VM size and type
- Subscription ID
- Resource group and region
- Network configuration
- Identity credentials (when using managed identities)
Access to IMDS is available through a specific endpoint: http://169.254.169.254/metadata/
. You can retrieve data by sending requests to the endpoint from within the VM.
While IMDS plays a crucial role in simplifying identity management in cloud instances, it also presents a potential attack vector when not adequately secured. One such vector is Server-Side Request Forgery (SSRF), which attackers can exploit to steal sensitive information, including credentials.
How SSRF Attacks Target IMDS
What is SSRF?
Server-side request Forgery (SSRF) is an attack in which the attacker manipulates server-side applications to make HTTP requests to unintended or malicious locations. Typically, this involves tricking a vulnerable application into fetching resources or data from internal services that shouldn’t be exposed, such as the metadata service.
In the context of Azure IMDS, an attacker might exploit SSRF to gain access to sensitive instance metadata, including managed identity tokens. These tokens can be used to authenticate against Azure services such as Azure Key Vault, Storage Accounts, or other resources, potentially compromising an organization’s cloud infrastructure.
Example SSRF Exploit on IMDS
- Vulnerable Web Application: Suppose a vulnerable web application is running inside an Azure VM. This application allows users to submit URLs, and the server fetches the content of those URLs without proper validation.
- Attacker Input: The attacker can submit a malicious request to access the IMDS endpoint, such as
http://169.254.169.254/metadata/identity/oauth2/token
, which retrieves managed identity tokens from IMDS. - Stealing the Token: By exploiting the SSRF vulnerability, the server fetches the token from IMDS, which is then passed back to the attacker. The attacker can now use this token to authenticate against other Azure services as the VM’s managed identity.
- Using the Token: The attacker can use the stolen token to access Azure resources, potentially leading to unauthorized access to sensitive data or services.
Real-world Exploit Example
An attacker could use the following request to fetch a token for a managed identity from IMDS (assuming the victim web server is vulnerable to SSRF):
GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2020-06-01&resource=https://vault.azure.net HTTP/1.1
Metadata: true
If successful, this request would return a token that grants access to the Azure Key Vault resource.
How to Protect Against SSRF in Azure IMDS
To safeguard your Azure environment from SSRF attacks targeting IMDS, consider implementing the following strategies:
1. Use IMDSv2
Azure now offers IMDSv2, which introduces additional security features to prevent unauthorized access to metadata. In IMDSv2, requests to the metadata service require a session token, making it harder for attackers to abuse SSRF vulnerabilities.
Here’s how it works:
- Before making any requests to IMDS, clients must request a token by sending a
PUT
request to the IMDS endpoint. - This token is then used in subsequent
GET
requests to fetch metadata, such as managed identity tokens.
This additional layer ensures that metadata is only accessible from legitimate, authenticated sources within the VM.
2. SSRF Mitigations in Web Applications
One of the most effective ways to prevent SSRF attacks is by properly validating and sanitizing user inputs in web applications. Here are the key steps:
- Input Whitelisting: Implement strict URL whitelisting to ensure the server can only fetch resources from trusted sources.
- Block Internal Requests: Configure your web application to block requests to internal IP ranges, including
169.254.169.254
, which is the IP address used by Azure IMDS. - Disable Unnecessary Functionality: If your application doesn’t need to fetch external resources, disable the functionality that processes URLs submitted by users.
3. Role-Based Access Control (RBAC) and Managed Identity Scope
Ensure that the managed identity assigned to your VMs is limited in scope and permissions using Role-Based Access Control (RBAC). Following the principle of least privilege, restrict the identity’s permissions so that the attacker’s access is minimal, even if a token is stolen.
4. Network Security Groups (NSG) and Firewalls
Consider using Network Security Groups (NSGs) and firewall rules to limit access to sensitive resources. For instance, you can configure NSGs to restrict outbound traffic from your VM to specific external addresses, preventing unauthorized communication with the metadata service or other internal services.
5. Monitor IMDS Access
Azure provides monitoring tools such as Azure Monitor and Azure Security Center to track unusual or suspicious access patterns to IMDS. Set up alerts to notify you if there’s an abnormal number of requests to the IMDS endpoint, which could indicate an SSRF attack.
6. Use Application Gateway with WAF
Deploy an Azure Application Gateway with a Web Application Firewall (WAF) before your application. WAF rules can help detect and block SSRF attempts, ensuring that malicious requests are intercepted before they reach the server.
Conclusion
While Azure IMDS simplifies identity and access management, it can also become an entry point for attackers if your applications are vulnerable to SSRF. You can protect your environment from these risks by adopting security best practices such as using IMDSv2, validating user inputs, and enforcing the principle of least privilege.
Take proactive steps to secure your applications and the infrastructure surrounding them, ensuring that your Azure VMs and the sensitive data they manage remain safe from attackers.