Archive for the ‘Security’ Category

Using Twocanoes’ Signing Manager to sign AutoPkg-built installer packages

March 6, 2021 Leave a comment

As part of many application or package building workflows, there is a requirement to sign the end result to guarantee that the app or package has not been tampered with. With the advent of Apple’s notarization process, this has become even more important because an app or installer package must be signed before it can be notarized.

However, in order to sign apps or packages, you must have the signing certificate available. This has often meant putting copies of Apple signing certificates, complete with the certificate’s private key, onto the Mac or Macs used to build the application and/or installer package. This has security concerns because if the signing certificate’s private key is compromised, you must now revoke the existing certificate, get a new one from Apple and re-sign everything that used that now-revoked signing certificate.

To assist with the security concerns, Twocanoes Software has developed Signing Manager. This tool provides a way to centralize hosting of signing certificates and make their signing capabilities securely available to Macs which need them. In my own case, I’m investigating Signing Manager in the context of signing AutoPkg-built installer packages. For more details, please see below the jump.

Read more…

Mad, bad and possibly dangerous – a cautionary tale of software installation

June 5, 2020 8 comments

In my career, I’ve run across a lot of terrible installers in a variety of forms. The one I ran across today though is noteworthy enough that I want to point it out because of the following reasons:

  1. It’s an installer application. I have opinions on those.
  2. It’s for a security product where, as part of the installation, you need to provide the username and password for an account on the Mac which has:
  • Administrator privileges
  • Secure Token

Note: I have no interest in talking to the vendor’s legal department, so I will not be identifying the vendor or product by name in this post. Instead, I will refer to the product and vendor in this post as “ComputerBoat” and leave discovery of the company’s identity to interested researchers.

For more details, please see below the jump.

Read more…

Notarization on macOS Catalina and IT auditing

October 3, 2019 Leave a comment

One of the changes Apple is introducing in macOS Catalina is the notarization requirement for code in the following categories:

  •  All apps signed after June 1st, 2019
  •  Signed executable code which are undergoing first run checks (this check would be triggered by the executable having a extended attribute.)

Note: Signed executable code can take many forms, including command-line binaries or other tools which don’t fit into the usual macOS app category. In this post, I’m going to be using “executable” or “executable code” in this post as shorthand for “It’s not an app, but you can sign, notarize and run it.”

Notarization is commonly thought of as Apple doing a malware scan on the app / executable in question, but it’s also more than that. Notarization also includes a code hardening process for the app or executable, which sets up the app or executable code to run in a protected environment. What protections are provided? According to Apple:

  •  App / executable can’t create executable memory without the app / executable being associated with a code signature.
  •  When the OS is reading code or data from drive storage, all the data being read in to the running app or executable must match the app /executable’s code signature.
  •  Code which is modified in memory and which no longer match the app / executable’s code signature can’t be executed.
  •  Protection provided against code injection and/or dylib hijacking.

While there are entitlements provided by Apple to allow apps / executables to bypass these protections, they’re embedded as part of the notarization process and can’t be changed later without breaking the code signature. Meanwhile, notarization is for the life of that particular app / executable code. It’s not just checked once, like has been the case with Gatekeeper’s code signature check for apps / executables on previous versions of macOS.

How does this relate to IT auditing and making it less painful? Well, imagine you had an auditor come to you and say “I need you to check and verify that all third-party apps used in your environment have been scanned for malware.”

Holy cow. That’s a huge requirement.

Or it was. Notarization provides exactly that capability and it can be verified on-demand using the stapler tool. Even better, since the OS is what’s requiring notarization for apps, it’s automatically handling compliance for you. Meanwhile, notarization’s protected environment limits considerably the ability of malware to hijack notarized apps. That likely would check a few more malware-related compliance boxes on the auditor’s checklist.

For an example of this, let’s take a look at the Australian Cyber Security Centre’s guidance for application whitelisting. For enforcement mechanisms, two of them are provided by macOS Catalina’s handling of notarized apps:

  • Cryptographic hash rules
  • Publisher certificate rules

Screen Shot 2019 10 03 at 11 57 06 AM

The US’s National Institute of Standards and Technology provides similar guidance (please see Section 2.2.1 File and Folder Attributes of NIST SP 800-167):

Screen Shot 2019 10 03 at 12 04 51 PM

This is not to say that you can hold up a “Notarized!” sign to the auditor, watch the auditor leave after just tossing the checklist aside and commence the post-audit party. But for those folks who have to undergo regular compliance auditing, I would recommend you examine your auditing requirements carefully to see which IT audit controls on your list now get handled automatically on macOS Catalina with its notarization requirements.

%d bloggers like this: