您的位置:首页 > 移动开发 > IOS开发

iOS安全攻防:越狱检测的攻与防 废除应用程序的ASLR特性

2014-03-10 09:44 471 查看


转自念茜的博客

本文是《iOS安全攻防》的(二十)和(二十一)小结内容

iOS安全攻防(二十):越狱检测的攻与防

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

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

那么,到底应该如何检测越狱呢?攻击者又会如果攻破检测呢?本文就着重讨论一下越狱检测的攻与防。



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

但是不要写成BOOL开关方法,给攻击者直接锁定目标hook绕过的机会
+(BOOL)isJailbroken{ if ([[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]){ return YES; } // ... }
攻击者可能会改变这些工具的安装路径,躲过你的判断。

那么,你可以尝试打开cydia应用注册的URL scheme:
if([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"cydia://package/com.example.package"]]){ NSLog(@"Device is jailbroken"); }
但是不是所有的工具都会注册URL scheme,而且攻击者可以修改任何应用的URL scheme。

那么,你可以尝试读取下应用列表,看看有无权限获取:
if ([[NSFileManager defaultManager] fileExistsAtPath:@"/User/Applications/"]){ NSLog(@"Device is jailbroken"); NSArray *applist = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:@"/User/Applications/" error:nil]; NSLog(@"applist = %@",applist); }
越了狱的设备是可以获取到的:



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

那么,你可以回避 NSFileManager,使用stat系列函数检测Cydia等工具:
#import void checkCydia(void) { struct stat stat_info; if (0 == stat("/Applications/Cydia.app", &stat_info)) { NSLog(@"Device is jailbroken"); } }
攻击者可能会利用 Fishhook原理 hook了stat。

那么,你可以看看stat是不是出自系统库,有没有被攻击者换掉:
#import void checkInject(void) { int ret ; Dl_info dylib_info; int (*func_stat)(const charchar *, struct stat *) = stat; if ((ret = dladdr(func_stat, &dylib_info))) { NSLog(@"lib :%s", dylib_info.dli_fname); } }
如果结果不是 /usr/lib/system/libsystem_kernel.dylib 的话,那就100%被攻击了。

如果 libsystem_kernel.dylib 都是被攻击者替换掉的……

那也没什么可防的大哥你随便吧……

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

列出所有已链接的动态库:
#import void checkDylibs(void) { uint32_t count = _dyld_image_count(); for (uint32_t i = 0 ; i < count; ++i) { NSString *name = [[NSString alloc]initWithUTF8String:_dyld_get_image_name(i)]; NSLog(@"--%@", name); } }

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

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

那么,你可以通过检测当前程序运行的环境变量:
void printEnv(void) { charchar *env = getenv("DYLD_INSERT_LIBRARIES"); NSLog(@"%s", env); }

未越狱设备返回结果是null,越狱设备就各有各的精彩了,尤其是老一点的iOS版本越狱环境。
iOS安全攻防(二十一):废除应用程序的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工具,来查看任意应用程序二进制文件的属性,以支付宝为例:
otool -hv Portal




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



removePIE 是个去掉PIE flag的工具。

坏消息是,年久失修,它不支持iOS7。

好消息是,我们还有2个变通方法可以走。
1.利用Theos编译removePIE
2.改编一个Mac版的MyRemovePIE

非越狱开发者可能不熟悉Theos,低学习成本的做法是第二种,那么让我们来改编一个Mac版的MyRemovePIE吧。

(懒得动手的可以直接到这里下载demo

创建一个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来处理应用程序:
./MyRemovePIE Portal



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





如何验证一下结果呢?

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




偏移量为0,嗯,这下就好了。一些手动处理的过程可以升级为自动了~
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: