Skip to main content

Auto-Update - Security Overview

  • Updated

Introduction

The purpose of this document is to provide an overview of the security measures that are employed within Auto-Update. This document outlines dataflows and protocols used in the delivery of this service and is aimed at information security personnel.

Infrastructure overview and compliance

Auto-Update is a cloud-based service hosted within the dataJAR platform. Our infrastructure is supplied in partnership with CloudHelix. All infrastructure components are hosted within Telehouse - one of the UK’s leading data centre providers. The dataJAR platform operates and is accredited to the ISO/IEC 27001:2013 (Information Security Management) standard. Additionally, CloudHelix and Telehouse adhere to strict compliance requirements which can be reviewed below:

blobid0.png

All external communication to the service is limited to the URLs listed below on the following public network range of 185.43.40.102/28:

  • auto-update.datajar.mobi
  • envquery.datajar.mobi

Secure communications

All communication between the Auto-Update service and managed macOS clients is performed over HTTPS/TLS 1.2 with a publicly signed wildcard certificate. Additionally, HTTP Public Key Pinning (HPKP) is used to mitigate the risk of man-in-the-middle attacks (MITM). By design, the Auto-Update service will reject any traffic to auto-update.datajar.mobi or envquery.datajar.mobi that has been proxied, SSL decrypted or redirected. This will invalidate the session as it is considered MITM.

To ensure further secure validation, communications between managed macOS clients and the Auto-Update service use JSON Web Tokens (JWTs), which are signed using Hash-Based Message Authentication Code (HMAC) and Secure Hash Algorithm 2 (SHA-256).

JWTs are an open, industry standard (RFC 7519) method for representing claims securely between two parties. These tokens are used within the service to transfer repository credentials between the envQUERY web application and managed macOS clients. If the service cannot verify the signature HMAC Digest of a JWT, it is disregarded and the pending installation run on the managed macOS client is aborted.

Service Design

The Auto-Update service has been designed to be both resilient and support multi-tenancy. Each customer who has purchased the service has their own application pod.

Each pod is a read-only pod and runs its own HTTPS web service (based on NGINX) and serves read-only content from our central application repository. Authentication to each pod is performed over HTTPS/TLS using Basic Authentication (BA) ensuring credentials are encrypted during transit. Each pod has a unique access URL which is anonymised. Authentication credentials are also rotated periodically to ensure service security.

Another major component of the Auto-Update service is a custom web application called envQUERY. envQUERY is a highly-available clustered web application, hosted within the Auto-Update service infrastructure. It is designed to securely supply details of Auto-Update repositories to managed macOS clients using the service.

Below is an example of what envQUERY stores in the central database:

  • Customer ID (e.g. Acme Ltd)

  • Auto-Update Repository randomised (e.g. ez558k0p2PWY6lik)

  • envQUERY authentication token
    randomised (e.g. aiNPGFjzBDMspHGz8KFrHdpFLo8HfEmx)

  • Auto-Update Repository Authentication - Token randomised (e.g SUhKYzBvQnZYbEZhTXM3aTptVUtxdVdmUnZJZWxVOXRM)

As an additional security layer, any administrative access to envQUERY is limited and is not externally accessible. Access is secured by a unique user ID, password and multi-factor token which is rotated every 60 seconds. 

Security updates to envQUERY are tested and applied regularly. Any vulnerabilities are evaluated through Dependabot (see https://dependabot.com/) before being applied to production systems during scheduled maintenance windows.

Data collection

Auto-Update has been designed with consideration towards both security and compliance. The service collects minimal data that could be classified as Personally Identifiable Information (PII). PII data, classified as General Data Protection Regulation (GDPR) relevant data, collected in conjunction with the service is limited to the local IP address and public IP address of a managed macOS client.

If you would like further information on how dataJAR utilises customer data, please review our Privacy Policy at https://datajar.co.uk/privacy-policy/.

Automated software packaging and distribution

The Auto-Update service leverages an industry standard Open Source application called AutoPkg (see https://github.com/autopkg/autopkg). AutoPkg is used to acquire readily available software, direct from the vendor, and populate the Auto-Update Repository with software titles.

Each software title has a Recipe Override which links to the files that contain the download, packaging, verification and versioning details as well as being stamped with trust-info. The trust-info key comprises the Parent Recipes git commit hash (see https://docs.github.com/en) and SHA-256 of the Recipe Override, plus any additional items. These are then stored, checked and processed when the Recipe Override is run.

When a software title Recipe Override has completed successfully, the downloaded media is uploaded to VirusTotal (see https://support.virustotal.com/hc/en-us/articles/115002126889-How-it-works) for analysis before being pushed to the Auto-Update Repository for distribution.

If for any reason any steps fail within the Recipe Override (such as SHA-256, Code Signature or VirusTotal,) then the process is halted and a service desk support incident is raised for remediation according to the Service Level Agreement (SLA).

Please see the below workflow diagram for reference:

blobid1.png

Client components 

In order for managed macOS clients to communicate and access the Auto-Update service, there are several components installed which are detailed below and shown in the figure above:

The Auto-Update core components are supplied as a signed installation package (.pkg) which is delivered to managed macOS clients from an existing Jamf Pro environment.

Both Munki and Notifier applications are managed by Configuration Profiles, which are deployed via a supported Jamf Pro MDM Server. This means the settings are enforced on managed clients and cannot be overwritten unless another Configuration Profile is installed.

For additional security, the Auto-Update Repository URL and authentication credentials are retrieved from the envQUERY web application. This process is triggered via the Auto-Update Preflight before being written to disk in a root only accessible location, which can only be read by Munki.

Once the Munki has completed the installation process it will then execute the Auto-Update Postflight which will securely remove any authentication artifacts from disk, but leave in place the Auto-Update Repository URL obtained from envQUERY. This is by design and is to avoid Munki’s default repo detection (see https://github.com/munki/munki/wiki/Default-Repo-Detection).

Please see the below workflow diagram for reference:

blobid0.png

Client tasks

Below is a detailed list of what occurs during a check-in from a managed macOS client to the Auto-Update service:

Auto-Update preflight tasks 

  • Core components
    • Munki needs to be installed. 

    • Check for root privileges.

    • The Jamf Binary needs to be present.

    • FoundationPlist from Munki needs to be present.

    • A valid Configuration Profile needs to be present.

  • Network connectivity
    • The local IP address of the macOS client is retrieved if the macOS client is online. If the macOS client is offline then the script will silently exit with a zero status.
  • Secure communications

    • A JSON Web Token is created using unique artefacts from both the Configuration Profile, this is then submitted to the envQUERY web application.

    • The public key is then presented by envQUERY to the managed macOS client - this has to match any of the expected public keys.

    • The response data returned from envQUERY has to match the expected format.

    • The URL from which the data was returned has to match that of envQUERY.

    • The HTTP response code from envQUERY has to have a value of 200.

    • The response data has to contain a valid JSON Web Token.

    • The JSON Web Token has to be signed with a valid HMAC digest.

    • The JSON Web Token signature has to be validated against the HMAC digest.

    • A valid Auto-Update Repository URL needs to be found within the JSON Web Token.
    • The Auto-Update Repository URL needs to be accessible to the managed macOS client.

Managed software installations and uninstallations

Managed software installations and uninstalls are handled by Munki.

Munki will check the version of the software title that has been added to the Manifest, which is controlled by Jamf.

Munki, by design, will perform a series of checks against the installation target before attempting the installation or uninstallation of a software title. Every software title within Auto-Update is accompanied by a supporting file containing additional metadata; this is referred to as a pkginfo file.

The pkginfo file contains various metadata for the corresponding software installation, such as:

  • Version information
  • SHA-256 checksum
  • Preinstall scripts
  • Install instructions
  • Installation method
  • Postinstall scripts
  • Blocking applications
  • Uninstall scripts
  • Uninstall Method

With both the software title and pkginfo downloaded, the SHA-256 checksum of the downloaded software title is checked against the SHA-256 checksum expected for the software title and detailed within the pkginfo.

If this verification fails, the installation will be aborted and the results logged. If the checksum is validated the installation is completed as instructed by the pkginfo file.

Auto-Update postflight tasks

  • Finalise

    • Munki's ManagedInstallReport is processed to see if any changes have been made during there last Auto-Update run.

    • Notify the current logged in user on the managed macOS client. Please be aware there are no notifications for software uninstalls.

    • Securely remove all authentication artefacts from the local disk.

Schedule

Auto-Update is primarily controlled by the Jamf Binary and is dependent on check-in schedules defined within the Jamf Pro.

However, once installed on a managed macOS client, Auto-Update will also run on Munki's randomised hourly schedule. This is completely transparent to the logged in user unless there are installation or uninstall tasks pending, at which point these items are processed.

Client logging

Activity and errors generated are logged locally to disk in the following location on the managed macOS client:

  • /var/log/auto-update.log

This log has a 10MB retention limit.

Integration with Jamf Pro

blobid0.png

Policy

As shown above, Auto-Update has been designed to work seamlessly with an existing and supported Jamf Pro environment. Fundamentally, Jamf Pro controls what is required to be installed or uninstalled on a managed macOS client.

The Auto-Update process is triggered by a policy within Jamf Pro which is defined and controlled by the Jamf  Pro Administrator.

This is via a policy within Jamf Pro which has the Auto-Update Policy Script added as a payload and passes a value to either parameter $4, $5, $6, or $7 of the Auto-Update Policy Script.

The Auto-Update Policy Script updates the Manifest and then Auto-Update is ran, processing this Manifest. If after Auto-Update is ran, the Manifest still has content it is ran again either via a subsequent Jamf Pro policy containing the Auto-Update Policy Script or Munki's randomised hourly schedule.

Regardless of how Auto-Update is triggered, the first item executed  is the Auto-Update Preflight, which will obtain the Auto-Update Repository URL and authentication credentials from envQUERY.

Logging and troubleshooting

Auto-Update can emit log messages which are available from within Jamf Pro, as well as on macOS.

This section details where to access these logs.

macOS Logging

Activity and errors generated are logged locally to disk in the following location on the managed macOS device:

  • /var/log/auto-update.log

Extension Attribute

The Auto-Update Extension Attribute logs the last line of the log file present on macOS.

  1. Login to Jamf Pro and click on Computers > Search Inventory.blobid27.png

  2. Search for your device and select it from the Inventory, navigate to General and scroll down until you reach the Extension Attributes section. There you will see the status of Auto-Update presented like so. blobid26.png

Policy Logging

To review the individual status of Auto-Update Policy, please complete the following:

  1. Login to Jamf Pro and click on Computers > Policies.blobid28.png

  2. Find your desired Policy from the list and select. At the base of the browser window select the Logs option.blobid29.png

  3. Find the device you would like to inspect further, and select Details. From there you will be presented with the output of the Auto-Update Policy log:

Executing Policy Auto-Update - Citrix Receiver
Running script Auto-Update.py...
Script exit code: 0
Script result: Adding CitrixReceiver to installs
Preflight: Contains 1 installs ['CitrixReceiver'], 0 uninstalls [], 0 pending, 0 warnings
Postflight: Contains 0 installs [], 0 uninstalls [], 0 pending, 0 warnings

Understanding Auto-Update Log Messages

Please see the KB Understanding Auto-Update Log Messages, for more detail around these log messages and any additional error messages which can present themselves within the logs.

Need further support?

Automate. Simplify. Succeed. If you still require assistance with us or have any further questions, please raise a ticket with our support team.

Alternatively, please see our frequently updated knowledge base articles for reference.

Related articles