Site loaded with backdoor scripts and wp-login expoit?

Aloha Seacoast,
I am truly sorry to hear how upset you are. I have had a lot of success and only a few misunderstanding with respect to this new addition. I am very disappointed to hear that you feel your hour was wasted. This is a free plugin that I donate my time to maintaining and I grateful to those who are satisfied enough to make a donation. I cannot turn back time for you but I am more than happy to refund your donation if you made one.

If your read this entire thread you must at least understand how important it is to offer a fix for this threat. I personally witnessed my patch successfully throwing off active attacks, thereby allowing the server to return to it’s normal workload. I still see these attacks in my own server’s log files and rest easier knowing that it no longer effects my system performance. I hope you can feel that added sense of security too and maybe then it won’t seen like your hour was a complete waste.

I would also like you to know that I take feedback very serious. If you agree with Jan that it is inappropriate to label this vulnerability as an “Exploit” then I would like to ask if you would be willing to take a little more of your time and offer a suggestion as to how I could improve the clarity of this threat when it is detected. I know that this may be asking too much if you are already pissed-off at me, but think of how it could help someone else to not have the same experience you did.

Every improvement I have made has been inspired by a user’s experience and feedback. I believe that is what open-source and free software is all about. Please feel free to contact me directly if you like: eli at gotmls dot net

Mahalo, Eli

Just a follow up – the hour was not wasted using your plugin – it was wasted researching what was supposedly wrong with wp-login.php (nothing actually) – hence my comment!

Thanks for the follow-up. I suppose, based on your short answer here, that this is as far as you want to take this.

I will leave you with my most sincere apologies for wasting your time, and my assurance that I will put more explanation into this patch so that everyone will know why the wp-login file comes up on the scan.

If anyone has a better label for this, to replace the word “Exploit”, please post your suggestions.

That seems to be the proper thing to do. I suggest you make this an optional module of your plugin with a very detailed explanation of what it will do (modify a core WordPress file). And about that…I also thought plugins (listed here) were not supposed to change core WordPress files…ever…or they did not muster. Has that changed?

I use Sucunia when I review a product for known vulnerabilities and how these are being exploited. Until you can note with a major security firm such as Sucunia that wp-login.php in WordPress 3.5.1 has a known vulnerability that is being exploited in the wild, it is just plain wrong, IMHO (and many others), to use that terminology.

Also, the scan I did was on a site that I had just uploaded /wp-admin/ and /wp-includes/ from a fresh download. Your ‘tool’ notes that I should check the files I am linking us all to here.

I have to assume all using WP3.5.1 are getting the same results (Red Flag for wp-login.php and Warning on the files noted)…seems (at best) to be a scare tactic. (Anyone else have some results to share?)

I realize this topic has gone off basis a bit, but strongly encourage you to modify use of the term ‘Exploit’ as being used in your current plugin version. And, since there is no exploit, there does not need to be a similar term applied.

That all said, continue your hard work on keeping WordPress clean. I am sure many appreciate it

Ouch! I am deeply offended that you think the Potential Threats is “(at best) a scare tactic“. You are right that the core files should not be in there if they have not been tampered with though. Most of the files in that list are there because they use the eval() function, which is a core component in almost every hack I see, although it is also used legitimately in many of these files. You can white-list these files so they don’t come up in the scan. I have only just perfected the ability to put out white-list updates in my definition updates. I have already white-listed some of the core WP files but obviously not all of them. I will work on add the rest of these core files today.

As for the WP Login threat, what term would you use to describe this vulnerability?
Not only is it susceptible to a brute-force attack (like any other login page) but such attacks are prone to overloading the server. This is the only reason I created this patch and I feel there is still a real need for it. If not “Exploit” (or any similar term) then what?

I will be releasing a plugin update by the end of the week and I would like to have this resolved in that release.

I really have nothing further to add. Again, your work is a good thing, it was just those parts of the plugin I object to.

As for my use of the term ‘scare tactic‘, step back from what you do all day long and be a layman. It’s scary to anyone not overly familiar with these topics to see this (which we know most are not and is WordPress’ biggest security problem, IMHO)…

I don’t have any further suggestions on this.