Infiltrate Your Own React Native App

This is a headline you don't want to see. As a product owner or as a business, you don't want to. As a developer as well, you don't want to see this headline popping up at the New York Times. This one really did pop up in 2002, 2020, sorry, because Jeff Bezos' iPhone was hacked because there was a vulnerability in WhatsApp. So not on iOS, which you heard multiple times, of course, that are some exploits for iOS itself. But this was only because WhatsApp made an error somewhere. So they were, yeah, Jeff Bezos was infiltrated that way and escalated on iOS multiple times. So every time you make a feature or you create code, of course, there is a chance of a bug. And every bug and feature can also be a potential flaw or potential entry point for bad actors to use, so they can exploit your app, exploit your business. So in research, there was like 75% of apps have bugs in them or features that can be used to infiltrate your app or exploit your business. So for example, the 7-Eleven one was a nice feature what they used to reset your password, which is, of course, an obvious functionality. But they thought, what happens if you change your email? So if you change email all the time, maybe you could just enter another email and reset your password that way. Sounds great, but of course, if somebody new and multiple people new, they reset passwords of other user accounts and then just ordered everything what they could online. So that feature was misused multiple times and like it says here, it cost some money for them as well. Another thing you see online a lot is fake applications. So they use your brand or has your icon if it's really popular, of course, as well to make fake applications, put that in the App Store, for example, iOS or Android doesn't really matter, or Google Play doesn't really matter, and try to lure you in to download your downloading that app and try to escalate privileges. For example, you can ask for the contact permissions for the contact list, although your normal app doesn't do that, the fake app does, and just upload that contact list of yours to their own server and try to do it that way. Another trick is, of course, what they do is try to put advertisements in your application. So they make a copycat application, just one on one, and enter advertisement code in it. So if you open the app, there's advertisements, which you didn't add. So they are profiting off your application as well. You would think that Apple and Google would do a great job of protecting your app, of course, because they have this really neat review process, which everybody loves and hates. But still, there are thousands of fake applications in the App Store right now. Of course, some with great brands, although smaller, which do this all day long. And also there are some app stores, which are not really app stores, but they are fake app stores with correct applications, for example, because some applications are expensive and people try to use them in a free way. So they will go to an app store, which isn't, of course, the Google or the Apple one, and then download the application. And usually there is malicious code in there as well, because they also need to make a profit off you, of course. So in the Fortnite example, for example, Fortnite is, of course, still a popular game, but they made an announcement that they were making the mobile version of it. They made an Android application, which downloaded the real game, let's say, like that. So they made a launcher app. So everybody made a fake launcher app, which downloaded some other app, which, of course, needed the permissions and, of course, tried to inject everything in your mobile device. Another one is, it's not only, they are not only attacking your app, but also your tools you use every day. Of course, most notably, the fake Xcode, as we call it, is one of an example of that. And not only the tools, but also your dependencies. So all the dependencies you have in your application are targeted to get there into your device, so in your MacBook or laptop. And they try to search for, for example, access keys for aws or some other credentials they want to need, they want you, they want to have, or they just put a crypto miner on your device without you knowing and they profit off you as well. Because these days, the software project has like 203 on average dependencies, I think react, of course, has some more, but that's the average at this time. There are a lot of ways for them, for bad actors to get into the dependencies as well, try to get into the app. Because most notably, of course, they try to do it on your machine as well to exploit that, but they want to exploit the application you are making as well. So again, they will eventually get into, get onto the device, buy your app, and then trying to get that data that they want. I think the British Airways one is one of the most notable here, is they use Modernizr, which is of course a web framework to attack, but they also use it on mobile as well. And what they did is every, they made a keylogger inside of Modernizr and then push that to BA and then every page on BA got that script. So every, also the checkout page, so everything you type in the checkout page was sent to them as well. So of course, all the credit cards, et cetera, details were sent to them and they use that of course to make all the purchases, et cetera. BA got fined for 20 million last year for this hack alone. So it is a really expensive trick that they did on them. So yeah. And of course the other one, also from last year, I guess, was the npm one, the UiParser one, was that they added a crypto miner for your machine. So if you run that or you added the newest version of that dependency, then of course you got that crypto miner as well. So what can we do about this? First of all, and I think Katie did a great job of saying that as well, know your service loader, so also know the native code of your react Native code. Of course, most people will know the JS code or the typescript code as well, but try to understand the other parts for your react Native app is using as well. If you don't, yourself, try to hire someone or contract somebody to see what the code is doing and what it is not doing. So you can assess what attack factors there are in your code. documentation of course. Again, thanking Katie for the react Native security documentation, which she made for the most of the bunch, which is great. So react Native itself on the website has some security guidelines, so please follow them as well. Google and Apple, for the native side, have great security guidelines as well, so to what to do and what not to do with your data and your security details, etc. Great shout out to Julia, because there should be a YouTube here, but I guess the Internet isn't working great at the moment. Julia is from Cossack Labs, which is a security company from Ukraine, she already has some talks about react Native and security for a few years now. Please watch them, because they are really good at knowing about how react Native works with the native side as well, for the bridge and all the things you need to account to. We have OWASP, which is an open source framework. We have that for web as well, we have the top 10 for OWASP for web. We also have that for mobile, which is shown in the infographic here as well. We have the 10 most used security vulnerabilities that are used in the wild, so they make a top 10 out of them. Take a look at them, see if your app is somewhere in that space and try to improve on that. They also have another project, which is the mobile requirement verification project, which is mainly, of course, there's a lot of documentation, but it also has an Excel sheet with all the things you can check to see if your application is safe. Not only code, but also in process, etc. So it's a very wide approach on how to make your application better. There's a lot of great stuff in there, so please take a look at it. Your dependencies, like I said, dependencies is one of the most used attack factors these days because it's really easy to get into most of the time, not all the time, but most of the time, like with npm or with other dependencies we use. So know your dependencies. Of course, there's a lot of them, so one by one, it's maybe not undoable, but it takes a lot of time, but it should be the case that you know all of them. If there's an update, always check if it's correct, what the code changes are, etc. And use tooling as well. So there is a lot of tooling online for doing your own penetration test, for example, with the mobile security framework, which is an open source library, which you can run your app, your compiled app against, and it will say like, those are the security things we found in your application. And then you can, of course, improve on that. So you can put that in your CI, for example, as one of the stages. There are also some commercial ones as well. You can use SNIC, which is a sponsor, to use for your dependency checking. It will scan vulnerabilities as well, which is great. It could also be a step in your continuous integration part. And of course, use ESLint, for example, ESLint rules or something else for some other things that can happen in your app. Let's say logic, which can be exploited. So use that as well in your advantage. And of course, for the great part is how easy it is to do. So let's try a demo. I made a react Native application, just a react Native init, and that's it. That's what I did. So that's what you see here. I added JailMonkey, which is from Gantt from InfiniteRat, which is a great library to detect if your device is jailbroken or not, or rooted if you have an Android. And what I did is just make a comparison, like if it's rooted, then just show this text and this image, and if it's not, then the other one. And that's it. So it's a really simple application. I compiled that application for iOS and for Android. You can see that here. And yeah, let's see what we can do about it, with it. So first of all, the IP and the APK is just an archive. So you can just unzip it, and then it will make a nice folder. And then you can see there is a plist, for example, and you can see there are assets, and there's the application itself. That's the binary. And you see here is the code, which is the compiled one, which Metro does. It's just a lot of javascript code, which, of course, gets loaded on runtime, and then you have your application. So what does that application look like? Let's install it on my simulator. Yeah. So it says it's a jailed application, because, yeah, I don't think you can even root a simulator on that part. So it's just a jailbroken, or not jailbroken application, it says. So that's fine. Or a device, it says. So that's fine. But can we change that? So in the app, we see, let's see, we see there is a call is jailbroken. Let's see if we can find that in the bundle. Yeah, here it is. This is my piece of code. So this is the comparison which I'm making in the app, which is the compiled one. And then we have this one. This is the function in the library, in the dependency itself. So that's compiled as well in your bundle, of course. And this is just a comparison. So why don't we just make it true all the time? Save it and install it again. And voila, it says it's a jailbroken phone, which doesn't exist, because it's a simulator. So with just looking at the code and searching for it, I just altered your application. It's as simple as that. So of course, the hardest part is now repackaging, you would say, but that's also not that difficult, repackaging an application. And then of course, you can just certify it with your own profile and put it in the app store if you want to. Of course, it hopefully gets rejected by Apple because it's a duplicate, but you could still do it. Or you can put it on another app store and just put it in there. You would say that it is more difficult in native code, but it isn't really difficult. I have a demo version. So if I open the application itself, so the binary, we have the compiler, which is Hopper in this case. There are multiple variants of the same thing, of course, on the web. You must pay for them usually, but for demo purposes, this is great. So it will load the application. And again, I will search for the jailbreak one, which we were searching for. Now there it is. So let's see what it is. A little slow today. Come on. Yeah. So this is a reference, as they call it, to a function. So we're going to go to that reference. Not the structure, but the function itself. And then it says, ah, here's the function. So I can double click on it. And if I do the graph version, then you see that it's a comparison as well. So it will take two stacks. This also, if I go through it, I could go to the end, I guess, and say, like, okay, this is also true or false. So this is, of course, the compiled code. So you need to usually do hexadecimal things as well. But the boolean is really easy, because you can do true or false, of course. And then repackage it, which I cannot do now, because I have an evaluation version of this. So then you can repackage the binary, and you're done again. And it will show the same results as well. So in native code, it's not always that difficult to do as well. On Android, we have the same thing. We have tooling, of course, to open the APK or AAV, depending on what you have. And what you see is that it will show all the classes. If you're Java, you know what those are. All the classes are here. And of course, in the resources, we have the same bundle, which we already saw in the previous example for iOS. And just change it as well and recompile it. So of course, we have done that. It's the same thing. But if we use environment variables, for example, which is done a lot of times, and I look at the environment variables we have here in my app, which is a Google Maps key, well, let's see if we can take that one and search for it in my Android application. So if I search for it, you immediately see that it's there. So open to everyone to see. So of course, the case here is don't put any keys in your environment variables. Just get them from the web or something else. Because like I've shown you here, in a minute, most people can search for it. Of course, you can obfuscate the Android app, which is great with ProGuard. But still, if you know where to look, and also this one will not get re-obfuscated, you can search for the pattern and still find it. So for the last part, let's see if my internet is working. Do we have it? Nope. Well, that's nice. Did I take that into account? Let's see. Sorry for that. I don't have one. I just tried to use my phone. I checked it before. Sorry for that. Let's see if I can do that in a sec. Come on. Let's see if we have internet. Because I wanted to show if you use CodePush, for example, it gets the source from the internet. So also that can be a vulnerability as well. So if I click on this, hopefully, yeah, it says it has an update. Great. So if I look at what it sent over the internet, I'm seeing here that my app is searching for something. So searching for the update. And it says, yeah, I have an update with a download URL. That's nice. What is that download? So if I click on install, it will get that package from the internet and apply the configuration changes. So what if we could redirect that to something like with a middleman attack to something I own? So I'm going to let's see. No, no, that's not correct. No, this one. So I'm going to just say that this URL is going to go to my own device, then serve an HTTPS request, and I need to, because I already applied the update, I need to install the app again, because otherwise it thinks it already has the correct update. So I will install the application. That's the update, which is in here. So it's just a zip file from CodePush, which also has the main bundle and the assets. Let's see if it works. It says, OK, I'm going to install it. And voila, it's a different one, because I just overwrote those as well. So thank you so much. And be safe. Oh, thank you very much, Wouter. We have a few questions from the audience. Are you ready? Yes, I am. All right. Well, first thing, what's the best way for teams to keep each other accountable about security? Like, are there good tools for groups to manage this? Well, that's a good thing. Tools are not, I think, not the case, but more a process. Of course, PRs and code reviews are a thing. So if somebody bumps up, for example, a dependency, always the question should be, did you look at it? Or if somebody makes a change to a functionality, always say, OK, did you check with our checklist of security? That is fine. tooling should be, of course, automated. So I don't think tooling is the correct word there. But I would definitely have a process in place. Yes, I think processes are tools. That's true as well. Where can we learn more about basic security precautions to take for react Native, for example? Well, I think, like I said, on the react Native website, there was a lot of documentation or Katie made some really great documentation about the few things I've just shown you about how to prevent that. So I would definitely take that into account. Yeah. Nice. And maybe my personal question. Why are you here on the good side helping us not hack apps? Why aren't you out there making money? Because I have a conscience, I guess. It's a really good question, because, of course, you can be a bad actor yourself and exploiting people. And of course, we don't want that. So I guess mainly because I have a conscience and I don't want to be on the bad side and always think about what I've done wrong in my life. So yeah, mainly. Thank you. Both a hero that we deserve and very much need. Thank you very much, Walter. Thank you.