Another Mac-specific malware pops up, but Apple's Gatekeeper still prevents infection

Posted:
in macOS
A second piece of Mac-specific malware has been discovered this week, one that could expose the passwords stored in the macOS Keychain. But once again, Apple's Gatekeeper security -- when properly configured -- will block the attack from succeeding.




Researchers at security firm ESET have been examining a new strain of OS X malware from an unknown source, and have published a breakdown of the so-called "OSX/Keydnap" package.

The malware is distributed as a .zip compressed archive, containing the package disguised as a text file or JPG graphic with accompanying icon. However, the file name has a trailing space, which by default, opens the Mach-O executable in the macOS Terminal.

After a double-click on the file, the Terminal icon appears in the dock, and very quickly closes. At this point, if Gatekeeper is active, the security mechanism pops up a warning to the user, saying that the file is from an unidentified developer, and prevents the launch.

If Gatekeeper has been configured by the user to execute all software regardless of source, the malware then downloads and runs the backdoor component which is executed at every reboot, replaces the Mach-O executable that the user clicked on with a decoy graphic or text file, and opens the decoy document in Preview.




The malware will seek root access, by waiting until another application launches, and popping up a dialog for user credentials.

After being granted root access, OSX/Keydnap can then be used by the owners of the a command and control server to hunt down the decryption key for the user's Keychain, and upload the stored passwords. Keychain-stored passwords include system passwords, as well as login information for Internet-based services, such as banking credentials, Gmail passwords, Amazon login information, and others.

To supplement Gatekeeper, an Internet connection monitoring application like Little Snitch can be used to examine incoming and outgoing Internet transmissions, and block undesirable ones, such as the download of the malware component in this case. Utilities similar to BlockBlock can continuously monitor for installation of persistent components vital for malware installers.

The revelation of the OSX/Keydnap package is the second Mac malware reveal in a week. On July 6, Backdoor.Mac.Eleanor was exposed, and is also easily preventable with properly configured Apple-provided security software, or by user awareness of the attack vector. AppleInsider was not able to obtain a sample of the malware to see if Apple's Xprotect has been updated.

The researchers at ESET note that they have no idea how the malware is spread, but spam email attachments are likely. Additionally, they have no count of active infections. Decoy images found during research point to the possibility of security researchers being a target of the malware.

Comments

  • Reply 1 of 10
    normmnormm Posts: 653member
    It seems like a bug for files ending with a space to open terminal and execute!  Clever the way this covers its tracks, though, by replacing itself with an actual jpg, and then opening it in preview.
  • Reply 2 of 10
    appexappex Posts: 687member
    Apple should fix the trailing space bug!!!
    cornchip
  • Reply 3 of 10
    RosynaRosyna Posts: 87member
    appex said:
    Apple should fix the trailing space bug!!!
    The Gatekeeper dialog makes it painfully clear that there is a space.


    kevin keecornchiplinkman
  • Reply 4 of 10
    Interesting we have two malware attempts with relatively new-to-Mac effects soon after Apple distributed the macOS beta with an unencrypted kernel. Perhaps unrelated? I don't know enough to know for sure...
    cornchip
  • Reply 5 of 10
    RosynaRosyna Posts: 87member
    Interesting we have two malware attempts with relatively new-to-Mac effects soon after Apple distributed the macOS beta with an unencrypted kernel. Perhaps unrelated? I don't know enough to know for sure...
    The kernel has never been encrypted on Mac OS X and none of these pieces of malware are new or exploit bugs in the system. They are all poorly written Trojans.
    dementuschikancornchippscooter63
  • Reply 6 of 10
    coolfactorcoolfactor Posts: 2,239member
    I am 100% confident that Apple will be improving file extension handling as a result of this malware. I just learned something interesting...

    Take an ordinary .jpg file (a real image), and add a space to the end. View "Get Info..." on the file and it's recognized as a TextEdit file! However, opening it still works as expected, opening up in my default image app (Xee.app, in my case).

    I just repeated this with .png and .sql files, as well. It seems that when there's a space on the end, OS X ... sorry, macOS ... no longer interprets the extension properly. I would classify that as a flaw!  It seems that spaces in file extensions are honoured, and that TextEdit is the default handler for file extensions that aren't recognized. Seems like a flawed implementation to me, and may be isolated to Finder.

    Curious that the article suggests that the file would open up in Terminal simply because of the space on the end. I don't believe that's the case. Clearly the file was distributed with an internal file type bound to be an executable.

    OS X only uses file extensions for compatibility reasons. It has its own internal file-typing system, which is why the above files still opened properly for me, even though Get Info is showing a different file type based on the extension. Finder flaw.
    cornchip
  • Reply 7 of 10
    Mike WuertheleMike Wuerthele Posts: 6,858administrator
    That's not the inference of the article. "which by default, opens the Mach-O executable in the macOS Terminal." The space at the end of the extension forces OS X to examine the contents of the file. The file is a Mach-O executable, so by default, it opens that in the Terminal.
    cornchipsteester
  • Reply 8 of 10
    Rosyna said:
    The kernel has never been encrypted on Mac OS X and none of these pieces of malware are new or exploit bugs in the system. They are all poorly written Trojans.
    AH. My bad. It was the iOS kernel which was recently left unencrypted in the iOS 10 betas. THanks for forcing me to look that up :)
    cornchipbaconstang
  • Reply 9 of 10
    RosynaRosyna Posts: 87member
    I am 100% confident that Apple will be improving file extension handling as a result of this malware. I just learned something interesting...

    Take an ordinary .jpg file (a real image), and add a space to the end. View "Get Info..." on the file and it's recognized as a TextEdit file! However, opening it still works as expected, opening up in my default image app (Xee.app, in my case).

    I just repeated this with .png and .sql files, as well. It seems that when there's a space on the end, OS X ... sorry, macOS ... no longer interprets the extension properly. I would classify that as a flaw!  It seems that spaces in file extensions are honoured, and that TextEdit is the default handler for file extensions that aren't recognized. Seems like a flawed implementation to me, and may be isolated to Finder.

    Curious that the article suggests that the file would open up in Terminal simply because of the space on the end. I don't believe that's the case. Clearly the file was distributed with an internal file type bound to be an executable.

    OS X only uses file extensions for compatibility reasons. It has its own internal file-typing system, which is why the above files still opened properly for me, even though Get Info is showing a different file type based on the extension. Finder flaw.
    LaunchServices, which controls document binding, prefers the extension over other metadata for "compatibility" with legacy systems (specifically OpenStep) that lack rich metadata.

    If the file name (which includes the extension as it is just the last part of the file name and not a separate field) does not match any claimed document types, LaunchServices falls back to other metadata like file type/creator code, mime type (set when the file was downloaded), or file magic (first few bytes of the file if the file mode is +x).

    This is not a bug. Mac OS X correctly identified it as a Mach-O executable. It correctly showed the file icon that was embedded in the resource fork of the executable. It correctly passed it to gatekeeper. Gatekeeper correctly rejected it because it was unsigned.

    So I'm not sure what the problem is that you think needs fixing here…
    edited July 2016 pscooter63loopless
  • Reply 10 of 10
    looplessloopless Posts: 325member
    Rosyna said:
    I am 100% confident that Apple will be improving file extension handling as a result of this malware. I just learned something interesting...

    Take an ordinary .jpg file (a real image), and add a space to the end. View "Get Info..." on the file and it's recognized as a TextEdit file! However, opening it still works as expected, opening up in my default image app (Xee.app, in my case).

    I just repeated this with .png and .sql files, as well. It seems that when there's a space on the end, OS X ... sorry, macOS ... no longer interprets the extension properly. I would classify that as a flaw!  It seems that spaces in file extensions are honoured, and that TextEdit is the default handler for file extensions that aren't recognized. Seems like a flawed implementation to me, and may be isolated to Finder.

    Curious that the article suggests that the file would open up in Terminal simply because of the space on the end. I don't believe that's the case. Clearly the file was distributed with an internal file type bound to be an executable.

    OS X only uses file extensions for compatibility reasons. It has its own internal file-typing system, which is why the above files still opened properly for me, even though Get Info is showing a different file type based on the extension. Finder flaw.
    LaunchServices, which controls document binding, prefers the extension over other metadata for "compatibility" with legacy systems (specifically OpenStep) that lack rich metadata.

    If the file name (which includes the extension as it is just the last part of the file name and not a separate field) does not match any claimed document types, LaunchServices falls back to other metadata like file type/creator code, mime type (set when the file was downloaded), or file magic (first few bytes of the file if the file mode is +x).

    This is not a bug. Mac OS X correctly identified it as a Mach-O executable. It correctly showed the file icon that was embedded in the resource fork of the executable. It correctly passed it to gatekeeper. Gatekeeper correctly rejected it because it was unsigned.

    So I'm not sure what the problem is that you think needs fixing here…
    Thanks for the clear analysis. AppleInsider needs to fix their article, as it is inaccurate. It is not the space at the end that causes the file to be identified as a Mach-O executable. It **is** a Mach-O executable. And , as stated, there is no problem that needs fixing.
    edited July 2016
Sign In or Register to comment.