New macOS malware steals info, including a user's entire Keychain database
malwarebytes.com
malwarebytes.com
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.
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?
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
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...
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.
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.
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.
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).
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
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]
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.
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.
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.
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.
[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.
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
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.
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.
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.
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.)
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!
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!"
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?
Given the above and the default macOS security configuration, you really have to work your way to get this malware running.
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 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
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.
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.
Unfortunately these are design weaknesses, so any "software stack" would just be a bandaid.
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.
No reason to make your life harder unless you’re doing it for your own enjoyment.
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.
I cannot be the only one basing my decision to run random blob from internet on virustotal output?
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.