邮件安全之发件人伪造

电子邮件工作原理

电子邮件传输过程中主要涉及到SMTP、IMAP、POP3三种协议，具体功能如下：

SMTP:全称Simple Mail Transfer Protocol，即简单邮件传输协议，主要用于发送邮件，使用端口号25。

IMAP:全称Internet Mail Access Protocol，即交互式邮件存取协议，主要用于收取邮件，使用端口143

POP3:全称Post Office Protocol-Version 3，即邮局协议，主要用于收取邮件，使用端口110。

电子邮件工作的整个过程如下图所示：

POP3与IMAP协议：

POP3和IMAP功能类似，主要用于收件方查看、管理收到的邮件，但是POP3协议具有只能从服务器端将用户的邮件下载到本地进行管理，并且同时会删除服务器端的邮件，而IMAP则可以不对全部邮件下载，直接在服务器上进行查看和其他操作。

SMTP发件过程

工作机制

SMTP通常有两种工作模式。发送SMTP和接收SMTP。具体工作方式为：发送SMTP在接收到用户的邮件请求后，判断此邮件是否为本地邮件，若是则直接投送到用户的邮箱，否则向DNS查询远端邮件服务器的MX记录，并建立与远端接收SMTP之间的一个双向传送通道，此后SMTP命令由发送SMTP发出，由接收SMTP接收，而应答则反方向传送。一旦传送通道建立，SMTP发送者发送MAIL命令指明邮件发送者。如果SMTP接收者可以接收邮件则返回OK应答。SMTP发送者再发出RCPT命令确认邮件是否接收到。如果SMTP接收者接收，则返回OK应答；如果不能接收到，则发出拒绝接收应答（但不中止整个邮件操作），双方将如此反复多次。当接收者收到全部邮件后会接收到特别的序列，接收者成功处理了邮件，则返回OK应答。

注意：SMTP发送只负责将邮件发送到目标服务器上，而不是直接投递给接受者的邮箱，接受者是通过使用其身份登录到服务器上才仅进行的邮件操作。

服务器查找

在接收到用户的邮件请求后，如果判断不是本地邮件，则要进行请求邮件发送方的邮件服务器查找，查找过程如下：

查找邮箱后缀域名的MX记录所指向的域名地址
根据指向域名地址通过dns查找域名地址指向的服务器ip
tcp连接服务器ip：25（默认端口)（用来登陆或者发送）

完成服务器查找后直接进行后续的登录发送操作即可。

交互过程

>>> telnet smtp.163.com 25【tcp连接】
220 163.com Anti-spam GT for Coremail System (163com[20141201])【欢迎信息】
>>> HELO 163.com
250 OK
>>> auth login【请求登陆】
334 dXNlcm5dhbWU6【要求用户名】
>>> Z3dfdsaffEDF=【输入base64用户名】
334 UGFzc3ddvcmQ6【要求密码】
>>> fdasDSDFFFfDS=【输入base64密码】
235 Authentication successful【登陆成功】
>>> MAIL FROM:xxx@163.com【发件地址】
rcpt to:xxx@163.com【收件地址】
>>> DATA【data命令，要求发送内容】
354 End data with .【提示信息，以.作为结束符号】
>>> FROM:gule11@163.com【要显示的发件地址】
>>> TO:xxx@163.com【要显示的收件地址】
>>> helllo world【内容】
>>> .【结束】
250 Mail OK queued as smtp13,EcCowABHIv39riFXqUpKBA—.47592S3 1461825582【返回发送状态，我的测试不幸进入垃圾邮件】
>>> QUIT【退出命令】
221 Bye

SMTP常见命令

SMTP命令不区分大小写，但参数区分大小写。常用命令如下：

HELO ——向服务器标识用户身份发送者能欺骗、说谎，但一般情况下服务器都能检测到
RCPT TO: ——用来标志邮件接收者的地址，常用在MAIL FROM后，可以有多个RCPT TO
DATA ——将之后的数据作为数据发送，以.标志数据的结尾
REST ——重置会话，当前传输被取消
NOOP ——要求服务器返回OK应答，一般用作测试
QUIT ——结束会话
VRFY ——验证指定的邮箱是否存在，由于安全方面的原因，服务器大多禁止此命令
EXPN ——验证给定的邮箱列表是否存在，由于安全方面的原因，服务器大多禁止此命令
HELP ——查询服务器支持什么命令

SMTP协议存在的缺陷

电子邮件邮件身份验证技术

SMTP不支持邮件加密、完整性校验和验证发件人身份。由于这些缺陷, 发送方电子邮件信息可能会被网络传输中的监听者截取流量读取消息内容导致隐私泄漏, 也可能遭受中间人攻击(Man-in-the-Middle attack, MitM)导致邮件消息篡改, 带来网络钓鱼攻击,邮件的身份验证 –> SPF, DKIM, DMARC

1.SPF

SPF，全称为 Sender Policy Framework，即发件人策略框架。根据 SMTP 的规则，发件人的邮箱地址是可以由发信方任意声明的,这显然是极不安全的。

SPF 出现的目的，就是为了防止随意伪造发件人。

原理

SPF 记录实际上是服务器的一个 DNS 记录，使用电子邮件的头部信息中的 ‘HELO’ 或 ‘Mail From’ 这两个邮件头里的域名来结合真正提供这个邮件的服务商 DNS 里面的记录去验证发送邮件服务器是否是冒充行为。原理其实很简单：

假设邮件服务器收到了一封邮件，来自主机的 IP 是173.194.72.103，并且声称发件人为email@example.com。为了确认发件人不是伪造的，邮件服务器会去查询example.com的 SPF 记录。如果该域的 SPF 记录设置允许 IP 为173.194.72.103的主机发送邮件，则服务器就认为这封邮件是合法的；如果不允许，则通常会退信，或将其标记为垃圾/仿冒邮件。

因为不怀好心的人虽然可以「声称」他的邮件来自example.com，但是他却无权操作example.com的 DNS 记录；同时他也无法伪造自己的 IP 地址。因此 SPF 是很有效的，当前基本上所有的邮件服务提供商（例如 Gmail、QQ 邮箱等）都会验证它。

记录查询

spf记录本质上是服务器上的TXT类型的DNS记录，因此要查询SPF记录只需要使用dig命令进行查询：

1
2
3

>> dig -t txt 163.com		# 查询163邮箱的spf
ANSWER SECTION:
163.com.		1160	IN	TXT	"v=spf1 include:spf.163.com -all"  # 其中的一条记录,代表了spf规则遵从spf.163.com的，在其中没有包含的都不允许接收

以查询xxx@163.com的spf记录为例，完整的查询过程如下：

>> dig -t txt 163.com		# 查询163邮箱的spf
ANSWER SECTION:
163.com.		1160	IN	TXT	"v=spf1 include:spf.163.com -all"  # 其中的一条记录,代表了spf规则遵从spf.163.com的，在其中没有包含的都不允许接收
>> dig -t txt spf.163.com 
ANSWER SECTION:
spf.163.com.		7283	IN	TXT	"v=spf1 include:a.spf.163.com include:b.spf.163.com include:c.spf.163.com include:d.spf.163.com include:e.spf.163.com -all"   # spf规则为a、b、c、d、e几个域名spf规则的和
>> dig -t txt a.spf.163.com   # 这里以a.spf.163.com为例，实际上还应对其他4个域名的spf记录进行访问
ANSWER SECTION:
a.spf.163.com.		60	IN	TXT	"v=spf1 ip4:220.181.12.0/22 ip4:220.181.31.0/24 ip4:123.125.50.0/24 ip4:220.181.72.0/24 ip4:123.58.178.0/24 ip4:123.58.177.0/24 ip4:113.108.225.0/24 ip4:218.107.63.0/24 ip4:123.58.189.128/25 ip4:123.126.96.0/24 ip4:123.126.97.0/24 -all"     # 明确了可以接收的ip地址

生效时间

SPF 记录本质上是一个 DNS 记录，所以并不是修改之后立即生效的——通常需要几个小时的时间。

人工检测通过SPF验证**

这里可以使用一个在线验证网站进行查询：SPF Record Testing Tools

首先对邮箱服务器对应的SPF记录进行查询（当然这里也可以使用dig命令进行手动查询）：

查询结果如下：

输入IP、spf记录、发送域名、HELO内容进行SPF验证。

最终查询结果如下：

Results - PASS sender SPF authorized表示验证成功。验证失败则显示为Results - FAIL Message may be rejected

SPF存在的缺陷：

与邮件转发器不兼容，转发电子邮件时，SPF检查可能会失败，因为SPF组件会对转发服务器（而不是原始发送服务器）进行身份验证。

2.DKIM

DKIM全称DomainKeys Identified Mail，DKIM使用加密技术对发件人的身份进行验证，并对邮件完整性进行保护。

启用DKIM的服务器当发送邮件时，邮件发送方生成一个DKIM-Signature，并使用私钥进行进行加密，并附在邮件的DATA部分的header中，当目标邮件服务器收到邮件后，将使用查询DKIM-Signature中的d字段，获取发送者的公钥，并验证DKIM有效性。

其中：

d ：代表发送者的域名
h : 代表DKIM覆盖的头部字段列表
l ：代表DKIM保证的有近头部长度

3.DMARC

DMARC是建立在SPF和DKIM之上的一种身份验证机制，在使用DMARC机制的邮件服务器中，接收邮件时，接收邮件服务器首先查询From字段所对应的域的DMARC策略，获知应该如何处理认证失败的邮件，

身份对齐验证：检查From字段中的域与SPF或DKIM中的域是否匹配
严格模式：From中的域名需要与SPF、DKIM中的域名完全一致
宽松模式：只需要From中的注册域名（@后面的部分）与SPF、DKIM中保持一致

SPF
DKIM

如果SPF或DKIM显示一个积极的结果，并且From中身份认证对齐成功，那么DMARC身份认证通过。DMARC身份认证比单独使用SPF或DKIM的鲁棒性更强，对于转发的电子邮件，SPF认证可能会失败，但是DKIM能够正常认证，DMARC还是能够正常通过。只有当两者都全部认证失败或身份对齐失败才会认为DMARC认证失败。

SPF、DKIM认证的结果将显示在Authentication-Results中，DMARC将从中解析域名来与文件内容中的FORM字段进行对齐验证。

身份认证机制本身存在的问题

虽然身份验证机制看起来很美好，但是在实际使用中由于身份认证本身存在的一些缺陷，仍然使攻击者能够通过一定的技术手段绕过认证，发送伪造邮件。

在身份认证保护下依旧产生发件人伪造的原因

不同身份认证组件之间的解释使用
邮件服务器和邮件客户端对特殊格式的不同解析
例如5节

1.HELO、MAIL FROM混乱

SMTP提供了HELO和MAIL FROM两个字段来表示发件人的邮箱地址，SPF标准指出应当同时对两者进行验证，但是，检查MAIL FROM是强制的，而HELO只是推荐进行检查。

DMARC标准指出DMARC验证应该使用MAIL FROM进行，当MAIL FROM为空才使用HELO进行验证。利用上面这两种机制，可使用下面的两种机制进行发件人欺骗：

1.1 不存在子域名

这种攻击方式如下图所示，MAIL FROM输入为合法域名下的不存在子域名，因为不存在子域名的SPF策略，SPF无法对其进行验证，转而使用HELO字段进行SPF验证，而HELO字段是攻击者可以进行任意设置的，因此可以通过SPF验证；同时，因为MAIL FROm地址不为空，DMARC将继续使用MAIL FROM进行域对齐，因为二级域名为合法域，与FORM字段域名相同，因此DMARC域名对齐验证通过。邮件成功绕过DMARC身份认证。

1.2 “空” MAIL FROM

在某些SPF实现中，将对(右侧内容视作注释内容，因此当使用(any@legitimate.com作为MAIL FROM地址时，SPF会将其视为空，然后使用HELO字段进行SPF验证，与上面相同，SPF通过验证并将验证结果传递给DMARC，在某些DMARC的验证中，仅仅将其视为普通地址进行与FROM域名进行域对齐身份验证，成功通过DMARC验证。

2. 身份验证组件与DNS组件不一致性

这种身份认证绕过方式利用了身份认证组件和DNS组件之间的不一致性，攻击者制作模糊域，使身份验证组件认为他正在查询合法域，但DNS组件实际上在查询攻击者的域以获得策略记录。

下图展示了这种攻击的实例，在C语言中，NUL(“\x00”)被认为是终止符，而在Perl和PHP中，将不被视为终止符，利用这种特性，攻击者对任意电子邮件可以构造绕过身份认证，首先他们使用自己的私有DKIM对邮件进行签名、生成DKIM-Signature标头，将标头中的d="legitimate.com"，而s="atttacker.com.\x00.any",当Gmail服务器（Gmail服务器存在该问题）其DKIM组件查询s._domiankey.d，即attack.com.\x00.any._domainkey.legitimate来获取公钥，DNS组件进行对改地址进行解析时会将NUL字符视为终止符，因此将从attack.com获取公钥（攻击者的公钥），然后DKIM组件使用攻击者的公钥验证伪造邮件，错误的认为合法域名已经对该域进行可签名。另一方面，DMARC将使用d=legitimate.com域名与FORM域名对齐认证，二者相同，成功通过DMARC认证。

3. 认证结果注入

Authentication-Results

SPF和DKIM以头部中的Authentication-Results将验证结果传递给DMARC组件，下面为Authentication-Results实例：

其中spf=pass和dkim=pass表示邮件服务器通过了example.com的spf和dkim认证，smtp.mailfrom表示SPF组件验证的域名，header.d表示DKIM验证的域名，括号内的内容为备注。DMARC组件解析这个字段来进行DMAR域名对齐认证。

认证结果注入攻击

这种身份认证的绕过方式来源于认证结果从一个组件传递到另一个组件的过程中，元字符的存在因起了身份认证类似于SQLi的攻击。对于某些特殊字符，SPF和DKIM会将这些字符视为数据，而DMARC组件在解析认证结果时将会将其视为控制信息，从而发生攻击。

3.1 DKIM认证结果注入

攻击者使用自己的私钥生成DKIM-Signature标头，在标头中使用带（的d=，例如在下例中，d=legitimate.com(.attacker.com,DKIM组件将查询selector._domainkey.legitimate.com(. attacker.com,该域名在攻击者的控制之下，获取攻击者的公钥并通过dkim验证，返回的结果如下：

当DMARC收到Authentication-Results，对d=xxx进行解析时，将会将其解析为legitmate.com,因为会将“（”后的内容视为注释，同时DMARC中解析到的域名与FORM标头匹配，成功通过DMARC身份认证。

“（双引号）和‘（单引号）与”(”具有相同的效果

3.2 SPF认证结果注入

SPF认证结果注入与DKIM认证结果注入与DKIM结果认证类似，攻击者在MAIL FROM中使用相同的网址SPF认证注入攻击，例如下面的SPF认证结果注入。

在一些邮件服务器中，对MAIL FROM的语法进行了一定的限制，MIAL FROM中不再能使用上面的特殊字符，但是我们可以使用另一种方式来进行SPF认证结果注入，如下图所示，邮件服务器进行SPF查询时将使用legitimate.com'@a.attack.com进行查询，该域名的SPF记录为攻击者设定，因此伪造的邮件能够成功通过SPF验证，而DMARC进行身份验证结果解析时，将'后的内容视为注释，使用域名legitimate.com与MAIL FROM域名进行对齐，成功通过DMARC认证。

UI不匹配问题

由于电子邮件服务和邮件代理（MUA）分别处理消息，UI不匹配攻击利用了电子邮件服务器验证消息和MUA最终展示给用户的内容不一致来进行欺骗。

1.From头模糊

经过研究发现，虽然SMTP标注中明确指出了电子邮件必须具有一个From header，但是仍存在大量电子邮件提供商和邮件代理并没有严格遵守这项规定，不会拒收这类邮件而是只是用第一个From header进行DMARC检查，这就造成了攻击者进行欺骗留下了机会。

1.1 多个From header

这种攻击方式，首先邮件服务器需要与许多个From header，其次邮件服务器与电子邮件客户端需要具有不同的解析方式。攻击者在使用多个From header，例如上图中服务器使用第一个From字段进行DMARC对齐认证，而电子邮件客户端将第二个From header展示给用户。

1.2 使用空格跳过多From header检测

SMTP标准规定每个email头部由字段名、冒号、字段对应的值组成，攻击者可以通过字段名之前或之后插入空格来违反此结构，那么不同的客户端、服务器将使用不同方式处理错误的标头，这为禁止使用多个From的邮件服务器使用多From header绕过认证提供了新的机会。

情形一：

虽然邮件服务器拒绝使用多个From头的电子邮件，但是攻击者使用折叠空间成功的From头绕过。因为服务器的DMARC组件可以识别出成功折叠的From头，验证attack.com，但是邮件代理客户端却将其作为未知头，而不是From头，因此将展示它认为只有一个From字段，即admin@legitimate.com，因此将admin@legitimate.com展示给客户。

这种情况要求请求邮件服务器能够成功识别出From头，而邮件代理客户端不能识别。

情形二：

我们也可以利用电子邮件服务器进行邮件转发时特殊的行为来欺骗邮件代理客户端。以下图为例，Fastmail.com邮件服务器和Fastmail.com邮件代理客户端否无法识别包含空格的From header，而是将其当做前一个From的一部分进行处理，但是Fastmail.com邮件服务器对成功读取到的From header将进行规范化，即再转发邮件时删除其中的空格。这样MUA收到的邮件为标准的多From header问题。

情形三：利用备用From header

在SMTP标准中，包含多个标识电子邮件发件人的角色，From代表编写消息的用户，Sender代表提交消息的用户，Resent-From代表代表转发消息的用户，通常只有From字段才在电子邮件认证和现实中起作用，但是如果攻击者故意制作没有From或无法识别的From字段，在某些情况下如果无法识别From字段，则使用备用头来标识发件人。

在测试的邮件服务器中，当无法读取到From字段时，Gmail显示resent-From来作为发件人展示，其他的都是只使用From进行DMARC认证，如果没有From字段，那么将不执行DMARC认证或返回None。

如下面所示，Naver.com（电子邮件服务器）能够识别空格折叠的From头，认证attack值，但是Outlook(代理邮件客户端)无法识别它，因此将展示备用头Sender，造成发件人欺骗。

情形四：利用多种技术的融合来绕过更加严格的身份认证

攻击者还可以使用多种技术融合来绕过更加复杂的身份验证，例如对于身份验证严格的Gmail邮件服务器，它拒绝多个From头，如果不存在From头邮件服务器将则根据MAIL From的值添加一个新的From头，攻击者同样可以使用多种技术的融合绕过，完成欺骗。

绕过方式如上图所示，首先在邮件的第一个头部字段使用前置空格的From字段，Resent-From作为备用的发件人字段，MAIL FROM使用空值。Gmail邮件服务器能够正确识别出折叠空格的From字段的内容，进行DMARC认证，然后在邮件的头部添加Authentication-results，这将导致MUA将From解析成为一个折叠的内容，即Authentication-results的一部分，随后它将按照MAIL Form的值添加一个From字段，这里新添的From字段为空，因此MUA将忽略From，使用Resent-From进行展示，成功进行发件人欺骗。