Start Securing Your iOS Apps from Zero

iOSDC 2024

https://fortee.jp/iosdc-japan-2024/proposal/03bf7708-471e-4533-967a-1990e990ece9

伝えたかったこと
- 自分の専門分野に関して、正しく脆弱性を理解したうえで、セキュリティエンジニアやセキュリティベンダーと対応コストも考慮した対応要否の議論が出来ると良い（その「正しい理解」をもってリスクを許容できることも重要）

Links
- OWASP Mobile Top 10 - OWASP
- MASVS - OWASP
- MASTG - OWASP
- スマホアプリの脆弱性診断って何するの？（iOS編）- STORES Product Blog
- How to inspect the bytes contained in a "Foundation.Data" byte buffer in Xcode? - StackOverflow

想定質問
- よくある脆弱性
- カスタムURLスキームの乗っ取り
- リスクそんなにある？
- 取り扱うデータや要件による。「脆弱性」はビジネスロジックの改ざんも含まれる。
- 例えばゲームだとメモリ改ざんやリクエスト改ざんでゲーム性を損ない得るし、金融系も同様。
- 課金だとレシートのチェックしてない、とかBoolで管理しているとか簡単にバイパス可能、とか。
- だが、一般的なアプリにSSLピンニング入れるメリットはそこまでないはず
- 特にiOSの場合堅牢で、比較的にリスクは小さいが、リスクがないわけではない。重要なのは、それが社会的にも自組織としても許容されるかされないか
- できない理由があるのであればリスク許容されうるが、そういうわけではないのであれば対応してしまったほうが早いのでは？コストに見合うかどうか
- デバイス落とした人を救うのか、救わないのか。セキュリティ目線でいうと、救える仕組みになっているべきではある（そういう仕組みにできるので）
- 「意味の薄い対策」とは？
- たとえば脱獄検知。一般的に紹介されているような方法は簡単にバイパスできる。Boolで管理しているならtrueを返せばいいだけ。Tweakで簡単にできる。あと、例えばバックアップに残存し得るデータで検知しているやつとか。
- メトリクスを取りたいだけなのか本気で防ぎたいのか、ゴールを決める
- SSLピンニングもそう。ピンニングして守りたいものは何なのかを考えた方が良い。それはBE側で担保するべき問題であることも多い。
- 要するに有効性とコストを、セキュリティエンジニアやベンダー側と議論できることが重要。

Transcript

1. Learning About Vulnerabilities from OWASP Mobile Top 10 Start Securing Your iOS Apps from Zero Soh Satoh (@soh_satoh) - STORES, Inc.
2. Who am I? • 2018? - 2021 • iOS Tweak Developer (Independent) • 2021 - 2023 • Security Engineer @ Security Vendor • 2023 - • Security Engineer @ STORES Inc 2 @soh_satoh
3. Introduction - What’s MASVS/MASTG? • MASVS The industry standard for mobile app security • MASTG A comprehensive manual for mobile app security testing and reverse engineering スマホアプリの脆弱性診断って何するの？（iOS 編 ）- STORES Product Blog 3 Reference: OWASP
4. Introduction - What’s OWASP Mobile TOP10? A standard awareness document for developers and mobile application security • M1: Improper Credential Usage • M2: Inadequate Supply Chain Security • M3: Insecure Authentication/Authorization • M4: Insu ffi cient Input/Output Validation • M5: Insecure Communication • M6: Inadequate Privacy Controls • M7: Insu ffi cient Binary Protections • M8: Security Miscon fi guration • M9: Insecure Data Storage • M10: Insu ff i cient Cryptography 4 Reference: OWASP (https://owasp.org/www-project-mobile-top-10/)
5. M9: Insecure Data Storage
6. M9: Insecure Data Storage Examples • Storing passwords in plain text • Unprotected logging • Unsecured local storage Attack Vectors • Sandbox escaping • Data leak from iOS backups • (Code injection) 6 Impacts • Leak of sensitive information • Leak of credentials • Compromised user accounts • Reputational damage Vulnerabilities caused by improper implementations for storing sensitive information
7. M9: Insecure Data Storage - App Sandbox App Sandbox A security mechanism for separating running programs • Restricting access to resources of other apps (e.g. UserDefaults) • Restricting access to system fi les ↓ Super Secure! 7
8. M9: Insecure Data Storage - App Sandbox 🤔 8 … Really?
9. M9: Insecure Data Storage - App Sandbox 9 Security 101 Do Not Overtrust Anyone!
10. M9: Insecure Data Storage - UserDefaults vs. Keychain • UserDefaults • NOT encrypted • Saved to “/var/mobile/Containers/Data/Application/{UUID}/ Library/Preferences” (mobile) • Can be backed up w/o encryption • Keychain • Encrypted (AES-128 / Hardware-based encryption) • Saved to “/var/Keychains/keychain-2.db” (_securityd) • Backed up with encryption 10
11. M9: Insecure Data Storage - Best Practices Best Practices • Do NOT store credentials in plaintext • Refresh token • Passwords (Never!) • Use Keychain as possible • Storing sensitive information in Keychain • Storing encryption keys in Keychain 11
12. M1: Improper Credential Usage
13. M1: Improper Credential Usage Examples • Hardcoded credentials • Insecure credential storage Attack Vectors • Sandbox escaping • Data leak from iOS backups • (Code injection) 13 Impacts • Leak of sensitive information • Leak of credentials • Compromised user accounts • Reputational damage Vulnerabilities caused by improper credential usage for storing sensitive information
14. M1: Improper Credential Usage - Hardcoded Credentials Hardcoded Credentials Examples • Encrypt sensitive information using hardcoded keys • Login to API using hardcoded password Attack Vectors • Reversing 14
15. M1: Improper Credential Usage - Obfuscation Obfuscation the act of creating source or machine code that is di ff i cult for humans or computers to understand Advantage It can delay the process of reverse engineering. Disadvantage While obfuscation can make reading, writing, and reverse-engineering a program di ff i cult and time-consuming, it will not necessarily make it impossible. 15
16. M1: Improper Credential Usage - Obfuscation 16 Encryption Flow (Example)
17. M1: Improper Credential Usage - Obfuscation 17 Static Analysis (with Ghidra) Disassembly Pseudocode
18. M1: Improper Credential Usage - Obfuscation 18 Dynamic Analysis (with LLDB)
19. M1: Improper Credential Usage - Obfuscation 19 Dynamic Analysis (with LLDB)
20. M1: Improper Credential Usage - Obfuscation 20 Dynamic Analysis (with LLDB) Ref: https://stackoverflow.com/a/78014359/26676166
21. M1: Improper Credential Usage - Best Practices Best Practices • Do NOT hardcode secrets • API keys • Encryption keys • Passwords • If secrets must be hardcoded, • Consider the importance of the information • Evaluate the e ff ectiveness of obfuscation 21
22. Summary Steps You Should Take for Mobile Application Security 1. Understand the common vulnerabilities in mobile apps 2. Consider whether each vulnerability could realistically have an impact, and assess the need for remediation 3. Develop the application with careful consideration of whether it could introduce vulnerabilities that might impact the business 22