什么是木马源,它是如何潜入你的源代码的?
11月初,剑桥大学发布了他们 名为Trojan-Source的研究。这项研究的重点是如何利用定向格式化字符将后门隐藏在源代码和注释中。这些可以被用来制作代码,而编译器对这些代码的逻辑解释与人类代码审查者不同。
这个漏洞是新的--尽管Unicode在过去曾被邪恶地使用过,例如通过颠倒文件名的最后部分的方向来隐藏文件的真正扩展名。最近的研究显示,许多编译器会忽略源代码中的Unicode字符而不发出警告,而文本编辑器,包括代码编辑器,可能会将包含注释和代码的行回流。因此,编辑器可能会以不同的方式显示代码和注释,并且以不同的顺序显示,这与编译器的解析方式不同,甚至是代码和注释的互换。
继续阅读以了解更多信息。或者,如果你想卷起袖子,尝试模拟黑客攻击木马源,请跳进我们的免费公开任务,亲自体验。
双向文本
其中一个木马源攻击利用了Unicode Bidi(双向)算法,该算法处理如何将显示顺序不同的文本放在一起,如英语(从左到右)和阿拉伯语(从右到左)。方向性的格式化字符可以用来重新组织分组和显示字符的顺序。
上表包含了一些与攻击有关的比迪覆盖字符。以此为例。
RLIe d o cPDI
缩写RLI是指从右到左的隔离。它将把文本从其上下文(由PDI,Pop-Directional-Isolate划定)中分离出来,并从右到左进行阅读。结果是。
ǞǞǞ
然而,编译器和解释器在解析源代码之前通常不处理格式化控制字符,包括Bidi重写。如果他们简单地忽略了方向性的格式化字符,他们就会进行解析。
e d o c
新瓶装旧酒?
当然,这在阳光下并不新鲜。在过去,定向格式化字符被插入文件名中,以掩盖其恶意的性质。一个显示为 "myspecialexe.doc "的电子邮件附件可能看起来很无辜,如果不是因为出现了RLO(从右到左的覆盖)字符,揭示了真正的名称是 "myspecialcod.exe"。
木马源码攻击在源代码中存在的注释和字符串中插入定向格式化字符,因为这些不会产生任何语法或编译错误。这些控制字符改变了代码的逻辑显示顺序,导致编译器读取的内容与人类完全不同。
例如,一个包含以下字节的文件,按这个顺序排列。

将通过方向性的格式化字符重新排序如下

导致代码被渲染成这样,如果方向性的格式化字符没有被明确地叫出来。

在最后一行,RLO将闭合括号翻转为开放括号,反之亦然。执行这段代码的结果将是。"你是一个管理员"。管理员检查被注释掉了,但是控制字符让人觉得它仍然存在。
(来源: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
这对你会有什么影响?
许多语言都容易受到这种攻击。C、C++、C#、JavaScript、Java、Rust、Go和Python,而且估计还有更多。现在,一般的开发者看到源代码中的方向性格式化字符可能会皱眉头,但新手也可能会耸耸肩,觉得没什么。此外,这些字符的可视化在很大程度上取决于IDE,所以不能保证它们会被发现。
但是,这个漏洞首先是如何潜入源代码的呢?首先,这可能发生在使用来源不可靠的源代码时,其中的恶意代码贡献没有被注意到。其次,它可能是通过简单地复制粘贴互联网上的代码而发生的,我们大多数开发人员以前都做过这种事。大多数组织依赖来自多个供应商的软件组件。这就提出了一个问题,我们能在多大程度上完全信任和依赖这些代码?我们怎样才能筛选出含有隐藏后门的源代码?
这是谁的问题?
一方面,编译器和构建管道应该不允许源代码行有一个以上的方向,除非一个方向被严格限制在字符串和注释中。请注意,字符串或注释中的方向性格式化字符,如果不被弹出,可以将方向性变化延长到行的末尾。一般来说,代码编辑器应该明确地呈现和突出可疑的Unicode字符,如同音字和定向格式化字符。自11月起,GitHub现在为每一行包含双向单码文本的代码添加警告标志和信息,尽管它没有突出显示这些字符在行中的位置。这仍然可能使恶意的方向变化与良性的方向变化一起潜入。
开发人员和代码审查人员的认识是至关重要的,这就是为什么我们创建了一个说明该漏洞的演练。目前,该演练适用于Java、C#、Python、GO和PHP。
因此,如果你想了解更多,可以试试我们对木马源的模拟(公共missions ),并阅读木马源研究报告。


11月初,剑桥大学发布了他们 名为Trojan-Source的研究。这项研究的重点是如何利用定向格式化字符将后门隐藏在源代码和注释中。这些可以被用来制作代码,而编译器对这些代码的逻辑解释与人类代码审查者不同。
这个漏洞是新的--尽管Unicode在过去曾被邪恶地使用过,例如通过颠倒文件名的最后部分的方向来隐藏文件的真正扩展名。最近的研究显示,许多编译器会忽略源代码中的Unicode字符而不发出警告,而文本编辑器,包括代码编辑器,可能会将包含注释和代码的行回流。因此,编辑器可能会以不同的方式显示代码和注释,并且以不同的顺序显示,这与编译器的解析方式不同,甚至是代码和注释的互换。
继续阅读以了解更多信息。或者,如果你想卷起袖子,尝试模拟黑客攻击木马源,请跳进我们的免费公开任务,亲自体验。
双向文本
其中一个木马源攻击利用了Unicode Bidi(双向)算法,该算法处理如何将显示顺序不同的文本放在一起,如英语(从左到右)和阿拉伯语(从右到左)。方向性的格式化字符可以用来重新组织分组和显示字符的顺序。
上表包含了一些与攻击有关的比迪覆盖字符。以此为例。
RLIe d o cPDI
缩写RLI是指从右到左的隔离。它将把文本从其上下文(由PDI,Pop-Directional-Isolate划定)中分离出来,并从右到左进行阅读。结果是。
ǞǞǞ
然而,编译器和解释器在解析源代码之前通常不处理格式化控制字符,包括Bidi重写。如果他们简单地忽略了方向性的格式化字符,他们就会进行解析。
e d o c
新瓶装旧酒?
当然,这在阳光下并不新鲜。在过去,定向格式化字符被插入文件名中,以掩盖其恶意的性质。一个显示为 "myspecialexe.doc "的电子邮件附件可能看起来很无辜,如果不是因为出现了RLO(从右到左的覆盖)字符,揭示了真正的名称是 "myspecialcod.exe"。
木马源码攻击在源代码中存在的注释和字符串中插入定向格式化字符,因为这些不会产生任何语法或编译错误。这些控制字符改变了代码的逻辑显示顺序,导致编译器读取的内容与人类完全不同。
例如,一个包含以下字节的文件,按这个顺序排列。

将通过方向性的格式化字符重新排序如下

导致代码被渲染成这样,如果方向性的格式化字符没有被明确地叫出来。

在最后一行,RLO将闭合括号翻转为开放括号,反之亦然。执行这段代码的结果将是。"你是一个管理员"。管理员检查被注释掉了,但是控制字符让人觉得它仍然存在。
(来源: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
这对你会有什么影响?
许多语言都容易受到这种攻击。C、C++、C#、JavaScript、Java、Rust、Go和Python,而且估计还有更多。现在,一般的开发者看到源代码中的方向性格式化字符可能会皱眉头,但新手也可能会耸耸肩,觉得没什么。此外,这些字符的可视化在很大程度上取决于IDE,所以不能保证它们会被发现。
但是,这个漏洞首先是如何潜入源代码的呢?首先,这可能发生在使用来源不可靠的源代码时,其中的恶意代码贡献没有被注意到。其次,它可能是通过简单地复制粘贴互联网上的代码而发生的,我们大多数开发人员以前都做过这种事。大多数组织依赖来自多个供应商的软件组件。这就提出了一个问题,我们能在多大程度上完全信任和依赖这些代码?我们怎样才能筛选出含有隐藏后门的源代码?
这是谁的问题?
一方面,编译器和构建管道应该不允许源代码行有一个以上的方向,除非一个方向被严格限制在字符串和注释中。请注意,字符串或注释中的方向性格式化字符,如果不被弹出,可以将方向性变化延长到行的末尾。一般来说,代码编辑器应该明确地呈现和突出可疑的Unicode字符,如同音字和定向格式化字符。自11月起,GitHub现在为每一行包含双向单码文本的代码添加警告标志和信息,尽管它没有突出显示这些字符在行中的位置。这仍然可能使恶意的方向变化与良性的方向变化一起潜入。
开发人员和代码审查人员的认识是至关重要的,这就是为什么我们创建了一个说明该漏洞的演练。目前,该演练适用于Java、C#、Python、GO和PHP。
因此,如果你想了解更多,可以试试我们对木马源的模拟(公共missions ),并阅读木马源研究报告。

11月初,剑桥大学发布了他们 名为Trojan-Source的研究。这项研究的重点是如何利用定向格式化字符将后门隐藏在源代码和注释中。这些可以被用来制作代码,而编译器对这些代码的逻辑解释与人类代码审查者不同。
这个漏洞是新的--尽管Unicode在过去曾被邪恶地使用过,例如通过颠倒文件名的最后部分的方向来隐藏文件的真正扩展名。最近的研究显示,许多编译器会忽略源代码中的Unicode字符而不发出警告,而文本编辑器,包括代码编辑器,可能会将包含注释和代码的行回流。因此,编辑器可能会以不同的方式显示代码和注释,并且以不同的顺序显示,这与编译器的解析方式不同,甚至是代码和注释的互换。
继续阅读以了解更多信息。或者,如果你想卷起袖子,尝试模拟黑客攻击木马源,请跳进我们的免费公开任务,亲自体验。
双向文本
其中一个木马源攻击利用了Unicode Bidi(双向)算法,该算法处理如何将显示顺序不同的文本放在一起,如英语(从左到右)和阿拉伯语(从右到左)。方向性的格式化字符可以用来重新组织分组和显示字符的顺序。
上表包含了一些与攻击有关的比迪覆盖字符。以此为例。
RLIe d o cPDI
缩写RLI是指从右到左的隔离。它将把文本从其上下文(由PDI,Pop-Directional-Isolate划定)中分离出来,并从右到左进行阅读。结果是。
ǞǞǞ
然而,编译器和解释器在解析源代码之前通常不处理格式化控制字符,包括Bidi重写。如果他们简单地忽略了方向性的格式化字符,他们就会进行解析。
e d o c
新瓶装旧酒?
当然,这在阳光下并不新鲜。在过去,定向格式化字符被插入文件名中,以掩盖其恶意的性质。一个显示为 "myspecialexe.doc "的电子邮件附件可能看起来很无辜,如果不是因为出现了RLO(从右到左的覆盖)字符,揭示了真正的名称是 "myspecialcod.exe"。
木马源码攻击在源代码中存在的注释和字符串中插入定向格式化字符,因为这些不会产生任何语法或编译错误。这些控制字符改变了代码的逻辑显示顺序,导致编译器读取的内容与人类完全不同。
例如,一个包含以下字节的文件,按这个顺序排列。

将通过方向性的格式化字符重新排序如下

导致代码被渲染成这样,如果方向性的格式化字符没有被明确地叫出来。

在最后一行,RLO将闭合括号翻转为开放括号,反之亦然。执行这段代码的结果将是。"你是一个管理员"。管理员检查被注释掉了,但是控制字符让人觉得它仍然存在。
(来源: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
这对你会有什么影响?
许多语言都容易受到这种攻击。C、C++、C#、JavaScript、Java、Rust、Go和Python,而且估计还有更多。现在,一般的开发者看到源代码中的方向性格式化字符可能会皱眉头,但新手也可能会耸耸肩,觉得没什么。此外,这些字符的可视化在很大程度上取决于IDE,所以不能保证它们会被发现。
但是,这个漏洞首先是如何潜入源代码的呢?首先,这可能发生在使用来源不可靠的源代码时,其中的恶意代码贡献没有被注意到。其次,它可能是通过简单地复制粘贴互联网上的代码而发生的,我们大多数开发人员以前都做过这种事。大多数组织依赖来自多个供应商的软件组件。这就提出了一个问题,我们能在多大程度上完全信任和依赖这些代码?我们怎样才能筛选出含有隐藏后门的源代码?
这是谁的问题?
一方面,编译器和构建管道应该不允许源代码行有一个以上的方向,除非一个方向被严格限制在字符串和注释中。请注意,字符串或注释中的方向性格式化字符,如果不被弹出,可以将方向性变化延长到行的末尾。一般来说,代码编辑器应该明确地呈现和突出可疑的Unicode字符,如同音字和定向格式化字符。自11月起,GitHub现在为每一行包含双向单码文本的代码添加警告标志和信息,尽管它没有突出显示这些字符在行中的位置。这仍然可能使恶意的方向变化与良性的方向变化一起潜入。
开发人员和代码审查人员的认识是至关重要的,这就是为什么我们创建了一个说明该漏洞的演练。目前,该演练适用于Java、C#、Python、GO和PHP。
因此,如果你想了解更多,可以试试我们对木马源的模拟(公共missions ),并阅读木马源研究报告。
11月初,剑桥大学发布了他们 名为Trojan-Source的研究。这项研究的重点是如何利用定向格式化字符将后门隐藏在源代码和注释中。这些可以被用来制作代码,而编译器对这些代码的逻辑解释与人类代码审查者不同。
这个漏洞是新的--尽管Unicode在过去曾被邪恶地使用过,例如通过颠倒文件名的最后部分的方向来隐藏文件的真正扩展名。最近的研究显示,许多编译器会忽略源代码中的Unicode字符而不发出警告,而文本编辑器,包括代码编辑器,可能会将包含注释和代码的行回流。因此,编辑器可能会以不同的方式显示代码和注释,并且以不同的顺序显示,这与编译器的解析方式不同,甚至是代码和注释的互换。
继续阅读以了解更多信息。或者,如果你想卷起袖子,尝试模拟黑客攻击木马源,请跳进我们的免费公开任务,亲自体验。
双向文本
其中一个木马源攻击利用了Unicode Bidi(双向)算法,该算法处理如何将显示顺序不同的文本放在一起,如英语(从左到右)和阿拉伯语(从右到左)。方向性的格式化字符可以用来重新组织分组和显示字符的顺序。
上表包含了一些与攻击有关的比迪覆盖字符。以此为例。
RLIe d o cPDI
缩写RLI是指从右到左的隔离。它将把文本从其上下文(由PDI,Pop-Directional-Isolate划定)中分离出来,并从右到左进行阅读。结果是。
ǞǞǞ
然而,编译器和解释器在解析源代码之前通常不处理格式化控制字符,包括Bidi重写。如果他们简单地忽略了方向性的格式化字符,他们就会进行解析。
e d o c
新瓶装旧酒?
当然,这在阳光下并不新鲜。在过去,定向格式化字符被插入文件名中,以掩盖其恶意的性质。一个显示为 "myspecialexe.doc "的电子邮件附件可能看起来很无辜,如果不是因为出现了RLO(从右到左的覆盖)字符,揭示了真正的名称是 "myspecialcod.exe"。
木马源码攻击在源代码中存在的注释和字符串中插入定向格式化字符,因为这些不会产生任何语法或编译错误。这些控制字符改变了代码的逻辑显示顺序,导致编译器读取的内容与人类完全不同。
例如,一个包含以下字节的文件,按这个顺序排列。

将通过方向性的格式化字符重新排序如下

导致代码被渲染成这样,如果方向性的格式化字符没有被明确地叫出来。

在最后一行,RLO将闭合括号翻转为开放括号,反之亦然。执行这段代码的结果将是。"你是一个管理员"。管理员检查被注释掉了,但是控制字符让人觉得它仍然存在。
(来源: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
这对你会有什么影响?
许多语言都容易受到这种攻击。C、C++、C#、JavaScript、Java、Rust、Go和Python,而且估计还有更多。现在,一般的开发者看到源代码中的方向性格式化字符可能会皱眉头,但新手也可能会耸耸肩,觉得没什么。此外,这些字符的可视化在很大程度上取决于IDE,所以不能保证它们会被发现。
但是,这个漏洞首先是如何潜入源代码的呢?首先,这可能发生在使用来源不可靠的源代码时,其中的恶意代码贡献没有被注意到。其次,它可能是通过简单地复制粘贴互联网上的代码而发生的,我们大多数开发人员以前都做过这种事。大多数组织依赖来自多个供应商的软件组件。这就提出了一个问题,我们能在多大程度上完全信任和依赖这些代码?我们怎样才能筛选出含有隐藏后门的源代码?
这是谁的问题?
一方面,编译器和构建管道应该不允许源代码行有一个以上的方向,除非一个方向被严格限制在字符串和注释中。请注意,字符串或注释中的方向性格式化字符,如果不被弹出,可以将方向性变化延长到行的末尾。一般来说,代码编辑器应该明确地呈现和突出可疑的Unicode字符,如同音字和定向格式化字符。自11月起,GitHub现在为每一行包含双向单码文本的代码添加警告标志和信息,尽管它没有突出显示这些字符在行中的位置。这仍然可能使恶意的方向变化与良性的方向变化一起潜入。
开发人员和代码审查人员的认识是至关重要的,这就是为什么我们创建了一个说明该漏洞的演练。目前,该演练适用于Java、C#、Python、GO和PHP。
因此,如果你想了解更多,可以试试我们对木马源的模拟(公共missions ),并阅读木马源研究报告。
资源
安全技能基准测试:简化企业安全设计
寻找有关 "按设计确保安全 "计划成功与否的有意义的数据是众所周知的难题。首席信息安全官(CISO)在试图证明投资回报率(ROI)和安全计划活动在人员和公司层面上的商业价值时,往往会面临挑战。更不用说,企业要深入了解自己的组织是如何以当前的行业标准为基准的,更是难上加难。美国总统的《国家网络安全战略》向利益相关者提出了 "通过设计实现安全和弹性 "的挑战。让 "按设计保证安全 "计划发挥作用的关键不仅在于为开发人员提供确保代码安全的技能,还在于向监管机构保证这些技能已经到位。在本演讲中,我们将分享大量定性和定量数据,这些数据来自多个主要来源,包括从超过 25 万名开发人员那里收集的内部数据点、数据驱动的客户洞察力以及公共研究。利用这些数据点的汇总,我们旨在传达一个跨多个垂直领域的 "按设计保证安全 "计划的现状。报告详细阐述了这一领域目前未得到充分利用的原因、成功的技能提升计划对降低网络安全风险的重大影响,以及消除代码库中各类漏洞的潜力。