Keylogger Found On Nearly 5,500 WordPress Sites (bleepingcomputer.com) 83
An anonymous reader writes: Nearly 5,500 WordPress sites are infected with a malicious script that logs keystrokes and sometimes loads an in-browser cryptocurrency miner. The malicious script is being loaded from the "cloudflare.solutions" domain, which is not affiliated with Cloudflare in any way, and logs anything that users type inside form fields as soon as the user switches away from an input field. The script is included on both the sites' frontends and backends, meaning it can steal both admin account credentials and credit card data from WP sites running e-commerce stores. According to site source code search engine PublicWWW, there are 5,496 sites running this keylogger. The attacker has been active since April.
Block '*cloudflare*' at your router (Score:1)
Noxious flatulent gas clouds are flammable and prone to flare up. Avoid that risk by banning cloudflare from your world.
Re: (Score:1)
My bassoon reed is NOT a phallus.
How long have you been an A.C. crapflooder?
Re: (Score:3)
About 25 years, but what does this have to do with...
Wait... you're trying to come on to me? Hey, I'm no guy for just one night! I at least want dinner first.
Reaction faces... (Score:4, Insightful)
Random users :
"OOH MY GOD !!! NO !!!! ALL MY PRECIOUS PASSWORDS!!!!"
Users of password managers :
"Phew !... at least they didn't log these".
Users of NoScript [noscript.net] (and other such popular script blocking extensions) :
"...yeah... whatever...."
---
Bonus:
Users of links/elinks/lynx, curl/wget and straight telnet :
"Bwaaah.... we're left out of the fun once again!..."
Re: (Score:3)
Because they can use it to scam people out of $250 for 20 minutes work setting up a "website".
Re: (Score:1)
Re: This is my shocked face (Score:1)
Nobody said that except you asshole.
More details? (Score:2)
They don't say if it's WordPress itself or in a popular plug-in.
Re: (Score:1)
The extension thing was made known for over a year before FF57's release. Plenty of time for users and extension authors to get up to speed.
Re: (Score:2)
I don't see how that could possibly be the issue.
Both NoScript 10+ and YesScript2 support Firefox 57+. If the users don't update their plugins after updating the browser, that's not really Mozilla's fault.
The old NPAPI support needed to die---for security reasons. Your attempt to cast a security improvement as a problem is ill-founded, and, quite frankly, idiotic.
Re: Firefox 57's extension breakage enabling this? (Score:2)
Noscript 10 is pretty terrible though. At this point it looks and feels like an Alpha release.
How's YesScript? Any better?
Use NoScript. It works the best (eve n in FF57) (Score:5, Informative)
Some of the most popular extensions are those that help prevent JavaScript from being used maliciously, and these kinds of extensions were among the ones to suffer the worst breakage, due to being so intricately tied to the operation of the browser.
Regarding ads:
uBlock Origin - was WebExtension compatible in advance, well before the release of FF57 (I use that one)
uBlock - was WebExtension compatible in advance, well before the release of FF57
AdBlock Plus - was WebExtension compatible in advance, well before the release of FF57
Regarding trackers:
FSF's Prvacy Badger - was WebExtension compatible in advance, well before the release of FF57 (I use that one)
Regarding script blocking :
uMatrix - was WebExtension compatible in advance, well before the release of FF57
NoScript - well Giogio Maone was a tiny bit in a hurry, but slill manage to make it compatible within a couple of days after the release of FF57. Still kudos to him for having managed it. (I use that one)
etc.
Well what was you point ?
Yup, maybe that weird specific no widely known extension that 3 other people beside you use, and whose authors have abandoned for the last 10 year, maybe that extension broke for you in FF57.
Meanwhile, all the major security extension were transitioned more or less on time. Partly on the grounds of Mozilla crew members closely collaborating with extension authors, to make sure that their WebExtensions interface provides all the necessary API to make the functionality possible.
So I would suggest that you stop bitching about the change of API by spitting the same copy-pasta whining on each remotely relevant /. news story, and instead spend your time and effort switching to extensions with a tiny bit more active developers and a little bit more active community than whatever rare precious gem you were using up until now.
While there have been efforts to port some of these extensions to Firefox's new WebExtensions model, in some cases it has proven to be impossible to replicate the existing functionality because WebExtensions is so, for a lack of a better word, crippled.
Which is why Mozilla devs have actively reached out to authors of popular XUL extensions to see how they could make them still work once transitioning to the WebExtensions API.
All the major security extensions worth mentioning have more or less finished transitioning, despite some of them not working on the Google's Chrome spin of WebExtensions.
So I'm now wondering how many Firefox users are now browsing without any kind of protection from malicious JavaScript code. I'm thinking it could be a far higher number than we might expect
I'm thinking it's only the stupider ones among them like you, who can't even put some though into the selection of security tools they'll use.
Next time, pick an extension with an author that is still alive and a number of users which exceeds your direct family.
Which security extensions ? (Score:2)
Being concerned when Mozilla breaks security extensions isn't 'bitching'.
Which security extensions got broken ?
Most of the major ones got ported to WebExtension API well in advance.
The ones that were not ready on D-day, managed to get ready over the few days after the big switch.
Really in practice, I haven't anyone I know bitten by missing security extensions.
If you're complaining that your specific security extension got broken, means :
- you're using a very rare one. at least it means the biggest part of firefox users (those who use the most common security extensions) aren't a
Re: (Score:1)
Because of Netflix (Score:2)
I'm going to go ahead and stick my head in a bear trap, but why does Mozilla rely so much on outside programmers to make the thing even borderline secure? I understand the reasoning not to include ad blockers, but some of the other commonly used extensions should just be baked in. Or am I really just too paranoid?
In a way you are paranoid, in that unlike most of the typical users you value your security much more than ease of use.
Most of the user don't have any idea about security. On the other hand, most of the users want to just watch their Netflix movie, post their shit on Facebook, etc. they want all the typical online activity to work straight out of the box.
Saddly, the current accepted standard behavious of *ALL* browser, is to download and execute any bullshit linked in a web page, no question asked
(though th
Re: (Score:1)
Re: (Score:2)
Actually no (Score:2)
Dear "hosts" APK troll.
Nope, your hosts doesn't work in the case of malicious javascript code.
You can't block just scripts, while still letting the plain HTML webpages.
A "hosts" entry can only block access to a whole domain.
Also it depends on the "hosts" list containing the new threat (it's fundamentally a black-listing approach. If a threat isn't known, a hosts list cannot prevent it).
Systems like NoScripts are White-Listing. They block by default unless told otherwise. I could never be affected by malicio
Re: (Score:2)
It's well-known that Firefox 57 unnecessarily, but intentionally, broke most extensions for most users.
Have you tried to access cloudflare.solutions? I have and can't. Google shows this a problem since 2011, I got nothing.
cloudflare.solutions isn't being blocked by me.
The problem is JavaScript! (Score:1)
The websites involved are irrelevant. The software they're running is irrelevant.
The real problem here is JavaScript, and more specifically, how JavaScript has pretty much no legitimate uses but a huge number of illegitimate, unwanted uses.
JavaScript adds nothing beneficial to the web. Some people will claim that JavaScript + AJAX can allow for a better user experience, but that's nonsense.
Just look at a site like Slashdot. The more that JavaScript has been used here, the worse the user experience has gotte
He's right about a good deal... apk (Score:1)
See subject & I'll add to what he said or missed - Javascript's misused like mad, slows you, runs on your dime clientside taking up power/cpu/ram & other forms of I/O + it slows you way, Way, WAY down! CGI bins/WinCGI run server side (so did ISAPI/NSAPI iirc but were often leaky due to being written in C as well as buffer overflow vulnerable thus - that could be changed by writing them in C++ instead, easily) NOT using YOUR POWER BILL or cpu cycles/ram & other I/O either.
Nobody has to note that
Re: (Score:2)
Re: (Score:1)
JavaScript is an old language, developed back when the web was a much safer place
...back before JavaScript?
This is why we need cryptographic authentication (Score:5, Interesting)
We need to switch to cryptographic authentication. FIDO U2F makes a lot of this moot.
With some software put in place at the CRAs, they could use FIDO devices to prevent opening new accounts. If you go into a bank with ID (Driver's ID, passport) and a FIDO device, the bank has done the best identification of you it can. Plug the key into a USB port in a computer, have the bank authorize trust establishment, and you generate 3 new key pairs--one for each CRA. The CRAs get the public key; the private key stays on your FIDO device. If it gets lost or stolen, call your bank, voice-verify, and they can cancel the trusts: your credit cards still work, but you can't open any new credit accounts until you physically enter a bank.
Credit cards? Your computer should have an EVM reader. Google accepts FIDO U2F authentication; Google Wallet (or Verified by Visa) could readily authenticate you before accepting a transaction, providing EVM--cryptographic credit card transacting.
Social Security? Walk into a DMV, Social Security building, or other Government building. They all federate trust. Generate a pile of new keys for all the Government service providers.
The weakest link is really any Internet provider to whom you authenticate, since you'll need a method of recovery. Anyone handling credit card transactions should use the CRAs as a secondary: if you can authorize a credit check, you're probably you.
You can lose personally identifiable information, but you can't lose authentication--not for any broad window, and not over the Internet.
Re:Not surprising (Score:5, Interesting)
This is why my Wordpress site runs Wordfence and uses Google Authenticator. At least I have 2FA and everything thrown at it gets run through an analysis engine to detect known exploits (and attack patterns) before it gets passed onto Wordpress. Updating the plug-ins and theme also helps. It also runs inside a Docker container, without write access to the Wordpress core (just plug-ins, themes, and uploads).
It's nice software, but you need a security product dedicated to protecting that one piece of software if you're going to use it. Plus running as a Congressional candidate with an IT security background and getting hacked would be embarrassing.