Skip to content

The Eclectic Light Company

Macs, painting, and more
Main navigation
  • Downloads
  • M1 & M2 Macs
  • Mac Problems
  • Mac articles
  • Art
  • Macs
  • Painting
hoakley August 20, 2020 Macs, Technology

The vulnerability in Remote Login (ssh) persists

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.

ssh01

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

ssh02

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.

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Pinterest
  • Email
  • Print

Like this:

Like Loading...

Related

Posted in Macs, Technology and tagged Big Sur, Catalina, macOS 10.14, macOS 10.15, macOS 11, malware, privacy, Remote Login, ssh, sshd, TCC, vulnerability. Bookmark the permalink.

15Comments

Add yours
  1. 1
    Andrew Reilly on August 20, 2020 at 7:41 am

    I’m pretty sure that if an “attacker” can establish an ssh connection, then you are, and should be, toast. Kind of the point of ssh. If I need to ssh into my machine (and I’m the only one who can), then I really don’t want macOS blocking me with something that will take a GUI to disable.

    I can confirm the behavior that you describe though: ssh-keygen-wrapper wasn’t in my list until I did ssh login and then log out again. Leaving it there but unchecked does indeed deny full disk access. So I won’t do that: I like my macOS being as Unix-like as it can be.

    LikeLike

    • 2
      Joss on August 20, 2020 at 9:05 am

      Afaik the exploit (XCSSET) doesn’t use a real ssh connection, but is only using the ssh-keygen-wrapper as a parent process to gain full disk access locally.

      LikeLike

      • 3
        hoakley on August 20, 2020 at 9:09 am

        It’s using scp, which is part of the same vulnerability, according to Trend Micro’s analysis.
        Howard.

        LikeLike

    • 4
      hoakley on August 20, 2020 at 9:08 am

      So you’re happy that a vulnerability which is being actively exploited by malware to gain unauthorised access to cookies – something that local apps can’t do without the user giving explicit permission – should remain for other malware to follow?
      If that’s Unix-like, I’m glad that macOS isn’t supposed to be Unix at all.
      Howard.

      LikeLiked by 1 person

      • 5
        Andrew Reilly on August 20, 2020 at 9:50 pm

        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. 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. To be sure, modern macOS with working SIP will try to protect you from even that eventuality, but traditionally, installing malware and giving it root permissions is a recipe for toast.

        Macos does (or at least used to) claim to be a fully standards-compliant Unix, and I’ve long considered it the best Unix workstation ever built. That’s why I use it myself. I don’t really _mind_ that Apple is trying to make it safer for regular users, who have no reason to understand the workings. 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.

        Cheers,

        Andrew

        LikeLiked by 1 person

        • 6
          hoakley on August 20, 2020 at 11:07 pm

          Thank you.
          This particular vulnerability doesn’t require gaining root permissions at all. 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. But this exploit is now out in the wild. I don’t know how it took so long; maybe it has already been used by other malware. I’m fairly certain this won’t be its last use either. 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.
          Howard.

          LikeLiked by 2 people

  2. 7
    Wally on August 20, 2020 at 8:00 pm

    I have Mojave 10.14.4 (18E2034) and none of the options you mentioned on your article are selected or available by default, and who in his/her right mind would want to SSH to their personal desktop and leave it available to connect out on the Internet?? If I needed to do that, I’d configure a bastion host or my SSH port would certainly not be dah port 22

    LikeLiked by 1 person

    • 8
      hoakley on August 20, 2020 at 9:30 pm

      Thank you.
      I’m not sure that you’ve seen where the vulnerability lies. 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. What it does is cheat the user into providing their password (or use a similar exploit), then connect to the protected folder on that same system. 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. 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.
      Howard.

      LikeLike

  3. 9
    noa shiruba on August 21, 2020 at 4:56 pm

    Hmm “Mac isn’t supposed to be Unix like at all?  Apple even bragged about being Unix based on their product page before, and anyone who has used the command line knows that it certainly is Unix based.
    More tot he point, I don’t consider this a vulnerability.

    TCC might make sense for local GUI applications, it does not make sense for SSH connections. For SSH to work properly, I need to be able to connect to my computer remotely and run the commands I want without something popping up on the GUI (or without there even being a GUI displayed at all).

    Web developers are using Macs for development, including SSH and command line access, and I am sure Apple uses it internally too. They wanted to add some protection without breaking the command-line, which makes sense.

    LikeLiked by 1 person

    • 10
      hoakley on August 21, 2020 at 5:41 pm

      Thank you.
      Allow me to correct your misquote: “macOS isn’t supposed to be Unix at all”. There’s no “like” there.
      Being Unix-based is a matter of history, not of behaviour of its security and privacy protection. If it was Unix, then there’d just be permissions, and no SIP. You’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. So macOS has parted from Unix in many of its fundamental behaviours, like them or not.
      If command tools, including ssh, are able to bypass security and privacy protections, then how can they do anything useful at all? All they are then is security theatre – they get in the way of legitimate GUI apps, but allow malicious software to use the tools to bypass the protection. 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. 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?
      Howard.

      LikeLike

  4. 11
    Bob on August 23, 2020 at 1:27 pm

    Hi Howard, great article, and robust comments. 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. So if it’s not Unix, the apple didn’t fall far from the tree (pun intended). Any further discussion of similarities and differences would degenerate into a discussion of what really constitutes the OS. I prefer to think of the OS as the kernel, with everything else being feature add-ons. To be sure, MacOS isn’t the Unix of 40 years ago (thank goodness).

    Regarding this “vulnerability” I am somewhat stuck on this statement:

    “To gain full access to any privacy-protected directory, all an attacker has to do is establish an ssh connection.”

    In other words, it behaves like a Unix system, minus the notion of “privacy-protected directory”. In other words, if we look at this in the context of any generic Unix platform, “all an attacker has to do is establish an ssh connection” is both a high bar and expected behavior. But because, in the Mac context, this breaks a security feature, we call it a vulnerability. An alternative way to look at TCC is a feature add-on, and as such, this is a feature bypass. Because that feature was supposed to improve security, we call it a vulnerability. I suspect this difference in the perspective is the cause of a robust discussion on the issue.

    LikeLiked by 1 person

  5. 12
    Bob on August 23, 2020 at 1:42 pm

    I should learn to finish my thoughts before posting.
    To be sure, this should be addressed because the situation violates intended design.

    The combining of a GUI with a command line has always been an uneasy marriage of convenience. I can recall in my early days of using OSX, foolishly using the passwd command to change my password, only to find out that certain things weren’t working right. A person more knowledgeable than me explained that I should use the GUI to do this. Which begged the question, why is the paswd command still there if it doesn’t achieve a complete password change? I’ve discovered commands with no man pages, and man pages that have no commands. The problem of developing a GUI in the context of a command-line system is that it’s hard to consider all of the ways the command-line might change things behind the GUI’s back. And worse, the command-line tends to be more fully-featured, allowing states of configuration not considered in the design of the GUI. This leads to strange representations in the GUI. Looks like this issue falls into that category.

    LikeLiked by 1 person

    • 13
      hoakley on August 23, 2020 at 6:21 pm

      Thank you. By a strange coincidence, my article of today is just about that.
      Howard.

      LikeLike

  6. 14
    Larry on August 24, 2020 at 2:27 pm

    If anybody wants to manually add ssh-keygen-wrapper to your Full Disk Access list and disable it, go to Settings -> Security & Privacy -> Privacy -> Full Disk Access, click the “+”, press shift-cmd-G to open the “go to the folder” pane, type in /usr/libexec, and select ssh-keygen-wrapper from the list.

    LikeLiked by 1 person

    • 15
      hoakley on August 24, 2020 at 4:29 pm

      Thank you.
      I’m still not sure whether you can remove that item from the FDA list using tccutil, though.
      Howard.

      LikeLiked by 1 person

·Comments are closed.

Quick Links

  • Downloads
  • Mac Troubleshooting Summary
  • M1 & M2 Macs
  • Mac problem-solving
  • Painting topics
  • Painting
  • Long Reads

Search

Monthly archives

  • February 2023 (17)
  • January 2023 (74)
  • December 2022 (74)
  • November 2022 (72)
  • October 2022 (76)
  • September 2022 (72)
  • August 2022 (75)
  • July 2022 (76)
  • June 2022 (73)
  • May 2022 (76)
  • April 2022 (71)
  • March 2022 (77)
  • February 2022 (68)
  • January 2022 (77)
  • December 2021 (75)
  • November 2021 (72)
  • October 2021 (75)
  • September 2021 (76)
  • August 2021 (75)
  • July 2021 (75)
  • June 2021 (71)
  • May 2021 (80)
  • April 2021 (79)
  • March 2021 (77)
  • February 2021 (75)
  • January 2021 (75)
  • December 2020 (77)
  • November 2020 (84)
  • October 2020 (81)
  • September 2020 (79)
  • August 2020 (103)
  • July 2020 (81)
  • June 2020 (78)
  • May 2020 (78)
  • April 2020 (81)
  • March 2020 (86)
  • February 2020 (77)
  • January 2020 (86)
  • December 2019 (82)
  • November 2019 (74)
  • October 2019 (89)
  • September 2019 (80)
  • August 2019 (91)
  • July 2019 (95)
  • June 2019 (88)
  • May 2019 (91)
  • April 2019 (79)
  • March 2019 (78)
  • February 2019 (71)
  • January 2019 (69)
  • December 2018 (79)
  • November 2018 (71)
  • October 2018 (78)
  • September 2018 (76)
  • August 2018 (78)
  • July 2018 (76)
  • June 2018 (77)
  • May 2018 (71)
  • April 2018 (67)
  • March 2018 (73)
  • February 2018 (67)
  • January 2018 (83)
  • December 2017 (94)
  • November 2017 (73)
  • October 2017 (86)
  • September 2017 (92)
  • August 2017 (69)
  • July 2017 (81)
  • June 2017 (76)
  • May 2017 (90)
  • April 2017 (76)
  • March 2017 (79)
  • February 2017 (65)
  • January 2017 (76)
  • December 2016 (75)
  • November 2016 (68)
  • October 2016 (76)
  • September 2016 (78)
  • August 2016 (70)
  • July 2016 (74)
  • June 2016 (66)
  • May 2016 (71)
  • April 2016 (67)
  • March 2016 (71)
  • February 2016 (68)
  • January 2016 (90)
  • December 2015 (96)
  • November 2015 (103)
  • October 2015 (119)
  • September 2015 (115)
  • August 2015 (117)
  • July 2015 (117)
  • June 2015 (105)
  • May 2015 (111)
  • April 2015 (119)
  • March 2015 (69)
  • February 2015 (54)
  • January 2015 (39)

Tags

APFS Apple AppleScript Apple silicon backup Big Sur Blake bug Catalina Consolation Console diagnosis Disk Utility Doré El Capitan extended attributes Finder firmware Gatekeeper Gérôme HFS+ High Sierra history of painting iCloud Impressionism iOS landscape LockRattler log logs M1 Mac Mac history macOS macOS 10.12 macOS 10.13 macOS 10.14 macOS 10.15 macOS 11 macOS 12 macOS 13 malware Mojave Monet Monterey Moreau MRT myth narrative OS X Ovid painting Pissarro Poussin privacy realism Renoir riddle Rubens Sargent scripting security Sierra SilentKnight SSD Swift symbolism Time Machine Turner update upgrade Ventura xattr Xcode XProtect

Statistics

  • 13,811,667 hits
Blog at WordPress.com.
Footer navigation
  • About & Contact
  • Macs
  • Painting
  • Language
  • Tech
  • Life
  • General
  • Downloads
  • Mac problem-solving
  • Extended attributes (xattrs)
  • Painting topics
  • Hieronymus Bosch
  • English language
  • LockRattler: 10.12 Sierra
  • LockRattler: 10.13 High Sierra
  • LockRattler: 10.11 El Capitan
  • Updates: El Capitan
  • Updates: Sierra, High Sierra, Mojave, Catalina, Big Sur
  • LockRattler: 10.14 Mojave
  • SilentKnight, silnite, LockRattler, SystHist & Scrub
  • DelightEd & Podofyllin
  • xattred, Metamer, Sandstrip & xattr tools
  • 32-bitCheck & ArchiChect
  • T2M2, Ulbow, Consolation and log utilities
  • Cirrus & Bailiff
  • Taccy, Signet, Precize, Alifix, UTIutility, Sparsity, alisma
  • Revisionist & DeepTools
  • Text Utilities: Nalaprop, Dystextia and others
  • PDF
  • Keychains & Permissions
  • LockRattler: 10.15 Catalina
  • Updates
  • Spundle, Cormorant, Stibium, Dintch, Fintch and cintch
  • Long Reads
  • Mac Troubleshooting Summary
  • LockRattler: 11.0 Big Sur
  • M1 & M2 Macs
  • Mints: a multifunction utility
  • LockRattler: 12.x Monterey
  • VisualLookUpTest
  • Virtualisation on Apple silicon
  • LockRattler: 13.x Ventura
Secondary navigation
  • Search

Post navigation

Skying 6: Pre-Impressionism
Nalaprop version 1.0 is released as a Universal App

Begin typing your search above and press return to search. Press Esc to cancel.

  • Follow Following
    • The Eclectic Light Company
    • Join 3,137 other followers
    • Already have a WordPress.com account? Log in now.
    • The Eclectic Light Company
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Copy shortlink
    • Report this content
    • View post in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...
 

    %d bloggers like this: