0x22bb
/
hacktricks
mirror of https://github.com/carlospolop/hacktricks.git
1
2
Fork 0
Code Releases Activity
hacktricks/macos-hardening/macos-security-and-privileg.../macos-proces-abuse/macos-ipc-inter-process-com.../macos-xpc/macos-xpc-connecting-proces.../README.md

8.3 KiB
Raw Permalink Blame History

macOS XPC Connecting Process Check

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

XPC Connecting Process Check

When a connection is stablished to an XPC service, the server will check if the connection is allowed. These are the checks it would usually perform:

  1. Check if the connecting process is signed with an Apple-signed certificate (only given out by Apple).
    • If this isn't verified, an attacker could create a fake certificate to match any other check.
  2. Check if the connecting process is signed with the organization’s certificate, (team ID verification).
    • If this isn't verified, any developer certificate from Apple can be used for signing, and connect to the service.
  3. Check if the connecting process contains a proper bundle ID.
    • If this isn't verified, any tool signed by the same org could be used to interact with the XPC service.
  4. (4 or 5) Check if the connecting process has a proper software version number.
    • If this isn't verified, an old, insecure clients, vulnerable to process injection could be used to connect to the XPC service even with the other checks in place.
  5. (4 or 5) Check if the connecting process has hardened runtime without dangerous entitlements (like the ones that allows to load arbitrary libraries or use DYLD env vars)
    1. If this isn't verified, the client might be vulnerable to code injection
  6. Check if the connecting process has an entitlement that allows it to connect to the service. This is applicable for Apple binaries.
  7. The verification must be based on the connecting client’s audit token instead of its process ID (PID) since the former prevents PID reuse attacks.
    • Developers rarely use the audit token API call since it’s private, so Apple could change at any time. Additionally, private API usage is not allowed in Mac App Store apps.
      • If the method processIdentifier is used, it might be vulnerable
      • xpc_dictionary_get_audit_token should be used instead of xpc_connection_get_audit_token, as the latest could also be vulnerable in certain situations.

Communication Attacks

For more information about the PID reuse attack check:

{% content-ref url="macos-pid-reuse.md" %} macos-pid-reuse.md {% endcontent-ref %}

For more information xpc_connection_get_audit_token attack check:

{% content-ref url="macos-xpc_connection_get_audit_token-attack.md" %} macos-xpc_connection_get_audit_token-attack.md {% endcontent-ref %}

Trustcache - Downgrade Attacks Prevention

Trustcache is a defensive method introduced in Apple Silicon machines that stores a database of CDHSAH of Apple binaries so only allowed non modified binaries can be executed. Which prevent the execution of downgrade versions.

Code Examples

The server will implement this verification in a function called shouldAcceptNewConnection.

{% code overflow="wrap" %}

- (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection {
    //Check connection
    return YES;
}

{% endcode %}

The object NSXPCConnection has a private property auditToken (the one that should be used but could change) and a the public property processIdentifier (the one that shouldn't be used).

The connecting process could be verified with something like:

{% code overflow="wrap" %}

[...]
SecRequirementRef requirementRef = NULL;
NSString requirementString = @"anchor apple generic and identifier \"xyz.hacktricks.service\" and certificate leaf [subject.CN] = \"TEAMID\" and info [CFBundleShortVersionString] >= \"1.0\"";
/* Check:
- Signed by a cert signed by Apple
- Check the bundle ID
- Check the TEAMID of the signing cert
- Check the version used
*/

// Check the requirements with the PID (vulnerable)
SecRequirementCreateWithString(requirementString, kSecCSDefaultFlags, &requirementRef);
SecCodeCheckValidity(code, kSecCSDefaultFlags, requirementRef);

// Check the requirements wuing the auditToken (secure)
SecTaskRef taskRef = SecTaskCreateWithAuditToken(NULL, ((ExtendedNSXPCConnection*)newConnection).auditToken);
SecTaskValidateForRequirement(taskRef, (__bridge CFStringRef)(requirementString))

{% endcode %}

If a developer doesn't want to check the version of the client, he could check that the client is not vulnerable to process injection at least:

{% code overflow="wrap" %}

[...]
CFDictionaryRef csInfo = NULL;
SecCodeCopySigningInformation(code, kSecCSDynamicInformation, &csInfo);
uint32_t csFlags = [((__bridge NSDictionary *)csInfo)[(__bridge NSString *)kSecCodeInfoStatus] intValue];
const uint32_t cs_hard = 0x100;        // don't load invalid page. 
const uint32_t cs_kill = 0x200;        // Kill process if page is invalid
const uint32_t cs_restrict = 0x800;    // Prevent debugging
const uint32_t cs_require_lv = 0x2000; // Library Validation
const uint32_t cs_runtime = 0x10000;   // hardened runtime
if ((csFlags & (cs_hard | cs_require_lv)) {
    return Yes; // Accept connection
}

{% endcode %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥