mobile day - app (in)security

INTRODUCTION MOBILE INSECURITY THE END

Mobile Aplication (In)Security

Fernando Castañeda G.

31 de octubre de 2017


#WHOAMI

I Penetration Tester or PentesterI Professor

I Penetration TestingI Operating SystemsI Computer Organization and ArchitectureI C Programming LanguageI (Next Semester) Development of Secure Mobile

Applications

I (Lawless) DeveloperI Malware Reverse Engineering and CTF aficionado


PRINCIPLES AND STUFF

I "Hacker’s Ethics"I Hackers should be judged by their hacking, not bogus

criteria such as degrees, age, race, or position


HISTORY

I 1908 -> Professor Albert Jahnke (First attempt to build aphysical wireless phone)

I 1907 -> Lewis Baumer (Forecasts for 1907)


NOWADAYS...

I War and (true)Hackers changed (almost) everything...I First there were the PDAs, then came the fusion with

cellphones that evolved into our useful devicesI We have an incredible power of processing in our pocketsI We can do almost everything we used to do on a PC on the

last decade or process through a mainframe on the 90swith a single touch


SEEMS OK BUT...

I We share a lot of personal data through our devicesI PicturesI Financial DataI Medical InformationI BiometricsI Private or Sensitive DataI And so on...

I And it’s far from being safe... :(


SOME PROOFS

I Perhaps the most important, Information Leakage...


REMEMBER THE TRIAD (CIA)

I ConfidentialityI IntegrityI Availability


CORE PROBLEMS

I Assumptions on user’s behaviourI Low or null knowledge of the platformI (Mostly)Developed under pressureI Disinterest for InfoSec (must be functional before secure)


OPEN WEB APPLICATION SECURITY PROJECT

I Start operations on 2001I Becomes a foundation in 2004, in order to get resources to

their projectsI OWASP depends on donations and the fees to their

associates, partners and companies


WHAT IS RELEVANT FOR US

OWASP MOBILE TOP 10Code VulnerabilityM1 Improper Platform UsageM2 Insecure Data StorageM3 Insecure CommunicationM4 Insecure AuthenticationM5 Insufficient CryptographyM6 Insecure AuthorizationM7 Client Code QualityM8 Code TamperingM9 Reverse EngineeringM10 Extraneous Functionality


M1. IMPROPER PLATFORM USAGE

I Android and iOS are Operating Systems

I Mobile Applications are not Web Applications (at all)I OWASP TOP 10 (not mobile)

I SQLiI XSSI XSRFI and so on...



I Android and iOS are Operating SystemsI Mobile Applications are not Web Applications (at all)

I OWASP TOP 10 (not mobile)I SQLiI XSSI XSRFI and so on...



I Android and iOS are Operating SystemsI Mobile Applications are not Web Applications (at all)I OWASP TOP 10 (not mobile)

I SQLiI XSSI XSRFI and so on...


M2. INSECURE DATA STORAGE

I A lot of information can be extracted from stolen phonesI Sensitive data should not be saved in plain text...

sensitivedata should not be saved on client’s side

I Banking Apps asks for re authentication after some time ofnull activity, and that is perfect!


M2. INSECURE DATA STORAGE

I A lot of information can be extracted from stolen phonesI Sensitive data should not be saved in plain text... sensitive

data should not be saved on client’s sideI Banking Apps asks for re authentication after some time of

null activity, and that is perfect!


M3, M5 = INSECURE COMMUNICATION,INSUFFICIENT CRYPTOGRAPHY

I SSL/TLS is not only for WebPagesI There is a general misconception of cryptography


M3, M5 = INSECURE COMMUNICATION,INSUFFICIENT CRYPTOGRAPHY

I Cryptography Is Not the SolutionI Cryptography Is Very DifficultI Cryptography Is the Easy Part

-Niels Fergusson, Bruce Schneier, Tayadoshi Kohno(Cryptography Engineering)

I Good implementations and understanding are needed...


HOW DOES INSECURE COMMUNICATION AFFECTS

MY APP?

I A Man in the Middle attack is always possibleI If I am in your network, I can sniff your packetsI If I used a proxy, I could intercept your requests


M4, M6 = INSECURE AUTHENTICATION, INSECURE

AUTHORIZATION

I Client Side Authentication (?)I Bad Semantics or "the ID in the petition manages it all"I No cookies or Token or anything to identify an userI Remember the AAA

I AuthenticationI AuthorizationI Accounting


MN. THE REST OF THE TOP VULNERABILITIES

I Some frameworks are new, are cool and untestedI Some functions are deprecatedI Sometimes debugging is forgotten when activatedI Sometimes there are weird reactions to certain actions


POC

I Turn off your cameraI Thou shalt not speak about this PoCI This will not be public for the good of this fellow... (me)


IMAGES AVAILABLE LIVE ONLY

I Sorry :)


A WORD ON MOBILE INSECURITY

I Know your FrameworkI Know your platformI Use well known cryptographic implementationsI Secure Channels please! (certbot might help you get free

trusted certificates)I Look for deprecated functionsI Care about debugging, but remember to disable it when

you finish debugging

https://certbot.eff.org


A WORD ON MOBILE INSECURITY II

I The apps that you use, you wouldn’t like to see thembroken, exposing your information

I If information gets leaked, you may face your client’sanger (and the law...)

I Care about Information SecurityI Do some penetration testing

I Or hire a good pentesterI Train!





I Care about Information SecurityI Do some penetration testingI Or hire a good pentester

I Train!





I Care about Information SecurityI Do some penetration testingI Or hire a good pentesterI Train!


WHERE CAN I TRAIN?

I Never pay expensive training (unless you really want it),there are a lot of good free resources.

I Click these to follow the training...I ANDROID -> InsecureBankingv2I iOS -> Damn Vulnerable iOS ApplicationI Others -> You should solve both...

I Devour the OWASP stuff

https://github.com/dineshshetty/Android-InsecureBankv2

http://damnvulnerableiosapp.com/


DUDAS?

FYI:http://fcastaneda.herokuapp.com/f/c/g/mobileday.pdf

@f99942 || @[email protected]

[email protected]

GRACIAS!!!!!!!!!!

http://fcastaneda.herokuapp.com/f/c/g/mobileday.pdf

mobile day - app (in)security

Software