Proton.B: What this Mac malware does | Hacker News Reader

Proton.B: What this Mac malware does

cybereason.com

170 pointsopen-source-ux87 comments

"Dialog boxes asking for passwords are a very popular social engineering tactic designed to trick users into giving attackers their passwords"

Apple is extremely guilty of normalizing the frequent entry of passwords. I recently reinstalled a Mac and an iPad, and for each device I must've entered my Apple ID password seven or eight times. in the normal course of getting things done I then enter either this, or my local login password, many times a week.

When your password is twenty characters of line noise or an extended passphrase this is thoroughly irksome, especially on virtual keyboards like the iPad. It is no surprise to me that less security conscious folks, faced with this onslaught of excessive credential demand, choose shorter i.e. easily cracked passwords; and no surprise that everyone becomes less suspicious of the sham password dialog.

So when reading of yet another photographic burglary from a cracked iCloud account, we should always lay part of the blame at Apple's feet, for systematically normalizing the frequent entry of credentials.

That is not the end of Apple's social engineering enablement shame. Another glaring blunder is in Apple Mail, where the "To:" field is shown with your real name, even when the sender did not include this. The humans respond positively to the use of their given name, so this heightens the verisimilitude of scam messages.

Yup. My Apple password is one of the very few remaining ones that isn't a random string generated by 1Password because Apple makes me enter it all the time. :(

"For your protection".

I agree, the number of times per week that I somehow end up entering my Apple ID password is egregious. Couple that with the abysmal iCloud/Apple ID/iPhone number conflicts that inevitably show up when you have more than one device. I've spent more hours than I care to remember working on my parents' devices fixing glitchy synchs.

FWIW I use 1pw's diceware generator for any password I might have to enter on iOS, Roku, PS4, etc.

Much easier to remember when looking from screen to screen and fewer keyboard shifts.

You people are doing something seriously wrong. About the only time I need to enter iCloud credentials is when I reboot my system, which is maybe once a month, or buy something. Complaining about credential entry on a new device install in this context is also kind of irrelevant, this malware doesn't strike during a new OS update.

I'm not sure why you've got downvoted, but I can confirm, that I'm using Macbook, iPhone, iPad and I very rarely have to enter iCloud password. I don't even remember last time I did it. I'm not reinstalling stuff or whatever, usually I'm working with programs I'm using and only password I'm constantly typing is password from locked computer or pincode for phone (and even those could be eliminated with modern touch buttons, I think).

Regarding the downvotes; I suspect it was the holier-than-thou tone delivering a blinkered refusal to accept someone else's reported experience, all prefaced by a cheap sneer.

I generally find that this forum has a higher than usual tolerance for unconventional perspectives, but takes a very dim view of poor manners. Unlike other places that seem to reward and even celebrate bad behaviour and low standards of discussion. This is a major reason I contribute here and basically nowhere else.

It's the anti Apple sentiment on HN. Nothing Apple is good anymore. But yeah, I can't remember either the last time I had to enter the iCloud password.

I've had almost all of my Apple devices at some time or another just randomly pop up a "please sign into your Apple ID" dialog in the middle of some other work. I think it's probably related to update checking? But it's definitely something Apple is responsible forZ

The standard macOS password prompt surely needs to change. It's become too familiar and I'm sure I've filled it in hastily before without wondering why or what for. It needs to be implemented in a way that is impossible for nefarious apps to replicate.

Yes, should show the users login photo at the very least...

And maybe dim the background, as wel as giving information about the creator of the application and if its codesigned. oh wait, that was too obtrusive and annoying

Not sure if you're being sarcastic about how users feel or about that kind of configuration for UAC, but personally it's one of the many things I dislike when I'm on a Windows computer.

For power users it's annoying and disruptive. For users that might benefit the most from it they quickly learn to press ok always whenever they are prompted for something, no matter what it's asking.

In my opinion, an ideal OS would have absolutly no confirmation dialogs what so ever, but instead it would have unlimited systemwide undo for any action. Look at Gmail vs Microsoft 360 webmail. One is a pleasure to use, the other a pain in the but. Some of that difference comes from dialogs and extra steps in 360 where GMail instead lets you undo.

Add powerful application isolation like in iOS, but make it as simple for the user to pass data between programs as it conceptually is to pipe text from one command to another in Unix, except that you shouldn't have to set up the pipeline first, instead you open a program work on something, pass it to another program work on it and so on. Each program also has an isolated location in the fs for persisting user data but since the only way for one program to access data from another program by the user explicitly sending it over, no application can access something it shouldn't have without the users interaction. So like iOS in that respect also. Of course the user can still be socially engineered into giving some data to a program that shouldn't have it but I don't think it could possibly be worse than what we have today.

There are a bunch of other problems and challenges also that I've not gotten around to consider, but I feel that an operating system like the one I described, if open source under an acceptable license (ISC, BSD, MIT or similar preferably) existed, I'd gladly throw away the portability advantages of POSIX in change for it.

> For power users it's annoying and disruptive

Let me stop you right there. As a sysadmin, UAC is both effective as it is necessary. I absolutely don't want any application a user can launch with a mere YES/NO prompt but proper secondary credentials, interactively or by some nefarious app spawning other processes, to have the ability to gain an administrative level of access over the local machine. Unless it's absolutely necessary (which in most cases, it's not!).

"Power Users" are, in my experience, an annoyance at the corporate level and especially at home when they bomb their system so badly that it requires reinstalling the OS every few months.

However your other points raise a good standard and I'd like to specifically mention one I really want to see in Desktop OS's. That app sandboxing for every "feature" accessed should be a whitelisted (by asking for permission) endeavor. It should request access to the file system (only for those directories in its specific needs), calendar, contacts, network access, looking into other apps (themselves or their access to the file system), network access, etc.

I totally agree with you, except that asking users multiple times for their password will increase password fatigue. It may be argued that we could prefer the users to mindlessly click on Yes when a popup arises, instead of mindlessly inputting their password. Another option can be timers on the Yes button (like Firefox does), it blocks a few user interface hijacking attacks and gives the user an opportunity to think before they click.

I find it funny that one of my complaints with my current work environment is that the GP UAC setting for power users is just slightly too low. As a Power User (subclass Developer), I know its my job to not do something stupid (with great power, comes great responsibility, after all) and I happily lean on UAC to do its job and help catch me from some of my own stupidity.

I like the Secure Desktop and its forced context switch and I've worked to train myself that A) as a Power User, if I'm pushed to the Secure Desktop its "Serious Business" and pay attention, and equally importantly B) as a Developer, if my app is pushing to the Secure Desktop and it's not for something critical to system security, I wrote something wrong (or one of the libraries I'm depending upon did), because my non-Power Users should probably never see Secure Desktop prompts in almost all of the apps I write.

I don't particularly want and am not sure I need to input secondary security credentials every time I see the Secure Desktop, but I'm happy with the default options in Windows these days and as a Power User welcome it.

(As for feature whitelisting, I think this is an underappreciated part of the Universal Windows Platform [UWP] still. I'm hoping that as more Enterprises start to see Windows 10 S they will pick up on the platform benefits to the UWP and start to mandate Store/UWP-only development. I think the Appx app model of UWP is a game changer for a lot of Enterprise security and that if some Enterprises weren't clinging so hard to "oldest LTS Windows Microsoft supports" deployments, aka Windows 7 is the current Windows XP, there would be a giant demand for UWP-friendly Enterprise developers that I've not yet started to see.)

There is no undo when you're giving access to information.

This malware reads your passwords and sends them to a remote server. How would you block it?

Because since the only way that a program can have access to information is by explicitly handing that info to the program from another program the only place you enter a password is on your login screen.

Login password perhaps (at least plain text version of it), but account info (including cookies) in a browser for example would be accessible, as well as anything on disk.

>anything on disk

Not if the file system is isolated per app as I said.

On Windows NT you had to press Ctrl-Alt-Delete at the login prompt because that was a key combination that no other application could intercept. Nowadays you work as a non-privileged user but then you have to enter your admin password in various dialog boxes with no way of knowing if its legit (sometimes ubuntu shows you an ugly-looking (i.e. wrong styled) gtk input dialog during updates. But only sometimes. Thats very confusing.).

On the other hand, each desktop application should be able to request root access. And if you trust these applications (e.g. handbrake on macos) you wouldn't bother to press Ctrl-Alt-Delete or do whatever else it takes.

Any good solution for that?

"Full" UAC, also known as actual UAC, moves you to a secure desktop without any other windows (which also prevents a few forms of keylogging). You can't alt-tab into any of your previous applications, either, until the prompt has been dealt with. Faking this requires kernel-mode permissions.

But then again, users will STILL enter the password, giving the app root permission anyway. The warning here would be that the "fake" Handbrake would not have been signed, and blocked by SmartScreen. (They could get a signing cert, and use that, and aware users would have to know it differs...)

I still think the safest way is Windows XP style. Applications do not get root. You cannot give them root. Things that require an administrative password have to be done under the administrative account.

That's what I always wondered — why it's hard to fake UAC? Surely I can create a full-screen application which won't give away focus with alt-tab (that's very frequent behaviour with bad games).

One software I was/am still working on has an onscreen display(clear always top window ) so I can draw icons and text over a game, it's a pain to alt-tab out of(due to me setting it to constantly check to see if it's ontop, and if not, to set it).

So I would say that it's certainly possible, although I haven't tried specifically to do that to emulate UAC.

Edit: Infact I had a bug at one stage where if I closed the main window, the invisible window would remain running, with no entry in the start bar.

Now I'm becoming a little more concerned, as I could also listen for hotkeys, (such as Ctrl alt delete) and display my own 'secure login' page. Shit

Listening for these hotkeys is kind of pointless. The whole idea of pressing Ctrl + Alt + Del is that, while you can detect the keys being pressed, you cannot prevent Windows to display its interface on top of yours. See https://en.wikipedia.org/wiki/Secure_attention_key That's actually a good mechanism that should be brought back to all modern OS. I wish Android had something similar (well, available physical input keys are limited, but you get the idea)

I would like to hope so, I haven't tried intercepting something like that(I just listen for certain keys), I do wonder if someone more experienced than me could listen for Ctrl and alt, then intercept the delivery, and display their own. (I would 'assume' the system gets first dibs on any keypress, but what if you listened for Ctrl and alt then used a sendkey to upkey the Ctrl and alt, and detect a del key press and then display a fake).

(Sorry, can't test, as I don't have a Windows machine ready)

AFAIK, whenever you get a dialog that asks for your admin password, hit Control-Alt-Delete. If the dialog is a real one, focus stays with that window. If it is fake, a real one pops up on top of the fake one.

But then everyone ends up using the admin account for everything and all applications run effectively as root.

What I would love to see is a reason. Any program that requests elevated privileges should have to state to me why it wants those privileges. It's really frustrating to get this dialog pop up and have no idea what it's doing.

Many programs actually do, to a varying degree. Some programs are very vague but others can be specific. In the article, the virus even explains it: to install additional codecs. It might have even tricked me into thinking that it might need those (maybe they are integrated into quicktime and thus needs those privliages).

Almost any program that does something more advanced stuff then emails needs a helped application which often requires a root password. This is unfortunately true and apple is not very interested in fixing it (because their AppStore is safe and you ought to only use the AppStore because it will be sufficient for all your needs -- at least that's what the geniuses at Apple told me, which is actually good advice for most people but from time to time they need to enter the root/admin password and you can't really educate "normal users" when to enter it and when not to).

I think that's what TouchID is supposed to solve.

In hindsight I have to admit that Ctrl-Alt-Delete of Windows is a good idea. I propose a variant of this:

Introduce some scary red extra button with a key or locker symbol on it which can't be intercepted by applications or by root applications. When the OS needs authorisation, the user is prompted to hit that button, then a truly modal authentication prompt appears which is only dismissed by a second hit of that button or turning off the system.

This system could use different ways of authentication than by passwords.

Additionally users should be trained in only using this way of authentication and no others. The OS offers a secure API to invoke authentication, so that browsers also can use this for web apps. The prompt will look different and display additional information like «Application X wants to do Z», etc.

Edit: some more thoughts and clarification.

Maybe not a good idea, but I was thinking it could be cool if they turned on some lock LED in the bezel.

I've used handbrake some time ago but not recently, and hadn't heard about this. Summmary of the situation from the handbrake website:

HandBrake-1.0.7.dmg was replaced by another unknown malicious file that DOES NOT match the SHA1 / SHA256 hashes on our website or on our Github Wiki which mirrors these: https://github.com/HandBrake/HandBrake/wiki/Checksums

The Affected Download mirror (download.handbrake.fr) has been shutdown for investigation.

The Primary Download Mirror and website were unaffected.

Downloads via the applications built-in updater with 1.0 and later are unaffected. These are verified by a DSA Signature and will not install if they don't pass.

Downloads via the applications built-in updater with 0.10.5 and earlier did not have verification so you should check your system with these older releases

It's a shame that it isnt easier to check for the correct hash on downloaded software. I know it's a one liner in the terminal, but that scares prople.

In KDE / Dolphin you can right click on a file, select 'properties' and then there is a tab for different checksums.

We need a right click > verify, then user pastes in the hash. It could also be added to the browser.

A hash property on the <a> tag would be spiffy

Apparently there is, sorta: https://news.ycombinator.com/item?id=14335840

Browsers could show a checksum when hovering on a downloaded file.

This is a brilliant idea! Does Firefox accept feature proposals if they're fleshed out? My friend is an aspiring UX designer looking to build a portfolio, and I can write crude sample code.

Not so sure that's a good idea. This would prevent users to programmatically compare hashes, and it would be hard to display one next to the other to facilitate comparison. Keep in mind that it is relatively easy to create a file that matches the first and/or last N chars of a hash. And who checks the center of the hash? No, we have to have the browser compare the full hash and give a simple green light to the user. I don't have a proposition in terms of UX but it should be studied (should have been 15 years ago actually)

I was thinking the same thing, actually. I made a UX mockup this morning that I feel good about and was able to explain to my parents over brunch. I'll see if my friend wants to work on it.

This is a HTML feature now, it's called sub-resource integrity. So you just put the hash inside a new element called "integrity" when you refer to external resources. Like so: <a href="..." integrity="...">

How does the browser know what hash algo to use?

https://hacks.mozilla.org/2015/09/subresource-integrity-in-f...

"As you may have noticed, the integrity attribute does not just include the hash value. It also contains the digest name. The syntax for the integrity attribute allows multiple tokens of this name-value format. This allows site owners to specify hashes of different strengths as well as the values of multiple scripts that may be behind a URL. This is useful for browser sniffing or content negotiation."

Correcting myself: looks like the SRI spec hasn't included the <a> element in the list of supported elements, though it has a mention that it might be supported in a future version :(

I'm intrigued and curious about why they download your 1Password databases…

I wonder if that's speculative - or if offline bruteforcing them works often enough for it to be worthwhile for the malware authors?

They're betting on a future weakness being discovered. Sure, it costs them some storage space to sit on these databases in the short run, but if they do get cracked, they hit the absolute motherlode.

They have all your saved passwords from your web browser, too, and your mac user account's password. I'd guess there's a reasonable amount of people who re-use at least one of those as their 1password master password.

Mobile OS security models are bound to land on the desktop soon-ish. What does any random App have to do with anything in ~/Library that is not its own Application Support or .plist preferences?

To be honest I don't mind if all Apps are sandboxed with the exception of a couple "user super-user"; I don't really care if my machine's root account is secure if all my horses sitting in $HOME are let loose on the net.

This Handbrake outbreak could have been easily avoided. For instance, Handbrake could create a separate server on say, Amazon EC2 and have it download the file from their website every 30min or so, and check the checksum. If it's not right, then it flips a kill switch on the website.

Doesn't fix the root cause, but could have caught it much sooner.

Does anyone actually do that? And what if you have a million files? And what happens within that 30 mins? I guess you could download and check your million files once ever 30 seconds...

Well, you would just check the final download dmg/iso file, and only do it for the first n-versions or so (since those will be the most popular.) The other ones can be checked too, but at a much lower frequency.

Or you know, just sign the application bundle. macOS has bundle signing for a reason. To make it even better, enable sandboxing for the application as well.

So everyone's supposed to maintain heartbeat servers for all their downloadable files now?

I have been using homebrew to install handbrake. What's nice is that homebrew checks SHA256 before installing.

  $ brew cask install handbrake
  ==> Satisfying dependencies
  complete
  ==> Downloading 
  https://download.handbrake.fr/handbrake/releases/1.0.7/HandBrake-1.0.7.dmg
  Already downloaded: 
  /Users/wolf/Library/Caches/Homebrew/Cask/handbrake--1.0.7.dmg
  ==> Verifying checksum for Cask handbrake
  ==> Installing Cask handbrake
  ==> Moving App 'HandBrake.app' to '/Applications/HandBrake.app'.
  handbrake was successfully installed!

Homebrew updated their hash to the infected one (differing from the Handbrake download page!), so people who installed using Homebrew got infected too. Do NOT trust homebrew.

https://news.ycombinator.com/item?id=14282116

Homebrew Cask distributed the infected Handbrake:

https://github.com/caskroom/homebrew-cask/commit/461af7672fa...

Note that hash 013623e5e50[...] is the infected Handbrake. Even worse, they changed the correct SHA-256 hash to the hash of the malwared Handbrake.

Homebrew added new policy https://github.com/caskroom/homebrew-cask/pull/33538/files

> When updating the `sha256` stanza of an existing Cask, the `version` also has to have changed. Otherwise, the new checksum has to be confirmed by the developer.

>The malware obtains the time and date by creating a new environment variable called $hcresult that contains what’s being returned by sending an HTTP request to the Google hosted link by executing this command:

>curl -sL https://script.google.com/macros/s/AKfycbyd5AcbAnWi2Yn0xhFRb...

What the hell, Google? Your domain name is one of the most trusted on the internet and yet you're hosting random user submitted scripts on there? What happened to googleusercontent.com?

Looks like its getting the current time from the json response. How dare Google distribute the current time?

The parent comment isn't talking about the payload being returned, it's about what domain Google is hosting user content on.

The response from script.google.com is a 302 redirect to script.googleusercontent.com. IOW, google.com itself does not serve that user content.

But why does Google redirect that? Why not just return an error?

It's not like users will accidentally type in script.google.com and get mad if it fails. Those script URLs are being used only by app developers, who will test their apps and fix script source URLs that are broken. Calling a googleusercontent script at google.com should return a 4xx status code telling them to use the googleusercontent domain.

Google.com is a trusted domain. I don't think it should be 302'ing to untrusted domains for arbitrary URLs.

>Google.com is a trusted domain. I don't think it should be 302'ing to untrusted domains for arbitrary URLs.

I think you should read this again and then take a moment to think about the services people primarily visit google.com for.

Also, what exactly are "trusted domains"? Why do they matter to users clicking links?

On a website there's no way for an user to verify where a link is going to take them without actually clicking the link. The tooltip for example tends to be relatively easy to spoof.

The point is that it's an arbitrary user submitted script. In this case it was just the time, but it could have easily been a botnet command and control message or some other malicious content.

It's standard security practice to serve user submitted content on a separate domain, so I'm a little surprised that Google isn't following it.

>It's standard security practice to serve user submitted content on a separate domain, so I'm a little surprised that Google isn't following it.

But it is being served under googleusercontent.com?

Ive got handbrake saved in my users application folder

So i ran the following in terminal

COMMAND : `cd /Applications shasum -a 1 HandBrake-* && shasum -a 256 HandBrake-`

and got this response which seems to be blank.. any ideas wether this is saying that i have an infected file or if ive just run the initial terminal command wrong ?

RESPONSE : `shasum: HandBrake-: Sams-MacBook-Pro:Applications Sam$ `

You run it against the DMG not the app.

> Note: The domains in red were not registered at the time of my research, although they were registered last night by an unknown entity. They seem to be back up domains in case one of the first two stops working.

Or they could be domains for checking if you're in a sandbox like WanaCrypt. Why wouldn't you just use 20 well known domains otherwise?

Why were they going after 1password filevaults? I assume 1password is like keypass, where all your passwords are in an encrypted file? How could they decrypt all those files? Or do they assume people use weak passwords?

According to the article this malware also does keylogging. So, presumably, they'll have the vault password as well.

Derp

Is there a good virus scanner for OSX?

Avast, ClamXav, Antidote, mcafee, kaspersky, eset

There are no good virus scanners – that is a general issue, not a Mac OS-related one.

Does the Mac have any ability to warn when someone attempts to install malicious software, other than the usual warnings about unsigned software? Windows 10, for example, will scan every attachment before opening it, catching a lot of stuff before it can do any harm.

Which is its own attack vector:

https://news.ycombinator.com/item?id=14296959

The problem here is that the file is being scanned without the user even attempting to run it. A similar vector would be file previews (thumbnails) or indexing.

If the user is about to execute a malicious file anyway, then scanning it before only adds protection.

The problem is more that the standard model for applications is 'can access the whole filesystem, can write to the user's home directory'. The default model should change to sandboxing an application without any permissions.

"scan everything before opening" is not always desirable as it exposes a large attack surface:

https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

"Avoid running your scan with elevated privileges" could have greatly mitigated this failure.

> NScript is the component of mpengine that evaluates any filesystem or network activity that looks like JavaScript. To be clear, this is an unsandboxed and highly privileged JavaScript interpreter that is used to evaluate untrusted code, by default on all modern Windows systems. This is as surprising as it sounds.

There is XProtect that warns people about known malware - https://www.howtogeek.com/217043/xprotect-explained-how-your...

There's Gatekeeper, that warns people about unsigned software from untrusted sources, and prevents it from running by default (you have to know to ctrl-click the app to force it to open, which really cuts down on accidental installs and saves most technically illiterate users from themselves).

There's also SIP, which makes sure that even if malware is installed, it can't mess with a large number of system-owned files, so the amount of damage it can do is somewhat curtailed.

Mac OS X Snow Leopard and malware detection https://support.apple.com/en-us/HT202234

Surprised I hadn't heard if this kicked in for Handbrake, but Apple maintains a list of malware (I assume by file hash?). I remember when this went into the OS because there were concerns about legit software being blacklisted.

Yes Apple has blacklisted the new malware in XProtect.

Reply on news.ycombinator.com