创建: 2022-05-24 15:44
更新: 2022-05-25 15:29
http://scz.617.cn:8/misc/202205241544.txt

给windbg团队邮件反馈TTD调试功能的BUG，提供PE格式的测试样本，被Gmail阻止。

这事儿存在多年了，过去可以修改文件扩展名、使用带密码的压缩包。到了2022年，这些歪招被Gmail进一步防范，简单改扩展名、带密码压缩很容易被Gmail禁止。不信邪的可以试试。Gmail检查文件内容时有不依赖扩展名的深度检查手段，扩展名为txt的PE会被检测到。

假设原始PE是cvtest_p.exe，想发给[email protected]，该PE在最新版TTD中触发内存访问违例。直接发.exe肯定不行，带密码压到cvtest_p.7z中，隐藏压缩包内文件名，被Gmail禁止。将.exe重命名为.txt，带密码压缩到cvtest_p.7z中，隐藏压缩包内文件名，将.7z扩展名删掉，被Gmail禁止。加密压缩7z并多层嵌套，被禁。

爹味十足的Google告诉你，这些附件有安全风险，参看:

File types blocked in Gmail
https://support.google.com/mail/?p=BlockedMessage

如下类型附件被禁

Certain types of files, including their compressed form (like .gz or .bz2 files) or when found within archives (like .zip or .tgz files)

Documents with malicious macros

Password-protected archives with archived content

.ade, .adp, .apk, .appx, .appxbundle, .bat, .cab, .chm, .cmd, .com, .cpl, .dll, .dmg, .ex, .ex_, .exe, .hta, .ins, .isp, .iso, .jar, .js, .jse, .lib, .lnk, .mde, .msc, .msi, .msix, .msixbundle, .msp, .mst, .nsh, .pif, .ps1, .scr, .sct, .shb, .sys, .vb, .vbe, .vbs, .vxd, .wsc, .wsf, .wsh

后来用mega存放cvtest_p.7z，在给微软的反馈邮件中提供URL，暂时对付过去。

前述官方URL就传递被禁附件提供了临时解决方案

If you're sure the file is safe, you can ask the sender to upload the file to Google Drive. Then send it as a Drive attachment.

若用HTTPS访问Gmail，在写邮件的界面底部有"Insert files using Drive"，中文版是"使用云端硬盘插入文件"，图标是"圆角三角形"，与之对比，添加附件的图标是"回形针"。

Insert files using Drive
  Upload
    Select files from your computer

即使收件方不是Gmail用户，仍可正常下载上述方案发送的邮件附件。

我很少用HTTPS访问Gmail，主要用各种邮件客户端。过去走POP3S/SMTPS，Gmail很快就不支持POP3S了，换成IMAP+OAuth2，Thunderbird支持这种用法。不确认雷鸟是否支持"Insert files using Drive"，即使支持也不想用，个人习惯吧。

对Gmail禁止某些类型附件有兴趣的，可用HTTPS界面测试，无需真实发送，上传附件后若被禁，立刻就能看到提示。用雷鸟之类的客户端测试此问题不划算，需要真实发送，等待Google服务端产生提示被禁的响应。

在微博上问有没有2022年还能用的歪招，编码到可打印字符范围这种不考虑。内在逻辑是，解压缩是常规动作，收件方大概率拥有解压软件；各种Decode则是非常规动作，即便Decode工具是OS自带的，也不如解压来得顺手。若收件方是发件方熟人，Decode方案是可接受的，比如我与bluerust互相用GPG处理附件，Gmail放行。

对Gmail附件检查策略进行黑盒测试，最后收敛到如下结论。无论何种格式/扩展名的压缩包，在检查压缩包内文件内容与扩展名两项上，至少要允许Gmail检查其中一项，两项皆不允许Gmail检查时，Gmail直接禁止压缩包作为附件。Gmail一般情况下只检查压缩包内第一层的扩展名，并不检查第二层的扩展名，但压缩包内第一层的扩展名是zip时，Gmail会检查第二层的扩展名。

基于上述理论，可进行各种组合，生成Gmail放行的附件。逻辑是，不能让Gmail通过文件内容检查到PE，同时将压缩包内相应层的扩展名改成未被禁止的。

"召唤"提供的此类型方案是，先tar再带密码生成zip

busybox64.exe tar cf cvtest_p.tar cvtest_p.exe

将cvtest_p.tar带密码压缩成some_0.zip，Gmail放行。非常喜欢该方案，收件方只用7-Zip就可以析取其中的cvtest_p.exe，7-Zip可以打开zip、tar扩展名，收件方无需做任何释放再改名的动作。"召唤"不愧是腾讯干将，赞。

将cvtest_p.exe重命名成cvtest_p.exe.txt，再带密码压缩到some_1.zip，Gmail放行。

将cvtest_p.exe带密码压缩到internal.7z，无所谓隐藏内部文件名，再无密码压缩到some_2.zip，Gmail放行。Gmail并未检查第二层的扩展名。

针对上例做对比实验，将cvtest_p.exe带密码压缩到internal.zip，再无密码压缩到error_2.zip，Gmail禁止。从internal.7z改成internal.zip，前者刻意未隐藏内部文件名，后者则无法隐藏内部文件名，从some_2.zip到error_2.zip，结果不同。Gmail对internal.zip做了更多检查。

成功案例

some_0.zip (召唤)
    tar + encrypted zip
some_1.zip
    rename to txt + encrypted zip
some_2.zip
    encrypted internal.7z (未隐藏内部文件名) + normal zip
some_3.pdf (小钻风)
    head.pdf + exe
some_7.docx (TK)
    用exe替换"some_7.docx\word\media\image1.jpeg"
some_8.docx
some_9.doc (Word 97格式)
    直接贴cvtest_p.7z到docx、doc中

失败案例

error_2.zip
    encrypted internal.zip + normal zip
error_5.gif
error_6.jpg
    head.gif + encrypted 7z (隐藏内部文件名)
    head.jpg + encrypted 7z (隐藏内部文件名)
error_10.docx
error_11.doc
    直接贴exe到docx、doc中

有个很tricky的事，带密码的7z，若选择隐藏内部文件名，Gmail既不能检查7z内文件内容也不能检查7z内文件扩展名，此时Gmail禁止这样的7z作为附件。为了让Gmail放行带密码的7z，必须选择"不"隐藏内部文件名，同时让内部文件扩展名不在禁止名单内。我之前总是失败，吃亏在隐藏内部文件名，这是个反直觉坑。

小钻风的方案:

$ busybox64.exe echo -ne %PDF-1.4\n\n%%EOF\n | busybox64.exe xxd -g 1
00000000: 25 50 44 46 2d 31 2e 34 0a 0a 25 25 45 4f 46 0a  %PDF-1.4..%%EOF.
$ busybox64.exe echo -ne %PDF-1.4\n\n%%EOF\n > head.pdf
copy /b head.pdf+cvtest_p.exe some_3.pdf

Gmail放行some_3.pdf。收件方可将some_3.pdf更名成some_3，即删掉扩展名，7-Zip用#方式打开some_3，从中析取exe。该方案未做任何加密处理，明修栈道、暗度陈仓，靠扩展名pdf骗过Gmail检查。非正常人类研究中心被研究对象、人民陪审员小钻风威武！

TK提及两种思路。1. docx这类文件本质上都是zip，是不是可以弄一个空docx，然后用PE文件替换docx中原本就存在的一个文件名。2. 至少winrar支持在文件中搜索压缩文件，也就是说，把rar文件附加在其他文件末尾，或者作为其他文件内部的一个数据结构，最后把附加或包裹了rar数据的那个文件的扩展名改为.rar，winrar可以正常打开处理。

先说测试结论，思路1可行，思路2为Gmail所防范。

TK在2012年发过一条微博，属于思路2的一次实践:

https://weibo.com/1401527553/ylBfB4Yxm

当时他是将任意文件压缩到x.rar中，又找了张图片x.gif，接着执行

copy x.gif /B + x.rar /B weibo.gif /B

在微图上发图weibo.gif，该图可以正常展示，内容就是x.gif的内容。别人可以"查看大图"，另存为x.rar，用winrar打开，得到压缩包中的文件。那篇受众是小白，生怕别人提取不了压缩包中的文件，连"查看大图"都强调了。图片不一定是gif，jpg什么的都可以。

假设cvtest_p.7z带密码保护，隐藏内部文件名，执行:

copy /b head.gif+cvtest_p.7z error_5.gif
copy /b head.jpg+cvtest_p.7z error_6.jpg

error_5.gif、error_6.jpg可正常显示，可用7-Zip打开error_5.gif、error_6.jpg析取其中的exe。若7-Zip打开error_5.gif、error_6.jpg析取失败，将扩展名改.rar之类的再用7-Zip析取。这个办法在别处可能有用，但error_5.gif、error_6.jpg无法作为Gmail附件。Gmail对gif、jpg文件做了深度解析，能识别出gif、jpg尾部。

下面说说TK的思路1。新建some_7.docx，任意贴张jpg进去。用7-Zip打开some_7.docx，有:

some_7.docx\word\media\image1.jpeg

在7-Zip中用cvtest_p.exe替换原有的image1.jpeg，将cvtest_p.exe改名成image1.jpeg。魔改过的some_7.docx可作为Gmail附件。收件方用7-Zip打开some_7.docx，析取image1.jpeg，改名回cvtest_p.exe。该方案未做任何加密处理，靠扩展名docx骗过了Gmail检查，与小钻风的some_3.pdf异曲同工，同样展现了非正常人类研究中心被研究对象的精神病特质。

受思路1启发，我做了另一类测试。新建some_8.docx，直接贴cvtest_p.7z进去，Gmail放行some_8.docx，若some_8.docx直接嵌exe，过不了Gmail检查。收件方用Word打开some_8.docx，选中嵌在其中的7z，Ctrl-C复制，在资源管理器中Ctrl-V粘贴得到cvtest_p.7z，该方案操作更小白化。稍微深入一下，用7-Zip打开some_8.docx，有:

some_8.docx\word\embeddings\oleObject1.bin\[1]Ole10Native\cvtest_p.exe

"[1]Ole10Native"相当于嵌在docx中的7z。

右键新建some_9.docx，此时文件大小为0，另存为Word 97格式的some_9.doc，注意扩展名有变；贴cvtest_p.7z进去，Gmail放行some_9.doc。用7-Zip打开some_9.doc，有:

some_9.doc\ObjectPool\_1714996400\[1]Ole10Native\cvtest_p.exe

docx、doc均适用于这种方案。

此时另一位非正常人类研究中心被研究对象yuange出场，他同样提出docx/doc方案，并进一步指出，Word文件是个"单一文件系统"，就是一个文件形式存在的文件系统，理解了这点，可以做很多事情。这事儿yuange很多年前就指出过，并应用在安全实践活动中。

我在微博上提问时没有严格限定哪些方案可接受、哪些方案不考虑，只提了一句，编码到可打印字符范围这种不考虑。三位我中心被研究对象及"召唤"精准理解了我之提问的潜在上下文环境，简单点说，改名、解压都是可以的，非压缩编码不可接受。这没有什么道理可言，只能说，他们与我是一类人，讨论技术问题时无需废口舌进行前置约束。

举几个反例，下面是曾经出现过的说法

a) 加密压缩即可

仔细看过前文的就知道这个说法多么粗糙而没有任何指导价值，有太多反例。

b) tar然后OpenSSL带密码加密，外面还可以再套一层base64

这位假设我是没听说过"免杀"之类概念的小白，b类变种说法太多，不枚举。

回看原始需求，对Google的爹味实足有了进一步感知。Chrome客户端对目标端口的限制、Gmail对附件的限制将大厂那种家长式傲慢、自负展现得淋漓尽致，处于垄断地位的它们打着"都是为了你们好"的幌子，收割着别人的选择自由。

不多扯了。本文在写作过程中，因结论不断收敛而几易其稿，力求不传递无效干扰信息。感谢各位无需前置约束的朋友进行积极有效的技术探讨，促使我对Gmail附件检查机制进行更深入的黑盒测试及结论收敛，解决了我的一个刚需。