Way back in macOS Mojave 10.14, several of us noticed strange behaviour in its Remote Login service (ssh) which appeared to bypass privacy controls. I reported on this in detail here on 12 November 2018, fully expecting it to change in the future.

Most of us then forgot about it, until Mikey @0xmachos was studying the recent report by Trend Micro on XCSSET malware. There, in the analysis of a “Data Vault vulnerability used in Safari cookie theft”, described as “a zero-day vulnerability exploitation that is at large”, this long-known vulnerability is now being exploited by malware.

It’s easy to reproduce this on your own Mac, without needing a second system to connect to it.

First, open the Sharing pane, and ensure that Remote Login is enabled.

Then open the Privacy tab of the Security & Privacy pane, and select the Full Disk Access list at the left. Scroll through that list and ensure that neither sshd nor sshd-keygen-wrapper are included in that list. If they are, click on the padlock and authenticate, select each and remove them using the – tool. Leave that list open so you can watch what happens there.

Now open Terminal. Type in the command
ssh username@localhost
where username is the short user name of your admin account. If this is the first time that you’ve used ssh you’ll be invited to confirm the fingerprint generated before adding localhost to the list of known hosts. Type yes as instructed, to allow the ssh connection to be established. Shortly after that, you’ll notice that a new item has been added to your Full Disk Access list for sshd, the service which supports your ssh connection. This doesn’t actually give you full disk access yet – that comes shortly.

To confirm that your ssh connection is working correctly (to the same host, in this instance), type a simple command such as
ls ~
and you should see the directory listing.

Now try listing one of the protected directories, for example using
ls ~/Library/Calendars
Not only will you get a full listing without having been prompted to add anything to the Full Disk Access list, but another item will automatically be added to that list, named sshd-keygen-wrapper

It’s the last of those, sshd-keygen-wrapper, which is critical. If you now untick that item in the Privacy tab, trying to list that protected directory will return an error, reporting that the operation is not permitted. But if you instead remove the sshd-keygen-wrapper item altogether, it will be added back, enabled, and the protected folder will be listed in full. This is explained in detail with relevant log excerpts in my previous article.

To gain full access to any privacy-protected directory, all an attacker has to do is establish an ssh connection. Provided Remote Login is enabled, and sshd-keygen-wrapper isn’t both present and disabled (unticked) in the Full Disk Access list, macOS will automatically bypass its own privacy protection without any further control.

There are two measures you can apply to make this harder for an attacker: disable Remote Login and ensure that sshd-keygen-wrapper has been added to your Mac’s Full Disk Access list but is unticked there.

Until, that is, Apple does something to fix this vulnerability which is now coming up to two years old. And apparently being actively exploited in the wild.

Historical Postscript

When macOS Mojave 10.14 was first released, there were (at least) three vulnerabilities noted in TCC, its new privacy system. Two were not initially disclosed in public, the third was reported by Phil Stokes in the SentinelOne blog on 25 September 2018. To the best of my knowledge, that is the first report of this problem with ssh and Full Disk Access, so its discovery should be attributed to Phil Stokes, not me.

Several looked at the ssh issue, and I added it to my first list of bugs in 10.14. At that time, TCC was new and its log transactions little understood. In any case, many of us thought that Apple would address this in 10.14.1, but it didn’t, to my surprise, and the ssh issue was carried over to my next list of known bugs for 10.14.1. I then turned my attentions to the log records and reached the deeper understanding which I wrote up in this article.

By that stage, Phil Stokes had already reported the issue to Apple, who eventually replied that they were still looking at it. However, nothing changed and we all moved on, until Trend Micro’s detailed analysis of XCSSET malware, which exploits this vulnerability. At this time, it was assumed that this was newly discovered but it turns out to be the same as first reported by Phil Stokes nearly two years ago, and detailed in my article about six weeks later.