Another pointless NativeScript Security Plugin....

So, I saw this blog (https://blog.nativescript.org/nativescript-ios-security/index.html) article today, and was thinking awesome someone is actually talking about security in NativeScript apps... My elation was very short lived. Shortly, after starting to read it, I'm like, oh my G*D! Bad security advice is way worse than no security advice! At least the other insecure plugin NativeScript/Secure-Storage has a point, this one....

Well, if you read any of my prior posts on the in-security of React Native, NativeScript, Ionic here, and here. You might have guessed what my response to this is...

Lets show how trivial this is to bypass...

Creating the Demo Applications

First, lets create a throw away folder, and two simple test apps.

mkdir bypass
chdir bypass
ns create demoapp --js
ns create shellbypass --js
cd shellbypass
ns plugin add @nativescript/ios-security
cd ../demoapp
ns plugin add @nativescript/ios-security

Creating a Demo to test it...

The demoapp is our awesome multi-year released app that we have poured hundreds of hours and millions of dollars in. The shellbypass is the hackers app.

Next you need to open the demoapp/app/main-page.js file.

Then at the top we want to add this awesome plugin so add:

const IOSSecurity = require("@nativescript/ios-security").IOSSecurity;

Then in right below the page.bindingContext = ... we need to add our security check...

let amInEmulator = false;
if (!global.android) {
  amInEmulator = IOSSecurity.amIRunInEmulator();
}

if (amInEmulator) {
    console.log("Hey I'm in a emulator");
    page.bindingContext.set('message', "I'm in a Emulator");
  } else {
    console.log("Hey, we are on a real device!");
    page.bindingContext.set('message', "I'm on a real device!");
}

So the main-page.js should look like this (with all comments deleted):

Ok, lets run this on a simulator.

> ns run ios

And look our security check worked perfectly!

You can see on the top it is built for a simulator; and the console.log says: "Hey I'm in a emulator". So we have deployed everything correctly. Now switching roles to the attacker, this app won't run on an emulator, or will it?

Lets just pretend we uploaded it the app store and then used one of the techniques I outlines in the other blog posts to download your application IPA directly from Apple to my mac (or you can just use a jail broken phone). The IPA will look something like this:

Lets go into the "app" sub-folder, as it contains our original NativeScript app code.

So what do we have here... I outlined them in the other blog posts but we will dip briefly into it.. First lets copy the bundle.js, runtime.js and vendor.js to our "shellbypass" app into a new folder called "other". Now normally I would run some my custom tooling to re-extract the code back out of bundle.js/vendor.js into all their separate files, so I can easily rebuild the app from virtually the same code that you had. But in this case I'm lazy and I want you to be able to easily follow along so we are just going to use the raw files from the "original" app..

If we are on an actual jail broken phone, we actually don't have to do the "Creating a Shell" step, you can skip all the way down to "Removing Security" as you can edit the files directly on the device...

Creating a Shell

1. Delete everything in app/ folder except the "app.js" file.

2. make app.js just have the following line of code to make sure that the IOSSecurity native code is built into the new NS app:

const IOSSecurity = require("@nativescript/ios-security").IOSSecurity;

3. Edit the webpack.config.js and make it look like this:

const webpack = require("@nativescript/webpack");
const fs = require('fs');
const platformInfo = require("@nativescript/webpack/dist/helpers/platform");

module.exports = (env) => {
  webpack.init(env);

  let output = platformInfo.getAbsoluteDistPath() + "/";
  if (fs.existsSync(output)) {
    fs.rmdirSync(output, {recursive: true});
  }
  setWait(output);

 return webpack.resolveConfig();
};

function setWait(output) {
  if (!fs.existsSync(output+"vendor.js") || !fs.existsSync(output+"runtime.js")) {
    setTimeout(() => { setWait(output); }, 100)
    return;
  }
  fs.copyFileSync("./other/bundle.js", output+"bundle.js");
  fs.copyFileSync("./other/runtime.js", output+"runtime.js");
  fs.copyFileSync("./other/vendor.js", output+"vendor.js");
  console.log("Copied");
}

Again I'm being very lazy, basically we are letting webpack work normally, then copying the original demoapp files into our hackers shellbypass app.

In all reality splitting the code back out of the bundle into its separate files makes it a lot easier, but my tooling is not very clean so I'm not ready to release it yet. But it is trivial if you read my prior blogs to split the files back out and de-minimize them...

So now we have a shell app that should run the original demoapp code as is. Lets test it.

> ns run ios --no-hmr

As you can see this app is called "shellbypass" and it is printing the same "Hey I'm in a emulator".

WooHoo, we have successfully cloned your million dollar app into our own free NativeScript shell.

Removing Security

All of that just to show you have this plugin doesn't matter... So first there is two ways to do this... I'll show you both ways, just to show you how trivial it is to remove these types of check's.

Bundle.js changes:

Search for "amIRunInEmulator" -- Look we found it on line 205... Lets just comment that right out...

Now what happens when I run my app...

Now the app prints "Hey, we are on a real device!" The awesome plugin's security sure did stop me from running on an emulator, didn't it? The app you so carefully programmed, and may have even spent years on -- I just simply removed the check and ran it and now I'm playing with it on a simulator or a jail broken device.

However, the vastly better method is to just change the vendor.js file, so that I don't have to find every place you put the checks in your code. (So first undo the comment we just added in the bundle.js, so it is back to "stock" demoapp)

Vendor.js changes:

This is the vastly superior solution, lets look about line 46849, and just return false....

All I would do is return false on basically every single one of these functions in the IOSSecurity class, and the plugin doesn't do a single thing no matter how many times, nor where you called it inside your application (the bundle.js).... Defeated in less that 5 minutes...

Wrapping it all up...

The problem with security measures like this, is that NativeScript, React Native, Cordova/PhoneGap, Ionic is they all ship the source code ships inside the app. It is trivial to extract it out, create a new shell and make the changes to make it my own "clone" project or to steal/corrupt your data by using your endpoints. If you plan on using something like this plugin you need to use a product like JSScrambler or https://AppProtection.net (my own product which encrypts the NativeScript source code). If you just ship the app using minimization (pointless for security, but useful for optimization). Please read the prior blog posts on how easy it is to pull everything out.

If you are interested in more info on my current NativeScript solution AppProtection, or if you want to help fund the vastly superior solution that eventually can work for both React Native and NativeScript with no coding changes in your app; please contact me at nathan@master.technology.