博客 SDK伪造和Adjust的应对方案

SDK伪造和Adjust的应对方案

什么是SDK 伪造？

SDK 伪造（SDK spoofing），又称重播攻击（replay attack），是移动作弊的一种新型手段，通过生成看似合法的安装来赚取广告主的预算，而事实上没有任何真实安装发生。作弊者利用真实设备在用户没有实际安装应用的情况下来实现欺诈目的。此作弊手段在2017年得到快速发展并被越来越多的作弊者所使用。由于借助的是真实设备，SDK伪造比仿真或安装农场（install farm)生成的虚假安装更难以被发现，也因此非常活跃和易于传播。

SDK伪造的起源

作弊者主要通过拦截跟踪SDK和其后台服务器之间通信的SSL加密，通常通过“中间人攻击”(MITM 攻击)来实现SDK伪造。最常用的方法是使用代理软件（例如Charles Proxy），作弊者只需一次按键即可执行攻击。

在MITM攻击后，作弊者将为他们希望欺诈的应用生成一系列测试安装。由于作弊者能够以明文格式读取所有服务器端连接的URL，他们将了解到哪些URL调用代表应用内事件的特定操作，如首次打开、重复打开应用，甚至是不同类型的应用内事件如购买、升级或任何被跟踪的事件。他们还会研究这些URL的哪些部分是静态的，哪些部分是动态，从而保留静态部分（如共享密钥、事件识别码等），并测试动态部分（如广告ID、或设备特定和环境特定的其它数据等）。

借助回传和近乎实时的安装和事件详情的通信，作弊者可以轻松通过创建点击和匹配安装会话来测试作弊设置。如果安装未被跟踪，说明URL逻辑错误。如果安装被成功跟踪，则说明逻辑正确。不过几十个变量，作弊者只需不断的反复测试，最终将获得其想要的结果。

一旦安装被跟踪，就意味着作弊者成功找到了能创建虚假安装的URL。

需要指出的是，在SDK伪造手段出现的早期，其复杂程度和对URL结构的理解还处于较低的水平，因此较容易被发现和阻止。调用一般来自数据中心或VPN，数据通常毫无意义，填充URL参数的数据也与预期目的不符。

SDK伪造是如何变得更加高级的？

从发现SDK伪造最早期迹象起，Adjust就开始记录、研究并立即采取防御措施。我们采用了最简单和快速的短期应对措施——对归因发布了热更修复程序，基于错误的参数结构和与预期目的不匹配的数据（如上所述）来阻挡作弊安装数据。

Adjust拥有丰富的反作弊经验，我们清楚地知道作弊者正在持续不断地改良技术以对抗我们发布的每一个过滤工具。因此在发布修补程序解决短期问题的同时，我们也在努力寻找长期解决方案——一个可以阻挡任何旨在伪造客户的作弊尝试（更多内容见下文）。正如我们所预料的，作弊者最终发现了我们是如何阻止他们的虚假安装，并就此升级了作弊技术。经过多轮来回对抗后，我们再也无法通过流量数据和被传送数据的失配来识别作弊流量。

SDK伪造作弊技术的真正飞跃就是从这里开始的。作弊者费劲心机以提高作弊技术的先进性。欺诈设备数据开始匹配真实设备流量，并且与多个基于设备的参数（以及之后所有基于设备的参数）保持一致。如果一切都是虚假的，作弊者是如何做到这些的？

简单却令人惊讶的答案是——不是所有的内容都是虚假的。作弊者通过自己所有的或可控制的他人应用来收集真实设备数据。他们收集数据的目的当然是恶意的，但这并不单纯地代表被利用来获取数据的应用也是恶意应用程序。被利用的应用可能是有实际使用价值的应用，或他人的合法应用，作弊者只是通过将其SDK集成到该应用来获取访问权限。SDK的类型不限，从商业SDK到收集信息为不透明的封闭源代码SDK。无论具体环境如何，作弊者都因此有能力访问正在被大量用户使用的应用。拥有可以生成真实设备数据的一个（甚至多个）来源使得作弊者的工作变得轻松得多。由于可以访问真实数据，他们再也无需随机化处理海量数据。但另一方面，反作弊研究和识别此类作弊却变得相当困难。

更糟的是，SDK伪造的复杂程度也随着作弊技术的此次巨大飞跃而被大大提高。URL再也不用从数据中心被调用，或通过VPN来传输。而是通过作弊者拥有访问权限的应用被发送到毫不知情的用户设备上。通俗地说，作弊者服务器运行了一个可以自动创建URL的脚本，来触发我们（或任何其他归因公司）跟踪安装或事件。作弊者现在可以发送URL到用户设备的应用上（作弊者拥有访问权限的应用），而不是直接发送URL到我们的服务器（或通过他们过去使用的匿名渠道）。该应用将在用户设备上执行URL。

这也解释了为什么连接看起来像是来自真实设备（及设备和被传输的数据匹配），因为它的确如此！连接是真实的，设备数据是真实的，设备也是真实的。但用户和应用投放的广告之间并没有交互，而且更大的问题是用户根本就没有安装应用。

我们如何应对SDK伪造？

SDK伪造的高级作弊技术让我们将这些虚假安装归因于虚假广告交互，导致一些客户遭受欺诈。通过发布热更修补程序来阻止这些行为逐渐变得非常困难。在一些极端的情况下，我们不得不人工调查数十万个数据点来证明这些安装实际上是虚假的，以帮助客户挽回广告预算的损失。与此同时，我们一直在努力寻求阻止此类欺诈行为的长久应对措施。

我们尝试了多种解决方案，如证书绑定（certificate pinning），或对每个应用和SDK集成创建校验和哈希（checksum hash）。我们还考虑构建自己的加密方式，但都由于对我们客户应用的CX / UX（客户体验/用户体验）可能造成的负面影响，和降低跟踪质量的潜在风险，这些方案最终流产。例如在证书绑定方案中，随着时间的推移证书过期或各种原因造成的证书弃用都可能会导致安全漏洞（例如2011年Comodo的安全漏洞）。很多应用在运行一段时间后会停止更新，或由于开发团队重组或解散，证书将过期，且对这些应用的跟踪将完成停止。另一个原因是绑定证书将禁用客户和渠道用于跟踪测试的所有常见测试套件。最终，客户（在本例中为移动设备）可以决定不再使用绑定的证书。因此，虽然证书绑定可以有效保障客户服务端通信免受MITM攻击，但仍存在不少漏洞。

最终，我们决定创建签名哈希(hashed signature)对SDK通信包进行签名。我们引入了一个新的动态参数到SDK，由于该参数无法被推测或盗取，且只能使用一次，重播攻击将不再凑效。为了实现安全哈希，且不影响用户体验，我们使用了一个额外的共享密钥，在控制面板中对客户希望保护的每一个应用独立生成密钥。营销人员可以更新密钥，和对不同的应用版本使用不同密钥。我们还支持在一段时间后弃用签名版本，以确保归因在最新签名版本提供的最高安全保障下进行，较旧版本可以从归因中完全删除。

该解决方案与SDK4.12版本同时发布，且对所有客户开放使用，包括未启用Adjust防作弊套件的客户。