IOS Masque Vulnerability Check

Recently published article related to the so-called. "Masque" vulnerabilities in iOS. Excerpt from the article:

“Vulnerability allows you to install a malicious application on top of an existing one, and this new application will get access to all files of the previous one. This is assuming that the application being installed will have the same “bundle identifier”, which iOS & OS X use to identify applications at the OS level, for example, when delivering updates to them. All versions of iOS since 7.1.1 are affected, including the latest iOS 8.1.1 beta. ”

I, as a person who has first-hand knowledge of Enterprise certificates, wanted to certainly deny / prove the real fact.

So, what is known about the Enterprise license:

1. Issued exclusively to companies (not individuals, detailed information );
2. To obtain an Enterprise license, you must provide Apple with a very serious set of documents. So it’s impossible to specify a non-existent company;
3. Enterprise licenses are issued solely for internal use. The fact that some applications are distributed in this way is the risk of the company being excluded from the iOS Developer Enterprise Program;
4. Installing the application from the site is possible through the manifest file and only through HTTPS;
5. When installing an application signed by the Enterprise license, the user displays the message “Do you really want to install the application“ App_Name ”, signed with the certificate“ Company_Name ”?”, While Company_Name is taken from the certificate.

In order to check the presence of a vulnerability, try to pass the path of the attacker.
')
To sign an application, you need to create Provisioning Profiles:



The next step is specifying the App ID:



But, in order to specify it, you need to create this App ID:



The image shows that when creating an App ID with an identifier “bundle identifier” similar to another application, an error is caused.

Total:
Provisioning Profiles can only be obtained with an App ID, which in turn cannot be created with an already registered “bundle identifier”. And without Provisioning Profiles, we will not be able to sign the application.

Step 2

There is another way to create an App ID "Wildcard App ID". The company's website says:

This allows you to match multiple apps. To create a wildcard App ID, enter an asterisk (*) as the last digit in the Bundle ID field.

Create your own wildcard App ID, exactly the same as the application that you want to replace. In the last part of the App ID (usually the name of the application) we write (*).



Next, create a profile for our new App ID.



Thus, we received App ID, created Distribution Provisioning Profiles for it, and we can safely sign our application to them.

So, create a project in Xcode and specify the following parameters for it:



The project is an empty application "Single View Application".

So, the installed program on the phone is on the desktop:



We connect the phone and collect our application. Let me remind you that our application has exactly the same App ID as the application that we want to replace. After building the application, we get the following desktop:



The application is really "lost". Vulnerability begins to be confirmed. Now it is interesting, but what about the data?
Open the famous application iTools. Pay attention to the version of the application - it has changed, but the build has remained the same (in Xcode, it is build == 1):



Copy the contents and open the application archiver.

And we observe: everything that was before the reinstallation remained in place!

TO :



AFTER :



As a result, we received an App ID, created Distribution Provisioning Profiles for it. Created a simple (empty) application and installed it on the phone. All data that was stored in the application, now in the hands of our application!

If we collect the archive and sign it with the created profile, it will be possible to distribute the application through, for example, the site or in the mailing list. The user will see the message “Do you really want to install the application“ App_Name ”, signed with the certificate“ Company_Name ”?”, While Company_Name is taken from the certificate. If the user is not embarrassed by the fact that the well-known application that he installed from the AppStore, is trying to update in such a strange way, and even signed by a certificate from some unknown company, such user will install this application and give it to third parties.

PS What exactly can I get from the application in this way? The same as when viewing the same iTools, for example, but already remotely.

In the comments to the article I expect tips on encrypting important information stored on the phone (in the sandbox of the application), ways to protect against such "penetration" into their applications.