Hey all! As you can see the video is still in the old style. In fact the video was prepared quite a while ago, but I was only able to publish it now. I hope you enjoy it regardless, because I think Sergey's story is super fascinating, and the bug he shows us is probably the coolest Android app bug.
To be fair, the problem is not really in Snapseed, but in the Android API. It shouldn't be possible to grant permissions to another app just by setting a result Intent. Instead, you should have to use an explicit API call to grant permissions. Otherwise, each app would have to scan for malicious data inside an Intent it wants to return to the sender.
Perhaps not, because any other app can create new intent filled with the data it wants to return it to the sender which doesn't copy the malicious flags from the sender. Also as a new intent is created, it doesn't copy everything blindly and also, there is no way of _accidentally_ setting malicious flags PS: I am not a bug hunter by any means and this information could be inaccurate ( please be sure to correct me if that happens! )
^ Tell me you hadn't made an Android app with Intents without telling me you didn't. The Intent was mishandled by Snapseed. So many wrong things have to happen for that vulnerability to even be possible and Snapseed happened to check them all. You shouldn't pass around raw Intents without some form of check as it's like passing around passwords
@@cryingwater This is not what I was trying to say. Yes, there was that bug in Snapseed. But had it not been for the bad API, this bug would not have been possible from the start. Also, yes, I have been developing native Android applications.
I'm not a bug hunter by all means, I'm jhus a 3rd year CS student, but I found the video very very, interesting, I love the way you explained the concepts, I don't know java but I was following along and it was definitely very interesting, thanks man, keep up the good work
this intent reflection thing is quite surprising and I can see why many programmers would accidentally do it. unless google changes the API somehow I can see how sergey will laugh to the bank forever with this tool.
As a mobile app developer, I am looking forward to seeing more bug reports for more and more apps and hopefully seeing them get patched. Also, I may be slightly concerned.
Franhofer institute (I'm butchering the spelling) built a framework for Code property analysis around the 2014s. While it was great for Java applications, it was very hit or miss for Android, usually it treated intents and other Android components as sinks. Glad to see that framework has adapted for Android
I've seen tons of apps that have their onesignal api's exposed and yes it is usable, its like they don't even try hiding it... for those who don't know onesignal is what you use to send out notifications.
Does anybody know where i could ask entry level webdev exploit questions? I have been googling myself for 2 days, reading research papers, docs and forum posts about indexedDB, WebGL and watched some defcon videos, but i seem to be stuck. Sadly theres no liveoverflow discord.
That's interesting, that an app can fake permission from another app. Isn't the security model of android apps flawed in this case? I mean, if the original app didn't have permissions, why can it appropriate it from another? Shouldn't the OS check for it? I mean, it knows that the malicious app is trying to read files, right!
The security model is basically "App X is trusted to make decisions about accessing something". And in this case, the Google app is giving access without any check or verification.
No, the original app has permissions. In this case the user has granted Snapseed the permission to read files. Snapseed is then sending the contents of the files to the attacker app. The attacker app still doesn't have permission to access the filesystem, but can use Snapseed as a middleman to read the files for it.
intent also confuse me a lot when im studying android, i always taught to myself intent means "my intention to *" - intention to start activity - intention to share *
"some researchers submit without looking at them" I see you, CVE-2023-34585. a guy reported a "passwords stored in plaintext in OBS" because there was an ini file containing the string "password"... it is the localisation file.
the thumbnail is literally one of the first frames of the video + the actual exploit developed in the video. How is that clickbait :D it's an extremely accurate thumbnail.
Damn, that oversecured site tried to charge me $500+ to scan a single apk. Are there any open source alternatives to this or do I have to find exploits off the muscle if im not already rolling in bounty cash?
This feels more like an Android defect instead of something the App developer should worry about. A malicious company can intentionally create app A(snapseed) and B(attack app) then makes user think it's respecting privacy by not acquiring in B but in A. Someone should report this to Android Core devs.
Wow, you're right. WDYT would be a good defense for this? They can't cross-scan the whole playstore. Maybe introducing a new app permission for granting permissions to other apps? Or a system dialog that monitors all cross-app traffic and intercepts suspicious intents?
@@D1ndo There is no issue here, app A cannot grant app B a permission that app A wasn't already granted by the user. If an attacker already controls app A, then they don't need app B. Accessing the internet already requires no permission, so if you have access to the filesystem in app A, you can already send it all away to your server, no need for a second app. And if as a user you trusted app A with access to the filesystem, then you are already lost if it's malicious, again, no need for app B.
Wow, that actually makes a lot of sense. This means that Android also needs the permission of the user to allow the app to give access to its content to other apps even if the app agreed to. This will simply block the app from allowing other apps to get access to its content even if it accepts to, but the user does not. It is like asking your mum(the app in this case) if you can go out on a data with this girl she met, she says yes, but your dad(the user in this case) says no. Therefore you do not get to go on a data with the girl. 😂
I disagree on 9:30....it is still vulnerable code, the impact is just very very low to not existant. Why should debug code be in the app in the first place? If it is never reached, why is it there? Can it be reached in the future? It still IS a vulnerability, but not exploitable at the moment.
If you can reach it, it becomes a vulnerability. If you cannot reach it, it’s not a vulnerability. Simple ;) It might be risky, and maybe it’s a not a good idea to write code like that, but it’s imo clearly not a vulnerability.
@@LiveOverflow it still should be fixed and for my understanding, still at least an informational issue in every report. (should be at least). i still stand with the idea: if i can't find the path to reach it, maybe i didn't search long enough, maybe i missed something. If you can't find a path to it, yes, impact=0, which makes it an informational. And it still should be reported ;)
@@Z3rgatul Proguard and other android compilation tools already do this. It's basically just dead code analysis during minification. It has nothing to do with java.
@@WarNinGXK exactly. Disassembling/recompiling is not possible anymore. Actually it is, but the code is scrambled and not really usable as it was before
Год назад
wrong! it will be not as easily as java/kotlin but it will still be possible, in the same that other languages that output to binary are susceptible to those types of analysis
Год назад
It big flutter apps become valuable targets for bug exploitation, the tooling will improve and less manual work will be required
