FireEye mobile researchers recently discovered potentially
“backdoored” versions of an ad library embedded in thousands of iOS
apps originally published in the Apple App Store. The affected
versions of this library embedded functionality in iOS apps that used
the library to display ads, allowing for potential malicious access to
sensitive user data and device functionality. NOTE: Apple has worked
with us on the issue and has since removed the affected apps.
These potential backdoors could have been controlled remotely by
loading JavaScript code from a remote server to perform the following
actions on an iOS device:
The offending ad library contained identifying data suggesting that
it is a version of the mobiSage SDK [1]. We found 17 distinct versions
of the potentially backdoored ad library: version codes 5.3.3 to
6.4.4. However, in the latest mobiSage SDK publicly released by adSage
[2] – version 7.0.5 – the potential backdoors are not present. It is
unclear whether the potentially backdoored versions of the ad library
were released by adSage or if they were created and/or compromised by
a malicious third party.
As of November 4, we have identified 2,846 iOS apps containing the
potentially backdoored versions of mobiSage SDK. Among these, we
observed more than 900 attempts to contact an ad adSage server capable
of delivering JavaScript code to control the backdoors. We notified
Apple of the complete list of affected apps and technical details on
October 21, 2015.
While we have not observed the ad server deliver any malicious
commands intended to trigger the most sensitive capabilities such as
recording audio or stealing sensitive data, affected apps periodically
contact the server to check for new JavaScript code. In the wrong
hands, malicious JavaScript code that triggers the potential backdoors
could be posted to eventually be downloaded and executed by affected apps.
As shown in Figure 1, the affected mobiSage library included two key
components, separately implemented in Objective-C and JavaScript. The
Objective-C component, which we refer to as msageCore,
implements the underlying functionality of the potential backdoors and
exposed interfaces to the JavaScript context through a WebView. The
JavaScript component, which we refer to as msageJS, provides
high-level execution logic and can trigger the potential backdoors by
invoking the interfaces exposed by msageCore. Each component has its
own separate version number.
src="/content/dam/fireeye-www/blog/images/ibackdoor/ibackdoorfig1.png"
width="233" height="269" />
Figure 1: Key components of backdoored mobiSage SDK
In the remainder of this section, we reveal internal details of
msageCore, including its communication channel and high-risk
interfaces. Then we describe how msageJS is launched and updated, and
how it can trigger the backdoors.
MsageCore implements a general framework to communicate with msageJS
via the ad library’s WebView. Commands and parameters are passed via
specially crafted URLs in the format class="code">adsagejs://cmd¶meter. As shown in the
reconstructed code fragment in Figure 2, msageCore fetches the command
and parameters from the JavaScript context and inserts them in its
command queue.

Figure 2: Communication via URL loading in WebView
To process a command in its queue, msageCore dispatches the command,
along with its parameters, to a corresponding Objective-C class and
method. Figure 3 shows portions of the reconstructed command
dispatching code.

Figure 3: Command dispatch in msageCore
At-risk interfaces
Each dispatched command ultimately arrives at an Objective-C class
in msageCore. Table 1 shows a subset of msageCore classes and the
corresponding interfaces that they expose.
|
|
MSageCoreUIManagerPlugin | width="162" valign="top"> |
MSageCoreLocation | valign="top"> |
MSageCorePluginFileModule
|