Alban Diquet, Data Theorem
Thomas Sileo, Data Theorem
Over the last two years, we've received and analyzed more than three million SSL validation failure reports from more than a thousand of iOS and Android apps available on the Stores, and used all around the world. From mobile banking to music apps, each report was triggered because an unknown or unexpected certificate was being served to the app, preventing it from establishing a secure connection to its server via SSL/TLS.
We've analyzed each of these reports to understand what caused the SSL connection to fail, and then grouped similar failures into various classes of SSL incidents. Throughout this presentation, we will describe the analysis we've made and present our findings.
First, we will provide a high-level overview of where, how, and why SSL incidents are occurring across the world for iOS and Android users, and describe the various classes of incidents we've detected. Some of these types of incidents, such as corporate devices performing traffic inspection, are well-known and understood, although we will provide new insights into how widespread they are.
Then, we will take a closer look at a few notable incidents we detected, which have been caused by unexpected, or even suspicious actors. We will describe our investigations and what we found.
Lastly, we will provide real-world solutions on how to protect apps against traffic interception and attacks, as a mobile developer.
6. TrustKit
• Open-source library for SSL reporting and pinning
• Released for iOS in 2015 and for Android earlier this
year
• https://github.com/datatheorem/TrustKit
• Makes it easy to monitor and improve the security of the
app’s network connections
7. SSL Pinning
• Hardcode in the app the SSL public key(s) to be expected
to be used by the app’s server(s)
11. SSL Pinning
• Hardcode in the app the SSL public key(s) to be expected
to be used by the app’s server(s)
12. SSL Pinning
• Hardcode in the app the SSL public key(s) to be expected
to be used by the app’s server(s)
// Initialize TrustKit
NSDictionary *trustKitConfig =
@{
kTSKPinnedDomains: @{
@"www.datatheorem.com" : @{
kTSKPublicKeyHashes : @[
@"lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=",
@"TQEtdMbmwFgYUifM4LDF+xgEtd0z69mPGmkp014d6ZY=",
]
}}};
[TrustKit initializeWithConfiguration:trustKitConfig];
13. SSL Pinning
• Hardcode in the app the SSL public key(s) to be expected
to be used by the app’s server(s)
// Initialize TrustKit
NSDictionary *trustKitConfig =
@{
kTSKPinnedDomains: @{
@"www.datatheorem.com" : @{
kTSKPublicKeyHashes : @[
@"lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=",
@"TQEtdMbmwFgYUifM4LDF+xgEtd0z69mPGmkp014d6ZY=",
]
}}};
[TrustKit initializeWithConfiguration:trustKitConfig];
14. SSL Reporting
• Send a report whenever an SSL error occurred
• Gives an overview of "SSL incidents" around the world
• Helps understanding connection errors across the user
base
• Helps making a decision on whether to deploy SSL
pinning
• Useful to all apps
15. SSL Incident
• Default SSL validation error
• Name mismatch, expired certificate,
untrusted CA, etc.
• Pinning validation error
App Server
17. SSL Reporting
• Any domain can be configured in TrustKit for where the
reports should be sent
• Data Theorem hosts one for free that developers can leverage
• Reporting dashboard to see trends and inspect individual
reports
• Notifications for when something unexpected happens
• Suspicious actor
• Spike in reports
20. The Data Set
• 10 million reports from 2 million devices in 2 years
• From apps configured to use Data Theorem’s reporting
server
• Mostly from iOS devices
• 70% of the reports came from the US
21. The Data Set
• From nearly 2 000 different apps
• Banking
• Shopping
• Music/streaming
• News
Top Platform
iOS 93.3%
Android 5.3%
macOS 1%
tvOS 0.4%
22. The Data Set
Top Countries
US 71%
GB 9.5%
TW 7.3%
CA 1.8%
HK 1.3%
23. The Data Set
• 3.3 million unique
certificate chains
• 38% of the certificate are
self-signed
• 78% of the certificate
matched the hostname
Certificate chain depth
2 62.2%
3 24%
1 11.4%
4 1.8%
5 0.5%
6 0.001%
24. Report Classification
• Use different heuristics to find the root cause
• By looking at the content of the report, mainly the
certificate chain
• Save some metadata along with the server date
• Contact the server for the hostname that was in the
report, to fetch its certificate chain
25. Report Classification
• Re-verify the certificate chain
• Set of rules that can target:
• A specific certificate or a specific public key
• Any certificate fields (Common Name, etc.)
47. Server Misconfiguration
• Category for servers with misconfigured SSL certificates
• Right now only one subcategory: expired certificates
• For example, huge spike of report when a certificate
deployed in production expired:
58. Pins Misconfiguration
• The SSL pins hardcoded in the app do not match the
server’s certificate chain
• With enforcement disabled:
• The app still works but is constantly sending reports
• With enforcement enabled:
• The app’s connections will fail
60. “On a Thanksgiving Day, November 24, 2016 an
emergency has occurred.
Customers of Barclays Bank, which were users of
mobile banking application, were unable to perform
any transactions due to pinning the outdated
intermediate certificate in the application.”
62. “Several thousands of customers of small and
medium-sized businesses, operating mostly in the
UK market, will not be able to perform any
transactions from 8.30 a.m. 25/11/16 on a "Black
Friday" and during the holiday shopping period.
This will affect hundreds of thousands of
customer's transactions, until the application is
updated, and then released again.”
63. Pins Misconfiguration
• 22% of apps with more than 30% of misconfiguration
issues
• Pressure on mobile developers to implement SSL pinning
in their apps
• From security teams, bug bounties, etc.
• But most apps do not need it
• Requires not just code changes but also very good
processes around server SSL keys
64. Global Categories
9 195 807 reports
Spyware 39%
Pins Misconfig 34%
Server Misconfig 4.3%
Dev Artifacts 0.5%
Corp Networks 2.2%
72. What Happened?
• A configuration profile was installed on the device
• With an always-on VPN config
• To route all traffic through the MobileXpression server
• With a custom root CA added to the device’s trust store
• To allow traffic decryption by the MobileXpression server
MobileXpression VPN App Server
73. MobileXpression?
“MobileXpression is a service of comScore, Inc., a
global leader in measuring the digital world,
providing insights into consumer behavior and
attitudes.”
74. ComScore
“This capability is based on a massive, global
cross-section of approximately 2 million
consumers, who have allowed comScore to collect
their online browsing, hardware and application
usage, and purchasing behavior.”
75. ComScore
• Owner of several “market research” apps
• MobileXpression, Digital Reflection
• Promise users rewards (gif cards, etc.) for installing the
app and configuration profile
76. ComScore
• Owner of several “market research” apps
• MobileXpression, Digital Reflection
• Promise users rewards (gif cards, etc.) for installing the
app and configuration profile
77. ComScore
• Inspect/decrypt all the users’ traffic to measure app
usage
• ComScore’s business model as a "measurement
company”
78. Spyware - Market Intel
• Configuration profiles are problematic
• Highly technical security warnings when installing the profile
• The profile/VPN does not get uninstalled when removing the app
• Makes sense from a technical perspective but will confuse users
• But not an easy issue to fix
• Corporate enrollment / MDM use case
• A profile can be installed directly via Safari
• Banning the spyware app from the store does not prevent it
81. Spyware - Ad Blocker
• Similar technical implementation with a VPN and custom CA
• Defend My WiFi
• "Automatically turns public Wi-Fi into safe and secure private
WiFi”
• Company does not exist anymore?
• Adblock Mobile
• iOS 8: SSL mitm on ad domains only
• iOS 9+: No more custom CA installed
86. What did we see?
• Traffic interception does happen, and for many reasons
• Usually not malicious
• Employers
• Users “willingly” sharing their data for a reward
• No visible move from Apple and Google on this
• Similarities and differences compared to previous work
on the web/desktop (Google, Facebook, Cloudflare)
87. What do we do?
• Which group does your app belong to?
• It is acceptable to expose the user’s data to “lawful
interception” (such as the user’s employer)
• Games, Business apps
• The user’s data is private and can never be exposed
• Mobile banking
• Can be technically enforced via SSL pinning
88. What do we do?
• More options on mobile compared to the web
• SSL reporting helps you understand what is happening
across your user base
• SSL pinning can be used for sensitive apps
• Significant burden and risk of catastrophic failure
• Must be decided and planned carefully
• Does not prevent reverse-engineering of your app