这一企图窃取用户名密码的网络“钓鱼”攻击事件本质上属于社会工程学的范畴。攻击者冒充 admin 的权威身份，向用户发送邮件，通过谎称不输入密码后头就无法使用邮箱向用户施加压力，很多不冷静的同学会中招。今天就来分析一下下，如有不正确的地方，欢迎斧正 
。
钓鱼行为分析
其实分析钓鱼邮件，有很多逻辑漏洞：
标题：《关于停用学生邮箱的通知》
学生 STU 邮箱自古已有，怎么可能停用，哪怕要停用，按照学校网信中心的惯例，也不会发邮件通知你的，顶多在 NIC 主页上发一则消息。
本通知发出后，未及时更新的学生帐号，1 周后（7 月 2 日）
账号将设置为“暂停”，即只能接收邮件，不能登录和发送邮件。
攻击者的逻辑都不能自洽：只能接收却不能登录和发送，然而不登录怎么能接收？
为了加强电子邮件安全管理，规范电子邮箱使用，保障师生权益，根据相关规定，未更新的学生账号 (@stu.xjtu.edu.cn）将被停用。
企图模仿权威口吻，但“相关规定”是哪些它并没有讲，而且它最后所附链接 https://coremail.club/ 的网站实在做得太 low 了，一点儿都没有体现那里有“加强电子邮件安全管理，规范电子邮箱使用”。
要是我来做的话，这封钓鱼邮件内容是说你的邮箱存在违规行为，需要点击某个链接以解决问题并修改密码，否则将予以封号处理。而且点击的链接肯定是一长串，带有用户名信息的链接，而不是这个攻击者用的如此简单的链接，连 xjtu.edu.cn 下面的子域名都不是（注意：以你交的 IT 技术水平，哪怕是官方域名也有钓鱼的可能，例如修改 DNS 记录、或者是在开放式无线网络中做 MITM 攻击）。
进入钓鱼网站后：
- 第一步，只让你输入邮箱地址（并且核验这个邮箱地址是不是邮件里的链接）不用输入密码以免你起疑心
- 第二步，说你有违规行为，所以要给你进行邮箱相关法律法规宣教；
- 第三步，问你是否仔细阅读并同意“电子邮箱使用规定”，如果是，请输入旧密码、设定新密码，以进行解封操作，此时网站后台连接 https://stu.xjtu.edu.cn 即真实的邮箱服务器，验证密码是否正确，如果是才给用户返回“成功”的讯息。这次这个攻击者啥都没做，就输入了个不知道可对的用户名密码就返回“更新成功”，着实是“更新了个寂寞”。
我认为这样才基本上算是一个合格的钓鱼攻击流程，这次的攻击者着实有点 too young too simple 了。
邮件的技术性分析
这次很多同学中招，一方面原因是发件人向 ceshi@stu.xjtu.edu.cn 这个邮件列表发送，而咱们所有用户都被配置订阅了这个邮件列表。这看起来像是配置错误导致的。
另一个很重要的原因是被发件人的邮件地址 admin@stu.xjtu.edu.cn 这样一个看起来比较权威的地址所误导，之前这个地址发送过西安交通大学校友汇刊 2023 年第 6 期、关于开展第三届校园开放日满意度调查的通知这样的合法邮件。这主要是由 Email 标准自身的局限性导致的。
这个 From:字段从名称上看应当为发件人的邮箱地址（邮件软件图形界面里发件人一栏显示的即是这里的内容），但请注意这一字段可以是假的甚至是空白。
根据 RFC5322:“From/来自：”字段指定消息的作者，即负责撰写消息的人的邮箱或系统的邮箱。 “Sender/发送者：”字段指定负责消息实际传输的代理的邮箱。例如，如果秘书要向他人发送消息，则秘书的邮箱将出现在“发送者：”字段中：实际作者的邮箱将出现在“来自：”字段中。如果消息的发起人可以由同一个邮箱表示，并且作者和传输者是相同的，则不应使用“发送者：”字段。否则，两个字段都应出现。
这被称为 Email Spoofed Phishing Attacks。
以下将逐行分析邮件的原始内容（eml 文件源码），可能会有点乱（尤其是手机 UI），但暂时没有更好的办法：
发件人的信息及 SMTP 收件软件信息
Received: from youardomain.com (unknown [122.239.134.75(浙江省温州市电信)])
-
by app1 (Coremail) with SMTP id <已省略了一串 X-CM-TRANSID>;
Sun, 25 Jun 2023 <已省略收件的时间> +0800 (CST)
Message-ID: < 已省略了长度为 32 的像是 MD5 的字符串 @youardomain.com>
From: admin admin@stu.xjtu.edu.cn 此字段上文中已详细分析
To: ceshi ceshi@stu.xjtu.edu.cn 收件人邮箱地址
Subject: =?utf-8?B?5YWz5LqO5YGc55So5a2m55Sf6YKu566x55qE6YCa55+l?=
注：对于 MINE 消息头中的非 ASCII 字符采用了 RFC 2047 标准进行编码，
这一段字符串解码后即是邮件主题“关于停用学生邮箱的通知”
Date: Sun, 25 Jun 2023 此处省略了时间 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=“----==----” 该邮件有好几部分，这一行表示边界
X-Priority: 3 邮件的优先级
X-Mailer: Supmailer 38.2.0 由什么软件发送的邮件
X-CM-TRANSID: 已省略了一串 X-CM-TRANSID
X-Coremail-Antispam 经过 coremail 邮件系统 MTA 投递时自动生成的反垃圾邮件信息 :
省略了 N 多行内容
Sender: yushunjiang@stu.xjtu.edu.cn 参见之前的 From:字段
Delivered-To: ceshi@stu.xjtu.edu.cnRFC 9228 专门描述这个字段，表示邮件投递到了哪个地址
Precedence: list
X-Ack: No
Errors-to: yushunjiang@stu.xjtu.edu.cn “投递通知”应该发送到哪个地址，RFC 不推荐使用该字段，
应改用 RCPT TO 和
Return-Path
List-Post: mailto:ceshi@stu.xjtu.edu.cn 使用该 URL 以发送给邮件列表：这就是为什么全校同学都收到
这封邮件的原因，因为咱们都在 ceshi@stu.xjtu.edu.cn 这个邮件列表地址里
List-Id: coremail maillist ceshi@stu.xjtu.edu.cn 邮件列表标识符
X-CM-Resent-From: ceshi@stu.xjtu.edu.cn
X-CM-SenderInfo: Coremail 邮件系统添加的一串对人来说没有信息量的字符串
邮件头的这些字段大多是由 RFC 标准确定的：https://www.iana.org/assignments/message-headers/message-headers.xhtml。 而 X-CM 开头的字段想必就是 CoreMail 邮件软件添加的
最后面是一堆东西 base64 编码的内容，包括一段纯文本和一个 html：
-
各位同学：
为了加强电子邮件安全管理，规范电子邮箱使用，保障师生权益，根据相关规定，
未更新的学生账号 (@stu.xjtu.edu.cn）将被停用。
现将本次批量停用邮箱帐号相关事宜通知如下：
本通知发出后，未及时更新的学生帐号，1 周后（7 月 2 日）
账号将设置为“暂停”，即只能接收邮件，不能登录和发送邮件。
请各位同学相互告知，及时更新学生账号。
点击进行 coremail 更新
附上門友提供的该次钓鱼邮件事件的截图
个人见解
stu.xjtu.edu.cn 这种不太靠谱的邮件服务不要用于重要的事情。
建议你交买个 Gmail 企业版，或者 MS outlook 企业版，邮件服务这东西还是大公司最可靠，而且比你买 CoreMail 软件自己搭建运维要省事。
这次事件充分暴露了你交 IT 系统有多烂，之前也有其他門友分享过：
这次只是一个很平庸的攻击，后面来个大的也未尝不可。
DNS 污染本站的动作倒挺快，然而这次事件之后这么长时间了 stu 邮箱并没收到任何预警/解释的邮件。
更新 1：
后面 stu 邮箱确实是收到了一封标题为“关于加强防范钓鱼邮件的通知”的邮件。
但没啥信息量，而且内容也有槽点，例如
看清邮件发送方的域名地址 我校官方电子邮件均以**admin@xjtu.edu.cn**发出，如对方邮箱帐号与上述不一致，或非学校官方邮箱，则需保持警惕
然而，此封邮件本身是由admin@stu.xjtu.edu.cn发出的，的确与上述不一致 
，这是否说明此封邮件也是非官方发出的？？
另外，网信中心咩改变也没做。例如，想必大家都收到了来自 { dapengcao, guhanwen}@stu.xjtu.edu.cn 回复 admin@stu.xjtu.edu.cn 的 “回复：关于停用学生邮箱的通知” 邮件吧
请问不能登录怎么接收邮件啊
你好，请问尝试登录邮箱显示登录已超次数该怎么办呢？
为啥他们回复给 admin 的邮件我们全都收到了呢？这说明任何人还是都能往 拥有所有人邮箱的邮件列表 发邮件。关于这一点到底是不是个 problem，你可以想象一下，假如 Gmail 的任何用户都能给其他所有 Gmail 用户群发邮件是什么样子。你交 IT 系统着实是没救了。
更新 2：攻击得逞的原因——邮件安全扩展 DKIM、DMARC、SPF
早期互联网的设计没有考虑一丁点安全性，比如 DNS, HTTP，流量都是明文，隐私都在裸奔。邮件协议也不例外。
类似纸质邮件，Sender:和 From: 分别对应信封上的发件人和内部信纸上的发件人，为了应用的灵活性，这两栏可以不一样，从而就有冒用身份发送电邮这一攻击。
邮件安全扩展 DKIM、DMARC、SPF 就是为了克服这一安全方面上的缺憾而设计的。关于这些，洋文好的同学可以看下面的这个链接，深入浅出，非常详细：
为啥这次 stu 邮箱攻击能得逞？我们查询一下 stu.xjtu.edu.cn这个域名的相关 DNS 记录即可知道答案。你也可以用dig 这样的工具自己查询验证，或者可以用在线服务查询。结果如下：
$ dig stu.xjtu.edu.cn txt +short
v=spf1 ip4:162.105.129.0(北京市北京大学教育网)/24 ip4:202.117.1.51(陕西省西安市西安交通大学教育网) ip4:202.117.1.52(陕西省西安市西安交通大学教育网) include:spf.icoremail.net ~all
$ dig xjtu.edu.cn txt +short
v=spf1 ip4:162.105.129.0(北京市北京大学教育网)/24 ip4:202.117.1.0(陕西省西安市西安交通大学教育网)/24 ip4:117.32.155.53(陕西省西安市电信) ip6:2001:250:1001:1::1/64 include:spf.icoremail.net ~all
SPF 全称为 Sender Policy Framework，2000 年左右出现，作用是允许域名的所有者设置“只有哪些 IP/域名的计算机发信才是合法的，否则都是未经过授权的”。由上面的 DNS 记录可见确实仅允许某些服务器发信。但是对于“这些服务器发的邮件传送到接受者的服务器的过程中是否有被篡改“就无能为力了。因而需要 DKIM。
DKIM 全称 DomainKeys Identified Mail，通过公私钥非对称加密，实现传输信息不被篡改，即接受者的服务器可通过文件头中的 DKIM 签名，判断该邮件的元数据和正文在传输过程中有没有被篡改。DKIM 因而可以被理解为纸质邮件系统中的邮戳。stu 邮箱接收到的邮件头部缺少这一字段。
DMARC 用于设置 DKIM 验证失败或者 Sender:/From:不统一时，收件邮件服务器应当怎么处理。有几种 policy：
- reject 表示退信，从而该邮件不会出现在收件人的邮箱中。
- quarantine 表示防疫隔离，把该邮件分类到spam文件夹里，提醒收件人注意该邮件是有问题的。
- none 表示不管，从而该邮件就像正常邮件一样出现收件人的邮箱
DNS 检索结果显示 stu 邮箱应该是没有设置 DKIM 和 DMARC！
下面看看这个交大門网站的邮件安全性如何呢？
交大門是通过 MailGun 实现邮件服务的。
$ dig xjtu.app txt +short
"v=spf1 -all"
$ dig mg.xjtu.app txt +short
"v=spf1 include:mailgun.org ~all"
$ dig krs._domainkey.mg.xjtu.app txt +short
"k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5Wqp0OsFNjfZ+03zwfKnN2Wx0A24AiKVH+ypYqWseBq16WxKpyQ5ZdJWqnNd96RCugXwjW4S+ylgB2u0U6QNZvCvwoJZMdc2uzEeVv5o7dH7sh2qlH0D+u0MMoM4LYtO+TFdnaM7mI83m1vYp0Ns4LECbxTvFWTMYDP8UgMNUqQIDAQAB"
$ dig _dmarc.xjtu.app txt +short
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:c8d07a9ce26e4cfcb1d42ba73f9e17cd@dmarc-reports.cloudflare.net"
可以看出交大門非常注重安全性，配置了只有 mailgun.org 的服务器才可以代表本站发信，并且配置了 DKIM 保证了邮件的 integrity，DMARC 策略是 reject，即有人企图假冒本站，收件邮件系统应当直接丢弃。
在这里讲一个趣事，交大門早期有 Gmail 用户和 Outlook 用户抱怨收不到注册邮件，垃圾邮件文件夹里也没有。原因是邮件由于 reject 的 DMARC 策略被直接丢弃了。
然而 SPF 和 DKIM 的配置都正确，（不然其他邮件服务的用户也注册不了啊），为什么会被丢掉呢？
原因是起初给用户发邮件用的是 noreply@xjtu.app这个地址，而 mailgun 里配置使用的是mg.xjtu.app 这个子域名，由 Gmail 显示的原始邮件内容中可见：
Sender: noreply=xjtu.app@mg.xjtu.app
From: "xjtu.app 交大門" <noreply@xjtu.app>
由于是 mg.xjtu.men 代 xjtu.men 发信，从而 Sender 和 From 两个字段不统一，所以被 Gmail 退信。
在这里特地表扬 Google Gmail 和 MS Outlook 在安全方面的谨慎。
再吐槽一下，交大門作为一个非官方网站，都能遵循网络安全领域的 common practice 进行配置。堂堂一个几万人的大学，IT 系统这么烂，着实有点说不过去。
如果有顶级黑客想渗透你交的 IT 系统，恐怕早已做过并留下后门，所以你交引以为傲的一些很牛的科研成果的原创团队要留心了，需要提高信息安全素养，别让成果被黑客给窃取了。
