Full Report
When you log in to a WiFi network, you are automatically native to a captive portal. The browser that opens for the captive portal is not normal Safari—it's Websheet. Naturally, the author had some questions about the control that a user would have over the content and the sandboxing of the application. We can return a malicious page using a malicious WiFi dongle and Linux machine. This page will have a Webkit exploit in it, which is out of the scope of this post. Since this is automatically rendered when connecting, it's a zero-click attack surface. Unlike Safari, WebSheet doesn't use a split process model between the sandbox renderer process. So, if you find a web bug, you have code execution in the context of WebSheet. Once we're in this process, the sandbox is restrictive but the next goal is to see what we can do with it. The entitlement com.apple.managedconfiguration.profiled-access can be used to install a configuration profile, which includes a RootCA and proxy settings. This can also be used to install an additional fake app in the background, silently backdooring the device forever. The next interesting permission is com.apple.springboard.opensensitiveurl. This can be used to open sensitive URL entitlements. For instance, opening Safari. Using this issue, we can force a URL to be open once again and deliver the same WebKit exploit as before. I personally love this post. Most of the time, we say, "How can we get in?" or require a full chain of bugs. This post assumes we have a WebKit bug the extrapolates what we can do with it. Defense-in-depth measures only matter if we properly scrutinize them. The entitlements on this application feel like too much and it's interesting to see how they can be abused.
Analysis Summary