Type yes as instructed, to allow the ssh connection to be established. 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. Leave that list open so you can watch what happens there.Ssh username is the short user name of your admin account. If they are, click on the padlock and authenticate, select each and remove them using the – tool. Scroll through that list and ensure that neither sshd nor sshd-keygen-wrapper are included in that list.
Sierra Full Access ToProvided 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. 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. 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. 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. 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 asAnd you should see the directory listing.Now try listing one of the protected directories, for example usingNot 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-wrapperIt’s the last of those, sshd-keygen-wrapper, which is critical.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. At that time, TCC was new and its log transactions little understood. 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. Two were not initially disclosed in public, the third was reported by Phil Stokes in the SentinelOne blog on 25 September 2018.It’s not a remote exploit: you have to download or install an infected xcode project, build it with XCode and run the result, and then say yes when it asks for administrator privileges. 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.I’m not exactly happy that there’s a vulnerability being exploited, but if you read the analysis it’s quite a stretch to make it happen. However, nothing changed and we all moved on, until Trend Micro’s detailed analysis of XCSSET malware, which exploits this vulnerability.In fact, having root permissions doesn’t give you access to protected data – that’s what TCC is all about.To use this bypass, there are three simple requirements: locally-running malware (which is pretty well everything likely to try exfiltration), Remote Login enabled (quite common among users), and the admin user’s password (one of the commonest requirements for successful malware, and easily tricked out of many users).In this particular case, it’s being used in a complex supply-chain attack, I agree. Indeed they’re doing a good job, in general.For myself, I bridle at being told that I can’t look at my own files, and I hardly ever use XCode: I’m more a vi + make kind of guy.This particular vulnerability doesn’t require gaining root permissions at all. I don’t really _mind_ that Apple is trying to make it safer for regular users, who have no reason to understand the workings. That’s why I use it myself. Ordinarily, to obtain access to protected data like cookies, the user has to give explicit consent by adding that app to the Full Disk Access list in the Privacy tab.The malware in question doesn’t do that, but gains full access all the same. It’s now in the repertoire of useful exploits.What if this malware developer builds on this product in the way that Xcodeghost did, and gets this exploit built into end-user software which is widely distributed?Maybe I need to build a PoC to bring this message home, that it’s not hard to bypass privacy protections completely.I’m not sure that you’ve seen where the vulnerability lies. I’m fairly certain this won’t be its last use either. I don’t know how it took so long maybe it has already been used by other malware. Visual studio enterprise 2017 for mac priceYou’d be able to look inside things like the versions database, which is now a Data Vault and can’t be opened by root at all. If it was Unix, then there’d just be permissions, and no SIP. There’s no “like” there.Being Unix-based is a matter of history, not of behaviour of its security and privacy protection. But if in doing so it lets malware do the same, that is a vulnerability, a gaping hole in privacy protection which is already being exploited in the wild.I hope that makes the situation clearer for you.Allow me to correct your misquote: “macOS isn’t supposed to be Unix at all”. This occurs without the user having to give any consent at all, and leaves them unaware that their data has been stolen, in this case using scp to copy it to a remote server.The vulnerability is therefore an effective bypass to the whole of privacy protection.I understand that some feel that ssh should be able to do this. Any further discussion of similarities and differences would degenerate into a discussion of what really constitutes the OS. So if it’s not Unix, the apple didn’t fall far from the tree (pun intended). I find myself waxing philosophically on these issues in my old age.Regarding the question of MacOS being Unix or not, my position is straightforward: MacOS was derived from NextStep which was derived from bsd 4.3 / et al., with only 13 years separating bsd 4.3 and the first incarnation of OSX. If that’s what Unix does, put me down for macOS instead, please.Finally, if a feature is being actively exploited by malware to exfiltrate private data, then how on earth can you pretend that it’s not a vulnerability?Hi Howard, great article, and robust comments. That’s a complete waste of effort on everyone’s part, isn’t it?Read the last section of my new postscript, in which I reveal how this vulnerability can be chained with another to give a user without root access free read-only access to every file in a snapshot. To be sure, MacOS isn’t the Unix of 40 years ago (thank goodness).
0 Comments
Leave a Reply. |
Details
AuthorStacey ArchivesCategories |