Transmission is a popular BitTorrent client for Mac, over the weekend it emerged that a version of their app available from the projects website had been swapped with another version.
This version contained the KeRanger ransomware, this seems to be the first functioning example of ransomware affecting OS X.
Below is more information, as well as a script that should alert or clean up affected Macs.
Sparkle is an open source update framework that is used within thousands of Mac apps, including my own AutoCasperNBI & AutoImagrNBI.
A vulnerability within which was recently disclosed, with an update to Sparkle issued soon after.
However, the update may take some time to reach all the apps that are on the Macs that we admin. So the below is some more detail, methods of mitigation & detection.
As mentioned before, when using Box with ADFS for SSO there are more than a few limitations.
In an attempt to overcome them, I took on Box’s API. The first hurdle was trying to connect to it as Box uses OAuth2 which massively differs from other API authentication for other API’s I’ve access such as Airwatch.
However, I’ve a method & in I’ve detailed it below. This method is used throughout all my Box API scripts.
So the past few posts detailed how to parse Portfolio’s logs to find troublesome files as well as how to restart Portfolio’s services.
Well when Portfolio is struggling to catalog files, it can generate massive amounts of temp files & folders, which if not maintained can fill the Portfolio hosts hard drive.
Not a great situation, so I’ve written the below to help automate the maintenance.
As mentioned before, we use Portfolio to archive old projects.
However since moving to Portfolio v1.x (from v11), we’ve had numerous issues. The main one has been getting the 40TB of data we host re-cataloged into Portfolio.
I’ve recently deep dived into Portfolio, & found some files that cause issues & these can be found via the logs. Parsing them allows me to “fix” the troublesome files or delete any corrupt ones.
Below is the how I’m parsing the logs.
After being nerd sniped by @unknown_err in a channel on the MacAdmins.org Slack, I started writing some client side API scripts.
This lead to an issue with 10.8.x clients connecting to my JSS.
The below is why I saw these SSL errors & a two resolutions, one client side & another server side.
AirWatch only keeps a record of the devices currently enrolled user, if the device is re-enrolled by/for someone else the details are overwritten.
Worse is that if your devices are not supervised, it’s trivial to unenroll a device. This then leaves a device record on AirWatch but with no user information.
To counter this, I’ve written the below API script that will add the enrolment users information to the devices notes. A new note is created with each scripts run, meaning that if a device is enrolled by another user, we’ll have a record & these notes are not deleted when a device is unenrolled.
This is detailed below.
We’ve started to look at enabling “Compliance Policies” within AirWatch.
However, these are scoped to “Assignment Groups” (was “Smart Groups”, another thing that seems to be mid-rename) & “Assignment Groups” do not have criteria for a devices “Enrolment Status”.
Below is an API script that I am using to automate device deletion if a device meets certain conditions & the method to the madness.
As mentioned in my previous post, I have been doing some work with AirWatch’s REST API & at the same time I have been learning Python.
This post is to show how you can access AirWatch’s REST API with Python to return devices information, as well as serve as a template for the scripts I use to access AirWatch’s REST API.
NOTE: Due to macOS Monterey's prompts when Python 2 in invoked, please review the blog post here to get the logged in user instead.
When running scripts via Jamf Pro, Munki or a launch daemon, you sometimes have a challenge to get the username of the currently logged in user.
Below has a method to achieve this, with a link to an Apple approved method.