Exchange 2013 阻止 txt 文件附件 - 有安全原因吗?

信息安全 电子邮件 交换
2021-09-08 12:11:31

我的 Exchange 管理员正在设置 2013,它被设置为专门阻止 txt 文件附件(以及其他附件)。

我曾尝试搜索与 txt 附件相关的风险,但找不到任何风险。我需要注意周围 txt 附件的任何风险吗?

编辑

管理员没有设置阻止规则,但发现这是从 2010 迁移期间 Exchange 2013 的默认规则。它导致我们的环境出现问题,因此他要求我批准将 .txt 文件列入白名单。

4个回答

我已经支持和管理电子邮件 18 年了,从来没有正当理由阻止文本附件。以下是我能想到的一些问题,这些问题不仅限于 TXT 附件,而是一般的附件

Unicode 解析

我遇到的唯一两个问题是这个unicode 错误,但理论上其他应用程序可能存在解析和/或显示 unicode 的问题。

MIME 类型与文件扩展名

SMTP 中的附件不仅包括文件扩展名.txt,还包括 MIME-Type 和相应的编码(如上所述)。如果这些“元数据”中的任何一个不匹配(vbscript 与文本的 mime,反之亦然),则可能会从客户端获得意外结果。

问题可能包括

  • 文件附件图标在客户端看起来像一个 TXT 文件,但实际上是一个 EXE
  • 客户端(或服务)不正确地处理附件,可能会执行它
  • 上述变体导致客户端(outlook/thunderbird 等)下载图像或验证 DKIM 签名,从而失去客户端的匿名性。

外表

由于 Exchange 2013 环境中最常见的客户端是 Outlook,因此我将重点关注这一点,即使此处的大多数问题都已经过彻底研究并且不再是问题(只要您使用的是当前的并已修补建造)。

Outlook 预览窗格风险

Outlook 预览窗格使用一种特殊的锁定版本的 IE。鉴于 IE 可以像 HTML/XSS 或任何其他活动内容一样执行“文本”数据,这可能会带来安全风险。(Outlook 漏洞作为预览窗格过去曾发生过)

WebReady Exchange 服务器风险

与 HTML 解析器类似的附件安装在称为WebReady的 Exchange 服务器本身上,它将附件转换为用于 Outlook Web Access 客户端的 HTML。这在过去已经是一个问题,导致漏洞和可执行代码在 Exchange Server 本身的上下文中运行。 在此处阅读有关此安全功能的更多信息。

概括

在我看来,在您的管理员阻止 TXT 附件之前,他们应该考虑禁用 Webready并首先解决悬而未决的问题:

  • 改进了最终用户的身份验证(智能卡等)
  • 服务器上的 AV/AS 和网关
  • SMTP 安全性,包括 DMARC、DKIM、SPF 和 Opportunistic / Secure TLS(在可能的情况下)
  • 内容扫描
  • 按需门户加密、SMIME 或 PGP 加密

如果他们正在禁用附件作为信息管理的一种形式,以防止披露(或接收)数据,那么他们应该考虑替代控制。

如果他们出于安全/加密原因禁用 TXT 附件并希望加密所有数据,请知道某些加密软件使用 TXT 数据将加密的有效负载或公共发送给客户端。相反,禁止此活动很容易,因为文件中有一个可以扫描的字符串。

只是为了澄清一下,“阻止”是指将其分类为Outlook 中的 1 级或 2 级附件吗?

除了 makerofthings7 的非常彻底的回答之外,另一个原因可能是防止网络钓鱼攻击在 TXT 附件中传输危险内容。

例如,如果您发送一个名为 ILOVEYOU.EXE.TXT 的文件,将其签名为“grandma”,并指示用户保存并重命名该文件 - 一定比例的用户会很乐意按照这些说明查看“grandma”发送给他们的内容.

没有与 RFC 定义的纯文本附件相关的特定风险。

参考:https : //www.rfc-editor.org/rfc/rfc2046

像Windows操作系统相关联的文件名的“TXT”扩展到纯文本/ MIME类型,并且对点击可执行协会/一些规定程序打开(如记事本/写字板等)。

默认情况下,在大多数操作系统客户端(Windows 和许多其他客户端)上,此关联程序没有发布导致打开纯文本文件的安全漏洞。事实上,如果他们这样做了,就永远无法打开/预览任何电子邮件,因为担心简单地呈现文本会执行恶意软件。

评估:管理员在阻止具有 TXT 扩展名的文件时出错。

进一步分析:文件扩展名本质上是没有意义的

例如,操作系统可执行病毒可以被赋予任何文件名/扩展名。单击/打开时,该文件内容将由与扩展名关联的某些阅读器程序处理。

实际上,企业环境中的常见做法是通过简单地重命名具有不同扩展名的文件或只是压缩内容(给文件一个“.zip”扩展名)以便读者可以接收它来绕过 Exchange 文件扩展名阻止规则。

例如,开发人员通过电子邮件交换语言源文件/片段的情况并不少见。此类文件属于 MIME 类型“纯/文本”,但许多 Exchange 管理员会阻止以“.c”或“.cpp”命名的文件,错误地认为语言源文件以某种方式固有地可执行。

也有可能所有附件都被阻止 - 无论扩展名如何。或者,可能存在仅允许某些文件类型的组织政策 - 可能只有 .pdf 已获批准,因此 .txt 被明确阻止。

虽然不一定是安全问题,但有人可能会发送大量占用大量存储空间的非常大的 .txt 文件。同样,打开一个大的 .txt 文件可能会导致系统资源问题。例如,打开一个包含 250MB 数据的 .txt 文件在一行中会导致 Notepad.exe 出现问题...

但这些可能是晦涩难懂的例子/理由。