零道书院｜互金时代，你的安全感从哪来

近日，外媒 hackread 爆料，优酷近亿账号用户信息在暗网被售卖，引起国内媒体的广泛关注。同时，在此次事件的背后，再次引发公众对信息安全的关注热潮。迈入信息化时代，一切在互联互通中变得透明，信息安全也变得尤为重要。...

在优酷信息泄露被曝出的第一时间内，其做出了回应：优酷采用了多重且无法逆向破解的加密技术，即使黑客尝试拖库也无法破译用户帐号敏感信息。根据已有的信息看，优酷泄露的注册邮箱和密码信息采用的是MD5密码，而在此前的研究中表明，MD5密码在某些情况下对黑产者来说几乎相当于明文密码。在用户信息安全愈发重要的情况下，互联网反欺诈阵营也在步步防守，通过各种手段来阻击黑产者的攻击，确保用户的信息安全。

各种互联网在线反欺诈系统均是由前端埋点（数据收集）和后端数据处理（风险决策）两个大部分组成。常见的技术资料往往强调的是建设后端的大数据处理与数据建模能力，对于前端，仅仅希望收集尽量“全”的数据。

从可信计算（Trusted Computing）的角度来看，前端代码，无论mobile、PC、H5均是运行在使用者完全控制的计算设备中，并不是在一个可信的计算环境中运行，其收集的数据很容易被伪造和篡改。直接的后果就是，黑产者可以伪造任意想要的数据，使得强大的大数据后台garbage in， garbage out，轻易就绕过了反欺诈规则设定。看一个真实的案例：某互联网金融公司的在线消费贷的android版app中，使用了某市场份额使用占比较高的反欺诈SDK。经反编译逆向后，其搜集的部分设备信息列表如下图所示：



反编译后，相关代码几乎等同于明文。据此分析结果可想而知，黑产者只需要使用一些常见的crack手段，即可任意生成收集字段，几乎以零成本“破”了反欺诈模型的数据堡垒。

由此可见，对于反欺诈系统来说，不仅需要后端具有强大的数据处理能力，前端在进行数据收集时也要打造充满安全感的可信环境。

针对上述真实案例，可看出前端的功能需要有两点来组成：

埋点收集设备端数据以供后端反欺诈决策；

建立『软件式可信计算环境』，可靠地收集到设备端数据。

我们的解决方案是：代码层面：

前端的反欺诈埋点SDK，所有易反编译代码都需要进行native改写，native代码的反编译结果为汇编代码，大大增加了黑产者的反编译难度，保护了反欺诈逻辑；

对于客户自身的业务代码，如果有需要，也可以通过我们提供的保护工具，以函数为单位，自动进行native转化。

实现思路基本是：对于系统框架调用、跨函数调用，均自动转化为对应的JNI代码进行桥接；而一般的流程性java代码，先经过编译器转变为DVM虚拟机的字节码，然后通过编写的LLVM编译框架的转换模块，转化为通用的中间字节码(IR)，产出物由LLVM转译成native代码，最终拼装为一个完成的native动态库。静态保护方面：

经过native改写的代码，依然会有一些痕迹可被高段位的黑产者利用。所以接着使用我们研发的自动化系统，根据native的编译产物做如下去痕处理：

所有静态字符串会经过加密混淆；

所有导入符号表，需要通过汇编级桥接，直接隐藏；

所有导出符号表，会被删除；

通过嵌入花指令，添加冗余流程，隐藏真实业务流程。运行保护方面：

静态保护保证了静态反编译工具链的失效。在此基础上，仍需要做动态保护以保证运行时的环境可信：

多进程守护， 检测出是否被断点执行，是否被调试挂载；

调用实体实时监测，避免拖库使用；

检测当前设备是否被root、是否为模拟器；

检测当前进程是否被注入第三方代码。

通过在设备端构建的可信环境，反欺诈前端数据埋点代码就如下图所示。相对于上述真实案例中经反编译后的『明文』代码，的确可以混淆黑产者的视线，大大增加了反编译的难度和时间成本。黑产者们完全懵逼了后续将会有更多的反欺诈技术与大家分享，请持续关注！

本文由零道书院原创



 关于“零道书院” 

我们是来自于中国平安集团旗下前海征信的fintech先锋团队。定期分享互联网金融的前沿技术，探讨热点专题。有料！有态度！欢迎关注。

    关注 SAS中文论坛