IOS安全

轉載自
http://blog.csdn.net/column/details/hackingios.html

iOS安全攻防（十八）：數據保護API
?
數據保護API

拿越獄檢測來說，起初大家只需判斷有無安裝Cydia就好了，hackers們說好，那我就不安裝Cydia也可以動手腳。開發者們又說，那你一定得用的上MobileSubstrate，bash，ssh吧，我去檢測手機有沒有安裝這些工具?？墒怯钟惺裁从媚?#xff1f;你判斷什么我繞過去什么。

當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，一些手動處理的過程可以升級為自動了。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的IOS安全[转载]的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。