On 10/9/07, Paul Lesniewski <paul@xxxxxxxxxxxxxxxx> wrote: > On 10/9/07, Nick Bright <nick.bright@xxxxxxxxxxxxxx> wrote: > > Paul Lesniewski wrote: > > > Please do NOT top-post and try to use correct reply quoting. > > > > > > On 10/9/07, Brent <brent@xxxxxxxxxxx> wrote: > > >> I had this exact issue. It ended up being one exploited account. The IP > > >> addresses connecting to the account were from various APNIC blocks. I would > > >> block one IP and it would move to another... suggesting that it was some > > >> kind of bot - however, I added the captcha plugin and they kept logging in! > > >> I changed the password on the exploited account and so far it hasn't > > >> resurfaced. > > > > > > You might have chosen a weak CAPTCHA mechanism. It might be useful > > > for others if you mention which CAPTCHA backend you used (and if you > > > tried any others). > > > > What mechanism do you suggest, I am looking at using this plugin, but > > there is quite the array of options for mechanisms to use. > > My first suggestion is to use it as part of the Restrict Senders > plugin. It only needs to show itself when there is a problem. Sorry, I meant the Lockout plugin. Restrict Senders should be used to cap the amount of junk that goes out once an attacker has gained access to your SM installation. Lockout in combination with CAPTCHA will provide some security against automated login attacks. > After > that, please read the comments about each mechanism in the config > file, research them online and look at each of them in operation > yourself. Some are obviously very weak - you'll probably want to > avoid those that are notated as such. Please report back your > findings to share with others. > > > > >>>>>> 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&startMes > > >> sage=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. 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. :-\ > > >> Yes that was my take as well, it really looks like a user using > > >> webmail but when I go through my AOL mail loop messages they show > > >> headers such as: > > >> > > >> from 81.199.179.36 (proxying for 10.250.50.255) (SquirrelMail > > >> authenticated user exploiteduser) by webmail.terraworld.net with > > >> HTTP; Thu, 4 Oct 2007 18:57:06 -0500 (CDT) > > >> > > >> IP Addresses from AOL mail loop: > > >> 196.1.179.183 > > >> 78.138.2.196 > > >> 41.219.220.2 > > >> 81.199.179.36 > > >> 84.254.188.2 > > >> 88.202.124.6 > > >> > > >> Where the IP address connecting as user "exploiteduser" varies widely, > > >> and the attached message is always the same 'lottry' phishing scam. I > > >> suppose it's possible that it's coming from the users' PC (they are on > > >> dialup after all), but the IP addresses vary so widely that I seriously > > >> doubt that it's one PC. The list is relatively short because I would > > >> expect most of the botnet to be listed on RBL's, and my web server > > >> blocks based on RBL lookups. > > >> > > >> - Nick > > >> > > >>> Ken > > >>> > > >>> > > >>>> - Nick > > >>>> > > >>>>> Ken > > >>>>> > > >>>>> > > >>>>>> Nobody can reasonably expect an ISP to keep every single users' PC > > >> clean > > >>>>>> of trashware constantly, so accordingly there needs to be some way to > > >>>>>> mitigate the impact of this type of issue at the common point - the > > >>>>>> SquirrelMail installation. It doesn't seem to me like this is a bug > > >>>>>> or a security vulnerability in SM since a valid users' password was > > >>>>>> compromised, but is there any way to mitigate this type of thing? > > >>>>>> > > >>>>>> I would appreciate any feedback regarding this topic and methods of > > >>>>>> mitigating damage done by compromised accounts. I will also answer any > > >>>>>> questions that may help develop a method of mitigation. > > >>>>>> > > >>>>>> - 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
