Archive
Building customized postinstall scripts for AutoPkg recipes
As part of some recent work, I needed to build a deployable installer package for an application named Zscaler. This application does not use an installer package, nor can it be installed as a drag-and-drop app. Instead, it uses a third party installer application to install.
This is exactly the kind of situation where I want to write an AutoPkg recipe to handle building a deployable installer package for me. As part of that, I had two bits of good news:
- There was a publicly available download URL for the Zscaler installer app.
- Zscaler has instructions for installing from the command line, so I could wrap up the installer application inside an installer application and use a postinstall script to run the installation process.
I had one bit of bad news:
The installer process included options for adding things like the Zscaler cloud instance which the app should talk to following the installation as well as various other options which probably shouldn’t be hardcoded into an Autopkg recipe. I especially shouldn’t be hardcoding my own organization’s credentials into a recipe which I was planning to share with other folks.
Normally, sensitive information is something I want to only have in an AutoPkg recipe override. Recipe overrides are locally-stored files that allow you to change certain input variables in AutoPkg recipes. Since the recipe overrides are stored locally on the Mac which is running AutoPkg and not shared with any other resources, the sensitive information is only made available to the AutoPkg installation running on that specific Mac. I’ve used this approach previously for the following:
Sensitive URLs: https://derflounder.wordpress.com/2017/06/12/autopkg-recipes-for-apple-enterprise-connect/
Signing AutoPkg-generated installer packages: https://derflounder.wordpress.com/2017/11/10/adding-installer-package-code-signing-to-autopkg-workflows/
This time though, I didn’t see a way to pass an AutoPkg recipe override’s variables to a postinstall script. I did have one idea though, which was using AutoPkg’s FileCreator processor to create a customized postinstall script. I had previously used the FileCreator processor in other AutoPkg recipes to create postinstall scripts, but those scripts were self-contained and didn’t use variables from the AutoPkg recipe.
That said, you never know what AutoPkg can do until you try it and sure enough the FileCreator processor was able to pass recipe variables as part of creating a file. For more details, please see below the jump.
Suppressing Microsoft AutoUpdate’s Required Data Notice screen
Suppressing Microsoft AutoUpdate’s Required Data Notice screen
As part of the latest update to Microsoft AutoUpdate app, a new screen has appeared which requires the logged-in user to click on it.
This screen is to notify users that Microsoft AutoUpdate collects diagnostic data for Microsoft and provides basic information on how to opt-out of the data collection. The overall point of the screen is to help Microsoft comply with the European Union’s General Data Protection Regulation (GDPR) and similar laws.
While this screen is fairly straightforward for an individual to deal with on their own Mac, it may cause challenges for computer labs because those facilities may remove and repopulate user home folders on each login. Since the setting which records that a user has seen the notification is stored in the user’s home folder, in the ~/Library/com.microsoft.autoupdate2.plist file, this may result in the lab’s users seeing this notification multiple times unnecessarily. To address this, Microsoft has made suppressing this screen possible by adding the following key and value to the com.microsoft.autoupdate2.plist file
- Key: AcknowledgedDataCollectionPolicy
- Value: RequiredDataOnly
This setting can be applied with a script or with a configuration profile. For more details, please see below the jump.
Additional Zoom remediation from Apple via MRT
Apple had released an MRT update on July 12th to cover the vulnerabilities disclosed for Zoom and RingCentral , but then additional Zoom variants popped up on the radar.
To fix all of the variants, Apple has released another MRT (Malware Removal Tool) update today. This fixes the vulnerabilities found in Zoom and its various white label versions which Zoom developed for third parties:
- Zoom
- RingCentral
- TelusMeetings
- BT Cloud Meetings
- Office Suite HD Meeting
- AT&T Video Meetings
- Biz Conf
- Huihui
- UMeeting
- Zhumu
- Zoom CN
This MRT update has the following version number:
1.46.1.1563225526
The installer package receipt associated with it is the following:
com.apple.pkg.MRTConfigData_10_14.16U4075
To verify that you have this installed, here’s a one-line command to check for the latest installed MRT installer package:
To verify that com.apple.pkg.MRTConfigData_10_14.16U4075 does install 1.46.1.1563225526, here’s a one-line command to get the version number from the latest installed MRT installer package receipt:
To assist with getting information like this for Gatekeeper, MRT and XProtect, I’ve written a script that pulls the following information for each:
- Version number
- Installation date
- Installer package receipt identifier
For more information, please see below the jump.
Zhumu vulnerability and remediation
As more security researchers look into the Zoom vulnerability issue, it now appears that Zhumu (Zoom’s affiliate for China) has a client for macOS with the same local webserver vulnerability as that previously discovered for Zoom’s and RingCentral’s clients for macOS.
For those wanting to manually remediate for all three clients, the following commands can be run:
The question at this point is: how many more Zoom variants are there out there? I hadn’t previously been aware of Zhumu or of Zoom’s business relationship with this company. Are there more?
I’ve updated my fix_zoom_vulnerability script to also address the Zhumu client. For more details, please see below the jump.
Checking if Apple’s Zoom remediation update has been installed on your Mac
As part of the Zoom vulnerability issue, further problems have been discovered as security researchers look into the local webserver installed by older versions of the Zoom app for macOS.
Apple has moved quickly and released an update to MRT (Malware Removal Tool) which addresses the issue by removing the local webserver. This update has the following version number:
1.45.1.1562731315
The installer package receipt associated with it is the following:
com.apple.pkg.MRTConfigData_10_14.16U4071
To verify that you have this installed, here’s a one-line command to check for the latest installed MRT installer package:
To verify that com.apple.pkg.MRTConfigData_10_14.16U4071 does install 1.45.1.1562731315, here’s a one-line command to get the version number from the latest installed MRT installer package receipt:
To assist with getting information like this for Gatekeeper, MRT and XProtect, I’ve written a script that pulls the following information for each:
- Version number
- Installation date
- Installer package receipt identifier
For more information, please see below the jump.
Zoom vulnerability and remediation script
Zoom is a popular video conferencing suite which is used by a number of shops because it provides a consistent cross-platform experience. Recently, it was discovered that Zoom was setting up a local webserver process. This capability enabled Zoom’s client to be launched in response to clicking a URL, but it also potentially allowed someone to be forcibly connected to a Zoom call with their video camera active. This issue has been assigned the following CVE identifier:
CVE-2019-13450: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13450
Update: 7-11-2019 – Apple has released an update to remove the Zoom web server from all Macs. This update deploys silently and does not require user interaction. For more details, please see Zoom’s July 10th blog post: https://blog.zoom.us/wordpress/2019/07/10/security-update-and-our-ongoing-efforts/
Once this vulnerability was widely publicized, Zoom responded with an updated version of their Zoom client for macOS which removes the local webserver and also allows users to manually uninstall the Zoom client. They also provided the following manual remediation instructions:
I’ve taken those commands and used them to build a script to address the vulnerabilities described in CVE-2019-13450. For more details, please see below the jump.
Managing macOS Mojave’s FileVault 2 with fdesetup
Since its initial release in OS X Mountain Lion 10.8.x, Apple’s main tool for managing FileVault 2 encryption has been fdesetup. With the transition from managing Core Storage-based encryption on HFS+ to managing the native encryption built into Apple File System completed, this well-developed toolset continues to be Apple’s go-to tool for enabling, configuring and managing FileVault 2 on macOS Mojave.
With its various functions, fdesetup gives Mac administrators the following options for managing FileVault:
- Enable or disable FileVault 2 encryption on a particular Mac
- Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
- Enable one or multiple user accounts at the time of encryption
- Get a list of FileVault 2-enabled users on a particular machine
- Add additional users after FileVault has been enabled
- Remove users from the list of FileVault enabled accounts
- Add, change or remove individual and institutional recovery keys
- Report which recovery keys are in use
- Perform a one-time reboot that bypasses the FileVault pre-boot login
- Report on the status of FileVault 2 encryption or decryption
For more details, please see below the jump.
Recent Comments