hacked by hacker

As stated above, work through these resources:
https://codex.www.ads-software.com/FAQ_My_site_was_hacked
https://www.ads-software.com/support/topic/268083#post-1065779
https://smackdown.blogsblogsblogs.com/2008/06/24/how-to-completely-clean-your-hacked-wordpress-installation/
https://ottopress.com/2009/hacked-wordpress-backdoors/

and make sure to harden your WordPress installation afterwards:
https://codex.www.ads-software.com/Hardening_WordPress

Thanks for these links. The problem is however related to Angela or the Smiley With No Name. When I open the smiley(image) in a new tab, the URL says this: https://stats.wordpress.com/g.gif?host=www.tarungoel.in&rand=0.959444040665403&v=ext&j=1%3A1.8.2&blog=34837231&post=0&ref=

Now the point here is this: Others with Angela Issue have reported smiley on the right/left or bottom. My smiley is just where it should not be, at the content area with no content visible at all.

After going through these links, I even tried editing the CSS Sheet but no use.

Just popping in because most routine references provided on all WP security questions include the Sucuri scanner. From personal experience I can conclusively state that Sucuri’s free scanner provides many false “clean” reports. It cannot, must not, be relied on to tell you a site is free of malicious code.

In one instance I pointed it straight at the malicious file, that is entered the full path to a known defacement script and it still came back clean.

I don’t question the effectiveness of the paid version, but I think it is unwise for experienced WordPress admins to keep citing this reference in the list of things compromised sites should use.

Ugh.. I tried the solutions posted above and all I get is a blank website now…I’ve reinstalled the wordpress and the theme, but all I get is a blank website now.

the website is https://www.disabilitytaxservice.ca

Any help would be greatly appreciated.

See https://www.disabilitytaxservice.ca/blog/

This appears to be your current issue: Fatal error: Call to undefined function language_attributes() in /home/disa8773/public_html/wp-blog-header.php on line 25

Whatever files are located in root that normally serves the blog located in the sub-directory named “blog”, probably need to be repaired. If you have something in root other than WordPress files, those need to be repaired. Reference: Using a pre-existing subdirectory install

Clayton, Thank you so much for getting back to be so quickly and taking the time to respond. Being in business for myself and being a do-it-yourself kind of person is stressful enough, without these major issues arising.

Everything works again. I honestly, can’t thank you enough. I’ll actually be able to rest easy tonight instead of staying up troubleshooting.

Thank you!!

1. HostPapa has quietly set the permissions on all wp-config files to 600 (rw——-)
– This most likely means that the hackers were somehow able to access wp-config files across the server once they compromised one account if the files were word readable.

2. By Default a world readable config file 644 (rw-r–r–) should not be an issue because the home directory of each account is supposed to have basedir protection enabled and be inaccessible by any other user.

3. NetRegistry (another host who got hit with the same “hacked by hacker” hack) has indicated that once one account on the server got compromised (through a legitimate WordPress vulnerability) the hacker was able to use a Cpanel symlink issue with .htaccess files to read the wp-config files of every other account on the server.

This Cpanel issue is discussed in detail on the Cpanel forum and if you scroll to the last couple of days you can read posts that are probably from HostPapa or NetRegistry admins who describe exactly what happened.

https://forums.cpanel.net/f185/how-prevent-creating-symbolic-links-non-root-users-202242.html

NetRegistry (another host who got hit with the same “hacked by hacker” hack) has indicated that once one account on the server got compromised (through a legitimate WordPress vulnerability)

*Jan sets phasers to SKEPTICAL and aims at NetRegistry*

I’m all for hosts saving face (that has it’s limits BTW) but an insecure host who is Doing It All Wrong™ is not a WordPress vulnerability.

If they or anyone have a legitimate proof of concept exploit for the current version of WordPress then they really need to report that to security [ at ] www.ads-software.com as explained at this link.

As always, a server is only as secure as it’s weakest script. :/

@pcsoko

You’re welcome! The site looks great and it all seems to be running smoothly again.

As always, a server is only as secure as it’s weakest script. :/

Well… that’s not entirely true. ?? In many hosts all of the users run under a jailed environment, where one account getting hacked does not affect the others. What is going on with these hosts is not a script vulnerability. Even if there were some accounts running older insecure versions of WordPress, using Bing’s cache I was able to verify that many that got hit were running 3.4.1 or 3.4.2 when they were hit.

What is going on with these hosts is not a script vulnerability.

We may have to agree to disagree on that. I agree that if the sites had been correctly sandboxed on the server, the hack wouldn’t have been so widespread. But the hackers gained initial access via just 1 insecure site – maybe someone using an old version of WP or a theme with an old insecure copy of something like tiumthumb. Once in, the poor server config meant that they were able to then access all sites directly – irrespective of what version of WP they were using. By all counts, some Joomla sites got hit too. so it looks like, as soon as the hackers had server access, they went after all of the big open source run sites.

But just one old or insecure site gave them the access in the first place. ??

But just one old or insecure site gave them the access in the first place. ??

You don’t know that though. You stated that a server is only as secure as it’s weakest script, but it doesn’t take a script vulnerability for someone to access a shared server. It could be someone with ftp access getting a virus on their machine, it could be a weak password, a malicious web developer angry at not getting paid… or hell, someone could just sign up for a new account on the same server. These are shared hosting accounts where anything could happen to one single account, they should all be firewalled from one another, period.

@mvandemar

As always, a server is only as secure as it’s weakest script. :/

I can only speak for myself here, but I’m inclined to interpret that in a broader context, rather than focusing only on whatever scripts reside in an public_html directory.

I think it might apply perfectly in discussions where security issues are likely to center on server and service administration, and I think your last statement may add support to that thought.

These are shared hosting accounts where anything could happen to one single account, they should all be firewalled from one another, period.

Wouldn’t those be hosting and server administration issues – rather than web-app vulnerability issues?

Wouldn’t those be hosting and server administration issues – rather than web-app vulnerability issues?

That was my point Clayton. Netregistry is blaming their clients and HostPapa is blaming WordPress, when in reality both of them apparently have security issues outside of what can be controlled by the client. The statement “As always, a server is only as secure as it’s weakest script. :/” was a quote, esmi was the one who said it originally. ??