5 ms·

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 signe

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.

mistrial9 4y ago
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?
- pjmlp 4y ago
  Because it keeps being validated time and time again, from endless amount of browser bars to cases like this one.
  - mistrial9 4y ago
    try thinking for a minute 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?
    - phendrenad2 4y ago
      Lazy logic. What if it's 4 million users? You're just assuming the answer you want.
    - pjmlp 4y ago
      Security businesses are the ones making money out of recovering exploited users when they cry for help.
calgarymicro 4y ago
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. [0]https://support.apple.com/guide/security/protecting-against-malware-sec469d47bd8/web https://support.apple.com/guide/security/protecting-against-...
- mleo 4y ago
  The amount of CPU resources wasted on windows defender is immoral.
  - nazgulsenpai 4y ago
    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.
  - phendrenad2 4y ago
    Can you tell us more? What is the amount?
  - croon 4y ago
    This has not been my experience at all, can you elaborate?
  - rdez6173 4y ago
    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.
    - shzhdbi09gv8ioi 4y ago
      Then you are in luck. Also rise up and stop with that anecdotal circle jerk.
trollied 4y ago
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.
ryanjshaw 4y ago
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.
- Someone 4y ago
  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.
  - xoa 4y ago
    >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.
ghusto 4y ago
> 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?
- Groxx 4y ago
  >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.
  - Kinrany 4y ago
    Where does GP suggest any new restrictions at all?
    - Groxx 4y ago
      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).
somethoughts 4y ago
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.)
reaperducer 4y ago
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!"
Groxx 4y ago
>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.
- eyelidlessness 4y ago
  > 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.
owaislone 4y ago
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.
xp84 4y ago
> 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!
clnq 4y ago
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.

mistrial9 4y ago

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?

pjmlp 4y ago
Because it keeps being validated time and time again, from endless amount of browser bars to cases like this one.
- mistrial9 4y ago
  try thinking for a minute 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?
  - phendrenad2 4y ago
    Lazy logic. What if it's 4 million users? You're just assuming the answer you want.
  - pjmlp 4y ago
    Security businesses are the ones making money out of recovering exploited users when they cry for help.

calgarymicro 4y ago

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. [0]https://support.apple.com/guide/security/protecting-against-malware-sec469d47bd8/web https://support.apple.com/guide/security/protecting-against-...

mleo 4y ago
The amount of CPU resources wasted on windows defender is immoral.
- nazgulsenpai 4y ago
  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.
- phendrenad2 4y ago
  Can you tell us more? What is the amount?
- croon 4y ago
  This has not been my experience at all, can you elaborate?
- rdez6173 4y ago
  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.
  - shzhdbi09gv8ioi 4y ago
    Then you are in luck. Also rise up and stop with that anecdotal circle jerk.

trollied 4y ago

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.

ryanjshaw 4y ago

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.

Someone 4y ago
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.
- xoa 4y ago
  >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.

ghusto 4y ago

> 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?

Groxx 4y ago
>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.
- Kinrany 4y ago
  Where does GP suggest any new restrictions at all?
  - Groxx 4y ago
    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).

somethoughts 4y ago

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.)

reaperducer 4y ago

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!"

Groxx 4y ago

>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.

eyelidlessness 4y ago
> 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.

owaislone 4y ago

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.

xp84 4y ago

> 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!

clnq 4y ago

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.