Robert

You are correct. I found the issue. The Sucuri plugin has a 1-click hardening feature that restricts access to /wp-content to prevent direct PHP script execution via .htaccess in that directory.

This caused the GET on superproxy.php to fail:

GET https://mysite.com/wp-content/plugins/google-analytics-dashboard-for-wp/realtime/superproxy.php

with the error:

Forbidden
You don’t have permission to access /wp-content/plugins/google-analytics-dashboard-for-wp/realtime/superproxy.php on this server.

I enabled access to wp-content via the Sucuri “Revert Hardening” button (i.e. delete the .htaccess file) and Real-Time Reports now work fine.

I’ll refine the .htaccess rules to allow access only to superproxy.php.

Thanks!

The Google Chrome Chrome console displays a warning and an error:

event.returnValue is deprecated. Please use the standard event.preventDefault() instead.

Failed to load resource: the server responded with a status of 403 (Forbidden) https://mysite.com/wp-content/plugins/google-analytics-dashboard…<token value>&key=<key value>

Seems the problem is the 403 Forbidden error. My site is hosted by WPEngine.com which disables certain PHP functions for security. I’m also running the Sucuri Premium WordPress plugin. Perhaps the hosting environment or Sucuri is blocking a call?

Thanks for working on Sunday!

I too had a problem with Google Apps Gmail and “Email could not be sent”.

My website is hosted on it’s own domain and Google Apps MX records are configured in DNS. Google Apps Toolbox Check MX reports everything is fine: https://toolbox.googleapps.com/apps/checkmx/

My hosting provider (WPEngine.com) does not offer e-mail services, which if it did can cause other well documented problems because mail will be sent to the hosting provider’s local mail servers instead of gmail for the domain. See the Google Apps Forums for more info.

Two-Step Verification is enabled via the Gmail Security settings (Gmail Account -> Security -> 2-step verification).

Configured Easy WP SMTP as so:
From Email Address: [email protected] <– alias setup in Gmail
From Name: WordPress
SMTP Host: smtp.gmail.com
Type of Encryption: SSL
SMTP Port: 465
SMTP Authentication: Yes
Username: [email protected] <– real user in Gmail
Password: < password used for https://mail.google.com >
Enable SMTP Debug: Checked

Sending test e-mails via the “Test & Debug Settings” section of the plugin failed.

I found the problem in the “SMTP Debug:” output panel. The Google Mail server said “Application specific password required” or something very similar.

Woo Hoo!

I logged into the Gmail admin@mydomain account via my web browser, navigated back to the Gmail Account -> Security -> 2-step verification and created a new application password for “WordPress”. Pasted the application specific password into the plugin:
Username: [email protected] <– real user in Gmail
Password: <application specific password for WordPress>

and e-mail works fine! Sent various test e-mails to Google Apps mail, regular gmail and external domain accounts. No problems!

I now receive WordPress comment notifications!

Ticket #22708 has patch files issued:
https://core.trac.www.ads-software.com/changeset/23016
* wp-admin/js/post.js (4 diffs)
* wp-includes/class-wp-editor.php (1 diff)

with a follow-up change here:
https://core.trac.www.ads-software.com/changeset/23017
* wp-includes/class-wp-editor.php (1 diff)

The patches perform an sanity check on the ed_size value and sets the post editor to 5000 pixels high if ed_size > 5000. That’s almost 5 screens high on my 1920w x 1080h monitor resolution and very annoying.

I installed the new files on my WP 3.5 staging environment and tested with FireFox and Chrome. The editor size bug remains and the post editor is continually reset to 5000 pixels. My workaround was to change the ed_size code from 5000 to 500 pixels in the above source code files. If you decide to make changes on your server, make copies of the original .js and .php files and be careful! e.g.
a. copy post.js to post.js_original
b. upload the patched post.js
c. do the same for class-wp-editor.php
CPanel -> FileManager is very convenient here. This assumes your hosting WordPress on your own server and won’t work if your site is on WordPress.com.

I opened a new bug ticket https://core.trac.www.ads-software.com/ticket/23042 because the underlying ed_size bug isn’t fixed.

I confirmed this is a bug in WordPress 3.5 that was found during development and the developers thought the bug was fixed. I ran a test while watching the wp_usermeta -> wp_user-settings -> ed_size= value in PhpMyAdmin and viewing the cookie wp-settings-58, Content: ed_size.

In brief, the ed_size field sets the post box editor height in pixels and the value is saved in a browser cookie. ed_size was being set to 33339999997615814 pixels, the actual value will vary somewhat. Setting the value to something reasonable like 600 pixels in PhpMyAdmin won’t survive a post update.

Reference:
Ticket #22708
Post edit page may become almost unusable and textarea cannot be resized
https://core.trac.www.ads-software.com/ticket/22708

I updated the ticket with the test sequence, database and cookie values.

We’ll have to wait for a WP 3.5 patch.

I’ve tried the latest versions of Chrome and FireFox on Win7. No joy.

Wonder if there’s a database parameter that can be manually set via PhpMyAdmin?

+1

The Post Editor on WP 3.5 automatically expands to the full length of the post. Dragging the triangle control in the bottom right corner of the editor pane to make it shorter isn’t remembered in both Visual and Text mode. A real annoyance!

I installed Socialble v4.3.3.2 and have the same problem even though the More button is disabled, i.e. not used in my blog. The 32px by 32px more.png image file is missing in that directory per the plugin .zip release content.

The problem is it junks up the server logs with tons of 404 errors.

My solution is:
* Copy the more image on the Plugin Settings page using mouse Right Click -> Save Image As…
* Open the more.png saved image in Windows Paintbrush.
* Resize it to 32×32 pixels (disable the keep fixed aspect ratio)
* Save it to more.png
* Upload the more.png file to /wp-content/plugins/sociable/images/option1/32/more.png
* Check the file permissions are the same as the other icons in that directory. CPanel -> FileManager is really easy here.

This gets rid of the 404 errors although the more icon looks pixelated. You could easily fix that by some extra effort in Paintbrush but I just wanted to fix the 404 problem.

Overall, I like Sociable better than the super-options Share-and-Follow type plugins because it’s simpler and doesn’t drag in a lot of extra stuff that can complicate security and server load.

OK – the dust has settled and my WordPress site is now clean.

My site was hacked by the Filesman (https://labs.sucuri.net/db/malware/backdoor-phpfilesman02) PHP backdoor which enables a hacker to install, modify and delete nearly ANY file on the WordPress site; PHP and .htaccess files were targeted in my case.

Here’s how the hack works:
1. The hacker gained access to my site via one of at least four or maybe five vulnerabilities that have been documented and since fixed over the past 12 months in a variety of plugins, theme (paid, not free) or TimThumb (thumb.php). Because there’s no central mechanism or clearinghouse that I’m aware of for receiving notifications of vulnerabilities and fixes across all themes and plugins, my site was exposed for months.

2. Fileman backdoor installed by the hacker. Not in once place, but many. Sometimes it was a new file masquerading as a legitimate file with a similar name, other times new code added to an existing PHP file in WordPress, the theme or plugin.

3. The hacker used the Filesman backdoor to insert the “drive-by download” malware code in a number of WordPress, theme and plugin PHP files. My .htaccess was also modified to allow foreign access. My site was acting as a “Typhoid Mary” (https://en.wikipedia.org/wiki/Typhoid_Mary) vector to infect website visitors.

4. When someone visited my site, the infected PHP file injected the iFrame in the web page code that contained Javascript malware and links to trojans pulled from overseas websites.

5. Hopefully, the web site visitor’s anti-virus software will block the drive-by trojan to prevent a PC infection. If not, the trojan infects the visitor’s computer – which is the ultimate goal – to do any of a number of things such spyware to steal online banking passwords, taking remote control of the PC, distribute spam, etc.

My home desktop was infected by the JS:Kryptik-D. The website malware further was identified as the Backdoor:PHP/Seqangle exploit. McAfee and MalwareBytes missed the Kryptik-D trojan in the drive-by download. Microsoft Security Essentials, Microsoft ForeFront and Avast Internet Security all detected, removed and blocked future downloads of the trojan. This isn’t a comment on the anti-virus programs, rather the arms race of constantly updating virus signatures. I am now running Avast Internet Security and really like it.

The difficulty of removing the WordPress site malware is you cannot rely on looking at file dates for changed files because the PHP malware uses programming calls to reset the infected PHP file back to it’s original date.

The only way to detect the infected PHP files is to:
A. Manually examine each file if you’re an expert and know what to look for. One of the PHP malware infected files had a nicely commented and formatted function to blend in with the standard WordPress code! And that new function did not contain obfuscated code.

B. Compare file checksums (binary equivalents) and file sizes against the known “clean” base release of WordPress, the theme and plugins. Impractical to do without automated tools.

C. Examine the MySQL database for infections – a very cumbersome effort due to the large database size and formatting of a SQL dump. A security expert is needed here.

=======

The solution was multi-layered approach:
1. Hire a security professional to diagnose and clean the WordPress site. An examination of the raw server logs and automated scan tools are essential.

2. Install a WordPress firewall plugin and server-side scanning script to monitor for all changes and block bad IP addresses.

3. The security professionals hardened .htaccess and other items to prevent access to files, execution of PHP in certain directories, obtaining directory listings, etc.

3. Change ALL passwords: CPanel, MySQL, WordPress.

4. Delete any plugins and unused themes that you can do without to reduce the possible set of vulnerabilities and total file count on the server. Reducing the file count makes the “finding the needle in the haystack” situation easier. When I look at some of the plugin PHP code and see URLs to Amazon Web Services (AWS) and remote web sites, it makes me cringe.

5. Check the Security and Firewall logs daily for suspicious activity; changed files, successful & failed logins, etc.

The WordPress firewall constantly blocks access from “bad” IP addresses (hackers, spammers), shows that hackers are constantly trying to guess the Admin WordPress password (delete the Admin user now if you already haven’t!), trying to access now-fixed exploits in WordPress and plugins, and execute PHP files remotely (e.g. https://www.mysite.com/wp-includes/somefile.php).

My advice is:
* If you haven’t signed up with a WordPress security service and installed a WordPress firewall, then you’re either already hacked and don’t know it, or it’s just a matter of time before you are hacked. The analogy is not running an anti-virus program on your home computer.

* Use plugins very sparingly and check the change logs regularly.

* Check the change log, blog or Twitter feed for your WordPress theme for any notices on a regular basis.

* Make regular full site backups and save these offline for long term storage. My hosting provider’s nightly, weekly and monthly backup service (a premium service) was very helpful.

Hope this helps.

WeWatchYourWebSite.com cleaned up the PHP infection on my site in 1 day. Very helpful and explained what was going on.
See this Support post for details: https://www.ads-software.com/support/topic/iframe-injection-attack-wp-342-httplarvalpro?replies=7

Hackers infected my website with several backdoors. It was scary to see, the hacker would simply point the web brower to a the full URL of an infected PHP file, type in a user name and a file management dialog box displayed to upload and delete files. The hackers could grab wp-config.php and view the MySQL DB user name and password, too. Whenever I reinstalled WordPress, an infected PHP file would simply reinfect WordPress.

I subscribed to the 6Scan Security firewall plugin (www.ads-software.com/extend/plugins/6scan-protection/) and We Watch Your Website (WeWatchYourWebsite.com). 6Scan Support identified the hacked files and have been amazingly helpful! WeWatchYourWebsite performed the malicious code cleanup within a day and has done an outstanding job.

I believe the hackers got in through an existing backdoor in an older and unsupported advertising plugin, but I may never know for certain. From there the hackers infected various PHP files with lots of obfuscated PHP code that looks like a monkey on a typewriter: “JTkVULCBTT0NLX1NUUkVBTS….” that goes on line after line. The obfuscated code is converted to executable PHP through base64_decode and various string functions with tedious loops and counters to hide what it’s about. Even the base64_decode() function was in a string “b.a.s.e.6.4._d.e.c.o.d.e” to thwart grep searches.

The purpose of the hack was not to necessarily damage my website, rather to load malware into the rendered web page from hacker sites to install a trojan on the visitor’s computer. The trojan could to any number of things, including spyware and spreading new infections. I scanned my local computer with the latest McAfee and MalwareBytes; nothing was found. On the advice of 6Scan, I downloaded the free Microsoft Security Essentials which found two spyware trojans and removed those. I’ve since purchased Avast Internet Security Suite on the security experts advice. Wow! Avast is so much more robust.

I think the semicolon page display was a screw-up on the hackers part that alerted me to the problem. The web site checkers (urlvoid.com) all reported my site clean before- and after the hack.

FireBug in FireFox will display the malware code if you inspect the page source and have an idea of what to look for.

Lot’s of bother changing all my website and hosting passwords, including my online banking and other accounts.

The services provided by WeWatchYourWebsite and 6Scan are very affordable and go way beyond the WordPress Hardening Recommendations – which is still a necessary step.

My site now loads much faster because it’s not requesting malicious code from the hacker sites.

Going forward I’ll stick with WeWatchYourWebsite and 6Scan firewall for prevention and notifications of suspicious activity. Now that I understand what they do, I won’t leave home without it.

Here’s what I’ve done so far:
1) Did a complete file and database restore from a weekly site backup.
2) Changed all passwords: MySQL, WordPress login, FTP, CPanel, etc.
to really long alpha/numerica/special character random passwords.
3) Changed all my WordPress Secret Keys using the online generator:
https://api.www.ads-software.com/secret-key/1.1/salt/
4) Reinstalled WP 3.4.2
5) Updated a couple of plugins (minor dot release upgrades).
6) Verified all directories are set to 755 and files to 644.
7) Double checked .htaccess and wp-config.php permissions.
8) Verified .htaccess and wp-config.php are still protected by:
<Files .htaccess>
order allow,deny
deny from all
</Files>
9) Installed the 6Scan Security plug-in with the monthly paid subscription for the WordPress firewall features. 6Scan only reported 3 minor vulnerabilities during the initial site scan. I’m hoping the firewall features will prevent the iFrame injection hack, etc. Installation was a breeze and the dashboard is user-friendly. Enabled automatic e-mail alerts, failed login lockout timer and all firewall options.

So far (only ~1 hour since all the updates) the site is working fine.

Later, I plan to run a file diff compare on the old site versus the new site to see if anything turns up.

BTW – I have a dedicated IP and SSL certificate. I’m the only active login account and setup WP to force HTTPS sessions. My SSL certificate expired earlier last week because the automatic renewal & install somehow failed. I was running for a few days on an expired certificate until my hosting provider tech support manually installed the new certificate. Wonder if that could have opened a vulnerability window?

Thanks for the help.

As of this morning, the iFrame injection is back. This is the full HTML when my page loads showing only the semicolon. Notice the URL has change from https://larval.pro to https://lennium.pro:

[ Redacted, please do not post that here ]

Looking for help to isolate and remove this hack.

Thanks

Thank you very much for the advice and site checker links. Sucuri, Unmask Parasites and Google all return a clean bill of health for my WordPress site.

I applied the WordPress Hardening advice early this year, well before the problem; I suspect a plugin to be the problem.

I seem to have solve the problem by disabling several popular plugins and reinstalling WP 3.4.2. The site looks good now from several computers and web browsers (FireFox, IE and Chrome). I also changed my CPanel and FTP password to a really long randomized string that even I can’t remember without saving to an offline file.

Bluehost.com Support said my site was having “CPU Throttling” issues – the CPanel report was showing up to 200 seconds per hour. After the corrective actions I’ve had almost no CPU Throttling issues. My website loads way faster now, too.

I will restore a web site backup from yesterday and redo today’s corrective actions one-by-one to isolate the problem.

I used Firebug (https://getfirebug.com/) in FireFox 3.0 to “Inspect” the unresponsive All In One SEO postbox control on the WordPress Edit Post page. This helped me locate the postbox code in the SEO php code.

The workaround is to:
1. Deactivate the All In One SEO Pack plugin.
2. Edit the SEO plugin code from the WordPress plugin
management page.
3. Remove the ‘closed’ option on the postbox class.

Change the original code from class=”postbox closed”:

<?php if (substr($this->wp_version, 0, 3) >= ‘2.5’) { ?>
<div id=”postaiosp” class=”postbox closed”>

to just class=”postbox” as shown below:

<?php if (substr($this->wp_version, 0, 3) >= ‘2.5’) { ?>
<div id=”postaiosp” class=”postbox”>

This defaults the SEO postbox display in expanded mode showing the various input controls. I think the default display mode should be expanded instead of hidden anyway.

4. Reactivate the SEO plugin.

I verified the fix works by inputting the SEO options for a new post and viewing the HTML source from the web browser, which contains the following HTML entries:

<!– all in one seo pack 1.4.6.15 [211,308] –>
<meta name=”description” content=”Water dripping from the ceiling was traced to leak from the upstairs shower/bathtub. Steps for finding and fixing the leak are explained with photos.” />
<meta name=”keywords” content=”access panel, bathtub drain, ceiling leak, drop ear elbow, drywall, finding a shower leak, how to, inspection and repair, leaky bathtub, maintenance panel, pipe joint compound, plumbing, rotozip, shower head, shower valve, teflon tape, water stain, wet wall,bathtub drain,ceiling,drop ear elbow,drywall,finding a shower leak,how to,inspection and repair,leaky bathtub,maintenance panel,pipe joint compound,plumbing,rotozip,shower head,shower valve,teflon tape,water stain,wet wall” />
<!– /all in one seo pack –>

Why the above HTML comment says version 1.4.6.15 I’m not sure as All In One SEO Pack shows ver 1.4.6.16 on the WordPress “Manage Plugins” page.

I verified the SEO form data I entered is retained for the newly updated post and as well as my older posts.