So What’s “169.254”, “169.254”?

So What’s “169.254”, “169.254”?

It is not often that an IP address appears within the posting of a data breach, but 169.254.169.254 is being pinpointed as a potential source of the Capital One data breach. Anyone who knows anything about IP addresses, knows that the address of 169.254.169.0/24 is a link-local address and only available to a local host. Within AWS and Azure, we use the address to gain access to the metadata associated with a VM (using an Instance Metadata Service). Unfortunately we access it using the horrible “HTTP” protocol, and which often lacks any real checking of the user and their rights to the metadata.

The other thing that has been pin-pointed as a possible source of the breach is Amazon’s IAM (Identity and Access Management) [here] role:

Basically the IAM role should have a large “Danger! Danger!” warning on them, and they are basically are used to create a limit-scope role which can read AWS S3 objects, but cannot write to them. These S3 objects are basically data buckets where objects — often files — are stored.

The Instance Metadata Service (IMS) provides information about the metadata on instances that are running and is accessed through the non-routable IP address. It can also be used to reconfigure instances. This includes information on network configuration, maintenance events, and so on:

An example to examine the AMI-ID (Amazon Machine Instance ID) is:

curl http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890

Unfortunately, the IAM role is often published with EC2 instances, where where the IAM role credentials from these instances can be gained from http://169.254.169.254/ (the EC2 meta service). This gives rise to any process on the network being able to contact the EC2 meta service and get the AWS keys for the IAM role. Once gained it is possible to read all the objects within S3 data buckets.

So, watch out for those IAM roles!