XHR on 169.254 - is this a hack?

[PlainName]

Just noticed that when visiting imdb.com some javascript wants to do XHR stuff on 169.254.169.254. I haven't been able to find out if this is definitely a hack or a protection, and given it's IMDB I suspect the latter. But does anyone know? I've had a shufty at the write-only html without getting a clue (but then I'm not a web dev).

[ejeffrey]

It definitely shouldn't be doing that but my guess is it is some sort of fingerprinting / tracking tool. 

[PlainName]

Hmmm. I'm not clued up enough to know either way, but that kind of thing is now blocked globally just to be sure

Edit: this is the URL it's trying: https://169.254.169.254/latest/api/token

A google search on that turns up Amazon EC2 stuff, and the StackOverflow page Failed to get Amazon EC2 instance ID. Looks pukka  but hacks are also associated with it, so it's staying blocked.

[AndyBeez]

Subnet 169.254.x.x (169.254.0.0/16) is called a "link local" address and is allocated when there is no authoritative DHCP server on the client's network. For example, your PC will assign 169.254.x.x to itself if you plug your PC into another device that has a functional ethernet connection but, has no functional TCP/IP stack. You get the message, "no or limited internet connection."  Packets directed at link local addresses [should] never get routed.

Theory: The XHR target IP is crap JS code (that worked on their test LAN) that someone in a hurry copied verbatim and released without testing in the wild?

Or: Your browser/anti-virus is modifying the end point as to send traffic into a black hole?

[PlainName]

Perfectly suitable DHCP server, but the PC is fixed IP anyway. AV isn't doing anything, and browser only blocks it because I told umatrix/ublock to (which is how I noticed in the first place).

Interesting hypothesis about the developer copying what worked for them, but I really think they would have a pukka IP address else they wouldn't be connecting to much to develop anything! Also, it seems to be a common thing to do with EC2, although I haven't worked out if it should be:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html

Because your instance metadata is available from your running instance, you do not need to use the Amazon EC2 console or the AWS CLI. This can be helpful when you're writing scripts to run from your instance. For example, you can access the local IP address of your instance from instance metadata to manage a connection to an external application.

Instance metadata is divided into categories. For a description of each instance metadata category, see Instance metadata categories.

To view all categories of instance metadata from within a running instance, use the following IPv4 or IPv6 URIs.

IPv4

http://169.254.169.254/latest/meta-data/

[AndyBeez]

Interesting hypothesis about the developer copying what worked for them, but I really think they would have a pukka IP address else they wouldn't be connecting to much to develop anything! Also, it seems to be a common thing to do with EC2, although I haven't worked out if it should be:

First rule of programming, NEVER HARD CODE. Sorry for the drama, but this certainly suggests someone was eager to meet their key performance indicator for Friday lunchtime. Done it? Yep. Works? Yep. Tested? Yep. Really? Yep. Beer? Yep.

The AWS is interesting. We can deduce the developers are using a virtualisation codebase built on the secure Nitro platform. Unlike you, they didn't RTFM. "The IP addresses are link-local addresses and are valid only from the instance." RTFM? Yep. Another Beer? Yep.