To find EC2 instance userdata using the AWS CLI (Command Line Interface), you can utilize the describe-instance-attribute command along with specifying the --attribute userData parameter. Open your terminal or command prompt and type the following command, replacing instance-id with your actual EC2 instance ID: aws ec2 describe-instance-attribute --instance-id instance-id --attribute userData. This command returns the userdata in an encoded format.

You can also use the Userdata Decoder 3000 CLI which will decode everything but also output a copy of base64 encoded user data

Few reasons...

The primary reason is to support a cybersecurity talk I am working on.

Some other reasons are that I found a disconnect between what was being stored in user data and what shouldn't be stored in user data. I also found examples where the generation of the user data was via several different processes and it wasn't straightforward to see exactly what the end result was and what was being stored. This client-side tool is to support a presentation and also to signpost to the main tool which can iterate over all the servers in an AWS account and decode the user data. This could be done for debug, discovery, pen testing, or audit purposes.

Although you can only access instance metadata and user data from within the instance itself, the data is not protected by authentication or cryptographic methods. Anyone who has direct access to the instance, and potentially any software running on the instance, can view its metadata. Therefore, you should not store sensitive data, such as passwords or long-lived encryption keys, as user data.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

Small note, this documentation from AWS is a little in-accurate since you can use the CLI to get the userdata in encoded form which is the target for this client side tool and the CLI version. The main point of this warning is the fact user data is not stored encrypted and therefore should not be used to store sensitive information.

No, this is purely client-side code. It uses native tooling, pako, and js-yaml to decode, decompress, and deserialize the data and present it to you.

There is also no analytics library present either as it would take some time to ensure the contents of the input are not captured which at this time I am not sure how to implement.

Base64 Decoding

Primary Step: Since the user data is always base64 encoded, the first step is always to decode this layer.

Format Detection and Processing

Plain Text & Shell Scripts:If the decoded data is plain text or a recognizable shell script (often starting with #!/bin/bash or similar) no further deserialization is required.

Gzipped Content:To detect and decompress gzippedc content the first few bytes of the decoded data are checked for the gzip signature (1F 8B). If present, the dats is decompressed to retrieve the original content, which then may need to be further processed based on its format.

Multi-Part MIME Message: MIME-encoded userdata is used to pass multiple pieces of data or scripts. If a MIME header is detected, the content is parsed into its parts and handled each according to its MIME type. This may involve recursively applying the other steps mentioning here to each part.

Cloud-Init Directives:Cloud-init data might start with specific markers or be in YAML format. If cloud-init directives are detected each of the write files are extracted and stored using the file path relative to the output directory. A complete copy of the cloud-init config is also stored.