刘涛：大家下午好，我是来自盘古的刘涛。今天我给大家带来的议题是《使用Janus大规模挖掘滥用授权凭证的移动应用》。

首先我们先来看一下，我们在做安全分析的时候，我们作为一个白帽子或者一个灰帽子经常会遇到这样一个情况，就是说相比起大的安全公司，像安天或者是阿里，他们每天可能会收到成百上千，或者是上万的安全应用。但是对于我们一些白帽子、灰帽子来说，我们每天可能就是搜集到一两个或者是十多个有用的样本，我们会对它进行一些分析。我们对于这些单一的样本分析可能会发现一些很有趣的问题，比如说像前不久，最先在百度地图里面发现有一个漏洞，当这个分析人员，这个白帽子找到有这样一个漏洞的时候，由于他没有足够的样本资源，他仅仅只能是把这样一个漏洞提交到乌云，或者是分享到一些像天眼的平台上面去，把这个漏洞发布。但是我不能够去找到更多的应用，从而把它造成一个舆论的事件。所以在这里面我们可以看到，SVM的发明者弗拉基米尔·万普尼克说过这样一句话，很可能你拥有足够的信息来很好的解决一个感兴趣的特定问题，但是你没有足够的信息来解决一个一般性的问题，我们经常在分析当中就会有一个信息不完全的问题。针对这个我们在想，有没有可能我们去搭建这样一个平台，我们能够把大量的APK的样本搜集到，我们对它进行一些信息的提取，我们发现我们的安全人员能够到这个平台上来，对他感兴趣的问题去查看，看他所发现的问题有没有大规模的存在，从而能够发现更多的情况。

这就是我们搭建Janus的初衷。首先Janus会去搜集大量的原始数据，这些数据主要是APK，还有一些就是URL，比如一些常见的恶意的样本库里面的一些URL，或者是一些敏感的，比如说大的数据，像腾讯，或者是像阿里、支付宝这样一些URL的链接，还有一些其他的信息资源。这些主要会通过渠道牵掣，或者是爬虫，我们会搜集到这样一些原始数据。收集到这些数据之后，我们自己之前也开发过很多静态分析工具以及动态分析工具，我们就能够把搜集到的这些数据原数据，一些有用的信息可以提取出来。比如说像APK里面的字符串，或者是他的一些签名，或者是所有的一些布局文件，Layout或者是URL的信息。其次我们也可以通过动态的，刚才陆立新教授提到的，我们可以用沙箱在里面跑一段时间，我们可以把这个APK基本的一些行为数据也可以提取出来作为一个原数据进行分析。

当我们把这些数据存储之后，就可以构成一个数据平台，之后我们都可以在这个上面进行一些数据挖掘或者是构建一些检测规则，我们可以利用一些分析引擎，在里面做一些威胁情报的搜集或者是一些漏洞的预警，这个主要就是我们Janus的整体架构。

在Janus的周围可以看到还有很多云，除此之外我们还可以在Janus上面做一些其他的事情。比如说我们可以去进行机器学习，我们可能去发现一些以前不知道的一些潜在漏洞。还有就是我们可以进行一些相似性比对，我们经常会发现在Android市场上面经常会存在重打包的问题。一个开发者他开发出一个应用来之后，一旦放到市场上面的话，会有很多其他的人员，他们会把这个东西，把APK下载下来，Android也是开源的，加一个东西重新打包，放到市场上面去。对于用户来说，用户他并不Care这些东西。但是对于一个开发者，或者对于用户的信息安全来说，会产生一些问题。比如像恶意分析，安全评估，SDK使用，这些都可以在我们这个平台上面延伸出去，我们觉得这个应该是有很大的作为的。

这个主要是我们的界面，我们不仅可以在渠道上面去挖掘和拉取到一些数据，我们也希望一些安全分析人员可以到上面来提交你所感兴趣的应用，我们会帮你尽量去提取一些数据出来。比如说我们会提供一个在线交互分析的工具，这样的话，它集成了我们现在大部分的Android分析，包括反编辑。你可以看到，我们还可以对于某一个程序点可以去看它的一些交叉引用或者是调用的一些关系。其次我们也会内置一些我们以前总结的分析插件，当你把这个APK提取上来的时候，我们可以帮你去抓取到一些我们已知的问题。你可以去对这个问题进行深入的分析，去看这个问题是否会真正导致一些什么敏感的潜在漏洞。除了反编译的话，我们也提供了一些阿里代码的东西，使得你能够更直观的去分析这个程序的问题，因为毕竟这个反编译的话，可能会造成一些信息的缺失。

这一块是除了我们对于深层的交互分析之外，我们还会去提取一些基本信息。比如像这里面，我们会提取出一些MD5或者是其他的，我们会跟一些其他的安全厂商有一些合作，交叉的把一些情报关联起来。这是一个我们的规则匹配界面，除了交互分析之外，你也可以把一些你总结出来的安全规则，可以用一个简单的语法表示出来，我们可以在整个的信息平台上面收集，看你这个东西是否会出现。

之后就进入我们今天要讲的一个恶意凭证的泄漏。首先我们要讲到这个授权凭证的话，就需要提到一个开放平台，现在随着SNS的发展，很多的SNS都会推出一个开放平台，可以使得第三方应用方便的接入到用户资源上面去。很多开放平台的接入现在一般都是用2.0协议，当用户在移动应用里面发起一个操作请求之后，第三方应用会向开放平台申请一个授权。在经过用户确认授权之后，第三方应用就能到这个开放平台上面去拿取到用户的一些数据，或者是他自己的一些数据进行交互分析。

在这里面主要就是在第一步，他会通过一个授权凭证去认证这个第三方应用是否有一个权限去访问这些用户的数据。一个授权凭证主要是由两部分构成，一个就是Client ID，一个就是Client Secret，在向第三方平台申请认证服务的时候，由服务平台给开发者的，主要是用于认证这个开发者和所对应应用的主要手段。

当这个东西如果存在滥用的话会有一个什么样的问题呢？首先一个最直接的就是说，我可以去利用这个授权凭证，用这个客户端认证的方式，就可以用你的凭证修改这个应用的一些基本注册信息。比如说像我们之前发现Facebook上面，如果说我知道了你一个应用的授权凭证的话，我会直接去Facebook上面，包括上面的官网地址，或者应用的一些链接能够直接篡改掉，比如说可以设置成一个钓鱼链接或者是其他的东西。其次也可以以应用的身份跟后面的交互，比如我们提到在微信的公共号当中，如果有这个公共号的授权凭证的话，在这个公共号上面交互的时候可以切入进去，跟用户直接进行交互。还有我们之前在乌云上面也可以看到有一些报告，就是我可以去利用这个授权凭证，构建一些虚假的链接，然后帮用户点击或者是扫描的时候，经过篡改或者是中间人攻击的方式，就可以去获得用户的一些登录凭证，从而就可以直接以用户的身份登录上去窃取用户的一些信息。除此之外还有更多的一些情况，也是有待于后面继续发现。

这里看一个简单的例子。这是去年曝光在乌云上面的一个广东号码百事通“总机服务”微信号授权凭证的泄漏。这是公众号的界面，大家都可以到乌云上面去看这个东西。这个问题当时是怎么发现的呢？就是这个安全人员他通过这个公众号的抓包，就可以发现这个授权凭证直接是固化在通讯包里面的，就可以看到当初这个公共号的授权凭证是APP ID和Secret，攻击者和安全人员就可以上去，直接换取到一个授权凭证ACCESS-TOKEN。进入之后，就可以通过刚才那个调试页，能够获取到用户的OpenID，就是所有在这个公众号上面进行关注的用户的OpenID。当用户有交互的时候，我也可以跟用户发送一些信息，还有可以上传页面，还可以去更改这个公众号的一些菜单信息，这些都是在授权的范围内的。

在知道这些情况之后我们也去扫描了一些我们搜集到的APK，一些Android应用。我们可以发现，单就微信的授权凭证，我们实际上很多应用里面都有发现，它有些是固化在代码当中的，有些可能是固化在配置文件里面。针对于微信这个，我们可以发现提取一个特征，这个特征主要就是以WX开头，后面接16位的十六进制串，是一个MD5。这样的话我们就可以很简单的构建出这样一个匹配规则，有了这个匹配规则，因为我们之前已经搭建了Janus，我们已经对这些APK里面的字符串进行过搜集处理，那么我们就能够直接到Janus，就是之前你们看到的规则页面上面，可以建立这样一个检测规则。这个写得比较简单，就是只检测刚才所提到的这个匹配表达式。之后再选择和控制我们所有的应用，去进行一个扫描。

由于时间的关系，我们并没有去做一个全库的，我们只是选取了6万多个应用进行了微信的授权扫描。这是我们扫描出来的，包含有仪式授权，就是刚才那个匹配成功的一个应用的列表。我们可以点击打开，能看到有很多字符串上的匹配。为什么会有那么多字符串？就是因为这边可能是授权平台，还有很多，我毕竟是去扫一个符合MD5的十六进制串。这里面匹配出来有一些可能不是，我们可以导出来这样一些匹配成功的数据。之后我们会进行一个验证操作，验证操作的话就如同之前所提到的，就是我直接去到测试页上面构造一个URL请求，去看这样一个本来搜索到十六进制串，是否可能去获取到一个ACCESS—TOKEN，下一步就直接可以用这个ID拉取到用户的一些信息，还有可能会进一步的跟用户交互或者是其他操作。

这是我们扫描出来的一个简单的结果，就是我们扫了5万多个应用，大概有400多个是找到了这样一些凭证，最终是有21对收到。这个数据是今年我们做的数据，去年做的数据会比这个稍微好一点。主要一个原因就是我们后来发现，好像腾讯后来也更新了一个授权凭证的系统，使得以前能够正常访问的现在这些凭证有一些已经过期了，导致这个操作不能成功。

除了之前所说的凭证以外，也可以把获取授权凭证这样一个链接作为一个规则，我们可以去扫描出来列表之后，到交互平台里面去，依次的去分析，看这个东西，去找到这个授权凭证可能会在什么样的位置。这样的话，找到的东西可能会更为精确一点，也更为实际一些，就是这两种分析的模式。除此之外，我们也会去新浪微博、阿里云、Facebook这些去分析，看有没有这样的问题。

之后我们讲一下为什么会有这样一个授权凭证的问题，我们是扫了一下。首先第一个，开发人员可能会存在这样一个情况，就是说他用于去分享数据，获取数据或者存储数据。因为我们发现有很多应用，比如我去使用阿里云的服务，我会去在上面存储一些应用的基本数据信息，比如说像游戏里面，他可能会使用排行榜，他可能会要用阿里云的服务进行一些存储。还有一些比如说他可能会到新浪微博或者是微信的朋友圈进行分享的时候，他可能也会需要用到这样一个授权凭证。

不正确使用Auth2.0的协议。因为在Auth2.0里面认证是分为三个部分，客户端和服务器，大部分的认证操作都是在服务器上面完成的，对于有一些Android的应用，把这个服务器上面的认证工作直接放到了客户端上面去进行。这样的话，就势必使得这个授权凭证直接放到客户端上面了，这样的话就会造成一个凭证的泄漏。还有我们发现有一些开发人员，他可能在写测试代码的时候并没有把这个测试代码移除掉。这样的话，就会使得一些代码放在外部版当中，也会造成一些问题的泄漏。

剩下的就是一些建议，我们对于应用开发者，他应该去保护好自己的授权凭证，以防止有意者拿到授权凭证做一些其他事情。还有一个就是希望开发人员能够在保证最小的应用授权，这样即使你的授权凭证在不小心的情况下泄漏出去了，也不会造成过大的一些影响。后面我们可能第一是进一步扩展我们Janus的能力，另外就是对外进行开放。现在基本上我们Janus也做得差不多了，我们正在做下一步的调试。另外一个就是对外开放API的接口，使得开发人员能够调用我们这些接口，去挖掘到一些他们所感兴趣的信息。就像前面提到的，我们下一步可能会对于Android应用市场上面的重打包以及推广类的App，像一些黑色的App，我们会进行一个挖掘分析，到时候可能会出一份报告。

我今天讲的就是这些内容，不知道大家有没有想要问的。

 

提问：我想的可能不太对，我请教一下。我看到你讲的过程当中直接就是ACCESS-TOKEN了，是用的什么模式？

 

刘涛：其实这里面检测主要是针对第四个模式，就是客户端认证的模式。

 

提问：最简单的客户端认证的模式？

 

刘涛：不是最简单的客户端认证的模式。

 

提问：2.0里面说了一下，最后的模式是有一定的安全隐患的。

 

刘涛：是的，但是对于一二三四种模式其实都是使用到了一个认证的方式，都使用到了授权凭证。为什么我们只是检测了第四种模式？因为我们在做定量分析的时候，其实并没有用户的参与加入进来。所以说我们在搜索授权凭证的时候，我们只是针对了最后一种模式，就是说在分析的时候会简化一些，在我们整个分析里面，但是并不是说这个授权凭证不会用到ER里面去。其实对于像很多这种开放平台的话，它都有授权凭证，有一些是一样的。比如说像之前你们可以看到微信的公众号里面的授权凭证，就是首先我能够进行第四步验证，就是直接是ACCESS-TOKEN，也可以用这个授权凭证在第一个正常的授权认证模式，让用户去发起一个登录认证，之后再去拿到一个临时的OID，我再去数据服务器上面拉取到用户实际的登录ACCESS-TOKEN。这是在不同的应用场景里面，但是都会用到这个授权凭证。

 

提问：在你们实际测试的过程中，是不是说大部分产品就没有定时的刷新ACCESS-TOKEN过程呢？

 

刘涛：这个并不在我们这次分析当中，就是我们在应用当中挖掘看看是否有授权凭证的存在，而不是看整个登录Auth2.0的使用过程当中是否是安全的，这是两个问题。你说的这个东西，我们也可以写另外一个检测规则去扫描，这些都可以在Janus上面完成。

 

提问：我想问一下你们在扫描这些授权凭证过程中影响最大的，影响用户最多的是哪个？

 

刘涛：这个数据我没有带过来，要回去稍微看一下这个东西。你提到用户最多，不知道你要通过哪个，是通过下载量去分析，还是说去通过在线用户度去分析。

 

提问：因为你用那个授权凭证，就是可以看到用户的信息。你拿到那个开发者的数据，你可以访问吗？

 

刘涛：你说像刚才那个微信公众号上面，我是可以拿取到用户列表的。这个我们没有去做过统计，因为我们仅仅只是去单独验证，因为是自动化的，我们只是说去看到我们可以拿到一个OID，我们就认为好，这个东西就过了。但是其实我们后面也手动分析过，我们从中挑了一个去看过。我们搜集到有一些，是一个游戏的公众号，我记不起是什么名字了，大概是有几千个用户关注了这个，但是我们只是抽取了其中几个，可能有一些其他的，有些可能就只有几百个，有些有上千个，但是这些数据你现在向我要的话，我给不了你，抱歉。

 

提问：这些开放平台大部分是可读的吗？还是可写的？可以修改用户的数据吗？

 

刘涛：你要修改用户的数据的话，这个好像我没有怎么去关注过，但是我可以去修改这个应用的数据。因为毕竟你要修改用户的数据的话，就像刚才那位女士提到的这个问题，就是说我要修改用户的数据的话，我一般都要通过第一步认证，就是必须都要有用户的登录参与，就是说要有用户的确认授权的话，他才可以去连接到用户的数据。拿到授权凭证的话，主要修改都以应用的身份去改一些东西。所以说改的大部分都是应用的一些相关的东西，但是我可以通过应用的东西去影响到用户。

 

提问：我想问一下，咱们Janus在分析我们APK数据的时候，如果遇到那种加固的应用我们一般是怎么处理？

 

刘涛：可能刚才我没有提到，我们现在也已经对一些常见的一些加固的进行了一个脱壳的处理，但是就是说现在还不是对所有的加固都能进行这样一个操作，但是我们现在正在研究怎么样更通用的把一个应用的加固去掉，现在有一部分是可以把壳脱掉的。

 

提问：你说的这个脱壳是完整的脱下来还是静态的，就是只是还原一步？加密过之后不是一个完整的，很多代码是抽掉的，就是只有在运行的时候。

 

刘涛：运行的时候动态注入出去是吗？

 

提问：对这一部分代码进行保护的时候，我们在提取这一部分代码数据的时候有没有一些方案？

 

刘涛：现在我们还正在研究当中，但是我现在只能告诉你，就是说一部分的加固我们是可以进行脱壳处理的，另外还有一些，我们也正在有一定的解决方案，还有一些是在研究进一步的解决方案，并不是所有壳都能脱掉的，这倒是肯定的。在Janus系统里面，我们也是有提取的，我们也是有处理的，只是说可能有一些并不会还原到Java代码上面去。

 

提问：静态分析方面有吗？

 

刘涛：有，刚才你看到的交互分析，很多数据其实都是通过静态分析获取到的。

 

提问：您提到开放问题，有没有可能以后开放给其他的企业或者是个人用户？

 

刘涛：这些都会的，我们对于普通的安全人员，比如像白帽子我们有这样的用户接口，还有对于企业的话，我们也有相应的用户接口。

 

提问：我看您进的过程当中都是用Http的，是直接就没有Https，直接在网上抓包得到的数据吗？

 

刘涛：刚才说的抓包的话，其实是当初去年在乌云上面曝光的广州号码百事通里面，当时是通过抓包获得的这个ACCESS-TOKEN，后来这个Janus我们是通过直接静态分析得到的，并没有存在抓包的。但是针对你ACCPS，我们在动态获取当中，我们是对于这个做过一定的处理得，ACCPS我们也可以抓取到里面的数据的。

 

提问：你是说把包解下来？

 

刘涛：把包解下来，可以拿到一些数据。现在根据我团队里面的成员他反馈给我的信息，好像有能够解决一部分，但是不是全部的。