Electronic Mail Security: SMTP & Sendmail

1. Electronic Mail Security:SMTP & Sendmail Cmpe 526 Operating System and Network Security Presentation Serdar Salı

2. Overview • Introduction • SMTP • SMTP Security Issues • Solutions to SMTP Security Issues • Sendmail • Sendmail security mechanisms

3. Introduction • E-mail : a leading communication medium • As usage spreads, security issues arise • Privacy, integrity, authentication • Spamming • Unsolited commercial - bulk e-mail

4. How e-mail works

5. SMTP • Simple Mail Transfer Protocol • Objective: • Transfer mail reliably and efficiently • Independent of a particular transmission system • Only a reliable ordered data channel required

6. SMTP • Can relay mail across transport service environments • SMTP transports a mail object • Envelope and content • A text based protocol

7. How SMTP works • User wishes to send mail • Client SMTP establishes two way transmission channel to Server SMTP • Receiver may be ultimate or intermediate • Client SMTP generates and sends SMTP messages • Replies are sent from Server SMTP

8. How SMTP works User Client SMTP Server SMTP SMTP Commands/Replies File System File System And mail

9. The SMTP Model • A typical communication • User establishes a connection • Identifies using HELO or EHLO • Sends mail using MAIL from: <address> • Specifies recipients using RCPT to: <address> • Specify mail content using DATA • Close connection using QUIT or send another mail

10. The SMTP Model • S: MAIL FROM:<Smith@Alpha.ARPA> • R: 250 OK • S: RCPT TO:<Jones@Beta.ARPA> • R: 250 OK • S: RCPT TO: <Green@Beta.ARPA> • R: 550 No such user here • S: RCPT TO: <Brown@Beta.ARPA> • R: 250 OK • S: DATA • R: 354 Start mail input; end with <CRLF>.<CRLF> • S: Blah blah blah... • S: ...etc. etc. etc. • S: <CRLF>.<CRLF> • R: 250 OK

11. The SMTP Model • SMTP can be used for: • Mailing: sending message to mailbox • Sending: sending message to user’s terminal if the user is online • Usually, SMTP is used for sending, POP or IMAP is used for retrieval

12. SMTP Mail Relay • The destination of the SMTP server may be final or intermediate • The client resolves the server address to: • an intermediate Mail eXchanger host or • a final target host. • A server may be: • Ultimate destination • Intermediate destination • A gateway

13. SMTP Mail Relay • Mail from: <reverse-path> • Rcpt to: <forward-path> • Two ways to relay messages: • Explicit source routing • DNS Mail eXchanger (MX) records

14. SMTP Mail Relay • Explicit Routing • Forward path: • <@a.com,@b.com,receiver@c.com> • Reverse path: • <sender@d.com> • SMTP servers connected in order • Each server removes its address and adds it to reverse path • Error or notification messages • Designed when internet was a small community

15. SMTP Mail Relay • DNS MX records • For a domain, search for a record in the DNS • Forward the mail request to that host • Currently used method for mail relay • Explicit source routing still supported for backward compatibility • This causes SPAM domain Preference value host

16. SMTP Security Issues • No authentication • Spamming • Unauthorized use of relaying, DoS • All communication done in plaintext • Eavesdropping • Man in the middle attacks • VRFY, EXPN commands

17. SMTP Security Issues • SMTP-AUTH: • An extension that adds access control to SMTP • A client may: • indicate an authentication mechanism to the server • perform an authentication protocol exchange • optionally negotiate a security layer for subsequent protocol interactions

18. SMTP-AUTH • SMTP-AUTH: • Only legitimate users can relay mail • Does not guarantee authenticity of envelope header or message header • Spoofing is still possible • The receiver can not tell if the sender was authenticated

19. SMTP-AUTH • Based on Simple Authentication and Security Layer (SASL-RFC-2222) • SASL uses plugins to define authentication mechanisms: • Plaintext password: PLAIN • Shared secret:CRAM-MD5, DIGEST-MD5 • Kerberos: KERBEROS_V4, GSSAPI

20. SMTP-AUTH • Adds AUTH verb to SMTP • Can take parameters to save round-trip • Any knowledge prior to authentication must be discarded

21. SMTP-AUTH • S: 220 smtp.example.com ESMTP server ready • C: EHLO jgm.example.com • S: 250-smtp.example.com • S: 250 AUTH CRAM-MD5 DIGEST-MD5 • C: AUTH FOOBAR • S: 504 Unrecognized authentication type. • C: AUTH CRAM-MD5 • S: 334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= • C:ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== • S: 235 Authentication successful.

22. SMTP-AUTH • AUTH verb can also be applied to mail from: verb • Allows trusted entities to communicate authentication of individual messages • AUTH=<> : not authenticated • C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com • S: 250 OK

23. SMTP-AUTH • Spoofing is still a problem • Subject to man-in-the-middle attack • Does not provide user authentication, only delivery authentication • Subject to brute force attacks when username – password schemes are used

24. Secure SMTP over TLS • Private, authenticated communication between client and server • Defines a new verb, STARTTLS • Takes no parameters • Used to tell client that the server is TLS capable • Used to start a TLS handshake by client

25. Secure SMTP over TLS • Sample communication: • S: <waits for connection on TCP port25> • C: <opens connection> • S: 220 mail.imc.org SMTP service ready • C: EHLO mail.ietf.org • S: 250-mail.imc.org offers a warm hug of welcome • S: 250 STARTTLS • C: STARTTLS • S: 220 Go ahead • C: <starts TLS negotiation> • C & S: <negotiate a TLS session> • C & S: <check result of negotiation> • C: <continues by sending an SMTP command> . . .

26. Secure SMTP over TLS • A publicly referenced SMTP server must not require TLS • May effect relaying capabilities • After the TLS handshake, client and server should give the decision: • Is the achieved authentication and privacy enough?

27. Secure SMTP over TLS • If not: • Client should quit immediately, • Server should respond each request with an error message • Server may place info from certificate in Received: header of the message body

28. Secure SMTP over TLS • If security level is enough: • All info before handshake is discarded • Client should send a EHLO again: • The server may report different services • Security considerations: • Not end-to-end • SMTP is not end-to-end • The entire chain has to be made secure • Does not indicate authentication for the receiving client

29. Secure SMTP over TLS • Decision on adequateness of security • Must be made locally • Implementation dependent • Susceptible to man-in-the-middle attack: • The STARTTLS response from server may be deleted by an eavesdropper • Client never knows that server is TSL capable

30. Secure SMTP over TLS • Solution to man-in-the-middle attack: • Client records if a server offers TLS • Generates a warning if it is not offered in later sessions • Can not be used to authenticate author: • Every chain needs to be authenticated • Other mechanisms are used for this purpose • PGP, MIME, etc.

31. POP-before-SMTP • POP requires authentication • A user uses POP to read mail • IP address of that user is recorded • User is granted access to SMTP server for a certain time period • Dependent on user reading mail • Not everyone uses POP • May introduce risks with • dynamic IPs • NAT schemes

32. Sender Policy Framework • An extension to SMTP • Also called SMTP + SPF • Quick and easy to implement • Designed to prevent forged e-mail • Checks if the sender is authorized to send mail from the domain they claim to be from • Two sides • Checking incoming mail • Other people checking mail you send

33. Sender Policy Framework • To check incoming mail • Use an SPF enabled message transfer agent • To allow others check the mail you send • Publish SPF records in DNS “This domain sends mail only through these servers”

34. Sender Policy Framework • Types of DNS records used in SPF • A: maps name to IP address • mail.example.com. IN A 192.0.2.3 • MX: indicates servers responsible for handling mail in the domain • example.com. IN MX 10 mail.example.com. example.com. IN MX 100 mailhandler.com • PTR: maps IP to name • 6.1.36.36.in-addr.arpa. IN PTR example.com • TXT: arbitrary text strings up to 255 characters long

35. Sender Policy Framework • Domains: • Identify which machines are allowed to send e-mail from that domain • Add this info as a TXT record to their DNS info • Receivers: • Must request and use SPF records

36. Sender Policy Framework • An example SPF record: “v=spf1 a mx a:127.0.0.1 a:my.resolved.ip.com ptr –all” • General format: • v=spf1 [[pre] type ] ... [mod] • Pre: specifies the result from a particular test • + : Pass (Default) • - : Fail • ~ : Softfail • ? : Neutral

37. Sender Policy Framework • Type: • include:domain • replace sender domain with given domain • Use SPF record for that domain • all: • Represents all other conditions • a, a:domain, a:domain/cidr, a/cidr • Requires an A record in DNS for sender domain • mx, mx:domain,mx:domain/cidr, mx/cidr • Requires an MX record in DNS for sender domain

38. Sender Policy Framework • Type: • ptr, ptr:domain • Requires a PTR record in DNS for sender IP • ip4:ipv4, ip4:ipv4/cidr • Used for defining valid IPv4s or IPv4 ranges • ip6:ipv6, ip6:ipv6/cidr • Used for defining valid IPv4s or IPv4 ranges • exists:domain • Requires existence of the domain

39. Sender Policy Framework • Mod: • redirect=domain • Redirects to SPF of indicated domain • Functionally equivalent to include • Can also be used after all to use redirect if all tests fail • exp=TXT-RR • Should come last in an SPF record • Defines a DNS name whose TXT records may be returned as error messages

40. Sender Policy Framework • Examples • Only allow mail.example.com to send for example.com • A receving MTA may also make an IP comparison • example.com. IN MX 10 mail.example.com. • mail.example.com. IN A 192.168.0.4 • example.com. IN TXT "v=spf1 mx –all" • mail.example.com. IN TXT "v=spf1 a -all"

41. Sender Policy Framework • Examples • Uses virtual domain • Defines a valid IP range: • 192.168.0.0 – 192.168.0.31 • vhost1.com. IN MX 10 mail.example.com • vhost1.com. IN TXT • "v=spf1 include:example.com -all" • example.com. IN MX 10 mail.example.com. • example.com. IN TXT • "v=spf1 ip4:192.168.0.3/27 -all" • mail.example.com. IN TXT • "v=spf1 ip4:192.168.0.3/27 -all"

42. Internal SMTP Issues • Vrfy name • Used to verify if a mailbox with the given name exists in an SMTP server • Expn maillist-name • Used to expand the members of the given maillist name • Both sources of e-mail address for spammers • Must be disabled

43. Sendmail • An open source mail transfer agent • Original version written by Eric Allman in 1980’s at UC Berkeley • Descendant of ARPANET delivermail • Very flexible • Supports different transfer and delivery protocols • Very complicated • Difficult to manage • Configured using sendmail.cf, sendmail.mc • Unfortunately, known for it’s bugs

44. Sendmail • Security measures: • Sendmail restricted shell: smrsh • Standard security checks • SMTP AUTH • SMTP STARTTLS • Rejecting SPAM • Access database • Anti-spamming relay features • Validating senders

45. Sendmail • Configuring sendmail • /etc/mail/sendmail.cf • Actual configuration file • /etc/mail/sendmail.mc • More user friendly configuration file • Make sendmail.cf from sendmail.mc • m4 /usr/local/share/sendmail/cf/m4/cf.m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

46. Sendmail • Turning off exploitable features • Find the line in sendmail.cf that contains • O PrivacyOptions= • Add noexpn and novrfy • O PrivacyOptions=noexpn novrfy • Most strict : goaway • Or set the confPRIVACY_FLAGS in sendmail.mc • define(`confPRIVACY_FLAGS’, `goaway, noexpn, novrfy, nobodyreturn’)

47. Sendmail • SMTP server banner • May give away system info • 220 192.168.1.1 ESMTP Sendmail 8.10.2+Sun/8.10.2; Tue,14 Jan 2003 09: 28:02-0500 (EST) • Change SmtpGreetingMessage field in sendmail.cf

48. Sendmail • Precautions against DoS attacks, in sendmail.mc: • Set confMAX_MESSAGE_SIZE to limit message size • Set confMAX_DAEMON_CHILDREN to limit number of processes • Does not prevent DoS attacks

49. Sendmail • Controlled SMTP relaying in sendmail: FEATURE(access_db) • List the domains you are willing to relay from in /etc/mail/relay-domains • FEATURE(relay_hosts_only) • Hosts must also be listed • FEATURE(relay_entire_domain) • Relay all computers in domain • FEATURE(access_db) • Enables or disables access database • FEATURE(blacklist_recipients) • Also look up recipients in access database

50. Sendmail • Controlled SMTP relaying in sendmail: • List the domains you are willing to relay from in /etc/mail/relay-domains • FEATURE(dnsbl) • Use realtime black hole list at mail-abuse.org • 1.5.5.192.blackholes.mail-abuse.org  IN A 127.0.0.2 • FEATURE(accept_unqualified_senders) • Allow users without domains • FEATURE(accept_unresolvable_domains) • Allow users with unresolvable domains • FEATURE(relay_based_on_MX) • Permit any relay directed to your host