 Move to the center of the row make sure that you get every single seat filled We want to make sure that we have enough room for everybody to get in We want to make sure that everybody gets a seat get close get friendly. This is Defcon make friends Are some of the things that I wish I could be telling you right now unfortunately Yeah, we can't I'm here and you guys are where you're at respectively so With that said we forge on and the second year of the apsec village continues on for this talk we've got Pedro umberlino and Joao Morris to talk about bug foraging in Android Pedro is a security researcher by day and a hack-a-day contributor by night He messes around with computers started on the spectrum. He's been through the bulletin board age He's draw been there for the drop of the internet and still roams around on IRC He's known on the internet by his handle Crippthor and he likes all sorts of hacks Joao is a penetration tester and researcher that started with the blue team Later was attracted to the red side of the force Although there's more Focused in application security. He's learned all sorts of attack factors So if you would take some time Sit back enjoy the talk and help me in welcoming these two fantastic presenters Hello and welcome to the Android bug foraging session It's great to be here at Defconn safe mode apsec village giving this talk despite everything that's happening It's really good to see the community coming together and make sure this kind of events still happen My name is Pedro Blino. I'm a senior security researcher at checkmaster security research team I'm also security researcher at chair 49. Sometimes I write for hackaday One of my hobbies is to make hardware and my daytime job is to break software I'm giving this talk with a friend of mine and colleague Thank you, Pedro. Hello everyone. Thanks for joining us here today. My name is João Moraes I'm a penetration tester team lead for a multinational company I also do pen testing and security research for other companies I'm part of the check marks and share 49 security research team So my background is very wide. I did many different things over the years always related to security though But in the last years I've been more focused in application security and mobile security Which is exactly what brought here today for you So yeah, and we'll hand over the mic to Peter now so that you can talk to you a little bit about this bug foraging concepts Thanks, João. So foraging foraging the act of identifying and gathering wild food in nature Bug foraging is like kind of the same But you're not in nature with you're in the Android ecosystem You're not hunting bugs to eat but you eat because you hunt bugs. So yeah, it's not the same But you know, you get the idea So our motivation to do this talk We wanted to instead of having like a theoretical approach and you know shared back practices in Android development and so forth We wanted to share our real-life Examples of vulnerabilities that we found in our analysis. We wanted to share with you our process of approaching and devising meaningful attack scenarios and proof of concepts and In a nutshell the overall experience that that you we have from first crash Until disclosure process and for that we are going to to use for different Examples of vulnerabilities in different and for different apps that that we found Some of them are from our older work and some of them are going to be disclosed here first-hand So as long as going to talk a bit about which one the wheels we are going to talk about so as well Thank you, Pedro. I'm moving on to the agenda. We'll go and present to you four cases Starting with Tinder the app X which is an app that we cannot say its real name Google camera and some song find my mobile the two really well-known apps in the Android world and then final words main key takeaways from this back for aging experience Moving on to case one the Tinder application. This is a very well-known application That allows you to meet people and chat with them The only basic knowledge you need to have about this application is that it will show you pictures of people And you can swipe left or swipe right and you'll actually be saying that you like them or dislike them And if they like you back, you'll have a match and then you can chat with them using the application Well, so let's start with what we did We started by sniffing and collecting the traffic and we could see a lot of HTTP going on HTTP would allow us immediately to know that a certain IP and MAC address was Using the application and also allow those to know more to allow those to match Images with user IDs because you can see they're in green That is actually the user ID that is shown in the URL Also, the image resolution is present You can see in yellow and we'll allow it to know if that image belongs to the user of the app or Someone who's the victim let's call it victim is chatting with And also allows you to see other users so they are in the discovery So other users that are being suggested to you for you to like or dislike them So now we have a good visibility a good invasion of privacy But going a little bit deeper we can see that in the HTTPS replies from the API That's why you see the 243 port in the source That's actually the reply from the API and you can see that the size of the payload is very different And that changes accordingly to the actions of the user So we could do a direct match between the actions of the user and the size of the payload of course We put more 10 or 20 bytes in our parser But it was around two seven eight for a nope three seven four for a like and five eight one for a match So now we could put all of this together and we ended up with this application the tinder drift Which is based or inspired in the drift net and if you have a Man in the middle attack going on or if you have some sort of access to the traffic in your network You could easily identify users of the tinder application. They're my cadres and IP You could see all the pictures you can see their picture on the top left You can see in the center the pictures of users that are being suggested So they are being shown in his device and also his actions the notes the likes and the matches We also put some traffic down below for debugging purposes But you can see this working now in this quick video This video is the tinder drift software demo Tinder drift was inspired by drift net and it's a software that passively analyzes network traffic and is able to identify in profile Tinder app clients So let's start the tinder drift for the demo. This is the app right here It receives Pickup file it can be a live pick up and it still analyzes it so On our mobile phone We are starting tinder and After a while you can see that you already detected that which image am I seeing? so tinder drift takes advantage of the fact that The tinder app fetches profile images via non encrypted HTTP connection and it associates that image Or those images to a client after that It analyzes the HTTPS encrypted connections from the client to the tinder API server and Infers the behavior of the client by the size of the server responses to that request So when the user swipes left or right The app sends a request to the API server the reply pike at size can be used to determine Which kind of action did the user took if it's a like didn't like or Even if it's a like and it's a match or if it's a super like So you can see that it takes sometimes to stabilize and after After that the software is able to identify Which action user took for example, let's like this profile When it's like you can see here in this corner that the image was Properly identified as a like and if it's a no like it's a nope. So let's like this also so and You can see that the app updates The software also supports multiple clients for example, let's switch to an iPhone Corporate response was quite fast But they didn't consider this a big deal in the beginning this ended up in the news Massive media storm came that culminated with the US senator Saying publicly that tinder was vulnerable and of course that led to a very quick fix and that was very positive There was no bounty because at the time as far as I recall there was no bug bounty program Let's move on to case 2 the app X This is not really its name It's just a name we made up because we are not allowed to say its name legally we can't do it But that won't be relevant For explaining the vulnerabilities So let's move on Starting with what we did we started by listing activities that could be used by other applications And we found out that the main activity can actually load a malicious URL and that's because there is some link validation but it's not Very strong. I mean you can see the reg X down there if you have a slash a hell hell character and the slash Your father your link is valid And it will be loaded by the web view So you'll end up with something like this if you have an attacking application It can create an intent that will then open the app X Which will then load your malicious content in the web view we tested that with the activity manager using ADP and it works So we did actually create an attacking application and we did as well create An HTML page Which was exactly the same as the original login page for the app So a user would not Be able to distinguish between the original web page for logging in and our malicious page for logging in and we could steal the Credentials and the application would still work smoothly We tried to leverage these findings We looked for other things and we found several JavaScript interfaces as you know a JavaScript Interfaces an export of a native Java function and allows the JavaScript in your web view to use it And this particular set base URL's function allows you to change the URL of the API And we can replace it with our own URL And when you do that this change is permanent your application will contact our malicious API Instead of the original API The app has certificate pinning and it works well, but it also supports plain HTTP So we can actually use an HTTP URL and the same with the official API that works either in HTTPS or plain HTTP So this was the perfect scenario for a man in the middle attack although We still need to trick the victim into install a malicious app So we tried to go deeper we saw there were some deep links for this app Let's consider this scheme. Of course, it's not the real scheme the app X just for clarity and There is a messaging system in the application. So we were trying to think of a way to send a link in Which we could exploit this exactly in the same way, but without requiring requiring a malicious application So the chat feature doesn't support deep links, but it supports regular web links and We could actually send a regular web link The browser would open it we could redirect to a deep link to the app X schema But how would we pass the parameter then to the main activity? I mean the main activity would open But it would use the default HTML content and we wanted to be able to pass it our malicious URL So we ended up with something like this This is the full chain of events you can see down there the full URI for the exploit The app X will open the application and the AF underscore DP parameter will allow us to inject That HTML in the web view, but let's start from the beginning So we don't need a malicious application anymore. We just need a message and We'll send a message with the web link as soon as the user opens the link Google Chrome is called It will request a malicious page to our server and our server will redirect to that full URI that you see down there So then the Android knows that app X scheme It will open the app X application and the app X application will load our HTTP attacking dot side comm of course, that's a fake domain just for demonstration purposes You can see the slash L slash so that it will pass the validation And this will work We have the full exploit just like we did before but without requiring a malicious application Now the AF underscore DP parameter is Something that we found by a reverse engineering and you can see there its content will be loaded in the web view So summing this up When the victim clicks in the link the attacker can steal its cookies impersonate So take over account Monitor all the application Activity read private messages. You can track the victim to its geographic location because the app has this feature and It can also create a wormable exploit Well, where all the contacts will receive a malicious link and by each contact that presses on the link It will send it to all the contacts of that Contact and so on and so on So becoming a sort of a wormable exploit and Consider that the application will always behave normally to the victim's eyes. So you won't know is actually being act I was going to show you a quick video demonstrating, but there was some Crash on our BLC players. So I'll just move on to the corporate response So the response was good. It was fast. It was classified as a critical issue. It was fixed There was no bounty because I think there was no bug bounty program at the time, but There was some legal issues. This wasn't good and we could avoid this, but we'll talk about this in the final words Section and now I'll hand over to Pedro so that he'll talk to you about the Google camera application Peter Thanks, so now we are going to look into case number three, which is the Google camera The Google camera app comes installing millions of different devices and this was research that comes in the context of an audit to the pixel tree sometimes instead of looking into a Specific application we just choose a vendor and by the latest phone and start to look into the pre-installed applications that come Since this implies a bigger attack surface and more users that could be at risk And in this case, we were focusing on the Google camera app now The the process is kind of the same when you do Android reversing for a while you just you list the activities and Broadcast receivers and so forth that you can call without permissions you reverse the APK You analyze the traffic you start reading the code. So In this case, there was a lot of exported activities and defined actions inside the Google camera app now We started to test the behavior of these activities and actions and look for interesting stuff because sometimes it is It's easier just to start and test the behavior of the application Instead of reading tons of reversed code Sometimes also skated so we noticed that there's this action called video camera that starts the Google camera app And immediately starts recording and we found that Interesting because there is also this action video capture that does not start recording So why were there two different ones? Any other action would open the Google camera on in photo mode But does not take a picture. So we are looking like the attack scenario here is a rogue application That's trying to control the Google camera application so We map out which classes handle which intense and which actions and then you start to read the code and Try to figure out if there's any extras or data or actions that you can Pass to the program and to the application and modifies the execution Or the behavior, right? So we noticed at least three interesting extras one is called the use front camera which allows us to the controller app to choose if The Google camera is going to use the front camera or the back camera There was this duration seconds which allows the camera to start a timer before before taking a picture and this Obscure one call extra turn screen on which essentially does what it what it says it does it turns the screen on now Why was this interesting? Because the timer duration seconds for example starts the Google camera app and also starts the timer So you could you could take video without user interaction And now we figure out the way to take a photo without user interaction if you use a timer the minimum default timer is Three seconds. It's hard coded, but still you can take photos without user interaction And the extra turn screen on was very interesting because it makes the camera app To open even if the phone is on standby or even if the smartphone is locked with a pin number So you can actually start from the background start the Google camera and take a picture and record the video now Why is this interesting because usually? The videos and photos are stored on in the SD card and the SD card As you know, it's easily accessible by other applications that have the read external storage permission So we started to think how can we leverage this in a meaningful attack scenario, right? so and we devised With this combination now you can make a road have you know take a picture record the video without user interaction even if the phone is locked and The big problem here is that This rogue app does not need permissions does not need camera permissions. It just abuses the Google camera app to take these actions for himself so We we devised a POC called Spixel It's a client server active architecture like the client is a rogue weather app It only needs the readers external storage permissions and the internet permissions to communicate with the command and control server the command and control server is listens for every client and has a bunch of interesting features now It the command and control server can order the rogue app to take a photo or take a video from a Chosen camera it uses some stealth features that we developed to prevent that the the Google camera app is popping up Or making a sound We can mute the all the audio streams. This was actually actually another another Topic that we submitted to Google because it's not it was not supposed to be possible to mute the phone without permissions to do so And it's another bug We monitor the proximity sensor to know if the phone is upside down or not or you are on the call We devise a feature call auto record calls When you answer the phone and you put the phone next to your face, it starts recording And it's actually possible to listen conversations in both sides if exit data is on you can grab the GPS locations and Locate the user like you can issue the camera to take a photo and then parse the exit data and Grab the GPS position. This is not completely related to the vulnerability in itself, but We kind of get creative and implemented this on on the tool among other features. So Now we're going to see a demo So this demo shows the auto record feature when David answers You can see on the right side the image from the camera Superimposed and this is the attacker side when it actually receives the video and Plays it back to the attacker On the speak cell interface, so the corporate response here was Really, I think standard for Google, which is really high for everyone else So we got a medium fast response after the first report This was classified as a medium impact vulnerability Then we shared our tool and an explanation of what we did and How our tool could bypass a locked phone and then they classified as a high impact vulnerability The response from now on from then on was really really fast They contact other vendors that were identified as using the Google camera or a by-product of Google cameras and derivative. There were also other companies affected and in the end Google Granted 75 K USD bounty, which is really cool So now we reach our last case with this case number for Samsung find my mobile Now find my mobile is an application that works together with the website that Samsung account owner can use to locate his phone if it's lost It just log into the website make the phone ring and lock the phone and whatever So this was research in the context of an audit to a Samsung s8 Also looking into default install applications and try to figure out if there's some vulnerabilities there now The process is kind of the same just list the activities Try to find that some some things that are reachable by other applications without permissions Reverse the APK analyze the traffic and so forth. There was not much luck involved at first But digging a bit deeper There's some piece of code that didn't even be compiled correctly that refers to a file in the SD card called FMM prop now, this was an interesting file to know and after a reversing it was possible to understand that The program would load the mg. URL and dive URL From this file if the file existed So this location since it lives on the SD card allows a malicious application to create this file and and FMM will use it and We'll communicate with a back-end and mg server There are going to be a lot of servers in in this example So the mg server is like the management server and we can control it if we create this file and pass it URL that you want but creating this file is not enough you must force FMM to assume this file usually this happens at buddha, but It's not really interesting if you cannot control it. So This was vulnerability number one and now vulnerability number two comes from a broadcast receiver So there was this this broadcast receiver called PCW receiver that when it receives the action that Resurrection was completed It will proceed to update URLs so what what this what this means in practice is that by By ascending a message to a broadcast message to this PCW receiver FMM gets signal that the registration is completed and then it context the mg server to perform this registration again and this mg server is the URL that we already under control In vulnerability number one now this is interesting because by pointing the mg URL to an attacker control server Enforcing this registration with vulnerability number two We can get a lot of details about the user because the phone contacts our own server And then we can get the course location via via e-pay address registration ID I may there's a lot of information that comes with this registration request and so Joining these two vulnerabilities together. We can effectively found a way to a monitor a user remotely this all happens in background and The user has no way of knowing this is happening So but this is the kind of not enough. I didn't want just to monitor users. I want I want more So by analyzing the original mg server response, we can see that the response Comes with a lot of different URLs. There's like this DM server DS server OSP server I didn't get to the, you know, the bottom of all servers what they all work for and what they are for but It was nice to see that we can also control the other endpoints and this allows us to go and talk about vulnerability number three Now the vulnerability number three exists in another receiver called the SPP receiver and there's this magic action That you can see there. That's fb0bd so hexadecimal string that indicates To fmm if there was a push push message received now By sending a broadcast with this magic magic action, we can additionally add an extra with the with the push push messages There was a lot of work involved in Reversing these messages. They are all encrypted then It's kind of hard to read but luckily the key was art coded in the code and we Don't even have to understand what what are all this message for We just need to know if we can craft the proper message then we can get fmm to talk with the DM server Now while the ng server seems for registration processes and delivering reports the DM server Actually stores the actions that the user performs when he logs into the website or to the web interface Now the website You can find it in findmymobile.samsung.com has a Map and has an overlay and the user can log in and perform depending on the API level You can perform a lot of actions. You can ring the phone. You can lock the phone and leave a message Create a backup retrieve call logs and SMSes Erase all data on the phone So there's a lot of different actions that that you can make on the web interface now There are executed by the by the phone when the phone received this this messages But the phone could be offline or somewhere without network access. So It's possible for the attacker to send the broadcast to this SPP reserver that results in fmm contact this DM server and and searches for pending actions that were taken and FMM didn't have network connectivity to perform those actions now This communication uses a proprietary sync ML implementation which was a bit hard to figure out It's it's not like standard sync ML to the best of my knowledge and there's something called Md5 on this on this communication. So I assume there was some kind of authentication going on an encryption so What happens is it's when the fmm contacts the DM server the DM server can just reply with a okay or The accumulated actions that were requested and missed while the smartphone was offline and this is where you can come in because we actually Because of vulnerability number two we actually control the DM server. So we control the energy server and the DM server But to be able to perform something Like closely remotely resembling a man in the middle attack, we need a valid certificate You need to monitor the messages. You need to detect the message types change the requests on the fly And you have to bypass this sync ML out d5 mechanism at the same time to make everything works So now we are going into vulnerability number four, which is the sync out md5 Algorithm So it has nothing to do with md5 weaknesses The authentication protocol seems to be like the client connects to the server and sends a field Sync ML out md5 on the first request. I assume this is a challenge the server response With another out md5 field, which I it's only depends on the client challenge original client channels in the IMA Chasing is the response and then the client now assets all server replies from now on Why is this important? It's because there is no message signing on or any mechanism that prevents message modification Which is really great for an attacker in the man in middle position. So I You know, you don't even need to reverse the the response verification mechanism to make this work You can just man in the middle the connection and send the authentication the challenge packet to the server Grab the response send to the client and then you can just use that token and communicate Because there was you can change the content of the packet because there was no, you know message signing so Putting it all together if you put all these vulnerabilities together so With vulnerability number one you can use the fmm prop file to change the ng server to your own server Then you send a broadcast to the pcw server receiver and then You can get the ng server that has all these actions stored And force the update via a spoofed response Then you send the another message another broadcast message to the spp server receiver That actually makes fmm contact the dm server and fetches any outstanding actions You are in the middle of this connection. So you just forward back you forward the challenge Packet to the original server Grab the response and then inject your own actions in the client Since there's no message integrity here and then the smartphone can actually execute whatever message you decide for them so You know the too long didn't read version is that any application could reset reset your phone stealer messages Locked, you know look locate the user Anything that fmm supports and depending on the API level any application without permissions Accept to actually use the SD card which is one of the most common permissions You can do whatever that fmm support it work on the wide range of devices including the s7 Yes, a the s9 plus this was tested and on a lot of devices and We have a demo that we can show now So I can actually claim that I'm able to you know erased all contents of the phone without actually showing it so Here's the server configuration files I'm going to switch my action to Nook This video is a bit sketchy. I'm sorry for that. I cannot record the the mobile phone Screen at the same time So Here's the Samsung s8 Don't walk it. I'm going to start the POC and over here. I'm I'm telling the logs of the rogue server So I'm going to do the exploit step-by-step This is the first step which changes the fmm prop This is the second step as you can see here You can already Watch that the rogue server receives the register requests So the URL endpoints now should already be taken over here and now when I'm going to do step 3 it's fmm is going to contact the The sync server the dm server and but it's already spoofed So the reply would be will be a nook and You can see it happened in real time here and Kabam bye-bye so It's the same thing that happened on the other video, but the action is actually different The action is is the erase so the phone gets erased also the SD card Is formatted so all that in the in this phone is lost That's it here you can see the different steps here so There we're here. There's a step one Then you get this is where the authentication gets Stolen from from the server there will reply to the to the phone it is injected with With To be wiped it's hard to see here, but so we're here to be wiped and then a series of steps that are needed to actually make the phone Erased So working with Samsung in the Samsung bounty program. They are very organized and they were they Issued a fast fast response after the first report. This was classified as a high impact vulnerability and then we realized we realized there was a lot more into it that this this kind of Behavior affects many different parts from the application of part The web server part there are some things that needed to change it took some time until they could issue a proper fix and They granted the 10k usd bounty and in addition There were some closely related critical for flaws that are not in the scope of this talk It's not that application side So it was added a 25k usd bonus. So in the end it was very very nice So this concludes our presentation We try to give you a variety of examples of real Applications that faced different problems like the lack of encryption Problems in the web views legacy code Intents without permissions. These are all different issues that sometimes are common to other Applications or some of them are very Android specific Before we go we'd like to just say some some words We really believe that we're trying to make the world just a slightly better place by you know Identifying these vulnerabilities making people overall a bit more safe while while being online Luckily we we are paid for this research and we're not depending on bounties, but of course they are always appreciated It's interesting to note that the vulnerability complexity does not you know equal having a greater impact or More rewards sometimes you spend a lot of time trying to develop a POC or a working POC and On a very complex issue other times you just find a very simple bug that has a lot of impact and Does you can usually get a higher reward if you are in it for the bounties and The final word is that We are really a friend. We are not the enemy. We are trying to help Companies making a better product sometimes products that we actually use and we have a complete interest in making the product better and you know threads and lawyers are Legal suits are really not necessary. We are We are we think of ourselves as friends and we are not trying to to hurt the company's image or whatever in any way so I think now we are going to be open for questions if anyone wants to ask something. Thank you