Evasi0n under the microscope
Recently released a new set of utilities for the "jail" iOS. It's time to disassemble it and see what exploits and penetration mechanisms it uses. Now jailing iOS has become so simple that people forget how difficult this process is. Protection mechanisms that are built into user space, such as a sandbox, ASLR (Address Space Layout Randomization - randomization of location in the address space) and digital signature mechanisms, make the Jail writing process incredibly complicated.
It is worth noting that, unlike previous jailbreak.me exploits that could be used on unsuspecting victims, “jails” that require a USB connection usually carry less security risks and are typically useful only to the device owner. The attackers are less interested in them, since the iPhone with the pin code will refuse to communicate via USB if it is locked, if it was not synchronized with the computer to which it is connected, of course. Thus, if the phone was stolen and a pin-code was set on it, the attacker will not be able to “jail” it. Only malicious code running on your computer may have at least some ability to jail seamlessly.
This article focuses on the Evasi0n user component. The mechanism used in Evasi0n is unique, because it is entirely based on the interaction with the file system, it does not require more typical approaches to data corruption in memory to elevate privileges to the root user. Evasi0n may have been so named precisely because he avoids all the protection of user space, instead of attacking them head-on.
Evasi0n works in three steps, described below. All of them are based on the standard iOS functionality available through the MobileBackup service, which backs up the data on the device and restores the same copies back if necessary. Since the archival copies themselves are created on the same iOS device, but should be able to be restored to another, they are difficult to secure cryptographically, i.e. the data in the copies is actually not reliable.
')
MobileBackup uses a domain, such as
During the first stage, Evasi0n creates a new empty backup copy to restore to the device containing the following files:
A symbolic link from .haxx to / var / mobile is created to bypass the restriction on working with files only within the domain, i.e. although the standard restriction will not allow copying of files outside
Next,
Unlike a regular iOS application, this main executable file is somewhat atypical and contains the following:
In fact, when you start the DemoApp program, the launchctl actually starts with the specified arguments.
In addition, in the
The device reboots, Springboard rereads the cache and displays the icon.
Previous files remain in place, the second stage creates another empty backup copy and restores several more files to the device:
In fact, it’s just creating a symbolic link
These access rights do not allow normal applications (launched from the mobile user) to explore this directory.
The next step, Evasi0n communicates with
Now we come to the first vulnerability. Sending an invalid
Evasi0n penetrates deep into
Evasi0n then repeats the PairRequest trick, making
This stage begins with the installation of Cydia and the package archive on the device. They will not be used right now, but will be available after the "Jail".
Further, the user is instructed to start the Jailbreak application (in fact, DemoApp). Let me remind you once again what it does:
with the environment
If you look at the
And in man on
Unlike most other things in iOS,
Since we are working with the
The final stage of the "Jail", and again used MobileBackup, but this time there is already full access to the system partition:
This looks a bit confusing due to several redirects to symbolic links, but in fact it creates the
Actually, when loading the following commands will be executed:
They will do the following:
Evasi0n pergloads the device that performs the described configuration. An interesting point is connected with the fact that neither amfi.dylib, nor evasi0n contain a digital signature. If you examine the file amfi.dylib with the help of
This technique is reviewed at http://networkpx.blogspot.com/2009/09/compiling-iphoneos-31-apps-with-xcode.html :
Using tricky use of a dynamic library without code, existing real functions (such as
Evasi0n is interesting in that it raises privileges and gets full access to the system partition without damaging the memory of processes. Using the
It is worth noting that, unlike previous jailbreak.me exploits that could be used on unsuspecting victims, “jails” that require a USB connection usually carry less security risks and are typically useful only to the device owner. The attackers are less interested in them, since the iPhone with the pin code will refuse to communicate via USB if it is locked, if it was not synchronized with the computer to which it is connected, of course. Thus, if the phone was stolen and a pin-code was set on it, the attacker will not be able to “jail” it. Only malicious code running on your computer may have at least some ability to jail seamlessly.
Evasi0n in user space
This article focuses on the Evasi0n user component. The mechanism used in Evasi0n is unique, because it is entirely based on the interaction with the file system, it does not require more typical approaches to data corruption in memory to elevate privileges to the root user. Evasi0n may have been so named precisely because he avoids all the protection of user space, instead of attacking them head-on.
Evasi0n works in three steps, described below. All of them are based on the standard iOS functionality available through the MobileBackup service, which backs up the data on the device and restores the same copies back if necessary. Since the archival copies themselves are created on the same iOS device, but should be able to be restored to another, they are difficult to secure cryptographically, i.e. the data in the copies is actually not reliable.
')
MobileBackup uses a domain, such as
MediaDomain , and a relative path within the domain to identify each file. A specific directory is fixed to each domain, and the combination of the path to this directory and the relative path to the file gives the full path. Evasi0n creates all work files in the MediaDomain domain, so all files have a working prefix of /var/mobile/Media .Stage 1
During the first stage, Evasi0n creates a new empty backup copy to restore to the device containing the following files:
directory: Media/ directory: Media/Recordings/ symlink: Media/Recordings/.haxx -> /var/mobile directory: Media/Recordings/.haxx/DemoApp.app/ file: Media/Recordings/.haxx/DemoApp.app/Info.plist file: Media/Recordings/.haxx/DemoApp.app/DemoApp file: Media/Recordings/.haxx/DemoApp.app/Icon.png file: Media/Recordings/.haxx/DemoApp.app/Icon@2x.png file: Media/Recordings/.haxx/DemoApp.app/Icon-72.png file: Media/Recordings/.haxx/DemoApp.app/Icon-72@2x.png file: Media/Recordings/.haxx/Library/Caches/com.apple.mobile.installation.plist A symbolic link from .haxx to / var / mobile is created to bypass the restriction on working with files only within the domain, i.e. although the standard restriction will not allow copying of files outside
/var/mobile/Media , but using a symbolic link, files actually fall into /var/mobile . This approach has already been used in jails and earlier.Next,
DemoApp.app , a regular iOS application, is created in /var/mobile . This is a regular application, with icons and other accompanying files. The com.apple.mobile.installation.plist file is also updated, where Springboard stores the cache of application paths so that the DemoApp icon appears among the rest.Unlike a regular iOS application, this main executable file is somewhat atypical and contains the following:
#!/bin/launchctl submit -l remount -o /var/mobile/Media/mount.stdout -e /var/mobile/Media/mount.stderr -- /sbin/mount -v -t hfs -o rw /dev/disk0s1s1 In fact, when you start the DemoApp program, the launchctl actually starts with the specified arguments.
In addition, in the
com.apple.mobile.installation.plist environment for running DemoApp is slightly modified: <key>EnvironmentVariables</key> <dict> <key>LAUNCHD_SOCKET</key> <string>/private/var/tmp/launchd/sock</string> </dict> The device reboots, Springboard rereads the cache and displays the icon.
Stage 2.1
Previous files remain in place, the second stage creates another empty backup copy and restores several more files to the device:
directory: Media/ directory: Media/Recordings/ symlink: Media/Recordings/.haxx -> /var/db symlink: Media/Recordings/.haxx/timezone -> /var/tmp/launchd In fact, it’s just creating a symbolic link
/var/db/timezone to the file /var/tmp/launchd . Typical access rights to /var/tmp/launchd are: drwx------ 2 root wheel 102 Feb 4 12:17 launchd These access rights do not allow normal applications (launched from the mobile user) to explore this directory.
The next step, Evasi0n communicates with
lockdownd , by sending an incorrectly formed PairRequest . Lockdownd is the main daemon that performs USB communication, it is also used to start / stop other services, such as MobileBackup and AFC (Apple File Connection, a service that allows you to share files with iTunes). Since lockdownd works as root user and the user can communicate with it, abuse of its capabilities or vulnerabilities has become popular in the latest jails.Now we come to the first vulnerability. Sending an invalid
PairRequest package causes lockdownd to change the access rights to /var/db/timezone to 777, thus making /var/tmp/launchd accessible to all users. It is not clear whether this is directly a lockdownd or some of the libraries that it uses.Stage 2.2
Evasi0n penetrates deep into
/var/tmp/launchd and modifies the access rights so that the launchd socket becomes available to the average user. Also at this stage the symbolic link to the timezone is updated: symlink: Media/Recordings/.haxx/timezone -> /var/tmp/launchd/sock Evasi0n then repeats the PairRequest trick, making
/var/tmp/launchd/sock available to the mobile user.Stage 2.3
This stage begins with the installation of Cydia and the package archive on the device. They will not be used right now, but will be available after the "Jail".
Further, the user is instructed to start the Jailbreak application (in fact, DemoApp). Let me remind you once again what it does:
#!/bin/launchctl submit -l remount -o /var/mobile/Media/mount.stdout -e /var/mobile/Media/mount.stderr -- /sbin/mount -v -t hfs -o rw /dev/disk0s1s1 with the environment
LAUNCHD_SOCKET = /private/var/tmp/launchd/sock If you look at the
launchctl man, you can find out that the submit command is described as follows: submit -l label [-p executable] [-o path] [-e path] -- command [args] A simple way of submitting a program to run without a configura- tion file. This mechanism also tells launchd to keep the program alive in the event of failure. -l label What unique label to assign this job to launchd. -p program What program to really execute, regardless of what fol- lows the -- in the submit sub-command. -o path Where to send the stdout of the program. -e path Where to send the stderr of the program. And in man on
launchd specified: ENVIRONMENTAL VARIABLES LAUNCHD_SOCKET This variable is exported when invoking a command via the launchd command line. It informs launchctl how to find the correct launchd to talk to. Unlike most other things in iOS,
launchd IPC is based on unix sockets. There are also several launchd processes — one for each active user. On iOS, one works with root rights, the other with mobile rights. The mobile user executes launchctl via DemoApp, but this launchctl does not communicate with the launchd mobile user, instead it communicates with the launchd root user because of the explicitly specified path to the socket and the extended access rights obtained through the vulnerability with /var/db/timezone .Since we are working with the
launchd root user, the task will be executed as root, which allows it to remount the system partition with write access to allow Evasi0n to make changes to the system to perform them in an early boot environment.Stage 3
The final stage of the "Jail", and again used MobileBackup, but this time there is already full access to the system partition:
directory: Media/ directory: Media/Recordings/ symlink: Media/Recordings/.haxx -> / symlink: Media/Recordings/.haxx/private/etc/launchd.conf -> /private/var/evasi0n/launchd.conf directory: Media/Recordings/.haxx/var/evasi0n file: Media/Recordings/.haxx/var/evasi0n/evasi0n file: Media/Recordings/.haxx/var/evasi0n/amfi.dylib file: Media/Recordings/.haxx/var/evasi0n/udid file: Media/Recordings/.haxx/var/evasi0n/launchd.conf This looks a bit confusing due to several redirects to symbolic links, but in fact it creates the
/var/evasi0n with the application and library, as well as the new launchd.conf , which stores the commands that are executed when the system boots.Actually, when loading the following commands will be executed:
bsexec .. /sbin/mount -u -o rw,suid,dev / setenv DYLD_INSERT_LIBRARIES /private/var/evasi0n/amfi.dylib load /System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist bsexec .. /private/var/evasi0n/evasi0n unsetenv DYLD_INSERT_LIBRARIES bsexec .. /bin/rm -f /private/var/evasi0n/sock bsexec .. /bin/ln -f /var/tmp/launchd/sock /private/var/evasi0n/sock They will do the following:
- remount the system partition with write permissions;
- amfi.dylib will be embedded in any application from now on;
- MobileFileIntegrity service starts;
- the “malicious” code recorded in the previous step is launched;
- amfi.dylib will no longer be implanted;
- removes the old symbolic socket reference to / private / var / evasi0n / sock;
- the symbolic link / private / var / evasi0n / sock is updated to point to / var / tmp / launchd / sock, allowing other code to directly interact with the launchd of the root user.
Evasi0n pergloads the device that performs the described configuration. An interesting point is connected with the fact that neither amfi.dylib, nor evasi0n contain a digital signature. If you examine the file amfi.dylib with the help of
otool , it turns out that there is no __text section in it (example of a translator: the machine code is stored in the __text section of the __TEXT segment ). And if there is no __text section, then there is nothing to sign, and verification for a digital signature will not be performed. Amfi.dylib works with late linking information: $ dyldinfo -export amfi.dylib export information (from trie): [re-export] _kMISValidationOptionValidateSignatureOnly (_kCFUserNotificationTokenKey from CoreFoundation) [re-export] _kMISValidationOptionExpectedHash (_kCFUserNotificationTimeoutKey from CoreFoundation) [re-export] _MISValidateSignature (_CFEqual from CoreFoundation) This technique is reviewed at http://networkpx.blogspot.com/2009/09/compiling-iphoneos-31-apps-with-xcode.html :
If we can force MISValidateSignature () to always return 0, any files will pass the test. This function is part of libmis.dylib, which is now stored in a shared cache, so it's hard to patch the function itself. Replacing the implementation of this feature using MobileSubstrate would be great, but no matter how I tried, MS could not replace it. Then I used the trick: I created a “proxy” library that redirects MISValidateSignature ().
Using tricky use of a dynamic library without code, existing real functions (such as
CFEqual() ) are re-exported as other functions with identical arguments, which causes MISValidateSignature() always return 0, allowing any executable file to be executed.Total
Evasi0n is interesting in that it raises privileges and gets full access to the system partition without damaging the memory of processes. Using the
/var/db/timezone vulnerability, it accesses launchd and modifies MobileFileIntegrity so that it always confirms that digital signatures are correct.Source: https://habr.com/ru/post/168373/
All Articles