Mobile App Security Fearmongering?

[@picklerick814]

"Flashlight" wants to use Location Local Storage External Storage Address Book Phone SMS WiFi status One of your kidneys Your social security number Your Bank Account

[@quantumbracket6995]

"Karen" wants to: take the kids

[@LiEnby]

doesnt even use the camera so it cant even touch the flashlight XD

[@staliniumprojectile]

*accept*

[@kangjiahuang9928]

@@staliniumprojectile Intents: DEVICE_WAKE, DEVICE_BATTERY_LOW, DEVICE_BOOT, DEVICE_POWEROFF *looks legit*

[@SalmanHusainGplus]

I totally agree. Mobile apps themselves are not really a target in the old sense of netsec. The only way (other than intent and other best practice violations) is a sandbox escape which is a game over anyways. I can really only speak for iOS but the OS makes it super easy to be secure, even forcing you to be with things like App Transport Security. On iOS if you want your file to be only decrypted when the device is unlocked and the app is running you just need a simple flag. With things like ASLR and PIE by default RCE tbh is out of the question so really if we can trust the sandbox we can trust the app no matter what.

[@kropmad]

Hey buddy, great video. I have to say that I tottally agree with you, specially on certificate pinning Don't get me wrong, I think every app should implement it if they can, but it's just a point to improve not a vulnerability. And the reason is simple, every time I have to do a penetration test with an app that implements it is a pain in the a** just to make the traffic go through my proxy, usually I have to spend a lot of time doing reverse engineering and patching the app just to start doing the job. Of course a black hat building a bank malware will have to do the same thing and if I was able to it, why wouldn't they? That's why I think certificate pinning is a "nice feature" but the lack of it is certainly not a vulnerability at all

[@hblaub]

Yeah fear sells. Please keep doing your videos. Really great and informative stuff. I personally don't do reverse engineering or pen testing for a living, but I'm interested in it as a hobby.

[@roguesecurity]

This has become common in today's world. Any new research related to vulnerability is exaggerated to such an extent that it grabs media headlines which in turn create chaos in public related to security stuffs. Media does not understand the vulnerabilities properly and just portrays them as biggest security threat of current time. This is exactly FUD

[@cryptodavidw]

Hey! Very nice video. I agree with everything you said, except maybe the "this is how SSL is supposed to work". There is nothing that tells you that TLS needs to use a "trust store" to validate certificates. Yes this is how HTTPS works on the internet, but this is definitely not how a banking app should secure its server's connection. See things like that: the banking app is not trying to reach websites on internet, it is just trying to communicate with a server, probably not even via the HTTP protocol (maybe an RPC connection?) What can it do to secure data? Well it can use many protocols. If it does decide to use TLS, it needs to make sure that the server is indeed the server, and the first way to do that is certificate pinning or a trust store inside of the app. Using the OS' trust store for that is dumb, just because it was not designed at all for this purpose but for browsing internet! Now is this a huge vulnerability issue? Of course not, you still need to manually install a cert on your mobile phone. Is this is an issue? Of course yes, the app should not use an external trust store to validate its own server, especially if these are banking servers.

[@cryptodavidw]

to add to this, think about it with threat models. Why would you include the internet PKI into your app's threat model? Sure it's working smoothly for browsing, sure if you can break the app then you would break the internet, but it is still not a good reason to include this threat model in your app by using the phone's OS trust store.

[@lightarmanov6266]

could I also mentioned that you don't need to hijack dns to cause a phone to connect to your server assuming this attack is done with an installed app couldn't that app just add a line to the hosts file

[@CptSenicar]

One thing that's not super clear to me... in the talk the researcher says he didn't actually have to touch the client at all to MitM the SSL connection. In the paper it mentions using social engineering as a potential method to get a user to install a cert to the local trust store. But it doesn't seem clear which method was actually exploited: Did the app use the local trust store to validate the cert for the backend connection (for mobile banking this would be pretty bad)? Or did the app just blindly accept any cert it received (much much worse)? The paper implies (but doesn't seem to explicitly state) the former, while the talk implies the latter.

[@LiveOverflow]

The app was using the local CA truststore

[@cryptodavidw]

The former it is of course ;)

[@Dosamer]

Oh i remember that talk from 33c3. That was entertaining, but your point is valid.

[@ytsuge]

Hi, I see you have drawn some conclusions from the poll you sent out for us to fill :) Good for you, I really enjoyed this this video!

[@samyong4148]

I agree with your criticism of the "research". I think interesting findings alone do not make a good research - sound arguments do. And this is what's lacking in this "research" of the mobile banking apps.

[@bjornleonhenry9750]

thanks for sharing, I agree with your point of view on this @LiveOverflow always interesting to watch your videos (or mostly listen to them actually) but anyways, it's both educating and enjoyable to hear your thoughts on hacking IT security and tech related topics in general so please keep uploading and stay awesome! the researchers claims are IMHO a bit confusing and over dramatic may be misleading and seemingly based on very theoretical analysis with no actual real proof of concept but of course anything is possible on the Internets...

[@adamkrasuski4743]

A small issue: at 13:11 the circled text is misleading due to missing word "account" that was on the next line in the article. When zooming and underlining a phrase, you should make sure it's what you mean. I mostly agree with your commentary. The biggest takeaway is that researchers exaggerate and news article writers misunderstand them furthering the reality distortion. DNS redirection and similar attacks are not trivial to pull off and are not caused by vulnerability in the app. Similarly for "vulnerabilities in CA validation process". This, or the possibility of malware being installed, in general means game over already. There's also the issue of phishing, but it's vulnerability of the user, not the app. On the other hand, while lack of countermeasures (even best effort ones) against these can not be classified as vulnerability, banking and other high-stakes applications would be responsible to implement them. Yes, it's the defense in depth, and yes, it's not a magic bullet, but if it improves the situation, they should do it. I don't agree with your counterarguments regarding phishing. The paper mentioned it as means of tricking person to install non-official certificate. Cryptography is understood very poorly by vast majority of population, so it wouldn't be a far stretch to imagine a person, which being shown some dummy error saying you need to install certificate to view content, does so. Heck, even some of my university's websites have broken SSL forcing me to add exceptions to the browser to even use it - and it's half way towards the described scenario. This is in contrast to your examples: "user can be tricked to install malware", which is in my opinion much less likely even for average person. Similarly phishing N26 dev to steal private keys is much harder, as they probably know what they're doing.

[@bibabuzze]

The banking app shouldn't use the CA store of the device, rather it should only trust the CA certificate of the bank.

[@saurabhswaroop9999]

thats what is cert pinning is , I think !

[@fasttorwa]

Finally someone understood!

[@vaisakh_km]

Now i also😅

[@marcelc2820]

I saw this talk recently and I was thoroughly rustl'd glad im not alone. He sounds like every LeetHax0r I have the displeasure of studying with. Constant inaccuracies and wild exaggerations. Oh und die schirchen Deutschen Accente. ;)

[@itfitness5791]

This dude from the n26 talk is ridiculous. What if the attacker Rev engineers the app, removes certificate pinning and rebuilds the app, still a vulnerability bc he didn't also use obfuscation to prevent that? Is every app without obfuscation a security vulnerability now? He obviously does not get what vulnerability means

[@iWhacko]

Yeah, he's basically saying: "Look if you disable every security measure this app has, you can do ANYTHING!!" :)

[@abc321meins]

Am I the only one around here who HATES certificate pinning? Of course it makes it harder for the attacker to do a MITM, but it also makes it impossible for me as a user to see what data is exchanged between the app and my bank. And imho the user should always be able to check wich data is transferred. I simply don't trust the closed source and obfuscated banking app at all. A simple popup in the app like: "The certificate has changed! Your connection is not secure! Please type"OK" to continue.". Would be a much better solution.

[@emilhozan71]

Hey! I'd love to hear more about this, do you have some additional information about how you went about "snooping" in on this traffic?

[@____-pb1lg]

@@emilhozan71 +1

[@frankschneider6156]

I tend to agree with most what you say, but not everything (I'm referring to mobile security in general, not the N26 stuff). One major difference between websites and apps is the degree of sandboxing. In a browser the code is at least in principle generally sandboxed from resources (especially from storage devices). On a smart phone the user is tasked with setting the degree of the sandboxing and which APIs the app is shielded from or not. This introduces a human element into the security, and obviously that's the weakest link in the chain that can and is being exploited, as people are primarily concerned with "stuff should run" not "stuff should be secure". People trust the application, as being generally trusting has been an evolutionary beneficial key-trait of humans as social animals (at least within the social group). This is of course not an app problem, but an overall issue. Combine this with a non-functioning update/system (which is the price one has got to pay for an open system) and the number of rooted phones and voila, you have a pretty insecure environment. Especially in a time, where people don't just want to break stuff for fun anymore, but primarily want access to data (the more confidential the better) without raising suspicion for nefarious purposes. So yes, I do think that the mobile environment rightly deserves its image as being "insecure", so this claim is certainly no FUD (although sensationalist articles certainly are). This also doesn't mean I'd declare classical, non-mobile environments"secure". Obviously they are not. One final note: yes, not using certificate pinning for transaction based applications IS an issue. as it adds security by providing an additional obstacle for an attacker. Yes, of course this can be overcome, but every additional layer helps (defense in depth yadda yadda) and this adds up. Thus using it is good practice, not doing so is not.

[@iWhacko]

"Combine this with a non-functioning update/system (which is the price one has got to pay for an open system) and the number of rooted phones and voila, you have a pretty insecure environment. Especially in a time, where people don't just want to break stuff for fun anymore, but primarily want access to data (the more confidential the better) without raising suspicion for nefarious purposes. So yes, I do think that the mobile environment rightly deserves its image as being "insecure", so this claim is certainly no FUD" But But, HOW can you blame the app for running on an insecure device? Sure you can implement certificate pinning to make sure the connection is secure. But if the device is compromised, they can disable all that. And the app can refuse to run on a rooted device, but hey that can be patched. So basically saying: "Hey if you disable all security features, then this app is useless and you can do everything". Which is why most of the arguments are bad.

[@seraphina985]

@@iWhacko Hell it doesn't even need to be patched in many cases. The simple fact is that some people have a genuine use for root on their devices and apps that blindly assume that is a problem causes them issues. The inevitable result is that modern root apps often must include features to selectively hide themselves from apps that do this.

[@mohdamrirazlan7879]

Totally agree with you.

[@zglozman]

Excellent and 💯 correct

[@RandomNullpointer]

I agree with this discussion, and the unnecessary FUD. However, one thing still troubles me: what is the possibility of a bad app screen-capturing sensitive data?

[@draracel]

Disclaimer: I’m that guy who gave the talk at 33c3. The N26 talk presented a thorough evaluation of the N26 security system and we think that it was valid to describe it as pretty insecure, particularly when compared to established (German) banks. You might rate it as an exaggeration to call those vulnerabilities severe but I don’t think we have been deceptive here. Furthermore, it is important to us that we also regard the missing certificate pinning the least significant security issue. The talks organization also reflects this as the part about certificate pinning is in the beginning of the talk and only lasts for 2.5 minutes. The rest of the presentation was about a bunch of other security issues that were-again, in our opinion-far worse and deserved to be described as ‘severe’. Most importantly, we never claimed that the missing certificate pinning could be abused to completely takeover an account. This, however, is what this video constantly suggests.

[@LiveOverflow]

Hey! Thank you very much for commenting! I do agree that the paper does contain good points which I mentioned a few times in the video. For example the unpairing link leak is beautiful. But which were the far worse issues you refer to that didn't rely on some kind of MITM (or other attacks like phishing, password reuse, ...)? I was mainly focusing the video on the big claims of full account takeover and transaction manipulation - which both require MITM (MasterCard ID from transactions and/or access token) according to your paper.

[@draracel]

The transaction manipulation attack was realized using a MitM attack, that’s correct. The account takeover required two steps: 1) the login credentials, and 2) the paired phone. For the purpose of 1, of course, it is possible to intercept the login credentials using MitM but we instead motivated a spear phishing attack during the talk. This is also described in Section 4.2 in the paper. Regarding 2: It is not necessary to use MitM in any way to obtain any of the required values. Please refer to Section 3.3.4 for further details.

[@LiveOverflow]

Yeah. And I don't think phishing counts as a vulnerability of the app. It's absolutely a valid attack path you have outlined, but I disagree with it being a "severe vulnerability" of the app. My understanding was that for unpairing you need the MasterCard ID (which you can either get from MITM, physical access to the card - not a vuln from the app), or having the login credentials (which require MITM or phishing - not a vuln from the app).

[@LiveOverflow]

I think there should be a stronger distinction between "vulnerabilities" and "defense". If you can harden N26 banking apps with certificate pinning AND a 2fa that prevents attackers from using phished credentials, then that is great. And criticising or encouraging N26 to implement more of these defenses is great. However I don't want those to be mixed together with direct "vulnerabilities". (I'm still trying to wrap my mind around this and try to formulate better what I just intuitively feel)

[@matejvolf5559]

May 2020 here. I still agree!

[@tobiasfellmann7692]

This research should be first inform the bank and try to work together. As you said mobile apps are easier secured than a pc. I don't have much experiance, but i think there are some big security risks still in open wlans or rouge hotspots. From there you should be able to influence dns on most devices. Still, we come a long way from 2008 without https or previous where banking was mostly trust. You have some great videos!

[@samfoxman7046]

iOS is pretty vulnerable too, there was even an in-browser _javascript_ jailbreak for ios 9, and almost all version iOS 1-11.1.2 are jailbreakable

[@ndm13]

So the gist of it is that many of the security issues represented as dangers to apps are actually web vulnerabilities, and that those that aren't typically assume a level of compromise where the app's security isn't the biggest worry (e.g. full MITM, root privileges, or similar invasion)? If that's where we are in terms of app security, I'm more than satisfied.

[@ahsan-li7sh]

Thank you for great video

[@UmbraAtrox_]

2020 still agree with your video

[@berndeckenfels]

Good summary, still you oppinion? :). Btw I do agree with your analysis, however the pinning defense in depth is such a easy and common best practice that it can be called a vuln if not used (given the state of PKI)

[@shinmai]

I know this is an old video, so it's understandable, but it *is* sort of funny that a big chunk of the video is "*thing that has happened in the wild since*? How realistic is that?!"

[@OussamaAmri]

Hi, apps who uses certificate pinning are independent from local CA verification, So an app with certificate pinning only verify with the certificate built in the app. So I think this is a big issue for a banking app .

[@LiveOverflow]

What about what I said in the video about banking websites? Paypal doesn't use public key pinning on the web? Is that not a big issue?

[@MTRNord]

So I am not sure if I get a awnser but I still ask: what about security of instant Apps or pwa Apps? Are the less or as secure as normal Apps? As instant Apps are more easy to get users to install. Pwa obviously depends highly on Bugs in Chrome Android as that's where thoose run.

[@TheSharkasmCrew]

What resources do you recommend for learning best practices when it comes to doing app audits?

[@LiveOverflow]

just do it

[@typedeaf]

Was the N26 app exploited or was a POC provided that could exploit? If not, then this was all conjecture and not really worth attention.

[@trlg2975]

Ishu

[@charlesbenca5357]

I am far in the futur !

[@IDCMI]

The main point of the paper is that mobile apps are worse than proper second factors. Mobile banking apps are a step back.

[@LiveOverflow]

which is a perfectly valid point! But it doesn't warrant "completely taking over account, transparently modify transactions" and "severe vulnerabilities".

[@IDCMI]

LiveOverflow There were quite a few severe vulnerabilities presented in the talk, however I agree the lack of certificate pinning is not one of them. I would, however, argue, that certificate pinning hardens the transport security in apps against certain attacks and is easily implemented. The reason cert pinning in the browser is going away is mainly due to the fact that admins were messing it up, causing denial of service for users by accident...

[@agowa338]

This is intentional and the (at least some) banks know about that. I talked to some people that took part in the discussion internally at a bank. They rated the risk lower than the changes of getting new customers and make more money. Also it should be noted, that at least in Germany the user is protected from that risks, as the bank has to "restore the bank account to the state before the fraud happened". The shift in liability happens on for example if the user uses optical tan, as it can be assumed that this authentication method is secure and that only the user could have made the transaction (until a security hole in that technology is found). So from a users perspective at least in Germany you don't have to care at all. If the bank would do everything in plain text over http the worst that could happen to you as a user is 1 someone knows your banking history 2. someone could make "temporary" (at least for the user, possible not for the bank) payments 3. you have to inform your bank about the fraud 4. maybe go to police in combination to 3.

[@SongsAboutHappiness]

You mentioned sandboxes. What about things like cryptolok/MorphAES. Really been interested in this stuff since my class is moving kind of slow. Thanks love your vids!

[@LucianC137]

Make a video on exploiting broadcast receivers of an app...

[@joveaaron-real]

Put the intro at 2x and you'll like it more :3

[@youdonotknowmyname9663]

Funny, I got an N26 add before the video ...

[@g0w1h4m]

I had the same reaction @15:00 WHY TF they are clapping?

[@bschlueter]

It would be interesting to see how to save and decrypt the Snapchat photos.

[@bschlueter]

Gigabyte1337 Not that easy to read smali code

[@LiveOverflow]

„Not easy“ does not mean „impossible“ ;)

[@emilhozan71]

@@bschlueter You're right here, but you can use JADX or other tools

[@carljustinemosquida9614]

Where to start in mobile app sec?

[@canyildiz8483]

Please do not use SSL anymore it is deprecated since 2015, TLS is the only acceptable wording.

[@LiEnby]

i really dislike the sandboxing approach to android because i like being able to access everything but google has a solution to this which is rooting. . but then it trys to detect root so you have to disable the root detections

[@therenaissance8322]

Just be a little more dramatic and a thunderf00t style video will appear.... lol

[@TheGrimravager]

gonna be really honest here, I am majoring in theoretical physics, I am considered pretty smart by my friends in terms of understanding technology.. I know how to program and I've just rooted my phone for the first time. I found it very difficult (but a very cool experience, learned a ton of stuff :D) If I am dumb enough to allow some malicious process to run on my phone as superuser, I deserve every consequence of that

[@ko-Daegu]

TheGrimravager And why are you writing that ... You are smart maybe in physics but plz leave sec field

[@TheGrimravager]

no you leave why are you writing this?

[@ko-Daegu]

TheGrimravager “No You leave “ Shows you totally didn’t get the point... Go back and read your comment again ...

[@TheGrimravager]

no I won't, you're just some guy on the internet

[@unarei]

> I didn't need to touch the device is that not something he said? pretty sure he said that he didn't have to install his own certificate on the device

[@amirroohi4566]

Is there a chance of seeing you do some c# tutorials, i really enjoy c# Console Application and Windows Form Application, there are so great and fun to write, please please any c# tutorials

[@LiveOverflow]

I have not much Windows and C# experience. So it's fairly unlikely :S

[@amirroohi4566]

well just wanted to say thank you for responding so quickly, but still thanks, i will continue watching ur videos, but is there any chance of seeing the very basics of c and python, so that i can follow ur videos better

[@nuffin2hide855]

There are more than enough sources out there already, just not on this channel.

[@tthtlc]

in 18:48, you mentioned HTTP u can MITM, but HTTPS (using SSL) u can't? yes, u cannot if u are using a legitimate DNS server, but i thought you mentioned the DNS was hijacked? so assuming the DNS is hijacked, then MITM using self-signed SSL can be used on the SSL. During SSL communication you can also traced that /etc/hosts is read - so if you hardcoded the IP address of the domain name there, you can always redirect the SSL communication into your own self-signed cert.

[@hikkamorii]

not really, you need a certificate that is issued by a CA, and if you in any way change DNS server to the one you control, and redirect requests to your website, you’ll either have to use self-signed certificate, which won’t work since your CA is not trusted, or you need to ask a real CA for a certificate, which they won’t give to you because you don’t own the domain.

[@Herblore7]

@4:28 why do you need to write native code for obfuscation and to protect against reverse engineering?

[@kangjiahuang9928]

[Actually saw this on Reddit] Allow "Calendar" to access your Calendar?

[@dazoedave]

I'm pretty sure he said he didn't have to install a CA on the client.

[@vurpo7080]

Without installing a root certificate on the client, none of the attacks mentioned are possible. Except for DNS hijacking, of course, but that's a theoretical attack that can't be done if the target server admins manage their DNS correctly (which so far, they have done).

[@kaotiskhund]

What's the purpose of this?! 🤣🤣🤣

[@smoov22_sonic]

try something like /r/changemyview

[@olaola-yh5ge]

Future here, do you still hold to that believe @liveoverflow