E-mail security Flashcards
MHS
Message handling system: used worldwide.
MUA (Message User Agent): SW used by user to send mail.
MSA (Message Submission Agent): SW module with task of injecting the mail into the transport system.
MTA (Message Transfer Agent): the mail transport system is composed of MTAs arranged in a chain. The mail is given to the next MTA until it reaches destination.
Upon reaching destination, the email will be stored in the MS (Message Store).
Receiver will read the mail using MUA when they want. After replying, the reverse MSA will be different than the sending MSA, MTA chain will be different.
Email client-server mode
User has a program that has configured to have mail server or outgoing mail server. It uses SMTP to send mail, the user can close the program and the mail will be submitted, but it does not mean it will be received.
When someone sends a message, it will be injected in the MTA chain and finally be stored in the Post Office (MS, incoming mail server).
When a user wants to read mail, it asks the MS for incoming messages, the user can choose to leave a copy on the server or delete them. For security it’s better to delete, but Post Offices could have illegal copies.
Webmail
MUA is replaced by a web-browser. A virtual MUA is placed inside the web-server, that is automatically configured. An HTTP engine is placed in front of the MUA.
Not good for privacy.
Mail protocols, ports, formats
- SMTP (Simple Mail Transfer Protocol)
- 25/TCP (MTA)
- 587/TCP (MSA)
- POP (Post Office Protocol)
- 110/TCP
- IMAP (Internet Message Access Protocol)
- 143/TCP
- Formats:
- RFC-822: Message format (pure text body)
- MIME: Multimedia extension of RFC-822
RFC-822 Messages
Provides pure test mail with only US-ASCII characters on 7 bits (8th used for parity).
Lines must be terminated by (system independentness)
Messages composed of:
- Header:
- keywords at the begginning of the line
- Continuation lines start with a space
- Body
- Separated from the header by an empty line
- Contains message
*
RFC-822 header
Written in english.
From: logical sender, some applications allow changing it to an arbitrary value.
Sender: operational sender, usually is the same as From
Date is the time declared by the MUA, easy to forge
Received: contains list of MTAs traversed.
CC: carbon copies.
BCC: blind carbon copies
Return-Receipt-to: when the sender would like to receive an ack.
Issues in securing e-mail
- E-mail is connectionless, TLS won’t solve the problem
- Untrusted MTA’s
- Security of MS, where messages are stored.
- Mailing-list encryption:
- public key of destination is needed
- A lot of mails as recipient makes it hard to send encrypted mails.
- Compatibility with already installed SW
- Solution developed:
- lnternet: PGP, PEM, MOSS, S/MIME
- OSI: X.400
- Only survivors are PGP and S/MIME.
Mail spamming
- UBE or UCE (Unsolicited Bulk/Commercial E-mail)
- Used to sent unwanted messages: unauthorized advertisement, attacks (malware, phishing, …)
- Nearly 50% of all e-mail.
- Good mail is ham, not spam.
Spamming strategies
- Spammer hides real sender, but uses a valid one, so the recipient believes they can trust it.
- Spammer sends spam via special MTA named Open Mail Relay
- not well configured, such that they accept and forward email from anybody.
- Spammers also use zombies or botnets witi a variable phantom IP address (unassgigned)
-
Content obfuscation:
- Deliberate Mistakes (Vi@gra)
- Image rather than text (not detectable)
- Bayesian poisoning: insert text from a book at the end of the mail, so that the systems cannot detect different frequency patterns
- Inside an error message: spammers send fake error messages in the hope that they are not checked from antispamming software.
(Open) mail relay
Usually, where there is a domain, there’s also a domain relay.
Configured to accept outgoing mail only if they come from the same domain (e.g. polito.it). Accepts incoming mail only if final destination is the same domain (e.g. polito.it). This is the configuration of a not-open relay.
If the systems is misconfigured or restrictions are not applied, an external user can ask the relay to send email to the outside, the user might be a spammer. For this reason, the relay must distinguish from real from fake users.
Anti-spam for MSA
Restrict use of MSA to authorized users, which must be authenticated.
To authenticate users it is possible to use:
- IP address of the MUA:
- problem with mobile nodes, IP spoofing and malware installed in valid node
- Value of the field From
- ca be easily tricked with a fake mail
- SMTP authentication
- The most secure
Strategies:
- Reject or accept mail from an MTA after checking a blacklist or whitelist. Check DNSBL (DNS-based blacklist) which works like this:
- a request from MTA is received, the address is checked using nslookup -q=DOMAIN.dnsbl.antispam.net
- if NXDOMAIN == “no such domain” then it is not a spammer
- else the query returns an address: 127.0.0.X (X is a code providing the reason for the blacklisting) and a TXT record with more info.
- Instead of looking at the MTA, that is changed frequently by attackers, another strategy consists in looking up addresses contained in the text of the mail. If a message contains a URI (for phishing), then a look up is performed on DNSBL (URI reputation data). Some honeypots are placed just for capturing phising URIs.
DNSBL lists
There is a number of free/commercial/anonymous listS.
Lists are managed by people that are not easy to be contacted, thus URIs inserted are not easy to be removed. Configuring the MTA correctly is strongly suggested.
Activate/use the abuse@domain address as required by an RFC.
Anti-sapm for incoming MTA
-
Greylisting: since spammers are sending millions of messages, they have scarce time; they would like to send the message as soon as possible.
- when someone is contacted by an MTA a temporary error is given, if the MTA comes back in some time them it will be accepted. A spammer would usually skip those. This will delay also ham. Server will need to keep a history of contacts.
-
Nolisting: if greylisting is not possible.
- If more than one mail exchanger is defined for target domain is defined, typically spammers contact the mail exchanges that has got the highest prioroity.
- If we list at least 3 mail exchangers: first and last don’t answer. Then spammer will only try either the first or the last.
- Problem: this will delay ham.
DKIM
DomainKeys Identified Mail: strategy in which the sender uses a signature to guarantee:
- the identity of the sender
- partial integrity of the message
- Done through a digital signature, created by the MSA or outgoing MTA.
- Signature covers some headers and part of the body and it is verifying through a public key (tipycally insterted by DNS)
- Every mail sent from the mail relay of Polito mail server contains a signature where the Polito MTA says “This was sent by me and I have authenticated the user”.
- Thanks to it we can discard messages with a fake sender and hence support anti-spam and anti-phishing.
SPF
Sender Policy Framework: techniques that consists in declareing which are the outgoin MTA via specific DNS records.
Performing an nslookup on polito.it returns ‘v=spf1 ptr ~all’, which means that any node inside Polito that has a valid reverse address (for which a PTR record exists) is a valid sender of electronic mail, all means that everything should be accepted.
Performing an nslookup on google, gives us the address where to find the exact list of nodes that are outgoing mail servers for google. A mail coming from a google user could be rejected if it not coming from one of those servers.
ESMTP AUTH examples
ESMPT AUTH challenge-response methods
There are other methods than LOGIN and PLAIN (both sending cleartext passwords).
CRAM-MD5 and DIGEST-MD5 are symmetric challenge response methods.
CRAM-MD5
- Challenge = base64(nonce)
- Response = base64(usr SPACE HMAC-MD5(pwd, nonce)lowercase hex)
DIGEST-MD5
- Similar to HTTP/1.1 digest authentication
- Declared obsolete in 2011, replaced with SCRAM
SMTP Protection with TLS
STARTTLS = option for EHLO and command
If negotiation is successful, the protocol status is reset, it starts again from EHLO and the supported extensions can differ.
If the negotiation produces a security level below the threshold:
- The client sends immediately QUIT and closes the connection
- The server respons to each command with code 554 (refused due to low sercurity), since in SMTP the connection must always be terminated by the client.
Secure electronic mail formats
- IETF created:
- PEM: protected text messages
- MOSS: protected MIME-based messages
- S/MIME
- People who didn’t trust CA created PGP, then MIME-PGP
- Dept. of U.S. Def. + European Commision used X.400, nowdays they use S/MIME
PGP
Pretty-Good-Privacy:
- authentication, integrity and confidentiality system for eletronic mail or private files.
- Similar in organization to PEM, but less structured.
- Uses concept of trusted friends and trust-propagation algebra.
- Available in any system.
- OpenPGP is the continuation of the “free” project.
Certification:
- Each user that trusts another user, signs their public key.
- Trust is propagated transatively with some approx:
- completely, partially, untrusted, unknown
- To make a partial trust, at least 3 other partial trusted trusted are needed.
Distribution:
- Public keys are stored individually by each user.
- Keys are distributed by the onwer (PGP parties) or by a key-server (where the key and all attached signatures are put).
- If among the signatures there is someone trusted that says the key is trusted, then the system trusts it.
- Also possbile to distribute via X.500 and DNS.
MIME
Multipurpose Internet Mail Extensions
A way of encode e-mail when it contains various kinds of artifacts. it solves these problems:
- Makes it possible to use different data encodings, it is also possible not to use USA alphabets, long lines (more than 56 chars), and binary data
- Multipart format means that a message can contain different parts, and each part can have a different type.
- MIME is also a recursive format which means that any multipart object can contain multipart objects.
The last 2 features are used in security to perform digital signatures and encryption. Digital signatures and encryption require that pieces of data of interest are not modified while transmitted (things that could happen when MTA transmits), an appropriate encoding can avoid this.
Secure multimedia electronic mail
MOSS and S/MIME provide digital signatures and encryption capabilities with X.509 certificates to protect MIME messages.
Signing: a trailig part is added in the last position, by computing the encoding of the digital signature over all previous parts inside the message.
Encryption: message is considered as a single object and thanks to the recursive property of MIME an encrypted object is created. The encrypted object can be a signed message, so it is possible to have the original MIME object signed and encrypted.
MOSS standard
RFC-1847 is a MIME extension for message security to apply a digitial signature.
Requires to add a Content-Type field to the message that was multipart/signed with the specification of the protocol (digital signature applied) used, and micalg (used to compute mic code). Also the boundary (string separating two parts of MIME) must be included.
When applied, there are N parts, the N - 1 parts are those to be protected, while the last one contains the digital signature.
S/MIME algorithms v4.0
S/MIME examples
Encrypted: B64(P7_enveloped(msg))
Signed (only S/MIME users): B64(P7_signed(msg))
Singed (for any user): MIME(msg) + B64(P7_signed_detached(msg))
Signed and encrypted:
- B64(P7_enveloped(P7_signed(msg)))
- B64(P7_signed(P7_enveloped(msg)))
- preferred option since it is more resistant to DoS attacks: it is possible to heck integrity before decrypting the whole message.
msg notation === RFC-822 body of the message
Protecting Pull operation from the Post Office
Pull operation corresponds to checking if there’s any mail at the post office.
Properties needed:
- Authentication of the user: mail server mus tbe sure to dliver meail only to the user whom they belong.
- Server authentication: client must be sure that it is not receiving fake mails
-
Confidentiality/integrity of mail messages:
- on the server: this protection must be addressed by the receiver
- while in transit
If a message requires protection, the sender is responsible of applying S/MIME, this way the server is protected both on the servers (post office and intermediate MTAs) and in transit.
POP
Post office protocol: text-based protocol.
POP2: it didn’t support password-based authentication, not used.
POP3: not used, it provided in-clear password-based authentication.
APOP: user authentication only through challenge
- APOP command replaces set of commands USER + PASS
- challenge is in the hello line contained inside the angle brackets
- Syntax: APOP user response-to-challenge
- response = md5(challenge + pwd), then encoded in hexadecimal
K-POP: mutual authentication by means of tickets, but requires Kerberos.
