November 18, 2014 at 11:50Masque iOS vulnerability check
Recently published an article related to the so-called. "Masque" vulnerabilities in iOS. Excerpt from the article:
As a person familiar with Enterprise certificates firsthand, I definitely wanted to refute / prove the real fact.
So, what is known about the Enterprise license:
1. It is issued exclusively to companies (not to private individuals, detailed information );
2. To obtain an Enterprise license, you must provide Apple with a very serious set of documents. So to specify a nonexistent company does not work;
3. Enterprise licenses are issued exclusively for internal use. The fact that some applications are distributed in this way is the company's risk of being excluded from the iOS Developer Enterprise Program;
4. Installing the application from the site is possible through the manifest file and only via HTTPS;
5. When installing an application signed with an Enterprise license, the user is prompted with the message “Do you really want to install the App_Name application signed with the Company_Name certificate?”, And Company_Name is taken from the certificate.
In order to check for a vulnerability, let’s try to go the path of an attacker.
To sign the 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 the App ID with the identifier "bundle identifier", similar to another application, an error is caused.
Total:
You can only get Provisioning Profiles with the App ID, which in turn cannot be created with the already bundled identifier. And without Provisioning Profiles, we won’t be able to sign the application.
Step 2
There is another way to create the “Wildcard App ID” App ID. The company website says:
We create our wildcard App ID, exactly the same as the application we 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 got the App ID, created Distribution Provisioning Profiles for it, and we can safely sign our application to them.
So, create the project in Xcode and specify the following parameters for it:
The project is an empty Single View Application.
So, the installed program on the phone flaunts 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 such a desktop:
The application is really "jammed." Vulnerability is beginning to be confirmed. Now I wonder, what about the data?
Open the notorious iTools application. Pay attention to the version of the application - it has changed, but the build remains the same (in Xcode, build == 1):
Copy the contents and open the application with the archiver.
And we observe: everything that was BEFORE the reinstallation remained in place!
BEFORE :
AFTER :
As a result, we got the App ID, created Distribution Provisioning Profiles for it. We created a simple (empty) application and installed it on the phone. All the data that was stored in the application is 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, a website or in the mailing list. The user will see the message “Do you really want to install the App_Name application signed with the Company_Name certificate?”, And 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 store is trying to update in such a strange way, and even signed by a certificate of some unknown company, such a user will install this application and give his data to third parties.
PS What exactly can you "get" out of 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 application sandbox), ways to protect against such "penetration" in their applications.
“The vulnerability allows you to install a malicious application on top of an existing one, and this new application will gain access to all the files of the previous one. This is provided that the installed application will have the same bundle identifier that iOS & OS X uses to identify applications at the OS level, for example, when delivering updates to them. Vulnerabilities are affected by all versions of iOS starting with 7.1.1, including the latest iOS 8.1.1 beta. ”
As a person familiar with Enterprise certificates firsthand, I definitely wanted to refute / prove the real fact.
So, what is known about the Enterprise license:
1. It is issued exclusively to companies (not to private individuals, detailed information );
2. To obtain an Enterprise license, you must provide Apple with a very serious set of documents. So to specify a nonexistent company does not work;
3. Enterprise licenses are issued exclusively for internal use. The fact that some applications are distributed in this way is the company's risk of being excluded from the iOS Developer Enterprise Program;
4. Installing the application from the site is possible through the manifest file and only via HTTPS;
5. When installing an application signed with an Enterprise license, the user is prompted with the message “Do you really want to install the App_Name application signed with the Company_Name certificate?”, And Company_Name is taken from the certificate.
In order to check for a vulnerability, let’s try to go the path of an attacker.
To sign the application, you need to create Provisioning Profiles:
Creating Provisioning Profiles
The next step is specifying the App ID:
Choose App ID
But, in order to specify it, you need to create this App ID:
Create an App ID
The image shows that when creating the App ID with the identifier "bundle identifier", similar to another application, an error is caused.
Total:
You can only get Provisioning Profiles with the App ID, which in turn cannot be created with the already bundled identifier. And without Provisioning Profiles, we won’t be able to sign the application.
Step 2
There is another way to create the “Wildcard App ID” App ID. The company website says:
This allows you to use a single App ID to match multiple apps. To create a wildcard App ID, enter an asterisk (*) as the last digit in the Bundle ID field.
Create Wildcard App ID
We create our wildcard App ID, exactly the same as the application we want to replace. In the last part of the App ID (usually the name of the application) we write (*).
Created Wildcard App ID
Next, create a profile for our new App ID.
Creating In-House Provisioning Profiles
Thus, we got the App ID, created Distribution Provisioning Profiles for it, and we can safely sign our application to them.
So, create the project in Xcode and specify the following parameters for it:
Create a project in Xcode
The project is an empty Single View Application.
So, the installed program on the phone flaunts on the desktop:
Desktop with the application that we plan to replace
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 such a desktop:
Desktop, our application successfully replaces Goal
The application is really "jammed." Vulnerability is beginning to be confirmed. Now I wonder, what about the data?
Open the notorious iTools application. Pay attention to the version of the application - it has changed, but the build remains the same (in Xcode, build == 1):
This is how our app looks in iTools
Copy the contents and open the application with the archiver.
And we observe: everything that was BEFORE the reinstallation remained in place!
BEFORE :
The folder structure of the original application
AFTER :
Folder structure after application spoofing
As a result, we got the App ID, created Distribution Provisioning Profiles for it. We created a simple (empty) application and installed it on the phone. All the data that was stored in the application is 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, a website or in the mailing list. The user will see the message “Do you really want to install the App_Name application signed with the Company_Name certificate?”, And 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 store is trying to update in such a strange way, and even signed by a certificate of some unknown company, such a user will install this application and give his data to third parties.
PS What exactly can you "get" out of 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 application sandbox), ways to protect against such "penetration" in their applications.