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 were 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, and 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 a bad actor 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 your 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 costs 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 it in the app store, for example, iOS or Android doesn't, or Google Play doesn't really matter, and try to lure you in to download that app, and try to escalate privileges. For example, you can ask the app 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 101, 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, while others 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 of you, of course. In the Fortnite example, for example, Fortnite is of course still a popular game, but they made an announcement that they were making a 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 escalated 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, XSKEYS for AWS or some other credentials 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 dependencies as well, and then try to get into the app.

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 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. They used Modernizr, which is of course a web framework to attack, but they also use that on mobile as well, and what they did is they made a keylogger inside of Modernizr and then push that to BA and then every page on BA got that script, so also the checkout page, so everything you typed in the checkout page was sent to them as well. So of course all the credit cards, etc. details were sent to them and they used that of course to make all the purchases, etc. BA got fined for $20 million last year for this hack alone, so it was a really expensive trick that they did on them. And also from last year, I guess, was the MPM one, the UI partial one, was that they added a CryptoMiner for your machine. So if you run that or you added the newest version of that dependency, then of course you get that CryptoMiner 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 your React Native app is using as well. If you don't, by 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 most of the bunch, which is great. 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, et cetera. Big 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, really good to 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. 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 and 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, et cetera.

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 vectors 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 some of with other dependencies we use. So know your dependencies. Know them.

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, et cetera. 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 compiled app against. It will say 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 the stages. There are also some commercial ones as well. You can use Snyk, which is a sponsor, to use for your dependency checking. So 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 apps that's, let's say, logic which can be exploited. So use that as well in your advantage. And of course, 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 in it, 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. 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, and let's see what we can do with it. So first of all the IP and 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's the code, which is the compiled one which Metro does. It's just a lot of JavaScript code which of course gets loaded over run time and then you have your application. So what does that application look like? Let's install it on my simulator.

So, it says it's a jailed application, because yeah, I don't think you can even root a simulator on this part, so it's just a jailbroken, not jailbroken application, it says, so that's fine, 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 it's compiled as well in your bundle, of course. So, 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, you can just alter 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 then again I will search for the jailbreak one, which we were searching for. There it is. So let's see what it is. A little slow today. Come on. Yep. 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 IERC to 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 all also true as well. So this is, of course, the compiled code. So you need to usually do x-decimal 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 demo version.

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 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, 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. 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. Well, that's nice. Did I take that into account? Let's see. Sorry for that. I don't have one.

I'll just try 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 Code Pooch, 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. If I look at what is 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. So, if I click on So, 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 minimal attack, to something I own? So, I'm going to... Let's see. No, no. That's not correct. Mm-hmm. No. This one. 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. Fetch 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, okay, 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.

Thank you very much, Wouter. We have a few questions from the audience. Are you ready? Yes, sure. 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, it'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 to say like, okay, 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's 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, yes. 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'm conscious, I guess. It's always a really good question. Because, of course, you can be a bad actor yourself, like 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 whatever I've done wrong in my life. So, yeah. Mainly. Thank you. Both a hero that we deserve, and a very much need. Thank you very much, Walter.