New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
This could mean that your server is compromised, or someone gained privileges through ex. a vulnerable script.
The configuration won't do you much at this point.
As @doghouch said, why would you be worrying about preventing it when you've already been compromised? You're a step behind.
you get it wrong, that line only applicable if you edit from WordPress dashboard.
There's a reason I have this in my TextExpander, it comes in handy often. Adjust instruction as relevant to your situation:
You'll have to go through your files one by one to find the malicious code. The proper way to deal with this is to take one of these files and run the command "stat" against it, like "stat filename", to find the modify time. Take that modify time and compare the timestamp to the website's access logs. You should find a "POST" request to another file which generated that malicious file. You may have to then take that file and do the same, until you are led back to the original compromise. If you've traced it back as far as you can and you are still not sure, take the IP address from the oldest access log entry that is clearly a malicious POST request, then run that IP through the logs. This method has always had a 100% success rate for me in identifying the root cause of a compromise. Once you identify the root cause, consider replacing any theme or plugin that may be responsible with fresh code. Make sure that the vulnerability is removed in the version you upload.
Just execute 'chattr +i header.php' from ssh.
When you say replace the theme/plugin, I hope you mean after you wipe the VM (yes, completely reinstall) and you restore from a pre-compromise backup.
While making a file immutable could be beneficial in some situations, this is not one of them. The server has been compromised; the root cause needs to be identified and patched, followed by a clean install of everything (erase and reinstall).
I do not. I assume first that the web server is not able to write anything of significance above web root, any other situation would be the exception in my experience. A privileged user with a compromised Wordpress plugin rarely justifies such excess reaction.
Definitely don't restore from a pre-compromise backup unless you've 100% confirmed the point of compromise so that you are able to prevent it.
Assumptions are always the root of all evil :-). Unless you are 100% sure of the system, and have verified every bit of code, you cannot trust it after a compromise.
Well it's not an uneducated assumption. This is the standard now in common prebuilt hosting environments and distribution repositories. I've cleaned a few thousand Wordpress sites in my day
It always sounds fancy and educated to one up a sound suggestion but that doesn't mean that the new suggestion is rooted in the common realities of the situation. I'm not new to this, I assure you.
Problem is we don't know how OP setup his/her WP site. We cannot assume that he simply didn't
chmod 777 wp-uploads, and the attacker uploaded a PHP remote shell. Secondly, because OP is asking for advice on what to do, we can assume he hasn't dealt with this before (which isn't a bad thing). Because of inexperience, however, the best thing to do is wipe, and restore from backups made pre-compromise (if they exist).That's great! It doesn't sound like OP has the same experience as you however. Unless you're offering to cleanup OP's WP site, that is...
I'm not trying to one up a suggestion. I'm merely echo'ing common security advice when dealing with a compromise.
Me too.
Which would be executed by what user? Are you suggesting that this client has modified their web server configuration to execute scripts as root? Having wp-uploads set to 777 and a shell inside of it executed by www-data (for example) does not compromise the root system unless we're talking about privilege escalation, which is far outside of character for the automated Wordpress compromises that we've been seeing over the years.
Precisely why I suggest that his environment is likely standard (not cPanel on CentOS 5 + DSO standard, but the last ~2 years standard).
This is the worst thing for an inexperienced user to do as it wipes the evidence and restores the server to a point where it is fully prepared to be compromised again, with no knowledge of how it was compromised.
Sure, if he asks.
That's precisely what you're doing. I could one-up you to say "If you don't replace the hardware under the assumption that the firmware has been compromised, you're not being thorough enough" but anyone who has spent enough time dealing with Wordpress compromises knows that there's no value in going that far with these typical, automated compromises that run through the internet these days. A personally targeted instance would be far less likely.
I'm glad this is deprecated this release cycle.
@zong11 read carefully what @jarland wrote and maybe ask him or someone else who has some experience to wprk with you directly on that issue. Try to be involved with that one by removing the issues to learn and understand what has to be done.
If you just reinstall you probably wont catch the point of failure and run into the same issues soon enough. in addition to that I'd guess you can't reliably tell which of your backups is clean enough to start with...
What if the OP doesn't know how to take the flag away? The file will be "invincible"
Need reverse with 'chattr -i header.php'.
I was just alluding to the fact that the OP may not know how, so the OP would probably open another thread about it. Thanks for preventing another help thread
Remember, 'chattr +i' is emergency action until remove hacking code and or reinstall applications with 'clean data'.
Where's our beloved OP. People give advice but he/she disappear after opening thread, like many other LEB thread.
Dont worry!!!
He/She will be back :-)
I m newbie for server actions so waiting for easier solution to avoid this... like any plugin name or else ?
The best would be that you actually post the code that's being added to this file so we can tell if it's malicious. In other cases it could be actually an already installed plugin that's making the modifications.
Nope. If you're waiting for an easier solution you need to move to managed hosting ASAP. You're done with self hosting, this event decided it for you.
you can scan all file with code scanner via http://www.mikestowe.com/2010/10/php-malicious-code-scanner.php or https://github.com/mikestowe/Malicious-Code-Scanner
these scanner only check for base64 encode string.
Torch the site, get wordpress.org/latest.zip, re-download as few-plugins as you need and check for malicious users added.
I can suggest LMD from RFXN.com or starting with grep base64 the files, or even looking for spawned processes, using their PROC ID and going to / pro c/ [PID] and using ls - al to check the symbolic link or environ file to see where it was launched from.
No matter what though, there’s going to be more files compromised and nested PHP shells.
Start from scratch, use someone like WPEngine as you need management at this point.
Note: remove blank spaces from the above, I kept triggering WAF @ CF, good ol Mod Security rules.
Damn I have been doing it wrong all these years