Archive
Setting up an ad-hoc TCP listener for connection testing using Python’s web service
I recently needed to set up a connection test so that an outside vendor could verify that firewall rules had been set up correctly on both ends and that a connection which originated at a specific IP address on the vendor’s end was able to resolve a DNS address on our end and make a connection.
I remembered that Python has a simple way to set up a web server, so I decided to use this to create a script which creates a connection listener by setting up a web server on the desired port. For more details, please see below the jump.
Using the Jamf Pro API to report on which Macs are assigned to a particular person
Every so often, it may be necessary to generate a report from Jamf Pro on which computers are assigned to a particular person. To assist with this task, I’ve written a script which uses the Jamf Pro Classic API to search through the computer inventory records and generate a report in .tsv format.
For more details, please see below the jump.
Codesigning, untrusted certificate authorities and why certain apps aren’t launching
A number of folks noticed that certain older applications they use on macOS stopped working as of August 24th, 2021. As of this date, this appears to affect the following applications among others:
Note: This list is not complete, it’s just the ones I’m aware of as of August 24, 2021.
Why this is happening goes back to an episode in 2018, where Symantec had to get out of the PKI certificate issuing business because of a number of issues discovered with how Symantec had been issuing certificates.
As part of these issues, Apple issued an advisory that a number of Symantec Certificate Authority (CA) root certificates were to be distrusted by Apple on a timeline which concluded with the full distrust of Symantec CAs on February 25, 2020.
While this primarily affected website operators, Symantec also issued certificates from the affected Symantec CAs which were used to provide code signing for applications. An example of this is RSA SecurID Software Token 4.2.1.
Update 8-26-2021: RSA has released RSA SecurID Software Token 4.2.2 to resolve the issue with RSA SecurID Software Token 4.2.1. For more details, please see the link below:
In the case of SecureID, this app relies on Qt Core for user interface support and ships copies of the QT Core framework along with the SecureID app. SecurID stores this in the following location:
/Library/Frameworks/stauto32.framework
If you take a look at the installer, you can see where the files are supposed to go.
However, the actual file which is causing the issue is buried further down in the following location:
/Library/Frameworks/stauto32.framework/Versions/4/QtCore.cire
This file is important because the QT Core framework is shipped without Apple’s code signing, which is to say that QT is not using an Apple Developer ID signing certificate to sign QT Core. Instead, QT ships a code signing certificate chain and that information is stored in the QtCore.cire file.
One of the certificates in the code signing certificate chain is using VeriSign Class 3 Public Primary Certification Authority – G5 as its root certificate authority (root CA). That root CA is one of the Symantec CAs which is no longer trusted by Apple.
To summarize: the SecureID app has a component which is signed by a not-trusted certificate. This is causing SecureID to not trust that component, which then prevents the app from launching correctly.
Why is this happening now?
Apple released updates on August 23, 2021 for both XProtect (now version 2150) and Malware Removal Tool (now version 1.82). My assumption is that XProtect’s update included instructions to no longer accept code signing from the distrusted Symantec CAs. XProtect checks executable code on launch, so it would be working with Gatekeeper to detect and block the no-longer-trusted code signing.
What should you do?
See if your vendor has released an updated version of the app which is having problems. If they haven’t yet, I recommend contacting them to make sure they’re aware of the problem.
Hat tip to all the folks working on this issue in the MacAdmins Slack for helping diagnose the issue and why it is happening.
Downloading and installing macOS Big Sur via macOS Recovery’s Terminal
Every so often, you may find yourself in a situation where you need to reinstall macOS Big Sur and everything is failing on you. Installing from macOS Recovery? Not working via the usual methods. Building a USB installer? Left the flash drive in your other pants. Using DFU mode and Apple Configurator on an Apple Silicon Mac? You need a second Mac to use this process and you just have the one Mac available.
For those situations, there’s one more option when you’ve exhausted all of the others. For more details, please see below the jump.
Signing AutoPkg-built packages using a .sign recipe
For those that need to sign their AutoPkg-generated installer packages with a signing certificate, the PkgSigner processor is available to assist with this. When I originally started using this processor, I was building the signing part directly into .pkg recipes, but my teammate @jaharmi came up with a better and more modular idea: the .sign recipe.
The .sign recipe uses the PkgSigner processor and is designed to be placed in the AutoPkg workflow between a .pkg recipe and a.jss recipe for JSSImporter, a .munki recipe for Munki or other recipes used to upload an installer package to a deployment tool. In this case, the .pkg recipe would be a parent recipe for the .sign recipe. In turn, the .sign recipe would be used as the parent recipe for whatever came next in the workflow.
For those who want to use .sign recipes, there is an example recipe available via the link below:
https://github.com/autopkg/rtrouton-recipes/blob/master/SharedProcessors/Example.sign.recipe
If you want to use the PkgSigner processor hosted from my AutoPkg recipe repo, first verify that AutoPkg is installed on the Mac you’re using. Once verified, run the following command:
autopkg repo-add rtrouton-recipes
Packaging a SAP GUI installer application for macOS
One of the recent changes for the macOS version of SAP GUI for Java is that both SapMachine Java 11 and OpenJFX 11 are now bundled with SAP GUI, so it is no longer required to have Java installed on your machine in order for SAP GUI to work. This change has also been extended to the SAP GUI installer, which is now available as a notarized installer application as of SAP GUI 7.70.
You can run this installer on a Mac which does not have Java already installed and it will install SAP GUI for Java with SapMachine Java 11 and OpenJFX 11 installations embedded inside the SAP GUI application.
Note: As of SAP GUI 7.70 rev 2, Rosetta 2 is required if installing on an Apple Silicon Mac so Rosetta needs to be installed and running before installing SAP GUI.
The installer application is available for download to customers via a link on the announcement blog post:
https://blogs.sap.com/2021/03/16/ann-sap-gui-for-java-7.70-available-for-download/
When you click the download link, you will see two choices:
- DMG
- JAR
The DMG download will provide the notarized installer application and the JAR download will provide the Java .jar installer that SAP GUI has traditionally used on macOS. I’ve discussed how to package the .jar installer in previous posts, so this post is going to focus on the new installer application contained inside the DMG download.
For more details, please see below the jump.
Monitoring Startup Security settings on Apple Silicon Macs
To help maintain the security of the Apple Silicon Macs in your environment, it’s helpful to be able to monitor what the Startup Security settings are for those Macs.
For this task, the reporting functions of the bputil tool are available. Normally, Apple wants you to avoid the bputil tool like you would a swarm of bees. As part of that, the following warning is displayed by bputil:
| username@computername ~ % bputil -d | |
| This utility is not meant for normal users or even sysadmins. | |
| It provides unabstracted access to capabilities which are normally handled for the user automatically when changing the security policy through GUIs such as the Startup Security Utility in macOS Recovery. | |
| It is possible to make your system security much weaker and therefore easier to compromise using this tool. | |
| This tool is not to be used in production environments. | |
| It is possible to render your system unbootable with this tool. | |
| It should only be used to understand how the security of Apple Silicon Macs works. | |
| Use at your own risk! | |
| The tool requires running as root | |
| username@computername ~ % |
However, the bputil -d command is safe to use as it displays the contents of the current security policy’s settings. When the default Full Security security mode is enabled, running the bputil -d command with root privileges should display content similar to what’s shown below:
| username@computername ~ % sudo bputil -d | |
| Password: | |
| This utility is not meant for normal users or even sysadmins. | |
| It provides unabstracted access to capabilities which are normally handled for the user automatically when changing the security policy through GUIs such as the Startup Security Utility in macOS Recovery. | |
| It is possible to make your system security much weaker and therefore easier to compromise using this tool. | |
| This tool is not to be used in production environments. | |
| It is possible to render your system unbootable with this tool. | |
| It should only be used to understand how the security of Apple Silicon Macs works. | |
| Use at your own risk! | |
| Current OS environment: | |
| OS Type : macOS | |
| Local Policy Nonce Hash (lpnh): 7E1ED4512B6DF2A284C6343E469C1F1459453E4898E770CF37A8F3B1D9C000E0DA0C5C5F0546AB70984BEC3A9870DD9E | |
| Remote Policy Nonce Hash (rpnh): 88EB8429C516B53BBCA49EC7C0D58C3F27F2890D23E176264B2178EE2A865327CFD06ED94834EE6FF7D145FB39245B59 | |
| Recovery OS Policy Nonce Hash (ronh): 6CF5EB6318AF551C5A23B8D3B2E4196AAA372B523E4F412C375CF6B39DCFED28F9B4E9881BF348886F9B9A14E918AA69 | |
| Current local policy: | |
| Signature Type : BAA | |
| Unique Chip ID (ECID): 0xD793810C0291E | |
| Board ID (BORD): 0x26 | |
| Chip ID (CHIP): 0x8103 | |
| Certificate Epoch (CEPO): 0x1 | |
| Security Domain (SDOM): 0x1 | |
| Production Status (CPRO): 1 | |
| Security Mode (CSEC): 1 | |
| OS Version (love): 21.1.268.5.8,0 | |
| Volume Group UUID (vuid): 2D85CA09-A291-47CA-A68A-66CB2D3BDF70 | |
| KEK Group UUID (kuid): AC09E9D5-36DC-10C9-4312-E6DAA3753224 | |
| Local Policy Nonce Hash (lpnh): 7E1ED4512B6DF2A284C6343E469C1F1459453E4898E770CF37A8F3B1D9C000E0DA0C5C5F0546AB70984BEC3A9870DD9E | |
| Remote Policy Nonce Hash (rpnh): 88EB8429C516B53BBCA49EC7C0D58C3F27F2890D23E176264B2178EE2A865327CFD06ED94834EE6FF7D145FB39245B59 | |
| Next Stage Image4 Hash (nsih): 443560FD2BE056BC9527452729EEC1A1BB22BA2DA456B278624DEF822DE9F7A64F0303B64ED811405B4039475F8A623D | |
| User Authorized Kext List Hash (auxp): absent | |
| Auxiliary Kernel Cache Image4 Hash (auxi): absent | |
| Kext Receipt Hash (auxr): absent | |
| CustomKC or fuOS Image4 Hash (coih): absent | |
| Security Mode: Full (smb0): absent | |
| User-allowed MDM Control: Disabled (smb3): absent | |
| DEP-allowed MDM Control: Disabled (smb4): absent | |
| SIP Status: Enabled (sip0): absent | |
| Signed System Volume Status: Enabled (sip1): absent | |
| Kernel CTRR Status: Enabled (sip2): absent | |
| Boot Args Filtering Status: Enabled (sip3): absent | |
| 3rd Party Kexts Status: Disabled (smb2): absent | |
| username@computername ~ % |
Here’s what bputil -d will return if the Startup Security settings are configured as follows:
- Reduced Security: Enabled
- Allow user management or kernel extensions from identified developers: Enabled
- Allow remote management of kernel extensions from identified developers: Enabled
| username@computername ~ % sudo bputil -d | |
| Password: | |
| This utility is not meant for normal users or even sysadmins. | |
| It provides unabstracted access to capabilities which are normally handled for the user automatically when changing the security policy through GUIs such as the Startup Security Utility in macOS Recovery. | |
| It is possible to make your system security much weaker and therefore easier to compromise using this tool. | |
| This tool is not to be used in production environments. | |
| It is possible to render your system unbootable with this tool. | |
| It should only be used to understand how the security of Apple Silicon Macs works. | |
| Use at your own risk! | |
| Current OS environment: | |
| OS Type : macOS | |
| Local Policy Nonce Hash (lpnh): 987619CF88732BB0FB0CCC476302DFE84EB1C1F7B92E8CBEC4B124D9F76B3DBACD8787E5DEBB8A3F70576639CE74F727 | |
| Remote Policy Nonce Hash (rpnh): 88EB8429C516B53BBCA49EC7C0D58C3F27F2890D23E176264B2178EE2A865327CFD06ED94834EE6FF7D145FB39245B59 | |
| Recovery OS Policy Nonce Hash (ronh): 6CF5EB6318AF551C5A23B8D3B2E4196AAA372B523E4F412C375CF6B39DCFED28F9B4E9881BF348886F9B9A14E918AA69 | |
| Current local policy: | |
| Signature Type : BAA | |
| Unique Chip ID (ECID): 0xD793810C0291E | |
| Board ID (BORD): 0x26 | |
| Chip ID (CHIP): 0x8103 | |
| Certificate Epoch (CEPO): 0x1 | |
| Security Domain (SDOM): 0x1 | |
| Production Status (CPRO): 1 | |
| Security Mode (CSEC): 1 | |
| OS Version (love): 21.1.284.5.5,0 | |
| Volume Group UUID (vuid): 2D85CA09-A291-47CA-A68A-66CB2D3BDF70 | |
| KEK Group UUID (kuid): AC09E9D5-36DC-10C9-4312-E6DAA3753224 | |
| Local Policy Nonce Hash (lpnh): 987619CF88732BB0FB0CCC476302DFE84EB1C1F7B92E8CBEC4B124D9F76B3DBACD8787E5DEBB8A3F70576639CE74F727 | |
| Remote Policy Nonce Hash (rpnh): 88EB8429C516B53BBCA49EC7C0D58C3F27F2890D23E176264B2178EE2A865327CFD06ED94834EE6FF7D145FB39245B59 | |
| Next Stage Image4 Hash (nsih): 1FAC4F6723D591DD6FAEC1DDB7D84C0AB28782096F8F2570EDA1F3CC41DECBE883A59BC4C3C962484E283F4E11549CB6 | |
| User Authorized Kext List Hash (auxp): absent | |
| Auxiliary Kernel Cache Image4 Hash (auxi): absent | |
| Kext Receipt Hash (auxr): absent | |
| CustomKC or fuOS Image4 Hash (coih): absent | |
| Security Mode: Reduced (smb0): 1 | |
| User-allowed MDM Control: Enabled (smb3): 1 | |
| DEP-allowed MDM Control: Disabled (smb4): absent | |
| SIP Status: Enabled (sip0): absent | |
| Signed System Volume Status: Enabled (sip1): absent | |
| Kernel CTRR Status: Enabled (sip2): absent | |
| Boot Args Filtering Status: Enabled (sip3): absent | |
| 3rd Party Kexts Status: Enabled (smb2): 1 | |
| username@computername ~ % |
Note: This reporting function does not require macOS Recovery and works while booted from regular macOS.
To check the Startup Security settings, the following status codes should be checked:
- smb0
- smb2
- smb3
In the Startup Security Utility app in macOS Recovery, the following settings correspond to the status codes listed above:
- smb0: Full Security / Reduced Security
- smb2: Allow user management of kernel extensions from identified developers
- smb3: Allow remote management of kernel extensions from identified developers
For more details, please see below the jump.
Updated Jamf Pro MDM lock script to add reporting feature
Previously, I’d written a script to manage sending device lock commands using the Jamf Pro Classic API. After writing it, I thought that it would be a good idea if the script could also generate a report that could be handed off to others so I forked the script and updated it to generate a report in .tsv format. Since others might prefer the original script without the automatically generated report, I left that one alone and have made the forked copy into its own script. For more details, please see below the jump.
Using the Jamf Pro API to send device lock commands via MDM to multiple Macs
Most Mac admins have had this conversation at one point or another over the course of their careers:
“$Very Important Person left their Mac behind in a cab! What do we do?”
“OK, no worries. We can send a command to lock the computer or have it erase itself. Do you want it locked or wiped?”
At that point, the admin pulls up their MDM admin console and depending on what the response was (lock or wipe), send out the appropriate MDM command accompanied by a PIN code. Once received, the Mac will then turn itself into a paperweight which does or doesn’t erase itself.
Doing these one at a time is a pretty straightforward process. For example, here’s how it looks in Jamf Pro to send a device lock command via MDM:
1. Log into Jamf Pro using an account which can send lock commands via MDM.
2. Go to the appropriate computer inventory record.
3. Select the Management tab.
4. In the Management Commands section of the Management tab, click the Lock Computer button.
5. Enter the PIN code which will later be used to unlock the Mac. If desired, you can also enter a message which will appear on the lock screen.
6. Click the Lock Computer button.
7. Click the OK button in the confirmation window.
Once the device lock command has been sent, the Lock Computer button’s text should temporarily change to Command Sent.
For a small number of machines (10 or less), the method outlined above works fine. But once you get beyond that number, this process gets time-consuming and unwieldy. Fortunately, there is also a way to use the Jamf Pro Classic API to send device lock commands. For more details, please see below the jump.
Using curl for telnet testing on macOS High Sierra and later
As part of introducing macOS High Sierra, Apple removed the telnet tool from macOS. This was part of Apple’s overall effort to improve security, as telnet does not use encryption and its traffic can be intercepted and read. However, telnet did (and does) serve a useful function as a quick way to check if it is possible to connect to a remote server on a particular port.
While there are alternative tools available for this task (like netcat), it’s also possible to still create a telnet connection on macOS using another tool: curl
For more details, please see below the jump.
Recent Comments