A bit of a tangent from my usual work, but here with a fun one: CVE-2023-44077! A privilege escalation vulnerability in Studio Network Solution’s ShareBrowser application, thanks to unguarded XPC services 🎉.

Examining ShareBrowser’s bundled launch services

To start off, we’ll install ShareBrowser’s macOS client (v6.1.5.27) and check what launch services our Virtual Machine registers:

If we examine one of these daemons, for example com.sns.evo-slingshot-helper.plist, we see that it exposes a Mach Service for processes to attach onto:

When we look at the rest of the services, we see 3 out of 5 of them expose a Mach Service:

Service Variant Exposed XPC service Running as root
com.sns.sbdccommunicationhelper.plist Agent sbdccommunicationhelper No
com.sns.evo-slingshot-helper.plist Daemon EvoSlingshotHelper YES
com.sns.sbdcmounthelper.plist Daemon sbdcmounthelper YES
com.sns.sbdiskservice.plist Daemon   YES
com.sns.sbhmdimporter.plist Daemon   YES

Digging deeper into XPC services

Now that we found some launch services with exposed Mach services, let’s take a peek inside how one works.

We’ll load up /Library/EVO ShareBrowser/EvoSlingshotHelper into Hopper Disassembler, and take a peek at -[BaseSlingshotService listener:shouldAcceptNewConnection:]:

Those who have worked with XPCs before might be having PTSD right now. For those who don’t, let me explain.

In an XPC service’s shouldAcceptNewConnection method, there should be some form of validation performed before blindly accepting a connection. Why this is important is that anything that connects will gain the abilities of that service. This includes the elevated privileges and XPC functions that might include sensitive information.

For ShareBrowser’s EvoSlingshotHelper specifically, this daemon has process calls, API calls, user credentials processing, etc inside. And since this application is written in Objective-C, it’s inherently at risk of memory safety bugs and potentially vulnerable to additional attacks such as buffer overflows for arbitrary code execution as root.

Now add this with sbdccommunicationhelper and sbdcmounthelper, we have a fun trio of potentially vulnerable services.

Possible solutions

Thanks to some amazing posts by Wojciech Reguła, Csaba Fitzl, Erik Berglund and Christian from Objective Development, we have some great resources to understand both the severity and solutions to ShareBrowser’s issues:

The simplest answer without going too deep is to ensure there’s proper code signature verification on processes wanting to attach. This means comparing the calling binary to a trusted certificate like a notarized binary with the developer’s Team ID.

If we take a peek at a good platform citizen, such as WhiteBox’ Packages, we see that they’ve implemented proper code signature checks that verify the authenticity of the application calling, and as such isn’t as easily abused:

Reporting process

Overall a bit annoying process as with most companies lacking a security team, mainly caused by poor communication. While not expecting a bug bounty, there was no compensation, notification of a public release or even crediting us for the vulnerability…

Though overall the main issue we faced was that after reporting the issue, we didn’t get a proper team to respond until after we threatened to publicize the vulnerability and have a CVE ID associated.

Remember kids, threatening to run to the press doesn’t just work on Apple ;p

Sender Topic Date
RIPEDA Vulnerability Discovered September 14th, 2023
RIPEDA Vulnerability Reported to Client September 19th, 2023
RIPEDA Vulnerability Reported to Studio Network Solutions September 19th, 2023
SNS SNS Support’s Automated Reply September 19th, 2023
SNS SNS Support’s Employee Reply September 21st, 2023
RIPEDA Response Back, asking for the existence of a security team September 21st, 2023
RIPEDA Escalation, warning of publication September 24th, 2023
RIPEDA Request for CVE ID from MITRE September 24th, 2023
MITRE Assigned CVE ID (CVE-2023-44077) September 26th, 2023
SNS Replied back, reporting XPCs will be optional September 27th, 2023
RIPEDA Requested confirmation that XPCs will be patched September 27th, 2023
SNS Confirming XPC patch and providing sample build October 4th, 2023
RIPEDA Request for update on release December 5th, 2023
SNS Replying saying they’re slowly rolling out of v7 to clients December 7th, 2023
SNS Releasing ShareBrowser v7.0 (without notifying us…) January 3rd, 2024
MITRE CVE Published January 17th, 2024

Verifying the updated bundles

Studio Network Solutions’ interim solution to this vulnerability was to strip all XPC services and have us deploy it to all machines we manage. Finally, after several months, we were able to grab an official copy to verify the fix.

Examining ShareBrowser v7.0.0.12 (archive.org mirror), we see they’ve stripped all but 1 launch service: com.sns.sbdcmounthelper.plist

This service, as with before, points to /Library/EVO ShareBrowser/sbdcmounthelper. When we examine this daemon again, we see signature verification! Specifically ShareBrowser is verifying against their Team ID, 76PTYDYVW4 🎉

Conclusion

Overall I’m fairly happy this vulnerability was patched however I would advise Studio Network Solution customers to be cautious when handling sensitive information through SNS products. As there doesn’t seem to be a security team, you should keep in mind that future vulnerabilities may not be handled with the most care.

Otherwise this was a really great learning opportunity for me. Since this initial discovery, RIPEDA has implemented Project Zero’s 90+30 disclosure policy to avoid issues with delayed vendor rollouts in the future. And big thanks to Devin Byrd (Wanderingbug), Csaba Fitzl (theevilbit), and others on the macOSsec slack for their help answering my questions!

And for everyone else developing XPC services, make sure you properly validate who’s connecting!