What is Mailsploit?
Mailsploit is an attack against a vulnerability on the mail client side, which can be spoofed by the sender's mail address, published on the web on December 7, 2017.
Easy to disguise sender's email address in the first place
As you know, sending mail is done using the SMTP protocol.Since the sender mail address is information that is basically used when you want to reply, the SMTP protocol itself does not mind "whether the sender's e-mail address is spoofed" when it is received.
In SMTP there are two places to describe the sender's mail address.One is a mail address to notify by "MAIL FROM" command after "HELO" command after establishing TCP connection, also called " envelope FROM ".The other is the email address to notify in the FROM: line of the content header, also called " header FROM".
"Header FROM" is information displayed as when viewed from the mail client.It is the same position as the body of the mail, it is not used in SMTP communication.Therefore it can easily be disguised.
"Envelope FROM", on the other hand, is treated as a source of SMTP communication.For example, if a destination mail address does not exist and an error mail returns, it will be addressed to "Envelope FROM".However, since others are positioned so as not to be "header FROM", they could easily be disguised in the same way, but recently it became information used by sender domain authentication technology such as SMTP AUTH, DKIM, SPF / SenderID which will be described later.
The figure below shows an example of sending by faking the mail address of nesuke.com from the mail server of yahoo.com.
Technology to prevent e-mail address camouflage
The way to stop imitation mail address on sending side
In the past, we did not verify whether the sender's e-mail address is correct or not when sending e-mails. Therefore, it was a common story that you could fool your email address without permission. Now, in SMTP from a mail client to a mail server, authentication using SMTP AUTH is required, and authentication is also required to use the sender's mail address.
Also, in the past, there were also many mail servers that set up mail addresses outside your domain (so-called open relay) settings, and in some cases it became a stage for spam mails. In principle, SMTP relaying is performed by direct path from the domain to the destination domain in principle.
The way to stop imitation mail address on receiving side (2 transmission domain authentication technologies)
However, measures on the sending side are still not perfect. There is a mail server that accepts other than SMTP AUTH, and will continue to be created, intentionally or intentionally. Measures on the receiving side were also requested there. Currently, there are two Sender Domain Authentication Technologies, DKIM and SPF/SenderID as a countermeasure.
1. DKIM's Overview and advantages and disadvantages (standardized by RFC 4871, RFC 5672)
DKIM stands for Domain Keys Identified Mail, which is a standard made by integrating "Domain Keys" proposed by Yahoo and "IIM (Identified Internet Mail)" advocated by Cisco.
For example, consider sending mail from the sender's mail address yahoyaho@yahoo.com to the destination mail address sanfran@cisco.com. At this time, place the private key in the mail server of @yahoo.com and place the public key in the TXT record of the DNS server managing the yahoo.com domain. By doing this, you can check that the source is surely "@yahoo.com" on the cisco.com mail server.
Specifically, when sending mail, hash the body of the message with the private key at the @yahoo.com mail server, add it to the mail, and send it to the mail server at @cisco.com.
For example, you can check the public key of yahoo.com with the following command.
Please refer to here for the mechanism of public key / secret key.
The greatest merit of DKIM is that it can be confirmed that the envelope FROM is correct and also that it is not tampered with in the header, so by verifying whether the envelope FROM matches the header FROM, it is possible to confirm that both validity.
However, disadvantage is that it takes time and effort to set up.
2. SPF/SenderID's Overview and advantages and disadvantages of SPF / SenderID (Standardized by RFC 4408, RFC 4406)
SPF is an abbreviation for Sender Policy Framework and is a mail authentication technology proposed by Mr. Meng Wong. In addition, its upward compatible SenderID is a standard made by combining "Caller-ID for Email" and "SPF" proposed by Microsoft.
As both mechanisms, check whether "Source IP address of SMTP TCP connection" matches "IP address included in TXT record of source mail address of the Domain Authority DNS server".
As in the previous example, consider sending mail from the sender's mail address yahoyaho@yahoo.com to the destination mail address sanfran@cisco.com. In this case, set the source IP of the mail server of @yahoo.com in advance, SPF/SenderID in the TXT record of the DNS server that manages the yahoo.com domain.
Then, the mail server of yahoo.com establishes an SMTP session to the mail server of cisco.com, and at the timing that "the sender's e-mail address is yahoyaho@yahoo.com", you can check the validity of the sender's mail address by acquiring the TXT record of yahoo.com and comparing it with the SMTP sender IP.
In the case of yahoo.com, if you look up the TXT record of yahoo.com, it says "Look at the TXT record of _ spf.mail.yahoo.com", and if you look at the record, you can see "reverse yahoo.com , Or certify that it is correct if you reverse the yahoo.net. Since it comes from other IP, do not judge whether other IP is right or wrong. " is what it reads.
You can check the SPF information of yahoo.com with the following command.
The merit of SPF / SenderID is that it is easy to implement, but as a disadvantage, you can only check envelope FROM.
Option to implement both DKIM and SPF/SenderID
Because of its nature, e-mails are hard to discipline and truncate. Even if both DKIM and SPF/SenderID are authenticated, it can be said that it is correct rightly, but it can not be said that anything that could not be authenticated is wrong.
So it may be important to implement both DKIM and SPF/SenderID and increase opportunities to confirm that it is correct, as in the implementation of yahoo.com. It will eventually lead to an era where all can be correctly authenticated.
What to do with Mailsploit
Mailsploit is an attack that slips through anti-spoof mail prevention technology of "header FROM" by DKIM. This is due to the fact that the mail client does not correctly implement RFC 1342 (established in 1992), but the way it slips through is varied among mail clients.
Examples of iOS and MacOS are introduced at the site of this attack attack discover below.
"https://www.mailsploit.com/index" <- has been closed
Encoding of outgoing mail server
On the sending mail server, write the header From as follows. The point is "=? Utf-8? Q? = 00? =", Which is a NULL encoded version.
When the encoded character string enters using the base64_encode () function, it becomes as follows. @ Is ASCII, but @ disappears. We will send this via SMTP.
Decoding of incoming mail server
Decoding it will be as follows. Save this as a file in a file.
iOS (iPhone) Interpretation
On iPhone, loading (= NULL) will ignore the rest. Therefore, it interprets as follows.
MacOS interpretation
In MacOS, when you load, ignoring the previous one, reading the first correct e-mail address later and stopping processing. Therefore, it interprets as follows.
In this way, the mail client can not recognize "@mailsploit.com". So if you store the DKIM public key of the mailsploit.com domain in the TXT record of mailsploit.com's DNS server, you will complete the email impersonation. It is because such a defense can not be done by the mail client after slipping through the mail server's DKIM.
This is a summary of the mailsploit attack.
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント