The POC for SIP-Bypass Is Even Tweetable – Mickey’s Blogs – Exploring the world with my sword of debugger :)
I discovered some new assault surfaces within the macOS PackageKit.framework, and efficiently disclosed 15+ essential SIP-Bypass vulnerabilities. Apple has addressed 12 of them with CVE assigned to date. There are nonetheless some stories within the Apple’s processing queue. All of them are attention-grabbing logic points, and naturally every has a profitable exploit demonstration.
Right here, CVE-2022-26712 is a quite simple one, which was patched in macOS 12.4. Nevertheless, I discovered one other solution to exploit it once more, lastly Apple addressed it as CVE-2022-32826 in macOS 12.5.
sudo /System/Library/PrivateFrameworks/PackageKit.framework/Variations/A/Sources/shove -X /tmp/crafted.db /Library/Software Assist/com.apple.TCC/TCC.db
System Integrity Protection (SIP), aka rootless, is the final line to guard all the system from malware. There are already some good write-ups in regards to the safety characteristic, so I don’t wish to duplicate right here. In case you are not aware of it, it is suggested to learn the references half on the finish of this weblog.
Word: SIP Bypass at all times means the Full TCC Bypass. With the primitive of SIP Bypass, an attacker might substitute the system config database TCC.db with a crafted one, to get full management of macOS TCC (Transparency, Consent, and Control).
Furthermore, an attacker might get arbitrary kernel code execution with the SIP-Bypass primitive. I did discover a new approach to do that on the macOS Monterey, however I couldn’t share the exploit right here proper now, as a result of it’s associated to a different unpatched 0-day.
The system XPC service /System/Library/PrivateFrameworks/ShoveService.framework/Variations/A/XPCServices/SystemShoveService.xpc has the entitlement com.apple.rootless.set up, which grants the method permission to bypass SIP restrictions.
The service gives just one technique to shove recordsdata from one place to a different place :
@interface PKShoveOptions : NSObject
- (void) setSourcePath:(NSURL *) src;
- (void) setDestPath:(NSURL *) dst;
- (void) setOptionFlags:(uint64_t) flags;
@finish
@protocol SVShoveServiceProtocol
- (void)shoveWithOptions:(PKShoveOptions *)choices completionHandler:(id) reply;
@finish
Nevertheless, there isn’t any test for the incoming purchasers, and any course of can fireplace the XPC request to the service:
Due to this fact, we are able to abuse the service to bypass the SIP restriction.
After I applied my very own XPC shopper to take advantage of the problem, I discovered there was already an XPC shopper within the system:
The choice -X is used to speak with the system XPC service.
And the choice -x is used for the usual XPC service: /System/Library/PrivateFrameworks/ShoveService.framework/Variations/A/XPCServices/StandardShoveService.xpc, which has no entitlements.
The system XPC service isn’t working by default, and will probably be launched by purchasers if required.
If the shopper is working as root, then the service may also be launched as root. In any other case the service will run as frequent consumer. Due to this fact, root privilege is required to take advantage of the problem.
- Take away the framework
/System/Library/PrivateFrameworks/ShoveService.framework, and naturally the XPC service. - For the system command
/System/Library/PrivateFrameworks/PackageKit.framework/Variations/A/Sources/shove, take away the choices[-X|x].
The patch above appears good, however is it sufficient ?
The previous susceptible XPC service continues to be signed with the particular entitlement com.apple.rootless.set up. If I can launch the previous XPC service from the brand new OS, then will probably be exploitable once more, I feel.
To show my idea, I developed a brand new utility from the Xcode template, with an XPC servcie inside the applying bundle. Open the constructed utility bundle listing, and substitute the constructed XPC servcie bundle with the previous susceptible SystemShoveService.xpc. Lastly, my utility can launch the previous XPC servcie and ship malicious XPC requests to it to bypass SIP.
Now, it stops the previous susceptible XPC service from launching within the newest OS.
First, let’s search for some hints from Console log:
Then we’ll discover it within the perform postValidation from AppleMobileFileIntegrity.kext :
It provides a validation merchandise for the precise identifier “com.apple.installandsetup.ShoveService.System” from its signature.
Word that there are various different utility identifiers within the perform postValidation! Particularly the one at line 201: “com.apple.configd”.
After studying the weblog put up for CVE-2021-30970 : New macOS vulnerability, “powerdir,” could lead to unauthorized user data access, I didn’t know the way Apple repair it, however I might reproduce the problem on the patched macOS!
In brief, the system command /usr/libexec/configd has a particular TCC entitlement: kTCCServiceSystemPolicySysAdminFiles, which grants the command permission to vary a consumer’s residence listing and forge the consumer’s database file TCC.db. An attacker might inject a malicious dylib into the method to benefit from the particular TCC permission.
Nevertheless, I discovered the command was nonetheless not signed with hardened runtime on the patched OS.
It means the system command was nonetheless injectable. The keypoint is transferring the system command to a different location and launching it.
Fail to load the bundle:
sudo /usr/libexec/configd -d -v -t /tmp/take a look at.bundle
Load the bundle efficiently:
cp /usr/libexec/configd /tmp
sudo /tmp/configd -d -v -t /tmp/take a look at.bundle
In case you are curious in regards to the motive, I’ll write one other weblog put up to uncover what occurs underneath the hood.
Now in macOS 12.5, Apple patched the CVE-2021-30970 once more with two further recognitions (No CVE assigned but) :
-
Signed with hardened runtime:
-
Cease the previous susceptible configd command from launching in the identical perform of AMFI.kext:
Final however not the least, within the newest macOS Ventura Beta model, Launch Constraints defeats this type of exploitation successfully.
https://www.microsoft.com/safety/weblog/2021/10/28/microsoft-finds-new-macos-vulnerability-shrootless-that-could-bypass-system-integrity-protection/
https://perception-point.io/technical-analysis-of-cve-2022-22583-bypassing-macos-system-integrity-protection/
https://theevilbit.github.io/posts/amfi_launch_constraints/