感谢您的反馈！
阿里聚安全
漏洞案例
更新时间：2016/09/10
访问次数：17324
某视频客户端存在高危漏洞导致低版本远程代码执行
漏洞概要
漏洞作者： Moonight
提交时间： 2015-09-06 11:02
公开时间： 2015-12-05 17:16
漏洞类型： 远程代码执行
厂商定级： 高
漏洞详情
这个漏洞的最终的情况是在非root的设备上，我发送一个intent，这个可以是任意应用，就可以控制整个客户端，包括获取任意机密数据、执行相应逻辑等。
1.该客户端存在导出组件com.xxx.gamecenter.GameWebViewActivity；
2.该组件会接收外部攻击者可控制的intent的extra参数url；
3.我将url设置为自己搭建的html，这个html是可以被加载执行的
4.客户端的webview采用了addjavascriptinterface导出了gamecenter这个变量，可以利用该变量反射调用shell去远程执行代码
漏洞证明：
可以看到加载我可以控制的攻击url后，payload被执行了，执行了我示例演示的ls －l命令并输出了出来，当然也可以使用任意指令，由于是在应用进程内做的事情，所以我也可以在非root下获取应用所有敏感数据或植入加载木马等。
修复方案：
-
不要导出com.xxx.gamecenter.GameWebViewActivity；
-
尽量避免使用，API 17中用@JavascriptInterface 代替addjavascriptInterface；
-
移除系统webkit内置的危险接口searchBoxJavaBridge_,accessibility,accessibilityTraversal
某网购安卓应用拒绝服务打包
漏洞概要
漏洞作者： 小手冰凉
提交时间： 2015-06-09 15:47
公开时间： 2015-09-07 16:28
漏洞类型： 拒绝服务
厂商定级： 中
漏洞来源： http://www.wooyun.org
漏洞详情
安卓端的拒绝服务一般有几个原因，一个是未验证Intent.getXXOOExtra方法造成的，还有是打破程序执行顺序的页面启动导致某些变亮未初始化，还有就是一些程序测试的接口在发布版本中存在，等等。
第一处
Activity:com.xxx.mobile.paysdk.ui.CashierPrepareActivity
测试命令
这个界面从名字看应该是测试用的，分析代码发现似乎是测试支付的，其中发生了如下调用关系。
最后的函数b有如下未验证代码导致程序崩溃
第二处
Activity:com.xxx.upomp.bypay.activity.SplashActivity
测试命令
目测这个界面应该属于第三方SDK，在问题出在初始化布局文件上，应该是引入不完整，缺少布局文件
第三处
receiver:com.xxx.mobile.ebuy.appstore.app.ui.PackageReceive
测试命令
这里直接使用了未验证的getDataString方法
第四处
Activity:com.xxx.dl.ebuy.dynamicload.XxxDLProxyActivity
测试命令
启动时发生如下调用
code区域
后面这个onCreate中使用了未验证方法，导致程序崩溃
第五处
Activity:com.xxx.dl.ebuy.dynamicload.XxxDLProxySingleTaskActivity
测试命令
这里问题产生的根源跟上面一样，都是调用了DLProxyImpl.onCreate()这个方法。
修复方案：
请严格校验输入参数，注意空值判定和类型转换判断，防止由于异常输入导致的应用崩溃。
某商品交易app信息泄露漏洞
漏洞概要
漏洞作者： ali
提交时间： 2015-06-10 11:10
公开时间： 2015-09-08 17:56
漏洞类型： 用户敏感数据泄漏
厂商定级： 低
漏洞来源： http://www.wooyun.org
漏洞详情
com.xxx.android.action.WebViewActivity对外导出：
接收任意url并进行加载
未对file域进行处理，会导致file域同源策略绕过漏洞，可导致cookie等敏感信息泄露。
修复方案
1、 不要将不必要组件导出；
2、如需导出，禁止使用File协议；
3、如需使用File协议，禁止js执行：setJavaScriptEnabled（False)。
两分钟窃取身边女神帐号
笔者在使用自己编写的Drozer模块对国内流行的安卓手机应用进行自动化扫描后发现有大量涉及用户财产和隐私的流行安卓应用存在Android AllowBackup漏洞，已测试成功受到漏洞影响的业务包括：论坛、网盘、电商、旅游客户端。
漏洞案例
先来看一个情景案例，某IT男一直暗恋部门某女神，一天女神手机太卡了找IT男帮助清理手机空间，IT男高兴地答应女神两分钟搞定，屁颠屁颠的跑到自己电脑旁边连上手机，女神在一边呆呆的看着IT男敲了几行代码然后在手机上点了几下，最后果然两分钟不到就搞定了，在女神谢着离开后，IT男露出了WS的笑容。
没错，他成功了盗到了女神的帐号，终于不用问同事女神的帐号是多少了~当然这不是结局，一天晚上睡觉时，他看了女神的私信后心突然碎了。
到底发生了什么，这背后有啥不可告人的秘密？且看本文详细分析。
漏洞背景
在谷歌2010年发布Android 2.2 Froyo (冻酸奶)系统中，谷歌引入一个了系统备份的功能，允许用户备份系统应用和第三方应用的apk安装包和应用数据，以便在刷机或者数据丢失后恢复应用。第三方应用开发者需要在应用的AndroidManifest.xml文件中配置allowBackup标志(默认为true)来设置应用数据是否能被备份或恢复。
当这个标志被设置为true时应用程序数据可以在手机未获取ROOT的情况下通过adb调试工具来备份和恢复，这就允许恶意攻击者在接触用户手机的情况下在短时间内启动手机USB调试功能来窃取那些能够受到AllowBackup漏洞影响的应用的数据，造成用户隐私泄露甚至财产损失。
使用反编绎工具JEB查看客户端manifest配置：
在之前的案例正是因为安卓客户端(最新版)AndroidManifest.xml并没有配置android:allowBackup=“false”，导致女神手机中的客户端数据可以在短时间内通过ADB调试备份到电脑中最后恢复到IT男手机，然后IT男以后每天就可以用女神的帐号看女神发了啥私信内容。
当然可利用的场景当然不止于此，想想，如果存在漏洞的是团购应用呢（看看有啥团购券我先来用吧），当然还有你的网盘应用（说不定可以看女神的私密照~），哦，对了连通讯录，社交和理财应用也不能放过（女神们还敢把手机给IT男清理不）。
检测方法
（1）手工检测
测试环境：
1.Windows 7，ADB调试工具
2.物理接触目标手机1，连接手机1到PC端
3.手机1和手机2均未被ROOT，开启USB调试
4.不用安装其它应用，不启动被测试的应用
测试流程：
1.连接安装开启USB调试手机1 到PC端
2.在PC自动（也可以提前）安装好手机驱动后
3.启动命令行界面输入以下命令：
4.点击手机1确认备份界面的“备份我的数据”
5.等待备份完成，至此客户端数据成功备份为com.sina.xxx.ab文件
6.断开手机1的连接，可以把手机还给女神啦
7.连接手机2 ，在命令行界面下输入以下命令：
8.点击手机2确认恢复界面的“恢复我的数据”
9.等待恢复完成
10.打开手机2中新安装的客户端，测试可正常登录手机1中帐号执行各种操作，且长期有效。
（2）在线检测
建议普通用户和开发者上传应用安装包进行在线检测。
1.阿里聚安全检测结果（ http://jaq.alibaba.com/ ）
2.腾讯金刚审计系统检测结果（ http://service.security.tencent.com/kingkong ）
3.360捉虫猎手检测结果（ http://appscan.360.cn/ ）
影响范围
目前测试了手上一台安装有Android 4.1.1系统的魅族MX2手机和安装有Android 4.4.2系统的魅族MX4手机均测试成功，理论上影响Android 2.2-Android 4.4系统中存在风险的应用。
建议评级：
尽管此漏洞的利用条件较高，需要物理接触，但此漏洞对涉及用户财产与隐私类的APP来说杀伤力较大，建议厂商视情况修复。
1.金融类APP 高危
2.支付类APP 高危
3.团购类APP 中危
4.社交类APP 中危
5.网盘类APP 中危
6.其它类APP 低危/无影响
修复方案
开发者如要避免应用数据泄露的风险，应当在设置AndroidManifest.xml文件中配置android:allowBackup=“false”，此时应用程序数据无法被备份和恢复。或者在应用启动时检测手机硬件和网络环境是否改变，如果存在异常则强制退出或重新登录。
编写Drozer模块实现漏洞自动化扫描
Drozer是MWR InfoSecurity公司开发的一款安卓应用安全评估框架，其社区版开源在Github上（ https://github.com/mwrlabs/drozer ）。对于从事安卓应用漏洞测试的安全研究者们来说，他们可以使用drozer提供的框架自己编写模块(Module)方便对的安卓应用进行漏洞检测与利用。
以下是作者编写一个Drozer Module，用于自动化批量检测手机中的哪些应用存在AllowBackup风险。
Python
运行截图：
注意事项：
此drozer module检测原理是匹配应用manifest文件中是否配置了allowBackup=“false”来判断应用数据是否可备份和恢复，实际测试会发现一部分应用能成功备份和恢复但就是无法登录（比如手机淘宝和京东客户端），这说明厂商已经考虑到此设置可能带来的安全风险，并做出了相应限制，此类应用是安全的。
编写Python脚本实现自动攻击与利用
1.如上文所述，整个漏洞测试过程中需要输入不少命令，对于手速慢和不习惯敲命令的人来说还是略麻烦了点，所以我们可以编写Python脚本来实现自动化攻击和利用。
Python
运行截图：
2.应用备份生成的.ab文件其实是可以解包的，解包后的目录结构如下：
分别对应了AndroidManifest.xml，apk安装包，database目录，files目录，其它目录以及shared_prefs目录，我们可以通过解包来对窃取的应用数据进一步分析。
解包的python脚本如下：
更多利用方法
国外安全公司PALO ALTO早在2014年8月就发过研究报告称超过94%的流行应用存在此漏洞， 大牛Claud Xiao更是在去年Hitcon会议分享过与此有关的研究，如何让这个被很多人厂商视如鸡肋的漏洞有为的利用呢？这里提两点自己想到的，欢迎大家一起来交流。
（1）在APP漏洞里不安全的内部存储绝对是十分常见的漏洞，比如密码明文储存。笔者曾在测试某金融类APP时发现该APP在应用内部(/data/data/com.xx.xx/shared_prefs/)存储了明文的手势密码(如下图中的lock.xml)，正常情况下如果用户手机是未ROOT的，就算明文存储也没法获取到，漏洞影响相对较小，而继而我发现该理财APP同时存在allowbackup漏洞，也就是说我可以先将该应用数据备份到另一台已经获取ROOT手机，然后我不仅获得了用户帐号登录权限，连手势密码我都可以直接修改成任意（服务器端没做验证）或者相同（服务器端有验证）。还有一种情况是应用数据库中(/data/data/com.xx.xx/database/)直接存储了用户的登录帐号和密码那相当于直接利用allowbackup盗得了用户帐户密码。
（2）LastPass(一个用户密码管理工具）曾经被发现存在通过备份到其它手机来清除手势密码来登录获取用户储存在LastPass上的所有密码的漏洞（CVE-2013-5113 and CVE-2013-5114）。发散一下思维，储存用户其它密码的还有哪些应用？浏览器！习惯用浏览器记住密码的用户，若浏览器存在该漏洞，就会导致信息泄露。
（3）将恶意软件内置到外观类似充电器的微型PC装置中，用户一连充电器自动备份所有应用数据。（感谢DragonEgg提出）
参考资料：
-
http://researchcenter.paloaltonetworks.com/2014/08/insecure-internal-storage-android/
-
http://developer.android.com/reference/android/R.attr.html#allowBackup
-
http://blog.c22.cc/2013/08/01/bsideslv-android-backup-unpacker-release/
-
http://nelenkov.blogspot.fi/2012/06/unpacking-android-backups.html
某租车APP客户端设计缺陷导致的一系列安全问题
漏洞概要
漏洞作者： feng
提交时间： 2015-04-10 13:45
公开时间： 2015-07-09 15:00
漏洞类型： 设计错误/逻辑缺陷
厂商定级： 高
漏洞来源： http://www.wooyun.org
漏洞详情
首先先列举一下安卓客户端的一些问题：
1、allowBackup=“true”；
2、代码未做混淆；
3、未做重打包防护；
4、使用AES对称加密算法，但秘钥硬编码
漏洞证明：
下面将一步一步讲解如何解密该租车安卓APP客户端请求数据从而进行攻击。
首先，通过burp代理app的数据，抓包如下：
可见请求的关键数据被加密了，我们只有找到加密算法并解密才能进行进一步的安全测试。
一、算法逆向分析：
使用JEB或者dex2jar逆向客户端代码，JEB的效果更好一点，本文使用JEB。
从上图可以看出，此APP并未对代码做混淆处理，我们可以很容易地通过名称猜想ActivityLogin为登陆界面的代码实现，通过查看其代码也进一步证实了我们的猜想。分析得出处理逻辑主要在onLogin()方法里面。在此方法里面，声明了一个LoginOperate对象，进一步分析得出，LoginOperate继承自BaseOperate 。
在BaseOperate 的initUrl()方法里面，我们找到了请求数据的拼接
看，里面有“&q=”是不是跟我们第一步抓包的请求参数是一致的。
继续跟进initJsonUrl()方法，
看到其返回了aes.onEncrypt方法加密后的数据。
继续跟进aes.onEncrypt
跟进encrypt（）
很明显看出了其使用了AES加密算法，且秘钥硬编码为key = “xxxcar123123”;
那么我们现在就理出了请求数据的装载过程
原始数据-》AES加密-》base64编码-》URL编码
数据还原过程相反，这样我们就可以对自己实现请求数据，同时解密返回数据了。实现过程只要把逆向代码中相关的类抠出来放到自己的代码里就好了。
二、重打包客户端：
通过上面的分析，可以看出BaseOperate类是处理数据请求的基类，可以通过在其中添加打印代码的方式，来直接将加密前的数据打印到日志中，这样方便程序的分析。
在以下代码中看到，只要XXConfig.IS_DEBUG为true，即可打印原始json数据。
使用APP改之理打开apk文件，找到对应的smali文件，将其改为true，重新打包，安装
这样我们使用DDMS就能在日志中看到请求的原始数据了，
三、安全测试
当我们可以构造请求数据时，就可以开始安全测试了。
1、 越权访问
当访问客户端的自驾订单，订单详情时，发现请求数据为：{“id”:“11468060”}\
那我们构造{“id”:“11468061”}的请求：
其中uid设置为你自己的uid即可，可以成功看到其他人的订单
修复方案：
1、建议通过 /dev/urandom或者/dev/random 获取的熵值来初始化伪随机数生成器PRNG；
2、禁止把密钥写死在程序中；
3、使用聚安全提供的安全加密组件；
4、使用聚安全提供的加固方案。
影响数千万APP的安卓APP寄生兽漏洞
某手机安全研究团队vulpecker发现了一种新型的安卓app安全漏洞，市面上数以千万的app都受该漏洞影响。该漏洞一旦被攻击者利用，可以直接在用户手机中植入木马，盗取用户的短信、照片以及银行、支付宝等账号密码，vulpecker以“寄生兽”命名这个漏洞。
寄生兽是日本作家岩明均创作的漫画《寄生兽》中的一种怪物，初始形态是一种虫子，会钻进生物的体内并夺取大脑，因人类严重的环境污染而诞生，该漏洞的攻击方式类似寄生兽的感染，可以长期驻留在受害者的手机内，本文将详细分析这个漏洞，揭开漏洞的秘密。
一.关于app的缓存代码
安卓的应用程序apk文件是zip压缩格式的文件，apk文件中包含的classes.dex文件相当于app的可执行文件，当app运行后系统会对classes.dex进行优化，生成对应的odex格式的文件。
odex文件相当于app的可执行文件的缓存代码，一般安卓系统在第一次加载运行apk时会将系统生成odex文件存放于 /data/dalvik-cache 目录下。
如图
可以看到该目录下的文件只有system用户有写权限，只有在拥有system权限的情况下才能对odex文件进行写操作。
二.广泛流行的插件机制
由于安卓应用的升级都需要重新安装程序，频繁的升级给用户体验和开发都带来了不便，所以市面上的app都开始采用插件机制，利用插件机制可以做到无缝升级和扩展功能，app只需要引入相应的插件文件就可以做到功能添加或升级，无需再重新安装程序。
app插件机制的实现方式是把相关功能编写成单独的apk或jar文件，然后在程序运行时用 DexClassLoader 动态加载，进行反射调用。我们来看一下 DexClassLoder 的定义:
public DexClassLoader (String dexPath, String optimizedDirectory, String library Path, ClassLoader parent)
dexPath：是要加载的jar/apk的路径
optimizedDirectory：目标odex的路径
libraryPath：依赖的native library(so文件)路径
parent：父加载器
下面是常见的调用DexClassLoader的代码片段
如图drozer.apk插件在被调用后生成了drozer.dex缓存文件，注意dex这个文件是odex格式,且这个目录是app的私有目录。
三. 插件机制引入的攻击点
在2013年，国外的mwr实验室给出了一个利用中间人的方式劫持app升级插件的攻击案例，参考：
几年前，大部分采用插件机制的app，在载入插件前都没有对插件文件进行完整性校验，导致黑客可以通过中间人劫持的方式替换app的升级插件，在插件中嵌入恶意代码控制用户的app和手机。
现今，大部分采用插件机制的app都加强了安全性，如最早使用插件开发方式的微信等app，在下载使用插件前都会校验插件文件的签名，黑客已经无法通过中间人的方式替换插件攻击app。
四. 插件机制新的攻击点
近日，国外的nowsecure公司公布了三星输入法的一个漏洞，利用过程直接替换了系统app的odex缓存代码。参考：
https://www.nowsecure.com/blog/2015/06/16/remote-code-execution-as-system-user-on-samsung-phones/
三星输入法是拥有系统最高级别的 system 权限，可以直接替换任意app的缓存文件。那安卓app插件的缓存代码是否和APP主程序直接产生的缓存代码一样能被任意替换？
我们去android源码中验证了一下，通过DexClassLoader() 加载jar/apk文件，最终会通过native接口openDexFileNative() 进入到native层。
对应于android-4.2.2_r1/dalvik/vm/native/dalvik_system_DexFile.cpp中的Dalvik_dalvik_system_DexFile_openDexFileNative() 方法，在native层对几个参数做一系列校验，如果检测到第二个参数指定的odex文件存在，则会调用dvmOpenCachedDexFile() 直接打开，调用处的代码如下：
很明显，第3、4个参数对应的是优化前的classes.dex的时间戳和crc校验值。最终会调用:
dvmCheckOptHeaderAndDependencies(fd, true, modWhen, crc, expectVerify, expectOpt)
如果crc、modWhen参数正确，则返回该odex的文件句柄；若crc、modEWhen校验错误，则尝试删除错误的odex，并重建新的odex。所以，攻击者如果要注入目标odex，需要对修改后的odex文件的crc及modWhen做修改。
下面是一个修改后的odex文件实例，dex_old是修改前的odex文件，dex_new是修改后的dex文件，两个文件的md5不一样，但是crc及modWhen却是一样的，这样就可以绕过DexClassLoader的校验。
五. “寄生兽”漏洞的真正危害
安卓应用的代码缓存机制是程序在执行时优先加载运行缓存代码，而google却只对缓存代码做了可以伪造的弱校验，这明显是一个安全架构实现上的严重漏洞。
广大app开发者在使用插件机制开发app时可以对插件文件做完整性校验，而系统生成的缓存代码却无法做到有效保护，一旦攻击者将恶意代码注入到缓存代码中，开发者对app插件文件做的各种保护都将失效。这种攻击很难被发现，即使关机后重启，只要app一运行，恶意代码也会随之运行，同时安全软件对这一块的检查和防御也几乎为零。
六.现实中的“寄生兽”漏洞攻击案例
1）利用zip解压缩漏洞覆盖缓存代码
在某输入法漏洞的利用中，作者用到了安卓下的zip解压缩漏洞，这个漏洞是单独的一个漏洞，且由来以久，在google官方的文档中已经做了警告，存在问题的是ZipEntry.getName()方法，我们看一下google文档中对该函数的描述：
链接： http://developer.android.com/reference/java/util/zip/ZipEntry.html#getName()
可以看到google对该方法给出了一个安全提示，提示开发者如果该方法的返回值中包含有”../”跳转符，需要特别注意不要将文件写到了目标文件夹之外。如果不对”../”跳转符做过滤，就有可能遍历目录，在解压zip文件时以本app的权限覆盖任意文件。
下面是一个安卓zip解压缩的常用代码片段
如果没有对 zipEntry.getName进行检查，盲目解压创建文件，将会穿越目录建立文件，如图
我们检测后发现市面上几乎所有使用zip解压缩功能的app都存在漏洞，为“寄生兽”漏洞的攻击提供了便利，主要分为三类情况：
APP关联文件类
这类漏洞主要影响有皮肤功能的APP，如输入法，浏览器类APP .很多app在manifest中做了zip类文件的关联，如果注册的文件格式被点击，对应的app就会启动解压文件。下图是app注册文件关联的一个示例
这个app关联了一个ssf格式的文件，其实这个文件的格式是zip压缩格式，用户在手机中下载打开ssf文件时，就会启动对应的app自动解压文件，文件中包含的恶意代码可以覆盖该app的缓存代码。
APP自升级类
这类漏洞主要影响有自动升级下载zip类文件功能的app，在app下载文件过程中可以被中间人劫持攻击，我们发现地图类的app和sdk插件最容易收到攻击，app在下载解压资源文件的过程中被攻击
APP默认解压类
这类漏洞主要影响默认有解压缩zip文件功能的app，如浏览器直接下载zip文件打开后，app就被感染缓存代码。
2）利用adb backup覆盖缓存代码
如果开发者没有在manifest里指定allowBackup=”false” ，就可以在不需要root权限的情况下备份、恢复app私有目录下的数据。如果该app用到了插件机制，则对应的插件的odex文件也会被备份。攻击者可以先用adb backup备份用户数据，对备份下来的odex文件进行修改，然后用adb restore恢复回去，就可以替换掉正常的odex文件，造成代码劫持。
3）其他可能的APP数据读写
如果一个木马病毒利用root权限实施“寄生兽”漏洞攻击方式，将能实现隐蔽的apt木马攻击方式，长期潜伏在用户的手机类，安全软件很难发现app的缓存代码被感染了。
七. “寄生兽”漏洞的防护方案
“寄生兽”漏洞的核心有两点，一是google没有考虑odex的安全问题需要开发者自己做防护，另一个是要阻断漏洞的攻击入口和利用方式，这里我们给出一些防护建议缓解该漏洞的攻击。
1）对odex文件进行完整性校验
由于对odex一般是由系统(DexClassLoader)自动生成的，且odex与apk/jar是相对独立的，开发者事先无法知道odex文件的MD5等信息，所以很难通过MD5校验等手段保护odex的完整性；同时，系统的DexClassLoader函数只是校验了odex中的crc、modWhen字段，可以很轻易的被绕过。
所以，目前对odex的防护只能由app自身来做，可以在每次运行DexClassLoader之前，清除已经存在的odex；
另外，在odex第一次生成之后，存储odex文件的MD5值，以后每次调用DexClassLoader的时候都对odex文件进行MD5校验。
2）对可能的劫持odex的攻击入口漏洞进行修复
对zip解压缩的漏洞，只需要在调用zipEntry.getName()的时候，过滤返回值中的”../”跳转符。对于引用的第三方的zip库也需要注意，可以用上面的测试用例测试一下第三方库是否有zip解压缩的漏洞；调用DexClassLoader动态加载dex的时候，第二个参数不要指定在sdcard上；在manifest里指定allowBackup=”false”，防止应用数据备份覆盖。
某浏览器安卓客户端信息泄露
漏洞概要
提交时间： 2015-06-16 15:02
公开时间： 2015-09-14 18:28
漏洞类型： 敏感信息泄露
厂商定级： 低
漏洞来源： http://www.wooyun.org
漏洞详情
部分Logcat日志：
修复方案
避免使用System.out.print等标准输出打印日志或转存日志信息。
某新闻客户端远程命令执行附加详细利用分析
漏洞概要
漏洞作者： 小手冰凉
提交时间： 2015-06-08 11:08
公开时间： 2015-09-09 20:30
漏洞类型： 远程代码执行
厂商定级： 高
漏洞来源： http://www.wooyun.org
漏洞详情
0x01 命令执行
客户端编译的安卓目标版本过低导致命令执行漏洞。
客户端阅读普通新闻的时候打开的正好是webview，我们将地址指向poc结果如下。
0x02 接口过滤不严&新闻伪造
通常找app提供的接口都是去AndroidManifest.xml文件中找注册的接受类，然后去反编译分析源码，那样有时候反编译不出来，这里我们换个不同的思路。随便打开一个新闻，然后使用分享功能，把分享信息中的URL复制出来，在手机浏览器中打开，你会发现这个时候就会自动跳转到新闻客户端，这个过程其实就是手机浏览器根据网页上的提供的app的本地接口打开app，并且通常情况下都会传递一个数据过去，例如URL。这样也就以为这js中会暴露出这个app的提供的接口的使用方式。
使用这种方式我们发现了如下接口
在js中用上面这个地址就会直接跳转到app。其中的URL是一个该新闻客户端提供的接口地址（例子： http://api.iclient.xxx.com/ipadtestdoc?aid=99008381 ），返回的是一个json，其中包含这个新闻的所有信息。然后这个app就会按照这个json文件把新闻展示在页面上。整个过程完全没有验证URL或者是信息来源。可用于新闻伪造，中奖信息欺骗等。
建立两个网页URLA和URLB，在URLA中使用js跳转到comxxxnewsclient://call?type=doc&id=URLB。URLB中则返回一个虚假新闻的json，效果如图：
地址：http://192.168.1.34:28214/if/fakenewsjm.html
0x03 远程命令执行
返回 http://api.iclient.xxx.com/ipadtestdoc?aid=99008381 包含新闻信息的json 中，出现了html标签。这也就以为着这写信息非常有可能是展示在webview中的。首先的想法就是在json的title字段添加js语句，发现不能执行，百思不得其姐！后来突然想到既然能加载图片，那图片的事件呢？果断在之前的字段加上
发现弹窗果然如期出现了！这样就好办了，配合之前的命令执行漏洞，直接用onerror执行window.location来跳转到执行页面就行了。
用安卓浏览器打开 http://192.168.1.34:28214/if/ls_0.html 就会跳转到并执行命令。远程执行列sd卡目录并显示：
地址： http://192.168.1.34:28214/if/ls_0.html
然后跳转到app加载 http://192.168.1.34:28214/if/new.html的json 。
这个json中包含下一步跳转的js，最后成功打开 http://192.168.1.34:28214/if/ls_1.html 并执行命令显示：
修复方案：
通过显示调用removeJavascriptInterface移除3个隐藏的系统接口： ‘searchBoxJavaBridge_’,‘accessibilityTraversal’以及’accessibility’。
某浏览器IntentScheme处理
漏洞概要
漏洞作者： 瘦蛟舞
提交时间： 2014-08-26 11:46
公开时间： 2014-11-24 11:48
漏洞类型： 权限提升
厂商定级： 低
漏洞来源： http://www.wooyun.org
漏洞详情
IntentScheme未做过滤，可以植入恶意意图。
1.android all，浏览器拒绝服务
2.android 3.x-4.3，重置PIN码
3.android 4.2.2以下 结合其他app webview执行远程命令
poc为打开android 4.1的原生游览器
4.android all 卸载其他app
漏洞证明：
浏览器版本
修复方案：
如果使用了Intent.parseUri函数，获取的intent必须严格过滤，intent至少包含addCategory(“android.intent.category.BROWSABLE”)，setComponent(null)，setSelector(null)3个策略。
某SDK设计缺陷导致手机敏感信息泄露
漏洞概要
漏洞作者： 小荷才露尖尖角
提交时间： 2015-07-28 12:38
公开时间： 2015-10-27 17:24
漏洞类型： 设计错误/逻辑缺陷
厂商定级： 高
漏洞来源： http://www.wooyun.org
漏洞定位
检测发现手机经常有应用会打开7777端口，并且在任意地址监听，于是便一探究竟。
然而直接在apk逆向后的代码中搜索7777或其16进制表示0x1e61却一无所获。最后发现手机助手apk是在运行的时候动态加载的plugin-deploy.dex打开了该端口。根据线索，
发现com.xxx.frontia.FrontiaApplication类对安装包中的plugin.dex解密后动态加载。
安装应用，对应用目录下的plugin.dex进行分析，该文件实际是一个odex文件，需要按如下步骤转换为dex
code 区域
最后生成的out.dex就可以使用JEB打开了。
漏洞分析
简单搜索可发现out.dex打开了7777端口进行监听，会对发往该端口的HTTP请求进行响应，见 com.xxx.frontia.module.deeplink 下的各类及方法，如图所示。
也就是说，可以通过访问 http://IP:7777/command?callback=xyz&... 的形式本地或者远程获取手机的敏感信息、或者执行命令。
对应用而言，对应于上图左边红框中的类，实际支持的command包括LightApi或RuntimeApi类支持的一些命令。
上图右边位于com.xxx.frontia.module.deeplink.a中，反映了SDK可以支持的远程传入的命令以及对这个命令进行处理的类。使用SDK的应用可以根据情况进行配置，例如我们发现许多使用该SDK的应用还支持geolocation命令，可以通过访问 http://IP:7777/geo***?callback=xyz 的形式远程获取手机的地理位置信息。下面是另一个使用该SDK应用支持的命令。
与应用相比，增加command的还对HTTP请求的Referer进行了判断。
该SDK生成的Demo支持geolocation、getcuid和getapn三个命令。
至此，我们可以得出这样的结论，由于该SDK设计缺陷，导致使用该SDK的应用开放7777端口，本地或者远程攻击者至少可以通过该端口获取手机的地址位置、IMEI、APN等信息，进一步可以通过LightApi或者RuntimeApi执行命令（尚未验证）。由于不同应用对该SDK的配置和使用不同，支持的命令有所不同，危害的表现形式也不同。
漏洞证明
远程获取手机的IMEI；
远程获取手机的地理位置信息；
上述漏洞也可以本地在127.0.0.1利用，使得本不具备android.permission.READ_PHONE_STATE和android.permission.ACCESS_FINE_LOCATION权限的本地应用读取IMEI和地理位置信息。
利用手机的热点功能，在3G/4G内网内扫描，可以批量获取手机的IMEI和地理位置信息，发现许多主机都打开了7777端口。
扫描一个C段的结果
这样就可以用来追踪某些手机所处的地理位置（需要同时支持geolocation和getcuid接口）试验中也发现，许多知名不知名的应用均打开7777端口，而且只有一个实例进程运行。当把其中一个打开7777端口的应用卸载后，另外一个使用SDK的应用又会打开7777端口又会继续监听，漏洞的危害则取决于应用如何使用和配置SDK。
修复方案：
建议不要监听固定端口获取数据，如果要开启监听端口，端口每次都要随机生成。
逆向某钱包APP可找回任意用户密码
漏洞概要
漏洞类型： 设计缺陷/逻辑错误
厂商定级： 高
自评Rank： 20
漏洞状态： 厂商已经修复
漏洞来源： http://www.wooyun.org
漏洞详情
APP找回密码的验证码为四位数字，且无次数限制，但是数据包有签名校验（sign）。
将APP反编译，APP并未混淆。定位sign计算算法，大致算法为，参数通过genSignData进行拼接后，在与固定key拼接后计算md5值，这样就得到了sign值。
多处class中用到一下类似的计算方式：
拼接算法在 BaseHelper.class的genSignData中，计算md5算法在 Md5Algorithm.class的sign中。
找回密码接口如下：
脚本生成，对应验证码的sign值。用burpsuite爆破即可重置密码。
成功登录的截图：
修复方案
1、关键代码需要做混淆。
2、登录接口需在服务器端做尝试次数限制。
3、建议接入阿里聚安全应用加固产品。