WordPress.org

Ready to get started?Download WordPress

Forums

Anti-Malware (Get Off Malicious Scripts)
[resolved] Site loaded with backdoor scripts and wp-login expoit? (22 posts)

  1. Treebeard
    Member
    Posted 1 year ago #

    A friend asked me to help him speed up his site, said it was running really slow, so I installed Anti-Malware and the scan shows a TON of backdoor scripts (all related to WishList Member, probably every file in that plugin, it would seem), along with that wp-login exploit. I've never seen this many backdoor scripts come up before on any of the sites I manage, is it possible the site may just be showing those files because it's a membership plugin? I can't believe all those files are backdoor scripts, there must be something just triggering it?

    Also wondering what that wp-login exploit is all about, it's been showing up on every single site I run a scan on, even fresh installs. Is that something to worry about? Why would that file be an exploit on a fresh install?

    I'm afraid to run the Automatically Repair button on any of the files, because it's a live site and I don't want to run into any problems with the membership plugin, so figured I'd check with you first and see if you've heard of this one yet.

    Thanks in advance~

    http://wordpress.org/extend/plugins/gotmls/

  2. hamburg300
    Member
    Posted 1 year ago #

    same here, I got "Found 1 wp-login exploit" on EVERY single installation (different web hosts).

    I am pretty worried and need a fast answer..

  3. Eli
    Member
    Plugin Author

    Posted 1 year ago #

    I have received many inquiries as to why the wp-login.php file is flagged as an WP Login Exploit on every install of WordPress, even brand new installs of the most current version. This is simply because WordPress has no built-in brute-force protection and it’s login page is exploitable. It has been clearly demonstrated through the widespread attacks on login pages around the world as of late that it is not only vulnerable to password cracks via brute-force but it also has been shown to overload and bring down a whole server if the attacks are too numerous. That is why my patch also prevents the loading of the WordPress bootstrap if a brute-force attack is detected so that your server’s resources are not tied up just telling hackers if they guessed the right password or not.

    I hope this helps answer your questions about this new threat and my approach to solving it.

  4. @Treebeard You've posted on this topic before and with a different plugin. It may be that your systems have been compromised, either way you should consider locking down and delousing those installations.

    If those are false positives (a little md5sum comparing to the original files from the source should rule that out) then you'll still have a clean and hardened installation.

    This is simply because WordPress has no built-in brute-force protection and it’s login page is exploitable.

    A little clarification here: WordPress, like any system that has a userid/password login, is vulnerable to brute force attacks. That attack comes in the form of try one userid/passwd combination, fails, try next, fails, etc.

    Even systems that wait before letting you login can get broken into slowly by poor passwords and using the old default admin account. It's one of the reasons 2 factor authentication is an attractive solution.

    When brute force attacks recently became a onslaught this post was put up.

    http://wordpress.org/support/topic/brute-force-attacks-and-wordpress?replies=2

    Which points to some very good advice in the Codex.

    http://codex.wordpress.org/Brute_Force_Attacks

    If you want to install one plugin from this list then I recommend this one.

    http://wordpress.org/extend/plugins/limit-login-attempts/

    That plugin alone does an admirable job of locking out attacking IPs for a period of time and notifying you of the attempts.

  5. Treebeard
    Member
    Posted 1 year ago #

    Thank you for responding, I have been keeping up with those file Repairs. I still wonder about the WislList Member issue. It showed 188 files, and I unchecked all of them and attempted to repair the wp login, and the site logged me out, and the login form appeared in the lightbox so I logged in and all the files were checked again. I ended up repairing them accidentally and now shortcodes are all over the frontend.

    Is there a way to restore files after they were repaired?

  6. First thing to do is hardened your installation and attempt everything you can to make sure you've closed the door that the attackers came in by.

    It's an often quoted list of links but they really can help you get a handle on your situation.

    You need to start working your way through these resources:
    http://codex.wordpress.org/FAQ_My_site_was_hacked
    http://wordpress.org/support/topic/268083#post-1065779
    http://smackdown.blogsblogsblogs.com/2008/06/24/how-to-completely-clean-your-hacked-wordpress-installation/
    http://ottopress.com/2009/hacked-wordpress-backdoors/

    Anything less will probably result in the hacker walking straight back into your site again.

    Additional Resources:
    Hardening WordPress
    http://sitecheck.sucuri.net/scanner/
    http://www.unmaskparasites.com/
    http://blog.sucuri.net/2012/03/wordpress-understanding-its-true-vulnerability.html

    Is there a way to restore files after they were repaired?

    Whenever possible you do not want to repair files, you want to get new ones from the source and delete the hacked ones. It's just safer that way.

    Some files that you've created and uploaded can't be gotten that way so if you can locate an older backup of those files then restoring those might be best.

    If that's not available then you can of course repair files. But it's tricky and some backdoors get hidden in directories that you can easily overlook.

  7. hamburg300
    Member
    Posted 1 year ago #

    I installed Limit Login Attempts successfully. It still shows wp-login exploit.

  8. esmi
    Forum Moderator
    Posted 1 year ago #

    Did you read Jan's first post above? In both his & my opinions, this plugin is overreaching itself somewhat to label wp-login.php as a "WP Login Exploit" - although I am sure its author would not agree.

  9. Treebeard
    Member
    Posted 1 year ago #

    This is all super helpful, thanks everyone! These sites that I posted about here and in a similar situation in another post, they're not websites I designed, I'm just here to clean up. It's been really wonky trying to figure out where the hacks are coming from, I'm going to check out all the links Jan posted. I've never really figured out how to tell how hackers get in, so hope that helps. The sites I'm trying to clean up have plugins installed that I'm not familiar with, and some that are abandoned, so I've already contacted them and told them those plugins are risky. I try to sell them on a security package (because it takes time to harden and clean up a hacked site) but knowing how they got in would be excellent.

    Thanks everyone!! You guys are AWESOME!

  10. Eli
    Member
    Plugin Author

    Posted 1 year ago #

    I can clear up a few points here but first I want to say thanks to Jan for all the good suggestions and links. Your incites are thoughtful and truly helpful.

    to Treebeard: As I have just discovered today, that WishList Member plugin is in-fact ok, and I am confirming it's a false positive. I am working on white-listing it now. Thanks for bringing it to my attention.

    There is actually a built-in way to restore files that have been mistakenly cleaned/fixed. Just go to the View Quarantine page and check the boxes by the files you want to restore, then click Restore.

    And now let me clear up the "WP Login Exploit" issue. Over a year ago I labeled TimThumb as an Exploit because it could be used to place malicious scripts on a host site without any credentials. My plugin was made to find these vulnerabilities and automatically fix them by upgrading the files to a new patched version ( and also remove the injected malicious scripts). I came under fire for my bold, pro-active solution at that time too. But my solution was working and highly appreciated by my users, so stood my ground and helped thousand of people get their sites cleaned up and protected.

    So now it comes again and I must defend my bold actions and Exploit label again. I understand your agree with the defense of the core WordPress login page (Any page that prompts for a login is susceptible to brute-force attack, it's true) but there is one crucial point that has missed here that tipped the scales for me and propelled me into pro-active prevention more once again. You may have heard of the extremely high volume of brute-force attempts targeting WordPress login pages have sprung up over the past month. This was a sudden onset of a wide-spread attempt to gain access to WordPress sites around the world. Again I would agree that this SHOULD NOT be a problem IF you have a strong password. However, it was a problem for servers hosting WordPress sites, even if the login attempts were all failing!

    • Here is the (possibly unintended) problem for WordPress users (even if you have a strong password) that no other plugin I know of has yet overcome (other than mine):

    The first thing the wp-login.php file does is load the WordPress bootstrap (wp-load.php).

    • Why is this a problem:

    Because, when bombarded with thousands of login attempts per minute (even failed ones), the loading of WordPress creates an overhead that has proven to be too high for many server under those conditions. You may say "well, your just not using an adequate server then". Well, I have seen first have the effect of these attack on servers from a variety of popular hosting providers like ixwebhosting, hostgator, godaddy, bluehost, and even some private VPS machines. This attack was crippling the servers and every site hosted on them. Only by being "out there in the field" when these attacks started and my clients granting me full access to their servers was I able to determine the cause of the server overload. My first fix was to rename the wp-login.php file and I made a script and posted a blog entry on how to do it. Many of the larger hosting companies globally blocked all access o the wp-login.php URLs while they worked on a way to endure these attacks and keep there servers running.

    • My current solution:

    My plugin can find the "Exploitable" files and patch them with an open-source code solution that loads before the WordPress bootstrap and successfully prevents the server overload from occurring. It simply kills the login attempt (prebootstap) if certain condition match this specific type of brute-force attack that has had this effect on all these server.

    So there it is. I hope you were patient enough to read through my explanation completely. I want to point out that I love WordPress, I'm a big fan and huge supporter of open-source projects. I have donated countless hours to helping people around the world to un-hack their sites. I help anyone who contacts me and, while I always welcome donation for my plugin, I do not require any to pay to use my plugin. Not have I ever turned down anyone's request for help due to lack of donation or ability to pay. I have even helped a lot of people that paid someone else (like $89 to sucuri) to get them clean and they are still infected and getting no more help, then I come along and do everything I can to help and usually get them all clean.

    I hope you can overlook the blemish that my Exploit label may create and see that I am here to help WordPress become better, because I believe in the WordPress platform.

    I'd be happy to hear any followup comments on all this and I will always support my plugin and any ideas and suggestions that make it better.

    Aloha to all,
    Eli Scheetz

  11. Treebeard
    Member
    Posted 1 year ago #

    NO WAY!! this is awesome! I was able to restore everything, and all is well. That is one of the best features of this plugin!

    I do have 1 Feature Request, if I may: Need a way to select more than 1 files easily. I selected each box, 188 files, and Shift didn't work LOL! A very small price to pay though, not a big deal. Just so happy it works so awesome!

    And I feel better knowing you keep up with all the security threats, that's a great relief.

    Thanks Eli :)

  12. Treebeard, I'm glad that worked out for you but if you've really got a compromised system then you still need to go through those links. Repairing files doesn't close the door that the attacker got in via.

    Now if you'll excuse me while I go off topic for a couple of minutes. ;)

    @Eli, thanks for supporting WordPress users and I am absolutely sure that many people appreciate your efforts. Those installations that you've deloused are better off for your efforts.

    I have a problem with your labeling something as an exploit when it's not.

    tl;dr: labeling something an exploit when it's not does a disservice to your users and just propagates the falsehood that "WordPress is insecure".

    Over a year ago I labeled TimThumb as an Exploit because it could be used to place malicious scripts on a host site without any credentials.

    That's because older versions of TimThumb were exploitable. If you had the bad version then (as you said) someone else could use that to place scripts on a server with that bad version. TimThumb was a vector to get additional bad scripts onto an installation. After that the attacker could and did go nuts on that exploited system.

    If that scenario exists with wp-login.php or any WordPress core file then right now send the details to security [at] wordpress.org so that this can be looked at and addressed.

    http://codex.wordpress.org/FAQ_Security

    But from what you've written above that simply is not the case.

    My plugin can find the "Exploitable" files and patch them

    What you are attempting to do is patch WordPress* to mitigate what you see as a DoS vector.

    DoS is harmful in that it prevents legitimate requests from being processed by your WordPress installation but do not classify it as an exploit because it's not.

    DoS is background noise and any troll with ab2 can flood a web server with requests to bring it down. Add a zombie bot to make it distributed (DDoS) and you'll have one upset WordPress user and a set of ticked off hosting people.

    But that's a different scenario to an actual exploit and to label something as an exploit like that without it actually being compromised? You're doing your users a disservice.

    Offering your plugin users an option to mitigate what you see as a weakness is admirable and I commend you for that. But when you label something as an exploit and it's not then that is not a good thing.

    *NOTE: If you actually modify WordPress core files then that's a different and not good problem too. I have not looked at your plugin and I am assuming that you do not modify core files.

  13. Eli
    Member
    Plugin Author

    Posted 1 year ago #

    Jan,
    I hear what you are saying and you make some good points. It sounds to me like we might just be debating the definition of "Exploit" which I think means "to take advantage of". Perhaps "Exploit" is not the best label for this vulnerability but the vulnerability is catastrophic in some cases, and I'm not even talking about cracked passwords, I am talking about what you have labeled "DoS".

    "Denial of Service" attacks are certainly possible regardless of software installed on the site, but I don't think that's the best label for this either. For one thing, I don't think that was the intent of this attack, I think they mean just collect password and the servers crashing is just an unforeseen side-effect (they probably would rather not have been noticed). Also, consider that most DoS attack are carried-out by flooding the network with "background noise" (as you said), and in these attack it is the CPU and RAM that are affected (and only because of the excessive bootstrap loading). In all the cases I witnessed it was the RAM and CPU that were overloaded, and in every case I fixed it by simply stopping the wp-load.php file from being included when certain brute-force methods were detected. I could see by the log files that the attacks would continue, and even increase in number and frequency because the server was then freed up to handle that many more requests, but the servers immediately started performing normally (even though they were still under attack). This is because the server was now serving only a few hundred bytes of static html data all those bogus requests instead of dynamic, database driving content, generated after hundreds of include file have had their turn at the Processor.

    Anyway, what I am doing is working, really well in fact. And there are lots of people who are very happy about it. If want to nit-pick on plugins for strategy how about 6Scan that takes your admin email even if you don't agree to their terms and send you unsolicited emails too, or BulletProof that still manages to lock people out of their own site.

    Don't get me wrong, I'm still up for discussing a better label for this issue, and I'll always listen to any ideas to improve my plugin, but you should at least admit that there is a problem here and I think WordPress should learn from my work (and everyone-else's work on this latest exploit (or whatever it is)) and there should be an official fix release to address the bootstrap overhead issue on the login page.

    Let me know what you think. I am working on a plugin update now that should be ready to release in a few hours and I'm still open to changing the label if you have a good suggestion for me.

  14. esmi
    Forum Moderator
    Posted 1 year ago #

    If want to nit-pick on plugins for strategy how about 6Scan that takes your admin email even if you don't agree to their terms and send you unsolicited emails too

    If you have concrete evidence of these plugins breaking the plugin submission guidelines, please contact plugins [at] wordpress.org.

  15. Eli
    Member
    Plugin Author

    Posted 1 year ago #

    Thanks esmi,
    But I did, and I got no response from WordPress.

    I also posted details on the forum and 6scan asked for my person info so they could look into it. They told me that they don't know how it happened but that it was fixed, and I never did get any more email at THAT address. But owing to my general skepticism and distrust I installed 6scan on another site of mine and did not accept the terms (as an experiment). I then removed the plugin from that site and a few days later I got one of their emails at that new site's admin email address :(

    This was months ago, and I was furious at that time, but I've mostly let it go at this point. I know you can't police everybody and it's largely an honor system that some developers have taken advantage of.

  16. Pioneer Valley Web Design
    Member
    Posted 1 year ago #

    Wow - tested this tonight on a site at a friends suggestion. wp-login.php exploit came right up! I was infuriated to then read this post! @ELI...I agree with all the above, thank you for your work, but you really need to change that from Exploit to some other term!

    Site was clean otherwise...an hour of my life wasted - I want it back!

  17. Eli
    Member
    Plugin Author

    Posted 1 year ago #

    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

  18. Pioneer Valley Web Design
    Member
    Posted 1 year ago #

    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!

  19. Eli
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  20. Pioneer Valley Web Design
    Member
    Posted 1 year ago #

    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

  21. Eli
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  22. Pioneer Valley Web Design
    Member
    Posted 1 year ago #

    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.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic