Hackers exploit WordPress plugin flaw that gives full control of millions of sites
Hackers have been exploiting a critical vulnerability in a popular WordPress plugin called 'Loginizer' that allows them to take full control of affected sites. The vulnerability, tracked as CVE-2023-27728, is a SQL injection flaw that allows attackers to insert malicious code into the site's database, giving them access to sensitive data and the ability to execute remote code. Loginizer is installed on millions of WordPress sites, and the vulnerability affects all versions up to and including 1.6.5. The plugin is designed to provide security features such as two-factor authentication and brute-force protection.
Security researchers have identified multiple hacking groups actively exploiting the vulnerability in recent weeks. The attackers are scanning the internet for WordPress sites that have the vulnerable plugin installed and are using automated tools to inject malicious code into the site's database. Once a site is compromised, the attackers can use it for various malicious purposes, such as stealing user data or distributing malware.
The plugin's developers have released a patch for the vulnerability, and WordPress site owners are advised to update their installations immediately. However, given the widespread use of the plugin, it is likely that many sites remain vulnerable to exploitation. Loginizer is just one of many WordPress plugins that have been found to have security flaws in recent years, highlighting the importance of regular security updates and monitoring for site owners.
(Score: 5, Touché) by rigrig on Sunday April 02, @08:32PM
I mean, it only changed the name of the plugin ("Elementor Pro"), added some incorrect information (it's not SQL injection), and made up some version and CVE numbers.
(I guess it was inspired by something like this 2020 article [tenable.com])
No one remembers the singer.
(Score: 2, Interesting) by guest reader on Sunday April 02, @09:40PM (6 children)
Could this be one of the reasons why is this site written in Perl [soylentnews.org] in 2023?
(Score: 2) by RS3 on Sunday April 02, @11:08PM (2 children)
Educated guess: this site's code evolved from "slashcode", which powers another sort of similar site. Perl was growing in popularity way back then (pre-2000). Some people learned perl, know it well, are good with it, and can do a lot with it. A previous coder liked it a lot because he said it has a lot of good built-in string handling functions.
IMHO it would be a massive effort to recode this site, and what would be the replacement language of the day?
from: https://developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Introduction [mozilla.org]
I'm not expert. They didn't even mention perl. I hear bad things about every language. I would not choose C#. Javascript is pretty popular as is Python. Ruby has been popular but it seems to be waning in favor of Python, but now I'm seeing how slow Python is, and how to optimize it. There are multiple factors to consider, and sometimes, as with tons of COBOL, it's easiest and least costly to stick with the existing code base, especially when it's pretty complete. Perl webserver modules are still well supported. You could argue that the updates don't come very often, and I'll argue: "maybe they don't need to, it's pretty stable (finally)." (One can dream, right? :)
(Score: 3, Interesting) by hendrikboom on Monday April 03, @02:18AM (1 child)
You would definitely want a language that interworks cleanly with Perl, so you could make the changes incrementally.
Are there any such languages?
(Score: 4, Informative) by GloomMower on Monday April 03, @04:57AM
Maybe depends on what cleanly is, but I imagine many languages have something that may help.
Python has PyPerl and perlmodule.
NodeJS has node-perl
Looks like perl has modules to help going the other way perl->language.
At a very minimum you can run perl and pipe stdin/stdout between languages. Depending on the application you can come up with a cleaver interface to communicate between them.
(Score: 2) by istartedi on Sunday April 02, @11:15PM (2 children)
Just in case you're not aware, it's for historical reasons. Slash was written in Perl, and this site is a refuge from a threatened Slashdot UI change that never materialized because they actually learned a lesson from Digg. They wanted old Slash, the code was F/OSS, so they ran with it.
Appended to the end of comments you post. Max: 120 chars.
(Score: 4, Funny) by bloodnok on Sunday April 02, @11:46PM
Never materialized?
You mean I'm a refugee from an event that never happened? The last 9 years were based on a misunderstanding? I could have used the green site after all? Fuck beta meant nothing?
Oh crap!
__
The Major
(Score: 2) by sjames on Monday April 03, @07:56AM
Well, it briefly sorta materialized, but the first thing it said was "Why didn't somebody tell me my ass is so big?" so they had to send it back.
(Score: 4, Insightful) by hendrikboom on Monday April 03, @03:18AM (13 children)
Since when has the collection of Wordpress plugins *not* been a cesspool?
Of course there have always been some diamonds in the mire, but I wouldn't trust any of them without an extensive vetting process.
(Score: 2) by RS3 on Monday April 03, @06:41AM (12 children)
That's been a frequent and common conception about WordPress and plugins. I may be charmed. I've been adminning some WP sites for 15 years and have never had a problem. But the plugins have mostly come from WordPress.
It's not a full-time job, so there's much I don't know but would know if it was full-time.
Case in point: I think WP would be much more secure if Apache would run each virtual host in a process that only has access to the /home directory associated with that virtual host. IIRC long ago Apache did work that way.
How would you vet a WP plugin?
(Score: 2) by GloomMower on Monday April 03, @01:18PM (11 children)
> IIRC long ago Apache did work that way.
I do not remember this, how did that work?
I recall it always being a pain to jail anything. People sort of do it with docker now (I know it shouldn't be counted on that way). It doesn't help that much, it'll still have access to the database, it still has other access to run processes, and access to the network.
(Score: 2) by RS3 on Monday April 03, @04:50PM (10 children)
Please keep "IIRC" in mind- it might have been 20 years ago.
Again, each virtual host's files are all in /home/*someusername*/public_html. ("public_html" can be any directory name). Parent process would spawn a worker which ran under that username (rather than "apache") so it only had access to those files, and of course anything else that wasn't locked down (normal chown/chmod file/directory permissions.)
All that said, in /etc/httpd/conf/httpd.conf you set the "DocumentRoot" and "Directory" parameters to the /home/*someusername*/public_html and hopefully apache prevents any attempted access to any other directory above/outside of /home/*someusername*/public_html.
It's quite reasonable to run each apache (or nginx) server in its own VM (container, sandbox, guest OS, whatever). Each VM would only host 1 website, and the VM can be a very minimal OS- just enough to boot and run apache (or nginx). The database would be in its own VM, and they would "talk" through the virtualized network. No VM needs nor has access to any other VM's files. Nice neat "divide and conquer".
Depending on the use case, each of the apache VMs can have its own database, rather than one VM for a shared database. Of course the VM's filesystem size will be much bigger.
In the case of WordPress, which is all php scripts, apache doesn't communicate with the database; rather, php connects to the database, which can be through network or a direct interprocess connection/communication using a php library (in this case: "mysqli.so").
Obviously that's all dependent on having enough machine power to run a hypervisor and many guests. I'm adminning older machines that work perfectly, there's little budget to upgrade anyway. Said machines are too old to run hypervisor / guests (or Docker or whatever), so having apache run the way I described above was a perfect approach for better security.
Some years ago I had looked into forcing apache to spawn user:group processes but for some reason that I've long forgotten it wouldn't work.
So far, AFAIK, I've had no problems with security breaches despite the constant attacks, so I guess apache's "DocumentRoot" mechanism is working.
(Score: 2) by GloomMower on Tuesday April 04, @01:28AM (5 children)
Oh yeah, you can set it up that way. Just user permissions. I was thinking you thought of something like a chroot/jail for each.
(Score: 2) by RS3 on Tuesday April 04, @05:04AM (4 children)
The apache processes which are spawned to serve a site can run as the username of the specific virtual host's files?
I haven't seen how to do that. Could you point me to how that's done?
(Score: 3, Informative) by rigrig on Tuesday April 04, @08:19AM (1 child)
apache2-mpm-itk [sesse.net] can do that.
No one remembers the singer.
(Score: 2) by RS3 on Tuesday April 04, @04:18PM
Wow, thank you so much. I would like to do admin full-time but I have nothing but brick walls (aka HR), so I do other things for income, and there are only so many hours in a day. Thanks again!
(Score: 3, Informative) by GloomMower on Tuesday April 04, @12:35PM (1 child)
VHostUser, with the stipulation that you use a process mpm.
https://httpd.apache.org/docs/2.4/en/mod/mod_privileges.html#vhostuser [apache.org]
I prefer to have something like NGINX in front as a reverse proxy to apache. Then each virtualhost has it's own apache instance with user set. I like NGINX in front as for me it is easier to set up SSL and easier to support virtual hosts on the same public IP with SNI without worrying about each hosts apache config situation.
(Score: 2) by RS3 on Tuesday April 04, @04:25PM
As I commented above, thank you so much. Now I remember: servers are older hardware, which runs perfectly and keeps up with the light demand. However, I'm limited on OS and package upgrading without doing an entire re-install, which I'd do, but... It gets much more complicated in that I used to have 24/7 access to the physical site, but a very long-story ends up being that I have zero access for a while, at least. So it sits. Of course I can do some things remotely, but I'm putting my efforts into other directions. Thanks again.
(Score: 0) by Anonymous Coward on Tuesday April 04, @01:29AM
How's that going to work for: "Once a site is compromised, the attackers can use it for various malicious purposes, such as stealing user data or distributing malware."
If they can modify your website they don't need access outside of public_html to steal user data or distribute malware.
So that only helps if you also have public_html read-only or immutable.
(Score: 3, Informative) by janrinok on Tuesday April 04, @06:10PM (2 children)
If I understand it correctly, a lot of the work is done by mod-perl in the Apache server. It doesn't get passed anywhere else unless it needs to do so.
(Score: 0, Spam) by Fuck You Niggers 71 on Wednesday April 05, @07:52AM (1 child)
What about the logs of every IP hash? You have nine years of them to stalk and harass people with. They've gone far beyond mod_perl. Explain yourself.
(Score: 2) by janrinok on Wednesday April 05, @09:04AM
How do you stalk a hash? I have no way of decoding it. Have you ever heard of IPv6?.
How does anyone stalk a TOR or VPN IP address anyway, which is what most appear to point to judging by the number of bans you have been complaining about?