Hack related to Simple Fields?

We are having similar issues as well.

Thanks for adding that. I had guessed that we wouldn’t be the only ones affected.

We actually ended up doing an export of our Simple Fields configuration to JSON file from our backup site, then imported that to our affected current site, and everything appears to be back to normal (after waiting a minute, it showed up correctly). So that is still consistent with the problem being isolated to Simple Fields data.

that’s exactly what we did as well but is only temporary fix. Hacks will still happen. in fact it has occured,again today. not 100% sure how they get in but need sometime to figure out. will post more findings hopefully soon.

I have the same problem on one of my sites. Behavior is exactly as described here.
Additionaly to the “test” Field Group, the language settings have been changed from “German” to “English”. Happend two times today. Deactivated Simple Fields. Now, I have to wait if it will happen again?

I have this as well on both my sites. One is ok cos the back up wasfine but i can’t get the other to backup so i’m screwed it seems. Annoyingly i can see all the data still in the db it just seems i need to put the post connecters backbut i don’t remember what they were

*edit* i managed to get my site back by finally getting a backup to work and exporting the simple fields json for the connecters. I then imported them again into the live site removing the spam ones – obviously as mentioned above nothing to stop this happening again so i think i’ll have to update it to advanced fields

• This reply was modified 5 years, 1 month ago by livingdeadbeat23.

Hi everyone! Plugin author here. I’m sorry to hear that you are having problems. And yes, it’s probably because someone found a vulnerability in the import function of Simple Fields. The people that found the vulnerability did not contact med at all, they just published details on how to hack a site.

I haven’t touched the code for Simple Fields in years so an update won’t come from me I’m afraid. If you know your way around PHP you could rename or remove the function maybe_do_import() that are in file inc-admin-options-export-import.php.

• This reply was modified 5 years, 1 month ago by eskapism.

After a couple hours of digging, I found some occurance of the js hack injection in DB under wp_posts. You can search under wp_posts => guid with ‘%https://bes.belaterbewasthere.com%’ Seems like its a scheduled action. Maybe woocommerce related as the sites effected both have woocommerce active. Hopefully, this won’t come back again.

Interesting. I just did the same checks on our wp_posts table but didn’t find anything matching belaterbewasthere in any of the text or varchar fields of wp_posts. I also did queries on a few other tables like wp_comments and wp_links. We did previously have woocommerce installed but it has been deactivated a long time.

SELECT * FROM wp_posts
WHERE
post_content LIKE ‘%belaterbewasthere%’
OR post_title LIKE ‘%belaterbewasthere%’
OR post_excerpt LIKE ‘%belaterbewasthere%’
OR post_status LIKE ‘%belaterbewasthere%’
OR comment_status LIKE ‘%belaterbewasthere%’
OR ping_status LIKE ‘%belaterbewasthere%’
OR post_password LIKE ‘%belaterbewasthere%’
OR post_name LIKE ‘%belaterbewasthere%’
OR to_ping LIKE ‘%belaterbewasthere%’
OR pinged LIKE ‘%belaterbewasthere%’
OR post_content_filtered LIKE ‘%belaterbewasthere%’
OR guid LIKE ‘%belaterbewasthere%’
OR post_type LIKE ‘%belaterbewasthere%’
OR post_mime_type LIKE ‘%belaterbewasthere%’;

I did some digging yesterday also. I could not find anything in my Apache access logs related to “simple-fields” between the times when I accessed it when the problem must have occurred.

I checked the MySQL database error log and there were some things on the 24th, but everything there seemed related to our backup/restore operations. There weren’t any bad queries or anything like that. Our MySQL config is set (like default) to only allow connections from localhost.

This may agree with your thought that this was a scheduled action.

So, I installed a plugin called WP Crontrol to view all of WordPress’ scheduled “cron jobs”. There were a lot of entries there, but nothing stuck out as unrecognizable.

I Google searched for that JS file URL in case it popped up somewhere else. I do see it on lots of websites and it looks like it has replaced the data in other database tables. Some Chinese characters show up after it too on website that are definitely not Chinese. I don’t know if that’s related to Simple Fields or not, but they all appear to be WordPress sites. I didn’t see any websites with info about it though.
https://boatrightmarine.com/fishing-boats-friendswood-texas-2/
https://www.benzoauto.com/listings/2017-volkswagen-jetta-1-4t-se/
https://www.brownellauto.com/inventory/

I think custom code prevention for XSS / JavaScript injection to Field Groups and Post Connections’ name’s would solve this issue. Maybe introduce HTML purifier into simple-fields plugin prior to creating Field Groups and Post Connections would do the trick? Thoughts?

Here’s the GitHub page: https://github.com/bonny/WordPress-Simple-Fields

HTML Purifier: https://htmlpurifier.org/docs

UPDATE: I also found this link that gives insight into the exact function that’s causing vulnerability.

https://www.pluginvulnerabilities.com/2019/09/16/hackers-may-already-be-targeting-this-persistent-xss-vulnerability-in-simple-fields/

• This reply was modified 5 years, 1 month ago by kjy112.

Had this on 3 older sites now. My method of fixing the sites (not the plugin) is as follows, but it does involve a bit of time and effort.

The immediate fix is to use a backup of your database, presuming that you have a recent backup. In PHPMyAdmin (or whatever db tool you use) drop all tables, then import your backup. This will roll your site back to a 100% working state, getting all your Simple Fields data back, and allow you to work on the next step.

Now you need to install the Advanced Custom Fields plugin. I use the Pro version (have an unlimited dev license and it’s worth every penny). I’ve been using ACF Pro ever since Simple Fields was abandoned, and it’s fantastic.

Now you need to recreate each and every Simple Field, in ACF. This needs to be done manually. Of course, I had a headstart as I’ve been using ACF for years now. So apart from being a bit laborious, it was easy enough for me. If you’re good with Simple Fields then you should be able to work out ACF pretty quickly – it’s more intuitive, to me at least.

Once you’ve got all your field groups sorted, you can go into each page and post editor and copy and paste the data from each simple field into it’s ACF counterpart. I dread to think how much work that could be for anyone with a lot of posts, but thankfully for me, the 3 affected sites were quite static, without a great deal of dynamic posts.

Now you’ll need to recode your template files to use the ACF fields instead of the Simple Fields. The PHP is similar and ACF has great documentation and examples on their site.

Once you have that all working, remove all the Simple Fields code from the templates, do a final frontend check to make sure all your pages and posts are working as expected, then delete the Simple Fields plugin completely.

I realise this could take a lot of time for some users, but unless some clever person out there can find an actual fix for the plugin, it’s the best I can offer.

Maybe a fix for anyone using Simple Fields that hasn’t yet had it hacked, OR anyone who has a backup of their database, taken before the plugin got hacked and is able to restore the DB after getting hacked.

According to the information given here (and posted earlier by @kjy112):

https://www.pluginvulnerabilities.com/2019/09/16/hackers-may-already-be-targeting-this-persistent-xss-vulnerability-in-simple-fields/

The problem lies in the file ‘/inc-admin-options-export-import.php’

Now, unless I’m mistaken the following should work:

comment out line 30 of that file (or even remove altogether):

add_action("admin_init", array($this, "maybe_do_import"));

then comment out everything (or even remove altogether) from line 34 through to line 99, should stop this particular vulnerability:

	function maybe_do_import() {
		
		if ( isset($_POST) && isset( $_POST["action"] ) && ( $_POST["action"] === "simple_fields_do_import" ) ) {
			
			if ("file" === $_POST["import-what"]) {

				if ( empty($_FILES["import-file"]["tmp_name"]) || ! is_uploaded_file($_FILES["import-file"]["tmp_name"]) ||  $_FILES["import-file"]["error"] !== 0 ) {
					wp_die( __("Import failed: something went wrong while uploading import file.", "simple-fields") );
				}

				$import_json = file_get_contents( $_FILES["import-file"]["tmp_name"] );

			} elseif ("textarea" === $_POST["import-what"]) {

				$import_json = stripslashes( $_POST["import-json"] );

			}

			// We have JSON contents from file or textarea
			// @todo: create function of the next part
			$arr_import = json_decode($import_json, true);
			if ( is_null( $arr_import ) ) {
				wp_die( __("Import failed: JSON data is not valid.", "simple-fields") );
			}
			
			$arr_field_groups = isset($arr_import["field_groups"]) ? (array) $arr_import["field_groups"] : array();
			$arr_post_type_defaults = isset($arr_import["post_type_defaults"]) ? (array) $arr_import["post_type_defaults"] : array();
			$arr_post_connectors = isset($arr_import["post_connectors"]) ? (array) $arr_import["post_connectors"] : array();

			$import_type = $_POST["simple-fields-import-type"];
			/*
			$import_type:
			replace
			overwrite-append
			append-new
			*/
			#sf_d( $arr_import, '$arr_import');
			
			if ( "replace" === $import_type) {
				
				// Just update our options with 
				update_option("simple_fields_post_connectors", $arr_post_connectors);
				update_option("simple_fields_groups", $arr_field_groups);
				update_option("simple_fields_post_type_defaults", $arr_post_type_defaults);
				
				wp_redirect( add_query_arg( array(
					"sf-options-subpage" => "import_export",
					"message" => "import-done"
				), SIMPLE_FIELDS_FILE ) );

				exit;

				//simple_fields_register_post_type_default($post_type_connector, $post_type);
				
			} else if ( "append-new" === $import_type) {

				// import new fields
				// i.e. fields with slugs that do not exist in current data
				

			}

			exit;

		}
	}

Be warned though – the article I’ve linked to warns of other possible vulnerabilities in the plugins code. So this may not be a strong fix.

EDIT (while my post is held for moderation): Just seen that Par, the plugin author, has replied – his post must have gotten held for moderation, and he’s basically saying the same as I have above.

• This reply was modified 5 years, 1 month ago by Steven Stern (sterndata).
• This reply was modified 5 years, 1 month ago by cokeyblokey.
• This reply was modified 5 years, 1 month ago by cokeyblokey.

Given that the author has formally abandoned this plugin and the plugins team has removed it from the repository, I strongly advise that you simply delete it from any sites on which it’s used and find another plugin. Perhaps, Advanced Custom Fields?

Given that the author has formally abandoned this plugin and the plugins team has removed it from the repository, I strongly advise that you simply delete it from any sites on which it’s used and find another plugin. Perhaps, Advanced Custom Fields?

100% agree! I’ve given a pretty good description of how to move to ACF, above.

Does the solution that @cokeyblokey suggested work?

We have over 30 old websites running Simple Fields and I need to buy as much time as I can so I can help fix (change to ACF) all of our customers websites before they get hacked. So far 3 of the websites have been hacked… =(

Thanks for the continued helpful posts here.

“Given that the author has formally abandoned this plugin and the plugins team has removed it from the repository…”

Well it’s not quite removed from the repository. The message on the plugin page is that the closure is temporary. But we’ll probably know soon enough if it will be removed.

With confirmation from the plugin author that he will not work on it and no other developer to manage it, then I do agree that a migration to another plugin is the only solution. That will definitely take some work. So to start, I’ll do the short term fix here disabling that function and renaming that file.

[redacted]

• This reply was modified 5 years, 1 month ago by Steven Stern (sterndata).