This malware gets onto systems 100% through social engineering. It lures users to download the software, run it, ignore the OS warning that the code isn’t signed, and then enter their password.
So, what should Apple do in response to such malware? Make it impossible for user code to read the entire keychain, even when running as admin? Containerize macOS more, making it impossible for user programs to access files written by other programs, in the way things work on iOS? Ignore it because, at some point, security becomes the user’s responsibility?
If tools like these get popular, I can see them getting blamed whatever they do or don’t do.
the narrative the users are helpless is a favorite, for sure. How real is that? Who gains what by simplifying this narrative? How are computers out-of-the-box experience changing with respect to corporate walled gardens, intrusive monitoring, long-term record keeping, links to government issued ID, corporate parallels to ID, or links to an active payment method?
if you have one thousand users of desktop computers distributed across geography and age groups, and you watch whatever behavior it is that you claim is "it" ... how many of the thousand users show the weakness or lack of care or lack of self-defense.. How many ? four? four hundred?
if four hundred users fall for some scammy website using a browser on the internet, you mean to say that every user must have bicycle training wheels and constant adult-supervision monitoring? Do you make money in some business-model that does that?
I assume the response should be to detect and block this malware specifically, rather than generally locking the OS down more. macOS comes with built-in antivirus called XProtect[0], in the vein of Windows Defender but less obnoxious.
The attack surface of Windows is massive, with legacy cruft tucked into every corner. Not saying Defender couldn't be optimized and improved, just that defending the monolith that is Windows is a monumental task.
I've never had Windows Defender use a noticable amount of CPU. It is, by far, the least intrusive antivirus/anti-malware that I've used (and I've used them all).
Unfortunately, I can only provide my anecdotal experience, but it seems to be in stark contrast to your comment.
Probably make it so that only notarised apps can read the whole keychain, unless presented with a system dialog that states very clearly what is happening.
There used to be a line of thinking in the capability-based security world which said "combine designation with authority".
In other words, instead of a 2-step UX like this: (run as admin) + (let app do any admin type thing)
Your system should have multiple explicit 1-step UXs: (let app do admin thing X)
The later will presumably present a more clear explanation to the user of what they are doing.
Of course, no Real(tm) capability-based GUIs have ever been built to my knowledge, not even in academia, so this is an entirely theoretical argument and not a criticism of Apple.
For things that, historically, didn’t require any additional authentication, both macOS and iOS are moving in that direction, I think.
On MacOS, applications by default don’t have the right to read your disk and show a list of files, they have the right to ask the OS to show a dialog that reads your disk shows a list of files, lets you pick one, and then grants that application the right to read that one file. Similarly, for saving files, the save dialog runs under OS control, and grants an application to write a single ‘file’ (which, on macOS, could be a directory containing multiple files)
Similarly, on iOS, apps can’t read photos, but can ask the OS to show a photo picker.
MacOS (¿still?) has system preferences that allow users to disable such checks, though, granting full file access to certain apps, for example, and also will ask users to grant apps the right to read entire file systems when they try to do so.
>MacOS (¿still?) has system preferences that allow users to disable such checks, though, granting full file access to certain apps, for example, and also will ask users to grant apps the right to read entire file systems when they try to do so.
Yes you can still disable a lot of this stuff. But I wonder if this is a case where a hardware aspect could let Apple make that less necessary without degrading UI. In principle, with cryptographic signing for input peripherals keyboard/trackpad/mouse/etc, secure processing element routing through it, and the right low level protected kernel support and signed stack, it would be possible to have the OS be able to distinguish between "operator initiated" and "automated" access at a fairly granular level. It'd even be possible to pass that on from one Apple system (or others if it was a standard) to remote ones via SSH or the like. That in turn could enable the system to have different UX between the two classes. For example like a some other HNers I assume I currently grant Terminal full disk access right out of the box as one of my first setup steps just because it's a real irritation to not be able to navigate around and use it from the CLI as I expect without GUI stuff popping up. But instead a system could transparently make it so that when I typed in commands into the shell they'd actually be treated with different permissions than if an automated shell script did the exact same commands, and this could be the case everywhere with a high degree of security. Much more intelligent granting of capabilities would make the UX a lot less irksome and could help push a request for human attention and decision making from the default to the unusual, and that in turn would encourage leaving it on.
I think Apple does already do this to some extent actually? Like, in a native widget GUI app, if the user initiates the GUI open/save file finder they're able to navigate to places outside the sandbox? I might be misremembering. But at any rate extending that as a low level hardware backed feature could be an important step in capabilities usability. Security has to have its costs in line with perceived benefits, or users will just end up degrading it (classic "just write the password on a sticky note leave it on the monitor" issue). The human element isn't a bug it's a core requirement, so would really like to see more effort on that side of things as well.
Whenever an app that has no business knowing my location asks for it, I always wish that iOS "Always Share/Share While Using/Share Once" modal had the additional option "Share Fake Location."
I get why it doesn't (the problems it would cause for Uber and DraftKings immediately come to mind) but the more sketchy advertisers there are who want to track my location data, the more I want that data to be garbage.
This is a fantastic comment for someone (like me) hungry to learn about security concepts. Do you have any more pointers to useful info about security topics?
Security is a pretty broad topic and it's not really my speciality I'm afraid.
That being said, I used to be very interested in capability-based security because it promised solutions to so many security problems but nobody seemed to know about the ideas, and the people who had heard the term often had significant misunderstandings of what was possible with capabilities.
It's been about 20 years but I mostly had it right ;)
> It lures users to download the software, run it, ignore the OS warning that the code isn’t signed, and then enter their password.
Warnings like this are useless when they bundle genuinely dodgy software along with software from legitimate companies I already trust and know. Those messages means nothing to me, and I ignore them, because they're warning me about something I already know "You're trying to run software you downloaded" — yeah, thanks.
> Make it impossible for user code to read the entire keychain
What I've always found kind of bonkers, is that MacOS allows any command to read the entire contents of your keychain (yes, with all your passwords). No auth, no checks, just full access via the `security` command.
> Containerize macOS more, making it impossible for user programs to access files written by other programs, in the way things work on iOS?
Maybe? I don't know if that's the right direction (it definitely isn't for me, and I'd jump ship), but perhaps that's the best thing for most people?
>Warnings like this are useless when they bundle genuinely dodgy software along with software from legitimate companies I already trust and know.
Since running unsigned apps is disabled by default, they are not bundled like this. One is prevented from running at all.
You can change the system to treat them as roughly equal parties (one still gets a warning while the other does not), but preventing this from being possible at all would be worth even more outrage.
If you want this kind of safety for someone who you can't trust to consider these kinds of risks, set their computer up so they can't change that setting and they don't have root access. That's just a second user account. Yes, they'll have to use the app store..... but that's the way it works everywhere.
I think it's entirely fair to say that their post essentially summarizes as "what we currently have is probably not enough" and ends in an implied "maybe we need more [though I would personally rankle at it]". So in some ways they did.
But yes, I agree: they do not actually suggest any new restrictions, and I did not mean to imply that they did. I just meant to head off the obvious rebuttals, and make my stance clear: you cannot have "allow the knowledgeable to do X" and "prevent the un-knowledgeable from doing X" in the presence of social engineering at a technical level, and there is ample evidence that more popups and friction are not an effective solution. So a safe default and reasonably-ergonomic-but-not-accidentally-trigger-able ways around it seems roughly ideal IMO.
I think OSX hits that balance fairly well: block by default, right-click -> open to bypass individually (arguably accidental-able, but odd enough compared to double-click and there is still a clear warning displayed), or change settings to allow by default. It's both effective and friendly, and going further in either direction seems like it requires major sacrifices in the other. And when you do want those sacrifices, you can get them (non-admin account or disable it entirely).
> MacOS allows any command to read the entire contents of your keychain (yes, with all your passwords). No auth, no checks, just full access via the `security` command.
No, that's not true. macOS has multiple keychain APIs with different capabilities.
Items within the traditional keychain can have ACLs applied to them. When you run `security dump -d`, it will only be able to dump items from a traditional keychain that are either set to allow access to all apps, or that have an ACL that grants access to `security`. Very few items should be set to "Allow All". In my login keychain, almost none are.
For all other items you will get a security prompt with "Always Allow", "Allow", and "Deny" which requires you to enter your password. You can also set items to require confirmation but not require the keychain's password.
If you add `security` to an item's ACL--say because you need access to that item from a script--then any app can of course access that item by calling `security`. My advice would be not to add `security` to any item's ACL.
AFAIK, `security` has no access to the iCloud Keychain where Safari stores its passwords. If you don't have iCloud Keychain enabled, I believe Safari stores its passwords in a traditional file-based keychain but those items should have ACLs on them.
Custom keychains are also available if you worry about malware dumping unlocked keychain data via kernel privilege escalation (to bypass ACLs). For critical items that you decrypt once a year, it doesn't make much sense to use the resident login and iCloud keychains.
ACLs shouldn't be overlooked though: manual keychain items use the default ACL configuration and require user confirmation, which means you need to authenticate N times to access N items.
> AFAIK, `security` has no access to the iCloud Keychain where Safari stores its passwords. If you don't have iCloud Keychain enabled, I believe Safari stores its passwords in a traditional file-based keychain but those items should have ACLs on them.
Clarifying my own comment.
Safari stores its passwords in the data protection keychain. This is called "Local Items" in the Keychain Access app if iCloud Keychain is not enabled. If it is enabled, it's called "iCloud Keychain". Either way, `security` does not enumerate any items from the data protection keychain, only from the file-based keychains. And again, all the items in those keychains should have ACLs on them.
> Items within the traditional keychain can have ACLs applied to them. When you run `security dump -d`, it will only be able to dump items from a traditional keychain
Could it be that the Terminal has full access then? I've never been asked for a password, or had a restriction of any kind put on me, when using the `security` command. Those prompts you speak of are for the "Keychain Access" GUI, no?
Access is gated upon `/usr/bin/security`, not the Terminal app.
The security prompt to "Allow All", "Allow", or "Deny" when a process tries to access a keychain item's value is a GUI window, but it's not part of any app.
To sign your software you need to dox yourself to your users and pay a fee for a cert. I think there should be organizations that will sign open source software for you with their certificate, not sure if this is allowed.
Why otherwise would end-users trust individual developers or tiny orgs, esp. from countries without much rule of law? What else gives your users assurance a binary isn't bundled with adware, malware, trojans, or privacy compromises, either now or won't sneakily be at any time in the future when the developers might cash out to some unknown org, or else simply want to generate a sneaky new revenue stream without their users' informed consent?
Suggesting an umbrella organization give the primary assurance of trustworthiness is similar to what SourceForge used to do, until their practices destroyed their reputation back in 2013, and also greatly damaged the reputations of legit developers who used their site. [https://en.wikipedia.org/wiki/SourceForge#Controversies]
Do what mobile OS do and make the app ask for permissions just before it needs to do something special.
Make it impossible to ask for root. Sandbox apps.
Linux distributions package applications (including binary ones) for their users, why can't macOS or Windows do this? Run automatic safety checks on them before deploying updates to users. The Windows Store and Apple's App Store (on macOS) are kind of like that, but they only have applications that developers chose to put there. I don't see Linux distributions asking developers for permission to package their application (there are proprietary packages on Arch and NixOS), so I don't see why Apple couldn't do the same.
macOS already does all of that for all programs. I think the main problem here is that macOS only protects certain directories and not others. Programs can request access to Documents or Downloads, or they can request full-disk access (e.g. to read Library/Messages).
For unprotected directories like Library/Keychains, programs can just copy the encrypted database. Since the malware obtains the keychain password with a fake password prompt, it can decrypt the database.
That's an aspiration. It's not what Android does these days.
Mobile OS permissions (at least Android) have become pretty weaselly.
Protecting you from malware blatantly asking for root is obviously very important. Sandboxing is important.
But the sneakier use of permissions for privacy exploits and data harvesting is different and more subtle.
GasBuddy ("GasBuddy Is a Privacy Nightmare")[0] is a case in point. Geolocating users and selling that to everyone. Harvesting users' driving habits then selling those to Allstate subsidiary Arity ("turning mobility and driver data into meaningful behavioral insights, leveraging telematics to make transportation smarter, safer, and more useful for everyone!"). (But there's an opt-out!)
So are fitness apps and trackers. Private equity loves acquiring them.
Permissions can be abused in ways that aren't made obvious to users. Obvious example: just because you disable "location access", doesn't mean the app can't (indirectly) geolocate you in a variety of sneaky ways.
Even if the app doesn't intentionally crash if you disable its location access: indirectly geolocating users indirectly from IP addresses or metadata on photos they upload. Device fingerprinting from motion sensors, so that you can track a unique user across networks and devices, and develop "behavioral insights". And on and on.
How does signing dox you? It doesn’t really include much in the way of identifiable information
Your idea would defeat the purpose of signing , which is to trust the delivery. If a company was sharing their signing certificate, nobody would know it came from you, and it would take just one malicious person also using that certificate to get everyone’s apps pulled.
> is that MacOS allows any command to read the entire contents of your keychain (yes, with all your passwords).
In Windows and Linux any application also can read any user's file. And in Chrome and Firefox, any extension can read browser history, capture key presses and so on. If you install Python packages, they can do anything to your computer, if you download a plugin for Gimp the same issue exists. On desktop security is broken since forever. OS developers (especially Linux developers) cannot innovate and use outdated security model from 80s where users are isolated from each other but today most computers have a single user and it makes little sense. Today you need to isolate program from a program, and prevent them from fingerprinting user's device (for example, in Linux any app can read MAC addresses, hardware serial numbers, list of nearby WiFi points and nobody cares about that).
> Linux any application also can read any user's file
Surely you mean any root application? Or is my understanding of the Linux security model completely incorrect?
> And in Chrome and Firefox, any extension can read browser history, capture key presses and so on
Also no, extensions have different privileges you must accept. There are lots of problems with that security model, but it doesn't any extension can do those things
> No auth, no checks, just full access via the `security` command.
Indeed, that security command was definitely a misnomer.
However these days it's not as easy, you get a pop-up for every app that wants to access the keychain.
The bigger problem though is that Apple resorts to pop-ups way too much. Installing a new Mac with my work stuff I get 30 of them. This causes fatigue and totally fails to solve the problem.
In fact it does the exact same thing that Apple blamed Vista for in their Mac vs PC ad. In fact macOS is worse now than Vista ever was. https://youtu.be/VuqZ8AqmLPY
I think a fully isolated developer mode user would be great - similar to Google ChromeOS would be interesting.
While there are some drawbacks in that you wouldn't be able share files/clipboard as easily, there are more ways to ensure more complete isolation.
I could forsee containerization being much more prone to social engineering of a novice non-technical user (i.e. stealing the clipboard, accidentally giving file access, etc.)
This malware gets onto systems 100% through social engineering. It lures users to download the software, run it, ignore the OS warning that the code isn’t signed, and then enter their password.
HN: "Apple products are so insecure, you can run anything on them!"
Also HN: "Apple products are too locked down. I can't run anything on them!"
>So, what should Apple do in response to such malware?
tbh I think they're already doing the best option:
>ignore the OS warning that the code isn’t signed
OSX ships with "run unsigned apps" completely disabled by default, so normally that option won't even be presented.
You can of course socially engineer someone to run it anyway, by changing that system setting... but you'll never stop social engineering entirely. It's always a question of what degree you'll go to, not if it's possible or not.
> OSX ships with "run unsigned apps" completely disabled by default
I’m behind the upgrade curve, so I had to look this up to see if it’s changed but it hasn’t. The default still allows running unsigned apps without any configuration change. You just have to know how to do it, which is a pretty good sensible default. If you don’t know how, it’s a trivial search away.
> so normally that option won't even be presented.
Which is why it’s a good sensible default. Most users who don’t know how to work around it won’t bother, and they’ll benefit from it. The rest of us who do know how will take a brief pause to consider the risk before disregarding the warning.
The people who will just blanket turn off the protection are either very confident in their own risk assessment capabilities because they should be, or because they wouldn’t be protected by any mechanism whatsoever.
I want macOS to be as locked down as iOS when my dad, wife and son use it but I want it to be as open as Linux when I use it. Perhaps it should be closed by default but have a developer mode that behaves how macOS behaves today.
> Make it impossible for user code to read the entire keychain
Now I’m pissed, because having endured the ordeal that was exporting the keychain, when migrating off of it to a proper password manager, I would have sworn it was already impossible to do so in any practical manner. Now I find out malware can do it? They’ve already made it nearly impossible to do legitimately!
Apple should not take any action. Imposing further restrictions on macOS would be unjust for the majority of users simply because some people choose to disregard clear warnings.
Decades ago, when software warned users about potential dangers, they would either accept the risk or avoid it. Nowadays, software has been so infantilized that people expect a guaranteed positive outcome, even when ignoring warnings, while "free thinkers" online argue that every warning is a false positive.
Philosophically, I don't think we should cater to this mindset. If someone decides to fall prey to an evident scam or install malware on a critical system despite clear warnings, that's their prerogative. This principle holds true beyond just software.
I genuinely dislike the trend of dumbing down and infantilizing everything in the world. This includes simplifying education to stifle exceptional kids, prioritizing clickbait over nuanced news, the prevalence of exaggerated content on social media just because it's easier to consume, watered-down movies and music designed to exploit mass audiences, political populism obscuring real problems, a flood of shallow literature, and suppressing innovation in technology due to it being inherently risky (like the slow pace of space exploration-related advancements compared to the 1960s). Regrettably, software has not been spared from the "dumbing down" to accommodate the lowest common denominator. This philosophy leads to decadence, disempowerment, and a loss of richness in whatever field it infiltrates. In my view, it is regressive.
What has happened to critical thinking in recent decades? It used to be sufficient for us to navigate life despite a little danger, challenge, and risk. "Danger" should not be a shunned taboo concept, it is an inherent part of life.
In short, use critical thinking, don't listen to forums that say WhatsAppCracked100PercentSafe.apk/.dmg/.exe is not a security risk. Or take accountability for your actions if you still install it — it is your prerogative. But it shouldn't be anyone else's responsibility to make sure you don't harm yourself. Same as in other areas of life.
> MacStealer being an unsigned DMG file is also a barrier for anyone, especially beginners, attempting to run the program on a modern mac, said Malwarebytes' Reed. "Its attempt at phishing for login passwords is not very convincing and would probably only fool a novice user. But such a user is exactly the type who would have trouble opening it."
Given the above and the default macOS security configuration, you really have to work your way to get this malware running.
This might be a good place to ask: I have Malwarebytes installed but aside from that nothing really. What's the recommended software stack to stay as protected as possible?
> On a Mac, just keep up with software updates and think really hard before overriding security warnings.
Also, while SIP wouldn't have helped in this particular situation, consider if it's really necessary to disable it. Living with SIP on is occasionally cumbersome, but I don't trust myself enough to run without it on, even as someone who's been a technically-minded computer user for coming up on a quarter of a century and a dev for over half of that.
If disabling SIP is ever truly necessary for me I think I'd do it in a VM. Especially on M-series machines virtualization of macOS has gotten quite good.
I've literally never had a need to disable SIP. About the only reason you could possibly need to is if you're doing particularly weird kernel driver development, and I'm not sure that's needed even then.
I think the most common cited reason to disable it that I've seen is the ability to attach a debugger to any program, even those using the hardened runtime, which isn't something I've needed thus far.
As things stand currently, sure. Nothing critical or tied to my livelihood is done on my gaming tower's dual booted Fedora install, it's mainly there to scratch tinkering itches. Similarly that tower's Windows install is used only for games and MS platform tinkering.
If Linux were to become my daily driver OS I'd probably enforce a greater degree of separation between machines, with e.g. one Linux box exclusively for work things, another for finance, etc which is pretty easy to do with cheap old laptops. This limits the potential blast radius and reduces chances of getting hit in the first place, with e.g. how there's no good reason to run random untrusted binaries on the finance laptop.
This is really the only Mac security advice anyone needs.
There are two categories of Mac malware: Ones where you have to enter your admin password into something that should have already raised several red flags by the time you see the prompt, or zero-days that are so stratospherically expensive that if you are an individual who would be targeted by one, malware is only one part of your overall threat model.
Linux. It has been "ready for the desktop" for more than a decade but it is not yet targeted by this type of malware. If it ends up being popular enough that will change but for now it is spared this disease. The advent of immutable distributions makes for a harder target for malware if and when this becomes a problem.
Most Linux distribution do still not have a properly verified boot chain, even something at the core of system boot like initrd is unsigned (which asks your LUKS password). There are immutable distributions, but they don't use sealed, cryptographically verified volumes. It is still trivial to modify the store in most immutable distributions to inject malware. User applications have no isolation at all, every app that parses untrusted input and does network access can read/write your whole home directory, including private keys, AWS credentials, etc. (most people don't use smartcards). Browsers only have some security because the browser developers have built their own sandboxes, but a determined actor can probably break it without too much issue through hardware acceleration APIs, etc.
macOS as many times more secure than the Linux desktop. The only reason Linux is not a malwarefest is because the market share is so small that it is not that interesting.
Why do you believe governments don't have backdoors in the open source ecosystem? It's very easy to slip innocent looking bugs into open source projects with plausible deniability. See e.g. heartbleed or the Debian OpenSSL bug. Note that I am not claiming that these bugs are made by state actors. Just to show that it is easy to slip vulnerabilities in billions of lines of open source code that are used in a Linux desktop system. Heck, the FBI even tried to slip backdoors in OpenBSD which is only a marginal project in terms of high-value targets [1].
If any government has backdoors in macOS outside open source software in macOS, it is probably very limited (the US government if any, but Apple seems to resist most attempts at weakening security).
It’s much easier to put in a backdoor, or actually implement a small monitoring system, in a closed source operating system.
That’s much harder with open source software, not due to technical reasons, but because there is a good chance that eventually it will be discovered by some developer or security researcher. That will cause distrust of the government, and people going to defensive mode, making it much harder for governments to routinely hack into devices.
So, for example, the discovery of the flaw in the Debian random number generator had a huge impact. People who design security systems really pay attention to PRNGs nowadays (to the point that it seems weak PRNGs are no longer a significant concern in the mainstream desktop operating systems, though the issue obviously remains in IoT, virtual machines, HSMs etc).
Hiding the code for malware is common sense. That’s also why governments severely punish leaks these days.
I think your logic stands when thinking about individuals or private organisations.
But when thinking about state actors they almost have unlimited money/resources thus even if adding a backdoor is a bit harder on open source having unlimited money/resources makes it irrelevant.
Where “unlimited” = to the size of the open source organisation that maintains a bit of software.
It's easy to hide backdoors in open source applications.
It's easy to detect backdoors in closed source applications.
People should definitely be using open source for as much as possible, because I want to live in a world that makes it as easy as possible for beginners to understand how their underlying software systems are working. The whole "backdoor" FUD just seems lazy though.
Linux for the desktop indeed has hardly progressed the last decade, and it sucks. Sure, gnome is more polished, but it's still a system for tinkerers. It's not user friendly and it's not a complete environment for end-users.
Honestly though, in my experience macOS especially has a habit of presenting legitimate password dialogs completely out of the blue. It clearly trains users to enter their password into random dialogs that appear at random times.
This is something that hasn't been fixed despite years of complaints from the security community for exactly this reason.
It's especially annoying as touchid provides a standard authentication mechanism on macOS, that doesn't provide reusable credentials to anything.
Agreed. I am so trained by macOS that it needs my iCloud password or account password randomly that I don’t even think about it anymore. I like to consider myself a savvy computer user, but I frankly only give myself a 50% chance at best of identifying a malicious password prompt at this point.
Use an outbound firewall like LuLu https://objective-see.org/products/lulu.html. It won't necessarily stop an infection but almost all malware wants to phone home. Explicitly approving every outbound request blocks this.
Crypto is incentivizing a lot of new malware. We're getting to see how MacOS fares when faced with real targeted attacks. I feel that in the end, everyone will have to copy the Windows security model, which has had to deal with these attacks for decades.
What is the security model that you think windows uses that Mac doesn't?
Already on Mac there are plenty of things you simply cannot do as root/super user/administrator, no matter how many passwords you have or enter. Having code execution in a user account doesn't provide full access to all the user's files and data, etc.
I'm curious as to exactly what this malware is doing - is it bypassing SIP and/or entitlement checks, or is it essentially the same as downloading a bash script and running it and giving it your admin password.
So I need to double click an unsigned DMG downloaded most likely from an unreputable source, bypass any security warnings, and then I'm vulnerable.
I wonder how many people got infected in the wild. Also, it's any moment that Telegram removes the channel that is used for C&C, making the malware virtually ineffective.
Is the Keychain DB (SQLite) stolen in encrypted form? As I understand, the Keychain DB is stored on the file system, but the DB's key is held in the Secure Enclave.
I am surprised that this is NEW. I mean, like nobody ever created a stupid program asking the user for the system password and tried to collect sensitive data based on it?
OSX Ventura has several guards already against it:
- prevent execution of software not downloaded from app store and not from an identified developer (not digitally signed basically). You as a user have to explicitly go to your security settings and enable the app, and then reopen it.
- ask explicitly for permissions to give to an app (e.g., X is asking to access the Downloads folder, ...). Maybe in case of Keychain this is not done, which could be something to improve... but even then if the user wants, there will be a "click".
92 comments
[ 3.3 ms ] story [ 110 ms ] threadSo, what should Apple do in response to such malware? Make it impossible for user code to read the entire keychain, even when running as admin? Containerize macOS more, making it impossible for user programs to access files written by other programs, in the way things work on iOS? Ignore it because, at some point, security becomes the user’s responsibility?
If tools like these get popular, I can see them getting blamed whatever they do or don’t do.
if you have one thousand users of desktop computers distributed across geography and age groups, and you watch whatever behavior it is that you claim is "it" ... how many of the thousand users show the weakness or lack of care or lack of self-defense.. How many ? four? four hundred?
if four hundred users fall for some scammy website using a browser on the internet, you mean to say that every user must have bicycle training wheels and constant adult-supervision monitoring? Do you make money in some business-model that does that?
[0]https://support.apple.com/guide/security/protecting-against-...
Unfortunately, I can only provide my anecdotal experience, but it seems to be in stark contrast to your comment.
In other words, instead of a 2-step UX like this: (run as admin) + (let app do any admin type thing)
Your system should have multiple explicit 1-step UXs: (let app do admin thing X)
The later will presumably present a more clear explanation to the user of what they are doing.
Of course, no Real(tm) capability-based GUIs have ever been built to my knowledge, not even in academia, so this is an entirely theoretical argument and not a criticism of Apple.
On MacOS, applications by default don’t have the right to read your disk and show a list of files, they have the right to ask the OS to show a dialog that reads your disk shows a list of files, lets you pick one, and then grants that application the right to read that one file. Similarly, for saving files, the save dialog runs under OS control, and grants an application to write a single ‘file’ (which, on macOS, could be a directory containing multiple files)
Similarly, on iOS, apps can’t read photos, but can ask the OS to show a photo picker.
MacOS (¿still?) has system preferences that allow users to disable such checks, though, granting full file access to certain apps, for example, and also will ask users to grant apps the right to read entire file systems when they try to do so.
Yes you can still disable a lot of this stuff. But I wonder if this is a case where a hardware aspect could let Apple make that less necessary without degrading UI. In principle, with cryptographic signing for input peripherals keyboard/trackpad/mouse/etc, secure processing element routing through it, and the right low level protected kernel support and signed stack, it would be possible to have the OS be able to distinguish between "operator initiated" and "automated" access at a fairly granular level. It'd even be possible to pass that on from one Apple system (or others if it was a standard) to remote ones via SSH or the like. That in turn could enable the system to have different UX between the two classes. For example like a some other HNers I assume I currently grant Terminal full disk access right out of the box as one of my first setup steps just because it's a real irritation to not be able to navigate around and use it from the CLI as I expect without GUI stuff popping up. But instead a system could transparently make it so that when I typed in commands into the shell they'd actually be treated with different permissions than if an automated shell script did the exact same commands, and this could be the case everywhere with a high degree of security. Much more intelligent granting of capabilities would make the UX a lot less irksome and could help push a request for human attention and decision making from the default to the unusual, and that in turn would encourage leaving it on.
I think Apple does already do this to some extent actually? Like, in a native widget GUI app, if the user initiates the GUI open/save file finder they're able to navigate to places outside the sandbox? I might be misremembering. But at any rate extending that as a low level hardware backed feature could be an important step in capabilities usability. Security has to have its costs in line with perceived benefits, or users will just end up degrading it (classic "just write the password on a sticky note leave it on the monitor" issue). The human element isn't a bug it's a core requirement, so would really like to see more effort on that side of things as well.
I get why it doesn't (the problems it would cause for Uber and DraftKings immediately come to mind) but the more sketchy advertisers there are who want to track my location data, the more I want that data to be garbage.
This is a fantastic comment for someone (like me) hungry to learn about security concepts. Do you have any more pointers to useful info about security topics?
That being said, I used to be very interested in capability-based security because it promised solutions to so many security problems but nobody seemed to know about the ideas, and the people who had heard the term often had significant misunderstandings of what was possible with capabilities.
It's been about 20 years but I mostly had it right ;)
"No designation without authority"
This is a great place to start: https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
Warnings like this are useless when they bundle genuinely dodgy software along with software from legitimate companies I already trust and know. Those messages means nothing to me, and I ignore them, because they're warning me about something I already know "You're trying to run software you downloaded" — yeah, thanks.
> Make it impossible for user code to read the entire keychain
What I've always found kind of bonkers, is that MacOS allows any command to read the entire contents of your keychain (yes, with all your passwords). No auth, no checks, just full access via the `security` command.
> Containerize macOS more, making it impossible for user programs to access files written by other programs, in the way things work on iOS?
Maybe? I don't know if that's the right direction (it definitely isn't for me, and I'd jump ship), but perhaps that's the best thing for most people?
Since running unsigned apps is disabled by default, they are not bundled like this. One is prevented from running at all.
You can change the system to treat them as roughly equal parties (one still gets a warning while the other does not), but preventing this from being possible at all would be worth even more outrage.
If you want this kind of safety for someone who you can't trust to consider these kinds of risks, set their computer up so they can't change that setting and they don't have root access. That's just a second user account. Yes, they'll have to use the app store..... but that's the way it works everywhere.
But yes, I agree: they do not actually suggest any new restrictions, and I did not mean to imply that they did. I just meant to head off the obvious rebuttals, and make my stance clear: you cannot have "allow the knowledgeable to do X" and "prevent the un-knowledgeable from doing X" in the presence of social engineering at a technical level, and there is ample evidence that more popups and friction are not an effective solution. So a safe default and reasonably-ergonomic-but-not-accidentally-trigger-able ways around it seems roughly ideal IMO.
I think OSX hits that balance fairly well: block by default, right-click -> open to bypass individually (arguably accidental-able, but odd enough compared to double-click and there is still a clear warning displayed), or change settings to allow by default. It's both effective and friendly, and going further in either direction seems like it requires major sacrifices in the other. And when you do want those sacrifices, you can get them (non-admin account or disable it entirely).
No, that's not true. macOS has multiple keychain APIs with different capabilities.
https://developer.apple.com/documentation/technotes/tn3137-o...
Items within the traditional keychain can have ACLs applied to them. When you run `security dump -d`, it will only be able to dump items from a traditional keychain that are either set to allow access to all apps, or that have an ACL that grants access to `security`. Very few items should be set to "Allow All". In my login keychain, almost none are.
For all other items you will get a security prompt with "Always Allow", "Allow", and "Deny" which requires you to enter your password. You can also set items to require confirmation but not require the keychain's password.
If you add `security` to an item's ACL--say because you need access to that item from a script--then any app can of course access that item by calling `security`. My advice would be not to add `security` to any item's ACL.
AFAIK, `security` has no access to the iCloud Keychain where Safari stores its passwords. If you don't have iCloud Keychain enabled, I believe Safari stores its passwords in a traditional file-based keychain but those items should have ACLs on them.
https://support.apple.com/guide/security/keychain-data-prote...
https://support.apple.com/guide/security/icloud-keychain-sec...
ACLs shouldn't be overlooked though: manual keychain items use the default ACL configuration and require user confirmation, which means you need to authenticate N times to access N items.
Clarifying my own comment.
Safari stores its passwords in the data protection keychain. This is called "Local Items" in the Keychain Access app if iCloud Keychain is not enabled. If it is enabled, it's called "iCloud Keychain". Either way, `security` does not enumerate any items from the data protection keychain, only from the file-based keychains. And again, all the items in those keychains should have ACLs on them.
Could it be that the Terminal has full access then? I've never been asked for a password, or had a restriction of any kind put on me, when using the `security` command. Those prompts you speak of are for the "Keychain Access" GUI, no?
The security prompt to "Allow All", "Allow", or "Deny" when a process tries to access a keychain item's value is a GUI window, but it's not part of any app.
Suggesting an umbrella organization give the primary assurance of trustworthiness is similar to what SourceForge used to do, until their practices destroyed their reputation back in 2013, and also greatly damaged the reputations of legit developers who used their site. [https://en.wikipedia.org/wiki/SourceForge#Controversies]
[1]: "A Cautionary Tale from the Decline of SourceForge" [https://news.ycombinator.com/item?id=31110206]
[2]: "Why SourceForge Lost" [https://news.ycombinator.com/item?id=2739995]
[3]: https://hn.algolia.com/?q=sourceforge
Linux distributions package applications (including binary ones) for their users, why can't macOS or Windows do this? Run automatic safety checks on them before deploying updates to users. The Windows Store and Apple's App Store (on macOS) are kind of like that, but they only have applications that developers chose to put there. I don't see Linux distributions asking developers for permission to package their application (there are proprietary packages on Arch and NixOS), so I don't see why Apple couldn't do the same.
Certificates are a bureaucratic half-solution.
For unprotected directories like Library/Keychains, programs can just copy the encrypted database. Since the malware obtains the keychain password with a fake password prompt, it can decrypt the database.
GasBuddy ("GasBuddy Is a Privacy Nightmare")[0] is a case in point. Geolocating users and selling that to everyone. Harvesting users' driving habits then selling those to Allstate subsidiary Arity ("turning mobility and driver data into meaningful behavioral insights, leveraging telematics to make transportation smarter, safer, and more useful for everyone!"). (But there's an opt-out!)
So are fitness apps and trackers. Private equity loves acquiring them.
Permissions can be abused in ways that aren't made obvious to users. Obvious example: just because you disable "location access", doesn't mean the app can't (indirectly) geolocate you in a variety of sneaky ways.
Even if the app doesn't intentionally crash if you disable its location access: indirectly geolocating users indirectly from IP addresses or metadata on photos they upload. Device fingerprinting from motion sensors, so that you can track a unique user across networks and devices, and develop "behavioral insights". And on and on.
[0]: https://news.ycombinator.com/item?id=30636730
Your idea would defeat the purpose of signing , which is to trust the delivery. If a company was sharing their signing certificate, nobody would know it came from you, and it would take just one malicious person also using that certificate to get everyone’s apps pulled.
In Windows and Linux any application also can read any user's file. And in Chrome and Firefox, any extension can read browser history, capture key presses and so on. If you install Python packages, they can do anything to your computer, if you download a plugin for Gimp the same issue exists. On desktop security is broken since forever. OS developers (especially Linux developers) cannot innovate and use outdated security model from 80s where users are isolated from each other but today most computers have a single user and it makes little sense. Today you need to isolate program from a program, and prevent them from fingerprinting user's device (for example, in Linux any app can read MAC addresses, hardware serial numbers, list of nearby WiFi points and nobody cares about that).
Surely you mean any root application? Or is my understanding of the Linux security model completely incorrect?
> And in Chrome and Firefox, any extension can read browser history, capture key presses and so on
Also no, extensions have different privileges you must accept. There are lots of problems with that security model, but it doesn't any extension can do those things
Indeed, that security command was definitely a misnomer.
However these days it's not as easy, you get a pop-up for every app that wants to access the keychain.
The bigger problem though is that Apple resorts to pop-ups way too much. Installing a new Mac with my work stuff I get 30 of them. This causes fatigue and totally fails to solve the problem.
In fact it does the exact same thing that Apple blamed Vista for in their Mac vs PC ad. In fact macOS is worse now than Vista ever was. https://youtu.be/VuqZ8AqmLPY
While there are some drawbacks in that you wouldn't be able share files/clipboard as easily, there are more ways to ensure more complete isolation.
I could forsee containerization being much more prone to social engineering of a novice non-technical user (i.e. stealing the clipboard, accidentally giving file access, etc.)
HN: "Apple products are so insecure, you can run anything on them!"
Also HN: "Apple products are too locked down. I can't run anything on them!"
tbh I think they're already doing the best option:
>ignore the OS warning that the code isn’t signed
OSX ships with "run unsigned apps" completely disabled by default, so normally that option won't even be presented.
You can of course socially engineer someone to run it anyway, by changing that system setting... but you'll never stop social engineering entirely. It's always a question of what degree you'll go to, not if it's possible or not.
I’m behind the upgrade curve, so I had to look this up to see if it’s changed but it hasn’t. The default still allows running unsigned apps without any configuration change. You just have to know how to do it, which is a pretty good sensible default. If you don’t know how, it’s a trivial search away.
> so normally that option won't even be presented.
Which is why it’s a good sensible default. Most users who don’t know how to work around it won’t bother, and they’ll benefit from it. The rest of us who do know how will take a brief pause to consider the risk before disregarding the warning.
The people who will just blanket turn off the protection are either very confident in their own risk assessment capabilities because they should be, or because they wouldn’t be protected by any mechanism whatsoever.
Now I’m pissed, because having endured the ordeal that was exporting the keychain, when migrating off of it to a proper password manager, I would have sworn it was already impossible to do so in any practical manner. Now I find out malware can do it? They’ve already made it nearly impossible to do legitimately!
Decades ago, when software warned users about potential dangers, they would either accept the risk or avoid it. Nowadays, software has been so infantilized that people expect a guaranteed positive outcome, even when ignoring warnings, while "free thinkers" online argue that every warning is a false positive.
Philosophically, I don't think we should cater to this mindset. If someone decides to fall prey to an evident scam or install malware on a critical system despite clear warnings, that's their prerogative. This principle holds true beyond just software.
I genuinely dislike the trend of dumbing down and infantilizing everything in the world. This includes simplifying education to stifle exceptional kids, prioritizing clickbait over nuanced news, the prevalence of exaggerated content on social media just because it's easier to consume, watered-down movies and music designed to exploit mass audiences, political populism obscuring real problems, a flood of shallow literature, and suppressing innovation in technology due to it being inherently risky (like the slow pace of space exploration-related advancements compared to the 1960s). Regrettably, software has not been spared from the "dumbing down" to accommodate the lowest common denominator. This philosophy leads to decadence, disempowerment, and a loss of richness in whatever field it infiltrates. In my view, it is regressive.
What has happened to critical thinking in recent decades? It used to be sufficient for us to navigate life despite a little danger, challenge, and risk. "Danger" should not be a shunned taboo concept, it is an inherent part of life.
In short, use critical thinking, don't listen to forums that say WhatsAppCracked100PercentSafe.apk/.dmg/.exe is not a security risk. Or take accountability for your actions if you still install it — it is your prerogative. But it shouldn't be anyone else's responsibility to make sure you don't harm yourself. Same as in other areas of life.
Given the above and the default macOS security configuration, you really have to work your way to get this malware running.
Also, don’t irritate any nation states.
Also, while SIP wouldn't have helped in this particular situation, consider if it's really necessary to disable it. Living with SIP on is occasionally cumbersome, but I don't trust myself enough to run without it on, even as someone who's been a technically-minded computer user for coming up on a quarter of a century and a dev for over half of that.
If disabling SIP is ever truly necessary for me I think I'd do it in a VM. Especially on M-series machines virtualization of macOS has gotten quite good.
If Linux were to become my daily driver OS I'd probably enforce a greater degree of separation between machines, with e.g. one Linux box exclusively for work things, another for finance, etc which is pretty easy to do with cheap old laptops. This limits the potential blast radius and reduces chances of getting hit in the first place, with e.g. how there's no good reason to run random untrusted binaries on the finance laptop.
There are two categories of Mac malware: Ones where you have to enter your admin password into something that should have already raised several red flags by the time you see the prompt, or zero-days that are so stratospherically expensive that if you are an individual who would be targeted by one, malware is only one part of your overall threat model.
No reason to make your life harder unless you’re doing it for your own enjoyment.
macOS as many times more secure than the Linux desktop. The only reason Linux is not a malwarefest is because the market share is so small that it is not that interesting.
[1] https://0pointer.net/blog/brave-new-trusted-boot-world.html
If any government has backdoors in macOS outside open source software in macOS, it is probably very limited (the US government if any, but Apple seems to resist most attempts at weakening security).
[1] https://arstechnica.com/information-technology/2010/12/fbi-a...
That’s much harder with open source software, not due to technical reasons, but because there is a good chance that eventually it will be discovered by some developer or security researcher. That will cause distrust of the government, and people going to defensive mode, making it much harder for governments to routinely hack into devices.
So, for example, the discovery of the flaw in the Debian random number generator had a huge impact. People who design security systems really pay attention to PRNGs nowadays (to the point that it seems weak PRNGs are no longer a significant concern in the mainstream desktop operating systems, though the issue obviously remains in IoT, virtual machines, HSMs etc).
Hiding the code for malware is common sense. That’s also why governments severely punish leaks these days.
But when thinking about state actors they almost have unlimited money/resources thus even if adding a backdoor is a bit harder on open source having unlimited money/resources makes it irrelevant.
Where “unlimited” = to the size of the open source organisation that maintains a bit of software.
It's easy to detect backdoors in closed source applications.
People should definitely be using open source for as much as possible, because I want to live in a world that makes it as easy as possible for beginners to understand how their underlying software systems are working. The whole "backdoor" FUD just seems lazy though.
For the less paranoid, Mac malware is still incredibly rare if you only download and execute files from trusted sources (preferably the Mac App Store)
And keep all software/OS up to date.
PS - slightly unrelated but I’ve always been so confused as to why Mac comes with the firewall disabled by default.
This is something that hasn't been fixed despite years of complaints from the security community for exactly this reason.
It's especially annoying as touchid provides a standard authentication mechanism on macOS, that doesn't provide reusable credentials to anything.
Unfortunately these are design weaknesses, so any "software stack" would just be a bandaid.
Already on Mac there are plenty of things you simply cannot do as root/super user/administrator, no matter how many passwords you have or enter. Having code execution in a user account doesn't provide full access to all the user's files and data, etc.
I'm curious as to exactly what this malware is doing - is it bypassing SIP and/or entitlement checks, or is it essentially the same as downloading a bash script and running it and giving it your admin password.
I wonder how many people got infected in the wild. Also, it's any moment that Telegram removes the channel that is used for C&C, making the malware virtually ineffective.
and/or ms_office_2022_free_activated.dmg
and apple too because xprotect
ohohoh and cisco too they have cisco endpoint protect and clamaw and umbrella dns that blocks malware!!!
btw who did 9/11?
OSX Ventura has several guards already against it:
- prevent execution of software not downloaded from app store and not from an identified developer (not digitally signed basically). You as a user have to explicitly go to your security settings and enable the app, and then reopen it.
- ask explicitly for permissions to give to an app (e.g., X is asking to access the Downloads folder, ...). Maybe in case of Keychain this is not done, which could be something to improve... but even then if the user wants, there will be a "click".
That seems like an insignificant technical detail to mention, or am I missing something?
I cannot be the only one basing my decision to run random blob from internet on virustotal output?