ios - Swift容易受到代码注入(inject)的攻击吗？

Question

我正在阅读有关Cycript和Cydia Substrate的信息，以及如何将它们用于iOS应用程序上的代码注入(inject)攻击。如果您在高安全性环境中工作，则这样的代码应该会吓到您。 (忽略/etc/password部分，只需考虑使用crackedMessage替换originalMessage的功能即可。)

cy# MS.hookFunction(fopen, function(path, mode) {
cy>     if (path == "/etc/passwd")
cy>         path = "/var/passwd-fake";
cy>     var file = (*oldf)(path, mode);
cy>     log.push([path, mode, file]);
cy>     return file;
cy> }, oldf)

我读了一个博客(我没有保存)，该博客说Swift不像Objective-C那样脆弱，因为它不那么动态。再说一遍，我还读到您可以执行 method swizzling in Swift，因此我不清楚Swift是否提供任何针对代码注入(inject)攻击的保护措施。

那么，Swift容易受到代码注入(inject)攻击吗？

Answer 1

最终，如果让程序在其设备上运行，则无法阻止他人劫持您的程序。有多种方法可以使其变得更困难，但没有任何方法可以使它变得不可能。

我可以想到将代码注入(inject)到应用程序中的主要方法:

在运行时模糊了Objective-C方法；

通过解析可执行文件并确定正确的位来改变虚拟Swift方法；

修改通话目标；

通过更改符号 stub 目标来模糊导入的符号；

使用dyld强制加载库或更改程序加载的库；

替换您的程序链接到的库。

在用户完全控制的环境中，没有100％有效的方法来防止上述任何一种情况。您应该根据威胁模型来决定是否担心。

运行时困惑的Objective-C方法

方法困惑是一种技术，您可以在运行时使用任意不同的代码(通常出于不同的目的)更改方法的实现。常见的用例是绕过检查或记录参数。

在Objective-C中困惑是一件大事，因为运行时需要标识每个方法和每个实例字段的元数据。我不知道有任何其他语言可以编译为本地机器代码，并且可以保留这么多的元数据。如果您有类似 -[AccessControl validatePassword:]的东西，那么您就使坏家伙们变得非常容易。使用 method_setImplementation ，这只是乞求发生。

由于Swift类可以从Objective-C类继承，因此仍然需要寻找这些东西。但是，从Objective-C类继承的类上的新方法只有具有 @objc属性(或者如果类本身具有 @objc属性)才向Objective-C运行时公开，因此与Objective相比，这限制了攻击面-C。

另外，Swift编译器可以绕过Objective-C运行时来调用，取消虚拟化或内联未标记为 dynamic 的Swift方法，即使它们被标记为 @objc。这意味着在某些情况下，只有通过Objective-C分派(dispatch)的调用才有可能出现困惑。

当然，如果您的类或方法没有暴露给Objective-C运行时，那是完全不可能的。

通过解析可执行文件并找出正确的位来改变虚拟的Swift方法

但是，您不需要Objective-C运行时即可交换方法实现。 Swift仍然具有用于其虚拟方法的虚拟表，截至2015年2月，它们位于可执行文件的 __DATA段中。它是可写的，因此，如果您可以找出要更改的正确位，则应该可以使用Swift虚拟方法。没有方便的API。

可以类似地修改C++类，但是默认情况下Swift方法是虚拟的，攻击面更大。如果编译器没有覆盖，则允许将方法虚拟化为一种优化，但是不承担将编译器优化作为安全功能的责任。

默认情况下，已部署的Swift可执行文件为 strip ped。非 public/ open符号的信息将被丢弃，与Objective-C相比，这使识别要更改的符号更加困难。不会删除 Public/ open符号，因为假定其他外部代码客户端可能需要它们。

但是，如果有人弄清楚他们想换出哪个函数实现，那么他们要做的就是将新实现的地址写入正确的虚拟表插槽中。他们可能需要制作自己的Mach-O解析器，但这肯定不超出制作Cycript之类的人员的范围。

最后， final方法降低了这种风险，因为编译器不需要通过vtable调用它们。同样， struct方法永远不会是虚拟的。

修改通话目标

如果其他所有方法均失败，则攻击者仍然可以遍历您的机器代码，并将 bl或 call指令操作数更改为他们希望的任何位置。这种方法涉及更多，并且很难/不可能用一种自动化的方法正确地实现100％正确，尤其是在缺少符号的情况下，但是有足够决心的人将能够做到这一点。您可以决定是否有人最终会为您的应用程序感到麻烦。

这适用于虚拟和非虚拟方法。但是，当编译器内联调用时，这是极其困难的。

通过更改符号 stub 目标来搅乱导入的符号

任何导入的符号，无论使用哪种语言编写以及使用的语言，都容易产生困惑。这是因为外部符号在运行时绑定(bind)。每当您使用外部库中的函数时，编译器都会在查找表中生成一个条目。这是一个示例，说明如果您将可执行文件返回到C代码，则对 fopen的调用可能看起来像:

FILE* locate_fopen(const char* a, const char* b) {
    fopen_stub = dyld->locate("fopen"); // find actual fopen and replace stub pointer to it
    return fopen_stub(a, b);
}

FILE* (*fopen_stub)(const char*, const char*) = &locate_fopen;

int main() {
    FILE* x = fopen_stub("hello.txt", "r");
}

最初对 fopen_stub的调用将找到实际的 fopen，并用它替换 fopen_stub指向的地址。这样，dyld根本不需要在程序及其库开始运行之前就解析成千上万的外部符号。但是，这意味着攻击者可以将 fopen_stub替换为他们想调用的任何函数的地址。这就是您的Cycript示例所做的。

除了编写自己的链接程序和动态链接程序之外，防止这种攻击的唯一保护措施就是不使用共享库或框架。在现代开发环境中，这不是可行的解决方案，因此您可能必须应对它。

可以通过多种方法确保 stub 到达您期望的位置，但这有点不可靠，而且这些检查始终可以由坚定的攻击者用 nop进行。此外，您将无法在共享库无法控制调用导入符号的情况下插入这些检查。如果攻击者决定仅将共享库替换为他们控制的库，这些检查也将毫无用处。

顺便说一句，启动关闭允许dyld 3用预绑定(bind)信息替换这些查找表。我不认为启动关闭程序目前是只读的，但看起来最终可能是关闭的。如果是这样，那么困惑的符号将变得更难。

使用dyld强制加载库或更改程序加载的库

Dyld supports强制将库加载到可执行文件中。此功能可用于替换可执行文件使用的几乎所有导入符号。不喜欢普通的 fopen吗？编写一个 dylib重新定义它!

如果可执行文件被标记为受限，则Dyld将不与该方法配合使用。有 three ways可以达到此状态(查找 pruneEnvironmentVariables):

在可执行文件上启用setuid位或setgid位；

是代码签名的，并且具有“受限制的”仅限OS X的权利；

在名为__restrict的段中具有名为__RESTRICT的部分。

您可以使用以下“其他链接器标志”创建 __restrict部分和 __RESTRICT段:

-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null

请注意，所有这些都很容易破解。当用户控制执行环境时，setuid和setgid位很容易清除，代码签名很容易删除，并且节或段只需重命名即可摆脱受限状态。

替换程序链接到的库

如果所有其他方法均失败，则攻击者仍然可以替换可执行文件用来使其执行其喜欢的操作的共享库。您对此无能为力。

tl; dr

在Swift应用程序中注入(inject)代码比在Objective-C应用程序中注入(inject)代码更难，但是仍然可以实现。可用于注入(inject)代码的大多数方法都是与语言无关的，这意味着没有一种语言会使您更安全。

在大多数情况下，您无法采取任何措施来保护自己免受此侵害。只要用户控制执行环境，您的代码就可以在其系统上作为 guest 运行，并且他们几乎可以用它来做任何想做的事情。