Introduction to EC2 instance metadata and risk prevention
Tags: aws, opensource, gpt3, devops
Published: 2023-07-09 15:40:47

## **Introduction**


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mtb30y4cxr3pctef3zfv.png)



Amazon EC2 Instance Metadata Service (IMDS) can help users obtain information about the instance itself. With IMDS, you can access various information about the instance, such as hostname, host IP, temporary access credentials, user data, and more. While this information is convenient for users, it also introduces new risks.

## **Risks**

A common attack scenario is when an instance has an SSRF vulnerability, attackers can retrieve information from the metadata. If temporary access credentials exist in the metadata, attackers can use these credentials for lateral attacks.

!https://superblog.supercdn.cloud/site_cuid_cldhcpt7a1506291jkdhe6vl2sc/images/untitled-11-1688916597258-compressed.png

Furthermore, if sensitive information is present in user data, attackers can retrieve this data through the metadata, resulting in information leakage and facilitating the next steps of attack and exploitation by the attackers.

## **Risk Detection**

### **Manual Assessment**

There are three main ways to assess the risks:

1. Access http://169.254.169.254/latest/meta-data/ within the instance to check if the returned result is normal. If it is, it indicates that the instance's metadata is enabled and accessible without authorization.
2. In the instance's Action → Instance settings → Modify instance metadata options, if the Instance metadata service is in an "Enable" state and IMDSv2 is in an "Optional" state, it means the metadata is at risk.
3. You can also use the AWS CLI to obtain the current instance's state:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7hzf000y9f8c77wgki6p.png)
F!


```
aws ec2 describe-instances --instance-ids <instance_id> --query 'Reservations[*].Instances[*].MetadataOptions'

```

If the HttpTokens in the returned content is "optional," it indicates that the metadata service of the current instance is at risk.

```
[
    [
        {
            "State": "applied",
            "HttpTokens": "optional",
            "HttpPutResponseHopLimit": 1,
            "HttpEndpoint": "enabled",
            "HttpProtocolIpv6": "disabled",
            "InstanceMetadataTagsF!": "disabled"
        }
    ]
]

```

### **Using Selefra for Assessment**

Manual discovery of these issues can be time-consuming and cannot be done in bulk. Using Selefra can help you quickly identify these risks. Selefra is a tool for rapidly discovering multi-cloud and SaaS risks. The Selefra project can be found at [github.com/selefra/selefra](https://github.com/selefra/selefra).

Let's start by installing Selefra:

```
brew tap selefra/tap
brew install selefra/tap/selefra
```

Next, create a project folder:

```
mkdir selefra-test
cd selefra-test

```

Copy the following YAML file to this folder:

```
selefra:
    name: selefra-test
    connection:
      type: postgres
      username: your_username
      password: your_password
      host: 127.0.0.1
      port: 5432
      database: postgres
      sslmode: disable
    log_level: info
    providers:
        - name: aws
          source: aws
          version: v0.1.0
providers:
    - name: aws
      provider: aws
      cache: 7d
rules:
  - name: ec2_metadata_unlimited_access
    metadata:
      title: EC2 metadata unlimited access
      severity: High
    query: |-
      SELECT
				*
			FROM
				aws_ec2_instances
			WHERE
				metadata_options ->> 'HttpTokens' = 'optional';
    output: "EC2 metadata unlimited access, arn: { {.arn} }"

```

As you can see, it is divided into three modules: selefra, provider, and rules.

In the selefra module, configure your own PostgreSQL database connection address, username, and password in the connection block. The cache block in the provider module can set the cache time for fetching data. The rules module is for configuring the detection issues. The title block represents the title of the detection strategy, and the SQL statement in the query block is used to execute the detection strategy by querying the vulnerable resources in the database.

Before starting the detection, configure your AWS credentials by running the following command:

```
aws configure

```

Then run the following command to run Selefra:

```
selefra apply

```

Now Selefra will start the detection process. Below is an example of the result:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uagtow25llu7s7s2rbyx.png)



In the result, we can see that there are 3 instances with metadata risks.

In addition to the above method, Selefra also integrates GPT functionality. This feature allows you to discover risk points by directly querying Selefra.

### **Using Selefra GPT for Assessment**

Similar to the previous steps, create a new folder and copy the following YAML file into it:

```
selefra:
    name: selefra-test
    connection:
      type: postgres
      username: yourusername
      password: yourpassword
      host: 127.0.0.1
      port: 5432
      database: postgres
      sslmode: disable
    log_level: info
		openai_api_key: your_openai_api_key
    openai_mode: gpt-4
    openai_limit: 10
    providers:
        - name: aws
          source: aws
          version: v0.1.0
providers:
    - name: aws
      provider: aws
      cache: 30d
rules:

```

The difference here is that you need to provide your own OpenAI API Key. You can also set whether to use GPT-4 or GPT-3.5 in the openai_mode. Furthermore, leave the rules block empty, as AI will generate the content for this section.

Before starting the detection, configure your AWS credentials as before. Then you can use the GPT functionality:

```
selefra gpt "Query instances with unrestricted access to metadata."

```

**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ie7b4edyj8xm5340ar25.png)

**

As you can see, with just a single sentence, you can discover instances where the metadata service is at risk. It's very convenient.

**Prevention**

To mitigate the risks associated with the AWS EC2 Instance Metadata Service, there are two main methods. First, if you don't need metadata, you can disable it directly. Second, if you need to use the metadata service, you can enable token-based access to prevent direct access to metadata.

To disable the metadata service, there are three common methods:

1.Disable metadata during instance creation.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/naqd5nv725rlgy5zstsl.png)



2.After creating the instance, go to the console's Action → Instance settings → Modify instance metadata options and disable it.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/feym5q95e7gumug8vq7b.png)



After creating the instance, you can also use AWS CLI to disable it:

```
aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-endpoint disabled
```

To enable token-based access, there are also three common methods:

1.During instance creation, select "V2 only" in the Metadata version.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jsyzurkms2qus7tkj5u0.png)



2.After creating the instance, go to the console's Action → Instance settings → Modify instance metadata options, and check "Required" for IMDSv2.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/37hp72phumy8lq11uoq0.png)



After creating the instance, you can also use the command line to modify it:

```
aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-tokens required

```

## **Conclusion**

In this article, we introduced the risks associated with metadata and how to mitigate these risks. By using Selefra, you can quickly and efficiently identify instances that have metadata risks. We hope this article has been helpful to you and that Selefra can make your cloud environment more secure.

GitHub: https://github.com/selefra/selefra

Slack: https://selefra.io/community/join

**Recommended reading**

[How to spot and fix issues with publicly accessible AWS S3 buckets](https://www.selefra.io/blog/how-to-spot-and-fix-issues-with-publicly-accessible-aws-s3-buckets-cljl5t7ng11971413tqwzdeuzfvm)

[Why Choose PGSQL as the Database for Resource Storage](https://www.selefra.io/blog/why-choose-pgsql-as-the-database-for-resource-storage-cljv8ln4a738313tp9502hzi9q)