标题: Gmail对附件的限制 创建: 2022-05-24 15:44 更新: 2022-06-19 14:36 链接: https://scz.617.cn/web/202205241544.txt 给windbg团队邮件反馈TTD调试功能的BUG，提供PE格式的测试样本，被Gmail阻止。 这事儿存在多年了，过去可以修改文件扩展名、使用带密码的压缩包。到了2022年， 这些歪招被Gmail进一步防范，简单改扩展名、带密码压缩很容易被Gmail禁止。不信 邪的可以试试。Gmail检查文件内容时有不依赖扩展名的深度检查手段，扩展名为txt 的PE会被检测到。 假设原始PE是cvtest_p.exe，想发给windbgfb@microsoft.com，该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做了更多检查。 显然Gmail在检查多层嵌套zip时，有不同寻常的逻辑，很可能在遭遇内层zip扩展名 时直接按zip格式继续检查，而不考虑内层zip扩展名实际对应一个PE。将exe扩展名 改成zip，再无密码压缩到some_12.zip，Gmail放行。对比测试，将exe扩展名改成 zip，再无密码压缩到error_12.7z，Gmail禁止。"zip+zip"与"zip+7z"的结局不同， 表明多层嵌套zip有自己特有的检测逻辑。注意，将exe扩展名改成zip，无法直接作 为Gmail附件，这是被防范的。 some_12.zip特别有意思，只利用了重命名、普通压缩，未使用任何加密手段，居然 也骗过了Gmail。带密码压缩属于加密手段的一种。 网友"__Green_m"提出一种新方案，用7-Zip压缩exe到some_13.xz，Gmail放行，不涉 及加密，这是目前为止我看到的最优解，若PE本身带毒，还是会报警，但原始需求是 传递普通PE。xz压缩时，假设最终生成some_13.exe.xz，解压得到some_13.exe；假 设最终生成some_13.xz，解压得到some_13；换句话说，xz压缩时内层文件名跟随外 层文件名，以前真没留意过。 部分成功示例 -------------------------------------------------------------------------- some_0.zip (召唤) tar + encrypted zip (pass is windbgfb) some_1.zip rename exe 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中 some_12.zip rename exe to zip + normal zip some_13.xz (__Green_m) normal xz some_14.vhd (_nt0skrnl) normal vhd -------------------------------------------------------------------------- 部分失败示例 -------------------------------------------------------------------------- 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中 error_12.7z rename exe to zip + normal 7z error_13.txt rename exe to txt error_14.zip rename exe to zip -------------------------------------------------------------------------- 有个很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。该方案未对原始PE做任何加密、压缩，明修栈道、 暗度陈仓，靠扩展名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附件检 查机制进行更深入的黑盒测试及结论收敛，解决了我的一个刚需。 2022-05-26 09:30 无论什么行业，下车伊始都是个很坏的毛病，无谓地浪费整体资源。有些人全文都没 仔细看下来，就急于发言，重复文中已经提及的方案或思路，吃饱了撑得没事做。 2022-05-27 22:10 张宇平提了个事，不带密码的zip内部依次出现ZipBomb、扩展名为txt的PE，Gmail会 怎么样？现在ZipBomb早已为各家产品所防范，我实测了一下，上传这种异常附件时 Gmail检查更加耗时，除此之外不影响其他结果。 2022-06-19 14:36 网友"_nt0skrnl"反馈，VHD可以搭载PE作为Gmail附件，实测可行。相比其他方案， VHD太重型，我用不上，或许有人用得上，FYI。 Manage Virtual Hard Disks (VHD) https://docs.microsoft.com/en-us/windows-server/storage/disk-management/manage-virtual-hard-disks 官方文档声称VHD最小3MB。 用diskmgmt.msc创建8MB动态扩展虚拟硬盘some_14.vhd，GPT模式，新建6MB卷，NTFS 文件系统，启用压缩。向some_14.vhd中复制PE，该vhd可作为Gmail附件。