Cracking app isolation on Apple devices is an intricate challenge due to the robust security measures implemented by the company. Apple employs a variety of mechanisms to ensure the isolation and integrity of applications, primarily through its sandboxing approach. Sandboxing restricts each app's access to system resources and other apps, limiting the potential damage that a compromised app could inflict on the device.
CCS335 _ Neural Networks and Deep Learning Laboratory_Lab Complete Record
Apple Presentation.pptx
1. Title: Cracking App Isolation on Apple: Unauthorized Cross-
AppResource Access on MAC OS X and iOS.
Authors: Wen Xu, Zhiwei Li, Le Yu, Hui Xue, Xiaolan Zhang,
and Patrick Tague from the University of California, Santa
Barbara
2. overview
On modern operating systems, applications under the same user are separated from
each other, for the purpose of protecting them against malware and compromised
programs.
However, it is less clear whether such isolation is effective against different kind of cross-app
resource access attacks (XARA) This paper explores the research conducted on MAC OS X and
iOS shows significant security weaknesses that allow a malicious app to gain unauthorized access
to sensitive data from other apps.
The vulnerabilities were found in various inter-app interaction services and the design of the App
sandbox on OS X.
These vulnerabilities are caused by the lack of app-to-app and app-to-OS authentications, making
it difficult to protect sensitive data from unauthorized access. A scanner was developed to detect
missing protection in app code, and a simple program was built to detect exploit attempts on OS
X to protect vulnerable apps.
The study highlights the importance of regular security assessments and the need for stronger
app-to-app and app-to-OS authentications.
3. How app isolation works in popular operating systems
App Sandboxing: The purpose of app sandboxing is to isolate apps and prevent unauthorized access to sensitive resources.
In Android, each app is assigned a unique user ID (UID) and runs as the user. Sensitive resources are assigned to Linux groups
such as GPS, Audio, etc. and an app needs to request permission from the OS or user to access system resources.
On MAC OS X and iOS, app sandboxing is enforced through the Trusted BSD mandatory access control framework. All apps
submitted to the MAC App Store are required to be sandboxed. The separation of apps is enforced through Trust BSD’s API
interpositions. Each app is identified by its Apple ID, a two-part string that consists of a Team ID Apple assign to the app
developer, and a Bundle ID supplied by the developer. An app within the sandbox has limited privileges and can only read and
write files within its container and some public directories. Whenever use of resources such as network sockets, built-in camera,
microphone, printer and other resources become necessary, the app explicitly requires them by declaring a set of entitlements
within its property file.
Among the small set of operations that a sandboxed app is allowed to do by default is the capabilities to perform some types of
inter process communication (IPC). The Apple platforms support a variety of IPC channels, including traditional UNIX ones (e.g.,
pipe, UNIX domain socket, shared memory) and Apple-specific mechanisms like distributed objects, NS Connection in particular,
and URL schemes. The NS Connection mechanism allows the client to invoke methods of the vended object and access its
variables as if the object existed in the client process. Socket-based IPC is also available on OS X. Scheme is another unique IPC
mechanism for both OS X and iOS.
4. Critical security flaws, discovered in the OS X
keychain, BID-based separation as well as various
IPC channels, i.e., NSConnection, WebSocket and
Scheme on both MAC OS X and iOS.
Password Stealing
We can observe security weakness in Apple's
keychain service, which is used to store passwords and
other credentials securely.
The weakness allows a malicious app to bypass the
isolation between apps and steal user credentials from
other apps.
The attack works by claiming an item in the keychain
and crafting an access control list that includes the
target app as a trusted app.
The keychain then allows all operations to proceed,
causing the target app to divulge its secrets to the
attacker. Another flaw in keychain, which allows an
existing keychain item to be deleted by an
unauthorized sandboxed app
5. Container Cracking
Container cracking refers to a security vulnerability in the keychain of macOS, which allows a malicious application to gain
access to the resources (e.g., passwords) of other sandboxed applications.
This vulnerability arises due to a weakness in the unique BID-based separation design on macOS. Each sandboxed app has
a BID that needs to be unique, and once the app is installed, its BID is used to create a container directory that other
sandboxed apps cannot touch.
However, the vulnerability arises because embedded programs within an app, such as a helper program or an XPC
Service, also have their own BIDs and container directories.
The Mac App Store fails to verify whether a sub-target's BID is in conflict with those belonging to other apps or their sub-
targets, except for the Apple reserved BIDs. This allows a malicious app to gain full access to other apps' containers,
completely breaking its sandbox confinement.
In a study, researchers implemented endto-end attacks on high-profile apps, including Evernote, WeChat, QQ, and others,
successfully stealing user data such as contacts, private notes, and message photos.
6. IPC Interception
IPC interception refers to the act of an attacker intercepting inter-process communication
(IPC) channels between two or more applications to gain unauthorized access to sensitive
information. In this context, IPC refers to the channels through which different applications
communicate with each other.
Two specific types of IPC channels - NSConnection and WebSocket - have been found to have
vulnerabilities that can be exploited by attackers. NSConnection is an Apple-specific IPC
channel that allows one party to act as a server and share an object with other client apps.
The problem with this channel is that there is no means for the apps to authenticate each
other when they are using NSConnection. Therefore, a sandboxed app can easily
impersonate the server or client of a target app to access sensitive resources.
In the case of WebSocket, which is a generic protocol for a server and a client to establish a
full-duplex single socket connection, a malicious program (with the network permission
when it is sandboxed) can claim a port pre-emptively before the legitimate server does, in
the absence of proper authentication. This enables the attacker to receive data from the
target extension. Similarly, a malicious extension can impersonate the authorized one to talk
to the local app through its port.
7. IOS Scheme hijacking
It relates to a security vulnerability on Apple platforms related to
URL schemes. URL schemes are used by apps to define a protocol
for communication with other apps. When a URL scheme is
triggered within a webview instance inside another app or in the
browser, an HTTP redirection is launched towards the "location"
part of the URL, which activates the app claiming the scheme using
the data delivered by the remaining part of the URL.
The problem is that when two different apps register the same URL
scheme with the operating system, the conflict is resolved according
to the nature of the scheme, and a malicious program can hijack a
target app's scheme to get the service request or data sent to it.
This vulnerability can be detected on OS X using certain APIs, but no
corresponding API exists on iOS. As a result, all third-party apps
running on iPhone and iPad are completely unprotected from this
threat.
8. Challenges in Addressing XARA Problems
Addressing XARA problems is challenging because often the OS itself does not
know how to protect the resource of a third-party app.
Proper interfaces may need to be given to the app developers to let them
specify and enforce their individual policies.
This complexity means these security weaknesses will likely persist until Apple
finds a way to work with developers to fix them.
9. Proposed approach: an automatic analysis tool has been built for detecting vulnerable apps and a measurement study that reveals
the scope and magnitude of the XARA problem.
Scanner App Design: The XARA scanner app inspects public information whenever a change to the system happens. For example,
write to a file or installation of a new app to detect whether a service, resource, or channel claimed by one app has been hijacked
by another. Our app registers file system event with API FSEvents, which is issued when a specific file has been modified.
Specifically, the scanner monitors the keychain files under /Library/Keychains/ and ∼/Library/Keychains/. Whenever they’re
modified, our app uses the API SecItemCopyMatching to find out whether a new item has been added, and if so further retrieves
its ACL using SecACLCopyContents and inspects all the apps on the list.
For Scheme and BID, the scanner keeps track of newly installed programs through the event API FSEvents. Whenever an app is
installed, the scanner goes through its plist to find out whether the URL scheme it registers or the BIDs of its helper programs or
XPC Services are in conflict with the ones already in the system.
For NSConnection, our scanner redirects outputs of command syslog -w to get new system logs immediately after they are
generated. Once it observes a failed attempt to register an existing object name or connect to an NSConnection server that serves
another app, an alarm is triggered.
10. Limitations of the Scanner App:
The scanner app has limitations. For example, it
can only protect known channels and cannot
prevent some attacks, such as those on
NSConnection and WebSocket, from taking
place.
However, it can detect these attacks after the
fact. A more heavyweight patch, such as
uploading a kernel module to gain a closer
monitoring of the events happening within apps,
may be necessary for a more complete solution.
11. Conclusion
In conclusion, the paper identifies a new category of security
weaknesses, XARA, that pose a serious threat to app isolation on
modern operating systems.
The study conducted on Apple platforms reveals the pervasiveness of
this threat, and the significant impacts it can have on critical system
services and channels.
The lack of authentication during app-to-app and app to-system
interactions is identified as the root cause of this problem.
The paper proposes new techniques to detect and mitigate this
threat, contributing to a better understanding of this understudied
security problem.
The development of a more effective app isolation mechanism on
future operating systems is essential to prevent the leakage of
sensitive information.