We study MITER ATT & CK. Mobile Matrices: Device Access. Part 1

Initial Access to a Mobile Device (Initial Access)

Links to all parts:
Part 1. Initial access to a mobile device (Initial Access)
Part 2. Persistence and Escalation of privileges
Part 3. Obtaining credentials (Credential Access)
Part 4. Protection bypass (Defense Evasion)
Part 5. Discovery and Lateral Movement.

I begin the next series of publications ( see previous ones ) devoted to the study of tactics and techniques for implementing hacker attacks, included in the MITER ATT & CK knowledge base . The section will describe the techniques used by cybercriminals at every stage of the attack chain on mobile devices.

Under the cut - the main vectors of compromising mobile devices, aimed at obtaining by the attacker a "presence" in the attacked system.

The author is not responsible for the possible consequences of applying the information set forth in the article, and also apologizes for possible inaccuracies made in some formulations and terms. The information published is a free retelling of the contents of ATT @ CK Mobile Matrices: Device Access .

Delivery of a malicious application through an authorized app store (Deliver Malicious App via Authorized App Store)

Platform: Android, iOS
Description: Malicious applications are the most common way to “presence” an attacker on mobile devices. Mobile OSs are often configured to install applications only from authorized stores (Google Play Store or Apple App Store), so the adversary may try to place their malicious application in an authorized application store.

Application stores usually require developer registration and have tools to detect malicious applications, but opponents can use some ways to bypass store protection:

• Download malicious code during application execution after installing it from the application store;
• Obfuscation of files and information;
• Use of compromised credentials and digital signatures of bona fide mobile application developers;
• Testing the possibility of bypassing systems for automated analysis of the security of mobile applications in the application store

An adversary can intentionally place malicious code in an application to determine if it works in the security analysis environment of the target store and, if necessary, disable the launch of malicious content during analysis. Attackers can also use fake identities, payment cards, etc. when creating developer accounts for the further publication of malicious applications in stores.

In addition, opponents can also use compromised Google user accounts to take advantage of the remote installation of applications on android devices associated with a controlled Google account (using this technique you can only install applications from the Google Play Store remotely).

Protection Recommendations:In a corporate environment, it is recommended to organize application checks for vulnerabilities and unwanted actions (malicious or violating confidentiality), implementation of application installation restriction policies or “Bring Your Own Device (BYOD)” policies (bring your own device), which impose restrictions only on the enterprise controlled part of the device. Training, trainings and user guides will help to support a certain configuration of corporate devices, and sometimes even prevent specific risky user actions.

EMM / MDM systems or other solutions for protecting mobile devices can automatically detect unwanted or malicious applications on corporate devices. Software developers usually have the ability to scan application stores for unauthorized applications that were sent using their developer ID.

Delivering a malicious application using other means (Deliver Malicious App via Other Means)

Platform: Android, iOS
Description: Despite the possible prohibition of installing applications from third-party sources on the target device, an adversary can deliberately avoid placing a malicious application in authorized application stores to reduce the risk of potential detection.

Alternative application delivery methods:

• Spearphishing Attachment - application as an attachment to an e-mail message;
• Phishing link - a link to a mobile application package in an email or text message (SMS, iMessage, Hangouts, WhatsApp, etc.), a website, a QR code b, etc .;
• Third-party application store - the application is published in the application store, in which there is no security control similar to an authorized store.

In the case of iOS, an adversary can also try to obtain a key pair and an Enterprise distribution key certificate in order to spread the malicious application without publishing to the AppStore.

Protection recommendations: In iOS, activating the allowEnterpriseAppTrust and allowEnterpriseAppTrustModification parameters will prevent users from installing applications signed by the Enterprise distribution key.

iOS version 9 and above requires the explicit consent of the user to install the signed Enterprise distribution key application not from the AppStore, so users should be trained not to agree to install the application if they are not sure about the source of the application distribution.

On Android, to install applications from third-party sources, the “Unknown Sources” parameter must be enabled, so users should be trained in activating and controlling this parameter.

EMM / MDM or other solutions for protecting mobile devices can identify the presence of applications installed from third-party sources, identify Android devices that are allowed to install applications from third-party sources, and determine the presence of Android or iOS application packages in email messages.

Shadow download of malicious content (Drive-by Compromise)

Platform: Android, iOS
Description: An adversary can gain access to a mobile system through a hidden code download, which is executed when a user visits a website controlled by an attacker. The implementation of this technique requires a corresponding vulnerability in the user's web browser. For example, a website may contain malicious media content designed to exploit the Stagefright vulnerability in Android.

Protection recommendations: The purchase of devices from suppliers or mobile operators that guarantee the prompt provision of security updates. You should stop using vulnerable devices that do not receive security updates due to expiration of the support period.

In a corporate environment, it is recommended to restrict and block access to corporate resources from mobile devices on which the latest security updates are not installed. Access from Android devices can be controlled based on patches. Access from iOS devices can be controlled based on the OS version.

It is recommended to use only the latest versions of mobile operating systems, which, as a rule, contain not only patches, but also have an improved security architecture that provides resistance to previously undetected vulnerabilities.

Exploit via Charging Station or PC

Platform: Android, iOS
Description: A mobile device can be connected (usually via USB) to a compromised charging station or PC, with which the enemy can try to gain access to the device.

Famous demonstrations of successful attacks:

• The introduction of malicious applications in iOS devices ( source );
• Exploiting Nexus 6 or 6P vulnerabilities via USB, including intercepting phone calls, network traffic and receiving data about the physical location of the device;
• Exploiting Android vulnerabilities via USB using the example of Google Pixel 2.

Cellebrite and Grayshift products are expected to use physical access to data ports to unlock passwords on some iOS devices.

Protection recommendations: Corporate security policies should prevent the inclusion of USB debugging on Android devices (if this is not required, for example, when the device is used for application development). On devices that provide the ability to unlock the bootloader, allowing you to modify the firmware, periodic checks are required to actually lock the bootloader.

It is not recommended that you use public charging stations or computers to charge your devices. Provide users with chargers purchased from a trusted supplier. Users are not recommended to add trusted devices unless necessary.

Exploit via Radio Interfaces

Description: Vulnerabilities may be exploited via the cellular communication interface or other radio interfaces.

Baseband exploits A

message sent to a mobile device via a radio interface (usually cellular, but it can also be bluetooth, GPS, NFC, Wi-Fi , etc.) could exploit vulnerabilities in the code that processes the received message (for example, a vulnerability in Samsung S6 ) .

Malicious SMS messages

SMS may contain content intended for exploiting SMS analyzer vulnerabilities on the receiving device. SMS may also contain a link to a website containing malicious content. Vulnerable SIM Cardscan be remotely operated and reprogrammed using SMS messages.

Protection recommendations: Purchase devices from suppliers or mobile operators that guarantee the prompt provision of security updates. You should stop using vulnerable devices that do not receive security updates due to expiration of the support period.

In a corporate environment, it is recommended to restrict and block access to corporate resources from mobile devices on which the latest security updates are not installed. Access from Android devices can be controlled based on patches. Access from iOS devices can be controlled based on the OS version.

It is recommended to use only the latest versions of mobile operating systems, which, as a rule, contain not only patches, but also have an improved security architecture that provides resistance to previously undetected vulnerabilities.

Install Insecure or Malicious Configuration

Platform: Android, iOS
Description: An adversary may try to install an unsafe or malicious configuration on a mobile device using a phishing email or a text message containing a configuration file as an attachment or a web link to configuration parameters. When setting configuration parameters, the user can be tricked by using social engineering methods. For example, an unwanted certificate of a certification authority (CA) can be placed in the device’s trusted certificate store, which increases the susceptibility of the device to man-in-the-middle attacks.

On iOS, malicious configuration profiles may contain unwanted Certificate Authority (CA) certificates or other insecure settings, such as the address of an unwanted proxy or VPN server to route device traffic through an attacker system. The device can also be enrolled in an enemy mobile device management system (MDM).

Protection recommendations: In iOS 10.3 and above, an additional step has been added that requires user action to install new trusted CA certificates. On Android, applications compatible with Android 7 and higher (API level 24), by default, trust only the CA certificates that are delivered with the OS, and not added by the user or administrator, which generally reduces the OS's susceptibility to middle-person attacks.

As a rule, unsafe or malicious configuration settings are not set without user consent, so users should be aware that they should not set unexpected configuration settings (CA certificates, iOS configuration profiles, establishing a connection to MDM).

On Android, a user can view trusted CA certificates through device settings to identify suspicious certificates. Corporate security systems for mobile devices can similarly check the certificate store for anomalies automatically.

On iOS, a user can view installed configuration profiles through device settings and identify suspicious profiles. Similarly, MDM systems can use the iOS MDM API to check lists of installed profiles for anomalies.

Lock Screen Bypass

Platform: Android, iOS
Description: Having physical access to a mobile device, an adversary may try to bypass the device’s lock screen.

Biometric Spoofing An

adversary may try to trick the biometric authentication mechanism. iOS partially mitigates this attack by requiring a device password, not a fingerprint, after each reboot and 48 hours after the last unlock. Android has similar protection mechanisms.

Guessing the unlock code or simple brute force An

adversary may try to brute force or in some other way guess the access code, including physical observation (sohulder surfing) while the user is using the device.

Other lock screen exploits

Android 5 and iOS 6 and other mobile devices periodically demonstrate how to exploit vulnerabilities to bypass the lock screen. Vulnerabilities are usually fixed by the device or OS developer as soon as they become aware of their existence.

Protection recommendations: Corporate security policies for mobile devices should set requirements for password complexity on the device. Corporate policy may include the automatic destruction of all data on the device when repeatedly entering the wrong password. Both of these policies are aimed at preventing brute force attacks, guessing or "spying" access codes.

If necessary, corporate policy may also prohibit biometric authentication. However, biometric authentication is more convenient than using a long, complex access code, because you don’t have to enter it every time.
It is recommended that you install security updates and use the latest versions of mobile OS.

Repackaged Application

Platform: Android, iOS
Description: An adversary can download an application, disassemble it, add malicious code, and then reassemble it ( example ). The rebuilt application will look like the original, but contain additional malicious functions. Then, such an application can be published in application stores or delivered to the device using other techniques.

Protection recommendations: Install applications only from authorized stores that are less likely to contain malicious repackaged applications.

EMM / MDM systems and other enterprise-level mobile application security tools can automatically detect unwanted, unknown, insecure, or malicious applications on devices.

Supply Chain Compromise

Platform: Android, iOS
Description: Supply chain compromise is a modification of a software product and product delivery mechanisms before they are received by a consumer in order to compromise data or a system. Opponents can exploit unintentional vulnerabilities, so in many cases it is difficult to determine if the vulnerable functionality is the result of a malicious or unintentional error.

Identification of vulnerabilities in third-party software libraries

Third - party libraries included in mobile applications may contain malicious code that violates privacy or creates vulnerabilities. There are known examples of vulnerabilities and security issues in mobile advertising libraries.

Distribution of malicious software development tools

As the XcodeGhost attack demonstrated , application developers can use modified versions of software development tools (for example, compilers) that automatically inject malicious code or vulnerabilities into the application.

Protection recommendations: Insecure third-party libraries can be detected by various application verification methods. For example, the Google Application Security Improvement Program detects the use of third-party libraries with known vulnerabilities in the Android applications available on the Google Play store. Malware development tools and modified software developers tools can be detected using file integrity monitoring systems on developers' computers.