Do you realize that someone could easily write a script that essentially "clicks" on any or every link on your board, quickly and repeatedly? Did you realize that this facility is actually built into every version of IE since 5.0?
The particular script that you cite opens the avatars directory, read the files, sorts them and displays them.
The more avatars you have, then the more resource it takes to read the directory, sort them, then display them.
You could put a flood check on it, but then nobody could scroll through your avatars if you have more than one page.
About the only thing you could do is make sure the requestor is logged in.
Open ubb_lib_misc. Find "sub avatar_select_menu{" insert under on a new line: "&RequireUserLogin;"
If the user that is doing this is logged in then there is nothing to stop it, but then... how do we know if it is a legitimate request to view your avatars or not?
Let me repeat, perhaps more clearly, any repeated loading of any of the scripts will have the same effect.
They didn't "exploit" a script, what they did was take advantage of a basic fact, that if you make the server do more tasks than the server can do at once it's going to eventually create a problem. It wasn't necessarily the avatar script that was the problem, it was the repeated operating of it.
I could go to your main ubb page and do the same thing.
So no, you are not looking for a particular string, you are looking for a particular IP doing the same operation far too rapidly to be indicative of normal useage patterns.
This is all fine and dandy but do you realize how much work is involved in pining something like that down.
I have full access to my server, but I also work on UBB sites that do not allow me access to the internal server functions and logs. In fact most people UBB customers will not have that level of access on their host servers.
Granted any CGI script is exploitable but wouldn’t it be prudent to update the UBB script to that these internal functions only be accessed only by the UBB script and not from posting a URL? Addressing flaws in the system that can be bandwidth and CPU intensive will either make or break this product. The creeps out there have now discovered this exploit. What is UBB going to do about it?
Saying that they can initiate a denial of service against this site by exploiting UBB code isn’t a very good selling point and not really an acceptable response to someone who has spent a great deal of money on your product over the years.
We could rewrite the access point any way you want, and as long as there is some way for some body to reach it or otherwise access it from the internet via a browser then it can be run repeatedly.
making it only accessable via the ultimatebb.cgi script?
If we changed it to a POST instead of a GET it just takes someone 30 seconds longer to figure out how to access the function. Even if we build in refer check to the POST operation perl still has to start, compile, check the refer(if it gets one), then exit.
negligable savings provided you don't have an ungodly number of avatars.
Changing the access point wouldn't make it less repeatable at all, just less traceable. You have already commented on how much work it is to grep your logs. But you want me to make it harder?
Last time - the truth is that if it can be reached from the internet it can be operated repeatedly. There is no escaping that. No amount of floodchecking is going to fix it either. Floodcheck still requires perl to startup, compile the scripts, run it's checks against a flat file that it has to open, and then exit. Same answer as a refer check in making the avatar window a POST. No real savings.
I'm sorry if you feel that is an unacceptable answer, but it is the truth and to me, answering with any less than an honest answer, based on the reality of the situation, is even less acceptable.
Thank you for a straight answer, no candy coating. I respect that. Understood. I guess we've all got to just get to a point where we can monitor over servers or virtual domains better.
How about some kind of code that could send the Admin a PM telling him or her that there is an IP or a member that or who is or might be flooding the server with requests, and maybe some kind color code status or percentage scale as to how severe the threat might be?
It's not fair to be the squeeky wheel when the person on the other end is honesly trying to help you, so I apologize.
I hadn’t noticed it listed in the requirements that UBB Classic needs to be expertly monitored for exploits. Many push themselves to the limit just installing the scripts, let alone hacking them, or in this case as a security measure “grep their logs†I don’t even know what you mean by that, other than “grep†can find anything. I haven’t really used it tracking down security problems. In fact most of what I do is offline and with DOS based utilities such as T-Find.
I think a security section on the board for common exploits that no code modifications on the planet will correct, as you stated there would always be a way to get around it.
Notifications of suspect access, and the ability to apply governors or flood controls unique to individual users or IP blocks:
Security Reports.
IP 149.69.58.2 Possible Avatar Flood 100 times in 30 minutes
Or something to that effect…
I do think that having the user logged in when accessing board features and utilities should be standard. There is no point leaving these exploits wide open to anyone.
I don’t mean to be the cranky customer here, but had UBB given me an alert that flooding was taking place with the avatar script, it could have saved me months tracking this particular exploit down. As message boards become more popular trolls and the weapons are getting more sophisticated. They of course believe they can outsmart anything you can engineer. It would be nice to see you folks prove them wrong.
You keep referring to this as an exploit, when in fact, it isn't. David explained earlier that it is a common fact that scripts can be repeatedly run no matter what kind of checking Infopop were to put in UBB.
The admin logging idea is fine and dandy, but wouldn't do anything to keep someone from executing the script hundreds of times in an attempt to bring your server to its knees.
Quote
Originally posted by David Dreezer Last time - the truth is that if it can be reached from the internet it can be operated repeatedly. There is no escaping that. No amount of floodchecking is going to fix it either. Floodcheck still requires perl to startup, compile the scripts, run it's checks against a flat file that it has to open, and then exit. Same answer as a refer check in making the avatar window a POST. No real savings.
So see, even floodchecking or admin logging would still require the above to activate, in turn, causing the load you are asking them to try to prevent by the script performing as designed. Admin loging of requests might actually amplify the problem by introducing more load into the mix by doing additional file i/o.
The whole issue centers around the fact that for UBB to do anything to stop the excessive requests, perl must be started, and the script complied. There is where your server was getting the snot kicked out of it. All of the Perl requests. You can do the same thing with just about any other message board out there. Send enough requests to it, and of course the server will take a beating.
The only way any kind of governor would be effective is on the server, otherwise you get back to the Perl.
--------------------- Suite Madame Blue....Gaze in your looking glass..you're not a child any more! TheGeeksInc.com Forums Have you tried Everwars yet?
Let me clear something up for you. I’m not making a point here as a point of debate or who is right or who is wrong, or whether it’s the term exploit doesn’t apply to the methodology used for nefarious bombardment of a server. Define it as you will, quit frankly I don’t give a hoot.
What I do care about is knowing how and when the server is being brought or has been brought to its knees.
As has been stated and UNDERSTOOD, that all cgi script can be used to exploit – no... be used to nefariously bombard a server and bring it to its knees. It would be prudent for the coders to apply a routine in their scripts that picks up on such things and reports those results in the administrative area of the program.
Someone has executed the nefarious bombardment of my server for who knows how long and repeatedly, bringing my server to its knees. I could not isolate the source, Now I know better. I can watch for it in the logs now.
I was finally able to pin it down after months of plowing through my server logs, large 200 MB server logs at times. Until I finally extracted all instances of the word Avatar, and found out how my server was being exploited,
With a practical routine encoded in the script reporting that an IP may be flooding the server with repeated requests hits on the same cgi routine. I could have isolated this problem months ago.
I have spent countless hours trying to pinpoint what it was that was exploiting my servers resources. YES I USED THAT WORD AGAIN.
I understand exactly what has been said here, It would also seem the onus is on the owner of the message board and his server when the UBB script or any CGI is used to crash it.
I am not blaming UBB for this.
If the point is we know about it, and we’re not going to do anything about it because the same can be done with other scripts, then fine, stand in parallel with the rest. Somehow I would have thought that UBB would want to step out and step up to the challenge of making their product far more superior than that.
[This message was edited by MovingPictures on July 19, 2003 at 09:57 AM.]
So see, even floodchecking or admin logging would still require the above to activate, in turn, causing the load you are asking them to try to prevent by the script performing as designed. Admin loging of requests might actually amplify the problem by introducing more load into the mix by doing additional file i/o.
Ron said this above, and he's right. If we were to try and add any sort of anti-DOS protection into the code, it would only end up adding even more load. The bang isn't worth the buck. Any such feature is nowhere near the whiteboard.
I would highly suggest looking into Apache's mod_dosevasive if you have further problems with people attacking your server with repeated requests.
-- Charles Capps UBB.classic™ Developer Having problems? Open up a support ticket!
I missed the point of it being a matter of overhead. Sorry about that. I guess I fumed this thread up enough.
"Apache's mod_dosevasive," I'll look into that.
The point you folks are making is that at this time it's not practical to have UBB do any of this (understood and the answer is honest and fair) and even it was there was, other improvements with greater benefits overall are in the works
The operative point is all CGI can make a server vulnerable, and if that’s the case and if anyone is the unlucky owner of a targeted server, then finding a better means of protecting the server overall is where the focus should be, and not on the individual programs.
I realize that I have been unfair here, it just so happens that this time it was UBB so where better to cast the blame. It’s really the jerks that perpetrate these things that should be feeling the heat, not you guys.
The important point is it’s not UBB Classic's problem, it’s my problem, and I need to find a way to isolate things like this when they happen more effectively and not blame the CGI programmers.
I can be a cranky chap, but I do appreciate you guys taking the time to set me straight. Thank you all for helping me through the aggravation.
I installed "Apache's mod_dosevasive." I think this is the answer I have been looking for.
You guys did me right, I owe you one.
I know I can get on your nerves, but I also keep coming back because I trust your product.
I may get angry with it, and in this case for the wrong reason, but I am a loyal customer and as long as people like you are behind this product, I'll keep coming back.
David Dreezer, J.C., Ron M ,Charles Capps, please accept my humble apology and Thank you.
The URL doesn't matter. This can be accomplished using any URL.
--------------------- Suite Madame Blue....Gaze in your looking glass..you're not a child any more! TheGeeksInc.com Forums Have you tried Everwars yet?
