atomizer

16:21:10.228 TypeError: document.getElementById(...) is null 1 options-general.php:187:60 – followed by a link to this page

let me try it with a fresh profile and i’ll post back

@aitpro – preventing a exploit is half the battle i think – my question is; could BPS Pro assist in determining the cause of the hack – for example, let’s say i have a poorly coded plug that opens the door – can BPS help me to identify this?

thanks

thanks for your detailed comments and the clean-up link you provided

at this point i’m deciding what to do – for me, $60 is a lot of money but i am seriously considering it

thanks for the feedback – reading your forum posts now…

In general though, …

that’s the problem though – “in general” doesn’t result in a hardened WP install – for example, .htaccess should be 400, not 644, but that causes problems for allot of people when setting a permalink structure, etc.

my wp-config was 644 i think and it was written to by the bot/hacker – i now have it at 400

seems like it might be a good idea for WP to set file permissions/ownership based on whether an admin is logged in or not ???

so if not, config is 400, and if so, config is 600, etc.

Those malware scanners can only scan the source of the public portion of the site, what the rest of us can see in a browser, they can’t scan the files in your hosting account.

i used at least 3 different server-side WP plugins that should have caught this i think, including Look-See Security Scanner

however, i digress; actually one scanner – Exploit Scanner – did catch the file, but i didn’t know how to interpret the results

the way i found the file was…

1) upload a fresh WP install archive and extract it to a temp directory
2) delete /wp-includes and /wp-admin
3) extract those directories from the archive and replace the original ones
4) test one of the malicious URL’s to see if it still worked – it didn’t (404) – bingo – i now knew where to look, so i started comparing a fresh copy of WP to the directories i deleted

You may want to implement some (if not all) of the recommended security measures.

yeah, i looked at that before – the problem is, what does, for instance, “all files should be writable only by your user account” translate to in terms of Linux file permissions (400, 600, 755, etc.)? this info should be in the guide

gee, that makes me feel all warm and fuzzy ??

i use a very highly rated host (A Small Orange) and all i can say is that the tech that went above and beyond to look at my files and DB did not see any similar behavior on other accounts on the same box – that said, he missed my problem and i know shared is not the way to go, but i’m not able to admin a VPS yet, nor can i afford a managed one

the kick in the ass regarding this issue is that NOT ONE of the scanners picked up the presence of this rogue file and all of them should have – it doesn’t get any easier than that

definitely not a password issue – i can’t possibly even remember any of my passwords

another account on the same server was compromised

that’s interesting – i know shared hosting is not as secure as it could be, but how would compromising another account allow writing to files on my account?

that’s only 1/2 the problem though – the bigger question is how the file got there and how the config file could be written to (i tightened permissions on it to 400)

found the problem – in wp-includes there was a file that didn’t belong:
class-wp-init.php

and in wp-config.php:
@include_once(ABSPATH . 'wp-includes/class-wp-init.php' );

see also: https://webmasters.stackexchange.com/questions/93236/where-are-these-spammy-posts-generated-from

i’ve been at this all day and a support guy from my hosting provider, who knows FAR more than i do, spent a lot of time with it – i think i’ve gone as far as i can

i do not want to reinstall the entire site

after reading the links given in this thread, reinstalling WP, as well as 5 site scans using ClamAV, one of the Sucuri scanners, the LookSee scanner and one other one, as well as having my host look at the WP files and DB’s, i’m at a loss – al the scans show clean and i can’t find the source of the problem

my host thinks the malicious code is in my DB and he does not think it’s a server-wide issue (i’m on a shared server)

i don’t really know where to go from here

scans are coming up clean and i’m not seeing any rogue files

these urls (and there are tons of them) seem to be dynamically generated

my host uses a cache mechanism for Nginx which can be bypassed my adding ?nocache=1 to the end of a URL – if i add that param, these pages come up blank

something very strange going on but not sure what it is

i opened a ticket with my host to see if it’s a server-wide issue, but would vey much appreciate any info anyone here could provide also

@buzztone – thanks for that – i was wrongly thinking that the ‘from’ section held a variable that would be set by the person sending the mail instead of the server mail address