This document summarizes a vulnerability in iOS that allows a malicious app installed via enterprise/ad-hoc provisioning to replace a previously installed app from the App Store if they share the same bundle identifier. It describes how an attacker could exploit this by social engineering a user to install a malicious app, which would then overwrite a legitimate app and potentially access its data or impersonate its interface. The document also outlines how this vulnerability presents a greater risk than on Android and discusses techniques used in proof-of-concept attacks, including bypassing a new alert in iOS 8 through URL scheme hijacking. It concludes with recommendations to mitigate the risk, such as always updating iOS and being wary of installing outside the App Store.

1. PREPARED BY:
Shakti Chauhan 12xxxxxxx
Ruchika Jain12xxxxxxx

3.  In July 2014, FireEye Security Company with the security
researchers Stefan Esser and Jonathan Zdziarski discovered1 that
an iOS app installed using enterprise/ad-hoc provisioning could
replace another genuine app previously installed through the
App Store, as long as both apps used the same bundle identifier.
 This vulnerability exists because iOS doesn't enforce matching
certificates for apps with the same bundle identifier.
 The malicious app could be downloaded and installed by a user
via social engineering attacks: once done that, the new app
overwrites the old one already installed on the device.
 An exception is represented by the iOS preinstalled apps: they
can’t be substituted.
 It is important to note that this attack poses iOS users at a
greater risk than the Android counterpart. In fact on Android
exists an option that disallow users to install application from
sources different from the Play Store, while on iOS this choice is
not available.

5. These are the main threat scenarios of this kind of attack:
 Non jailbroken iOS Apple devices are threatened too;
 A user may not be conscious of having a malicious app on his
device because it replaces one that is regularly installed;
 The malicious app can read all the unencrypted data stored by
the previous app, but the Keychain, and send them to their
servers;
 The malicious app can mount a phishing attack mimicking the
original UI app and it can steal the related credentials;
 The malicious app can be launched although the presence of an
alert prompt when launching enterprise-signed apps for the first
time;
 The malicious app can hijack the URL Schemes of a legitimate
popular app in order to perform phishing attacks to steal
credentials or gather data intended to be shared between two
trusted apps.

7. Environment Setup
 An enterprise provisioning profile matched with a developer
certificate were used to perpetrate the attack: the public key
inside the first file is related to the private key of the certificate
installed on the host where the compilation of the app is
performed.
 The app is installed on the device via OTA, using a local HTTPS
web server.
 It has to be noticed the fact that developer certificates and
mobile enterprise provisioning files can be easily found on
Internet through ad-hoc Google dorks. Following a screenshot of
a website where these files can be located:
 For the signing part of the created IPA, the iReSign tool was used
(https://github.com/maciekish/iReSign):
 As we can see, the IPA can be signed with a smuggled developer
certificate.

8.  On 19 February 2015 FireEye security researchers have
presented a new kind of Masque Attack exploiting URL Schemes
vulnerabilities2.
 On iOS 8, whenever a user is launching an enterprise-signed app
for the first time, he is asked to trust or not the new signing
party, as can be seen from the following screenshot:
 If a user clicks on “Don’t trust” the app does not open.
 It has been discovered that this precaution is not enough:
indeed, it is possible to bypass this alert message exploiting the
present implementation of URL Schemes.
 This can be demonstrated using the following setup: An Apple
device with iOS 8.1.2 installed; A widespread installed app like,
for example, Facebook; An enterprise-signed app registering
an URL Scheme identical to that used by the previous app.
 So, it is possible to create an enterprise-signed app registering
an URL Schemes used by Facebook, fb://, and bypass the alert
prompt calling that URL Scheme to open the malicious app.

11.  Update iOS on the device to a version >= 8.1.3 as suggested
above. Note that the URL Schemes Hijacking vulnerability
illustrated at the end of section 2.4 has not yet been fixed;
 Don’t install apps from third-party sources other than
Apple’s official App Store or the user’s own organization;
 Don’t click “Install” on a pop-up from a third-party web page;
 When opening an app, if iOS shows an alert with “Untrusted
App Developer”, click on “Don’t Trust” and uninstall the app
immediately. Nevertheless note that this alert can be
bypassed as shown in section 2.4 if iOS >= 8.1.3 is not
installed.

13. THANK
YOU