Malicious code and abandoned websites are increasingly becoming more of a problem. It’s a serious issue in terms of privacy and security.
Website owners: Be careful when using third-party code that you don’t control.
Users: Hope for the best! Use a content blocker browser add-on like uBlock Origin. On your mobile device use Firefox with uBlock Origin.
What’s the problem?
Abandoned or unmaintained websites can be re-registered by malicious people. Any website using third-party code could be a victim.
To highlight the issue, let’s look at a specific example. This example luckily wasn’t extremely malicious. It could have been much worse! But it still highlights the current state of the web.
Image of malicious code:
The problem is this third party website stopped offering their free service. They notified users via their website and eventually the resources they used for counting Tweets were abandoned. This included the Amazon S3 bucket they used. Unfortunately many website owners didn’t get the notice, or ignored it.
Image of a website including the malicious code in their source code:
Update October 28, 2018: AWS will not confirm the S3 bucket was banned on their side. The malicious code could return at any time, and possibly be worse next time. According to AWS they need other people to alert them if the malicious content re-appears! From AWS: “Should you see the content return or similar appear, please report it immediately.”
Update November 9, 2018: From AWS: “Content in question is not currently accessible”.
Update January 14, 2019: From AWS: “We have again blocked the content.”
Who can fix this?
- Individual website(s) that include the third-party malicious code
- Hosting provider where the malicious code resides
- Web browser blocks malicious code
- Web browser add-on blocks malicious code
- You and me? Social media? News outlets?
Unfortunately it’s hard to get all 800+ websites to fix this on their sites. So ultimately we need the company hosting the malicious content to step in.
But why is this so hard? Just take down the malicious code!
What about the hosting provider?
At first they said this malicious script didn’t violate their terms of service! I had to read through their terms of service (TOS) and provided them with exact details of how this malicious script actually does violate their TOS.
Such a painful process!
- At the time of publishing this post, AWS has not confirmed they took the malicious script down due to a violation of the terms of service. So hopefully this malicious script won’t come back online in the future at the same location!
A browser add-on can also help
I had a feeling it was going to take the hosting provider a while to respond, since these things take time. As a work-around, a browser add-on to the rescue!
What about the browser itself?
The most recent version of Firefox 63 now has Tracking Protection. But this can only block entire domains and not specific files. So that can’t help in this case.
Directly in the Chrome browser? Not currently an option either.
You and me? Social media? News outlets?
Unfortunately that seems to be what it’s come to. More on that below.
Luckily this example wasn’t worse. The malicious code only redirected a mobile user to a scam website when they pressed their back button on one of the 800 affected websites. It could have been cryptocurrency mining malware, or code to exploit some bug in Android or iOS. Who knows, maybe the hosting provider would respond much faster if it was more serious? Or the website owners? Maybe.. Maybe not.
Solution for users
Unfortunately web users have little control over what a website is serving their browser. One thing that can help is using a content filter add-on for your browser like uBlock Origin for Firefox or for Chrome. In the above case the malicious code was only affecting mobile users. Only Firefox supports add-ons for their mobile browser. This is another reason to use Firefox on your mobile devices! In a related post, check out how easy it is to upgrade your privacy using Firefox.
Long term solution for website owners
Website owners need to be careful when adding third-party code to their websites. However, this is extremely difficult in today’s modern web. Often websites use many, many different third-party services.
One solution is to host all third party code locally on your web server. Unfortunately, this has it’s own issues since there would no longer updates to the code by the developer unless the website owner manually updates their site.
Another solution is to use Subresource Integrity (SRI). Unfortunately this can be tedious to implement for a website owner. And even worse, if you use a CMS like WordPress, you rely on the plugin developer to implement SRI into their plugin or theme. There is a WordPress plugin called (SRI) Manager which can help add SRI to all plugins, but your mileage may vary with getting it to work.
Conclusion – Who should fix this?
Who can fix this versus who should fix this is a good question. In my opinion, this should be the responsibility of the individual website. However, getting 800+ websites to fix this in a timely manner.. not going to happen (and it didn’t in this example!). As of the time of this post, most websites still include a link to the malicious code on their sites! Thankfully now it does nothing since it no longer exists.
It really needs to be easier for website owners to have secure third-party code on their website, otherwise we continue down this path.
Who needs to drive this change?
Specifically in the above example of “New Share Counts,” was it only a concerned internet user (myself) that made this happen?
Probably not, since it was in the news. That’s probably the only reason there was any traction. But regardless, I contacted an infected website (which I randomly found while surfing the net. Mind you, only one website of 800+), initiated an abuse case with the hosting provider (AWS) where the malicious code was, and lastly, initiated a support ticket for a work-around using a popular browser add-on.
Maybe other people also contacted the hosting provider. Maybe I should have contacted more content filtering browser add-ons? More pressure on social media? Or something else in addition?
Maybe more people need to take action against these issues after they happen.
The next question is, who should be driving this overall change to make it easier to secure third-party code on websites? That’s also a great question..
However, until that’s figured out we need individuals and news outlets to raise these issues when they happen.
For instance, open abuse reports with the hosting provider, try to inform the websites impacted, find work-arounds when it’s taking too long. Raise awareness on social media platforms.
Currently, that’s all we can do. That is, if the issue is even detected in the first place.
For anyone interested, here’s a timeline of events for the “New Share Counts” issue from what I observed. This isn’t meant to single out the hosting provider (AWS) in particular, they are probably flooded with abuse reports. But still, their generic responses are pretty funny. Bold used for emphasis.
2018/10/15 17:55 EST – Response from hosting provider: Generic response asking for logs.
2018/10/16 06:56 EST – Securi publishes article about malicious redirects from newsharecount.
2018/10/17 03:00 EST – BleepingComputer publishes article.
2018/10/17 18:33 EST – Reply to BleepingComputer’s tweet, including AWS twitter handle to highlight lack of response from AWS.
2018/10/17 18:39 EST – Hosting provider responded via email: “This case has been investigated and being resolved by the appropriate team.”
2018/10/17 19:15 EST – Submitted issue with uBlock Origin (browser add-on to filter content) via their Github issue tracker.
2018/10/18 03:48 EST – Hosting provider responds via twitter that they are investigating.
2018/10/19 09:41 EST – Hosting provider responded via email:
“We understand your concern regarding the continued availability of the content you have reported. As noted previously, AWS customers are responsible for their activity on AWS. As a courtesy we notified our customer of your request to have the content removed or access disabled, however, as we do not consider this content to be in violation of our terms, we are not able to take additional action. We strongly encourage you to continue to work with our customer directly to address the concerns that you may have.”
2018/10/19 10:12 EST – Replied to hosting provider via email:
“It’s unfortunate that this bad actor’s malicious script/bucket can’t be removed since it is clearly hijacking users mobile browsers to serve them ads/malware/malicious script. I suspect that notifying the current AWS customer which owns this bucket will have no result, since they are responsible for this malicious script in the first place.”
2018/10/19 10:29 EST – Hosting provider responded, via email, stating the same thing again and the case was closed:
“As noted previously, AWS customers are responsible for their activity on AWS. As a courtesy we notified our customer of your request to have the content removed or access disabled, however, as we do not consider this content to be in violation of our terms, we are not able to take additional action. We strongly encourage you to continue to work with our customer directly to address the concerns that you may have. This case has been resolved by the appropriate team.”
2018/10/19 19:08 EST – Hosting provider responded via email:
“Thank you for your reply. We are looking into this issue further and passed it on to our customer.”
2018/10/23 19:45 EST – Noticed http://newsharecounts.s3-us-west-2.amazonaws.com/nsc.js is down. Returning error: “Access Denied”.
2018/10/25 16:53 EST – Replied to hosting provider via email:
“Can you confirm this S3 bucket is now suspended and can’t be used again?”
2018/10/27 – No response from the hosting provider at time of this post.
2018/10/28 09:19 EST – Hosting provider responded, via email:
“At this time the content appears to be no longer active or available. If you have any evidence otherwise, please let us know.”
2018/10/28 09:27 EST – Replied to hosting provider via email, asking for confirmation the S3 bucket is suspended and if not, to do so.
2018/10/28 09:39 EST – Hosting provider responded, via email. Due to privacy policies they cannot discuss what actions have been taken, and:
“Should you see the content return or similar appear, please report it immediately.”
2018/10/31 17:42 EST – Replied to hosting provider via email. Malicious content is back online.
2018/11/06 11:05 EST – Hosting provider responded via email.
“We have begun our investigation into the source of the activity or content you reported.”
2018/11/09 04:28 EST – Hosting provider responded via email.
“Content in question is not currently accessible.. If you believe this content is still live, please provide additional evidence and we will be sure to investigate further. At this time please consider this case as resolved.”
2019/01/09 05:42 EST – Emailed hosting provider. Malicious content is live, again.
2019/01/14 08:55 EST – Hosting provider responded via email.
“Thank you for advising us that the content has been uploaded again. We have again blocked the content.”