In order to hijack a web page and make it distribute malicious content, an attacker usually has to find a vulnerability in the respective web server or the employed scripts. As twitter user @Random_Robbie and Kevin Beaumont [1,4] noticed, sparking an online discussion, this cumbersome process is not always necessary!
This is not necessarily a security issue. But in this specific case the link was not simply broken but referenced a file in an Amazon S3-Bucket that had not been registered…. yet. All an attacker needs to do is simply register that bucket and deploy a script file that caters to his or her needs. This is an imminent threat and is not just limited to those who use Amazon S3. Likewise, the link might have referenced a yet unregistered domain, posing the exact same risk. Still, relying on S3 makes this a little more delicate. Even if the bucket already existed, chances are you might still be able to exchange content as buckets are commonly misconfigured and writable to the public as has been revealed within the last two weeks [2,3].
Although any kind of web space can be misconfigured, this case of publicly writable buckets is S3-specific. On the other hand, loading content from non-existing sources is obviously a risk in any scenario and not limited to Amazon. What is not obvious, though, is how and why such a scenario arises.
Possible explanations are manifold, ranging from human error to malicious intent. Either way, loading content from locations that one is not in control of is, in my humble opinion, a bad habit that unfortunately evolved to be common practice.