Events Vulnerability

I have Events+ installed, but haven't really used it as it didn't work as well as MarketPress to manage my workshops.

Just a few minutes ago, while looking around at some unrelated things in the back end, I found a problem. Apparently, on the main site of my multisite, someone ELSE had created 12 different events in this plugin, all filled with spam links. ALL of them were created under usernames of people who had set up subdomain sites, but never finished the process by paying.

In other words, somehow just the process of getting username/password access to the site (I do not offer free sites), gave them access to the events creation area. They were also all published.

Ideas?

  • aecnu

    Greetings ProSapien,

    Thank you for this great question and a significant item to bring up.

    ALL of them were created under usernames of people who had set up subdomain sites, but never finished the process by paying.

    And all of them are probably spammers who have created accounts for this exact purpose and accessing the events through their dashboard privileges.

    Please log in as one of them and check to see if they have access to the Events+ plugin menu selection.

    Is the Events+ plugin set to be only allowed for paid users?

    Please advise.

    Cheers, Joe

  • aecnu

    Greetings ProSapien,

    Thank you for the additional input, it is greatly appreciated.

    Both of those files are old WordPress files injected into your WordPress installation that are causing a security breach for unauthorized signups.

    Check them against a fresh WordPress installation files and you will see that they do not exist.

    But do not delete them because the perpetrators will just turn around and replace them getting past the current version of WordPress because in my opinion WordPress see them as its own files (I believe these are indeed OLD WordPress files somehow injected into the installation).

    What you want to do is to permission the files 0, that is zero so they cannot be overwritten and are rendered absolutely useless.

    Please check it out and let me know.

    Cheers, Joe

  • ProSapien

    I cannot set the permissions to 0, BBEdit won't apply that value. But it will apply 000. Will that work?

    If so, I've done that now.

    Are you saying that once these people signed up for an account, they were able to make changes to those files and those changes somehow allowed them to access the Events+ plugin?

    If so, don't I need change those files BACK to the default values to remove the vulnerability? (FTR, I don't see anything in those files I can detect as a hack. But I'm no expert.)

  • aecnu

    Greetings ProSapien,

    Thank you for letting me know, it is greatly appreciated.

    I cannot set the permissions to 0, BBEdit won't apply that value. But it will apply 000. Will that work?

    Absolutely this will work as well and I appreciate you telling about this possibility that in some instances three zeroes will apply and yes it will work just as well.

    Are you saying that once these people signed up for an account, they were able to make changes to those files and those changes somehow allowed them to access the Events+ plugin?

    No not at all, I am saying that those two files are bogus files that have somehow been injected into the WordPress root folder allowing access to things they should not.

    Because they seem to be scalped files from previous versions of WordPress I do not think this is anything but a WordPress Core security issue, but no way to prove it at this time but have figured out how to stop it by the actions I had you take.

    These two files are not part of the modern WordPress 3.3+ files.

    If so, don't I need change those files BACK to the default values to remove the vulnerability?

    No you will just open the door again. These files are not coming with WordPress anymore and therefore they blend right in.

    However, if you want to open the door again (they were using these on me for Directory signups so it is not related to the plugin) do so at your risk and peril.

    Your site, your choice.

    Cheers, Joe

  • ProSapien

    Let me try to explain, with the understanding that I don't know how this vulnerability works and I'm trying to figure it out — at a rudimentary level, as least — so I can prevent future issues.

    Apparently something about access to those two files allowed further access to the Events+ plugin. Is that right?

    You said to set the permissions to 0 so "they cannot be overwritten and are rendered absolutely useless." So I assume that there is something about WRITING to those files — changing the CONTENT — that is a problem. Is that right?

    If so, I assume you mean they changed the content of those files in the hack. So I'm asking if the CONTENT needs to be changed back to the default?

    You said I can't delete the files, because the hackers can just "replace them." If they can replace files in my root, how do they have access to do so?

  • aecnu

    Greetings ProSapien,

    Thank you for your additional questions regarding what I had mentioned about the two "bad" files.

    Apparently something about access to those two files allowed further access to the Events+ plugin. Is that right?

    It is not relative to the Events+ plugin, it is relevant that they hack their way in through those files becoming members of the site/network and then they have access to other stufff like Events+ and Directory. Probably all privileges with the role they hack in at.

    You said to set the permissions to 0 so "they cannot be overwritten and are rendered absolutely useless." So I assume that there is something about WRITING to those files — changing the CONTENT — that is a problem. Is that right?

    Not exactly. Permissioning those files zero prevents them form being replaced, read, and/or executed ruining there day for sure.

    The files do not allow them to change content, it allows them to become members. How I discovered it was on my Directory site where the registration is closed i.e. disallowed and they still were able to register, create posts etc. and I figured out how they were doing it and how to stop them - i.e. via those two files.

    You said I can't delete the files, because the hackers can just "replace them." If they can replace files in my root, how do they have access to do so?

    I cannot prove it but I believe that WordPress core lets those files be placed there, I have no other possible explanation and they always use the same name and files.

    If it were really a root hack they could c99 us and own the server completely.

    This is certainly not the case and I am sure they would if they could, but they cant at this point and lets try to keep it that way.

    Make note it is quite often that WordPress version change logs mention plugging up security vulnerabilities.

    Cheers, Joe

  • shawng

    @aecnu

    Am I to understand you right in that you are suffering from the same problem?

    If so, has this been reported upstream for possible resolutions?

    *I ask because I have just completely destroyed a few sites on my old server that were full of spam due to same type of issue and I wonder if there is a new zero day exploit out there that we need to track down.

    guessing if you were hit and you are suggesting to leave those pages, that you have not yet tracked down the entry point?

  • aecnu

    Greetings shawng,

    Thank you for the great question.

    Yes it has happened on my test production server and I have seen it on other members sites where they complained that they were being spammed though they have captcha and registration turned off.

    The point of entry is almost 99.999% the WordPress core.

    The code of the files are from previous/older versions of WordPress that do not exist in the current version - this is why I think the core is allowing them somehow.

    This is NOT happening on non WordPress sites.

    Because I am not a coder and of course even if I were I would have to go through all the WordPress core code since I am unfamiliar with the core code to try to find the hole.

    With this in mind and since me going through the core is not happening, the thing to do next is to stop them which has been done my using the zero permissioning technique I figured out how to implement stopping phishers some years ago.

    I do not consider this to be of any big threat of any kind since it is more of a nuisance then anything else - at least up until now.

    The big one is the c99 coding which has been has been the root (no pun intended) problem for companies like Host Gator and the big WHMCS breach as well.

    Though I do know of how they are doing it (c99) to Host Gator, for security reasons I cannot disclose it but assure you it does not exist on my server configurations.

    Cheers, Joe

  • shawng

    @aecnu
    Thank you for the information. I think it sounds prudent for me to get ahead of this issue by actually creating those files ahead of time and taking the measures you mention to fight against it proactively.

    The c99 problem sounds really bad. I hope that WordPress is aware of this problem and comes out with a patch quickly as to not leave us vulnerable for to long. You mention that you don't have that particular server configuration so you are safe, can you mention what configuration we should avoid?

  • aecnu

    Greetings shawng,

    Thank you for your additional input and question, it is certainly appreciated.

    C99 is not relative or specific to WordPress, not by a long shot.

    It goes after any site, any host, any server that is not protected against it and they have have similar to root access over the infected system.

    Some companies such as Host Gator, basically invite this tyrant of a script by not setting directories to non browsing.

    So in the case of c99, it would not be fair to say it is a WordPress issue, but more accurately a server security/configuration issue.

    Cheers, Joe

  • ProSapien

    I figured out how they were doing it and how to stop them - i.e. via those two files.

    For the record, I changed the permissions to those two files as indicated above. I was hacked again two days ago. (Yes, I have the current version of WordPress running.)

    This change does not stop the infiltration.

    Although I don't understand all the cryptic language, the host indicated that there was an exploit in the Deep Blue theme, in case that helps.

  • aecnu

    Greetings ProSapien,

    Thank you for the additional input which is certainly appreciated.

    The fact that there are additional breaches in your installation does not invalidate my find, and to date I have not had a single, not one breach/bs signup since I took this measure and they used to be daily.

    I am ever so grateful that you brought this to light with the Deep Blue theme of course which should help members of the community. But to date those members that were having this problem and did as I instructed have not mentioned a breach since, obviously they are not running the Deep Blue theme either :wink:

    Thanks again for this valuable information.

    Cheers, Joe

  • ProSapien

    I'm not sure what you mean by "running the Deep Blue theme." I have the WPMUDev Theme Pack — which includes Deep Blue — installed, but it is not being used by any sites.

    But to date those members that were having this problem and did as I instructed have not mentioned a breach

    I am a member and I did as instructed. And I'm still having the problem. aecnu, above you gave an unsolicited lecture to me about customer service. Do you believe it is good customer service to tell someone with a problem, "Well, no one else has the problem."?

    The fact that no one else has reported a problem after implementing your "fix" isn't an indication that the steps resolved the problem. Whereas the fact that I did employ the "fix" and it did NOT solve the problem, is.

    If I stop eating pancakes and do NOT have a heart attack, that doesn't prove causation. Whereas if I stop eating pancakes and DO have a heart attack, it is evidence that refraining from pancake eating does not prevent heart attacks.

    If your claim is that the problem has nothing to do with WPMUDev (the Deep Blue exploit notwithstanding), I can understand that. Is that what you're saying? Are you saying that the problem is caused by c99?

    I still believe my earlier, unanswered question is relevant:

    You said I can't delete the files, because the hackers can just "replace them." If they can replace files in my root, how do they have access to do so?

    If they can replace those files, then how can changing permissions solve the problem? Why can't they just create OTHER files?

  • Mason

    Hiya,

    I've seen where on a couple of these threads the dialogue is really no longer constructive :disappointed:

    Let's see if we can get back to the heart of the issue, which as I understand it is that you've been hacked. That sucks. We wanna help fix that.

    So, there are several things we need to look for here. When Joe mentioned securing the wp-pass and wp-register files, that is one possibility. From what Joe's said, it seems like something he's seen happen frequently enough that it was best to check that first.

    While there are several ways for an intruder to get in and gain access to your install, we can generally narrow it down to a few possibilities:
    1. Insecure server environment
    2. Insecure or otherwise discovered passwords
    3. Vulnerability in a file itself

    So how do we avoid getting hacked? Well, in truth, there's no 100% guaranteed way to do it, but we can be pretty smart and make the hackers look for easier targets.

    Firstly, go with a reputable host. Not all hosting environments are equal and often you get way you pay for. HostGator is a reputable company, so we can generally assume they are ok in this regard.

    Additionally, make sure your WordPress environment file permissions are up to par:
    http://codex.wordpress.org/Hardening_WordPress

    Next, make sure your passwords are all very secure - multiple cases, numbers, letters, and special characters. Always use a secure protocol to access your site - ie use SFTP - never FTP. Transmitting your password via an unsecured connection is just asking for trouble.

    Regardless, you should immediately change all your passwords. If another hack occurs you need to change them again.

    Finally, a plugin or theme could possibly be coded poorly and as such be inherently vulnerable. There are security scanners for this thing and running code from reputable vendors is a major step in running code that's trustworthy.

    In this case, should the deep blue theme be responsible, we'd greatly like to know more about what in that code HostGator found that led them to that answer. It's possible that a hacker used an alternate method and then left a backdoor in that theme.

    Really, there are tons of possibilities. We'll need to go through things a step at a time to make sure all areas are secure. In terms of security scans for WordPress I use and highly recommend these guys:
    http://sucuri.net/

    There are also managed WordPress hosting solutions that will take care of any hacking attempts for you (as well as being more built for WordPress - and thus, more secure from the beginning).

    Hope this information helps. Let us know if we can assist further. Thanks.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.