这篇文章将介绍切片表达式(slicing expression)和部分控制流图(Control Flow Graph, CFG)的概念,将它们结合起来实现一个 SMT 驱动的算法来探索虚拟化的 CFG。最后,还将花一些时间介绍 LLVM 优化管道以及它的配置和使用过程中的局限性。

切片器(slicer)

对符号表达式进行切片以对其进行评估、将其发送给 SMT 求解器或将其与某种模式匹配,这在所有符号推理工具中都极为常见。幸运的是,使用另一个 C++ 辅助函数来实现这个功能是微不足道的。在 VMProtect 环境中,我们主要对切片程序计数器感兴趣。我们想要在探索单个 VmBlocks(一旦连接,形成 VmStub)或在探索 VmStubs(一旦连接,形成 VmFunction)时这样做。以下 C++ 代码旨在仅保留与 VmBlock 或 VmStub 末尾的虚拟指令指针的最终值相关的计算:

1.png

敏锐的观察者可能会注意到函数定义与之前给出的 HelperFunction 定义基本相同,基本区别在于参数按值传递,因此如果与切片表达式的计算有关,则很有用。

使用上述辅助函数的步骤是:

◼HelperSlicePC 被复制到一个新的抛弃型(Throwaway) 函数中;

◼对 HelperStub 函数的调用与对我们想要切片最终指令指针的 VmBlock 或 VmStub 的调用交换;

◼被调用的函数被强制内联到 HelperSlicePC 函数中;

◼优化管道在复制的 HelperSlicePC 函数上执行,导致作为优化副作用的最终指令指针表达式的切片。

下面的 LLVM-IR 片段展示了这个想法的实际效果,最终得到优化的函数,其中条件分支的条件和边缘都清晰可见。

2.png

接下来,我们将探索如何使用这种技术的变体来探索虚拟化控制流图、解决条件分支和恢复切换案例。

虚拟化控制流图的探索可以通过不同的方式完成,通常像VMProtect或Themida这样的保护程序会显示一个独特的形状,可以轻松地进行模式匹配、简化和解析,以获得条件块的出边。

不同VMProtect条件跳转版本使用的逻辑在前面已经讲过了,所以接下来我们将深入研究基于探索的控制流图的增量构建。

鉴于详细算法的通用性质,没有什么能阻止它在其他保护程序上使用。通常的问题显然是由嵌入难以解决的约束的保护引起的,这些约束可能会阻碍自动求解阶段,但部分 CFG 约束和表达式的构建和传播在实践中仍然有用,以拉出自动化程度较低的探索算法,或识别并简化反动态符号执行技巧,例如,导致路径爆炸的虚拟循环可以通过 LLVM 的循环优化传递或自定义用户传递来简化。

部分CFG

部分控制流图是在给定已知边的情况下连接当前探索的基本块的控制流图。构建它背后的想法是,每次我们探索一个新的基本块都可能导致一些新的基本块,甚至是已知的基本块。因此,两个块之间的每条新边界都向整个控制流图添加信息,我们实际上可以传播新的有用约束和值以实现更强大的优化,可能简化条件分支的求解,甚至将已知分支从无条件改为有条件。

接下来我会讲解两个示例,说明为什么构建部分 CFG 可能是一个好主意,因为这可以复制通常由符号执行工具实现的推理类型,并添加有用的内置LLVM通道。

示例1

考虑下面的部分控制流图,其中蓝色表示刚刚处理过的VmBlock,橙色表示未处理的VmBlock,紫色表示示例中感兴趣的VmBlock。

3.png

假设我们刚刚解决了基本块 A 的输出边界,获得了通向新基本块 B 和 C 的两个连接。 现在假设我们对唯一基本块 B 的分支条件进行切片,获得对常量数组的访问64 位符号索引。枚举所有有效索引可能不是一项简单的任务,因此我们可能希望使用符号索引上的已知约束来限制搜索,如果存在,这些约束很可能来自前驱链基本块 B。为了绘制一个符号执行并行,我们需要从一定数量的原有内容中收集路径约束的情况,例如,我们可能想要增量地获取约束,因为有时所需的约束在我们正在求解的基本块附近,并将它们链接起来,以提供给SMT求解器,执行有效索引的成功枚举。

像 Souper 这样的工具在切片表达式时会自动收集路径约束集,因此构建部分控制流图并将其提供给 Souper 可能足以完成任务。此外,使用 LLVM API 来遍历基本块的原有内容,也很容易获得所需的约束集,并且我们还可以利用LLVM提供的已知的真实条件。

示例2

考虑下面的部分控制流图,其中蓝色代表刚刚处理过的 VmBlock,橙色代表未处理的 VmBlock,紫色代表示例中感兴趣的 VmBlock,红色虚线箭头表示示例中边,实线绿色箭头表示边刚刚处理过的。

4.png

假设我们刚刚解决了基本块 E 的输出边界,获得了通向新块 G 和已知块 B 的两个连接。那就可以知道我们检测到了到先前访问过的块 B(绿色边)的跳转,这基本上形成了一个循环链(B→C→E→B),从B开始,我们可以到达目前已知为无条件的两条边(B→C和D→F,用红色虚线标记),但是,鉴于新获得的边 E → B,可能不再存在,因此需要再次证明。构建一个新的部分控制流图,包括所有新发现的基本块连接,并对块 B 和 D 的分支进行切片,现在可以将它们显示为有条件的。

在实践中,当处理conconic执行方法时,上面提到的是基于索引的循环的常见模式,从已知的具体索引开始运行,直到索引达到上限或下限N。在第一次执行N-1次时,工具将采用相同的路径,只有在迭代N时,才会探索其他路径。这就是为什么concolic和符号执行工具试图构建启发式或使用状态合并等技术来避免遇到路径爆炸问题或最多执行循环N次的原因。

相反,使用 LLVM 构建部分 CFG 会将第一次循环返回边缘标记为无条件,但再次构建它,包括新发现的后边缘的知识,将立即揭示循环模式。结果是 LLVM 现在将能够应用其循环分析传递,用户将能够使用API来构建特别的LoopPass传递来处理应用于循环组件的特殊混淆(例如,编码循环变量/不变变量)或SMT求解器将能够将合并点上新创建的Phi节点视为符号变量。

下面的LLVM-IR片段显示了在探索下面展示的虚拟化组装片段期间获得的切片部分控制流图。

5.png

FirstSlice函数显示已经检测到一个无条件分支,标识字节码地址0x1400B85C1(5369464257),这是因为不知道后边界,比较结果为 cmp 1, 2000。 SecondSlice 函数显示有条件的分支检测到在字节码地址 0x140073BE7 (5369183207) 和 0x1400B85C1 (5369464257) 之间进行选择的分支。现在使用符号 PHINode 完成比较。 F_0x14000101f_WithLoopOpt 和 F_0x14000101f_NoLoopOpt 函数显示了应用和未应用循环优化的完全去虚拟化代码。

伪代码

部分 CFG伪代码如下:

1. 初始化算法创建:

6.png

2.我们将入口VmBlock的地址推入Worklist;

3.我们获取要探索的 VmBlock 的地址,如果第一次遇到,我们将其提升到 LLVM-IR,使用来自 Edges 映射的知识构建部分 CFG,然后我们对当前 VmBlock 的分支条件进行切片。最后,我们将分支条件提供给 Souper,Souper 将处理表达式,收集所需的约束并将其转换为 SMT 查询。然后,我们可以将查询发送到 SMT 求解器,询问有效的解决方案,逐步拒绝已知解决方案直至达到某个限制或直到找到所有解决方案。

4.一旦我们获得了当前 VmBlock 的输出边,就可以继续更新映射和集合:

4.1我们验证每个求解的边是否通向一个已知的 VmBlock,如果是,我们就会确认这一联系之前是否为人所知。如果未知,则意味着我们找到了已知 VmBlock 的新前身,然后我们继续将已知 VmBlock 可访问的所有 VmBlock 的地址添加到 Reprove 集并将它们从探索集中删除,为了加快速度,我们最终可以无条件跳过每个VmBlock。

4.2我们用新解决的边更新Edges映射。

此时我们检查 Worklist 是否为空。如果不是,我们跳回第 3 步。如果是,我们用 Reprove 集中的所有地址填充它,在这个过程中清除它并跳回第 3 步。如果 Reprove 集也是空的,它意味着我们探索了整个CFG,并最终在探索阶段对所有获得新原有内容的VmBlocks进行验证。

如本节开头所述,探索虚拟化 CFG 的方法有很多,使用 SMT 驱动的解决方案可以概括大部分步骤。显然,这也带来了一系列新问题(例如难以解决的约束),因此人们最终可以在需要时退回到基于模式匹配的解决方案。正如预期的那样,基于模式匹配的解决方案有时也会盲目地探索不可达的路径,因此混合解决方案确实可以提供最佳的 CFG 覆盖。

本节中提供的伪代码是 SATURN 目前使用的基于部分 CFG 的探索算法的简化版本,简化了在探索由 VMProtect 虚拟化的 CFG 时不必要的一组推理。

管道

到目前为止,我们已经多次介绍了LLVM的优化和分析的底层用法,现在就让我们看看它们的配置和局限性。

管理管道

运行整个 -O3 管道可能并不总是最好的主意,因为我们可能只想使用它的一个子集,此外,默认情况下,LLVM 提供了一个执行一次的优化链,旨在优化非混淆代码。

我们的要求如下:

1.添加一些自定义通道来解决特定于上下文的问题,并在管道中的精确点执行此操作以获得最佳输出,同时避免相位排序问题;

2.多次迭代优化管道,直到我们的自定义通道不能对IR代码应用任何更改;

3.能够向管道传递自定义标志,以便随意切换一些通道,并最终为它们提供从二进制文件中获得的信息,例如访问二进制文件部分。

LLVM 提供了一个 FunctionPassManager 类来自定义管道,使用 LLVM 的通道和自定义通道。下面的c++代码片段展示了我们如何添加一个混合的通道,这些通道将按顺序执行,直到不再有任何更改或达到阈值为止:

7.png

OptimizationGuide结构可以用来将信息传递给自定义通道,并控制管道的执行

配置

如前所述,LLVM默认管道意味着尽可能高效,因此它在配置时考虑了效率和效能之间的权衡。在对大函数进行去虚拟化时,看到默认使用的更严格配置的影响并不少见。

在Godbolt UI中,我们可以在左边看到一个LLVM-IR代码片段,该代码将 i32 值存储在名为 arr 的全局数组的递增索引处。第96行的store在arr[1]处写了值91,这有点特殊,因为它完全覆盖了第6行的store,在arr[1]处写了值1。如果我们查看右上角的结果,就会看到应用了DSE通道,但不知为什么它没有在第6行删除失效store。如果我们查看右下方的结果,就会看到DSE通道设法实现了它的目标,并在第 6 行成功阻止了失效store。 产生这种差异的原因完全与DSE通道的保守配置有关,默认情况下,在确定一个store没有阻止另一个后主导store之前,将估计多达90个MemorySSA定义。将memoryssaupwardsstepllimit设置为一个更高的值(例如示例中的100),这肯定是我们在消除一些代码混淆时想要做的事情。

我们要添加到自定义管道的每个通道都可能会提供次优反混淆结果的配置,因此检查它们的 C++ 实现并确定调整某些选项是否可以改善输出是一个好主意。

当调整一些配置没有给出预期的结果时,我们可能需要更深入地研究一下通道的实现,以了解是否有什么阻碍了它的工作,下面是一些关于为什么深入研究通道实现可能会导致带来卓有成效的改进的示例。

IsGuaranteedLoopInvariant (DSE, MSSA)

在查看一些非虚拟化代码时,我注意到即使启用了调整后的配置,一些明显已经失效的存储并没有被 DSE 删除。原因是IsGuarenteedLoopInvariant函数使用的内镜下动态慢动作影像MSSA传递并没有使用一个指针的安全假设计算块的条目。

GetPointerBaseWithConstantOffset (DSE)

在查看一些访问不同大小内存插槽的非虚拟化代码时,我注意到一些明显已经失效的存储并没有被 DSE 删除,即使启用了调整后的配置。原因是,在计算部分重叠的内存存储时,DSE只考虑具有相同基址的内存插槽,而忽略了完全重叠的相互偏移的存储。解决方案是使用另一个补丁,它提供关于内存插槽偏移量的信息:D93529。

这篇文章将介绍切片表达式(slicing expression)和部分控制流图(Control Flow Graph, CFG)的概念,将它们结合起来实现一个 SMT 驱动的算法来探索虚拟化的 CFG。最后,还将花一些时间介绍 LLVM 优化管道以及它的配置和使用过程中的局限性。

切片器(slicer)

对符号表达式进行切片以对其进行评估、将其发送给 SMT 求解器或将其与某种模式匹配,这在所有符号推理工具中都极为常见。幸运的是,使用另一个 C++ 辅助函数来实现这个功能是微不足道的。在 VMProtect 环境中,我们主要对切片程序计数器感兴趣。我们想要在探索单个 VmBlocks(一旦连接,形成 VmStub)或在探索 VmStubs(一旦连接,形成 VmFunction)时这样做。以下 C++ 代码旨在仅保留与 VmBlock 或 VmStub 末尾的虚拟指令指针的最终值相关的计算:

1.png

敏锐的观察者可能会注意到函数定义与之前给出的 HelperFunction 定义基本相同,基本区别在于参数按值传递,因此如果与切片表达式的计算有关,则很有用。

使用上述辅助函数的步骤是:

◼HelperSlicePC 被复制到一个新的抛弃型(Throwaway) 函数中;

◼对 HelperStub 函数的调用与对我们想要切片最终指令指针的 VmBlock 或 VmStub 的调用交换;

◼被调用的函数被强制内联到 HelperSlicePC 函数中;

◼优化管道在复制的 HelperSlicePC 函数上执行,导致作为优化副作用的最终指令指针表达式的切片。

下面的 LLVM-IR 片段展示了这个想法的实际效果,最终得到优化的函数,其中条件分支的条件和边缘都清晰可见。

2.png

接下来,我们将探索如何使用这种技术的变体来探索虚拟化控制流图、解决条件分支和恢复切换案例。

虚拟化控制流图的探索可以通过不同的方式完成,通常像VMProtect或Themida这样的保护程序会显示一个独特的形状,可以轻松地进行模式匹配、简化和解析,以获得条件块的出边。

不同VMProtect条件跳转版本使用的逻辑在前面已经讲过了,所以接下来我们将深入研究基于探索的控制流图的增量构建。

鉴于详细算法的通用性质,没有什么能阻止它在其他保护程序上使用。通常的问题显然是由嵌入难以解决的约束的保护引起的,这些约束可能会阻碍自动求解阶段,但部分 CFG 约束和表达式的构建和传播在实践中仍然有用,以拉出自动化程度较低的探索算法,或识别并简化反动态符号执行技巧,例如,导致路径爆炸的虚拟循环可以通过 LLVM 的循环优化传递或自定义用户传递来简化。

部分CFG

部分控制流图是在给定已知边的情况下连接当前探索的基本块的控制流图。构建它背后的想法是,每次我们探索一个新的基本块都可能导致一些新的基本块,甚至是已知的基本块。因此,两个块之间的每条新边界都向整个控制流图添加信息,我们实际上可以传播新的有用约束和值以实现更强大的优化,可能简化条件分支的求解,甚至将已知分支从无条件改为有条件。

接下来我会讲解两个示例,说明为什么构建部分 CFG 可能是一个好主意,因为这可以复制通常由符号执行工具实现的推理类型,并添加有用的内置LLVM通道。

示例1

考虑下面的部分控制流图,其中蓝色表示刚刚处理过的VmBlock,橙色表示未处理的VmBlock,紫色表示示例中感兴趣的VmBlock。

3.png

假设我们刚刚解决了基本块 A 的输出边界,获得了通向新基本块 B 和 C 的两个连接。 现在假设我们对唯一基本块 B 的分支条件进行切片,获得对常量数组的访问64 位符号索引。枚举所有有效索引可能不是一项简单的任务,因此我们可能希望使用符号索引上的已知约束来限制搜索,如果存在,这些约束很可能来自前驱链基本块 B。为了绘制一个符号执行并行,我们需要从一定数量的原有内容中收集路径约束的情况,例如,我们可能想要增量地获取约束,因为有时所需的约束在我们正在求解的基本块附近,并将它们链接起来,以提供给SMT求解器,执行有效索引的成功枚举。

像 Souper 这样的工具在切片表达式时会自动收集路径约束集,因此构建部分控制流图并将其提供给 Souper 可能足以完成任务。此外,使用 LLVM API 来遍历基本块的原有内容,也很容易获得所需的约束集,并且我们还可以利用LLVM提供的已知的真实条件。

示例2

考虑下面的部分控制流图,其中蓝色代表刚刚处理过的 VmBlock,橙色代表未处理的 VmBlock,紫色代表示例中感兴趣的 VmBlock,红色虚线箭头表示示例中边,实线绿色箭头表示边刚刚处理过的。

4.png

假设我们刚刚解决了基本块 E 的输出边界,获得了通向新块 G 和已知块 B 的两个连接。那就可以知道我们检测到了到先前访问过的块 B(绿色边)的跳转,这基本上形成了一个循环链(B→C→E→B),从B开始,我们可以到达目前已知为无条件的两条边(B→C和D→F,用红色虚线标记),但是,鉴于新获得的边 E → B,可能不再存在,因此需要再次证明。构建一个新的部分控制流图,包括所有新发现的基本块连接,并对块 B 和 D 的分支进行切片,现在可以将它们显示为有条件的。

在实践中,当处理conconic执行方法时,上面提到的是基于索引的循环的常见模式,从已知的具体索引开始运行,直到索引达到上限或下限N。在第一次执行N-1次时,工具将采用相同的路径,只有在迭代N时,才会探索其他路径。这就是为什么concolic和符号执行工具试图构建启发式或使用状态合并等技术来避免遇到路径爆炸问题或最多执行循环N次的原因。

相反,使用 LLVM 构建部分 CFG 会将第一次循环返回边缘标记为无条件,但再次构建它,包括新发现的后边缘的知识,将立即揭示循环模式。结果是 LLVM 现在将能够应用其循环分析传递,用户将能够使用API来构建特别的LoopPass传递来处理应用于循环组件的特殊混淆(例如,编码循环变量/不变变量)或SMT求解器将能够将合并点上新创建的Phi节点视为符号变量。

下面的LLVM-IR片段显示了在探索下面展示的虚拟化组装片段期间获得的切片部分控制流图。

5.png

FirstSlice函数显示已经检测到一个无条件分支,标识字节码地址0x1400B85C1(5369464257),这是因为不知道后边界,比较结果为 cmp 1, 2000。 SecondSlice 函数显示有条件的分支检测到在字节码地址 0x140073BE7 (5369183207) 和 0x1400B85C1 (5369464257) 之间进行选择的分支。现在使用符号 PHINode 完成比较。 F_0x14000101f_WithLoopOpt 和 F_0x14000101f_NoLoopOpt 函数显示了应用和未应用循环优化的完全去虚拟化代码。

伪代码

部分 CFG伪代码如下:

1. 初始化算法创建:

6.png

2.我们将入口VmBlock的地址推入Worklist;

3.我们获取要探索的 VmBlock 的地址,如果第一次遇到,我们将其提升到 LLVM-IR,使用来自 Edges 映射的知识构建部分 CFG,然后我们对当前 VmBlock 的分支条件进行切片。最后,我们将分支条件提供给 Souper,Souper 将处理表达式,收集所需的约束并将其转换为 SMT 查询。然后,我们可以将查询发送到 SMT 求解器,询问有效的解决方案,逐步拒绝已知解决方案直至达到某个限制或直到找到所有解决方案。

4.一旦我们获得了当前 VmBlock 的输出边,就可以继续更新映射和集合:

4.1我们验证每个求解的边是否通向一个已知的 VmBlock,如果是,我们就会确认这一联系之前是否为人所知。如果未知,则意味着我们找到了已知 VmBlock 的新前身,然后我们继续将已知 VmBlock 可访问的所有 VmBlock 的地址添加到 Reprove 集并将它们从探索集中删除,为了加快速度,我们最终可以无条件跳过每个VmBlock。

4.2我们用新解决的边更新Edges映射。

此时我们检查 Worklist 是否为空。如果不是,我们跳回第 3 步。如果是,我们用 Reprove 集中的所有地址填充它,在这个过程中清除它并跳回第 3 步。如果 Reprove 集也是空的,它意味着我们探索了整个CFG,并最终在探索阶段对所有获得新原有内容的VmBlocks进行验证。

如本节开头所述,探索虚拟化 CFG 的方法有很多,使用 SMT 驱动的解决方案可以概括大部分步骤。显然,这也带来了一系列新问题(例如难以解决的约束),因此人们最终可以在需要时退回到基于模式匹配的解决方案。正如预期的那样,基于模式匹配的解决方案有时也会盲目地探索不可达的路径,因此混合解决方案确实可以提供最佳的 CFG 覆盖。

本节中提供的伪代码是 SATURN 目前使用的基于部分 CFG 的探索算法的简化版本,简化了在探索由 VMProtect 虚拟化的 CFG 时不必要的一组推理。

管道

到目前为止,我们已经多次介绍了LLVM的优化和分析的底层用法,现在就让我们看看它们的配置和局限性。

管理管道

运行整个 -O3 管道可能并不总是最好的主意,因为我们可能只想使用它的一个子集,此外,默认情况下,LLVM 提供了一个执行一次的优化链,旨在优化非混淆代码。

我们的要求如下:

1.添加一些自定义通道来解决特定于上下文的问题,并在管道中的精确点执行此操作以获得最佳输出,同时避免相位排序问题;

2.多次迭代优化管道,直到我们的自定义通道不能对IR代码应用任何更改;

3.能够向管道传递自定义标志,以便随意切换一些通道,并最终为它们提供从二进制文件中获得的信息,例如访问二进制文件部分。

LLVM 提供了一个 FunctionPassManager 类来自定义管道,使用 LLVM 的通道和自定义通道。下面的c++代码片段展示了我们如何添加一个混合的通道,这些通道将按顺序执行,直到不再有任何更改或达到阈值为止:

7.png

OptimizationGuide结构可以用来将信息传递给自定义通道,并控制管道的执行

配置

如前所述,LLVM默认管道意味着尽可能高效,因此它在配置时考虑了效率和效能之间的权衡。在对大函数进行去虚拟化时,看到默认使用的更严格配置的影响并不少见。

在Godbolt UI中,我们可以在左边看到一个LLVM-IR代码片段,该代码将 i32 值存储在名为 arr 的全局数组的递增索引处。第96行的store在arr[1]处写了值91,这有点特殊,因为它完全覆盖了第6行的store,在arr[1]处写了值1。如果我们查看右上角的结果,就会看到应用了DSE通道,但不知为什么它没有在第6行删除失效store。如果我们查看右下方的结果,就会看到DSE通道设法实现了它的目标,并在第 6 行成功阻止了失效store。 产生这种差异的原因完全与DSE通道的保守配置有关,默认情况下,在确定一个store没有阻止另一个后主导store之前,将估计多达90个MemorySSA定义。将memoryssaupwardsstepllimit设置为一个更高的值(例如示例中的100),这肯定是我们在消除一些代码混淆时想要做的事情。

我们要添加到自定义管道的每个通道都可能会提供次优反混淆结果的配置,因此检查它们的 C++ 实现并确定调整某些选项是否可以改善输出是一个好主意。

当调整一些配置没有给出预期的结果时,我们可能需要更深入地研究一下通道的实现,以了解是否有什么阻碍了它的工作,下面是一些关于为什么深入研究通道实现可能会导致带来卓有成效的改进的示例。

IsGuaranteedLoopInvariant (DSE, MSSA)

在查看一些非虚拟化代码时,我注意到即使启用了调整后的配置,一些明显已经失效的存储并没有被 DSE 删除。原因是IsGuarenteedLoopInvariant函数使用的内镜下动态慢动作影像MSSA传递并没有使用一个指针的安全假设计算块的条目。

GetPointerBaseWithConstantOffset (DSE)

在查看一些访问不同大小内存插槽的非虚拟化代码时,我注意到一些明显已经失效的存储并没有被 DSE 删除,即使启用了调整后的配置。原因是,在计算部分重叠的内存存储时,DSE只考虑具有相同基址的内存插槽,而忽略了完全重叠的相互偏移的存储。解决方案是使用另一个补丁,它提供关于内存插槽偏移量的信息:D93529。

据司法部称,在入侵了AT&T的内部网络并成功安装上了恶意软件之后,一个作案长达七年的电话解锁恶意软件的头目将会被判刑。

罪犯是来自巴基斯坦的格林纳达的穆罕默德-法赫德(Muhammad Fahd),他因在华盛顿州博特尔(Bothell)的一个呼叫中心诱导诈骗AT&T员工而被定罪。他和其他已死亡的同谋者共同贿赂员工,首先使用他们的AT&T证书,然后将该公司仍在合同期内的客户的电话从AT&T网络中切断,这意味着这些客户可以将他们的电话转移到另一个服务机构中。而后,法赫德要求他在呼叫中心的同伙安装定制的恶意软件和黑客工具,这样就可以使他从巴基斯坦远程解锁手机。

总的来说,35岁的法赫德在将近200万部手机从运营商的网络切断后,有效地骗取了超过2亿美元的订购费。

解锁手机可以有效地将其从AT&T的网络中移除,从而使账户持有人不必向AT&T支付服务费或支付任何购买手机的费用。

招聘内部人员进行攻击

这一切都始于2012年的夏天,法赫德通过Facebook以 "Frank Zhang "的化名锁定了一名AT&T的员工,他向该员工提供了巨额资金贿赂其参与该计划,并要求该员工也招募其他的AT&T员工加入该团伙。

他还给出了如何清洗贿赂资金的指示。法赫德会指示那些参与该计划的员工注册虚假的企业以及该企业所对应的银行账户,方便接受付款,并为每笔存入虚假企业银行账户的款项伪造虚假的发票,造成一种这些钱是为真正的服务付款的假象。

大约一年后,即2013年春天,在AT&T实施新的攻击计划后,法赫德公司的处境变得有些艰难。法赫德并没有气馁,他雇用了一名软件开发人员设计恶意软件,使他能够更有效地解锁更多手机。同时,该恶意软件也被隐蔽地安装在AT&T的网络上,这又要感谢他招募的公司内部人员。

应法赫德的要求,为协助攻击能顺利进行,这些员工向法赫德提供了有关AT&T电脑系统和解锁程序的机密信息。法赫德还让员工在AT&T的电脑上安装恶意软件,以获取AT&T电脑系统的信息和AT&T其他员工的网络访问凭证。法赫德将这些信息提供给他的恶意软件开发者,这样开发者就可以定制恶意软件,使其在AT&T的电脑上运行。

当然,这种访问可能会被用于不同类型的网络攻击,如勒索软件攻击或大规模的间谍活动,但法赫德的唯一目标似乎是对手机进行劫持。美国电话电报公司的取证分析显示,总共有190万部手机被解锁,使美国电话电报公司的潜在手机用户损失了2亿美元。因此,法赫德被命令将这些钱归还给公司。

2015年,美国电话电报公司对和案件相关的呼叫中心工作人员提起诉讼,并对这一攻击行为进行了详细说明。直接对客户进行服务的是一家名为Swift Unlocks的公司,该公司为消费者提供手机解锁服务。当有人要求解锁时,Swift Unlocks就会答应,利用恶意软件对AT&T系统的远程访问获得解锁代码。

根据诉讼,为促进这项工作的进行,AT&T的员工每两周都会获得2000美元的报酬,其中两名头目分别获得了10,500美元和20,000美元。AT&T在2013年10月左右发现了这个恶意软件,并解雇了相关员工。最终,警方追溯到了法赫德和他的团队。

法赫德在2017年被起诉,2018年在香港被捕。然后他被引渡,并于2019年8月在西雅图的美国地区法院出庭。他在去年9月承认了共谋进行电信欺诈的罪行。

据司法部称,在入侵了AT&T的内部网络并成功安装上了恶意软件之后,一个作案长达七年的电话解锁恶意软件的头目将会被判刑。

罪犯是来自巴基斯坦的格林纳达的穆罕默德-法赫德(Muhammad Fahd),他因在华盛顿州博特尔(Bothell)的一个呼叫中心诱导诈骗AT&T员工而被定罪。他和其他已死亡的同谋者共同贿赂员工,首先使用他们的AT&T证书,然后将该公司仍在合同期内的客户的电话从AT&T网络中切断,这意味着这些客户可以将他们的电话转移到另一个服务机构中。而后,法赫德要求他在呼叫中心的同伙安装定制的恶意软件和黑客工具,这样就可以使他从巴基斯坦远程解锁手机。

总的来说,35岁的法赫德在将近200万部手机从运营商的网络切断后,有效地骗取了超过2亿美元的订购费。

解锁手机可以有效地将其从AT&T的网络中移除,从而使账户持有人不必向AT&T支付服务费或支付任何购买手机的费用。

招聘内部人员进行攻击

这一切都始于2012年的夏天,法赫德通过Facebook以 "Frank Zhang "的化名锁定了一名AT&T的员工,他向该员工提供了巨额资金贿赂其参与该计划,并要求该员工也招募其他的AT&T员工加入该团伙。

他还给出了如何清洗贿赂资金的指示。法赫德会指示那些参与该计划的员工注册虚假的企业以及该企业所对应的银行账户,方便接受付款,并为每笔存入虚假企业银行账户的款项伪造虚假的发票,造成一种这些钱是为真正的服务付款的假象。

大约一年后,即2013年春天,在AT&T实施新的攻击计划后,法赫德公司的处境变得有些艰难。法赫德并没有气馁,他雇用了一名软件开发人员设计恶意软件,使他能够更有效地解锁更多手机。同时,该恶意软件也被隐蔽地安装在AT&T的网络上,这又要感谢他招募的公司内部人员。

应法赫德的要求,为协助攻击能顺利进行,这些员工向法赫德提供了有关AT&T电脑系统和解锁程序的机密信息。法赫德还让员工在AT&T的电脑上安装恶意软件,以获取AT&T电脑系统的信息和AT&T其他员工的网络访问凭证。法赫德将这些信息提供给他的恶意软件开发者,这样开发者就可以定制恶意软件,使其在AT&T的电脑上运行。

当然,这种访问可能会被用于不同类型的网络攻击,如勒索软件攻击或大规模的间谍活动,但法赫德的唯一目标似乎是对手机进行劫持。美国电话电报公司的取证分析显示,总共有190万部手机被解锁,使美国电话电报公司的潜在手机用户损失了2亿美元。因此,法赫德被命令将这些钱归还给公司。

2015年,美国电话电报公司对和案件相关的呼叫中心工作人员提起诉讼,并对这一攻击行为进行了详细说明。直接对客户进行服务的是一家名为Swift Unlocks的公司,该公司为消费者提供手机解锁服务。当有人要求解锁时,Swift Unlocks就会答应,利用恶意软件对AT&T系统的远程访问获得解锁代码。

根据诉讼,为促进这项工作的进行,AT&T的员工每两周都会获得2000美元的报酬,其中两名头目分别获得了10,500美元和20,000美元。AT&T在2013年10月左右发现了这个恶意软件,并解雇了相关员工。最终,警方追溯到了法赫德和他的团队。

法赫德在2017年被起诉,2018年在香港被捕。然后他被引渡,并于2019年8月在西雅图的美国地区法院出庭。他在去年9月承认了共谋进行电信欺诈的罪行。

CVSS评分9.8分的VMware vCenter漏洞PoC发布。

CVE-2021-22005漏洞概述

VMware vCenter服务器是帮助IT管理员在企业环境中通过console管理虚拟主机和虚拟机的服务管理解决方案。9月,安全研究人员George Noseevich等发现了VMware vCenter中的一个文件上传漏洞——CVE-2021-22005。CVE-2021-22005漏洞是Analytics服务中的任意文件上传漏洞,CVSS评分9.8分,未经过认证的远程攻击者可以通过上传精心伪造的文件到受影响的vCenter服务器部署来利用该漏洞以转型命令和软件。整个攻击过程非常简单,且无需任何用户交互。漏洞影响运行vCenter Server 6.7 和 7.0版本的所有应用。

漏洞PoC

随后,越南安全研究人员Jang发布了关于CVE-2021-22005漏洞的技术分析以及VMware补丁的分析。文章最后,Jang还提供了CVE-2021-22005漏洞的PoC代码,但严禁人员称该PoC代码是无害的,因为其中不含有实现远程代码执行的最关键的部分。但相关技术细节非常详细,有经验的开发者可以根据相关技术细节开发漏洞利用,获取root权限以及实现远程代码执行。

9月27日,研究人员wvu发布了CVE-2021-22005漏洞的又一PoC漏洞利用,其利用环境是启用了Customer Experience Improvement Program (CEIP)组件的终端,这也是VMware vCenter的默认状态。但VMware对该漏洞的描述是任何可以通过网络访问vCenter Server的用户都可以利用该漏洞,漏洞利用与vCenter Server的具体配置无关。Wvu还从技术上解释了漏洞利用的每一个步骤,从创建路径遍历所需的目录到反向shell派生。

Wvu称虽然该漏洞利用会生成多个文件,但是攻击活动不会被传统的安全解决方案记录到。

安全建议

研究人员在互联网上搜索暴露在互联网的VMware vCenter示例,shodan显示有超过5000台机器,Censys显示超过6800台机器。

VMware vCenter hosts exposed on the public internet

9月24日,美国CISA也发布了CVE-2021-22005漏洞的安全警示,督促受影响的用户更新机器或应用VMware提供的临时补丁。

CVSS评分9.8分的VMware vCenter漏洞PoC发布。

CVE-2021-22005漏洞概述

VMware vCenter服务器是帮助IT管理员在企业环境中通过console管理虚拟主机和虚拟机的服务管理解决方案。9月,安全研究人员George Noseevich等发现了VMware vCenter中的一个文件上传漏洞——CVE-2021-22005。CVE-2021-22005漏洞是Analytics服务中的任意文件上传漏洞,CVSS评分9.8分,未经过认证的远程攻击者可以通过上传精心伪造的文件到受影响的vCenter服务器部署来利用该漏洞以转型命令和软件。整个攻击过程非常简单,且无需任何用户交互。漏洞影响运行vCenter Server 6.7 和 7.0版本的所有应用。

漏洞PoC

随后,越南安全研究人员Jang发布了关于CVE-2021-22005漏洞的技术分析以及VMware补丁的分析。文章最后,Jang还提供了CVE-2021-22005漏洞的PoC代码,但严禁人员称该PoC代码是无害的,因为其中不含有实现远程代码执行的最关键的部分。但相关技术细节非常详细,有经验的开发者可以根据相关技术细节开发漏洞利用,获取root权限以及实现远程代码执行。

9月27日,研究人员wvu发布了CVE-2021-22005漏洞的又一PoC漏洞利用,其利用环境是启用了Customer Experience Improvement Program (CEIP)组件的终端,这也是VMware vCenter的默认状态。但VMware对该漏洞的描述是任何可以通过网络访问vCenter Server的用户都可以利用该漏洞,漏洞利用与vCenter Server的具体配置无关。Wvu还从技术上解释了漏洞利用的每一个步骤,从创建路径遍历所需的目录到反向shell派生。

Wvu称虽然该漏洞利用会生成多个文件,但是攻击活动不会被传统的安全解决方案记录到。

安全建议

研究人员在互联网上搜索暴露在互联网的VMware vCenter示例,shodan显示有超过5000台机器,Censys显示超过6800台机器。

VMware vCenter hosts exposed on the public internet

9月24日,美国CISA也发布了CVE-2021-22005漏洞的安全警示,督促受影响的用户更新机器或应用VMware提供的临时补丁。

研究人员在iOS 15系统中发现一个新的尚未修复的iPhone锁屏漏洞。

image.png

9月15日,安全研究人员Jose Rodriguez (@VBarraquito)发推称发现了iOS 15和iOS 14.8系统中的尚未修复的锁屏漏洞,可以直接接触到有漏洞设备的攻击者可以通过Siri/Voice Over来绕过锁屏访问Notes APP。

Rodriguez称在现实攻击中,被窃的设备可能会成为攻击的主要目标,攻击者可以利用该锁屏绕过漏洞来访问敏感信息。攻击者利用该漏洞还可以在手机被锁定的情况下,访问即时消息WhatsApp 或Telegram这样的 APP。

研究人员还发布了该锁屏绕过漏洞的PoC视频:

https://www.youtube.com/embed/5L2uVg8FDBs

Rodriguez称,苹果公司已经部分修复了该问题,但在发布的补丁测试过程中并没有联系他。此外,还没有将该漏洞纳入苹果公司的漏洞奖励计划。

该漏洞对于个人和企业用户是很严重的威胁,因此,研究人员建议安全研究人员在进行手机渗透测试评估中将该漏洞包含在内。

研究人员在iOS 15系统中发现一个新的尚未修复的iPhone锁屏漏洞。

image.png

9月15日,安全研究人员Jose Rodriguez (@VBarraquito)发推称发现了iOS 15和iOS 14.8系统中的尚未修复的锁屏漏洞,可以直接接触到有漏洞设备的攻击者可以通过Siri/Voice Over来绕过锁屏访问Notes APP。

Rodriguez称在现实攻击中,被窃的设备可能会成为攻击的主要目标,攻击者可以利用该锁屏绕过漏洞来访问敏感信息。攻击者利用该漏洞还可以在手机被锁定的情况下,访问即时消息WhatsApp 或Telegram这样的 APP。

研究人员还发布了该锁屏绕过漏洞的PoC视频:

https://www.youtube.com/embed/5L2uVg8FDBs

Rodriguez称,苹果公司已经部分修复了该问题,但在发布的补丁测试过程中并没有联系他。此外,还没有将该漏洞纳入苹果公司的漏洞奖励计划。

该漏洞对于个人和企业用户是很严重的威胁,因此,研究人员建议安全研究人员在进行手机渗透测试评估中将该漏洞包含在内。

随着新一轮科技革命和产业变革席卷全球,云计算、大数据、5G、人工智能、区块链等新技术不断涌现,给网络空间安全带来了新的机遇与挑战。9月27日,由国家计算机网络应急技术处理协调中心主办、以“凝聚共识,构建更紧密的网络安全合作伙伴关系”为主题的网络安全技术发展和国际合作论坛顺利召开。论坛汇聚国内外互联网领域诸多大咖,在专题对话环节,天融信科技集团董事长兼CEO李雪莹博士向与会嘉宾以及现场观众分享了新技术、新领域下的网络安全技术发展趋势,并就如何整体提升网络安全能力发表精彩观点:

图片1.png

观点1:新技术促进网络安全能力提升 

李雪莹博士:以云计算、大数据、人工智能、5G等为代表的新技术的出现,促进了网络安全能力的进一步提升。例如,利用大数据,让我们能够更好发现安全事件,这源于大数据高强度的处理能力,以及它所追求的数据之间的相关关系而非因果关系,有助于提升网络安全监测与预警能力。又如,利用人工智能,基于特征会有一些发现,如果基于行为,则能做出更加精准的判断,进而提升访问控制与问题发现的效能。

观点2:新技术引发网络安全新需求

李雪莹博士:新技术在提升安全能力的同时,也给我们带来新的安全问题,进而引发出一系列新的安全需求。例如,在云计算方面,云环境下网络边界依然存在,只是由南北向边界和东西向边界取代了传统物理边界,这也对安全能力提出了更高要求。又如,在5G方面,5G的SDN架构在扩展网络边界的同时,又引入了很多敏感的网元,带来新的安全需求。而5G还带来了切片,包括切片控制层面、策略层面,这些都会产生新的安全需求。此外,5G部署的基站量很大,数据量也很大,这又带来边缘计算的安全需求。

总之,新技术一方面提升了网络安全能力,另一方面确实也给安全提出了很多新的挑战,这也为我们带来一些新的机遇。

观点3:新领域为网络安全市场打开新空间

李雪莹博士:工业互联网、物联网、车联网等新领域不同于传统企业级网络,在这些领域中都会有一些新的特点。例如,工业里面的协议、应用模式、管理模式,车联网带来的车的控制和娱乐之间通信的问题、车和人的问题、车和路的问题、车和网端的问题等等。从某种程度上讲,新领域的出现给网络安全既带来新挑战,也带来了巨大的市场空间。

观点4:网络安全的着力点应从降低攻击面、提升攻击成本与持续运营三方面综合考虑

李雪莹博士:网络安全威胁发现的能力、态势感知的能力、安全防护的能力,其最终的目标是为构建“可信网络 安全世界”。网络安全的本质是攻防对抗,如何才能做到安全呢?第一,从系统的角度,如果攻击面没有被攻击,那一定是安全的,所以降低攻击面是第一点要做到的事情。第二,提高攻击方的攻击成本,使得攻击方因为成本过高而达不到原计划的攻击效果,这样相对也是安全的。第三,没有不被攻破的防线,一旦被攻击,则要具备及时快速的发现能力、问题处理能力和受损害后的恢复能力。这是一个动态的过程,会有很多我们看不到、不知道的风险和行为,所以需要有持续运营的思路贯彻在里面。

观点5:以体系化、融合化、协同化构建可持续改进机制

李雪莹博士:第一是体系化,即整个技术架构上要成体系部署。基于全域全时监测,达到全面感知。采用灵活的分析引擎,足够量获取的数据,通过分析模型做智能分析,并以此来动态调整我们的防护策略。在这个过程中,要结合平台,结合人,结合业务去做,为用户、客户赋能,形成一套闭环技术体系。  

第二是融合化,安全一直在讲三分技术、七分管理,融合就包括技术和管理的融合,也包括厂商之间的技术融合,以及安全和业务的融合等。

第三是协同,形成多元参与、协同发展的模式。多元主体共同防控网络安全问题成为一种必然的趋势。监管机构、各个行业的主管机构、上/下游厂商和用户等,在网络安全防控中各行其责,切实发挥多元主体协同共治的效用。只有大家携手并进,才能向更安全的目标迈进。

随着新一轮科技革命和产业变革席卷全球,云计算、大数据、5G、人工智能、区块链等新技术不断涌现,给网络空间安全带来了新的机遇与挑战。9月27日,由国家计算机网络应急技术处理协调中心主办、以“凝聚共识,构建更紧密的网络安全合作伙伴关系”为主题的网络安全技术发展和国际合作论坛顺利召开。论坛汇聚国内外互联网领域诸多大咖,在专题对话环节,天融信科技集团董事长兼CEO李雪莹博士向与会嘉宾以及现场观众分享了新技术、新领域下的网络安全技术发展趋势,并就如何整体提升网络安全能力发表精彩观点:

图片1.png

观点1:新技术促进网络安全能力提升 

李雪莹博士:以云计算、大数据、人工智能、5G等为代表的新技术的出现,促进了网络安全能力的进一步提升。例如,利用大数据,让我们能够更好发现安全事件,这源于大数据高强度的处理能力,以及它所追求的数据之间的相关关系而非因果关系,有助于提升网络安全监测与预警能力。又如,利用人工智能,基于特征会有一些发现,如果基于行为,则能做出更加精准的判断,进而提升访问控制与问题发现的效能。

观点2:新技术引发网络安全新需求

李雪莹博士:新技术在提升安全能力的同时,也给我们带来新的安全问题,进而引发出一系列新的安全需求。例如,在云计算方面,云环境下网络边界依然存在,只是由南北向边界和东西向边界取代了传统物理边界,这也对安全能力提出了更高要求。又如,在5G方面,5G的SDN架构在扩展网络边界的同时,又引入了很多敏感的网元,带来新的安全需求。而5G还带来了切片,包括切片控制层面、策略层面,这些都会产生新的安全需求。此外,5G部署的基站量很大,数据量也很大,这又带来边缘计算的安全需求。

总之,新技术一方面提升了网络安全能力,另一方面确实也给安全提出了很多新的挑战,这也为我们带来一些新的机遇。

观点3:新领域为网络安全市场打开新空间

李雪莹博士:工业互联网、物联网、车联网等新领域不同于传统企业级网络,在这些领域中都会有一些新的特点。例如,工业里面的协议、应用模式、管理模式,车联网带来的车的控制和娱乐之间通信的问题、车和人的问题、车和路的问题、车和网端的问题等等。从某种程度上讲,新领域的出现给网络安全既带来新挑战,也带来了巨大的市场空间。

观点4:网络安全的着力点应从降低攻击面、提升攻击成本与持续运营三方面综合考虑

李雪莹博士:网络安全威胁发现的能力、态势感知的能力、安全防护的能力,其最终的目标是为构建“可信网络 安全世界”。网络安全的本质是攻防对抗,如何才能做到安全呢?第一,从系统的角度,如果攻击面没有被攻击,那一定是安全的,所以降低攻击面是第一点要做到的事情。第二,提高攻击方的攻击成本,使得攻击方因为成本过高而达不到原计划的攻击效果,这样相对也是安全的。第三,没有不被攻破的防线,一旦被攻击,则要具备及时快速的发现能力、问题处理能力和受损害后的恢复能力。这是一个动态的过程,会有很多我们看不到、不知道的风险和行为,所以需要有持续运营的思路贯彻在里面。

观点5:以体系化、融合化、协同化构建可持续改进机制

李雪莹博士:第一是体系化,即整个技术架构上要成体系部署。基于全域全时监测,达到全面感知。采用灵活的分析引擎,足够量获取的数据,通过分析模型做智能分析,并以此来动态调整我们的防护策略。在这个过程中,要结合平台,结合人,结合业务去做,为用户、客户赋能,形成一套闭环技术体系。  

第二是融合化,安全一直在讲三分技术、七分管理,融合就包括技术和管理的融合,也包括厂商之间的技术融合,以及安全和业务的融合等。

第三是协同,形成多元参与、协同发展的模式。多元主体共同防控网络安全问题成为一种必然的趋势。监管机构、各个行业的主管机构、上/下游厂商和用户等,在网络安全防控中各行其责,切实发挥多元主体协同共治的效用。只有大家携手并进,才能向更安全的目标迈进。