It is common nowadays to hear news about new families of banking malware for Android devices and how they work. However, the same cannot be said for iOS devices. This may lead us to ask “Is there malware for iOS? And banking malware?
The first question is easy to answer: yes, there is malware for iOS. The second is not so simple. We have not publicly found any malware sample especially designed for the theft of banking credentials, but there could be samples that have not been detected.
Although banking malware has not been detected as such, malicious applications intended for credential theft, especially the Apple ID and password, have been detected for devices with 'jailbreak' (such as the KeyRaider 2015 malware).
The general operation of Apple's operating system makes banking data theft more difficult than in Android. As has been discussed on previous occasions, the technique par excellence used for the theft of banking data on Android devices is the use of 'overlays'.
Through this technique, malicious applications on Android show a phishing window upon detecting that the user is opening their bank’s legitimate application. This way, the user will think that the window requesting the logon data is legitimate.
To display the 'overlay,' malicious applications on Android use services that run in the background and some tricks to determine the application that is running in the foreground and show the 'overlay' with the phishing. Therefore, malware requires three key functionalities for data theft on Android; let's see if iOS provides such functionalities.
Run in background
Yes (with limitations)
Get list of installed applications
Identify foreground application
Show phishing ‘overlays’
As we can see in the above table, Apple's operating system does not seem to provide the functionalities necessary for the theft of banking data. Let's see if the restrictions imposed on iOS applications are really effective and how those restrictions work.
In Android an application can create what is known as a "service". Android services are modules of the application that can run in the background and can be launched from different events, such as when you reinitialize the system.
In addition, applications can request the ‘REQUEST_IGNORE_BATTERY_OPTIMIZATIONS’, permission, which allows them to ignore battery optimizations. This way, they prevent the service running in the background from being stopped by the system due to battery optimizations.
Although an application can run in the background on iOS, there are no services as we know them on Android. In iOS, the developer must indicate the type of activity that the application will perform in the background. This way, the system can apply the correct restrictions based on the activity.
As we can see in the image, Apple allows background execution of applications through 'Background Modes'.
The system selects what restrictions to apply depending on the mode selected by the developer. For example, if 'Location updates' is selected, the system will be responsible for generating an event each time the device location changes. This event will launch the execution of the corresponding code in the application.
These modes make it possible to restrict the connection to the network in case it is not necessary in that mode, or the access to other system features such as location. This also makes it possible to limit the time the application can be running in the background.
List of installed applications
On Android it is possible to obtain the complete list of applications installed on the device, without needing to request additional permissions. This not only allows a banking Trojan to determine if any of its target entities is installed, but also allows another application to know the applications installed by the user, which could be considered a privacy issue.
In iOS it is not possible to obtain the complete list of installed applications. However, it is possible to determine if certain applications are installed. To determine if an application is installed, an iOS application may take advantage of the 'URL Schemes'.
The 'URL Schemes' allow an application to indicate to the operating system that it wishes to handle requests made to URLs with a particular scheme. For example, the Twitter application asks the system to pass URLs that use the “twitter://” scheme to the application for handling.
This functionality is used so that it is the application itself that shows related information when a user clicks on a link with a specific scheme. This way, Twitter can display a tweet or a user's profile when the user clicks on a link having the “twitter://” scheme
In the above image we can see a block of code responsible for checking if it is possible to open a URL whose scheme is “instagram://”.
If the system can open this URL it means that there is an application installed capable of managing this scheme. In this case, the “instagram://” scheme is reserved for the Instagram application (no other application can manage this scheme), so if this URL can be opened, it means that the Instagram application is installed.
For a banking Trojan for iOS to determine whether the application of an affected entity is installed, that application must necessarily manage some URL scheme. Otherwise it cannot determine whether the application is installed or not.
In addition to this way of detecting installed applications, there are other ways through private and undocumented operating system APIs. A banking malware could use these private APIs to obtain the list of installed applications, although it could not be published in the App Store under any circumstances, since the use of these APIs is not allowed and would cause rejection of the application.
Stealing credentials with 'overlays'
As we have mentioned previously, in Android the preferred technique, and the most effective one, is based on the use of phishing 'overlays' at the moment when the user opens the legitimate application. This technique is employed by all popular banking malware families today, such as Anubis Bankbot, Cerberus or Marcher.
In iOS it is not possible to apply this technique, since the restrictions imposed by Apple prevent it. As we have explained, an iOS application is not able to keep running in the background permanently. It can run in the background for a limited time depending on the mode selected by the developer.
However, even if an iOS application were able to run in the background permanently, it would not be able to obtain information about the application that is running in the foreground all the time. So it could not show an 'overlay' as it happens in Android.
The third element necessary for data theft using 'overlays' is to be able to display the 'overlay' itself. This functionality does not exist in iOS either.
An iOS application can not show any window to the user beyond the windows of the application interface itself while running in the foreground. So an application cannot start any other application or show any visual component to the user from any of the available 'background modes'.
Other possibilities to steal credentials
A small part of Android banking malware is based on fake applications that supplant legitimate banking applications. These applications are usually distributed through unofficial 'markets' or websites and forums.
Commonly, legitimate banking entity applications will not work if they are installed on 'rooted' devices, so users may be forced to look for modified applications that eliminate such restrictions. These applications could be infected and primed for banking credential theft.
As with Android, this type of fraudulent applications could exist in iOS. In recent years, the installation of applications signed with company certificates has become popular, allowing applications to be distributed and installed without going through the Apple Store.
'Exodus' (2019) is a recent example of malware for iOS that was distributed using company certificates. In this case, it is a spyware designed to steal sensitive information from users, including photos, videos, contacts, information on the location of the device and telephone conversations.
By not going through the controls of the Apple store, these applications can use private APIs, such as APIs that make it possible to list installed applications, or they could be prepared to steal banking data.
It doesn't have to be a Trojanized banking application, it could be any application. For example, a modified Spotify application to eliminate advertising, which steals user data when logging in, or in case the user makes any payment through the application.
As with the root on Android devices, a jailbreak gives the user full control of the iOS device. The installation of malicious applications or 'tweaks' (application or system modifications) poses a high risk to the user.
A 'tweak' is able to inject code into applications installed on the device, and in the same way that these modifications make it possible to eliminate restrictions and customize applications, they can also be designed to inject malicious code into banking applications or any other type of application.
After the injection of malicious code, the attackers could steal banking data and the user would not even realize it, since they would be using the legitimate application.
No banking malware has been discovered that takes advantage of the jailbreak possibilities to steal credentials. However, malware has been discovered that takes advantage of these possibilities to steal other user data.
Most of the malware for iOS has been distributed through 'tweaks', and its main functionality has consisted of spying on the user, providing the attacker with information on location, SMS, calls and the address book (Xsser mRAT, 2014). In other cases, the malware has been designed to display unwanted advertising to the user, or even buy applications from the official Apple store without the user's consent (AppBuyer, 2014).
Jailbreak is a problem for the security of iOS devices, but it does not mean that non-jailbroken devices are completely protected against these attacks. The same vulnerabilities that make jailbreak possible can be used to compromise the device and install malware on it.
Infection through vulnerabilities
Simply accessing a malicious website can jeopardize user data. Exploiting vulnerabilities in the 'Safari' browser, an attacker could end up installing malicious applications on the device and even take full control of it.
Like Android, iOS may have security vulnerabilities that attackers use to install malicious software on the device through 'exploits'. If these vulnerabilities are at the core of the operating system, the 'exploit' could take full control of the device.
These 'exploits' would allow the attacker, for example, to intercept all communications made by the device, which would make it possible to steal banking credentials or the credentials of any other service.
A recent case of malware distributed through the exploitation of vulnerabilities is the spy malware targeting Tibetan groups (Tibetan Groups Targeted with 1-Click Mobile Exploits). This malware is a spy malware designed to steal contacts, spying through the device's geolocation and obtaining specific data from the infected application.
The distribution of the malicious link through these applications permits the 'exploit' to run the malicious code with the same permissions as the application in which it is opened, allowing attackers access to the documents stored by the application.
This means that if the user visits the link through WhatsApp, for example, the malicious code can access the documents stored by the WhatsApp application (chat messages, multimedia files, etc.)
Infection through malicious 'exploits' is one of the most dangerous, since, as in the case of the malware targeting Tibetan groups, the user just has to visit the malicious website. Even so, the use of such vulnerabilities for banking credential theft is unlikely.
Finding security vulnerabilities is very costly, and once the vulnerability is discovered it is much more profitable to sell it. The high price of these vulnerabilities means they are usually used for attacks directed at entities of major interest.
Infection through official stores
Several malicious applications published on the official Android store, Google Play, have been detected in recent years. It is true, though, that Google has toughened the checks for Google Play applications in the last year, trying to reduce the possibility of attackers distributing malware through their store.
In the case of iOS, its official store, the App Store, has done manual reviews of applications since its launch. And although these checks make it difficult for any malicious application to be published, some malicious applications have been published in the App Store as well.
The first of the malicious applications that slipped into the official Apple store was 'Instastock', developed by security researcher Charlie Miller in 2011.
The application exploited a vulnerability in the iOS operating system, as a proof of concept. It was developed and sent to the App Store to test whether the reviews were robust enough. The result was that the application ended up published in the store.
More recently, in 2015, researchers from the University of Indiana sent a new application to the App Store that included a proof of concept of 'XARA' vulnerabilities. These vulnerabilities allowed a malicious application to access resources stored by any other installed application. This proof of concept was also published in the Apple app store.
According to our analysis, we can say that we have very rarely found banking malware per se targeting iOS devices, although there is spyware that could rob banking data.
Thanks to the restrictions implemented by Apple in its operating system, malware possibilities on iOS are very limited, whether it’s banking malware or more general purpose. This considerably reduces attacker interest.
The controls put in place by Apple and Google in their respective application stores reduce the chances that a malicious application will end up published in official stores. However, the controls are not insurmountable and several malicious applications have been published over the years. Even so, both platforms, especially Google, have increased their efforts to improve their application review processes.
The three main features necessary for the theft of banking credentials on Android (execution of background services, list of applications in the foreground and execution of 'overlays') are not available on iOS. In the case of background services, iOS allows developers to run their applications in the background, but in a restricted way and based on the activity they are going to develop.
An effective way to steal banking data on iOS is to use malicious 'tweaks' to inject code into other applications. In this way, malware could inject code into legitimate banking entity applications and steal logon credentials without the user noticing.
Another option would be to distribute fraudulent applications supplanting those of banking entities. To do this, they can distribute the IPA installation file signed with a company certificate without going through the Apple Store.
The difficulty involved in this attack is to obtain a company certificate without providing real attacker data which could then lead to their location and arrest if they are discovered.
Finally, there is also the possibility of using 'exploits' for security vulnerabilities that allow malicious applications to be installed or even enable full control of the device, permitting the attacker to intercept network communications made by the infected device. However, this type of attack vector is often used in attacks targeting specific groups of interest, due to the difficulty in finding and exploiting these vulnerabilities.
The restrictions imposed by Apple greatly hinder the distribution and development of malware for iOS. However, and as we have seen, this does not prevent attackers from finding different paths to infect iOS devices. iOS device limitations reduce the area for attack, but do not make iOS invulnerable by any means.