On 10/9/07, Nick Bright <nick.bright@xxxxxxxxxxxxxx> wrote: > Paul Lesniewski wrote: > > On 10/9/07, Ken A <ka@xxxxxxxxxxx> wrote: > >> Nick Bright wrote: > >>> Ken A wrote: > >>>> Nick Bright wrote: > >>>> > >>>>> Per some suggestions in the thread I was able to determine that they are > >>>>> not using "mailto.php", but rather compose.php: > >>>>> > >>>>> /var/log/httpd/access_log:196.1.179.183 - - [07/Oct/2007:21:54:10 -0500] > >>>>> "GET /webmail/src/compose.php?mail_sent=yes HTTP/1.1" 200 37102 > >>>>> "http://webmail.terraworld.net/webmail/src/compose.php?mailbox=None&startMessage=0"; > >>>>> > >>>>> "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" > >>>> > >>>> Are you saying that was the only entry in the log from that IP? They > >>>> only hit compose.php? If not, what was the sequence of events? > >>> There were many hits from quite a few different IP addresses, and they > >>> all looked simmilar to that. I've extracted log entries from that IP > >>> address, and attached the file to this message. > >>> > >>> From what I can tell it logs in, then hits compose.php repeatedly. > >> That's odd. It really doesn't look like a bot. > > > > I agree - a bot probably wouldn't hit any options pages, etc. > > Someone else said that they saw the same behavior, and the bot was > hitting the options page to change the FROM address and users' name. > > > > >> Perhaps it's using an IE > >> toolbar of some sort to control the browser. There is a CAPTCHA plugin, > >> and a "Password Forget" plugin, but when a bot behaves like a user, it's > >> hard to block without inconveniencing the user. :-\ > > > > Right. I would suggest the Restrict Senders plugin is what the OP > > wants if "mitigation" is the goal. "Re-coding whatever is allowing > > these POST url's to send mail" is meaningless unless you want SM > > without compose functionality. > > I'll look at the restrict senders plugin. > > My suggestion about not allowing POST to send mail is based on me not > knowing anything about how SM works, but the thought of "if they can't > craft a URL to send mail and poke it to the server, wouldn't that fix > the issue?". Seems like GET should be just as valid, and prevent an > injection exploit like this appears to be. You yourself seemed to agree it *isn't* an injection exploit. If you are claiming it is, we need evidence to support that. GET is *more* vulnerable in general than POST to various forms of abuse, not to mention that it just wouldn't work for a form with this much data in it. Your problem is exposed passwords, so I don't know why you are suggesting SM's internal mechanism for sending mail be modified. > Please keep in mind I am not a programmer, just a user, so there's not > much good in raking me over the coals with programming arguments. > > - Nick Bright > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- squirrelmail-users mailing list Posting Guidelines: http://www.squirrelmail.org/wiki/MailingListPostingGuidelines List Address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
