Hallo, Paul, Du (paul) meintest am 09.10.07: > 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=No >>>>> ne&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 Why do you full quote? Viele Gruesse! Helmut ------------------------------------------------------------------------- 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
