Category Archives: apple

Google Faces Privacy Lawsuit Over Tracking Users in Incognito Mode

A $5 billion class-action lawsuit filed in a California federal court alleges that Google's Chrome incognito mode collects browser data without people’s knowledge or consent.

Contact tracing mobile apps hold potential to stop COVID-19 – but governments have missed the mark so far

By Brian Jackson Research Director, Info-Tech Research Group     Several thousand Swiss citizens – mostly members of academia, the Swiss Army, and hospital staff – just began what may be the most important trial of a mobile app in human history. On Monday, May 25, SwissCovid became the first official application supported by Apple…

Apple fixes CVE-2020-9859 zero-day used in recent Unc0ver jailbreak

This week Apple released security patches to address the CVE-2020-9859 zero-day vulnerability that had been used to jailbreak iPhones devices.

Apple released security patches to address the CVE-2020-9859 zero-day vulnerability in the iOS kernel that had been used to jailbreak iPhones.

The flaw was discovered by a team of cyber-security researchers and hackers that also released a new jailbreak package dubbed Unc0ver (from the name of the team that devised it) that works on all recent iOS versions.

Jailbreaking an iOS mobile device it is possible to remove hardware restrictions implemented by the Apple’s operating system, Jailbreaking gives users root access to the iOS file system and manager, this allows them to download and install applications and themes from third-party stores.

By default, Apple does not allow users to have full control over their iPhones and other iOS devices, citing security reasons.

The Unc0ver team released Unc0ver 5.0.0, the latest version of their jailbreak, which can root and unlock all iOS devices, even those running the latest iOS v13.5.

The jailbreak exploits a the CVE-2020-9859 zero-day in the iOS operating system that was discovered by Pwn20wnd, a member of the Unc0ver team, and that has yet to be addressed by Apple.

Pwn20wnd states that #unc0ver v5.0.0 will be a big milestone for jailbreaking because it is the first zero-day jailbreak released since iOS 8 that was released in September 2014.

The Unc0ver team tested the jailbreak on iOS 11 through iOS 13.5, the software did not work on iOS versions 12.3 to 12.3.2 and 12.4.2 to 12.4.5.

What makes this jailbreak outstanding is that according to Pwn20wnd it doesn’t impact Apple’s iOS security features.

According to the CERT Coordination Center, the kernel vulnerability could allow a malicious application to achieve unsandboxed, kernel-level code execution and the jailbreak works on modern iOS devices that use a CPU that supports Pointer Authentication Code (PAC), which indicates that PAC does not prevent exploitation of this vulnerability.

Now Apple addressed the vulnerability and revealed that the root cause of the flaw was memory consumption.

Apple released iOS 13.5.1 and iPadOS 13.5.1 version for iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch 7th generation.

The IT giant also released security updates for macOS High Sierra 10.13.6 and macOS Catalina 10.15.5 (macOS Catalina 10.15.5 Supplemental Update, Security Update 2020-003 High Sierra), Apple TV 4K and Apple TV HD (tvOS 13.4.6), and Apple Watch Series 1 and later (watchOS 6.2.6) to patch the vulnerability.

Pwn20wnd confirmed that iOS 13.5.1 addressed the vulnerability exploited by their jailbreak.

Pierluigi Paganini

(SecurityAffairs – Apple, jailbreak)

The post Apple fixes CVE-2020-9859 zero-day used in recent Unc0ver jailbreak appeared first on Security Affairs.

Cyber Security Roundup for June 2020

A roundup of UK focused Cyber and Information Security News, Blog Posts, Reports and general Threat Intelligence from the previous calendar month, May 2020.

EasyJet's disclosure of a "highly sophisticated cyber-attack", which occurred in January 2020, impacting 9 million of their customers was the biggest cybersecurity story of May 2020 in the UK. Although no details about this 'cyber-attack' were disclosed, other than 2,208 customers had their credit card details accessed.  


Using terms like "highly sophisticated" without providing any actual details of the cyberattack makes one think back to when TalkTalk CEO Dido Harding described a cyber-attack as "significant and sustained cyber-attack" in 2015. In TalkTalk's case, that cyber attack turned out to be a bunch of teenage kids taking advantage of a then 10-year-old SQL injection vulnerability.  City A.M. described Dido's responses as "naive", noting when asked if the affected customer data was encrypted or not, she replied: "The awful truth is that I don’t know". Today Dido is responsible for the UK governments Track, Test and Trace application, which no doubt will ring privacy alarms bells with some. 

Back to the EasyJet breach, all we know is the ICO and the NCSC are supporting UK budget airline, EasyJet said "We take issues of security extremely seriously and continue to invest to further enhance our security environment. There is no evidence that any personal information of any nature has been misused, however, on the recommendation of the ICO, we are communicating with the approximately nine million customers whose travel details were accessed to advise them of protective steps to minimise any risk of potential phishing. We are advising customers to be cautious of any communications purporting to come from EasyJet or EasyJet Holidays." 

It will be interesting to see the DPA enforcement line Information Commission's Office (ICO) adopts with EasyJet, especially considering the current COVID-19 impact on the UK aviation industry.  Some security commentators have called ICO a "Toothless Tiger" in regards to their supportive response, an ICO label I've not heard since long before the GDPR came into force. But the GDPR still has a sting its tail beyond ICO enforcement action in the UK, in that individuals impacted by personal data breaches can undertake a class-action lawsuit. So then, it can be no real surprise to law firm PGMBM announce it has issued a class-action claim in the High Court of London, with a potential liability of an eye-watering £18 billion!. If successful, each customer impacted by the breach could receive a payout of £2,000.

The 2020 Verizon Data Breach Investigations Report (DBIR) was released, the most valuable annual report in the cybersecurity industry in my humble opinion. The 2020 DBIR used data compiled before COVID-19 pandemic.  The report analyses 32,002 security incidents and 3,950 confirmed breaches from 81 global contributors from 81 countries.
  • 86% of data breaches for financial gain - up from 71% in 2019 
  • 43% web application (cloud-based) - these attacks have doubled, reflecting the growth in the use of cloud-based services.
  • 67% of data breaches resulted from credential theft, human error or social attacks. 
  • Clearly identified cyber-breach pathways enable a “Defender Advantage” in the fight against cyber-crime 
  • On-going patching successful - fewer than 1 in 20 breaches exploit vulnerabilities
The vast majority of breaches continue to be caused by external actors.
  • 70% with organised crime accounting for 55% of these. 
  • Credential theft and social attacks such as phishing and business email compromises cause the majority of breaches (over 67%), specifically:
    • 37% of credential theft breaches used stolen or weak credentials,
    • 25% involved phishing
    • Human error accounted for 22%
The 2020 DBIR highlighted a two-fold increase in web application breaches, to 43%, and stolen credentials were used in over 80% of these cases. Ransomware had a slight increase, found in 27% of malware incidents compared to 24% in the 2019 DBIR with 18% of organisations reported blocking at least one piece of ransomware last year.

REvil (aka Sodinokibi) hackers are said to have stolen celebrity data from a law firm 'Grubman Shire Meiselas & Sacks'. With 756 gigabytes of personal data, emails, and contract details were taken, including Lady Gaga, Madonna, Elton John, Barbara Streisand, Bruce Springsteen and Mariah Carey to name a few. 

Pitney Bowes was hit with ransomware for the second time in 7 monthsPitney Bowes said attackers breached company systems and accessed “a limited set of corporate file shares” that “contained information used by our business teams and functional groups to conduct business-related activities.” News reports state the Maze ransomware group is behind the attack, threatening to post confidential if Pitney Bowes does not pay up.

Amazon's UK website was defaced with racist abuse,  which appeared on multiple listings on its UK website. Amazon has not disclosed how long the racist language remained on the site, but it sparked outrage on Twitter, Amazon said: "We investigated, removed the images in question and took action against the bad actor".

LogMeOnce, a password identity management suite provider, has published a detailed interview with myself titled 'Passwords are and have always been an Achilles Heel in CyberSecurity'. In the Q&A I talk about Passwords Security (obviously), Threat Actors, IoT Security, Multi-Factor Authentication (MFA), Anti-Virus, Biometrics, AI, Privacy, and a bit on how I got into a career in Cybersecurity.

BLOG
NEWS
VULNERABILITIES AND SECURITY UPDATES
AWARENESS, EDUCATION AND THREAT INTELLIGENCE

    FBI finally unlock shooter’s iPhones, Apple berated for not helping

    The FBI's Apple problem.

    The Guardian view on an NHS coronavirus app: it must do no harm | Editorial

    Smartphones can be used to digitally trace Covid-19. But not if the public don’t download an app over privacy fears – or find it won’t work on their device

    The idea of the NHS tracing app is to enable smartphones to track users and tell them whether they interacted with someone who had Covid-19. Yet this will work only if large proportions of the population download the app. No matter how smart a solution may appear, mass consent is required. That will not be easy. Ministers and officials have failed to address the trade-offs between health and privacy by being ambiguous about the app’s safeguards.

    Instead of offering cast-iron guarantees about the length of time for which data would be held; who can access it; and the level of anonymity afforded, we have had opacity and obfuscation. It is true that we are dealing with uncertainties. But without absolute clarity about privacy the public is unlikely to take up the app with the appropriate gusto.

    Continue reading...

    Crescendo: Real Time Event Viewer for macOS

    Prior to 2017, researchers couldn’t easily monitor actions performed by a process on macOS and had to resort to coding scripts that produced low level system call data. FireEye released Monitor.app in 2017 that enabled collection of information on macOS at a higher level; at a simplified data set versus something like Dtrace. I created many versions of Monitor.app over the years and have received very positive feedback from users. Recently though, users have noticed it doesn't work on macOS Catalina (10.15)...

    Originally, a kernel extension was required to provide the inspection capabilities offered by Monitor.app. Unfortunately, kernel extensions are running in privileged mode which has very little protection from software bugs that may lead to system instability. This means kernel extensions should only be used if absolutely necessary. Microsoft and Apple have started providing engineers more userland alternatives to accomplish what previously required writing kernel code.

    In Catalina, Apple released the Endpoint Security Framework (ESF) to provide a robust and (more importantly) safer way of getting access to internal operating system artifacts. Being a security guy, I’m not a huge fan when apps must ship with kernel extension to get their job done and I think this is a move in the right direction. With the coming release of 10.15.4, Apple will now pop-up a warning when a kernel extension is loaded that uses a set of these deprecated kernel programming interfaces (KPIs).

    Now seemed like a good time to kick the tires on the Endpoint Security Framework. Also, what engineer doesn’t love to learn new languages, so why not write it all in Swift as well?

    Introducing Crescendo

    Crescendo is a real time event viewer for macOS that uses the ESF to show process executions and forks, file events, share mounting events, kernel extension loads, and IPC event data. ESF provides a vast amount of data, but the goal was to just pick out the things that analysts would be interested in when analyzing a piece of malware or trying to understand how a process (or component) works. Just the right amount of data without being a firehose of events to the user.

    Here are some of the features of Crescendo:

    • System Extension using Endpoint Security Framework
    • Real time event viewer and event detail viewer
    • Search for easy filtering of events by process, PID, username, or event type
    • Filters for unsigned apps vs apple signed apps
    • Ability to export all events to JSON
    • Context highlighting when unsigned apps are executed

    Apple has added some extra security features that require some extra setup for enabling Crescendo’s system extension. Head on over to the Getting Started section in the README to get started. I'm hopeful this inconvenience will be fixed in future versions.

    Oh, One More Thing...

    Crescendo is being released open source under the MIT license! It consists of a ready to use framework that wraps the ESF with a Swift interface, removing some of the nuances and providing a simple callback for event data. This way other developers don't have to understand all the inner details of the Endpoint Security Framework. One caveat, if you wish to use the framework in your own app, you must obtain an entitlement from Apple

    Missing a feature you’d like to see? Submit a Pull Request!

    Head over to the Crescendo Github to learn more and download the latest release.

    Living off the Orchard: Leveraging Apple Remote Desktop for Good and Evil

    Attackers often make their lives easier by relying on pre-existing operating system and third party applications in an enterprise environment. Leveraging these applications assists them with blending in with normal network activity and removes the need to develop or bring their own malware. This tactic is often referred to as Living Off The Land. But what about when that land is an Apple orchard?

    In recent enterprise macOS investigations, FireEye Mandiant identified the Apple Remote Desktop application as a lateral movement vector and as a source for valuable forensic artifacts.

    Apple Remote Desktop (ARD) was first released in 2002 and is Apple’s “desktop management system for software distribution, asset management, and remote assistance”. An ARD deployment consists of administrator and client machines. While the administrator app must be downloaded from the macOS App Store, the client application is included natively as part of macOS. Client systems must be added to the client list on an administrator system manually, or they can be discovered via Bonjour if they are in the same local subnet as the administrator system. In a typical enterprise environment deployment, managers would be the ARD administrators and have the ability to view, manage, and remotely control their managed personnel’s workstations via ARD.

    Lateral Movement

    Mandiant has observed attackers using the ARD screen sharing function to move laterally between systems. If remote desktop was not enabled on a target system, Mandiant observed attackers connecting to systems via SSH and executing a kickstart command to enable remote desktop management. This allowed remote desktop access to the target systems. The following is an example from the macOS Unified Log showing a kickstart command used by an attacker to enable remote desktop access for all users with all privileges:


    Figure 1: Kickstart command example

    During an investigation, you can use a few different artifacts to trace this activity. Execution of the kickstart command modifies the contents of the configuration file /Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd to contain the string “enabled”. SSH login activity can be found in the Apple System Logs or Audit Logs. Execution of the kickstart command can be found in the Unified Logs, as seen in Figure 1.

    An ARD administrator has a substantial amount of power available to them, similar to compromising an administrator account in a Windows environment. By compromising an account that has access to ARD administrator system, an attacker can perform any of the following actions:

    • Remotely control VNC-enabled machines, including in “Curtain Mode” which hides the remote actions from the local workstation’s screen
    • Transfer files
    • Remotely shut down or restart multiple machines simultaneously
    • Schedule tasks
    • Execute AppleScript and UNIX shell scripts

    Apple’s ARD web page and the ARD help page contain more details about ARD’s capabilities.

    ARD Reporting as a Forensic Force Multiplier

    Along with remote system control functionality, Apple Remote Desktop’s asset management capabilities include conducting remote Spotlight searches, file searching, generating software version information reports, and more importantly, generating application usage and user history reports. The reporting process generally follows these steps:

    1. Client systems compute reports and cache the data locally before transferring them to the administrator system (the default policy is to begin this at 12:00 AM local time, daily).
    2. Data received from clients is cached on the administrator system. Alternatively, a macOS system with the administrator version of ARD installed can be set up as a “Task Server” for a centralized collection option.
    3. Cached data is written to SQLite database on the administrator system

    The cached data is stored in various subdirectories under the /private/var/db/RemoteManagement/ parent directory. The directory has the following structure:


    Figure 2: /private/var/db/RemoteManagement/ directory structure

    This directory structure is present on all systems, but which files exist in which directories depends on whether the system is an ARD client or administrator system.

    Artifacts from ARD Client Systems

    There is one directory that is the focus for investigations on client systems: /private/var/db/RemoteManagement/caches/. This directory contains the following files, which are the local client data cache that is periodically reported to the administrator system. Do note, however, that these files are routinely deleted by the system, so they may not be present. These files are typically deleted from the client system once they are transmitted to the administrator system. Once transmitted, the data is stored on the administrator system.

    File

    Description

    AppUsage.plist

    plist file containing application usage data

    AppUsage.tmp

    Binary plist file containing application usage data, often the same as or less thorough than AppUsage.plist

    asp.cache

    Binary plist of system information

    filesystem.cache

    Database containing an index of the entire file system, including users and groups

    sysinfo.cache

    Binary plist containing system information, some of which is also present in asp.cache

    UserAcct.tmp

    Binary plist containing user login activity

    Table 1: ARD cache files

    In our experience, the most useful information available from these files is application usage and user activity.

    Application Usage

    The RemoteManagement/caches/AppUsage.plist file contains one key per application, where each key is the full path of the application, such as file:///Applications/Calculator.app/.

    Each application key contains a dictionary that includes a “runData” array and a “Name” string, which is the friendly name of the application, such as “Calculator”, as seen in Figure 3.


    Figure 3: AppUsage.plist structure

    Each “runData” array contains at least one dictionary consisting of the following keys and values:

    Key

    Value Format

    Description

    wasQuit

    Boolean: true or false

    Indicator of whether or not the application was quit prior to the last report time. This field may not exist if the value is not “true”.

    Frontmost

    Number of seconds

    Total duration which the application was “frontmost” on the screen

    Launched

    macOS absolute timestamp

    Time the application was launched

    runLength

    Number of seconds

    Duration the application was run

    username

    String

    User who launched the application

    Table 2: AppUsage.plist runData keys and values

    Of the two application usage cache artifacts, RemoteManagement/caches/AppUsage.plist usually contains the same or more content than RemoteManagement/caches/AppUsage.tmp.

    User Activity

    The RemoteManagement/caches/UserAcct.tmp file is a binary plist that contains user activity that can be correlated with other artifacts on a macOS systems, such as the Apple System Logs or Audit Logs. The file contains keys with the short name of each user logged on the system.

    Each key contains a dictionary that includes a “uid” string with the user’s UID, and an array for each login type: console, tty, or SSH. Each login-type array contains at least one dictionary consisting of the following keys and values:

    Key

    Value Format

    Description

    inTime

    macOS absolute timestamp

    Time the user logged in

    outTime

    macOS absolute timestamp

    Time the user logged out

    host

    String

    Originating host for remote login. This field has been observed to not be consistently present.

    Table 3: UserAcct.tmp keys and values

    Artifacts From ARD Administrator Systems

    The data outlined in Table 1 is reported to the administrator system daily. The files are then stored in the RemoteManagement/ClientCaches/ directory. Each file is renamed to the MAC address of the reporting system and placed into the appropriate subdirectory, as seen in Table 4. The subdirectories contain the following:

    Subdirectory

    Data Contained in Each File

    ApplicationUsage/

    AppUsage.plist files

    SoftwareInfo/

    Filesystem.cache files

    SystemInfo/

    Sysinfo.cache files

    UserAccounting/

    UserAcct.tmp files

    Table 4: /private/var/db/RemoteManagement/ClientCaches/ subdirectories

    Additionally, there is a plist file, RemoteManagement/ClientCaches/cacheAccess.plist that contains keys of MAC addresses with values of more MAC addresses. The purpose and context for this file has yet to be determined.

    The Gold Mine

    All the aforementioned data, with the exception of the filesystem.cache files, is added to the main SQLite database RemoteManagement/RMDB/rmdb.sqlite3 (“RMDB”). The RMDB exists on all ARD systems but is only populated on the administrator system. It houses a wealth of information about the systems in the ARD network over a significant timespan. Mandiant has observed data for application usage timestamps from over a year prior to when we acquired a database on a live system.

    The RMDB file contains five tables: ApplicationName, ApplicationUsage, PropertyNameMap, SystemInformation, and UserUsage. The following sections detail each table within the database:

    ApplicationName

    This table is an index for the applications on each system, where each application is assigned an item sequence number (“ItemSeq”) per system. This data is used for correlation in the ApplicationUsage table.

    Column

    Value Format

    Description

    ComputerID

    String

    Client MAC address, no separators

    AppName

    String

    Friendly application name

    AppURL

    String

    Application URL path (i.e. file:///Applications/Calculator.app)

    ItemSeq

    Integer

    ID number for each application, per ComputerID, used for the AppName table

    LastUpdated

    macOS absolute timestamp

    Last report time of the client

    Table 5: ApplicationName table columns

    ApplicationUsage

    The AppName table is unique in the fact the “Frontmost” and “LaunchTime” values in the table are swapped. The research at the time of this blog post was verified on MacOS 10.14 (Mojave).

    Column

    Value Format

    Description

    ComputerID

    String

    Client MAC address, no separators

    FrontMost

    macOS absolute timestamp

    Application launch time

    LaunchTime

    Number of seconds to 6 decimal places

    Total duration the application was “frontmost” on screen

    RunLength

    Number of seconds to 6 decimal places

    Total duration the application was running

    ItemSeq

    Integer

    ItemSeq number for the respective ComputerID, referenced in the ApplicationName table

    LastUpdated

    macOS absolute timestamp

    Last report time of the client

    UserName

    String

    User who launched the application

    RunState

    Integer

    “1” for “running”, or “0” for “terminated” at the time of the last report

    Table 6: ApplicationUsage table columns

    PropertyNameMap

    This table is used as a reference for the SystemInformation table.

    Column

    Value Format

    Description

    ObjectName

    String

    Various elements of a macOS system, such as Mac_HardDriveElement, Mac_USBDeviceElement, Mac_SystemInfoElement

    PropertyName

    String

    Property names for each element, such as ProductName, ProductID, VendorID, VendorName for Mac_USBDeviceElement

    PropertyMapID

    Integer

    ID number for each property, per element

    Table 7: PropertyNameMap table columns

    SystemInformation

    There is a substantial amount of system information collected in this table. This table can be leveraged to extract USB device information, IP addresses, hostnames, and more, of all the reported client systems.

    Column

    Value Format

    Description

    ComputerID

    String

    Client MAC address, with colon separators

    ObjectName

    String

    Elements of a macOS system outlined in the PropertyNameMap table

    PropertyName

    String

    Properties per element outlined in the PropertyNameMap table

    ItemSeq

    Integer

    ID number for each element, i.e. if there are 4 Mac_USBDeviceElement data sets, each one will have an ItemSeq number, 0-3, to group the properties together

    Value

    String

    Data for the respective property

    LastUpdated

    yyyy-mm-ddThh:mm:ssZ

    24 hour local time, last report time of the client. Example: 2019-08-07T02:11:34Z

    Table 8: SystemInformation table columns

    UserUsage

    This table contains the user login activity for all the reported client systems.

    Column

    Description of Value

    ComputerID

    Client MAC address, no separators

    LastUpdated

    macOS absolute timestamp, last report time of the client

    UserName

    Short name of the user

    LoginType

    Console, tty, or ssh

    inTime

    macOS absolute timestamp, time the user logged in

    outTime

    macOS absolute timestamp, time the user logged out

    Host

    Originating host for remote login. This field has been observed to not be consistently present.

    Table 9: UserUsage table columns

    Filesystem Cache

    The RemoteManagement/ClientCaches/filesystem.cache file is a database that indexes the files and directories found on a macOS computer’s file system. Rather than using SQLite like the RMDB, ARD uses a custom database implementation to track this information. Fortunately, the database file format is fairly simple, consisting of a file header, six tables, and entries that point to string values. By interpreting the information in the filesystem cache file, an investigator can recreate the directory structure of an ARD-enable system. Mandiant uses this technique to identify and demonstrate the existence of attacker-created files.

    The database header, identified by the magic value “hdix”, contains metadata about the database, such as the total number of indexed folders, files, and symlinks. Pointers from this header lead to the six tables: “main”, “names” (file names), “kinds” (file extensions), “versions” (macOS app bundle version infos), “users”, and “groups”. Entries in the “main” table contain references to entries in the other tables; by walking these references, an investigator can recover full file system paths and metadata.

    In practice, the filesystem.cache file may be tens of megabytes in size, tracking dozens or hundreds of thousands of file system entries. Figure 4 shows truncated content of a parsed file system cache file; these entries are for the artifacts discussed in this article!


    Figure 4: Screenshot of filesystem.cache contents, listing ARD artifacts

    On a macOS system, the program “build_hd_index” traverses the file system and indexes the files and directories into filesystem.cache. Figure 5 shows a portion of the documentation for this tool; as expected, the default output directory is [/private]/var/db/RemoteManagement/caches/.


    Figure 5: documentation for build_hd_index

    Ironically, internet message board posts going back to at least 2007 complain of the performance impact of this tool. A post by “Anonymous” indicates that “build_hd_index” was designed to support file indexing on OS X Panther (2003), which didn’t have Spotlight. Now, 16 years later, we can exploit these artifacts during an incident response.

    Introducing: ARDvark

    It was evident that if this artifact exists in a future investigation, leveraging its wealth of data will be critical to identifying attacker activities. In some scenarios, investigators may be able to generate reports directly from an ARD administrator system, but this may not always be the case. If not, then investigators would have to rely on manually acquiring and extracting information from the RMDB file on the ARD administrator system. ARDvark is a tool that extracts all user activity and application usage recorded in the RMDB and outputs the data in an analyst-friendly format.

    ARDvark will also process the AppUsage.plist and UserAcct.tmp files found on ARD client systems under /private/var/db/RemoteManagement/caches/. Additionally, ARDvark has the capability to parse the filesystem.cache files to produce a file system listing, as well as all users and groups present on the respective system. Please see the FireEye Github for more information.

    Detecting and Preventing ARD Abuse

    To detect suspicious ARD usage, organizations can monitor for anomalous modification of the /Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd file to identify remote desktop access enablement where ARD is not used. Analyzing the Unified Logs for evidence of unexpected kickstart commands during threat hunting missions can uncover suspicious ARD usage as well.

    Mitigating ARD abuse is reliant upon the principle of least privilege. Mandiant recommends allowing as few remote control privileges as possible, and only allowing administrator privileges to necessary accounts. Apple provides guidance on setting privileges, and authenticating without using local accounts with ARD in the help page and in the ARD user guide. ARD administrators can then routinely generate reports in the ARD application to ensure no changes are made to administration privilege settings.

    A Bushel of Evidence

    Application usage artifacts for macOS are few and far between. To date, some of the best artifacts for application usage include CoreAnalytics files and the Spotlight database, but none of these artifacts provide the exact time of execution of all applications. While ARD artifacts are not present across every macOS system, if ARD is deployed in an enterprise environment it may provide some of the most valuable data for investigators which you would not uncover otherwise.

    User login activity typically exists in the Apple System Logs and Audit Logs, but short log retention is frequently an issue when the average attacker dwell time in 2018 was 78 days. The RMDB provides a potential source of application usage and user login information that is over a year old, long outliving typical log retention times.

    The system information available in the RMDB includes IP addresses, USB device information, and more which may be useful to investigators. Also, the file system cache files that are collected contain an extensive file listing of multiple macOS systems, which allows investigators to identify files or users of interest on other systems without having to collect data from the suspect system directly.

    ARD is an excellent example of how remote administration tools provide an attack surface for abuse while simultaneously providing a vast amount of data to help piece together malicious activity, all from a single system. If your organization utilizes ARD, consider reviewing the information available through the reporting functionality during threat hunting and future investigative purposes, as the artifact doesn’t fall far from the tree.

    iBackDoor: High-risk Code Sneaks into the App Store

    The library embeds backdoors in unsuspecting apps that make use of it to display ads, exposing sensitive data and functionality. The backdoors can be controlled remotely by loading JavaScript code from remote servers to perform the following actions:

    • Capture audio and screenshots.
    • Monitor and upload device location.
    • Read/delete/create/modify files in the app’s data container.
    • Read/Write/Reset the app’s keychain (e.g., app password storage).
    • Post encrypted data to remote servers.
    • Open URL schemes to identify and launch other apps installed on the device.
    • “Side-load” non-App Store apps by prompting the user to click an “Install” button.

    The offending ad library contains identifying data suggesting that it is a version of the mobiSage SDK [1]. We found 17 distinct versions of the backdoored ad library, with version codes between 5.3.3 and 6.4.4. However, in the latest mobiSage SDK publicly released by adSage [2], identified as version 7.0.5, the backdoors are not present. We cannot determine with certainty whether the backdoored versions of the library were actually released by adSage, or whether they were created and/or compromised by a third party.

    As of publication of this blog, we have identified 2846 apps published in the App Store containing backdoored versions of mobiSage SDK. Among these 2846 apps, we have observed over 900 attempt to contact their command and control (C2) server. We have notified Apple and provided the details to them.

    These backdoors can be controlled not only by the original creators of the ad library, but potentially also by outside threat actors. While we have not observed commands from the C2 server intended to trigger the most sensitive capabilities such recording audio or stealing sensitive data, there are several ways that the backdoors could be abused by third-party targeted attackers to further compromise the security and privacy of the device and user:

    • An attacker could reverse-engineer the insecure HTTP-based control protocol between the ad library and its server, and then hijack the connection to insert commands to trigger the backdoors and steal sensitive information.
    • A malicious app developer can similarly inject commands, utilizing the library’s backdoors to build their own surveillance app. Since the ad library has passed the App Store review process in numerous apps, this is an attractive way to create an app with these hidden behaviors that will pass under Apple’s radar.

    App Store Protections Ineffective

    Despite Apple’s reputation for keeping malware out of the App Store with its strict review process, this case demonstrates that it is still possible for dangerous code that exposes users to critical security and privacy risks to sneak into the App Store by piggybacking on unsuspecting apps. Backdoors that enable silently recording audio and uploading sensitive data when triggered by downloaded code clearly violate the requirements of the iOS Developer Program [3]. The requirements state that apps are not permitted to download code or scripts, with the exception of scripts that “do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.” And, for apps that can record audio, “a reasonably conspicuous audio, visual or other indicator must be displayed to the user as part of the Application to indicate that a Recording is taking place.”  The backdoored versions of mobiSage clearly violate these requirements, yet thousands of affected apps made it past the App Store review process.

    Technical Details

    As shown in Figure 1, the backdoored mobiSage library includes 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 backdoors and exposes 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 backdoors by invoking the interfaces exposed by msageCore. Each component has its own separate version number.

     

    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.

    Backdoors in msageCore

    Communication channel

    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  adsagejs://cmd&parameter. 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.

    High-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.

    msageCore Class Name

    Interfaces

    MSageCoreUIManagerPlugin

    - captureAudio:

    - captureImage:

    - openMail:

    - openSMS:

    - openApp:

    - openInAppStore:

    - openCamera:

    - openImagePicker:

    - ...

    MSageCoreLocation

    - start:

    - stop:

    - setTimer:

    - returnLocationInfo:webViewId:

    - ...

    MSageCorePluginFileModule

     

    - createDir

    - deleteDir:

    - deleteFile:

    - createFile:

    - getFileContent:

    - ...

    MSageCoreKeyChain

    - writeKeyValue:

    - readValueByKey:

    - resetValueByKey:

    MSageCorePluginNetWork

    - sendHttpGet:

    - sendHttpPost:

    - sendHttpUpload:

    - ...

    MSageCoreEncryptPlugin

    - MD5Encrypt:

    - SHA1Encrypt:

    - AESEncrypt:

    - AESDecrypt:

    - DESEncrypt:

    - DESDecrypt:

    - XOREncrypt:

    - XORDecrypt:

    - RC4Encrypt:

    - RC4Decrypt

    - ...

    Table 1: Selected interfaces exposed by msageCore

    The selected interfaces reveal some of the key capabilities exposed by the backdoors in the library. They expose the ability to capture audio and screenshots while the affected app is in use, identify and launch other apps installed on the device, periodically monitor location, read and write files in the app’s data container, and read/write/reset “secure” keychain items stored by the app. Additionally, any data collected via these interfaces can be encrypted with various encryption schemes and uploaded to a remote server.

     

    Beyond the selected interfaces, the ad library exposes users to additional risks by including explicit logic to promote and install “enpublic” apps shown in Figure 4. As we have highlighted in previous blogs [4, 5, 6, 7, 8], enpublic apps can introduce additional security risks by using private APIs, which would normally cause an app to be blocked by the App Store review process. In previous blogs we have described a number of “Masque” attacks utilizing enpublic apps [5, 6, 7], which affect pre-iOS 9 devices. The attacks include background monitoring of SMS or phone calls, breaking the app sandbox, stealing email messages, and demolishing arbitrary app installations.

     

     

    Figure 4: Installing “enpublic” apps to bypass Apple App Store review

     

    We can observe the functionality of the ad library by examining the implementations of some of the selected interfaces. Figure 5 shows reconstructed code snippets for capturing audio. Before storing recorded audio to a file audio_xxx.wav, the code retrieves two parameters from the command for recording duration and threshold.

     

     

    Figure 5: Capturing audio with duration and threshold.

     

    Figure 6 shows a code snippet for initializing the app’s keychain before reading. The accessed keychain is in the kSecClassGenericPassword class, which is widely used by apps for storing secret credentials such as passwords.

     

     

    Figure 6: Reading the keychain in the kSecClassGenericPassword class.

    Remote control in msageJS

    msageJS contains JavaScript code for communicating with a C2 server and submitting commands to msageCore. The file layout of msageJS is shown in Figure 7. Inside sdkjs.js, we find a wrapper object called adsage and the JavaScript interface for command execution.

     

     

    Figure 7: The file layout of msageJS

     

    The command execution interface is constructed as follows:

     

              adsage.exec(className, methodName, argsList, onSuccess, onFailure);

     

    The className and methodName parameters correspond to classes and methods in msageCore. The argsList parameter can be either a list or dict, and the exact types and values can be determined by reversing the methods in msageCore. The final two parameters are function callbacks invoked when the method exits. For example, the following invocation starts audio capture:

     

    adsage.exec("MSageCoreUIManager", "captureAudio", ["Hey", 10, 40],  onSuccess, onFailure);

     

    Note that the files comprising msageJS cannot be found by simply listing the files in an affected app’s IPA. The files themselves are zipped and encoded in Base64 in the data section of the ad library binary. After an affected app is launched, msageCore first decodes the string and extracts msageJS to the app’s data container, setting index.html shown in Figure 7 as the landing page in the ad library WebView to launch msageJS.

     

     

    Figure 8: Base64 encoded JavaScript component in zip format.

     

    When msageJS is launched, it sends a POST request to hxxp://entry.adsage.com/d/ to check for updates. The server responds with information about the latest msageJS version, including a download URL, as shown in Figure 9. Note that since the request uses HTTP rather than HTTPS, the response can be hijacked easily by a network attacker, who could replace the download URL with a link to malicious JavaScript code that triggers the backdoors.

     

    Figure 9: Server response to msageJS update request via HTTP POST

    Conclusion

    In this blog, we described a high-risk ad library affecting thousands of iOS apps in the Apple App Store. We revealed the internals of backdoors which can be used to silently record audio, capture screenshots, prompt the user to side-load other high-risk apps, and read sensitive data from the app’s keychain, among other dubious capabilities. We also showed how these backdoors can be controlled remotely by JavaScript code fetched from the Internet in an insecure manner.

     

    FireEye Protection

    Immediately after we discovered the high-risk ad library and affected apps, FireEye updated detection rules in its NX and Mobile Threat Prevention (MTP) products to detect the affected apps and their network activities. In addition, FireEye customers can access the full list of affected apps upon request.

    FireEye NX customers are alerted if an employee uses an infected app while their iOS device is connected to the corporate network. It is important to note that, even if the servers that the backdoored mobiSage SDK communicates with do not deliver JavaScript code that triggers the high-risk backdoors, the affected apps still try to connect to them using HTTP. This HTTP session is vulnerable to hijacking by outside attackers.

    FireEye MTP management customers have full visibility into high-risk apps installed on mobile devices in their deployment base. End users receive on-device notifications of the detection and IT administrators receive email alerts.

    Click here to learn more about FireEye Mobile Threat Protection product.

     

     

     

    [1] http://www.adsage.com/mobisage

    [2] http://www.adsage.cn/

    [3] https://developer.apple.com/programs/ios/information/iOS_Program_Information_4_3_15.pdf [4] https://www.fireeye.com/blog/threat-research/2015/08/ios_masque_attackwe.html

    [5] https://www.fireeye.com/blog/threat-research/2015/02/ios_masque_attackre.html

    [6] https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html

    [7] https://www.fireeye.com/blog/threat-research/2015/06/three_new_masqueatt.html

    [8] https://www.virusbtn.com/virusbulletin/archive/2014/11/vb201411-Apple-without-shell