Posts Tagged: javascript


26
Mar 18

Who and What Is Coinhive?

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.

Coinhive is a cryptocurrency mining service that relies on a small chunk of computer code designed to be installed on Web sites. The code uses some or all of the computing power of any browser that visits the site in question, enlisting the machine in a bid to mine bits of the Monero cryptocurrency.

Monero differs from Bitcoin in that its transactions are virtually untraceble, and there is no way for an outsider to track Monero transactions between two parties. Naturally, this quality makes Monero an especially appealing choice for cybercriminals.

Coinhive released its mining code last summer, pitching it as a way for Web site owners to earn an income without running intrusive or annoying advertisements. But since then, Coinhive’s code has emerged as the top malware threat tracked by multiple security firms. That’s because much of the time the code is installed on hacked Web sites — without the owner’s knowledge or permission.

Much like a malware infection by a malicious bot or Trojan, Coinhive’s code frequently locks up a user’s browser and drains the device’s battery as it continues to mine Monero for as long a visitor is browsing the site.

According to publicwww.com, a service that indexes the source code of Web sites, there are nearly 32,000 Web sites currently running Coinhive’s JavaScript miner code. It’s impossible to say how many of those sites have installed the code intentionally, but in recent months hackers have secretly stitched it into some extremely high-profile Web sites, including sites for such companies as The Los Angeles Times, mobile device maker Blackberry, Politifact, and Showtime.

And it’s turning up in some unexpected places: In December, Coinhive code was found embedded in all Web pages served by a WiFi hotspot at a Starbucks in Buenos Aires. For roughly a week in January, Coinhive was found hidden inside of YouTube advertisements (via Google’s DoubleClick platform) in select countries, including Japan, France, Taiwan, Italy and Spain. In February, Coinhive was found on “Browsealoud,” a service provided by Texthelp that reads web pages out loud for the visually impaired. The service is widely used on many UK government websites, in addition to a few US and Canadian government sites.

What does Coinhive get out of all this? Coinhive keeps 30 percent of whatever amount of Monero cryptocurrency that is mined using its code, whether or not a Web site has given consent to run it. The code is tied to a special cryptographic key that identifies which user account is to receive the other 70 percent.

Coinhive does accept abuse complaints, but it generally refuses to respond to any complaints that do not come from a hacked Web site’s owner (it mostly ignores abuse complaints lodged by third parties). What’s more, when Coinhive does respond to abuse complaints, it does so by invalidating the key tied to the abuse.

But according to Troy Mursch, a security expert who spends much of his time tracking Coinhive and other instances of “cryptojacking,” killing the key doesn’t do anything to stop Coinhive’s code from continuing to mine Monero on a hacked site. Once a key is invalidated, Mursch said, Coinhive keeps 100 percent of the cryptocurrency mined by sites tied to that account from then on.

Mursch said Coinhive appears to have zero incentive to police the widespread abuse that is leveraging its platform.

“When they ‘terminate’ a key, it just terminates the user on that platform, it doesn’t stop the malicious JavaScript from running, and it just means that particular Coinhive user doesn’t get paid anymore,” Mursch said. “The code keeps running, and Coinhive gets all of it. Maybe they can’t do anything about it, or maybe they don’t want to. But as long as the code is still on the hacked site, it’s still making them money.”

Reached for comment about this apparent conflict of interest, Coinhive replied with a highly technical response, claiming the organization is working on a fix to correct that conflict.

“We have developed Coinhive under the assumption that site keys are immutable,” Coinhive wrote in an email to KrebsOnSecurity. “This is evident by the fact that a site key can not be deleted by a user. This assumption greatly simplified our initial development. We can cache site keys on our WebSocket servers instead of reloading them from the database for every new client. We’re working on a mechanism [to] propagate the invalidation of a key to our WebSocket servers.”

AUTHEDMINE

Coinhive has responded to such criticism by releasing a version of their code called “AuthedMine,” which is designed to seek a Web site visitor’s consent before running the Monero mining scripts. Coinhive maintains that approximately 35 percent of the Monero cryptocurrency mining activity that uses its platform comes from sites using AuthedMine.

But according to a report published in February by security firm Malwarebytes, the AuthedMine code is “barely used” compared to the use of Coinhive’s mining code that does not seek permission from Web site visitors. Malwarebytes’ telemetry data (drawn from antivirus alerts when users browse to a site running Coinhive’s code) determined that AuthedMine is used in a little more than one percent of all cases that involve Coinhive’s mining code.

Image: Malwarebytes. The statistic above refer to the number of times per day between Jan. 10 and Feb. 7 that Malwarebytes blocked connections to AuthedMine and Coinhive, respectively.

Asked to comment on the Malwarebytes findings, Coinhive replied that if relatively few people are using AuthedMine it might be because anti-malware companies like Malwarebytes have made it unprofitable for people to do so.

“They identify our opt-in version as a threat and block it,” Coinhive said. “Why would anyone use AuthedMine if it’s blocked just as our original implementation? We don’t think there’s any way that we could have launched Coinhive and not get it blacklisted by Antiviruses. If antiviruses say ‘mining is bad,’ then mining is bad.”

Similarly, data from the aforementioned source code tracking site publicwww.com shows that some 32,000 sites are running the original Coinhive mining script, while the site lists just under 1,200 sites running AuthedMine.

WHO IS COINHIVE?

[Author’s’ note: Ordinarily, I prefer to link to sources of information cited in stories, such as those on Coinhive’s own site and other entities mentioned throughout the rest of this piece. However, because many of these links either go to sites that actively mine with Coinhive or that include decidedly not-safe-for-work content, I have included screenshots instead of links in these cases. For these reasons, I would strongly advise against visiting pr0gramm’s Web site.]

According to a since-deleted statement on the original version of Coinhive’s Web site — coin-hive[dot]com — Coinhive was born out of an experiment on the German-language image hosting and discussion forum pr0gramm[dot]com.

A now-deleted “About us” statement on the original coin-hive[dot]com Web site. This snapshop was taken on Sept. 15, 2017. Image courtesy archive.org.

Indeed, multiple discussion threads on pr0gramm[dot]com show that Coinhive’s code first surfaced there in the third week of July 2017. At the time, the experiment was dubbed “pr0miner,” and those threads indicate that the core programmer responsible for pr0miner used the nickname “int13h” on pr0gramm. In a message to this author, Coinhive confirmed that “most of the work back then was done by int13h, who is still on our team.”

I asked Coinhive for clarity on the disappearance of the above statement from its site concerning its affiliation with pr0gramm. Coinhive replied that it had been a convenient fiction:

“The owners of pr0gramm are good friends and we’ve helped them with their infrastructure and various projects in the past. They let us use pr0gramm as a testbed for the miner and also allowed us to use their name to get some more credibility. Launching a new platform is difficult if you don’t have a track record. As we later gained some publicity, this statement was no longer needed.”

Asked for clarification about the “platform” referred to in its statement (“We are self-funded and have been running this platform for the past 11 years”) Coinhive replied, “Sorry for not making it clearer: ‘this platform’ is indeed pr0gramm.”

After receiving this response, it occurred to me that someone might be able to find out who’s running Coinhive by determining the identities of the pr0gramm forum administrators. I reasoned that if they were not one and the same, the pr0gramm admins almost certainly would know the identities of the folks behind Coinhive. Continue reading →


21
Jan 15

Java Patch Plugs 19 Security Holes

Oracle this week released its quarterly patch update for Java, a widely-installed program that for most casual users has probably introduced more vulnerability than utility. If you have Java installed and require it for some application or Web site, it’s time to update it. If you’re not sure you have Java on your computer or are unsure why you still have it, read on for advice that could save you some security headaches down the road.

javamessOracle’s update brings Java 7 to Update 75 and Java 8 to Update 31, and fixes at least 19 security vulnerabilities in the program. Security vendor Qualys notes that 13 of those flaws are remotely exploitable, with a CVSS score of 10 (the most severe possible score).

Java 7 users should know that Oracle plans to start using the auto-update function built into the program to migrate those users to Java 8 this week.

According to a new report (PDF) from Cisco, online attacks that exploit Java vulnerabilities have decreased by 34 percent in the past year. Cisco reckons this is thanks to security improvements in the program, and to bad guys embracing new attack vectors — such Microsoft Silverlight flaws (if you’re a Netflix subscriber, you have Silverlight installed). Nevertheless, my message about Java will remain the same: Patch it, or pitch it. Continue reading →


25
May 11

Blocking JavaScript in the Browser

Most Web sites use JavaScript, a powerful scripting language that helps make sites interactive. Unfortunately, a huge percentage of Web-based attacks use JavaScript tricks to foist malicious software and exploits onto site visitors. To protect yourself, it is critically important to have an easy method of selecting which sites should be allowed to run JavaScript in the browser.

It is true that selectively allowing JavaScript on known, “safe” sites won’t block all malicious scripting attacks: Even legitimate sites sometimes end up running malicious code when scammers figure out ways to sneak tainted, bogus ads into the major online ad networks. But disallowing JavaScript by default and selectively enabling it for specific sites remains a much safer option than letting all sites run JavaScript unrestricted all the time.

Firefox has many extensions and add-ons that make surfing the Web a safer experience. One extension that I have found indispensable is NoScript. This extension lets the user decide which sites should be allowed to run JavaScript, including Flash Player content. Users can choose to allow specific exceptions either permanently or for a single browsing session.

The NoScript extension makes it easy to place or remove these restrictions on a site-by-site basis, but a novice user may need some practice to get the hang of doing this smoothly. For instance, it’s not uncommon when you’re shopping online to come across a site that won’t let you submit data without fully allowing JavaScript. Then, when you enable scripting so that you can submit your address and payment information, the page often will reload and clear all of the form data you’ve already supplied, forcing you to start over. Also, many sites host content from multiple third-party sites, and users who prefer to selectively enable scripts may find it challenging to discover which scripts need to be enabled for the site to work properly.

Chrome also includes similar script- and Flash blocking functionality that seems designed to minimize some of these challenges by providing fewer options. If you tell Chrome to block JavaScript on all sites by default, when you browse to a site that uses JavaScript, the upper right corner of the browser displays a box with a red “X” through it. If you click that and select “Always allow JavaScript on [site name]” it will permanently enable JavaScript for that site, but it doesn’t give you the option to block third-party JavaScript content on the site as Noscript does. In my testing, I had to manually refresh the page before Chrome allowed scripting on a site that I’d just whitelisted.

Continue reading →


6
Dec 10

What You Should Know About History Sniffing

Researchers have discovered that dozens of Web sites are using simple Javascript tricks to snoop into visitors’ Web browsing history. While these tricks are nothing new, they are in the news again, so it’s a good time to remind readers about ways to combat this sneaky behavior.

The news is based on a study released by University of California, San Diego researchers who found that a number of sites were “sniffing” the browsing history of visitors to record where they’d been.

This reconnaissance works because browsers display links to sites you’ve visited differently than ones you haven’t: By default, visited links are purple and unvisited links are blue. History-sniffing code running on a Web page simply checks to see if your browser displays links to specific URLs as purple or blue.

These are not new discoveries, but the fact that sites are using this technique to gather information from visitors seems to have caught many by surprise: A lawyer for two California residents said they filed suit against one of the sites named in the report — YouPorn — alleging that it violated consumer-protection laws by using the method.

As has been broadly reported for months, Web analytics companies are starting to market products that directly take advantage of this hack.  Eric Peterson reported on an Israeli firm named Beencounter that openly sells a tool to Web  site developers to query whether site visitors had previously visited up to 50 specific URLs.

The Center for Democracy & Technology noted in March that another company called Tealium has been marketing a product taking advantage of this exploit for nearly two years.  “Tealium’s “Social Media” service runs daily searches of a customer’s name for news and blog postings mentioning the customers, and then runs a JavaScript application on the customer’s site to determine whether visitors had previously read any of those stories,” CDT wrote. “The service allows Tealium customers a unique insight into what sites visitors had previously read about the company that may have driven them to the company’s Web site.”

Continue reading →


24
May 10

Devious New Phishing Tactic Targets Tabs

Most Internet users know to watch for the telltale signs of a traditional phishing attack: An e-mail that asks you to click on a link and enter your e-mail or banking credentials at the resulting Web site. But a new phishing concept that exploits user inattention and trust in browser tabs is likely to fool even the most security-conscious Web surfers.

As Mozilla Firefox creative lead Aza Raskin describes it, the attack is as elegant as it is simple: A user has multiple tabs open, and surfs to a site that uses special javacript code to silently alter the contents of a tabbed page along with the information displayed on the tab itself, so that when the user switches back to that tab it appears to be the login page for a site the user normally visits.

Consider the following scenario: Bob has six or seven tabs open, and one of the sites he has open (but not the tab currently being viewed) contains a script that waits for a few minutes or hours, and then quietly changes both the content of the page and the icon and descriptor in the tab itself so that it appears to be the login page for Gmail.

In this attack, the phisher need not even change the Web address displayed in the browser’s navigation toolbar. Rather, this particular phishing attack takes advantage of user trust and inattention to detail, or what Raskin calls “the perceived immutability of tabs.” Then, as the user scans their many open tabs, the favicon and title act as a strong visual cue, and the user will most likely simply think they left a Gmail tab open.

“When they click back to the fake Gmail tab, they’ll see the standard Gmail login page, assume they’ve been logged out, and provide their credentials to log in,” Raskin explained. “After the user has enter they have entered their login information and sent it back your server, you redirect them to Gmail. Because they were never logged out in the first place, it will appear as if the login was successful.”

Raskin includes a proof-of-concept at his site, which is sort of creepy when you let it run. In fact, at least once while composing this blog post in Firefox I went to click on the tab that had my Gmail inbox open, only to discover I’d accidentally clicked on Raskin’s page, which had morphed into the fake Gmail site in the interim.

It’s important to keep in mind that this attack could be used against any site, not just Gmail. Also, Raskin includes a few suggestions about how this attack could be made far sneakier — such as taking advantage of CSS history attacks.

Of course, if you are browsing with the excellent “Noscript” add-on and this is a site you have not allowed to run javascript, the proof-of-concept won’t work until you allow javascript on the page. It did not work completely against the Safari browser on my Mac (no favicon), and the test page failed completely against Google Chrome. [Update: As several readers have correctly pointed out, this attack does in fact work against Chrome, although it doesn’t seem to change the favicon in Chrome tabs].

I’m left wondering what this new form of phishing will be called if it is ever adopted by the bad guys. Tabnabbing? Tabgrabbing? See if you can coin a better phrase in the comments below.

Update, May 25, 7:55 p.m. ET: Researcher Aviv Raff has posted an interesting proof-of-concept of his own that shows how this attack can work against Firefox even when users have the Noscript add-on installed and in full paranoid mode. Raff crafted his page, which is a mock up of this blog post, to morph into an image of the Gmail login page, and it will reload every 20 seconds but will only change to the sample phish page if you move to another tab with your mouse, or after 10 reloads (in case you moved with the keyboard). So it will change only after 3 minutes or so, unless you move to another tab with your mouse.

“I was trying to find a way to work around the javascript need for the [proof-of-concept],” Raff said in an instant message. “First I was able to do this without knowing if the user moved to a new tab. Now I can almost be sure of that.”

Update, May 27, 11:41 p.m. ET: For Firefox users with the Noscript plugin, there is an update to the program that can block these types of tabnabbing attacks.