Subject: Mail2Web.com leaks user authentication information Date: Jan. 31, 2006 From: Joseph Tam While investigating why I had hundreds of idle Qpopper daemons running on my mail server, I discovered most of them were connected to 168.144.0.0/16, which is owned by mail2web.com, a free Email web client service that offers to connect to your remote mail server via POP or IMAP. An examination of my logs showed hundreds of (unsuccessful) login attempts from them by users that didn't exist on our network. None of them were numerous enough to be considered a dictionary attack. A quick Google showed that many of these usernames existed in different networks on campus. I have since learned that it is a feature they call "Intellilogin" where the user supplies an Email address and password, and it will automatically try to find the correct remote mail server by making guesses at the server hostname by adding likely hostnames to the domain part of the Email (e.g. pop.domain, smtp.domain, etc.) as well as trying the MX entries. This is their default login style. For example, during test of their service, their DNS server looked up pop pop3 mail smtp email imap pop.mail pophost1 postoffice If they find a DNS entry, they attempt connections to the usual POP/IMAP/SSL ports. A security problem starts if the user can not authenticate. Some reasons for failure could be - typographical error in Email address (username, domain) - error in password. - server is unavailable (crashed, in service, overloaded, etc.). - network does not supply remote mail service - remote service is filtered (e.g. firewall). Instead of doing the sensible thing and bailing, it will start hunting around other known POP/IMAP servers >>outside the mail domain<< and attempt to log in >>using the same authentication information<<. So if Mail2Web can't authenticate within x.ubc.ca, eventually it will try that username/password combination on other POP/IMAP servers in other domains like y.ubc.ca. This lends itself to passive capturing of sensitive authentication information (albeit with possible errors). It required a 2-line patch in my qpopper installation to capture this information. Without too much problems, I was able to match up usernames and passwords with domains they were intended for. The ease in which this could be subverted depends on what the original error was: if the failure was caused by the remote mail server being unavailable, the username/password is error-free and can immediately be exploited. If it was a typo, it might be harder to exploit, but an educated guess at the mistake yields results. I'm not even sure how far afield Mail2Web tries (e.g. ubc.ca -> unbc.ca?) or whether one could inject a rogue POP server into their search list. I have tested this by making up a fake Email address outside my domain with a bogus password, and within a few minutes, that information popped [all my puns are unintentional! --jt] right into my logs. I have complained to abuse@mail2web.com, but not surprisingly, I have not received any response other than the cursory we'll-look-into-it. I read with chagrin one of their FAQ items: Question: Is it safe to use mail2web.com? Answer: mail2web.com does not compromise any corporate security policies. Our application was entirely architected with a corporate IT department in mind. Security is always considered highly important. This is the reason why Java and ActiveX were purposely avoided in the development of the application. If additional security is required, use the SSL version from the main page. Click here to learn how. mail2web.com is available in standard or 128-bit secure SSL. While using the SSL version, your email address, password, and email messages are entirely secure. [ Insert hysterical laughter here. --jt] Your passwords and email messages are never permanently stored by mail2web.com. Your email addresses are retained if you choose to customize mail2web.com in order to make regular use of the application more convenient, but you are never added to any mailing list. How to deal with this it? I would suggest a few things: - warn your users about Mail2Web: at least they should not use the Intellilogin, but rather specify the remote mail server directly. Better yet, they really shouldn't be trusting a third party with their critical authentication information. If they want a GUI front end to their mail, install a mail reader like Thunderbird instead. - do not give out hostnames like pop.your.domain, etc. to any host within your network domain. - the usual way of dealing with problem hosts on the internet -- by denying network access -- makes this problem worse. If Mail2Web can't authenticate using the correct username/password to a remote mail server, it is an invitation to truck this information around all over campus (and beyond?). What's worse, the username/password is probably free from defects. If network blocking is to be done, it will have to be done at the campus border to stop them from roaming around. I am testing an alternate way of dealing with this: I patched my pop daemon to accept any authentication data from Mail2Web, create a fake session that supplies a persistent (read-only) mailbox with one message that warns the user about the Mail2Web service and scare the bejeezus out of the user. This has many benefits: - it will stop idle daemons from hanging around since I can enforce a timeout. - it will arrest their roaming and stop then from spraying this information further down their server search list. - it issues a directed warning to Mail2Web clients. Self inflicted negative advertising. I have Emailed some of administrators of the heavily used domains that I manage to match user accounts up to. Late notice: as of Nov. 10, 2006, I stopped getting these Mail2Web logins 11 months after my initial complaint. This might mean they've fixed it (it's easy enough to find out), or they've wised up to my trap and excluded my POP server from their search list. I Emailed them, but as usual, they've "escalated" my trouble ticket case, which seems like their euphemism for "filed under /dev/null".