In this second session, we will take a further dive into more of OWASP's top 10 threats for mobile security, the common Android security pitfalls we all succumb too and look how we may code in a more security-focused mindset going forwards.
Dad to a Pomeranian • Security ‘enthusiast’ (Please please note: NOT expert) Find me on social: • @Sp4ghettiCode • spght.dev/talks • Follow me for more! (And dog pictures) Who am I? I’m this one. This is not me.
I have enough time to cover • Introduction to more of the OWASP Top 10 • Address the most common mistakes in our apps • Q&A • Bedtime (for me at least!)
just in case someone goofs up later. • Anything you learn here is to be used for educational purposes ONLY • Do NOT test on apps you are not authorised to use • Please consider seeking your company’s security advice from someone that knows a lot more than me! • This talk is NOT associated with and/or endorsed by the OWASP Foundation or my employer!
Web Application Security Project • Non-profit OWASP Foundation created in 2001 • Provides free security resources for developers & organisations alike • Also maintains ‘Top 10’ list(s) of the greatest security threats to application security
updated 2016) 1. Improper Platform Usage 2. Insecure Data Storage 3. Insecure Communication 4. Insecure Authentication 5. Insufficient Cryptography PART 1 OF THIS TALK NOW AVAILABLE ON ANDROID WW’S YOUTUBE youtu.be/HRJw8RIgbSg spght.dev/talks 5
you’re allowed to do that… • Authorisation != Authentication • Authentication = Proving your identity • Authorisation = Performing an action with permission • E.g. Logging in to Twitter • Authentication via email + password • Authorisation permits you to view your DMs (and not mine)
‘How insecure can we make an app’ • Smart Sheriff was a 2015 government mandated parental monitoring mobile app in South Korea • By LAW must be installed on anyone under the age of 19’s phone • Gave parents the ability to monitor web searches, block sites and snoop on messages • Amazing talk: Smart Sheriff, Dumb Idea by Abraham Aranguren & Fabian Fäßler
‘How insecure can we make an app’ • The app had an API to retrieve lost passwords for child accounts that could be called by any user • Passing in a mobile number would return either the app’s password or the mobile number of the child’s parent 🤦 • Trivial to traverse phone numbers to gain privileged info • Pen-test link @ spght.dev/talks Image: 7asecurity.com
When using authorised APIs • Use the minimum required permissions for call • Verify any user roles server-side • Avoid using role/permission information that comes from the mobile device itself
• Have a solid code review process • Use static analysis tools e.g. SonarCloud / Snyk • Know the flaws and dangers with using particular languages • Consider using ‘Strict Mode’ to catch errors early
within Android Framework to detect code violations at runtime • e.g. Performing I/O operations on the Main Thread • Leaks - e.g. not closing a ‘Closeable’ • Split into Thread + Virtual Machine violations
BEST PRACTISES: • Add within Application class before super.onCreate call • Use within debuggable builds only • Use penaltyDeath() for most serious cases • E.g. penaltyDeathOnCleartextNetwork() • Always read the docs!
unwanted modification of your app’s code • Modification of your app’s resources • The unintended use of your app through the use of a ‘rooted/ jailbroken’ device • More common in popular apps such as ‘freemium’ games • Used by malicious actors to distribute modded APKs with spyware + more nasty surprises 😈
• Using APKTOOL: ibotpeaches.github.io/Apktool • Decompiles APK to resources and SMALI files • SMALI = Converted .dex byte-code • Run using: apktool d app.apk
# Re-compile the app # base in this example is the base folder of the decompiled app apktool b base # Generate a new key to sign the build keytool -genkeypair -v -keystore key.keystore -alias publishingdoc -keyalg RSA -keysize 2048 -validity 10000 # Sign the new app APK jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore ./key.keystore base.apk publishingdoc • Modify Smali files to do XYZ (i.e. whatever) • Samples: https://ur.link/43i ⚠ • Re-compile app using apktool then re-sign using jarsigner
two articles with relevant code tampering material: • “Learning to 'Hack Android' with picoCTF” • “Hands on with Jetpack's Security App Authenticator library” ✨ BOTH AVAILABLE TO READ AT SPGHT.DEV ✨
your app and understanding how it works to find vulnerabilities + other goodies • Similar attack approach to Code Tampering • Uses a similar set of tools to look at source code
• .dex files are Dalvik Executable files • Similar to Java .class files but run on Android’s JVM • Contains Dalvik byte code • Possible to convert back to its original source code (lossy process)
• Where possible, do not ship with anything included in your app that could be ‘enabled’ when you don’t want it to be • Ensure you strip out any hard-coded credentials or anything you use for QA-ing the app • GOOD CODE REVIEWS!
Twitter @Sp4ghettiCode • Thanks to Android Worldwide for rescheduling this talk! • More resources and links at spght.dev/talks • Please do reach out if you are interested in learning more or have knowledge to share with the community! • Questions and Answers to follow…
sp4ghetticode
maroon1st
myamagishi
syumai
datanalyticslabo
oekazuma
sullis
taiyow
honyanya
niftycorp
rinchoku
stoneream
eddie
kastner
phodgson
mongodb
afnizarnur
sonatard
akosma
garrettdimon
tammyeverts
wjessup
quramy
eileencodes
jnunemaker
