Security Basics mailing list archives
Re: Sender Spoofing via SMTP
From: Tomasz Nidecki <tonid () hakin9 org>
Date: Tue, 8 Nov 2005 11:56:14 +0100
-----BEGIN PGP SIGNED MESSAGE----- Hash: MD5 Thursday, November 3, 2005, 9:20:35 PM, brandon wrote:
Thanks for your replies thus far, but they have helped add few more thoughts. By the way, I'm also looking for any thoughts on how to restrict this from happening internally as well. Using the about example, I can connect to a local exchange server and intiate the same spoofing technique to another local user -- for example I can connect to the server via Telnet to 25 and send my cubemate an email from santa@mydomain and tell him that the north pole has been having connectivity issues... It's junk like this I am trying to prevent internal and external people from doing straight from a telnet session.
In reality, you can't do anything about that. You can only use half-measures. This is a general problem with the SMTP protocol and nothing but a complete overhaul of mail protocols will help in preventing that.
Quote(Andrew Chong) - Currently, two common technologies are SMIME and PGP to digitallysign/encrypt emails. Response - This would help validate the sender to the enduser, which is a good start (and easy to teach to users). Not really the overall solution but definetly getting there. Thanks!
Well, SMIME and PGP are very nice, but you cannot require EVERY sender you can think of to sign their letters digitally. It's nice if they do, then you may be sure it's really them that sent the emails. But 99% of the senders will not sign their emails. So, you're in a situation where you can neither force everyone to use digital signatures [why should external senders listen to you?], nor discard all unsigned letters [you'd be discarding 99% of legitimate traffic]. All you CAN do is require all your company senders to digitally sign their email, but this only validates them in the eyes of their recipients, and does NOT prevent them from sending unsigned letters from fake domains.
Quote(Craig Wright) - Internal mail will not generally pass through SMTP Response - Great Point, but in this scenario I am connecting to port 25 and intiating the message directly via SMTP on the server. I think regardless of what happens to the message once it hits the queue and gets moved around by the Information Store or another MTA the fatal problem is that I was able to connect and send send the message?
Well, there IS a way to prevent this from happening partially, but it has serious consequences as well. More about that later...
Quote (Dallas Jordan & Corey LeBleu) (sort of combining these two) - I believe you should set your email server to only relay email coming from your domain. that would prevent people from the internet connecting to the server and sending emails randomly.
NO, NO, NO! First of all, NEVER use the domain given in MAIL FROM as a basis of the decision to relay mail or not. This domain can be given by ANYONE, as MAIL FROM is no form of authentication. I could connect to your server then:
telnet yourserver.com 25
< 220 yourserver.com ESMTP
HELO yourdomain.com
< 220 yourserver.com
MAIL FROM:<postmaster () yourdomain com>
< 220 Ok.
RCPT TO:<someoneelse () somewhereelse com>
< 220 Ok. This is BAD, BAD, BAD. It's a classical open relay, which spammers know very well how to use. You'd end up with queue full of spam, you'd be listed on DSBL, NJABL [not ORDB I think since I don't think it uses a domain-based test]. You'd be in a lot of trouble then. The ONLY things that may be used to make a decision whether to relay mail or not are: * the IP address of the connection [you MAY, but don't have to relay all mail from internal IPs such as 10.*, 192.168.* etc.] * SMTP AUTH [best use CRAM-MD5, not LOGIN or PLAIN, for security reasons] * POP BEFORE SMTP [this validates a given IP for a given amount of time] What you MIGHT do, if Exchange or other servers allow this [I haven't researched into other servers either...] is implement the following politics: 1. ALL local users [local IPs] are allowed to relay mail, BUT 2. the MAIL FROM given by the local user MUST match one of your local domains This will prevent your users from playing tricks, but will NOT prevent users from the outside connecting to your server and doing this:
telnet yourserver.com 25
< 220 yourserver.com ESMTP
HELO yourdomain.com
< 220 yourserver.com
MAIL FROM:<santa () santaclaus com>
< 220 Ok.
RCPT TO:<localuser () yourdomain com>
< 220 Ok. There are ways to check the validity of MAIL FROM, but, as I already said, they bring dire consequences and more on that later on in this mail.
Unauthenticating Mail Relay Response - However if I setup the server so it requires authentication for communication, would this not break the ability for other domains to send email to my users? I
No, if it's set up correctly. The politics must be such: 1. If someone [anyone] wants to send mail to one of your local domains, authentication is NOT required 2. If someone from the outside [or anyone for that matter] wants to send mail to some remote domain, authentication IS required This is the proper way to set up a mailservers and all properly set up mailservers use this solution. The only differences lay in whether local [local IP] users must use authentication or not. This is really up to you to decide, dependent on the size and security of your internal network.
have validated that I cannot spoof outbound emails from the internet based connection, so I'm not a completely open relay, but open enough that external connections can spoof an internal email sender and get that mail delivered to a recipient.
If anyone from the outside may send email to any remote user via your server just by giving your local MAIL FROM, then you ARE an open relay and sooner or later spammers will find that out and you'll find thousands of mails in your queue and you'll find yourself blocked on open relay blacklists... Don't let that happen! I used to have a hole on my server which allowed someone to give any login and password in the SMTP AUTH dialogue to authenticate and relay mail. This is much more difficult for the spammer to discover, than an open relay such as you're describing. And they DID find that hole and I was listed for some time on open relay blacklists, so believe me I know what I'm talking about 8].
Sorry for hitting this so hard, but I have done a bunch of searching on the net, read way too much Technet and although I find bits and pieces, nothing really addresses the ability to spoof a sender or prevent this type of relaying without breaking everything else.
Well, there is a way. But a risky one. It's called SPF. It works in the following way: 1. Every domain [that's the goal of SPF, however until now only a small part of domains does that] publishes a special IN TXT record in their DNS, which contains information on which SMTP servers [IPs, FQDNs] are allowed to send mail from this domain. 2. A mail server protected with SPF does the following. 2.1. Notes the IP of the connecting user/mailserver 2.2. Notes the given MAIL FROM and extracts the domain name 2.3. Looks up the SPF record in the DNS for the domain given in MAIL FROM and checks whether the IP noted in 2.1. is allowed to send mail with this sender address. 3. Now there are a couple of things that can happen. 3.1. The SPF record exists and matches the IP -> accept mail 3.2. The SPF record exists and does not match the IP -> deny mail 3.3. The SPF record does not exist... what to do then? Either: 3.3.1. Deny the mail [you'd be denying 90% of traffic...] or 3.3.2. Accept the mail [you'd be accepting 90% of spoofed mails then] The problem in SPF is that not everyone uses it and not everyone will use it. Ever. Impossible to force this upon everyone. So you'd allways find a domain which does not have an SPF record and then you have to accept it, or else you're risking denying legitimate emails. Now, imagine, santaclaus.com does not have an SPF record. You have to accept all mail from domains which do not have an SPF record [or else you'd be denying 90% of the traffic, blah blah blah], so ANYONE can spoof using this domain! Worse case. Imagne a spammer buys a domain called, for example, biggestbankofamerica.com and published an SPF record, which allows EVERY IP to send mail using this as MAIL FROM. Then you have a global address that can be used by EVERYONE as a spoof, and NO SPF will help you, even if you deny traffic from domains which do not have an SPF record, since this domain DOES have an SPF record and ANYONE can send mail from it... The problem is, that legitimate domains with such setup must exist, and these domains belong to companies which sell mail forwarding... Such as, I believe, mail.com? There are thousands of such domains or more. And the owners of those domains have no other way but to publish SPF records allowing ANYONE to relay! Why?... Imagine the following situation. 1. You have a mail forwarding account, joe () forwardtome com. This account is managed by the company which owns the forwardtome.com domain and sells mail forwarding or gives it for free for everyone so they can place adds on their websites or in the forwarded mails. This is a very popular setup. 2. You've set this domain up at www.forwardtome.com, so that all mail sent to joe () forwardtome com is sent to joe () yourserver com. And yourserver.com is protected with SPF. 3. Someone sends you email to joe () forwardtome com. The original sender is, say, mike () somedomain com. Now, somedomain.com publishes an SPF record which states that only mail.somedomain.com is allowed to send mail with somedomain.com MAIL FROM. If this mail was sent directly to yourserver.com, your SPF protection would see the following: * IP address of the connection would be mail.somedomain.com * Sender name is mike () somedomain com * the SPF record for somedomain.com allows mail.somedomain.com to send mail for this domain * mail is accepted 4. Now, what happens if the mail is sent to joe () forwardtome com? Since forwardtome.com is managed by the company ForwardToMe, its mailserver, not yours, receives the mail and then forwards it to your mailserver, maintaining the original sender! So your server will see: * IP address of the connection would be mail.forwardtome.com * Sender name is mike () somedomain com * the SPF record for somedomain.com DENIES!!! all other mailservers from sending mail with somedomain.com * mail is denied!!! Therefore, if SPF is introduced on all mail servers, automatically ALL companies offering mail forwarding go out of business!!! Because they cannot forward mail anywhere!!! Same happens to all forwarding options in all other mail accounts, you will not be able to forward mail to other addresses, so a fundamental functionality of SMTP which until now was used globally, is removed by the use of SPF! Therefore, SPF will not help you much, because you'll either have to deny 90% of the traffic or accept 90% of spoofed emails, and you will not accept any mail from forwarding accounts. Conclusion: SPF IS BAD! DO NOT USE IT EVEN IF YOU'RE TEMPTED! Ouffff... Now this was a long post 8]. So, in conclusion, there is NOTHING you can do against address spoofing, as long as SMTP is used as the mail protocol. You have to live with it. And you have to protect your server against relying mail, or else you'd be marked as a spammer by the community. - -- Tomasz Nidecki, Sekr. Redakcji / Managing Editor hakin9 magazine http://www.hakin9.org mailto:tonid () hakin9 org jid:tonid () tonid net Do you know what "hacker" means? http://www.catb.org/~esr/faqs/hacker-howto.html Czy wiesz, co znaczy slowo "haker"? http://www.jtz.org.pl/Inne/hacker-howto-pl.html -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUAQ3CEUUR7PdagQ735AQHStAQAtUjDBzKQXqMEQJRBh3rO6Gs1ImXE3JEV kgbHLog1+fJmC6IhS/++opDFdy6mH6ed+5IL39G9rt/IGPHkxRKS8n99Ya97i+5u cKqba+sBw1AJ5pBg1Z1ihrdyltBqXskJoQ3zOpT4gTlNegpHG51W2uiqE0Sg4FAr u7d9WYyahH8= =XO78 -----END PGP SIGNATURE-----
Current thread:
- RE: Sender Spoofing via SMTP, (continued)
- RE: Sender Spoofing via SMTP Tim Ballingall (Nov 04)
- RE: Sender Spoofing via SMTP Craig Wright (Nov 04)
- Re: Sender Spoofing via SMTP brandon . steili (Nov 04)
- Re: Sender Spoofing via SMTP Pranav Lal (Nov 07)
- Re: Sender Spoofing via SMTP Ansgar -59cobalt- Wiechers (Nov 07)
- Re: Sender Spoofing via SMTP Pranav Lal (Nov 09)
- Re: Sender Spoofing via SMTP Chris Moody (Nov 10)
- Re: Sender Spoofing via SMTP Pranav Lal (Nov 07)
- RE: Sender Spoofing via SMTP David Gillett (Nov 07)
- Re: Sender Spoofing via SMTP S.A.B.R.O. Net Security (Nov 08)
- Re: Sender Spoofing via SMTP Tomasz Nidecki (Nov 08)
- Re: Re: Sender Spoofing via SMTP Bryan S. Sampsel (Nov 08)
- Re: Re: Sender Spoofing via SMTP Barrie Dempster (Nov 08)
- Re: Re: Sender Spoofing via SMTP Bryan S. Sampsel (Nov 08)