感觉十月份大部分时间都在干这一件事情，15天的比赛（关键是这之后还有7天realword），真的卷烂了，我没见过这么卷的场面，我中间一度差点看伪造邮件的东西看吐了。我只是个没有感情发垃圾邮件机器人，以及人肉Fuzz工具，真的连续发了半个月的垃圾邮件，所以自动化改变生活。
淦，那种测试岗不会其实天天就是干这种事情吧，重复且没有技术含量。
参考文献
这一部分是这次比赛主要看的一些资料，其实看完这些东西基本上就足够了。
这是第一篇讲邮件伪造方面的论文，从邮件安全协议到如何攻击都讲的很清楚，读完这篇文章能对整个邮件系统有一定的了解。
这篇文章在前一篇基础上提了很多新的UI绕过方法，例如在From字段中插入一些字符。这篇论文中提出的攻击模型也非常有意思。
两篇论文都在github开源了相关工具，2020年的叫espoofer，2021年的叫emailtesttools(比赛期间下架了)。在后期想实现自动化测试的时候对两个工具的源码都看了一遍，emailtesttools的确做的会更成熟一些，也开源了Fuzz部分相关代码。但是使用起来还是swaks最容易上手。
[3] 邮件伪造组合拳
我最喜欢的一篇参考文献，其实是依据2020年那篇论文写的，没办法我们碎片人就是只能看技术博客，不能看论文的。
因为去年Coremail比赛的时候，看这篇博客比看论文还认真，所以第一题找伪造邮件没找全，还被评审说看论文不认真。
[3] Swaks
这可是邮件系统测试的瑞士军刀！
好的，弄懂参考文献就基本掌握了核心技术，明年Datacon邮件安全前三没你我不信。
必要知识
首先需要了解发邮件过程中的一些重要的字段和邮件安全策略。
邮件相关字段
From
由MUA(mail user agent)显示的发件人地址。
Mail From
SMTP认证中的发件人，并指定在传送邮件过程中出现任何问题（例如未送达通知）时发送返回通知的地址，该地址通常不显示。
Sender
用于在“From”中有多个地址时标识真正的发件人。
这里可以简单将Mail From理解为信封外填写的发件人，From是信中填写的发件人。
安全协议
SPF(Sender Policy Framework)
SPF 记录是一个 DNS 记录，通过验证发出电子邮件的域的域名，帮助阻止欺骗和钓鱼。SPF 根据发送域的可疑所有者来验证发件人的 IP 地址，从而验证电子邮件的来源。
SPF主要对HELO和Mail From字段进行验证，其中HELO字段并非必需的字段，一般在Mail From为空的情况下，会使用HELO进行验证。
DKIM(DomainKeys Identified Mail)
邮件发送方发送邮件时，利用本域私钥加密邮件生成DKIM-Signature，将DKIM-Signature及其相关信息插入邮件头。邮件接收方接收邮件时，通过DNS查询获得公钥，验证邮件DKIM签名的有效性。从而确认在邮件发送的过程中，防止邮件被恶意篡改，保证邮件内容的完整性。
DKIM签名结构如下所示：
1 | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; |
a：签名算法
c：用于对标头和正文的算法规范化，simple&relaxed
d：是这一个域的签名。在DMARC检查签名中的域是否和发送者的域相匹配中用到
q：定义用于检索DKIM公钥的查询方法。它不必存在，默认为“ dns / txt”
s：在DNS中寻找RSA密钥的参数
h：应该包含在签名中的邮件头字段列表
bh：邮件正文的hash
b：是签名本身的核心，包括’h’给出的字段，以及DKIM-Signature头本身(视b=为空)
DMARC(Domain-based Message Authentication, Reporting & Conformance)
SPF对Mail From来源IP进行了验证，DKIM保证内容不被篡改，但是显示在MUA的From字段并没有被保护，DMARC就是在SPF、DKIM两种策略的基础上实施，为解决From字段被伪造的问题提出的。
接收邮件时，接收邮件服务器会查询 From 标头中的域以获取其 DMARC 策略，该策略指定接收者应对邮件执行的操作。这里需要注意的是，DMARC策略不是收件服务器定的，而是声明的域定的。
查询某个邮件服务厂商DMARC是否设置，以及策略：
1 | dig +short txt _dmarc.qq.com |
接收服务器执行标识符对齐机制，以检查 From 头中的域是否与 SPF 或 DKIM 验证的域名匹配。对齐机制有两种模式：严格和宽松。在严格模式下，From 头域需要与 SPF 或 DKIM 认证的标识符完全匹配。在宽松模式（默认模式）下，只需要拥有相同的注册域。如果 SPF 或 DKIM 均为pass，并且发件人域通过对齐测试，则电子邮件通过 DMARC 身份验证。对于转发的电子邮件：SPF 可能会为fail，但 DKIM 会继续存在。如果两者都为fail，服务器将强制执行域所有者指定的 DMARC 策略，例如拒绝电子邮件和发送失败报告。
Swaks
swaks是一个SMTP测试工具。通过swaks --to user@example.com --server test-server.example.net就可以发送邮件，并且工具本身提供了其他参数可供修改，下面是伪造邮件常用的参数。
1 | --from <Mail from> |
邮件分发过程
2021年的论文将邮件传输过程中的认证分为四个部分，上面这张图基本上就是整个邮件的分发过程。
邮件发送鉴权
发件客户端在整个邮件安全策略中也起着非常重要的作用，在这里是指，发送者MTA(Mail Transport Agent)会对Mail From和认证账号进行一致性检测。
那么在具体伪造过程中，如果邮件发送客户端进行了鉴权的话，用户在伪造邮件的时候无法对mail from字段随意修改，直观一点就是使用swaks的时候–from字段无法被直接修改为admin@mail.com，会要求–from和–au相同。
1 | swaks --to victim@mail.com --from attack@mail.com --server mail.con --ap password --au attack@mail.com |
邮件接收认证
接收认证就是指SPF、DKIM和DMARC这些安全协议。
邮件转发认证
这一个过程是针对邮件自动转发的认证，在转发过程中添加一个新的DKIM验证。
邮件UI渲染
UI渲染主要是指在客户端展现给用户的界面，这里一般比较关注From字段。其实这一步是保证邮件安全环节中很重要的一步，但是也比较容易忽视。其实目前很多厂商有做代发提醒，或者显示邮件发件方无法确认。有了UI提示之后，还是要依靠用户本身的安全意识来辨别，但是添加相关安全提示之后，我觉得是会大大提高用户警惕心。
邮件伪造攻击模型
2021年的论文中将邮件伪造的攻击模型分成了三种：共享MTA攻击、直接MTA攻击和转发MTA攻击。
共享MTA攻击
同一个域内进行发件人伪造，因为发件的MTA有spf记录，所以一般能绕过spf验证。
直接MTA攻击
前一部分提到，发件人MTA也是需要进行一个检查的，如果有检查机制的话，就会使Mail From很难伪造，所以攻击者会考虑使用自己的邮件发件服务器，把Mail From 和From都进行篡改。
转发MTA攻击
利用的是邮件的转发功能，这种攻击方法结合了前两种攻击方法的优势。
邮件伪造实践
这里可以把邮件伪造的方法分为两大类，一类是绕过安全协议，一类是利用UI渲染的差异性。
一般的话绕过安全协议本身难度会比较大，更多的是利用UI渲染的漏洞来进行一些伪造。邮件伪造组合拳这篇文章把各种攻击方式都讲的比较通俗易懂了，当然更全的还是需要去看2020年的论文，里面大概包含了16种攻击方法，实践中还能将多种攻击方法进行组合。除此之外，了解安全协议的原理才能对协议进行绕过，所以在看欺骗的各种方法之前，可以先了解安全协议校验的方法和具体验证的字段。
这里可能没有办法概括很多情况，只提一下遇到的情况，并且因为没有自己搭邮件服务器，所以都只能用现成的邮箱来进行伪造。
SPF绕过
spf会检测发件人ip和Mail From中的域名是否匹配。那么当我们拥有a.com的邮箱之后，使用a.com的MTA发件的话，SPF是为pass的，因为邮件由合法的ip发出。我们可以尝试修改Mail From为admin@a.com，在a.com没有对发件进行严格的检测时，这种伪造方法是可行的。
但是这种方法只能伪造a.com下的账户，并且要求发件人MTA不进行严格的检查，通常接收端MUA(mail user agent)还会显示代发提醒。
DKIM绕过
邮件伪造组合拳中的重放攻击部分就讲的关于DKIM的绕过。
DKIM的h=中说明DKIM签名的字段，并且From是一定要在签名里面的。
但是如果有好几个标头，例如From，DKIM签名的是最后一个标头，但MUA显示的可能是第一个。
DKIM中的l=字段是规定的签名body的长度，在这种情况下就可以在后面附加一些内容。
UI渲染绕过
如果伪造邮件是想进行诈骗和钓鱼的话，MUA中显示的发件人是攻击者最想伪造的部分，MUA显示的发件人地址是From字段，而各大邮件系统对From字段的解析可以说是漏洞百出。2020年和2021年的两篇论文都有很多修改From字段进行攻击的案例，在这些基础上发散一下，可能还会有更多新的方法。
过严的安全规则一般带来的比较烂的用户体验，两者之间的权衡还是很微妙的。但是邮件厂商在MUA里面多加一些安全提醒还是非常非常有必要的，毕竟安全这种东西完全依靠用户的安全意识也太扯了。
最后在思考，把From字段当作用户输入一样处理，邮件厂商过滤一下From字段里面的奇怪字符会带来什么坏处吗（真的没有阴阳怪气）？目前好像还没有看见厂商在做，按理来说UI渲染的问题应该没有这么棘手才对。