APIsecure 2023 - Enhancing API Security with Runtime Secrets & Attestation, Ted Miracco (Approov)
0 likes40 views
The document discusses enhancing API security through runtime secrets and app attestation, highlighting various mobile attack surfaces and methods to protect API keys. Key findings from a recent report show significant vulnerabilities in financial apps, with suggestions for defenses like obfuscation, runtime checking, and secure storage of secrets. The proposed approach emphasizes minimizing security functionality within apps while allowing live updates to secrets, thus strengthening resilience against attacks.
APIsecure 2023 - Enhancing API Security with Runtime Secrets & Attestation, Ted Miracco (Approov)
- 1. Enhancing API Security with Runtime Secrets & Attestation PRESENTED BY: Ted Miracco
- 2. 2 Ted: Defense Electronics -> RF/Microwave CAE -> Electronic Design Automation -> Anti-Piracy Technology -> Mobile App & API Security Skip: Chip Design -> Reconfigurable Computing -> HW/SW -> Embedded & Crypto Acceleration -> Mobile and API Security approov.io tedmiracco skiphovsmith
- 3. 3 Outline ● Mobile Attack Surfaces ● Hiding API Secrets in App ● Moving Secrets Off Device ● App Attestation ● Summary & Next Steps
- 4. 4 5 Mobile Attack Surfaces ● Attackers can use their devices, emulators, environments for reconnaissance ● Better reconnaissance, the more profitable attacks
- 5. 5 Danger - Hardcoded API Keys ● In the Headlines… ○ Automotive ○ Retail ○ Fintech
- 6. 6 Attack: Static Analysis ● Search for high-entropy strings ● Use static analysis tools like MobSF, JADX, AndroGuard ● Keys could be constants, resources, or inside NDK ● Surprising how often this yields results
- 7. 7 Recently Published “Secrets Report” ● Looked at the top 200 Financial Apps - Sensor Tower ● Downloaded the APKs ● Performed Static Analysis ○ apk_api_key_extractor ○ Git Leaks ○ Trufflehog ● Categorized the Findings ● Grouped the Results by Application Type and Country
- 9. 9 Report Findings - By Country
- 12. 1 2 Initial Defense: Obfuscation ● Obscure hardcoded secrets, program flow, and security code ● Use R8, ProGuard, or others ● Trade obscurity vs run time cost ● If a secret is valuable enough, it may be reverse engineered
- 13. 1 3 Attack: Run in Debugger ● Though secret is hidden in code, it's still exposed in the run time, go after it there ● Analyze code flow and call signatures to identify values exposed at run time ● Replace key functional blocks
- 14. 1 4 Defense: Run Time Checking ● Block running in debugger and emulator ● See https://github.com/scottyab/rootbeer, for simple approach ● Adds more functionality to protect and to be protected ● Attacks evolve over time, do detection tools keep pace?
- 15. 1 5 Defense: Play Integrity ● Stronger form of run time checking which guards against rooting, tampering, and repackaging ● Requires Google Play services ● Time and quotas may limit use ● Note that the verdict is evaluated off device
- 16. 1 6 Attack: Manipulator in the Middle ● Pivot to the channel ● Manipulator pollutes the device trust store and spoofs the service identity. ● Manipulator decrypts and reads and/or manipulates credentials and API calls/responses.
- 17. 1 7 Defense: Certificate Pinning ● App compares public key fingerprint of presented and expected certificates. ● Fingerprint can be specified statically in the android manifest file or specified at networking client construction. ● Fingerprint is not a secret, but should be write-protected.
- 18. 1 8 Attack: Bypass Certificate Pinning ● Add instrumentation frameworks to hook functions without tampering ● Objection and Frida can detect and bypass OkHttp pinning ● With obfuscation, may need to search for function call signatures blog.nviso.eu/2019/04/02/circumventing- ssl-pinning-in-obfuscated-apps-with- okhttp/
- 19. 1 9 Defense: Trust On First Use ● On first launch, your app requests some primary secrets ● Primary secrets no longer hardcoded but are placed in secure storage ● Primary secrets may be used to decrypt other hard coded secrets ● Assumes app & channel are initially trustworthy and storage is safe Store secrets in secure storage On first launch, request secrets
- 20. 2 0 Defense: Harden Channel ● Use short-lived JWT Tokens ○ Use API secret to sign JWTs ○ Secret not exposed in channel ● Sign or encrypt API messages ○ Increases anti-tampering or confidentiality ○ Requires more secrets, time, and functionality
- 22. 2 2 Hide & Seek Observations Upsides ● Loading secrets remotely (TOFU) avoids hardcoding them ● Play Integrity evaluates verdicts off app ● JWTs do not directly expose secrets in the channel Downsides ● TOFU requires blind trust ● More protection capabilities mean more secrets and more functionality to hide ● Frequent code updates are required as attacks evolve
- 23. 2 3 Design Objectives ● Keep no secrets in app at rest (in code or storage) ● Minimize amount of security functionality in app ○ Measure app and run-time environment ○ Make security decisions off app ● Provide live updates to both secrets and security
- 24. 2 4 Proposed Architecture Protocol: Request - Measurement - Verdict - API Call - Validation
- 25. 2 5 Making a 1st Party API Call If app attests as healthy, a properly-signed token is validated by the 1st party recipes service
- 26. 2 6 Making a 1st Party API Call If app attests dirty, an improperly-signed token is rejected by the recipes service
- 27. 2 7 Changing the Signing Secret ● Ops team changes secret at the service and the gateway. ● Each app’s next attestation is signed with the new secret.
- 28. 2 8 Making a 3rd Party API Call ● If app attests clean, the 3rd party API key is passed to the SDK. ● The SDK rewrites the API call to use the API key.
- 29. 2 9 Changing an API Key ● Ops team changes the 3rd party API Key at the service. ● Each app’s next clean attestation returns the updated API key.
- 30. 3 0 Managing Certificate Pinning ● Ops team changes certificate at the app auth service ● The next attestation updates the certificate, and the SDK generates a new certificate-pinning client
- 31. 3 1 Signing a Message ● If app attests clean, the message signing key is passed to the SDK. ● The SDK rewrites the API call after signing the message.
- 32. 3 2 Updating Security Live Security Posture ● Changing security posture is simply a change in how measurements are used to decide the attestation verdict ● Ops team can change security policies at the app auth service ● Full measurements are still being reported Security Enhancements ● Cannot update dex code of the app, but can reconfigure the measurement service inside the SDK after a clean attestation
- 34. 3 4 Mobile Application Security Verification Standard ● Impede Dynamic Analysis and Tampering ○ All detections can be split into measurements and verdicts ○ Detection and response are separated and further protected by on/off app split (stealthy) ● Device Binding ○ Unique IDs enable different security policies per device and app ● Impede Comprehension ○ Small footprint SDK and auth channel can be rigorously shielded ○ Other portions of an app can be independently obfuscated ● Impede Eavesdropping ○ Certificate pinning and message encryption can be managed off device Resilience is strengthened by having secrets never at rest, splitting measurement from verdict, and live updating:
- 35. 3 5 API Secrets Exposed ● 23% Financial Applications Immediately Revealed Secrets ● Code Obfuscation Ineffective ○ 93% with Obfuscation ○ 96% without Obfuscation ● Only 4% Used TLS Certificate Pinning ● Vulnerabilities exist both at rest and at runtime
- 36. 3 6 App Auth as a Service ● Removed secrets in app code and storage ● Minimized security vulnerabilities in app by: ○ Measuring conditions in app ○ Deciding security verdicts off app ● Provide live updates to secrets and security ● Provide live telemetry and forensics
- 38. 3 8 Questions ● How expensive is an attestation, and how often should a running app be re-attested? ● What's the relationship between user authorization and app attestation/authorization? ● Why is remote attestation better than really strong in-app self-protection?
- 39. 3 9 Man-in-the-Middle Attacks MitM attacks occur when an attacker intercepts or manipulates mobile device communications to gain access to sensitive information. Apps were considered protected if pinning is detected in the network config file and no other red flags are raised. They were rated vulnerable if (1) user-generated trust anchors were permitted, (2) cleartext traffic its permitted for non-localhost domains, or (3) Android SDK API level below 25 is declared in the Android Manifest.