Exploiting Common iOS Apps’ Vulnerabilities

so good morning and welcome so almost exactly a year ago on november 14th of last year i submitted a vulnerability to a company that had a crypto wallet they had embedded uh some user credentials in their mobile application and with this an attacker will be able to log it into a third-party service and um query their database and anyone who download this application could just reuse these credentials and log in as them they awarded i don't know if you can see that but they were like two thousand dollars for this and they invited me to their private program where they would pass me their application before it would hit the app store so that i can check them beforehand um and with this since then i i started doing this in a daily basis i was i was checking different applications there are a bunch of application a bunch of companies that provide a public blog pantry where they tell you okay here's my mobile application please just check it and if you find something we're going to pay you money for it and during this year i found that many many apps are i'm making the same mistakes over and over so i found the same vulnerabilities in very different applications and we're going to talk about four of them i wish we could talk about more but it's going to take a long time and this is how the journey started uh so a little bit of disclaimer all that i talked about here are it's my opinion it's my views and they do not reflect those of my employer right center stuff to who i am my name is ivan rodriguez i'm a software engineer and security researcher i specialize in mobile applications and specifically on ios and that is because i was an ios developer for a long time and then i moved into security because it was a space that was it's not crowded there's not many people doing this and it was interesting to earn money because of that um i i do a lot of research around mobile applications like i said ios and i publish most of my research on my blog which is ibeatboringus.com so you can check out their different topics there are different different researches that i've done in the past so you can check the blog post there i also tweet a lot about this so you can find me on twitter at the rodrigo ca i retweet a lot of accounts that i have to do anything with security on mobile applications that's for both ios and android but i tweet a lot about that and finally during my version here i found that there are some steps they can automate so if i feel comfortable with sharing some very bad code i publish them on github you can also check my my repos over there and sometimes you can get some scripts that will help you automate some of the things for reverse engineering ios apps and today we're going to talk a little bit about reversion and it's a very high level because that could be a talk on its own so a very high level how do we decrypt ios apps and how do we transfer them to our computer so we're going to see some tools to do that and then finally we're going to see four different vulnerabilities that are very common in in many many applications and we're going to see some like prevention and techniques and how to fix them if you already have them on your application uh and finally some resources about this if you're interested in learning more and experiencing this by yourself you can just check them and hopefully we answer some questions okay so let's start with reverse engineering um not many people know but when you download an app from the app store that app is encrypted so it's not plain text on your phone and so the first step we have to do is we need to decrypt that ios app and apple uses a protocol that is called or an algorithm that is called fairplay which was introduced with itunes when back in the day when action was introduced you were able to download songs instead of buying cds and apple needed a way to protect the songs so that you will not download them and redistribute them and so they came up with this algorithm that's called fairplay and they use something similar it's kind of tricked but it's similar for the ios apps we need a jailbroken phone to do this that is because uh most of the tools that we're going to use are not allowed in the app store so also people might not know but every single process that runs under your ios device has to be signed by apple or a developer certificate or enterprise certificate that also go all the way to the chain to apple and these tools that are that we're using to the ios apps are not signed by apple so that's why you need a jailbroken phone and third we don't really decrypt the the ios apps uh we're just going to load it into memory and we put a dump portion of the memory and just going to rewrite the binary right so we're going to ask ios look ios you know how to decrypt this apps just load it into memory intent we're just going to grab it from memory and lastly once we have this we built the ios app which is transferred to our computer where we can do further analysis so how do we do it we can use some tools like dump memory where it takes a file name which in this case the binary app and then a portion of the or an offset of memory that we want to dump and the reason is because all the the the binaries have a header that indicate what's the portion of the binary that's encrypted it's not the entire binary that's encrypted so with this information we can as ios load it into memory and then we dump that portion of of the binary that is encrypted luckily we don't have to do this by hand we don't have to figure out the headers and all of that there are tools that we can use for this these are three of the most common ones there are many many more now at the dump decrypted or bf inject or free ios stump all of them are open source and you can check them um they will allow you to target an application and it will launch it for you it will decrypt it and then you will end up with a decrypted version of an ios app so for the non-ios developers in the room and the applications of the ios applications have a ipa extension but in reality they're just zip files so what we could do is we could literally just rename that file into that zip and extract all the files that come in with your application you know this is going to be very important because sometimes developers and realize that every file that they include into in their app can be easily accessible by a potential attacker and we're gonna see that um once you're you have the decrypted version of your app you can perform two types of analysis which is uh the dynamic analysis and the static analysis most of the people that i know love the dynamic analysis it's it's very fun it's it's uh you're sniffing the traffic of your application most of the applications would need a server to connect to to read data or to write data so this is very fun where you get to see the packets they're going through you're going to change some values you're going to see oh how the server reacts change some values again how do the app reacts so this is a very fun part of the analysis um also many company companies are interested into games for example they have open bug monty programs where they will say look if you find a vulnerability that a very common currency in game it's coins like to say if an attacker can generate thousands of millions of coins and they can get an unfair advantage of that because of that so we're interested to see any of those kinds of vulnerabilities so this would be part of the dynamic analysis where you literally are playing the game to see how it works and to see if you can circumvent some of the restrictions and you can figure those things out but there's also the other side which is the static analysis many people like this one because they say it's very boring and i i sometimes agree but i personally love this part actually all the one reels are going to see today were found using static analysis i did not even run the app to find them and then this represents a that you will have to sit down you have to read the decrypted version of the app you see the machine code you figure out this method is jumping here this method is doing this um the the application does x when when i tap this button things like that and you also read through thousands maybe thousands of files that the developer included with the binary and so you have to go through fonts you have to go to images you have to go through configuration files which is very important because sometimes developers don't realize that if they add a configuration file with a hard coded credential it's going to end up in the binary it's going to end up in the bundle and then an attacker could just extract that and that's exactly what happened in the first vulnerability we're going to see today when you when you unzip your application you end up with all of these files you have folders like the frameworks folders which holds all the third-party frameworks that you're using in this application and then it has all the images that you use all the custom fonts that you use but especially the configurationfile.json.please.xml files they're going to be there play in plain text so in this case this is a very common mistake that a lot of people do they embed a configuration file sometimes with things like a private key yes which is intended to be private as the name suggests it should be private so how do we end up in this situation what's happening is that a very common pattern is that they're the companies don't have the resources of time maybe what time is the resource but they don't have the resources to build their own backend system for example and they so they hire the services of a third party let's call it a cloud database for example and what this provider is going to do is going to say okay i'm going to give you a certificate with a private key so that you can access your resources in our cloud and that certificate probably has an ssh key like a private key to so that you can establish an ssh connection into the server the problem is that many developers are embedding their certificate directly in their app and making the api requests directly from the app to the third party now this is if you look at it from the user perspective this this is not different from connecting to your server or anything like if the app is just connecting to somewhere but from the attacker's perspective that means that your certificate is leaving the same in the same client that i'm able to see in plain text and so don't do this anyone could have access to this vulnerability or this credentials and this is exactly what the first vulnerability i showed you the screenshot for what they were doing exactly this um right so how do we fix this what's the proper way to handle this pattern or architecture this system so yes we're going to generate the certificate from the server we're going to download that but we're going to build a middleware we're going to build our own infrastructure our own server where we actually store the certificate and then this certificate this server will expose a public api that our application is going to connect to now this has many many benefits and some of them are so you're going to be able to handle the authentication part on your own you're gonna give them a username and password and then you're gonna return a token or a session id or something then you know that they're authenticated to use your api that's number one second is that you're not exposing files like the the private key that your third-party cloud service is requiring you to access their their services um you're going to do that directly from your server which is it doesn't have a front-end or it should not be exposed to the internet and that's the one that is going to host this private certificate so this is the way you should do it this is the way you should build an architecture of the system instead of embedding directly private information into your mobile app volume number two so for the non-ios developers in the room and for those that jump directly into swift this is objective team and to showcase the the vulnerabilities i built my own vulnerable app so my my own application is vulnerable to all of these vulnerabilities that we're gonna talk about uh first we need to know that there's an api from ios that allows an app to be launched from a different process for example different application let's say we have uh application x and that application has some sort of feed and in the feed you find a tweet a link of a tweet for example when you when the user taps on that link the popup is going to show and they're going to say do you want to open this and the twitter app and most of the users are going to say yes because the experience is going to be way better if you open that link in the twitter app because the twitter app was literally built to show twits so this is a very common pattern and it's called uh url schemes so you as an apple as an application you register the urls that you're supposed to be handling that you are allowed to handle that you know how to handle and the convention is that it's usually the name of the application column slash and then you can send some arbitrary parameters to the application that when it launched in this case and this is a real word scenario where the application was listening to a url scheme and it will look for the keyword news and then forwards last and then everything that came after that was treated as a valid html content and not only that after treating as a valid html content it would load a webview for those who don't know webview it's essentially a fully functional web browser within your native application and so this app will search for the the keyword news and then we'll treat the entire parameters as valid html that it will load in a web view within their application not not send them to safari like load them directly in their application so what could go wrong with this uh so this is my application that i named it coinsan porn because i was building a crypto wallet funny application and zap because i love pizza um and so let's imagine that the user is just browsing around they're just navigating websites they're just um i don't know googling something or something and there's a link they find a link in the links and safari says you want to open this and your native app let's imagine this is your bank app right just imagine you're going to have a rich experience if you open this link in your web app the problem is that since the html is controlled by anyone that is opening this url they can pass in whatever html content that they want in this case it's just loading a wikipedia article which is defined just to illustrate this but someone can build or craft a login screen for your bank app for example if your bank application is loading arbitrary html content within their own app people are going to trust that people are are going to inherently just say yes i'm just going to enter my username and password again because it's your mobile it is your bank application that it says oh sorry we lost your your session can you please re-login most of the people are going to do that and the real problem is that this is a fully functional web view web browser but we don't necessarily have a navigation bar so nowadays uh many people are aware that there are phishing attacks where they're gonna try to make you enter using a password in a funny email web email for example but they they are learning that if the url looks funny i'm not going to enter things whereas here that's not possible because the logo is going to be your bank application it's going to be your crypto wallet it's going to be whatever native app that you're launching and then people are going to inherently just trust that i'm just going to enter the username and password again so to illustrate this this is the way url schemes work where you establish the name of the application in this case going sa column slash news and then some some html parameters in this case it was just very simple we just changed the the the current web page to a wikipedia article but again as we said before it could be something more dangerous and you have to encode the url so that it was partial when it's passed to a different application right so how do we fix this first never ever ever trust arbitrary code that you don't own or that you're not generating if someone else can send you this information and someone else can send you parameters don't just trust them don't never load them into something that a user can interact with right so url schemes and web views are a very dangerous combination and you should be careful when you're using them just make sure that the content that you're loading it's trusted that you know that it's executing the right things and never load arbitrary code that you don't know where it's coming from and lastly if you need to react to dynamic actions from uh like a url scheme passing parameters just maybe have a white list of actions that you're allowed to take and then if if the content or the parameters that you're getting doesn't align with any of those you're just gonna say sorry i'm not gonna load this thing right number three um so this vulnerability it's not specifically for third-party applications but it's is it's shown here because one of one of the very one of the most popular third-party libraries for accessing the network was vulnerable to this so what's happening when you build a browser the browser has to open any website okay you don't know which websites the user wants to open but when you build an app you probably know which services this app is going to connect to you know probably just one server or at least a handful of servers that you're going to connect to so you know the urls that it's that are expected to be uh queried from your application so what many people do and i suggest you to do it because it's a very good approach or getting featured to have um they're going to do what it's called people call it as ssl pinning certificate pinning or public key pinning there's actually a huge difference between pinning the certificate or the public info but anyways the the the core idea is that you know the website that your application is supposed to connect to so what you're going to do is you're going to get the same tls certificate that your server has and you're going to embed that with your app and then when your app tries to connect to the server it's going to say okay server send me your your certificate you're going to check that information against the information that you haven't backed if it's not the same i'm not going to talk to the server that's it plain and simple right so when we request we ask for the certificate and if it's the same one that we have we establish a connection if you have someone in between that is going to try to fake a certificate they're going to make a fake certificate for the website that we're trying to connect to ideally this mechanism should stop that request to not allow any other certificate than the one that we have the real problem is that when there in this case the third party library was vulnerable to this or when you build this logic and you don't do it correctly you open the door excuse me to someone giving you a fake certificate and you accepting them some of the main reasons i've seen this is and i've seen this in at least six different applications where developers start building this feature and they're like oh we're gonna do this later in the next cycle so they just have a to-do within the the method that's supposed to handle the certificate checks and then what that does is that just gonna return true to all of them and they're just going to accept any certificate they're going to send and with that an attacker which is the attack is called the mad emitter attack it's going to be able to sniff all your traffic between the your application and your server and it's not just the url that you're connecting to it's all the data the username and password your bank application so your bank information your health information everything that is between you and the server they're trying to connect is going to be able to be sniffed to illustrate this i'm going to use a tool that is called better cap what better cup is going to do is is it's going to ask me for an ip that we're going to call target and we're going to launch it and we're going to ask to sniff for hd traffic and something that is important to see here is that this is a remote attack i don't have physical access to the device all i have is the advice i p so let's imagine that there's an attacker in a public coffee house for example and they know the ips so somehow they they managed to get the ips of of the users out there on their phones if your application is vulnerable to this specific issue what better cap is going to do is going to start listening to all the packets that your application or your phone is sending and if one of them is from your vulnerable app your app is going to say okay i need to request this this url can you send me this the tl certificate for this url and then the beauty of the internet is that whoever responds faster that's the package i'm going to process and so since i'm it's the the attacker it's probably closer to you that the server is going to respond faster so your phone is going to get that packet before the the actual server and so in this case it's going to have a fake certificate for the url they're trying to connect to and since we're vulnerable to this issue where we accept any certificate they're going to be able to sniff our traffic so it might be a little bit difficult to read but have a certain version here so what's happening here is that my application just to mimic some traffic i'm going to ask for some content from google use sorry github user account user content.com and better cap is going to see that request i'm going to say okay i'm going to create a fake version of the tls certificate for this website for this url i'm going to serve that to see if your application accepts it the promise is that this application is vulnerable to this and it's going to accept that certificates and now better cap is able to see the request that i'm making which in this case is just a static file but it could be anything yeah like real data that your application is sending so how do we fix this vulnerability keep your third party libraries up to date i cannot stress this enough almost every app that i've checked has at least one dependency that is outdated and being a developer i know it's a huge headache you update this thing sometimes they break your app and the like most of the pms would say if it's not broken don't fix it just leave it as it is so that's why many of the third party libraries that are in mobile applications are very outdated like i'm talking about two three four five and even six years outdated and this could lead to potential uh vulnerabilities like these uh and and also i understand that it's hard to manage because some applications have 10 15 20 different third party libraries that have to keep up to date make sure to do that uh then also be careful to implement in this logic uh ssl painting or certificate painting or public key pinning it's a very useful um security measure that you can add to your application but me be sure that you know how to implement that because a bad implementation of this logic could introduce this vulnerability where where someone can send you a fake certificate and you might end up accepted if you need to do it this is a very good library trust kit and they built it and they use the proper pending which is the public key info painting is the one they use they explain why they bring how so you can definitely use this in your projects if you want to implement certificate painting and there's also more information and the os project the open source web application project it will give you more information about why this is a good idea how to do it what's the best way to pin what information to pin so if you want to read more just read about this the fourth vulnerability the back to the first vulnerability that we saw is that this application is accepting arbitrary html code but in this case we're going to pair that with a very dangerous um vulnerability from an old ios class which is called ui webview as you can see in the documentation even apple says that be careful when you're using this class specifically this method with this class to access local files um we're going to see why a little bit later but as you can see from documentation this this class was deprecated in ios 12 it was released last year but i haven't not found one app that is not using this yet uh so there are many many apps that are still used in a ui webview and the problem when they're using this uh method or actually before we go into that uh i will suggest you to use this this other method is called i load html with a base url the problem is that what is not said in the documentation is that having a null or an empty base url is the same as not having that so these two api calls are equivalent so as a nut don't use any of this and the reason is because when you don't define a base url for a webview any javascript that is running on that web you have access to any file within your file system within your sandbox of your application so all your documents folders all your temp folders your cache folders are accessible by javascript executed on your webview if you don't define a base so you're basically finding a scope for your javascript if you don't define a scope it's like it's open game for any access to any file that you have within your binary within your bundle so something like this could happen someone can write a payload that will search for in this case the searches for a database and during the static analysis you can you can find that an application saves a database for let's say your messaging apps so your message for example or your uh it's very common that your crypto wallet would just create a local database where it stores all the private keys for your cryptocurrency so this is a very dangerous application to have loading with you with no scope because javascript could just search for that database and just send them remotely so just read that file from the local disk and just send them to a remote server right this is how that payload looks when you encode it that's not important but here i'm going to show how to do that like again the user is just surfing around and then they're going to try to open a link and that's going to open a webview within the vulnerable application and i'm not going to show you like the database being sent to a server because that that's that's kind of a difficult show but here we're able to read this database that is in the documents folder of your application uh even though this is just a simple website this is just a webview that is loaded it has access to all your file system within your sandbox right so how do we fix this don't use ui webview anymore there's no need to use that there's a new and better class that is called the wk webview uh it supports everything that the ufv supports and it doesn't have the same vulnerabilities it doesn't have the same vulnerable apis if you buy for some reason you still need to use the ui webview class maybe all or old versions or compatibility issues don't use these two methods don't use the to load request for local access and if you're using the base url method make sure if you don't know what's the base url you can use the strict where you just have about column blank which is at standard way on web to load a blank web page and that will give the scope to your web view to just whatever is loaded within that webview and that's all the resources that javascript can access some conclusions about this add security assessments to your bill cycles whenever if you have like a qa cycle for example add secure assessments to that that's a very good idea have someone either internally or a third party pen tester go through your app or your apps plural and check about like check some of these vulnerabilities i keep your third party libraries up to date this is i know i've said this before but yes again i've seen so many of these instances where applications are vulnerable just because they have an old version of an application of a third-party library be careful when you copy and paste data from just the internet like stack overflow or something like that because they might have vulnerable portions especially when you're implementing very complicated logic like uh ssr like ssl pinning and things like that you need to make sure that that code works and it's not vulnerable um lastly and this is a very important one have a public bug bounty like if you want to pay researchers for for finding miller bills that's fine but at least have some way for someone to contact you i i move from just working with public bug bounties to just randomly download applications and searching for vulnerabilities and there are many many many applications that are vulnerable but there's no way to contact the vendor there's no way to say oh hey look developers can just fix this please i'm not asking for money in return or anything i just want you to fix this for your users and i've usually just find out a random like contact ad website.com email or a contact form from their website that goes to i don't know sales and they might not know how to react to someone saying i find a vulnerability in your system or in your app and it just might discard this email so have some way so that anyone can contact you and give you this information because this is a struggle that we have in the community where we find vulnerabilities and we don't know how to reach out to people because sometimes they're like we're threatened into oh we're going to sue you we're going to send the police your way or something like that whereas we're just trying to help the companies so this is very important and some of the resources that you can find so the always program the project it was built for web but now it has a mobile branch where you can find a lot of resources for how to securely build your ios or android applications how to pen test the applications yourself how to start learning about all these things and then finally i have my own version of this so i created a i call it a course but it's a bunch of write-ups about very common vulnerabilities but also takes you from not knowing how to decrypt an ios app to all the way to modify that and i i did this because i i found that there are many people that are interested into learning all this thing but they don't know how to start they don't know where to start and so this will teach you all the way from installing all your tools creating your environment all the way to modifying your application or third party applications at runtime and it's free it's there to use it's open source um i recently found that there's a professor that is using this course and some write-ups that i have for one of his courses which it was fantastic this is exactly where i write this kind of stuff so more people will learn about it and so back to the initial story after that and they invited me to their private program to see their their app before it would hit the market many many many other companies reach out and say okay can you please also look our to our apps because there are not many many researchers looking at the mobile apps and many of them will offer to pay you double for the vulnerabilities if you find something on your mobile app so yeah if you're looking for doing something on the side this is a very interesting job to do and with that i'm going to take some questions thank you thank you i think we have a time to have a discussion right to ask questions and as as someone with microphone i'll do first so ivan uh which vulnerabilities have you found like which are most popular um the most popular one that i've seen is the hard coded credentials that's how to go hardcoded credentials right in the app right yeah and basically you can you can get them just by like reverse engineering just by running strings commands for your app yeah so you could go all the way from just a simple plain text file as it showed here all the way to having an obfuscated string within the binary that at the end of the day if i spend enough time i will be able to reverse engineer that and figure that the values and i'm going to be able to use those to log in as the company yeah yeah also from my experience the cryptographic keys you know when you have some encrypted data in your app but you put a key somewhere in a playlist near the data great okay thank you so please raise your hand if you have a question and we have a microphone here right do we please click continue having your hand yeah yeah that's it hey thank you great talk um you you talked a little bit about certificate pinning and you do reverse engineering so i'm i'm curious and so just a reminder for people certificate of paintings helps prevent man-in-the-middle attacks on the tls connection for instance so um are you finding certificate painting as a reverse engineer are you finding it to be an impediment to figuring out the protocol or are you able to like take out the logic that checks the certificate or replace the logic that checks the certificate with your own certificate um so yes to both questions um i find it as an impediment it's because you usually just want to do the very initial uh dynamic analysis where you just install your own certificate on your device and then you want to try and sniff the traffic uh so the first thing that it says like oh i cannot see the traffic or it's blocking the connections it's like oh there's some certificates i have to fix this right i have to figure this out so the second question yes it's not trivial because some of them have very intricate logic around the pinning and you have to break that before you can sniff the traffic so it's it's a game where the more layers they have to your security will it will benefit the company but someone with enough time resources will eventually get there great please raise your hand yeah here hi thanks for the talk um can you talk a little bit about the differences in the protection offered by apple's app transport security settings and certificate pinning like what are the different attacks that you would be protected from under both uh sure apple or app transporter security it's apple's way to ensure that your application is connecting over tls so they have they enforce that every connection that your application is trying to make it it has a tls connection in it and it has a well-defined set of accepted cryptographic algorithms that you can use for that uh tls so for example you cannot use tls 1.0 or 1.1 for example right so it limits to the or it guides you towards what type of tls connections you can have certificate pinning it's an extra step to that where you will only accept the one or the two or the three certificates for your specific domain within a tls connection so it's it's a step beyond what apple is doing with atf idp yes hi uh thanks for the great talk i think it was very practical thank you very much i am as a this is a question from a app user point of view rather than app developer point of view i get really very scared when an app loads a web ui because i can't see the url and even if i could see the url i can't see the certificate the ur url is getting served from right this is a problem across all platforms not just ios right i'm just curious why industry has fallen so behind about this very important aspect because you know it's a simple thing a content being served from a some server which could do something to your device and there is just no way of knowing what where that content is coming from it seems like a big thing why are you on web ui webview allowed in general in the apps yeah uh well i don't really have uh an answer for that but my experience is that there are many companies that are doing this because of time they cannot build something for both ios and android very quickly or they might change their minds down the road so they build a webview side of things because they can dynamically change that they can change that in the server side and if you're loading just a webview it could look like anything you could just change that page you don't have to resubmit an app to either of the stores and so it's about time and things like that simplicity those are the most common aspects i have seen for people using webviews yeah yeah thank you do we have more questions please raise your hand do we have questions from this side this sector yes hey thanks once again for the talk um i do have a question about uh this process can we kind of automate it i know linkedin created quark a couple of years ago that's for android only these specific things are for ios is something like work available for ios as well well that's a good question um there are not many services providing this automation there are tools that will help you but it's not an automated process in the entire uh there like for example i have scripts that will decrypt your app and transfer it to your computer on its own but the actual analysis that's a very hands-on thing um i i think mainly because of the time ecosystem that apple has that not many things will run on devices like i know there are automated tools that that are companies i know of companies that have this but they're not publicly available to anyone to use the services i know of two at least two companies that they regularly download apps from like the top 100 apps or free apps or something like that and they have some static analysis on all of them and they have like a farm of devices that are downloading because you have to have a device to download an ios app so they have farms and devices where they download the applications they perform all of them are jailbroken they have custom bills they have custom scripts running on them but it's a proprietary it's not available for the public okay thank you any more questions please raise your hand yeah i see a hand thank you hi a great talk um most apps are using http json http based request yeah so did you encounter any apps that used for example protobuf and is protobuf making um reverse engineering any harder or many the middle attacks any harder that's a great question um yeah most of them are using a rest api uh or even a graphql but at the same time it's it's it's text right provo it's more of an encoding of the actual data that we send and yes it kind of makes it harder but there are tools like burp burp it's a proxy application that you can use to sniff the traffic between it's mostly built for web but you can also use it for mobile applications and they have a built-in parser for protobus so even if the traffic it's it's encoded into a binary code it will be able to just show you the plain text so it's not that big of a deal yeah thanks any more questions yes yes sure just curious in your experience if you've seen any more vulnerabilities with apps that are a result of coming from a cross-platform solution like react native or flutter or something like that good question that's a very good question um yes uh well the the first thing to say about that is that it's easier to go through the source code because at the end of it it's just javascript that is bundled in the app so it is not down to machine code it's javascript that you can read very very well so it's easier for a reverse engineer to check that bundle to check that application if you see the binary it just has very tiny code that loads the webview and then everything goes to the javascript so in that sense it's the entry barrier is easier for anyone reverse engineering that type of app second some of the developers don't realize that it's it's like that is a plain text javascript but it's going to end up in their application so they hardcore a lot of credentials and those type of apps and so that's including to your first question was that uh what what's the most common one that is part of that the the hard coded credentials within javascript code that's very common the second it's cross-site scripting vulnerabilities where you're allowed as we saw the last one is a cross-site scripting vulnerability where you're allowed to execute code or access data from a different domain than your webview these types of frameworks would allow you to do that because at the end of the day they cannot restrict to just one webview they have to restrict you everything within your application bundle so you can see some across subscription and vulnerability introduced because of that thank you thank you one last question do we have it three two one salt okay i have a question i want how long does usually take you to reverse engineers applications i know this is like an endless journey but do you have some like timing in mind um it depends on the functionality like for example i'm very interested in crypto wallet applications that's most of the the applications i've done in the past two or three months are crypto wallet kind of applications and they're kind of simple because most of the logic is within the application but at the same time you have to understand what what are the um cryptography parts that they're using and all the logic that they're using to protect the cryptocoins and things like that so it could take a week to figure out on like perfectly an application but also part of of my research it's around applications that are like at spying on users for example and that will take a month or two but when you say a week or month it's not like a full-time job yeah no i do this on a site so it's like i have my flight to a nine-to-five job and then i go back home and just do this so software developer during j hacker during night yeah okay thank you thank you a lot

Channel: InfoQ

Views: 2,387

Keywords: Mobile, iOS, iOS App, Development, Security, InfoQ, Operating Systems, Mobile Development, QCon, QCon San Francisco, Transcripts

Id: RLzbHHoEKo8

Length: 45min 28sec (2728 seconds)

Published: Mon Feb 15 2021