说到移动安全，可能大家比较陌生，因为这方面的研究是在最近几年才逐渐火起来的。那么什么是移动安全呢？首先，我们知道，移动安全无非就是ios平台和安卓平台上的一些安全性的问题，包括平台系统系统本身的一些问题和应用层面上的问题。当然在客户端和服务端在进行交互的时候还需要涉及一些通信协议，主要是http及https协议，当然还有一些其他的协议，比如websocket等等。这些协议本身的缺陷我们就不做过多的关注了，我们需要关注的是数据包在传输的过程中是否有进行必要的加密，服务端是否有对用户的操作权限进行控制，服务端的一些业务逻辑处理是否存在缺陷等等，这一方面的思路基本和web渗透差不多，但也有一些不同。
说到移动安全，当然少不了病毒和木马的攻击，常见的远控木马有droidjack、SpyNote等等，还有前一段时间如雨后春笋般涌现的锁机软件。
图1Droidjack
图2 锁机软件
攻击者可以利用Droidjack这类软件，生成木马程序，这种恶意的木马程序一般存在于一些三流的apk市场里。一般来说，攻击者会在这些apk中投放一些带有诱惑性的信息，比如免费观看某某美女视频，某某视频免广告客户端，某某爽图浏览器等等。攻击者将这些带有诱惑性信息的apk发布到网络上后，会在远程服务器上起一个服务端程序，一旦用户安装运行了这个恶意程序，黑客就可以在远程服务端对用户手机进行操控，监视用户的各种行为，进而窃取用户隐私信息。
归根结底，这些木马病毒层面的攻击，主要还是由于用户安全意识方面太薄弱，就不做为主要的讨论对象了，我们主要还是针对安卓的应用层面的安全性进行一些讨论。
那么我们该如何进行app漏洞的挖掘呢？首先，对于从web安全转战移动端漏洞挖掘的安全工作者而言，当然想挖一挖和自己所在领域比较相近的漏洞，而app的服务端基本和web安全领域的服务端差不多，只是web程序它的客户端更多的是浏览器，而移动应用它一般都有一个可以安装在移动设备上的app程序。所以，对于app服务端漏洞的挖掘上面，我们照样可以凭借以往的web经验，对其中的一些xss，ssrf，sql注入，任意文件读取等漏洞进行挖掘。
在对web应用进行漏洞进行挖掘时，我们可以通过在浏览器配置代理，来对我们web应用进行抓包分析，那么对移动端应用我们该怎么进行数据包分析呢？
其实，安卓应用的数据包分析也是要基于代理的，只是代理的配置相对复杂点罢了。我们在burptsuit或者fiddler中配置相应的代理后就可以使用他们进行数据包的截取和重放操作了。具体的步骤这里就不做详细阐述，网上都有教程，各位可自行查阅。
这里，对于xss，sql注入等一些经典的漏洞我就不做多说了，也没什么好说的，这里主要说下移动应用的越权漏洞。我们知道，web安全里，越权漏洞一般时由于服务端没有对用户请求进行权限校验，只凭用户id就执行了用户请求而导致的。那么正确认证方式是一种什么样的过程呢？用文字简要的描述就是:用户在登陆认证成功后，服务端会将标识用户权限写进cookie，然后返回给浏览器，浏览器保留下这个cookie；用户在之后发起的请求包中带上这个cookie，服务端对数据包中的cookie做校验，从而识别用户权限，执行相应权限的操作。
图3 cookie认证过程
当然，还有一种认证方式是session认证。Session认证和cookie认证都可以对用户的身份进行认证，那么，Session认证和cookie认证方式的区别什么呢？
简单来说，cookie存放在客户端，而session存放在服务端。从安全的角度来说的话，cookie相对不安全，而session相对安全些，因为cookie是存放在客户端的，攻击者可以在客户端获取cookie，如果用于标识用户身份的字段没有进行加密，容易被枚举，那么，攻击者就可以对cookie进行伪造，进而进行越权操作。而如果启用了session认证，那么客户端登入成功后获得的仅仅是对应的session的id。这个id是一串加密的字符串，是无法被遍历的。
那么它的认证过程又是什么样的呢？首先我们要知道，session认证也需要依赖于cookie的，用户在登陆成功后，服务端会将用户对应的session写进服务端的数据库中，session中带有用户的一些身份标识等信息，然后服务端会将这个session对应的id发送给客户端，所以客户端中的cookie的内容一般就只有一串sessionid=xxxxxx这样的字符串。用户在之后发起的请求中需要带上这个sessionid，服务端通过识别sessionid，然后查询数据库，获得相应的用户权限信息，然后再判断用户是否有权限执行响应的操作。
显然，session机制要相对安全一些，但安全的另一面也是需要付出代价的，相对cookie来说，session机制会更加消耗服务器的性能。
图4 Session认证过程
但是，在移动端，用户身份认证是不用cookie的，而是基于token进行识别。那么它又是一种什么样的认证方式呢？用简要的文字表述的话，它的认证过程一般是这样的，客户端登陆验证成功后，服务端会返回一个token字符串，这个字符串就是该用户的会话凭证，用户在此后与服务端进行交互时，都要带上这个token，这样才能对用户身份进行识别。
图5 Token认证过程
如果我们在分析数据包的时候，发现有请求是不带token的，那么这个数据包很有可能就存在越权漏洞，当然还得结合具体的场景进行分析，判断其是否对业务逻辑有影响。这是我们在移动端挖掘越权漏洞的一般姿势。但是，这种姿势未免太弱智，没什么门槛，基本是谁碰到都能挖。
针对越权漏洞，还有一种挖掘姿势，说起来，感觉也比较奇葩，这种越权漏洞的产生根本原因是由于认证策略本身的失误。记得在很久以前，对一款直播软件进行过一次协议的分析，发现其认证逻辑是这样的：用户登入校验成功后，服务端返回用户id，然后本地生产用户token，在此后的请求中，带上这个token作为用户身份的凭证。这个显然是有bug的，因为这个用户id是可以遍历的，而token的生成算法是在本地，所以攻击者只要获取到其他用户的id然后将本地的token生成算法抠出来，就可以自己计算token，然后伪造用户登陆了。
当然这种越权漏洞的挖掘难度还是比较大的，这要求漏洞挖掘者有比较深的逆向分析能力和编码能力。但是，作为开发者，绝不能因为这种难度而放松对应用安全方面的加固，特别是用户认证这种非常重要的功能模块，一定要做好安全方面的防护。
至于客户端的漏洞，主要是通过反编译工具对app客户端进行反编译，获得源码，然后结合一些经验及安全知识进行静态源码审计。常见的反编译工具有apkide，jeb，apktools等。下面给大家截个图，了解一下：
图6 改之理
图7 Jeb
当然我最喜欢用的还是android逆向助手，非常实用。
图8android逆向助手
结合jeb使用，基本可以满足日常逆向分析。
安卓应用平台主要分为native层和java层。Java层的话，我们可以使用以上工具进行分析，而native层的话，则要借助ida来进行分析。Ida是一款非常好用的反汇编工具，我们可以通过ida对apk的so文件进行反汇编，然后利用其f5功能，将arm汇编代码转为c++伪代码，对其中的逻辑算法进行分析。它还支持动态调试，可远程调试apk应用，我们可以利用ida动态调试，bypass掉一些so层中的校验，如二次打包校验，或者进行动态调试脱壳。
说到应用脱壳，这在apk分析过程中是很有必要的。在说脱壳之前，我们先来了解下什么是加壳。加壳即在应用运行之前优先获得程序的控制权，之后再把程序的控制权交给原来的程序。在安卓平台上的加壳实现是将原本的dex文件加密并隐藏起来，然后通过壳程序获取原本的dex文件再还原回去；还有一种是将函数指令抽取出来，在运行的时候，通过hook相应的类加载函数，将指令填充回去。
对于加壳后的应用，原程序的逻辑基本面目全非了，我们无法通过加壳后的程序来进行安全分析。所以，我们需要对应用进行脱壳处理。常见的自动化脱壳工具有drizzledump和dexhunter。Dexhunter很好用，但需要刷机，而且很多加密厂商都对其进行了检查，所以直接用是行不通的，需要做一些修改，bypass一些检测。至于详细的使用方式，大家可以自行上网寻找教程，这里就不做赘述了。如果工具不能用，那最后只好上ida了。
下面我们来详细看一下针对源码层面的安全检测需要注意的问题。
组件安全
首先是组件方面的安全问题，我们知道安卓应用有四大组件，分别是：activity，service，content provider，broadcast receiver。这些组件如果不是很有必要，应该将其导出属性即exported设置为false，即禁止导出。如果设置为true的话就会被外部应用调用，可能造成信息泄露，权限绕过等漏洞。另外，在使用Intent.getXXXExtra() 获取或处理数据的时候，如果没有做 try…catch进行异常处理的话，就可能出现拒绝服务漏洞，这些异常包括但不限于：空指针异常、类型转换异常、数组越界访问异常、类未定义异常、序列化反序列化异常。
像上面提到的组件安全，我们一般都是通过分析安卓的androidManifest.xml文件来判断的。AndroidManifest.xml是Android应用的入口文件，它描述了package中暴露的组件（activities, services, 等等），他们各自的实现类，各种能被处理的数据和启动位置。 除了能声明程序中的Activities, ContentProviders, Services, 和Intent Receivers,还能指定permissions和instrumentation（安全控制和测试）。通过分析这个manifest.xml文件，我们还可以发现例如应用数据备份和应用可调式这些漏洞。当然这些漏洞一般属于比较低危的漏洞，即对程序的业务逻辑不会造成太大的影响。而且应用可调式这个漏洞，其实即使设置了debuggable禁止攻击者调试该应用，也不能够阻止攻击者对应用进行调试，因为开发者只能控制应用本身不受调试，但控制不了用户的系统。攻击者只要设置下内存中的一个属性即可对系统中的所有应用进行调试，无论应用是否设置可被调试。但，此处还是有必要做下这个禁止调试的设置的，因为并不是所有的逆向分析者都知道能够绕过这个设置的。
webview安全问题
要说安卓客户端应用中比较严重的漏洞，那肯定是webview方面的漏洞了。现在很多App里都内置了Web网页，比如说很多电商平台，淘宝、京东、聚划算等等，如下图：
图9 webview展示图
其实这些都是android中的一个组件webview实现的。WebView是一个基于webkit引擎、展现web页面的控件，它的作用是显示和渲染web页面，直接使用html文件作布局，与javascript交互调用。Webview可以单独使用，也可以结合其他子类一起使用。Webview最常用的子类有WebSettings类、WebViewClient类、WebChromeClient类。这里就不做过多介绍了，如果对安卓编程感兴趣的，可以百度查找更多资料。
Webview这个组件可谓是一个两面刀，一方面，它的出现可以减轻客户端开发的负担，将程序的主要逻辑放到服务端上进行实现，本地只要使用webview加载相应的网页即可，但如果配置不恰当，就可能存在远程命令执行漏洞。相关的cve有cve-2012-6636，cve-2014-1939，cve-2014-7224。
cve-2012-6636这个漏洞是源于程序没有正确限制使用WebView.addJavascriptInterface方法。远程攻击者可通过使用Java Reflection API 利用该漏洞执行任意Java 对象的方法。
cve-2014-1939 这个漏洞是由于java/android/webkit/BrowserFrame.java 使用 addJavascriptInterface API 并创建了SearchBoxImpl类的对象，攻击者可通过访问searchBoxJavaBridge_ 接口利用该 漏洞执行任意Java代码。
cve-2014-7224 攻击者主要是利用了accessibility和accessibilityTraversal 这两个 Java Bridge来执行远程攻击代码。
Webview远程命令执行的产生还需要依赖java的反射机制。Webview 中的addJavascriptInterface方法可以往 WebView里注入了一个 Java Object, 而这个Jave Object 的方法可以被Javascript 访问。之所以提供 addJavascriptInterface， 是为了WebView中的Javascript可以和本地的 App 通讯。这确实是一个很强大的功能，这么做的好处在于本地App逻辑不变的情况下，不需要升级App 就可以对程序进行更新，修改相应的 Web页面就可以了。但是在Android 的早期版本并没有对可以访问的方法做限制，利用 Java 的反射机制，可以调用任意对象的任意方法，这就是WebView 漏洞 的根本成因。
apk更新包攻击 (中间人攻击)
上面提及的几个漏洞是安卓应用中比较常见也是影响比较大的漏洞，还有一些漏洞相对影响比较轻，但如果利用得当它的危害还是比较严重的。比如中间人攻击，它需要攻击者和受害者处于同一个局域网下，受害者的流量受到攻击者的控制。中间人攻击能干什么？弹个xss吗？获取用户 cookie？当然这里显然获取用户cookie没有用，应该是token 信息。在移动端攻击中，中间人攻击利用得当甚至可以导致远程命令执行。比如控制应用更新时下载的更新包，将其替换为恶意的攻击数据包，应用没有对更新包做必要的签名校验就执行了这个被攻击者改造后的返回包中的更新程序，这就可能导致恶意程序程序被执行。
对于客户端的漏洞检测，目前没有什么好的扫描引擎。前一段时间调研了下某数字公司，某梆，某加密的apk安全扫描工具，效果一般，基本差不多，都是基于反编译后的源码进行的简单漏洞验证。那么我们是否也可以自己写一个自动化检测工具呢？我此前也自己写了一个 apk自动化漏扫工具。
下面我来讲一下我的实现思路，首先我们知道，我们主要的分析对象是AndroidManifest.xml和dex 文件，但这两个都是编译后的二进制文件，我们需要将他们反编译出来。反编译 AndroidManifest.xml需要用到的工具是AXMLPrinter.jar，而反编译 dex文件需要用到的文件是 baksmali.jar。其实这两个jar包也是一些逆向工具常用的 jar包。我们来看下 android逆向助手这款反编译工具的程序目录：
图10 安卓逆向助手程序目录
这个名叫android逆向助手的逆向工具主要就是用了这两个工具实现对AndroidManifest 和 dex文件进行反编译的。
我们的自动化漏扫工具中只要编写相应的逻辑，调用这两个工具将AndroidManifest和dex 文件反编译出来后，我们就可以通过匹配一些漏洞特征，对漏洞进行检测了。
下面是项目目录结构的简要介绍：
图11 Apk漏洞扫描项目目录及简介
首先我们需要应用的包名，然后对application的一些设置进行检测，如是否允许备份，是否可调式等；然后获得acvitiy ， service，content provider，broadcast receiver 这四个组件的一些配置信息，判断其是否可导出；然后获取应用申请的权限，判断其是否过于敏感；获取应用自身创建的权限，判断下它是否做好了权限限制。
接下来对反编译后的smali文件进行漏洞特征检测。这主要是依赖与我们事先收集好的漏洞特征。这里我把漏洞特征写到了一个xml 文件中，在启动漏洞扫描的时候，加载到内存中，供程序调用。我们可以自定义这些漏洞特征，让我们的程序可以扫描到更多的漏洞。目前漏洞特征的定义支持字符串和正则形式。这个项目目前还在维护，不过基本功能都已经实现，可以满足日常的扫描检测，只要稍微对扫描结果进行一些排误即可。
1、任意文件读写漏洞
2、密钥硬编码漏洞
3、强制类型转换本地拒绝服务漏洞
4、系统组件本地拒绝服务漏洞
5、Intent Schema URL漏洞
6、Content Provider组件本地SQL 注入漏洞
7、代码动态加载安全检测
8、证书弱校验
9、主机名弱校验
10、HTTPS敏感数据劫持漏洞
11、Hash算法不安全
12、AES弱加密
13、Locat泄露隐私信息
14、日志泄漏风险
15、PendingIntent误用风险
16、Intent隐式调用
17、数据库文件任意读写
18、WebView系统隐藏接口漏洞检测
19、WebView组件远程代码执行漏洞检测
20、WebView忽略SSL证书错误检测
21、WebView明文存储密码
22、SharedPreferences任意读写
23、任意文件读写
24、随机数使用不安全
25、组件权限检查
26、应用是否可调式检查
27、应用权限检查
28、应用自定义权限检查
30、应用备份漏洞检查
1、将需要扫描的apk文件放到workspace/apk 目录下
2、点击AndroidCodeCheck.exe或执行python AndroidCodeCheck.py 即可执行漏洞扫描
报告输出路径在report下
1）txt格式
算是程序的运行日志吧，也可以作为扫描结果参考。
2）html格式
html格式的报告有目录，点击目录中的漏洞名称即可跳转到相应的漏洞类型说明。在类型说明处可点击返回目录返回到漏洞目录列表，方便漏洞审阅。
最后给一个漏洞扫描的报告截图，有点简陋，后期会逐步完善。
图12 报告目录首页
图13 漏洞详情
Apk静态源码漏扫工具项目地址：
https://github.com/zsdlove/ApkVulCheck
以上是如何分析APK安全及自动化审计的详细内容。更多信息请关注PHP中文网其他相关文章！
