Trusting iOS SDKs
summary
Analysis of 40 popular iOS SDKs finds 31% of top SDKs vulnerable to simple man‑in‑the‑middle attacks that replace downloads served over HTTP. Demo replaces SDK zips via a Raspberry Pi MITM and shows a malicious binary that enables SSH and a keylogger, harvests iCloud credentials via fake system prompts and runs without code calls. One SDK fixes in 3 days, five within a month, seven never reply. Recommendation: refuse unencrypted installs and avoid curl | sh over HTTP for SDKs.
AI-written summary · about
chapters (18)
- 0:00Introduction and setup
- 1:49Why third-party code matters
- 4:21Security risks in SDKs
- 6:30HTTP vs HTTPS explained
- 9:00ARP poisoning basics
- 10:49CocoaPods security flaws
- 11:51Localytics download attack
- 14:23AWS SDK vulnerability
- 15:28iCloud phishing pop-ups
- 18:19Malicious SDK injection demo
- 18:42Developer machine attacks
- 19:24Shell script SDK exploit
- 21:12Attack realism and Wi-Fi risks
- 22:37Vulnerability research findings
- 23:43Closed vs open source SDKs
- 24:26SDK provider backdoors
- 25:07Responsibility of developers
- 25:29Q&A session begins
related talks
24mTrusting SDKs
43mTrusting SDKs
39mMobile App Security
47mSecurity Threats & Mitigations for iOS Developers
48mMobile Security Attacks: A Glimpse from the Trenches
27miOS Attack Vectors and how to protect your app
58mUncovering OWASP’s Mobile Risks in iOS Apps
15mAvoiding Security and Privacy Issues in SDK Integration