[HN Gopher] New macOS malware steals info, including a user's en...
___________________________________________________________________
New macOS malware steals info, including a user's entire Keychain
database
Author : WallyFunk
Score : 151 points
Date : 2023-04-15 15:16 UTC (7 hours ago)
(HTM) web link (www.malwarebytes.com)
(TXT) w3m dump (www.malwarebytes.com)
| phendrenad2 wrote:
| 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.
| olliej wrote:
| 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.
| can16358p wrote:
| 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.
| rejectfinite wrote:
| name it free_fortnite_bux_and_robux.dmg for home users
|
| and/or ms_office_2022_free_activated.dmg
| snehk wrote:
| 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?
| the_third_wave wrote:
| 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.
| danieldk wrote:
| 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.
|
| [1] https://0pointer.net/blog/brave-new-trusted-boot-
| world.html
| aborsy wrote:
| On the other hand, MacOS is closed source, so governments
| and Apple most likely have backdoors. Spyware counts too,
| when discussing malware.
| px43 wrote:
| 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.
| danieldk wrote:
| 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).
|
| [1] https://arstechnica.com/information-
| technology/2010/12/fbi-a...
| aborsy wrote:
| 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.
| tgv wrote:
| 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.
| isthiseasymode wrote:
| I know I'll ruffle some feathers on HN, but macOs is fine and
| probably the best OS for Mac (especially m1) hardware.
|
| No reason to make your life harder unless you're doing it for
| your own enjoyment.
| cj wrote:
| Enable Lockdown Mode if you're truly paranoid (will degrade UX
| since lockdown disables certain OS features to reduce attack
| surface).
|
| 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.
| meindnoch wrote:
| Don't enter your password into random dialogs?
| olliej wrote:
| 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.
| atty wrote:
| 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.
| GTP wrote:
| Being careful about what you're doing is the best antimalware,
| regardless of which OS you're using.
| mwint wrote:
| On a Mac, just keep up with software updates and think really
| hard before overriding security warnings.
|
| Also, don't irritate any nation states.
| mortenjorck wrote:
| 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.
| kitsunesoba wrote:
| > 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.
| olliej wrote:
| 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.
| kitsunesoba wrote:
| 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.
| josephcsible wrote:
| Do you trust yourself to use Linux, even though it has no
| equivalent to SIP?
| kitsunesoba wrote:
| 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.
| rickette wrote:
| 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.
| ikekkdcjkfke wrote:
| If you really want to go the distance, Remote Browser Isolation
| sunshinerag wrote:
| Looks like an ad for malwarebytes. Genuine question: how do we
| know they are NOT in the business of writing the malware
| themselves
| rejectfinite wrote:
| yes and kaspersky and norton and sentinelone and crowdstrike
| and macafee and windows itself becasue they make windows
| defender yes gottem
|
| 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?
| provenance wrote:
| 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.
| Someone wrote:
| 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.
| ryanjshaw wrote:
| 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.
| emodendroket wrote:
| iOS does pester me all the time about whether I want to allow
| this or that app to use my location.
| letitbeirie wrote:
| 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.
| jeromegv wrote:
| There's "less precise" which isn't quite the same but
| also helps to not target all the way on top of your home
| and is more city wide accurate.
| callalex wrote:
| But that still informs the app of your choice, and many
| will disable themselves until you grant the precise
| location permission.
| Someone wrote:
| 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 wrote:
| > _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.
| narrator wrote:
| Newer android prompts before apps are allowed to do things
| like access location and files.
| provenance wrote:
| > "combine designation with authority"
|
| 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?
| mistrial9 wrote:
| 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 wrote:
| Because it keeps being validated time and time again, from
| endless amount of browser bars to cases like this one.
| mistrial9 wrote:
| 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 wrote:
| Lazy logic. What if it's 4 million users? You're just
| assuming the answer you want.
| pjmlp wrote:
| Security businesses are the ones making money out of
| recovering exploited users when they cry for help.
| owaislone wrote:
| 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.
| somethoughts wrote:
| 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.)
| pakyr wrote:
| 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-...
| mleo wrote:
| The amount of CPU resources wasted on windows defender is
| immoral.
| phendrenad2 wrote:
| Can you tell us more? What is the amount?
| croon wrote:
| This has not been my experience at all, can you elaborate?
| rdez6173 wrote:
| 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 wrote:
| Then you are in luck. Also rise up and stop with that
| anecdotal circle jerk.
| rejectfinite wrote:
| Is it? You don't want Windows to come with good antivirus?
| nazgulsenpai wrote:
| 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.
| trollied wrote:
| 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.
| reaperducer wrote:
| _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!"
| xp84 wrote:
| > 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!
| Groxx wrote:
| > _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.
| clnq wrote:
| 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.
| ghusto wrote:
| > 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?
| tempaccount420 wrote:
| 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.
| [deleted]
| codedokode wrote:
| > 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).
| Groxx wrote:
| > _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 wrote:
| Where does GP suggest any new restrictions at all?
| js2 wrote:
| > 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.
|
| 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...
| dvzk wrote:
| 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.
| mk89 wrote:
| 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".
| hjuutilainen wrote:
| > 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.
| hot_gril wrote:
| Kid who wants to run games and stuff will open it. Plenty of
| benevolent things are stuck behind barriers.
| [deleted]
___________________________________________________________________
(page generated 2023-04-15 23:01 UTC)