Prevent Users from Installing macOS Sierra using LANDESK Security Suite 2016

On September 20, 2016 Apple will release its next generation operating system, macOS Sierra.  While Apple may think it’s great that the Siri enabled Mac do “even more for us, so we can do more with our Mac”, as an organization, we may not be quite ready to introduce macOS Sierra into our environments.  If you you’re looking at your calendar trying to figure out if you’re going to be able finish validating your AV and your critical business applications are fully functioning with macOS Sierra, you can use LANDESK Security Suite to temporarily block the installer from running.  Going this route will give you the extra days/weeks you need to finish validating the OS without having to worry about who is going to install the update and be calling you tomorrow wondering why their VPN won’t work.

The process to block an application in LANDESK Security Suite is quite easy and should only take you a couple of minutes to setup your policy and get it deployed.

    1. Launch the LANDESK Console
    2. Go to Tools > Security and Compliance > Patch and complianceblocked-apps-menu
    3. From the menu bar, select the first button that may be titled All Types, but could be Antivirus, Blocked applications, Custom definition, Driver, LANDESK update, Security threat, Software update, Spyware or Vulnerability. Select Blocked applications if not already selected.
    4. Expand out the Blocked applications (all items) menu tree
    5. Right click on the Block folder and Add Fileadd-file-blocked-apps
    6. Insert “Install macOS Sierra.app” or whatever the final name of the OS installer is. Currently, the developer beta is “Install macOS Sierra Developer Beta.app”
    7. Check the box at the bottom that says Mac and uncheck the Windows box.blocked-apps-properties-panel
    8. If you don’t want to block the installer globally, click on the Block Status tab at the tab and select which Scopes the restriction should be applied to.block-status-tab
    9. Click OK.

Now that you have the blocked app definition created, you need to make sure the LANDESK security scanner has been enabled for blocked app scanning.  To validate this or to set this, go through the steps below:

  1. Go to Tools > Security and Compliance > Agent Settings
  2. From the All Agent Settings menu tree, click on Distribution and Patchdist-and-patch-settings
  3. Open the Distribution and Patch setting assigned to your Macs. If you have more than one, edit each one respectively.
  4. Go to the Scan Options section under Patch-only settings and make sure the Blocked applications checkbox is checked.blocked-apps-settings-copy
  5. Click Save

At this point, your machines will automatically receive the change and begin blocking the macOS installer the next time a security scan is initiated. If you created an entirely new Distribution and Patch setting, different from the one currently applied to the Mac, you’ll need to create a Change Agent Settings task.

  1. While still in the Agent Settings window, click on the Calendar/Clock icon, it’s the second one in the menu bar and then select Change Settings.change-settings
  2. Give your task an appropriate name, I named mine “Blocked Apps Agent Settings”
  3. Find Distribution and Patch from the list on the right hand side of the panel and click on the corresponding Keep agent’s current settings.
  4. Find your newly created Distribution and Patch setting and select it.change-settings-drop-down
  5. Now set your desired Task Settings (policy, push, policy supported push) and desired portal settings (required, recommended,optional). I used a policy-supported push and required.
  6. Add in your Targets
  7. Schedule your Change Settings task

That’s it.  Now, whenever someone attempts to launch the macOS Installer they’re going to get a nice Application Denied prompt like the one below.

application-denied

Silently Install Cylance Protect with LANDESK Management Suite

Overview

Cylance Protect is a next generation anti-virus product and seems to be taking the OS X world by storm.  The product marketing aspect verbiage states Cylance “blocks threats in real time BEFORE they ever cause harm.”

As a result of Cylance’s success, I’ve recently received a number of requests from customers asking how they can silently install the product with their specific, company-unique token.

Luckily, accomplishing  a silent install of Cylance Protect is a fairly simple process.  I’ve written a basic script that will accomplish the task for you.  One particular customer sent a reply back to me after using this script, stating the “Cylance deployments went great!!!”  Hopefully your deployments can go as smooth as theirs.

Furthermore, because this script leverages the LANDESK SDClient tool for the download,  you will still benefit from bandwidth controls and  you’ll be able to leverage the peer sharing if your store your package file into the sdcache folder.

For simplicity, I’ve chosen to write my package to the same folder as where I’ll write my token file.  Because the token file can be read with any text editor, I’ve chosen to store my data in a private folder; which means I will only benefit from LANDESK’s bandwidth controls, but I figured it was a good tradeoff for me.  I just didn’t want to put the license key into a folder that people might be accustom to look at.

Cylance Protect Script

Break out your favorite Text Editor (TextWrangler or XCode is what I use) and let’s get started.  I’ll break the script down into sections for easy understanding.  The first part of the script contains your obligatory declaration indicating it’s a shell script as well as some comments as to what I named the script, when I created the script and what it does. Besides the very first line, everything is optional.

#!/bin/sh
#  CylanceSilentInstall.sh
#  Created by Bennett Norton on 8/30/16.
#  This script will copy a file from the source destination and place it on the Mac into the destination folder

The next part is where you’ll set the variables used throughout the script.  You’ll need to supply the custom Cylance token, the package name, the location of where the package will be stored on your HTTP share and the location to where you’ll want to store the package and Cylance token on the client.

It’s likely that you’ll be able to leave the cylancePackageName and cylancePackageAndTokenDestination variables as is, only modifying the cylanceToken and cylancePackageLocation variables.  Just repalce the text betweent the quotes.

#Script Variables
#change these variables to match your token and desired destination paths

cylanceToken="cylanceCustomToken"
cylancePackageName="CylancePROTECT.zip"
cylancePackageLocation="http://ldserver.ldlab.org/SoftwareDist/MacPackages/Cylance/"
cylancePackageAndTokenDestination="/private/tmp/Cylance"

The next section of the script detects if the folder for where we will store the package file on the client exists and if it does not, creates it.  You may want to enhance this part of the script on your own to delete any files inside if it does exist, I have not added that in, but it may be a good idea.

#Check to see if destination exists and if not, create it

if [ ! -d "$cylancePackageAndTokenDestination" ]; then
echo "Location doesn't exist.  Creating directory"
mkdir $cylancePackageAndTokenDestination
echo "$cylancePackageAndTokenDestination created"
fi

You shouldn’t need to adjust anything within the next phase of this script.  This step is simply creating an output file of the token to be used during the install.

#Output token to file
#You shouldn't need to make any changes here

echo "$cylanceToken" > "$cylancePackageAndTokenDestination/cyagent_install_token"

The next step within our script is to download the installer package.  This piece is specifically tailored to LANDESK Management Suite and uses SDClient as the downloader.  If you don’t have LANDESK Management Suite, alter this part of the script to use CURL.

#Download package installer

/Library/Application\ Support/LANDesk/bin/sdclient -noinstall -package "$cylancePackageLocation/""$cylancePackageName" -destdir "$cylancePackageAndTokenDestination"

We now need to unzip the package file and install the package using OS X commands, which means this code is generic, not specific to LANDESK Management Suite.

#unzip package installer

unzip "$cylancePackageAndTokenDestination/""$cylancePackageName" -d "$cylancePackageAndTokenDestination"

#Install Cylance

sudo installer -pkg /private/tmp/Cylance/CylancePROTECT.pkg -target /

Finally, let’s clean up after ourselves.  The final command in our script will delete the entire /tmp folder.  

#Delete Cylance folder

rm -rf "$cylancePackageAndTokenDestination"

As I mentioned with the folder detection, you may want to do some detection logic to see if the application exists in the Application folder prior to deleting the folder, that’s up to you.

And that’s it, you now have a fully functioning script you can use to silently deploy Cylance Protect in your environment.  For ease in the copy and paste process, here is the entire script.

#!/bin/sh
#  CylanceSilentInstall.sh
#  Created by Bennett Norton on 8/30/16.
#  This script will copy a file from the source destination and place it on the Mac into the destination folder


#Script Variables
#change these variables to match your token and desired destination paths

cylanceToken="cylanceCustomToken"
cylancePackageName="CylancePROTECT.zip"
cylancePackageLocation="http://ldserver.ldlab.org/SoftwareDist/MacPackages/Cylance/"
cylancePackageAndTokenDestination="/private/tmp/Cylance"

#Check to see if destination exists and if not, create it

if [ ! -d "$cylancePackageAndTokenDestination" ]; then
echo "Location doesn't exist.  Creating directory"
mkdir $cylancePackageAndTokenDestination
echo "$cylancePackageAndTokenDestination created"
fi

#Output token to file
#You shouldn't need to make any changes here

echo "$cylanceToken" > "$cylancePackageAndTokenDestination/cyagent_install_token"

#Download package installer

/Library/Application\ Support/LANDesk/bin/sdclient -noinstall -package "$cylancePackageLocation/""$cylancePackageName" -destdir "$cylancePackageAndTokenDestination"

#unzip package installer

unzip "$cylancePackageAndTokenDestination/""$cylancePackageName" -d "$cylancePackageAndTokenDestination"

#Install Cylance

sudo installer -pkg /private/tmp/Cylance/CylancePROTECT.pkg -target /

#Delete Cylance folder

rm -rf "$cylancePackageAndTokenDestination"

At this point, you need to save your file to an OS X machine, if you’re not already on a Mac. Make sure your file extension is .sh as well, I saved mine as CylanceSilentInstall.sh.

After your shell script is saved, you then need to open up Terminal and give the script execute permissions.  Don’t skip this step or your script will not execute when using LANDESK.  Once Terminal is open, run the following command:

chmod +x /path/to/your/script/name.sh

You should now be able to test your script manually.  Find a test machine or VM, if the Mac you’re using is not viable, open Terminal on it and run the following command:

sudo /path/to/your/script/name.sh

Assuming all goes well and Cylance Protect installs, you’re ready to zip up your script and copy it to your HTTP package share.  Now you just need to build a LANDESK Mac package and deploy the package to your target machines.

Create a LANDESK Mac Software Package

  1. Open the LANDESK Console
  2. Navigate to the top menu bar, select Tools > Distribution > Distribution Packages.
  3. In the lower left menu tree, highlight My Packages or Public Packages from within the Distribution Packages window
  4. On the Distribution menu bar, press the New Package button and select New Macintosh Package.
  5. Give the package a name
  6. Provide a description as well as any metadata information desired
  7. Set the primary file to the zip file you previously transferred to your software distribution folder
  8. Fill out the Metadata details if desired, specifically supplying a logo so it shows up properly in the portal
  9. Save the package

Create a Scheduled Mac Software Distribution Task

  1. Right click on the Mac software distribution package created and select Create Scheduled Task
  2. From the network view, select and drag the desired machine(s), user(s) or query(ies) and drop them onto the task
  3. Now, right click on the task and select properties
  4. Set the desired Task type under Task Settings as to whether you want a push, a policy or a hybrid of the two types in a policy-supported push
  5. Set the radio button in the Portal Settings to either Recommended or Optional if you desire to put the package into Workspaces.  If you’d like to automatically deploy the app, select Run automatically
  6. Change the Reboot Settings or Distribution and Patch settings if desired
  7. Set the schedule task settings with the appropriate start time

 

 

 

The FBI’s 2016 Privacy Red Herring – Despite What You Read in the Media, Corporations Can Unlock the iPhones They Own

I often find myself laughing in regards to the overreactions we make in today’s world, where every opinion can be so easily spread – especially if there is any type of political current. As of late though, my laughing has subsided and I find myself much more concerned. Unfortunately for the majority of us whose opinions’ fall in the middle of the extremes, our voices are typically too quiet and often drowned out.

I write this blog today knowing it’ll probably be read by 10 people, if I’m lucky. But I do it anyway to speak on behalf of the group I feel I fall into and that is the silent majority.

And, because my blog is about Apple in the Enterprise, I want to do my part to inform the businesses that may be unaware, or wrongly informed by the media, that they can indeed get access to the data on the corporate devices they own and assign to employees.

Now, first off, before I get into the method of how to unlock an iPhone, let me express my opinion on this political side of the issue.

I personally believe the FBI’s request to un-encrypt the encrypted iPhone used by Syed Farook, the San Bernardino terrorist, is a red herring. Yes, having access to Syed’s corporate device may prove helpful, but at what cost? The FBI is using this terrorist act as a catalyst to find a way around the iPhone’s encryption for much more than just this single incident. Just look at this article in The New York Times, Justice Department Wants Apple to Unlock Nine More iPhones.

Apple is losing the PR battle on this and they shouldn’t be. This isn’t just about one phone, this is about you and your privacy. Apple is arguing its First Amendment rights regarding this, and we should all be standing behind them.

Think of all of the common individuals, like you and me, that will be put at risk if a backdoor to our personal data were made available by Apple. The FBI will not be the only entity that will eventually have access to such a tool. Even with Apple’s best and brightest working on a solution, nefarious individuals, companies and governments will find a way to use such a backdoor.

Do you remember the LA hospital that was paralyzed by hackers that made the news last week? A backdoor to our phones will only make it that much easier for all of us to have our personal information put at risk and potentially held hostage.

Donald Trump and possibly even Bill Gates disagree with me on this, depending on which report you believe. As for me, I’m against it. In the lexicon of Donald Trump himself, it is such a bad, bad, bad idea.

I place a lot of value on respect – especially regarding my privacy. And I extend that wish for privacy and respect for me, for my family, for my neighbor, for those who also live in the great state of Texas and every other individual that believes in our basic unalienable rights.

The FBI’s use of fear to override our basic rights is not a viable option – especially when the cost is the privacy of millions of individuals. Stewart Brown in his article in The Washington Post titled Has Apple made iPhones illegal in the financial industry? has it wrong, or missed a major piece of the picture. The collateral damage isn’t just a corporation (which can somewhat protect itself), it’s primarily you and me.

The argument here is that the iPhone was issued by the San Bernardino County Department of Public Health and, even although they’re not a financial institution, the law states that all financial institutions “have policies and procedures in place to monitor all electronic communication used by the firm and its associated persons.”

Seriously? We have a law to monitor all electronic communication? Good luck trying to enforce that.

With that, I don’t know the history of the law, nor do I have the full context of the law. It may have good intentions, but it compromises our privacy and puts us at a security risk. Data in motion is encrypted for our own security. We already have enough issues with our data being stolen and misused to think that we should un-encrypt all data so it can be monitored.

Really, this  whole thing is crazy and worrisome. We have laws that make us vulnerable and governments that ask companies to remove what protections we do have. We need to stand up now, before we don’t have the freedoms to protect ourselves any longer.

Luckily for us “commoners,” there are plenty of others that feel the same way we do, both public and private figures.

Now it’s time to discuss how corporations can unlock the phones they own. Apple and Google have put protections in place for corporations, giving them the ability to remotely “unlock a phone.” The caveat is simply that it must be a managed device. Any MDM (Mobile Device Management) vendor can unlock a managed device in seconds.

That’s right, in seconds. My Dad always taught me that with the right knowledge and tools any job can be easy.

Unlocking an iPhone managed by LANDESK Management Suite is literally a two-click process. All you have to do is find the phone in network view, right click on it and select Unlock.  And just like that, the phone’s password, and if applicable, fingerprint protection, will be removed.

MDM Unlock

I understand that not every terrorist is going to use a company phone that should be managed prior to a terrorizing event. However, had the San Bernardino County Department of Public Health not neglected its duty to protect itself by managing the devices it assigns out to its employees, we wouldn’t even be having this conversation. The county would have been able to unlock the phone for the FBI, and the FBI would still be trying to come up with some other excuse to tear down our privacy protections.

As a people, both as public and private individuals, we shouldn’t be attacking Apple for having put in place privacy protections for all of us. We should be focusing on the negligence that is putting us in the tough spot to begin with, in which the proposed solutions steal away your own rights to privacy.

 

 

Hard Drive Encryption for Your Macs is Free From Apple – Why Aren’t You Leveraging its Protection?

2014 and 2015 have been monumental years when it comes to data breaches and the costs incurred by the business entity for those breaches. According to a study released by IBM and the Ponemon Institute, the average total cost of a data breach increased to $3.79 million dollars in 2015.

While Sony Pictures Entertainment, JPMorgan Chase, Target, Ashley Madison, and the U.S. government are high-profile customers, it only takes one forgotten laptop in the back of taxi cab or left in the airplane back pocket to put you in the sites of a possible attack.

Now, data breaches have many causes. Hacking, whether by brute force or social engineering (think skimming or phishing attacks) incidents are by far the most popular means for getting to your personal or corporate data. However, in second place, coming in at 15% of all data breaches, is the category of employee negligence – of which is included lost/stolen devices.

What’s crazy is that while you can’t prevent people from being forgetful, or prevent humans from stealing from one another, you can prevent your data from being accessible if one of your devices ends up in this situation.

So how is that done? It’s done by encrypting the hard drive so it’s contents cannot be read without the decryption key; which is your logon password, so it’s not like your end users have to remember anything unique. And, conveniently for you, built directly into OS X, for free, is FileVault – the premier hard drive encryption tool for your Mac. All you have to do is enable it and reap the benefits of its protection.

Without an encrypted drive, all one would need to read all of the data from a stolen/lost laptop would be a screw driver, a $20 hard drive enclosure, a computer and about 30 minutes of free time. Do you know of anyone that might have all four of those ingredients?

We all do, right? Retrieving data from a device is not rocket science.

Okay, knowledge of why you need to encrypt your hard drives is only going to take you so far. How to encrypt every Mac you have is just as important, if not more so. Built into LANDESK Security Suite 2016, released on Friday, February 5th, is the capability to not only enable FileVault remotely, but to capture the backup encryption key just in case your users forget their logon password—and we all know that for some people, remembering their password is as complicated as rocket science.

Follow the brief steps below or watch this walk through video to learn how to leverage LANDESK to encrypt your Macs and manage your FileVault keys. Then, sit back and rest a bit easier knowing when the next laptop from your corporation is lost or stolen, you’ll know the data is encrypted and safe from prying eyes.

  1. Launch the LANDESK Console
  2. If not yet done, upgrade the Mac agent to the 2016 LANDESK agent
  3. Select Security and Compliance and then open the Patch and Compliance Window
  4. For convenience, change the ‘All Types’ dropdown button to Security Threats
  5. Find the security threat ‘FileVaultActivation-10 ID’, right click on it and create a Repair task
    • Note: Ensure you’re downloading Apple Mac Security Threats in the “Download Updates” portion of the patch manager tool if you don’t see the FileVaultActivation-10 ID.
  6. Apply your desired task settings, decide if you’re going to make it required or make available via LANDESK Workspaces, add your targets and schedule the task.
  7. Once the client devices receive the task, a prompt will display letting the user know encryption has been enabled asking the user to restart so that the process can commence at the next login event.  FVEnablementOnly
  8. At the next login event, the active user will be enabled for FileVault. The machine will then restart.EnablingFVOnly
  9. Login to the pre-boot screen with the authorized account.
  10. The authorized user can now use the machine, however it may be a bit slow as the encryption processes finishes. Status can be seen by going to Settings > Security & Privacy and clicking on the FileVault tab.
  11. If additional users on the device need to be enabled, the first FileVault authorized user will need to enable the accounts by clicking on the Enable Users button on the FileVault tab in Security and Privacy. The account passwords for the additional accounts will need to be entered to complete this step.
  12. If desired, run an inventory scan to see the updated FileVault status in inventory. This step is optional as the regular inventory scanner schedule will send the updated status change automatically.
  13. Return to the LANDESK Console and go to Configuration > Client Data Storage to view the key stored for the client.CDS

How to Patch Mac App Store Apps with LANDESK Patch’s Manual Definitions

Introduction

Patching OS X applications can be quite the adventure.  Due to digital rights management, Apple ID’s and user agreements, not all content found inside of Apple’s Mac App Store for OS X is available for redistribution by LANDESK.  This white paper will discuss how an application installer found in the Mac App Store (MAS) can be captured and used to patch applications deployed on your OS X devices.

Overview

LANDESK has a team of engineers that write content for many of the common applications in use on the OS X platform.  This content can be downloaded by anyone with a LANDESK Patch Manager or LANDESK Security Suite license.  However, unless the application is patched by Apple’s update servers, the content provided by LANDESK will have a “manual” appended to the title of the definition file.

Manual Content.png

This “manual” indication in the title is to inform you that LANDESK cannot redistribute the content for that particular object. In order to do more than just detection for that vulnerability, the application will need to be manually downloaded.  By reviewing the Description tab on the Properties panel, you’ll find the note: “The patches for these applications should be downloaded from the Apple network by the LANDESK administrator. The respective patches should then be compressed into individual packages for each patch and named as *-version.zip (for example, Pages-5.0.zip). The last step would be to copy the zip package to the path \\coreservername\ldlogon\patch” or wherever your patch repository is located.

 

Pre-Requisites

The LANDESK administrator will need to have access to an OS X device that has purchased the application that is intended to be patched, but that does not have the application currently installed.  A VM set aside just for downloading Apps may be an efficient method for the ongoing patch process.

Enable Debug Mode for the Mac App Store (MAS)

When an application is downloaded from the MAS, the installer file is downloaded, executed and then promptly removed.  By enabling debug mode for the MAS, we can create a link to the downloaded installer(s) allowing for future use on more than just the machine currently downloading the app.

  1. Quit the Mac App Store if currently opened
  2. Open Terminal and run the command ‘defaults write com.apple.appstore ShowDebugMenu -bool true’

EnableDebug.png

Note: To disable debug mode, use the following command: ‘defaults write com.apple.appstore ShowDebugMenu -bool false’

Download the Installer for the App to be Patched

Once the debug mode is enabled, it will be possible to capture the download installer file for later use in patching.

  1. Launch the App Store App (notice you should now have a Debug menu item) and navigate to the Purchased tab.  Sign in if prompted.
  2. Select the app to be patched and click Install
  3. Once the install process shows visible progress in the download process, hit the pause button
  4. From the Debug menu, select the option Show Download Folder
  5. Finder will open and you’ll need to navigate inside the com.apple.appstore folder
  6. Locate the folder with a string of numbers, this should be your app, and navigate inside of it

RandomNameAppStoreApp.png

You now need to create a hard link between the randomly named download to a file name and path of where to store the installer.  You’ll do this by opening Terminal and use the ‘ln’ command followed by the path of the installer from the Mac App Store and then the path to where you want to save your copy of the installer that won’t be deleted as soon as . The easiest way to enter the path of the randomly named installer is to drag and drop it into terminal after typing ‘ln’

  1. Launch Terminal and type ‘ln /path/to/macappstore.pkg /path/to/savedinstaller.pkg’                            HardLink.png
  2. Return to the Mac App Store purchased tab and resume the download
  3. When the installation for your app finishes, you’ll have a signed installer from Apple to use to update your fleet of Mac devices

Automating for Multiple Concurrent Downloads

If the manual linking process described above seems a bit burdensome when in need of downloading many applications, Max Schlapfer has created a script to not only automate the creation of the hard links, but it also has the capability to download multiple files at once.  To download Max’s AppStoreExtract script, seehttps://github.com/maxschlapfer.  These next steps are not requisite, if you have the installers you need to patch, skip forward to Configuring the Output Installers for LANDESK Patch.

Note: You do not need the Debug mode enabled for the Mac App Store, as outlined above, for this script to work.

  1. Download Max’s script from Github and extract it to a folder location of choice                                                 AppStoreExtractGitHub.png
  2. Open terminal and execute the script by typing in ‘./path/to/script/AppStoreExtract.sh’ and hitting Return
    1. Note: Do not run this script as root.                                                                                             AppStoreScriptWaiting.png
  3. Launch the App Store App and navigate to the Purchased tab.  Sign in if prompted.
  4. Click Install on all of theApps you want to create installers for and wait for them to complete the install process
  5. When the installation process has finished, return to the Terminal window and hit any key to finish the script.  When asked to finalize the packages, type Y.TerminalAppStoreExtractProcess.png
  6. The script will name the output files according the product and version and then convert them to DMG files and store them in the /Users/Shared/AppStore_Packages folderOutputAppStoreExtract.png

Configuring the Output Installers for LANDESK Patch

There is a good chance that LANDESK has already created the definitions needed to properly detect and repair the application of choice, you simply need to zip up the installer and name it according to what the definition file expects.  Refer to the description tab for each piece of content for specifics, but in general, you’ll want to name the zip file by the productname-version.zip.  If LANDESK has not already created the content, feel free to reach out to your local support representative and request the content be generated. Alternatively, you can create your own custom definitions as well.  See https://community.landesk.com/support/docs/DOC-6041 for more information on creating your own vulnerability definitions.

  1. Rename each installer according to productname-version.zip as defined in the definition file.  Make sure artifacts such as .dmg or .pkg are removed from the zip file name as well as any underscores “_” where LANDESK patch content may be expecting a dash “-.”    If you want to verify you have properly named your installer, go to the properties panel for the detection rule within the vulnerability definition and highlight the Patch Information menu tree item. TheUnique Filename provided will tell you the exact name it is expecting.                                     UniqueFileName.png
  2. Copy the installers to your LANDESK patch repository
    1. Typically, the path to the LANDESK patch repository will be \\coreservername\ldlogon\patch.  However, this can be changed by an administrator.  If you’re unsure, go to the Patch and Compliance tool within the console and hit the Download Updates icon from the tool’s menu bar.  From there, click on the Patch location tab and validate your UNC path.

Note:  The individual patch content will not show as downloaded until the next scheduled patch download or if you manually attempt to download the patch.  At that point, it will see the file and change the status to yes.

Repair Your OS X Devices Using LANDESK Patch

Now that you have the installers for your content, you can repair your devices by either scheduling a repair task or by setting the content to be repaired by Autofix.

Autofix

  1. Open the Patch and Compliance tool within the LANDESK console
  2. Ensure your desired content is in the Scan folder
  3. Right click on the definition and select Autofix > Enable global autofix or Enable autofix for all scopes.AutofixSelection.png
    1. If you prefer to only enable autofix for a couple of scopes, go to the prosperities panel, select the Autofix tab and  check the boxes for the desired scopes.ScopeSelection.png

For more information on Autofix, see: https://community.landesk.com/support/docs/DOC-33690

Scheduled Repair

  1. Open the Patch and Compliance tool within the LANDESK console
  2. Ensure your desired content is in the Scan folder
  3. Right click on the definition and select Repair
  4. From the Add targets select on the Repair settings task panel, select Add all affected computers                              RepairTaskTargets.png
  5. In the Tasks settings panel, set your desired Task type.
  6. Ensure the Display in portal option for the portal settings panel is set to Run automatically (unless you want your users to update their own apps)
  7. Schedule the task to start when desired from the Schedule task panel
  8. Save the task

 

For additional information on how to use LANDESK Patch Manager, see: https://community.landesk.com/support/docs/DOC-32250

Does Your Mac Patch Process Rely Solely on Hope and Prayer?

The Hope and Prayer of a Contractor

My family and I love to play pickup basketball games together in our backyard. We do however, live in Texas, and as you probably know, Texas summers are hot. Due to the heat, we decided it would be wise to install an overhead light on the basketball court so we could play hoops when the sun goes down. Since I’m not electrician, we contracted out the work in early February.

Well, it’s now the middle of August and we’re still waiting for the electrician to finish his job. Last week I was pressing the general contractor for a commitment for a specific day for the work to be done. Let’s just say his response was not exactly what I was expecting.

“He said next week for sure. Praying that happens.”

Now, I am a very religious individual and strongly believe in the power of prayer. I even believe prayer should be invoked on behalf of our businesses and livelihood.

However, I believe prayer is a tool to be used after we’ve done everything possible on our end to bring about our desired outcomes. I do not believe prayer should be a tool used as a crutch to overcome our own lack of effort and planning (James 2:20). A general contractor, in my opinion, should be able to effectively work with his team and his subcontractors to gain commitments and delivery dates without doing anything more than throwing it onto the wings of hope and prayer.

How Does this Relate?

So what does this story have anything to do with patching processes for Macs?

To that, I say, good question. In response, I’ll answer your question with a question. Are you secretly relying solely on hope and prayer that the Macs in your environment will simply be self-managed by the savvy users that employ them? After all, Mac users want to be treated differently, right?

I was on a phone call again on Friday and asked the IT administrator if they have just Windows devices employed in their environment, or if they have anything else such OS X devices and/or Linux devices that he would need to manage. His response is about as common as it gets.

“We have some Macs, the total number of which is growing, but it’s mainly just our marketing team and several of our executives. At this time, we don’t manage them.”

You don’t manage them? Wow! How often do we hear the idiom “a chain is only as strong as its weakest link?” Why do organizations invest so much time and money in their infrastructure when they’re only going to patch a percentage of the total attack vectors, leaving the remaining portion to chance…or was that to hope and prayer?

The Vulnerability Data

Common Vulnerabilities and Exposures is reporting that OS X has 178 new security vulnerabilities published in 2015 alone. To compare, that’s more than 2013 and 2014 combined and we still have a third of the year to go – this data only includes vulnerabilities released up until the first week of July. It doesn’t account for the latest zero-day vulnerabilities being reported this week here and here. Furthermore, of the 178 vulnerabilities, 25 of them allow the attacker to gain additional privileges on the compromised system. To put that into perspective, 25 new privilege vulnerabilities is greater than all previously reported exploits of the same type over the last eight years combined!

NumberofVulnerabilities GainPrivileges

Hoping and praying an attack doesn’t surface, through the management process of “look the other way”, is incredibly risky and could potentially cost you millions. Infosec Institute is reporting that in 2013 “the average annualized cost of cybercrime incurred per organization was $11.56 million, with a range of $1.3 million to $58 million.”

So What Do I Do?

Sounds like it’s time to quit relying on just hope and prayer and to put forth some action. So where do you start? First and foremost, obtain a tool that allows you to scan your managed machines against a known vulnerability list that you can control, and ensure your machines scan on a frequent basis and then centrally report up their results.

Just knowing where you stand against the 178 new vulnerabilities is a great start. It will also give you the information you need to make intelligent business decisions.

Notice that I mentioned you will now have the data to make intelligent business decisions. Blindly patching all 178 vulnerabilities without properly testing them, while better than completely ignoring them altogether, is not moving forward intelligently. If you were to blindly patch everything, there’s a good chance you could break a critical business process which in turn could potentially affect your organization to the tune of millions of dollars as well. So be careful and use caution.

Many security pundits will encourage you to test and evaluate new patches in phases. Apple doesn’t have a “Patch Tuesday” so you’ll need to be constantly vigilant about when Apple releases new security updates. Hopefully the tool you use to scan your machines can notify you of new content. If not, keep on an eye on Apple’s Security Updates page found here.

I personally like to break down my patch process into five distinct phases:

  • The lab test phase
  • The smaller, more controlled initial test pilot phase
  • The larger, greater reach secondary pilot phase
  • The mass rollout phase
  • The exception handling phase

The size of your organization and the resources available may force you to adapt, and that’s alright. It’s the checks and balances part that is critical.

The Lab Test Phase

Inside the lab test phase, you should have replica environments for the different types of configurations you have deployed in your environment. Keep them up to date with reality. Make sure when you update your critical business applications in production that you also update your test lab machines. Almost as important, make sure you downgrade the business critical applications to the current release version when testing new security content. Don’t think just because the Apple security update works with version 2.2.x of your business app that it will also work with version 2.1.x.

In order to advance out of the lab test phase, ensure that your exit criteria has been defined and that it meets your success metrics. These metrics may be as simple as defining a machine has been patched, it still can be logged into and that the critical business applications can still be opened. You may also decide to get much more granular, that’s up to you and your organization’s tolerance for risk. What’s important is that a set of defined exit criteria has been established. You can’t be successful if you don’t know what success looks like. Once you have success, document the status of your exit criteria with times and dates and move on.

In regards to timing, when new content comes out, you should be immediately testing against your lab machines.

The Smaller, More Controlled Initial Test Pilot Phase

Once you’ve validated the content against your lab machines and have met your successful exit criteria, move on to a focused pilot group. This is stating the obvious but members of this pilot group need to be using machines that match the type of devices deployed to your entire corporation. That may mean you’re going to need to find dozens of different types of users to match finance, engineering, marketing, etc. Understanding your different user types is critical. Furthermore, these individuals need to be flexible and must be willing to communicate when things don’t work. Build feedback channels into your process that are easy to use. If something breaks, the pilot test group user should know exactly how to contact you with the information you desire.

The next obvious step is to notify the pilot group that patches are coming so they know to be alert and aware.

Just like with the lab test phase, define your exit criteria and document it. Not everyone in your pilot group is going to be available 100 percent of the time. You may have to settle with a 100 percent approval rating from your test group, or up to seven business days. Define what success is, establish the process, and once you can quantify whether you’ve hit your metrics, move on. If you can’t meet your success metrics due to issues, single out the offender and proceed with the rest while you move the offender into the exception handling process.

Ideally, you should be able to wrap up this phase within three to 10 business days from the initial content publication date.

The Larger, Greater Reach Secondary Pilot Phase

The larger pilot phase is nearly identical to the first, only this time increasing the amount of participants. Maybe you move from 2 percent of your machines to five to 10 percent of your machines. Due to the greater number of participants, you may need to be more lax in your exit criteria. You may decide that if 75 percent of your participants approve, or if seven business days have transpired, you have sufficient information to move on. When things break, people complain. When it comes to patch, no news is often good news, that’s why we can put time down as a successful metric. It’s not perfect, there are always those applications that are run on a periodic basis, but it’s a start. Just document were you stand and move on.

Again, just make sure the proper notification is going out to your pilot group so they know to be aware and provide them with dates they need to respond by. Ensure the proper channels are in place so the pilot users can communicate the good and the bad.

This phase should put you two to three weeks out from the content’s publication date. Remember, time is not on your side. The key is to be disciplined, yet focused on getting the content released.

The Mass Rollout Phase

Here comes the fun part, let’s roll out the patch updates to the rest of the organization. While no process will prevent every potential bad outcome, enter into the mass rollout phase with confidence. It won’t hurt to hope and pray at this point either, but at least you’ve done your part.

The key to this portion is to capture the feedback and learn. If a certain individual or group is adversely affected, understand how he/she/them differ from your pilot test groups. Consider adding in this individual or a member from the group into your pilot phase for future testing. The outspoken, high-energy individuals are usually willing to participate in such programs, so bring them in.

Make sure you’re using your patch tool to track the progress. You should be able to hit a pretty high success criteria within days of release.

Where I see most companies struggle here is with off-network devices. Ideally your patch tool should be able to handle the delivery of a patch regardless of where it sits, whether on or off the network. If it doesn’t, you may want to re-evaluate your tool. Machines are always going to be offline or off network, sometimes for days, weeks, months or even indefinitely. Build your process around the exceptions and you’ll be successful.

The Exception Handling Phase

Use this phase to deal with all of the one-off scenarios. It may be a single system that causes you grief. It may be a patch that will not apply. It may be hardware that fails months after patches have been applied, making you vulnerable to items you thought you had patched months ago.

Every scenario is going to be unique and require a different set of steps to troubleshoot. Figure out what you can and then re-insert it back into your patch workflow when it’s ready to be re-evaluated. For me, what’s important, is to document, learn and use what you can to enhance your established patch process so that with each iteration it gets better and better.

Conclusion

Using your patch tool, you should be able track the trends and understand how quickly you can turn around a patch. What may take 35 days can be gradually improved to 30 days, then into the 20s, the 10s and maybe even into single digits. The size of an organization will have such an impact on turn around that comparing against others is not as important as comparing against yourself.

Now, after implemented your newly minted and customized patch process, continue to hope and pray what you’ve done is enough. Zero-day threats will always be with us, having 100 percent prevention is nigh impossible. But having done all that you can do and covering what is in your control, you can now use that prayer and hope  to overcome what is outside your control.

Force LANDESK Antivirus for Mac to Update its License File

I recently had to install LANDESK AV directly from the Mac Client package on a machine, but unfortunately, the machine was not connected to the Core server’s network nor the Internet.  I’m not sure if that is a required step in order to pull down the license file or if it was just circumstantial, nonetheless, I couldn’t get the client to pull down the license even after I connected it to the Core’s network and to the Internet.

As I always do in these types of situations, I pulled up my browser and hit the LANDESK Community site.  I quickly found an article titled How to refresh the Mac AV license key on client machines and was quite hopeful the answer would be found therein.  I was in luck!  The prescribed solution written by Bryce worked like a champ.

Within minutes I had a custom script written in the Manage Scripts portion of the LANDESK Console, a task created and targeted with a successful result returned.  The Mac I was working with was able to update to the latest pattern files letting me get back to the problem at hand.

Now, while the script did indeed work as described in the how to community article, the ldkahuna command to download files is old and outdated within the modern LANDESK Mac agent.  It works, it hasn’t been completely deprecated, but there is a better way and that better way is to use sdclient.

Using sdclient instead of ldkahuna has a number of advantages.  First off, it has access to the bandwidth controls built into the agent.  It also has a -dest switch allowing you to not only download but to specify the location of where you want the files to be placed.  Furthermore, rumor has it, that in the next LANDESK Management Suite release, sdclient will become peer aware like the Windows agent.

Who wants to use the old stuff anyway, when you can use the new stuff?  If Steve Goodrich uses it when he needs to download stuff, I’ll use it as well.

The best part, the switch is quite straight forward.  Let’s look at how we would write it with ldkahuna and how it would be written with sdclient.

Old Code:

REMEXEC01=ldkahuna http://%CUSTJOBHOSTIP%/ldlogon/avclient/install/key/ldav.key</pre>

New Code:

REMEXEC01=sdclient –noinstall –package http://%CUSTJOBHOSTIP%/ldlogon/avclient/install/key/ldav.key</pre>

Pretty simple change, right?  I thought so.  Now just schedule out your Managed Script and target those stubborn Macs that won’t update their license file.  In short order, you’ll be back in business.

How to Recover from “Redirect-AVScanner.com” or Other Malware Highjacking Safari on Mac OS X

Over the weekend I was troubleshooting a machine in which Safari was being highjacked by a visual pop up and audible voice indicating the machine had a MAC iOS Alert.  

The malware was completely taking over Safari and wouldn’t allow any other tab to open.  The message on the screen essentially said there was a security update to fix an SSL connection and said I just had to call the “Apple Support” number.  Even if you hit the OK button, you were stuck.  The only thing that could be done was a Force Quit on Safari.  

Red flag alert!  Don’t call the number. 

I know those of you who are LANDESK admins won’t do it, but for anyone else that may stumble upon this article, DO NOT call the number on the screen and DO NOT pay them any money.

For information on how to remove Mac Defender, I looked at Apple’s article on removing Mac Defender but it was for 10.6 and earlier and didn’t help much.  My machine was on 10.10 so I kept searching and ended up using this article on StackExchange. 

Basically, I deleted the following files:

  • ~/Library/Saved\ Application\ State/com.apple.Safari.savedState
  • ~/Library/Safari/LastSession.plist
  • ~/Library/Cookies (all cookies in the folder)

I then relaunched Safari and all was well, Safari was back to normal. 

If you’re a LANDESK customer and want to deploy a script to remediate more than one machine, copy the code below into a shell script.  Just set the execute permissions on it and copy it to your distribution repository.

#!/bin/sh
#&lt;span class="Apple-converted-space"&gt;  &lt;/span&gt;Redirect-AVScanner Malware Removal.sh
#August 3, 2015
rm -rf ~/Library/Saved\ Application\ State/com.apple.Safari.savedState
rm -rf ~/Library/Safari/LastSession.plist
rm -rfv ~/Library/Cookies/*

Since these folder locations are inside the user’s profile, creating a deploy package may be a bit more difficult if multiple profiles exist on a single machine.  It may be best to create an optional package and publish into Workspaces.

To create your Workspace package, use the following steps:

  1. Open the LANDESK Console
  2. Navigate to the top menu bar, select Tools > Distribution > Distribution Packages.
  3. In the lower left menu tree, highlight My Packages or Public Packages from within the Distribution Packages window
  4. On the Distribution menubar, press the New Package button and select New Macintosh Package.
  5. Give the package a name, I used #1 MacDefender Removal
  6. Provide a description if desired
  7. Set the primary file to the zip file you previously transferred to your software distribution folder
  8. Fill out the Metadata details if desired, specifically supplying a logo so it shows up properly in the portal
  9. Save the package

With the malware removal package created, just schedule a task for deployment.

  1. Right click on the malware removal package created and select Create Scheduled Task
  2. From the network view, select and drag the desired machine(s), user(s) or query(ies) and drop them onto the task
  3. Now, right click on the task and select properties
  4. Set the desired Task type under Task Settings as to whether you want a push, a policy or a hybrid of the two types in a policy-supported push.
  5. Set the radio button in the Portal Settings to either Recommended or Optional.  You’ll also want to check the box for “Allow users to run as desired (keep in portal after selected) so they can execute the script multiple times if need be.
  6. Change the Reboot Settings or Distribution and Patch settings if desired
  7. Set the schedule task settings with the appropriate start time
LANDESK Workspace MacDefenderRemoval Screenshot
LANDESK Workspace MacDefenderRemoval Screenshot

How to Remove Adobe Flash with LANDESK Management Suite

Do you think it’s time to remove Adobe’s Flash Player from your OS X boxes?  One glance at the Common Vulnerabilities and Exposure’s latest update should get you motivated!

If that doesn’t work, check out Ars Technica’s latest blog on the details of the two 0-day exploits.

It is passed time to remove Flash.   Get it out of your environment and get it out now.

Luckily, removing Flash is not very difficult.  With the simple script below, Flash can be quickly relegated to the depths of trash bin, never to be recovered.

#!/bin/bash

UninstallFlash=(

"/Applications/Utilities/Adobe Flash Player Install Manager.app"

"/Library/Internet Plug-Ins/Flash Player.plugin"

"/Library/Internet Plug-Ins/flashplayer.xpt"

"/Library/PreferencePanes/Flash Player.prefPane"

"/Library/Receipts/Adobe Flash Player.pkg"

)

for FlashObject in "${UninstallFlash[@]}"; do

rm -rf "${FlashObject}"

done

If you’re a LANDESK customer, you can create a package file out of the script if you would like, following the steps outlined in the previous blog post on the “The 3 Step Process of Bundling Scripts with Pkgbuild for a Payload-less Package Deployment

For our Adobe Flash instance, an abbreviated version of 3 steps will be as follows:

Step 1 – Create a “Remove Adobe Flash” folder structure and build script for the PkgBuild utility.  Insert the code below for your “package_the_script.sh” script, changing your identifier as needed.

#!/bin/bash

PKG_ID=Remove_Adobe_Flash

sudo pkgbuild --identifier com.appleintheenterprise.$PKG_ID --nopayload --scripts ./scripts ./$PKG_ID.pkg

 

Once saved, run the command “sudo chmod a+x package_the_script.sh” to ensure execute permissions are set.  You may also want to sign the package if using Gatekeeper.

Step 2 – Copy the Uninstall flash script in the beginning of the article into the Scripts/postinstall file

#!/bin/bash

UninstallFlash=(

"/Applications/Utilities/Adobe Flash Player Install Manager.app"

"/Library/Internet Plug-Ins/Flash Player.plugin"

"/Library/Internet Plug-Ins/flashplayer.xpt"

"/Library/PreferencePanes/Flash Player.prefPane"

"/Library/Receipts/Adobe Flash Player.pkg"

)

for FlashObject in "${UninstallFlash[@]}"; do

rm -rf "${FlashObject}"

done

Step 3 – Create the Remove_Adobe_Flash Package by opening Terminal and browsing to wherever you saved your package_the_script file.  Once there, type “sudo ./package_the_script.sh”.  So doing should create your uninstaller package.  Now, zip the pkg file and copy it to your software distribution share and build your LANDESK deployment package.

  • From the LANDESK Console, open Tools > Distribution > Distribution Packages
  • Inside the menu tree, highlight My Packages or Public Packages and then select the New Package button on the menubar and select New Macintosh Package
  • Give the package a name, description and point the primary file to the zip file created previously
  • Fill out the Metadata details if desired
  • Save the package

To create a task to deploy your LANDESK package, walk through the steps below:

  • Right click on the package created and select Create Scheduled Task
  • Target the desired machine(s), user(s) or query(ies)
  • Right click on the task and select properties
  • Set the desired Task type under Task Settings
  • If you desire the end user to be able to initiate the task, set the radio button in the Portal Settings to either Recommended or Optional, otherwise set it to Required and it will automatically begin the upgrade during the next maintenance window
  • Change the Reboot Settings on the task to one that forces a reboot
  • Schedule the task

To validate your success, browse to http://www.adobe.com/software/flash/about/ on the machine and you should see that the plug-in is missing.