IOS安全[转载]

IOS安全

转载自
http://blog.csdn.net/column/details/hackingios.html

iOS安全攻防（十八）：数据保护API
 
数据保护API

拿越狱检测来说，起初大家只需判断有无安装Cydia就好了，hackers们说好，那我就不安装Cydia也可以动手脚。开发者们又说，那你一定得用的上MobileSubstrate，bash，ssh吧，我去检测手机有没有安装这些工具。可是又有什么用呢？你判断什么我绕过去什么。

当class-dump大肆流行，函数符号都被暴露，开发者想尽办法藏起自己的敏感函数代码。hackers们也知道class-dump的死穴在哪里，于是新的检索办法油然而生。也就说，当一个防御手段成为流行，它就不会再是个让hackers大骂“真特么费劲”的防御手段了。比如之前介绍的一个小技巧：内存数据擦除  ，hackers知道开发者都去擦数据了，那我hook memset在你擦之前去读就好了。开发者说：我直接写硬盘上然后删除！hackers说：难道你没听说过文件恢复？

数据保护API

文件系统中的文件、keychain中的项，都是加密存储的。当用户解锁设备后，系统通过UDID密钥和用户设定的密码生成一个用于解密的密码密钥，存放在内存中，直到设备再次被锁，开发者可以通过Data Protection API 来设定文件系统中的文件、keychain中的项应该何时被解密。

1）文件保护

01./* 为filePath文件设置保护等级 */ 
02.NSDictionary *attributes = [NSDictionary dictionaryWithObject:NSFileProtectionComplete 
03.                                                       forKey:NSFileProtectionKey]; 
04.[[NSFileManager defaultManager] setAttributes:attributes 
05.                                 ofItemAtPath:filePath 
06.                                        error:nil]; 

01.//文件保护等级属性列表 
02.NSFileProtectionNone                                    //文件未受保护，随时可以访问 （Default） 
03.NSFileProtectionComplete                                //文件受到保护，而且只有在设备未被锁定时才可访问 
04.NSFileProtectionCompleteUntilFirstUserAuthentication    //文件收到保护，直到设备启动且用户第一次输入密码 
05.NSFileProtectionCompleteUnlessOpen                      //文件受到保护，而且只有在设备未被锁定时才可打开，不过即便在设备被锁定时，已经打开的文件还是可以继续使用和写入 

2）keychain项保护
01./* 设置keychain项保护等级 */ 
02.NSDictionary *query = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword, 
03.                        (__bridge id)kSecAttrGeneric:@"MyItem", 
04.                        (__bridge id)kSecAttrAccount:@"username", 
05.                        (__bridge id)kSecValueData:@"password", 
06.                        (__bridge id)kSecAttrService:[NSBundle mainBundle].bundleIdentifier, 
07.                        (__bridge id)kSecAttrLabel:@"", 
08.                        (__bridge id)kSecAttrDescription:@"", 
09.                        (__bridge id)kSecAttrAccessible:(__bridge id)kSecAttrAccessibleWhenUnlocked};   
10.     
11.OSStatus result = SecItemAdd((__bridge CFDictionaryRef)(query), NULL); 

01.//keychain项保护等级列表 
02.kSecAttrAccessibleWhenUnlocked                          //keychain项受到保护，只有在设备未被锁定时才可以访问 
03.kSecAttrAccessibleAfterFirstUnlock                      //keychain项受到保护，直到设备启动并且用户第一次输入密码 
04.kSecAttrAccessibleAlways                                //keychain未受保护，任何时候都可以访问 （Default） 
05.kSecAttrAccessibleWhenUnlockedThisDeviceOnly            //keychain项受到保护，只有在设备未被锁定时才可以访问，而且不可以转移到其他设备 
06.kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly        //keychain项受到保护，直到设备启动并且用户第一次输入密码，而且不可以转移到其他设备 
07.kSecAttrAccessibleAlwaysThisDeviceOnly                  //keychain未受保护，任何时候都可以访问，但是不能转移到其他设备 

应用实例
把一段信息infoStrng字符串写进文件，然后通过Data Protection API设置保护。

01.NSString *documentsPath =[NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject]; 
02.NSString *filePath = [documentsPath stringByAppendingPathComponent:@"DataProtect"]; 
03.[infoString writeToFile:filePath 
04.             atomically:YES  
05.               encoding:NSUTF8StringEncoding 
06.                  error:nil]; 
07.NSDictionary *attributes = [NSDictionary dictionaryWithObject:NSFileProtectionComplete 
08.                                                       forKey:NSFileProtectionKey]; 
09.[[NSFileManager defaultManager] setAttributes:attributes 
10.                                 ofItemAtPath:filePath 
11.                                        error:nil]; 

设备锁屏（带密码保护）后，即使是越狱机，在root权限下cat读取那个文件信息也会被拒绝。

iOS安全攻防（十九）：基于脚本实现动态库注入
 
基于脚本实现动态库注入

MobileSubstrate可以帮助我们加载自己的动态库。

还有别的攻击入口吗？

1）必须在应用程序启动之前，把dylib的环境变量配置好
2）dylib的位置必须能被应用程序放问到
3）最后再启动应用程序

走bash！

为了让特定功能的脚本被执行，我们可以把脚本改成应用程序二进制的名字伪装成应用程序，让系统调用启动。在脚本中，配置好dylib，然后再手动启动真的应用程序，假装什么也没发生。

将真的支付宝程序改名为oriPortal：

01.mv Portal oriPortal 

将待执行的脚本改名为支付宝：

01.mv Portal.sh Portal 

脚本代码：

01.#!/bin/bash 
02. 
03.#得到第一个参数 
04.C=$0 
05. 
06.#第一个参数是二进制的绝对路径 比如 : 
07.#/private/var/mobile/Applications/4763A8A5-2E1D-4DC2-8376-6CB7A8B98728/Portal.app/ 
08.#截取最后一个 / 之前的内容 
09.C=${C%/*} 
10. 
11.#库和二进制放在一起 
12.export DYLD_INSERT_LIBRARIES=${C:-.}/wq.dylib 
13.#执行原来APP $@ 别忘了把原来的参数保留 
14.exec "${C:-.}"/oriPortal "$@" 

失败了……
错误信息如下：

在打开某个加密信息时出了错误，大概猜一下应该是类似加密签名校验的步骤，但是我们无法去了解其中详细的操作到底是什么样的，那么就把原始的可执行文件环境全部给他造出来，因为检验文件属性肯定不会带着路径信息的。

备份一份Portal.app目录Portal_ori.app，修改脚本为：

01.#!/bin/bash 
02.C=$0 
03.C=${C%/*} 
04.export DYLD_INSERT_LIBRARIES=${C:-.}/wq.dylib 
05.exec "${C:-.}"/../Portal_ori.app/Portal "$@" 

运行支付宝app验证一下，
在iOS6上，成功加载了动态库wq.dylib
在iOS7上，失败了，错误信息如下：

应该是因为iOS7的沙盒机制升了级，

iOS安全攻防（二十）：越狱检测的攻与防

越狱检测的攻与防

在应用开发过程中，我们希望知道设备是否越狱，正以什么权限运行程序，好对应采取一些防御和安全提示措施。

iOS7相比之前版本的系统而言，升级了沙盒机制，封锁了几乎全部应用沙盒可以共享数据的入口。即使在越狱情况下，限制也非常多，大大增加了应用层攻击难度。比如，在iOS7之前，我们可以尝试往沙盒外写文件判断是否越狱，但iOS7越狱后也无该权限，还使用老方法检测会导致误判。

首先，你可以尝试使用NSFileManager判断设备是否安装了如下越狱常用工具：
/Applications/Cydia.app
/Library/MobileSubstrate/MobileSubstrate.dylib
/bin/bash
/usr/sbin/sshd
/etc/apt

但是不要写成BOOL开关方法，给攻击者直接锁定目标hook绕过的机会。

攻击者可能会改变这些工具的安装路径，躲过你的判断。

那么，你可以尝试打开cydia应用注册的URL scheme：

01.if([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"cydia://package/com.example.package"]]){ 
02.     NSLog(@"Device is jailbroken"); 
03.} 

但是不是所有的工具都会注册URL scheme，而且攻击者可以修改任何应用的URL scheme。

那么，你可以尝试读取下应用列表，看看有无权限获取：

01.if ([[NSFileManager defaultManager] fileExistsAtPath:@"/User/Applications/"]){ 
02.        NSLog(@"Device is jailbroken"); 
03.        NSArray *applist = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:@"/User/Applications/" 
04.                                                                               error:nil]; 
05.        NSLog(@"applist = %@",applist); 
06.} 

越了狱的设备是可以获取到的：

攻击者可能会hook NSFileManager 的方法，让你的想法不能如愿。

那么，你可以回避 NSFileManager，使用stat系列函数检测Cydia等工具：

01.#import <sys/stat.h> 
02. 
03.void checkCydia(void) 
04.{ 
05.    struct stat stat_info; 
06.    if (0 == stat("/Applications/Cydia.app", &stat_info)) { 
07.        NSLog(@"Device is jailbroken"); 
08.    } 
09.} 

攻击者可能会利用 Fishhook原理 hook了stat。

那么，你可以看看stat是不是出自系统库，有没有被攻击者换掉：

如果结果不是 /usr/lib/system/libsystem_kernel.dylib 的话，那就100%被攻击了。
如果 libsystem_kernel.dylib 都是被攻击者替换掉的……

那么，可能该检索一下自己的应用程序是否被链接了异常动态库。

列出所有已链接的动态库：

01.#import <mach-o/dyld.h> 
02. 
03.void checkDylibs(void) 
04.{ 
05.    uint32_t count = _dyld_image_count(); 
06.    for (uint32_t i = 0 ; i < count; ++i) { 
07.        NSString *name = [[NSString alloc]initWithUTF8String:_dyld_get_image_name(i)]; 
08.        NSLog(@"--%@", name); 
09.    } 
10.} 

通常情况下，会包含越狱机的输出结果会包含字符串： Library/MobileSubstrate/MobileSubstrate.dylib 。

攻击者可能会给MobileSubstrate改名，但是原理都是通过DYLD_INSERT_LIBRARIES注入动态库。

那么，你可以通过检测当前程序运行的环境变量：

01.void printEnv(void) 
02.{ 
03.    charchar *env = getenv("DYLD_INSERT_LIBRARIES"); 
04.    NSLog(@"%s", env); 
05.} 

未越狱设备返回结果是null，越狱设备就各有各的。

iOS安全攻防（二十一）：废除应用程序的ASLR特性

废除应用程序的ASLR特性

ASLR (Address Space Layout Randomization)，即地址空间随机布局。大部分主流的操作系统都已实现了ASLR，以防范对已知地址进行恶意攻击。iOS从4.3开始支持ASLR，Android从4.0也支持了ASLR机制。

ASLR的存在，给iOS系统越狱造成了很大的困难，某些不完美越狱方案就是因为攻破不了或者绕不开ASLR，所以每次重新启动后地址再度随机偏移，需要重新进行越狱操作。与此同时，ASLR也给应用层攻击带来了一些困难，不同进程会造成不同的地址空间偏移，而且在运行时才可确定其偏移量，不易锁定攻击地址。

Mach-O文件的文件头会记录二进制的属性标识，有个flag叫做PIE (Position Independent Enable)。开启了PIE的二进制文件，在执行时会产生ASLR。

我们可以使用otool工具，来查看任意应用程序二进制文件的属性。

有PIE标识，表示该程序在启动时会产生随机地址布局。

removePIE 是个去掉PIE flag的工具。
它不支持iOS7。
可以：利用Theos编译removePIE；改编一个Mac版的MyRemovePIE。

非越狱开发者可能不熟悉Theos。

创建一个Command Line Tool工程，

然后复制 removePIE.c 代码到main.c中，并且修改第43行：

 if(currentHeader.magic == MH_MAGIC){ //little endian

添加iOS7的判断条件:

 if(currentHeader.magic == MH_MAGIC || currentHeader.magic == 0xbebafeca ){ //little endian

编译后生成可执行文件MyRemovePIE.

利用我们编译生成的MyRemovePIE来处理应用程序：

01../MyRemovePIE Portal 

这样以后支付宝Portal再被启动执行就不会具有ASLR特性了

把处理过的Portal二进制拷贝回iPhone，启动支付宝钱包应用，然后gdb该进程，利用info sh命令查看偏移：

偏移量为0，一些手动处理的过程可以升级为自动了。