Slashdot Mirror
Mail Server Flaw Opens MS Exchange to Spam
bl8n8r writes: "
Exchange 5.5 and 2000 can be used by spammers to send anonymous e-mail. He says even though software Microsoft provides on its site certifies that the server is secure, it's not.
There are dozens of messages--with subject lines such as 'Open relay problem' and 'We are sending spam?'--on Microsoft's Exchange Administration newsgroup, sent by information system managers who haven't been able to staunch the flow of spam from their servers. 'It is really inexcusable for a company that claims security is its top priority,' he said." If you are using vulnerable versions of Exchange, and have been hit by a Code Red variant, you may want to insure your 'guest' accounts are still disabled.
We came across this at work a few months ago. Turns out its actually a problem in SMTP's RFC. Sendmail and qmail will allow you to do the same thing if you a guest level account made on your *nix box, which scarely enough, many ISP *nix mailservers do. We started checking random client's ISP's email servers, and tho most were *nix, most allowed us to relay with guest.
Code softly but carry a big magnet.
Turn off Guest!
Since M$ windows will not allow you to delete the guest account (or administrator) it is standerd practis,
after disabeling guest to rename both accounts to somthing hard to guess.
It might shock you but on my Linux boxes the superuser is not called 'root' either.
As of Postgres v6.2, time travel is no longer supported.
this issue was never really resolved for exchange 5.5.. but it is simply resolved in 2000 which is detailed here
If you are running Exchange 5.5 you shouldn't be wasting time locking it down... Your hours would be better spent opening ports on your firewall or something, because 5.5 is so old and underupdated that it more efficient to work on a new mail server with new software.
- what is the definition of simultanagnosia?! I've been meaning to look it up!
Are you sure the upgrade will help you with Ximian? From what I understand, the Exchange server needs to turn on "http export" or something like that. It's basically M$ speak for webdavs. I can't use either Ximian Connector or KOrganizer at work with the Exchange Calendar just because of this.
Don't blame me, I didn't vote for either of them!
Actually its an error considering when the login FAILS you can still send email. RTFA!!!
No, this is
The problem has nothing to do with Exchange, or SMTP itself. It has to do with SMTP AUTH -- an extension that allows clients to authenticate themselves. This allows a roaming client (connecting from anywhere) to authenticate via username and password, and they are then given relaying rights as if they were directly on the ISPs network.
The attacker simply finds a frequently used account such as 'guest' and guesses a few passwords on it. This is classic account/password compromise, nothing more. Once the spammer is 'authenticated' they are free to relay. They could have also guessed any real user's password, the effect would be the same.
Nope....try to refrain from commenting when you really have nothing of value to add. The Windows Guest account is equivlent to the anonymous login in most other system. These do not require a valid password, and generally anything or nothing can be entered. If there was a password that could fail then it would no longer be a Guest/Anonymous account now would it?! Don't take it personally though, I was just in a flaming mood, and your post smelled like gasoline...haha!
If you must!
This is an SMTP AUTH problem and any mail server which permits relaying using SMTP AUTH and doesn't filter by source IP is open to this type of abuse. Exchange is more susceptible to this attack than other mail servers because there are predictable account names which can be brute forced and SMTP AUTH is enabled by default. It is simple to turn this off.
What is the big deal?
It looks like thinkcomputer has an ulterior motive "Microsoft telephone support is not available without the risk of paying a relatively high per incident fee. Therefore, we recommend contacting Think Computer via e-mail at info@thinkcomputer.com for more information about the issues discussed in this White Paper."
This is one Americanism that really pisses me off. Learn the difference between the two, and use the right one. To insure is to arrange financial or other reimbursement, in the event that the unwanted happens. To ensure is to take steps to prevent the unwanted happening in the first place. BTW, I don't care what dictionary.com may say. The definitive guide to the language is the Oxford English Dictionary, which says that in modern English, "insure" is used almost exclusively to mean protecting against losses.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
"If you are using vulnerable versions of Exchange, and have been hit by a Code Red variant, you may want to insure your 'guest' accounts are still disabled. "
What insurance policy would that be on sir?
I think you mean "you may want to ensure..."
The attacker simply finds a frequently used account such as 'guest' and guesses a few passwords on it. This is classic account/password compromise, nothing more.
the article says:
"If the guest account is enabled (on Exchange 5.5 and 2000), even if your login fails, you can send mail, because the guest account is there as a catchall,"
> Just for the same reason why my brand new Linux box has a
> "nobody" account. Which, admittedly, cannot log on.
>
> Having an user with no privileges whatsoever (at least in theory) is a very handy convenience.
Not directed at your comment, but remember that 'nobody' *does* have privileges.... Privileges to access everything running as "nobody" for one thing.
So many people install irc servers, web servers, etc.etc. as "nobody", yet if one is compromised, the hacker has access to all the stuff running as nobody.. You should use DIFFERENT and SEPERATE "nobodys" for each service, not rely on the stock "nobody"
Sig out of date
If by ancient history, you mean September 2003, yeah sure, Sendmail holes are ancient history.
Je ne parle pas francais.
Heh: I didn't say Americans are dumb ;)
Enquire: to ask a question
Inquire: an investigation (presumably consisting of enquiries)
With the emphasized syllable capitalized, Americans tend to pronounce it IN-queer-ee, and Britons en-CHOIR-ree.
No, it's turned off by default (which you would know if you had bothered to read more than the one comment you were replying to).
By attempting to take over every single area of the software industry, they have bitten off way more than they can chew.
Not to mention that every software intallation or update creates a new system for all practical purposes, because every thing is so tightly integrated, and interdependent it's no wonder that simple changes have system-wide unintended side effects.
Apocalypse Cancelled, Sorry, No Ticket Refunds
That is the worst excuse for insecurity that I've ever heard. Call me the IT gestapo if you like but there are a TON of ways to securely share documents with an unknown anonymous community. Don't believe me? What do you think you're doing right now! A web page is nothing more than a series of files. Files that are securely shared and, most of the time, done incredibly easily.
Using the guest account is probably the worst way that I can think of to share files... oh wait, I just thought of a worse one - using the Administrator account. The problem with both of these is that, while they accomplish the intended goal, they fail a security check because they also permit additional access that isn't necessary for the stated goal. Why do you think you need to use a guest account to share files? Sure it works. But it also lets someone LOG IN! Categorically, it is not different from using the Administrator account to accomplish the same thing. In both cases, the solution provides WAY too much access for the task that is to be accomplished.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Please read the article. This is not a flaw in exchange, but a flaw in the server configuration. The feature is generally disabled but might have been enabled if the server in question had been infected with a virus.
To put it bluntly: Administrators who do not secure servers after a virus infection are not the victims of a Microsoft security hole, but the cause of this particular problem.
Quote: "The guest account is a way for administrators to let visitors use a mail server anonymously, but because of security issues, the feature is generally not enabled. Exchange servers that had been infected by the Code Red worm and subsequently cleaned will still have the guest account enabled, Greenspan said. "
The article implies that you cannot disable this feature of Exchange. Also, there is still a problem there because the guest account is letting people send mail even when they fail to login to it properly. That is not "a flaw in the protocol" or a misconfiguration. That is typical Microsoft BS.
There are legitemate reasons for administrators to let people use a guest account, as outlined in the article. But it can be password protected and set with quotas and logging to prevent abuse. However, because of Microsoft's sloppy design there is an ability for a spammer to send spam without such restrictions applying.
Then configure exchange not to allow the guest account to send email. Yes, you can set exchange to disallow sending email on a user by user level.
Real exchange admins already know all this. The people being hit by this "vulnerability" are the same morons who got hit by Code Red. That should tell you something.
Hey Mr Insightful Exchange Admin, maybe you could read posts you reply to? The poster said they wanted to let the guest account send mail and your response is to make the guest account unable to send mail? Is this one of those "chewbacca is a wookie" "These aren't the flaws you're looking for [waves hand]" kind of Microsoft-fan arguments?
The article even explains why some people were using the guest account feature, which is not working correctly in this case. So, yes, it is a flaw in Microsoft's software and Microsoft once again blames the user. "Where do you want to go today? .. Oh? you want to go there? well, i don't understand why you would want to actually use that function so I am going to pretend you are incredibly stupid and mock you publicly instead of fixing it."
Yes it does.
Version 1.4 of the connector was recently released to support exchange 2003
If you can't beat them, arrange to have them beaten. -George Carlin
This is good to know.
Still, the folks writing worms (so far) don't exhibit signs of being particularly knowledgeable about Windows. They're basically script kiddies who dare to break out Notepad and fiddle around a bit. I don't know of any source of statistics for failed worm writing attempts, so who knows what the ratio is of wannabe worm authors vs the ones who manage to make one that works.
My point is that even though a given security measure can be defeated by a determined & informed attacker, it may still be worth the effort if it turns away the script kiddies and worms. Most of us don't have anything that's worth a determined & informed attacker's time, whereas a worm doesn't care, and worm authors don't need to account for every possible situation; they attack the default configuration and ignore all the alternate possibilities.
Setting restrictanonymous=1 is almost trivial. "almost trivial" = was trivial in my home, and corporate networks, but just might present problems on yours. Setting restrictanonymous to 2 is much more exciting - IIRC, it is completely unfeasible to do it on servers running Exchange 2k, or active directory boxes E2k will query.
Backup Exec didn't appreciate either setting one bit -- it refused to back up any server that had RestrictAnonymous set (with a cryptic and unhelpful error message). IIRC, McAfee management console crapped out as well.