Apple was Unknown About This 3 Years Old Vulnerability: That Can Break the Sandbox

We all know that how much the apple products costs in the market. The simple reason behind this is that they charge more for the privacy and integrity they give in their products as compared to their rival products in the market. The Apple Store which is believed to be the most secure source to download apps in the IOS platform contains the verified apps. The Apple security test is till now believed to be the most hard of all the other platforms available in its rivalry. But today we have come across a researcher who is playing with this security for almost three years in the and the Apple is now able to identify and correct its bugs in it IOS 13.5. Still now some can’t believe this, but yes this is the reality how a security researcher is using this bug for almost three years for his own benefits which is no more alive now. The bugs is nothing but the integrity checks that are performed by the Apple to allow developers to get their apps on Apple Store. There are some features or resources which are restricted only to the root users and third party apps are not allowed to use them.  But this bug is allowing a developer to do so. It is allowing to escalate some permissions which are only preserved for the privileged user i.e. root and not for the other apps. Lets have a detailed look what exactly is the bug.

A DETAILED ANALYSIS

So imagine you are a developer and you want to post your app on the playstore. So the very first thing you do is tht you will check the rules and regulations required by the Apple to post your app. You need all your config setting files and code signatures in the plist file ( a file that stores data in serialized format). This format is used by apple in its macOS configuration and basically you will encounter two types of plist files in apple:

  • Bplist ( a binary format that is non human readable format by humans and is faster than any other plist file)
  • Plist file in XML or JSON format.

So if we we take into consideration the format of plist file in XML (Xtensible Markup Languagage).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>OS Build Version</key>
    <string>19D76</string>
    <key>IOConsoleLocked</key>
    <false/>
    <!-- abc -->
    <key>IOConsoleUsers</key>
    <array>
        <dict>
            <key>kCGSSessionUserIDKey</key>
            <integer>501</integer>
            <key>kCGSessionLongUserNameKey</key>
            <string>Siguza</string>
        </dict>
    </array>
    <!-- def -->
    <key>IORegistryPlanes</key>
    <dict>
        <key>IODeviceTree</key>
        <string>IODeviceTree</string>
        <key>IOService</key>
        <string>IOService</string>
    </dict>
</dict>
</plist>

These plist file can be also be used to store entitlements. Entitlements are nothing but the user’s right to access a particular resource in an environment. Though in a UNIX environment, a normal user can’t have the access to root user resources but here the Apple operating systems (iOS or MAC OS) though UNIX operating systems has some relaxations and use the entitlements to allow user to give access to a particular task or a resource.

Now coming into the most important point that we know every application a developer develops has its own binary. A developer needs an extension called  AppleMobileFileIntegrity (or “AMFI”) to run the binary on the system and for this, developer needs to validate his identity that are either known to the kernel or these checks can be validate through the signed certificate by the verified authority.

Now the big picture comes here who will be that verified authority that signs the certificate for the developers app? Either that authority may be the Apple Store itself for which the developer’s app need to pass some difficult security test and it is sure that if some malicious content, it will be immediately blocked. So if a hacker is trying to go through this, it is confirmed that he will not be able to pass the test and might not achieve its motives. The other way is that the developer self signs the certificate which is valid for 7 days and it needs another security check parameter i.e provisioning profile to verify the developer’s identity and decide how much privilege has to be given to that binary . Xcode (Apple IDE) or sometimes a third party software fetches it for you. Its something like a guarantee or witness by a third person that you are legal. After somehow the developer manages to give a provisional profile to prove its identity, app can then able to run its binary and if there is some devil in place of developer, he can then able to give any entitlements in its binary to do some evil task. But by default apple keeps third party apps in a containment zone and allow very less access to system’s resources. Then how an attacker able to execute the entitlements? According to researcher, the apple has four parsers(a software that converts the input text to structural format for processing by the machine):

  • OSUnserializeXML in the kernel
  • IOCFUnserialize in IOKitUser
  • CFPropertyListCreateWithData in CoreFoundation
  • xpc_create_from_plist in libxpc (closed-source)

All these parsers can able to parse the entitlements but all of them have different outputs. What it means that, consider you programmed two different calculators, in the first you say that only 2+2=4 and in the second you say that only 1+3=4. So now if you query the first calculator tell me that if 1+3=4, it will give the output no while the second calculator will say yes. So all these different parsers have different syntax. So an attacker can easily able to fool the parser which is actually used by the kernel while he is able to execute through other parsers and same as in reality the system will listen to the majority three parsers and ignores the other. So by having access to almost every resource, an attacker can inject some load or generate code, spawn a shell, or any of literally a thousand other things.

CONCLUSION

This was just a zero day which was discovered three years ago by a security researcher and now it is fixed in iOS 13.5 though it is a beta, we are hoping that the company will soon release its stable version. You do not need to underestimate the Apple’s security as its not just a script that any script kiddie run and will bypass its security. These bugs should be really appreciated when discovered and the company should response to it as soon as they can.