they include The City University of New York (cuny.edu), Uncle Sam's court information portal (uscourts.gov), Lund University (lu.se), the UK's Student Loans Company (slc.co.uk), privacy watchdog The Information Commissioner's Office (ico.org.uk) and the Financial Ombudsman Service (financial-ombudsman.org.uk), plus a shedload of other .gov.uk and .gov.au sites, UK NHS services, and other organizations across the globe.They were all running Coinhive's Monero miner in visitors' browsers. How and why did this happen and what should these sites have been doing to prevent it? Follow me below the fold.
Manchester.gov.uk, NHSinform.scot, agriculture.gov.ie, Croydon.gov.uk, ouh.nhs.uk, legislation.qld.gov.au, the list goes on.
 |
| Some resources for a page |
In an age in which every browser gifts a free-to-use, unlimited-usage, fast VM to every visited web site, and these VMs can boot and run quite responsive 3D games or Linux distributionsYou (and I) need to be very careful about gifting these VMs to sites we don't trust, which is why I use NoScript. The resources Talking Points Memo wants me to execute are not delivering me information I want. A few of them want to show me ads, probably for things I just purchased and so will definitely not purchase again. Most of them want to track me. Back in 2015 Georgis Kontaxis and Monica Chew won "Best Paper" at the Web 2.0 Security and Privacy workshop for Tracking Protection in Firefox for Privacy and Performance (PDF). They demonstrated that Tracking Protection provided:
a 67.5% reduction in the number of HTTP cookies set during a crawl of the Alexa top 200 news sites. [and] a 44% median reduction in page load time and 39% reduction in data usage in the Alexa top 200 news site.Some of them would likely have been malvertising, using the incredibly complex and opaque advertising ecosystem as an efficient channel for distributing malware. But increasingly, as in this case, some of them would be cryptojacking, mining cryptocurrency in your browser. It turns out that, although the return from an individual browser is small, as Brannon Dorsey demonstrated it is easy to collect vast amounts of computing resource by advertising:
Anyone can make an account, create an ad with god-knows-what Javascript in it, then pay to have the network serve that ad up to thousands of browser.But the ads aren't the only remote resources in the typical page. The language of Web pages used to be HTML, now it is JavaScript. JavaScript is a programming language. People who write programs use libraries, so the typical page loads JavaScript libraries. Libraries are programs. Programs have bugs. As Thomas Claiburn at The Register explained last March, this means the JavaScript libraries your browser is executing have bugs:
So that's what Dorsey did -- very successfully. Within about three hours, his code (experimental, not malicious, apart from surreptitiously chewing up processing resources) was running on 117,852 web browsers, on 30,234 unique IP addresses. Adtech, it turns out, is a superb vector for injecting malware around the planet.
Some other fun details: Dorsey found that when people loaded his ad, they left the tab open an average of 15 minutes. That gave him huge amounts of compute time -- 327 full days, in fact, for about $15 in ad purchase.
The web has a security problem: code libraries. Almost 88 per cent of the top 75,000 websites and 47 per cent of .com websites rely on at least one vulnerable JavaScript library.Dan Goodin at Ars Technica understands the real significance of this incident:
As described in a recently published paper, "Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web," researchers from Northeastern University in Boston, Massachusetts, have found that many websites rely widely on insecure versions of JavaScript libraries and that there's no immediate way to eliminate this problem.
If someone can control the JavaScript that the US court system and thousands of other organizations load into their webpages, they can potentially exploit critical browser flaws, steal log-in credentials, and perform other malicious acts. As offensive as drive-by mining is, it's one of the more benign offenses that can result from malicious code that gets executed on our devices.Chris Williams at The Register explains what happened to the 4,275+ Web sites:
The affected sites all use a fairly popular plugin called Browsealoud, made by Brit biz Texthelp, which reads out webpages for blind or partially sighted people.Plugin, library, same difference. They're both code from some place else that the page invokes. On Twitter, Prof. Alan Woodward points out what sites should have been doing to prevent this:
This technology was compromised in some way – either by hackers or rogue insiders altering Browsealoud's source code – to silently inject Coinhive's Monero miner into every webpage offering Browsealoud.
This is what happens when you use third party content & don’t ensure its integrity. Just look at all those public sector sites affected. If you wanna know how to stop it read these:Prof. Woodward and security researcher Scott Helme are suggesting sites need to do three things:
https://scotthelme.co.uk/subresource-integrity/ …
https://scotthelme.co.uk/content-security-policy-an-introduction/ …
And use @reporturi
- Use SubResource Integrity (SRI).
- Use Content Security Policy (CSP)
- Use Reporturi.
A CSP header allows you to define approved sources for content on your site that the browser can load. By specifying only those sources that you wish the browser to load content from, you can protect your visitors from a whole range of issues. Here is a basic CSP response header.If the 4,275+ sites had used CSP headers, the compromised Browsealoud plugin would not have been able to load the JavaScript miner from coinhive.com.
Content-Security-Policy: script-src 'self'
Going back to the example above of an attacker using a specially crafted comment to load javascript from another domain, this CSP header would prevent the browser loading content from nastyhackers.com. The script-src directive specifies the whitelist of sources that the browser may load scripts from. Using the 'self' keyword is easier than specifying my whole domain and makes the policy a little easier to read once it starts growing. Because the domain nastyhackers.com isn't in the script whitelist, the browser will not load the script content from nastyhackers.com.
But coinhive.com is not actually the problem. The problem is that your browser is running malicious code from browseraloud.com, and that is a site that would have been in the CSP whitelist. The miscreants could have copied the miner code into the browseraloud.com page rather than incorporating it by reference. This is where SRI comes in.
What SRI is intended to do is to prevent Content Distribution Networks (CDNs) altering content they are distributing. Scott Helme explains:
Most sites on the Internet these days load some kind of content from a CDN, usually JS and CSS. Whilst this comes with great performance boosts and savings on bandwidth, we're trusting that CDN to load content into our pages, content that could possibly be harmful. Until now, we had no way to verify the content we were loading from the CDN was actually what we expected, it could have been altered or replaced. SRI allows us to check the integrity of the JS or CSS to ensure it's exactly what we were expecting.How is this done?
SRI allows us to instruct the browser to perform an integrity check on an asset loaded from a 3rd party. By embedding the base64 encoded cryptographic hash digest that we expect for the asset into the script or link tag, the browser can download the asset and check its cryptographic hash digest against the one it was expecting. If the hash of the downloaded asset matches the hash that we provided, then the content is what we were expecting to receive and the browser can safely include the script or style. If the hash doesn't match then we know we can't trust the data and it must be discarded.There are lots of interesting details about the use of SRI that you can read about in Scott Helme's explanation. But what's relevant here is that SRI doesn't just protect your site's visitors from accidental or malicious corruption of content by CDNs, it protects them from compromise of the originators of resources that your site uses such as browseraloud.com. Had the sites co-opted into mining Monero used SRI to force the browser to check the hash of the code from browseraloud.com,they would have discovered that the code had been corrupted and refused to run it.
But what of reporturi? It is a service that allows webmasters to track violations of the CSP they set. In this case, it would have alerted the sites to the fact that attempts were being made to load JavaScript from coinhive.com.
17 comments:
The gross from the Browsealoud hack was just $24!.
Epidemic of cryptojacking can be traced to escaped NSA superweapon writes Cory Doctorow:
"The epidemic of cryptojacking malware isn't merely an outgrowth of the incentive created by the cryptocurrency bubble -- that's just the motive, and the all-important the means and opportunity were provided by the same leaked NSA superweapon that powered last year's Wannacry ransomware epidemic."
Hackers Hijacked Tesla's Amazon Cloud Account To Mine Cryptocurrency reports msmash at \.
In Ad network uses advanced malware technique to conceal CPU-draining mining ads Dan Goodin reports on the next round of the war between ad-blockers and cryptojackers.
"GitHub says its security scan for old vulnerabilities in JavaScript and Ruby libraries has turned up over four million bugs and sparked a major clean-up by project owners." reports Liam Tung at ZDnet in GitHub: Our dependency scan has found four million security flaws in public repos.
"Multiple security firms recently identified cryptocurrency mining service Coinhive as the top malicious threat to Web users, thanks to the tendency for Coinhive’s computer code to be used on hacked Web sites to steal the processing power of its visitors’ devices. This post looks at how Coinhive vaulted to the top of the threat list less than a year after its debut, and explores clues about the possible identities of the individuals behind the service." writes Brian Krebs in a must-read post. Read to the end - it gets scary.
"After a policy that previously permitted them, Google has decided to remove any and all Chrome extensions that mine for cryptocurrencies after finding that too many developers didn't play by the company's rules." reports Peter Bright at Ars Technica.
"The Node Package Manager (npm) team avoided a disaster today when it discovered and blocked the distribution of a cleverly hidden backdoor mechanism inside a popular —albeit deprecated— JavaScript package.
The actual backdoor mechanism was found in "getcookies," a relatively newly created npm package (JavaScript library) for working with browser cookies.
The npm team —who analyzed this package earlier today after reports from the npm community— says "getcookies" contains a complex system for receiving commands from a remote attacker, who could target any JavaScript app that had incorporated this library."
This from Somebody Tried to Hide a Backdoor in a Popular JavaScript npm Package by Catalin Cimpanu.
Attacks on the package distribution channel like this show that the security of the Web depends on the vigilance of package maintainers and distributors. You don't realize, and can't even find out, the set of people you are trusting to keep you safe. Cimpanu writes:
"Npm index maintainers appear to have caught a future supply-chain attack before it happened. The npm team has also removed the "dustin87" user behind the attack and unpublished the getcookies, express-cookies, and http-fetch-cookies packages.
They've also rolled Mailparser to v2.2.0, removing three versions (2.2.3, 2.2.2, and 2.2.1) that contained the http-fetch-cookies malicious package."
"Criminals infected more than 100,000 computers with browser extensions that stole login credentials, surreptitiously mined cryptocurrencies, and engaged in click fraud. The malicious extensions were hosted in Google’s official Chrome Web Store." reports Dan Goodin at Ars Technica.
In A Malvertising Campaign of Secrets and Lies Check Point describe in detail a massive malvertising campaign:
"an alarming partnership between a threat actor disguised as a Publisher and several legitimate Resellers that leverage this relationship to distribute a variety of malware including Banking Trojans, ransomware and bots. Furthermore, powering the whole process is a powerful and infamous Ad-Network called AdsTerra.
The following analysis reveals the full extent of this well-planned Malvertising operation and the manipulation of the entire online advertising supply chain. Our research also raises questions, as seen in our conclusion, about the collaboration involved in this campaign as well as proper verification of adverts in the online advertising industry as a whole. Furthermore, concerns from this discovery include the current role of Ad-Networks in the Malvertising ecosystem, who, as we shall see, are the companies powering these attacks."
It is a must-read, the details are fascinating. Tip of the hat to John Leyden at The Register, who writes:
"The researchers told The Register that they have observed over 40,000 infection attempts per week from this campaign (that is, at least 40,000 clicks on malicious adverts) and said the campaign was still active. They reckon the crims are getting a decent return on their ad spend so they can afford to outbid legitimate publishers.
Check Point claimed that the brain behind the campaign – whom it dubbed Master134 – redirected stolen traffic from over 10,000 hacked WordPress sites and sold it to AdsTerra, a real-time bidding ad platform. They wrote that AdsTerra then sold it to advert resellers (ExoClick, AdKernel, EvoLeads and AdventureFeeds) which then went on to sell it to the highest bidding "advertiser".
However, the security researchers claimed, these "advertisers" were actually criminals looking to distribute ransomware, banking trojans, bots and other malware. The infected adverts then appeared on the websites of thousands of publishers worldwide, instead of clean, legitimate ads."
In The Bullshit Web Nick Heer takes up the cudgels laid down in 2015 by Georgis Kontaxis and Monica Chew in Tracking Protection in Firefox for Privacy and Performance. They demonstrated that Tracking Protection provided:
"a 67.5% reduction in the number of HTTP cookies set during a crawl of the Alexa top 200 news sites. [and] a 44% median reduction in page load time and 39% reduction in data usage in the Alexa top 200 news site."
Heer's excellent rant takes off from this observation:
"When I moved into my own apartment several years ago, I got to pick my plan and chose a massive fifty megabit per second broadband connection, which I have since upgraded.
So, with an internet connection faster than I could have thought possible in the late 1990s, what’s the score now? A story at the Hill took over nine seconds to load; at Politico, seventeen seconds; at CNN, over thirty seconds. This is the bullshit web."
He looks at:
"that CNN article, for example. Here’s what it contained when I loaded it:
+ Eleven web fonts, totalling 414 KB
+ Four stylesheets, totalling 315 KB
+ Twenty frames
+ Twenty-nine XML HTTP requests, totalling about 500 KB
+ Approximately one hundred scripts, totalling several megabytes — though it’s hard to pin down the number and actual size because some of the scripts are “beacons” that load after the page is technically finished downloading.
The vast majority of these resources are not directly related to the information on the page, and I’m including advertising. Many of the scripts that were loaded are purely for surveillance purposes: self-hosted analytics, of which there are several examples; various third-party analytics firms like Salesforce, Chartbeat, and Optimizely; and social network sharing widgets."
Heer continues with an interesting discussion of Google's AMP, which needs a whole post to itself.
Like everything else in the blockchain world, cryptojacking is centralized:
"according to researchers from RWTH Aachen University, who used a new detection technique to track pages mining the cryptocurrency and found that [PDF] just 10 users were responsible for 85 per cent of the links that the Coinhive service uses to mine about $250,000 worth of Monero currency every month."
Shaun Nichols at The Register reports on yet another instance of vulnerabilities in JavaScript libraries:
"As it turned out, the vulnerability they discovered went far beyond one subdomain on a site for lonely hearts. The team at VPNMentor said the since-patched security hole had left as many as 685 million netizens vulnerable to cross-site-scripting attacks, during which hackers attempt to steal data and hijack accounts. To pull off one of these scripting attacks, a victim would have to click on a malicious link or open a booby-trapped webpage while logged into a vulnerable service.
That staggering nine-figure number is because the security issue was actually within a toolkit, called branch.io, that tracks website and app users to figure out where they've come from, be it Facebook, email links, Twitter, etc. With the bug lurking in branch.io's code and embedded in a ton of services and mobile applications, the number of people potentially at risk of being hacked via cross-site scripting soared past the half-a-billion mark, we're told."
As usual, the vulnerable code wasn't doing anything for the readers of the Web pages, it was scraping their information to be sold. This is why you need to block ads and disable JavaScript wherever possible.
Catalin Cimpanu's US iOS users targeted by massive malvertising campaign reports that:
"A cyber-criminal group known as ScamClub has hijacked over 300 million browser sessions over 48 hours to redirect users to adult and gift card scams, a cyber-security firm has revealed today.
The traffic hijacking has taken place via a tactic known as malvertising, which consists of placing malicious code inside online ads.
In this particular case, the code used by the ScamClub group hijacked a user's browsing session from a legitimate site, where the ad was showing, and redirected victims through a long chain of temporary websites, a redirection chain that eventually ended up on a website pushing an adult-themed site or a gift card scam.
These types of malvertising campaigns have been going on for years, but this particular campaign stood out due to its massive scale, experts from cyber-security firm Confiant told ZDNet today."
Malvertisers target Mac users with steganographic code stashed in images by Dan Goodin reports on a fascinating new malvertising technique:
"The ads were served by a group security firm Confiant has dubbed VeryMal, a name that comes from veryield-malyst.com, one of the ad-serving domains the group uses. A run that was active from January 11 to January 13 on about 25 of the top 100 publisher sites triggered the image as many as 5 million times a day. In an attempt to bypass increasingly effective measures available to detect malicious ads, the images used steganography—the ancient practice of hiding code, messages, or other data inside images or text—to deliver its malicious payload to Mac-using visitors."
Catalin Cimpanu's Coinhive cryptojacking service to shut down in March 2019 reports that:
"Coinhive, an in-browser Monero cryptocurrency miner famous for being abused by malware gangs, announced this week its intention to shut down all operations next month, on March 8, 2019.
The service cited multiple reasons for its decision in a blog post published yesterday.
"The drop in hash rate (over 50%) after the last Monero hard fork hit us hard," the company said. "So did the 'crash' of the crypto currency market with the value of XMR depreciating over 85% within a year."
"This and the announced hard fork and algorithm update of the Monero network on March 9 has lead us to the conclusion that we need to discontinue Coinhive," the company said."
Brian Krebs has more on the Coinhive shutdown, and the sleaze behind it.
Post a Comment