@whu606 Ok, Cleanser seems good, and I know about Botstop. But I don't think you really understand what was happening here. I had approval registration setup. It has been working fine for years. There is definitely no issue with any settings. It wasn't a problem with bots applying. It was a problem with bots getting approved even though I didn't approve them! If that's not a vulnerability of some kind, I don't know what is.
Were they actually members, or just in your gdn_user table?
Applicants will still be entered into your table until you approve them, so the question is, did they actually get approved as members, or simply bypass your approval setting?
They actually became full fledged members. Most of them didn't post at all. A few posted comments on their own profiles, which is why we didn't notice them at first. One of them made a new discussion, which is how we noticed the problem.
It says that new/approved users should be "Members" and guests should be "Unauthenticated". It's also configured that applicants who are not yet approved should be "Applicants". It's been that way for years.
@Apreche said:
It says that new/approved users should be "Members" and guests should be "Unauthenticated". It's also configured that applicants who are not yet approved should be "Applicants". It's been that way for years.
Sorry for slow reply, I was out of town.
So, if a person applies to your forum do they become Applicant or Member?
what happens when you test applying for membership using the normal process?
If they become applicant, what permissions do you have set for applicants?
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
I don't know how many times I have to post the same thing before you believe me.
If you apply to the forum you are an applicant. I tested this. If I apply to the forum for a new account, that account remains an applicant. Even after it confirms it's email address, it is still has the applicant role until it is manually approved.
Applicants do not have permission to post or do anything but read. They're basically no different than anonymous users.
Somehow, there were many new accounts that were set to the "Member" role, but were never approved. Some of them posted comments on their own profiles. One of them created a new discussion. These accounts were not manually approved. They never even appeared in the application queue.
Now that registration is completely disabled, this is no longer happening, but I would like to allow registrations again.
I don't know how many times I have to post the same thing before you believe me.
we believe it is happening. just trying to get clarifications.
perhaps one of the other admins or moderators changed it.
theoretically - no one can change a role without user edit privileges.
maybe you could start a new thread and post snapshots of the role permissions.
form the dashboard. since your question has nothing to do with the topic of the thread.
it might give some insights
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
There are no other admins or moderators. There is no problem with the configuration. It is exactly as I have told you. It has been that way, and working properly, for years. Nobody has ever touched it. Only in the past month or two something changed and due to some exploit bots are bypassing the approval process.
@Apreche
I was suggesting how to possibly to attempt to solve your situation with more eyes looking at your setup and permissions and roles. Your choice to do as suggested above. -
Repeating the same thing without the above may not get you where you want to go. Kind of like going to a foreign country, where they don't understand your language and just repeating the same thing louder, hoping they will now understand you with the added volume to your voice.
I would also change all admin passwords and database password in config and database. after you have done the security update. someone may have already viewed your tables or added something prior to the security update.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
@Apreche A configuration issue is 1000:1 more likely than an exploit that only your forum has ever fallen victim to. I suggest starting a new discussion summarizing what you've checked up until now and under the assumption that there is something wrong with your particular install until you definitively find otherwise.
I would think development would be most interested in the potential for an exploitation here, no? If a possible exploit is always viewed with the "configuration issue is 1000:1 more likely" idea in mind, then that implies that it's going to take a lot of your customers noticing and reporting that they are getting hit before you start looking at it, and at that point you are way behind the curve with lots of customers impacted. With a report such as this, why not go into it assuming that something is wrong and proving it false, versus the opposite? Wouldn't that be the more secure approach?
This concerns me, especially in light of the security update that was released back on 4/2013 that patched security issues as far back as 4/2012. Getting those security patches out doesn't seem to be a priority, but perhaps I'm just missing something here.
I would think development would be most interested in the potential for an exploitation here, no? If a possible exploit is always viewed with the "configuration issue is 1000:1 more likely" idea in mind, then that implies that it's going to take a lot of your customers noticing and reporting
always viewed with the "configuration issue is 1000:1
where was the word always implied.
lol, the poster provided nothing that would allow anyone to even begin to figure out where and when and if there was an exploit.
the poster said they would report back if they could gather more info. I view Lincoln's comment more as a soothing salve to a forum owner then due to a lack of interest on the part of any vanilla developer.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
@CreamFilling said:
why not go into it assuming that something is wrong and proving it false, versus the opposite? Wouldn't that be the more secure approach?
No, it wouldn't. It would waste a tremendous amount of time.
My "odds" were based on the fact that no one else reported such an issue. Saying "I think it's an exploit!" is no basis for actually finding an exploit. I have no idea how you drew the conclusion we'd need "lots" of reports to investigate something. All it takes is 1 detailed, reproducible report.
This concerns me, especially in light of the security update that was released back on 4/2013
It's concerning we deal with security issues brought to our attention?
Just to restate, you said that it takes a single detailed, report to investigate a possible exploit. How exactly is a customer expected to reproduce an unknown exploit? A customer can only be expected to identify a situation and report it as best as they can. The customer themselves can't reproduce it unless they know how the exploit works, and figuring that out is more on the part of the development team (unless they are "lucky" enough to have someone post it on pastebin or elsewhere). I can completely understand that you don't have the development cycles to respond to everything, but to seemingly establish this as a barrier to entry would seem to result in investigating and remediating vulnerabilities late in the game. If that's the case, that's fine, it's just important for customers (and potential customers) to understand.
My concern over why it took a year to get vulnerabilities patched wasn't addressed. I'm referring to the most recent Security Update from 4/2013 which covered vulnerabilities going as far back as 4/2012. I'm specifically asking if customers really were left vulnerable for a year, or if there was something else you were doing for them to notify them and get them patched up as quickly as possible (and if so, what it was). Again, it's important for customers (and potential customers) to understand.
Comments
@Apreche
Using the BotStop plugin with approval registration stops bots in their tracks.
This plugin: http://vanillaforums.org/addon/cleanser-plugin may meet your bulk delete needs.
It may well be a setting on your forum, rather than a vulnerability, so you could have a long wait.
Searching this forum might help you with your settings.
@whu606 Ok, Cleanser seems good, and I know about Botstop. But I don't think you really understand what was happening here. I had approval registration setup. It has been working fine for years. There is definitely no issue with any settings. It wasn't a problem with bots applying. It was a problem with bots getting approved even though I didn't approve them! If that's not a vulnerability of some kind, I don't know what is.
@Apreche
Were they actually members, or just in your gdn_user table?
Applicants will still be entered into your table until you approve them, so the question is, did they actually get approved as members, or simply bypass your approval setting?
Did they actually post, and if so, where?
They actually became full fledged members. Most of them didn't post at all. A few posted comments on their own profiles, which is why we didn't notice them at first. One of them made a new discussion, which is how we noticed the problem.
@Apreche Check /role/defaultroles on your site and make sure they are still set correctly.
It says that new/approved users should be "Members" and guests should be "Unauthenticated". It's also configured that applicants who are not yet approved should be "Applicants". It's been that way for years.
Sorry for slow reply, I was out of town.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
I don't know how many times I have to post the same thing before you believe me.
If you apply to the forum you are an applicant. I tested this. If I apply to the forum for a new account, that account remains an applicant. Even after it confirms it's email address, it is still has the applicant role until it is manually approved.
Applicants do not have permission to post or do anything but read. They're basically no different than anonymous users.
Somehow, there were many new accounts that were set to the "Member" role, but were never approved. Some of them posted comments on their own profiles. One of them created a new discussion. These accounts were not manually approved. They never even appeared in the application queue.
Now that registration is completely disabled, this is no longer happening, but I would like to allow registrations again.
@Apreche
we believe it is happening. just trying to get clarifications.
perhaps one of the other admins or moderators changed it.
theoretically - no one can change a role without user edit privileges.
maybe you could start a new thread and post snapshots of the role permissions.
form the dashboard. since your question has nothing to do with the topic of the thread.
it might give some insights
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
There are no other admins or moderators. There is no problem with the configuration. It is exactly as I have told you. It has been that way, and working properly, for years. Nobody has ever touched it. Only in the past month or two something changed and due to some exploit bots are bypassing the approval process.
@Apreche
I was suggesting how to possibly to attempt to solve your situation with more eyes looking at your setup and permissions and roles. Your choice to do as suggested above. -
http://vanillaforums.org/discussion/comment/183982/#Comment_183982
(in a louder volume
Repeating the same thing without the above may not get you where you want to go. Kind of like going to a foreign country, where they don't understand your language and just repeating the same thing louder, hoping they will now understand you with the added volume to your voice.
I would also change all admin passwords and database password in config and database. after you have done the security update. someone may have already viewed your tables or added something prior to the security update.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
And I'll spkit the problem topic from the security topic once I have means & opportunity
There was an error rendering this rich post.
@UnderDog - I "means" this is your golden opportunity. You taking a break from vacation!
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
I reactivated registration and am waiting for it to happen again to collect some evidence and such. I will get back to you if/when it happens again.
@Apreche A configuration issue is 1000:1 more likely than an exploit that only your forum has ever fallen victim to. I suggest starting a new discussion summarizing what you've checked up until now and under the assumption that there is something wrong with your particular install until you definitively find otherwise.
I would think development would be most interested in the potential for an exploitation here, no? If a possible exploit is always viewed with the "configuration issue is 1000:1 more likely" idea in mind, then that implies that it's going to take a lot of your customers noticing and reporting that they are getting hit before you start looking at it, and at that point you are way behind the curve with lots of customers impacted. With a report such as this, why not go into it assuming that something is wrong and proving it false, versus the opposite? Wouldn't that be the more secure approach?
This concerns me, especially in light of the security update that was released back on 4/2013 that patched security issues as far back as 4/2012. Getting those security patches out doesn't seem to be a priority, but perhaps I'm just missing something here.
@CreamFilling said:
always viewed with the "configuration issue is 1000:1
where was the word always implied.
lol, the poster provided nothing that would allow anyone to even begin to figure out where and when and if there was an exploit.
the poster said they would report back if they could gather more info. I view Lincoln's comment more as a soothing salve to a forum owner then due to a lack of interest on the part of any vanilla developer.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
@
said:
I try to tell religious people that all the time!! except with the prove it true variable....of course
that said.. I have faith in the Vanilla dev team
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
No, it wouldn't. It would waste a tremendous amount of time.
My "odds" were based on the fact that no one else reported such an issue. Saying "I think it's an exploit!" is no basis for actually finding an exploit. I have no idea how you drew the conclusion we'd need "lots" of reports to investigate something. All it takes is 1 detailed, reproducible report.
It's concerning we deal with security issues brought to our attention?
I'd say yes.
Thanks for your timely responses.
Just to restate, you said that it takes a single detailed, report to investigate a possible exploit. How exactly is a customer expected to reproduce an unknown exploit? A customer can only be expected to identify a situation and report it as best as they can. The customer themselves can't reproduce it unless they know how the exploit works, and figuring that out is more on the part of the development team (unless they are "lucky" enough to have someone post it on pastebin or elsewhere). I can completely understand that you don't have the development cycles to respond to everything, but to seemingly establish this as a barrier to entry would seem to result in investigating and remediating vulnerabilities late in the game. If that's the case, that's fine, it's just important for customers (and potential customers) to understand.
My concern over why it took a year to get vulnerabilities patched wasn't addressed. I'm referring to the most recent Security Update from 4/2013 which covered vulnerabilities going as far back as 4/2012. I'm specifically asking if customers really were left vulnerable for a year, or if there was something else you were doing for them to notify them and get them patched up as quickly as possible (and if so, what it was). Again, it's important for customers (and potential customers) to understand.