Malicious code and abandoned websites are increasingly becoming more of a problem. It’s a serious issue in terms of privacy and security.
TL;DR:
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.
Recently there was an issue where 800+ websites were using javascript from an abandoned free service called “New Share Counts” which counted the number of Twitter shares.
Image of malicious code:
Securi and BleepingComputer have great write-ups on the details.
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:
According the research from BleepingComputer, on October 3rd the AWS S3 bucket was cancelled and on October 4th a “bad actor” registered a new AWS S3 bucket under the same name. Up until October 23rd, all 800+ websites that didn’t remove this javascript file were serving all of their visitors with a malicious script which redirected mobile users to a scam website.
As of October 23, 2018: the malicious javascript (newsharecounts.s3-us-west-2.amazonaws.com/nsc.js) has been blocked on the AWS S3 bucket. It is returning the error: Access Denied
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 October 31, 2018: Malicious javascript is back online.
Update November 9, 2018: From AWS: “Content in question is not currently accessible”.
Update January 9, 2019: Malicious javascript is back online, again.
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.
It seems having this issue in the news and social media definitely helps put pressure on those who can take the malicious content down. In this case it was an Amazon S3 bucket hosting the malicious javascript.
But why is this so hard? Just take down the malicious code!
What about the hosting provider?
In this case, I submitted an abuse report to AWS the night of October 15th. It was only after Securi and BleepingComputer published news articles on October 16th/17th and some pressure on social media did AWS acknowledge the issue (to me at least). Then it took AWS over a week to take the resource down*. And that was only after countless back and forth emails with them. Thankfully, at least for now, the malicious javascript has been removed.
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!
uBlock Origin added this malicious javascript to their content filtering add-on 25 minutes after I opened an issue with them! Now that’s fast! So at least anyone using this popular browser add-on would be protected (well that is if they use Firefox on their mobile device, which actually isn’t the dominant browser).
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.
Timeline
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/14 23:13 EST – Randomly found issue on one specific website (Latest Hacking News) while surfing the net on my couch (on my phone) and informed them about malicious javascript on their site.
https://i.imgur.com/4E6uSx5.png
2018/10/15 17:19 EST – Emailed “Latest Hacking News” with more details. Including script where the malicious javascript is located.
2018/10/15 17:47 EST – Abuse report submitted to the hosting provider (AWS). ( where malicious javascript is hosted: newsharecounts.s3-us-west-2.amazonaws.com/nsc.js ). Gave details on what this malicious javascript is doing and how to reproduce malicious behaviour.
2018/10/15 17:55 EST – Response from hosting provider: Generic response asking for logs.
2018/10/15 18:04 EST – Replied to hosting provider: Gave info where they can find a site infected with the malicious javascript. Also, exact steps to reproduce malicious behaviour.
2018/10/16 06:56 EST – Securi publishes article about malicious redirects from newsharecount.
2018/10/16 11:06 EST – “Latest Hacking News” removed the malicious javascript from their website.
2018/10/17 03:00 EST – BleepingComputer publishes article.
2018/10/17 18:22 EST – Replied to hosting provider via email: No response from hosting provider (AWS) since 15th. Asked for abuse case to be expedited and if they can shutdown this AWS S3 bucket / javascript file. Also mentioned to AWS this was now in the news via Securi and BleepingComputer.
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/17 19:40 EST – uBlock Origin now blocks this malicious code. Only took 25 minutes! Anyone using the uBlock Origin browser addon (on mobile device) will not be affected by the malicious javascript.
2018/10/18 03:48 EST – Hosting provider responds via twitter that they are investigating.
2018/10/18 04:46 EST – “Latest Hacking News” responded via twitter, with thanks for finding the malicious javascript on their website.
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 18:26 EST – Replied to hosting provider via email. I read through all of their Terms of Service and found where this malicious javascript violated their terms in two places. Provided details about how this malicious javascript was breaking their TOS in those two places.
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 16:30 EST – “Abandoned Tweet Counter Hijacked With Malicious Script” Podcast from Security Now! about this issue. Episode #686 Audio & Video.
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/23 19:48 EST – Replied to hosting provider via twitter: Asking hosting provider to confirm they took down the javascript due to violation of their terms.
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.”