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.
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
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.
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.
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
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.
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.
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. 😂
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.
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.
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.
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.
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 *
@@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
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.
"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.
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.
were you waiting for google to fix this class of bugs before your audience got any funny ideas?
@@landyn436 ye i have same question please liveoverflow answer :D
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
Lmfao 3rd year
You are a spaniard midnightrunner
@@Snail641 huh, you good?
I've started looking into mobile bug hunting yesterday and today I wake up to this notification. I guess it's a good sign
It was the ghost of Steve Jobs.
Go go
Not luck but Google trackers😂 they know everything.
Thank the google trackers lol
So how it's going
One of my favorite videos you've produced. Thank you Sergey too
As a android developer, THIS IS GREAT! thank you for this content !
This video brings up so much value. Thank you both!
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.
I am noob in android development (only tried developing 2-3 single apps for myself), but I had the same thoughts while watching this video
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.
Thank you for putting in the work to make everything as clear as possibile. This is really valuable. Great job!
Learned quite a bit from this video. Hope some people have success in their endevours ❤
I have a list of dozens of apps that include hard coded API keys, you wouldn't believe how many app developers just don't care.
Or are newbies? Or it's from big apps?
@@WarNinGXK Big apps that have official bug bounty programs. Rejecting reports because they don't care if their API keys get abused.
The current version of Google Authenticator does for example🤔 (look at the results on oversecured)
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.
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
It's "Fraunhofer" :)
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.
Really interesting to watch!! I enjoyed your detailed explanation! Thank you so much❤
Sergei is a well known person in russian speaking infosec community. It’s great to see him here.
Thank you for a great video
I hope he doesn't support war as many russians do
I love watching your videos and I've learned a lot from them. I work with Android security and this one is making the rounds :D
What the hell!
The comment was year ago!!
yeah wtf , u time traveler or something bro?
I guess video was unlisted?
Wait, how is your comment from one year ago? 🧐
This is crazy
You timetraveler
I was waiting for it 🎉
Thank you.
Nice explanation! Looking forward to more Android security videos!
I wish your Intent as our ContentProvider would be to make more videos on Android.
Dang, I use Snapseed almost daily. So easy for quick edits on amateur shots, since it supports RAW format.
😂😅
Your Mona Lisa drawing was way way better than most could do 😂
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.
Amazing video, very well explained. Thanks a lot!
I can tell this guy loves to say the name sergey
Great video!!! Please, make more videos about mobile app security.
I subscribed to you because of this video just want to let you know Happy hunting
sounds like a great ctf idea
So, I believe this is why Android added the functionality where it asks you if the app can share your data
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. 😂
Which version which feature?
great breakdown
I used snapseed occasionally. Interesting!
Why does it say "advertisement" in the upper right. Is this whole video actually just a commercial for the tool?
It's an advertisement for Google's Bug Bounty program, he says so at the beginning.
Why is this video hidden in your channel page?
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.
8:36. What is happening there? Why the question marks?
Great Video
Are there any such tools to scan the source code of opensource apps or repos? Something like github copilot x but for finding bugs & malicious code
sonarqube
Any other resources for learning Android security?
cool, I am an android developer, and this video just blow my mind
More Android videos, PLEASE!
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?
But how did Sergey get the complete source code from the apk? Since the app was developed by google, I believe it must have some sort of obfuscation.
as you can see from jadx, the code is obfuscated
I hope you give us some resources to learn ❤
What Udemy courses do you guys recommend for Android development?
No udemy course. Just official android developer documentation
android pentesting blackbelt edition course will help you understand and find all the android vulnerabilities
bruh ed Sheeran is so talented. He even knows how to hack
Lol😂
THIS IS SO COOL
if you are german
cooles video!
Thanks bro
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.
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.
Continue 6:00
Basically G is paying us to label the output of the tool for them 🤔
bwoah, 500 USD per apk scanned. That's a bit too $$$ for me, but I love concept.
I hope to meet u someday will hug you and never let go
Yo Live, i made a minecraft server scanner. But it only spits out 52 ips? It scans ALL the hetzner ranges. Can you help?
rate limiting by hetzner? wrong port? (is mine in it xD (no i wount tell the ip))
@@schwingedeshaehers the port is 25565
send your code, we can't help you if there's no way to find the issue
@@undefinedchannel9916 im gonna send on discord. if thats ok for you=? google aint letting me put hastebin links
@@zvanmilisavljevic8879 okay for me (DC is in may channel description)
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.
Because java is not C/C++, it doesn't support conditional compilation symbols
@@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.
Ayo pls create a public discord server and pls explain about the bungee exploit(also know as uuid spoofing) in minecraft.
Sounds like an advert for a get rich scheme...
I'm shocked.
Android bugs are the best ❤ scrapping so many apps through bugs 😂
Right, right. Totally a "coincidence"
Push!
Woo motivation
I love how the rewards are multiples of 1337 (LEET) 😂
that man is rich
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 *
Cloud bug hunting
at the of the day you're just helping criminals to mantain their monopoly and control over you, im not talking about hackers...
Meanwhile flutter dart is slowly replacing Kotlin/java. Bug hunting will not be possible (or at least almost) anymore.
Because of flutter dart?
@@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
@ "or at least almost".
It's easier to disassemble a compicated c++ library than disassembling a flutter dart compiled app.
Please make a threads account!
I live in EU
@@LiveOverflow vpn
take a look at how much data threads collects on you
Downvote for "how this looks like".
You beleave russian?Fake job.
$1337 Rewards --> cool :D
I like your videos, but really can't stand the clickbait thumbnails and titles. I really don't want to but I have to unsub, I can't anymore.
what exactly was clickbaity about this video?
u are free to leave. -1
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.
"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.
I googled it, read it, and I can't believe this happened in 2023 and not like 2018....
It gets even better. There is CVE-2023-36262 published 2 weeks ago and it's a duplicate of CVE-2023-34585, which at the time was already withdrawn.
Hey bro Goodmorning, if possible u can hack this application vip pack , ChatGum
U can't guy's because This app soo secure