Paul Lesniewski wrote:
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.
Then just ignore my comments about the internal mechanisms. As I clearly
stated, I have no idea how the guts work, and I'm not a programmer anyways.
As far as exploits go yes, there is exploitation going on, but no it
doesn't appear to be because of a bug or vulnerability in SM. It's going
on because a user got their password swiped. That's a big difference
between that and a buffer overrun that lets someone run wild with your
system.
My attempted suggestion was merely "hey, could this particular method be
broken by changing part X". Your answer is obviously "No, it can't", so
lets just leave it at that.
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
begin:vcard
fn:Nick Bright
n:Bright;Nick
org:Terra World Communications, LLC
adr:Suite #11;;200 ARCO Place;Independence;KS;67301;USA
email;internet:nick.bright@xxxxxxxxxxxxxx
title:Network Administrator
tel;work:888-332-1616
tel;fax:620-332-1201
x-mozilla-html:FALSE
url:http://home.terraworld.net
version:2.1
end:vcard
-------------------------------------------------------------------------
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
