Using Risk Insights and On-Prem Deployment For Automatic Vulnerability Remediation

Pro Tips #52

Problem: “Thank you Cyber Security Team for this really long PDF of scanned vulnerabilities from your super-expensive tool for me to fix. I don’t have time to decipher the results.”

We’ve all gotten that PDF remediation list – whether you paid for an expensive audit scan, or the cyber team dumped it in your inbox. It’s your problem now. You 1) don’t have time to fix things and don’t want to work every single weekend, and 2) don’t have time to spend on figuring out what in the world all of the stuff means in the first place. I’ve found that this predicament is one of the top reasons that lead to data breaches or systems compromise.

Solution: We have you covered. Lansweeper Sites offers comprehensive inventory, with easy to understand Vulnerability and Risk Insights

The good news is, with Lansweeper, not only do we have a complete inventory of all windows applications installed in our environment, we also have Risk and Vulnerability Insights to tell us vulnerabilities, and the assets that are affected!

The bad news is, we just uncovered 45 formerly unknown applications that should be kept current, and we either just angered the deployment admin, or just gave ourselves more work. Sure, there are third-party updating tools that work well, but they are expensive and often either complicated to use, are not granular enough for all purposes and situations.

Problem: “I know things aren’t perfect – I just don’t have the time to fix everything”

I’ll admit it – as a Systems Administrator, I often struggle with keeping third-party applications patched or updated to the latest versions… something that is crucial to do in today’s IT landscape. Most of the time, the deployment and patching admins (sometimes just myself) are too busy creating task sequences for imaging, and OS patching/deployments, let alone work on application patching.

Solution: Relax and take advantage of Lansweeper On-Prem’s Powerful Deployment Feature to Automate Patching and Upgrading Applications

Lansweeper On-Prem’s Deployment Feature to the Rescue!

One thing that often goes unnoticed is the power and granularity of Lansweeper’s Deployment feature – if you can report on it, you can pinpoint-target deploy to it. I’ve used it a lot – but still have to keep packages for third-party applications updated as new versions come out. This led me down the rabbit-hole of finding free ways to keep third-party applications updated, using Lansweeper’s Deployment feature, without having to change or modify the deployment packages in the future. During my adventure, I came across Winget and Chocolatey as really good candidates for accomplishing this task. Let’s jump in!

Case Study: Remediating Zoom Vulnerabilities

I logged on to Lansweeper Sites, and immediately saw Zoom under my critical vulnerabilities. I can easily read about the CVE and also see that there’s three assets that have this particular critical vulnerability.

Checking one of them, I see that the application is a user-profile based install because it has the person/avatar icon.

Installing/Updating Zoom using Lansweeper Deployment and Winget

The first tool I tried was winget – a Microsoft command-line tool that inventories and updates native and third-party applications. (reference: Use the winget tool to install and manage applications ).

Pros

• It comes pre-installed on windows 10 build 1709 and later, and all of the Windows 11 builds
• It inventories the local machine and shows what it can update, along with the latest version available in it’s repository
• It’s easy to use – basically ‘winget install <application>’ etc. at the command-line
• It uses the Microsoft Package Repo/Store by default, but can be modified to use other sources
• You can use Lansweeper Reporting and Deployment packages that don’t need to be modified to be current
• It’s Microsoft – who doesn’t like Microsoft??

Cons

• It’s still not a very mature product
• The number of software titles available to install or upgrade is not as large as other community-driven tools and repositories
• It (currently) only works under the current logged on user
• It (currently) triggers the UAC prompt if admin rights are needed when deploying or upgrading
• It’s hard to tell what can be a profile-based install (requiring no admin rights) or what is a system-wide install (requiring admin rights)
• The Microsoft Package Repo/Store is community-driven – it’s not 100% failsafe to use
• Installing Winget on workstations that don’t have it via GUI (App Installer) is easy, but installing it via command-line is very tricky, buggy, and usually changes as new winget versions are released
• Creating Initial Deployment Packages in Lansweeper is harder at first
• As with anything similar, pay attention and adhere to licensing requirements for any application you install
• It’s Microsoft, who likes Microsoft??

Problems Right Out of the Gate

Right off the bat, I found that winget functions only under the currently logged on user, with the executable file and environment variable (Path) using the user variable – so scanning for the file using Lansweeper doesn’t work in this scenario, and trying to install as system or another credential results in ‘file not found’ for winget.exe. Scanning HKEY_LOCAL_MACHINE is generally out of the question as keys in there either have GUIDS or have the specific winget version referenced – and I don’t want to keep updating the registry check each time winget updates to a new version.

Fortunately, Lansweeper can also scan HKEY_CURRENT_USER keys if there’s a user logged on during the scan. Adding “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths\winget.exe” with the regvalue of ‘Path’ as a scanning target will accomplish the tasks of both ensuring that winget installed, and also that a user was logged on during the scan. This registry key to scan also doesn’t need to be updated as the winget path variable stays the same for each user.

Creating a Report to Find Winget Computers that Have Outdated Zoom Versions

You can create a report that shows winget workstations/laptops that do not have the latest version of Zoom. Since we cannot tell what the latest version is, and can only report on what all is installed in our enviroment, we can make a report that finds all installations that have an older version than the maximum version found. This allows us to control the deployment by simply installing the latest version on one asset – which will automatically update the report for all assets with a version less than the one you just installed.

Since the application resides/functions at the user profile level, we will need to add a short timeframe on the report to increase the chances of having someone still logged on for the future deployment we will make.

Report: Winget Workstations Not latest version of Zoom (Past 15 Minutes)

I scanned WIN10VM1 and it immediately showed up on the report since it has an older version of Zoom – showing the current version it has, and the maximum version found in my environment. (If the other two assets above that have older versions were online and scanned, they would show up here as well)

Creating the Deployment Package that Updates (or Installs) Zoom using Winget

First, to grab the winget package name, I searched for the application here: winget.run – in this case, Zoom… which will give you the command to copy and run:

winget install -e --id Zoom.Zoom

NOTE: In this case, Lansweeper told us that it’s a user profile-based application – so this won’t require admin rights to update. System-wide applications will trigger the UAC prompt if a non-admin user is currently logged on – so it’s a deal-breaker for silent installs to non-admin users.

Now we can make a simple deployment package in Lansweeper. Winget has arguments that allow an install if the application is missing, or update if it is, making the Lansweeper deployment package very easy to set up for both scenarios. One great thing about Lansweeper’s deployment options is the ability to deploy as the logged on user – because winget actions will fail under any other circumstance.

Go to ‘Deployment’ menu option, then ‘Deployment Packages’ (note: if the deployment menu is missing, check your lansweeper permissions)

Create a new deployment package – I named mine ‘winget install or upgrade zoom.‘ Add a COMMAND step – I named mine ‘winget install or upgrade zoom.‘

Another Caveat is that if Lansweeper deploys as the locally logged on user, a command prompt window for the deployment process opens. We can however launch it minimized by launching a command line using the ‘start’ command and /min argument. This is the command I used.

start /min cmd /c "winget install --id Zoom.Zoom --accept-source-agreements -e"

Download deployment Package: winget install or upgrade zoom

Automating the Deployment Package

Next, create a scheduled deployment to key off of the above report. We need to catch these devices as quickly as it populates that report, in order to have the best chances of having someone logged on the machine for winget to run, so we choose ‘After Scanning’ for the execution plan, versus a scheduled interval. We then choose the above report to deploy to (remember to select the run mode of ‘Currently Logged on’ or winget won’t work).

Now whenever a windows device is scanned that matches the criteria, the deployment package will execute.

Another Caveat: Unfortunately, in order to minimize the installation window, you cannot get the proper exit code for winget – which means that you will get a timeout on the deployment status.

It still should work though – you can verify if it does or not by the software changes. And, the device will fall off of the respective CVE (or any other Zoom CVE’s that upgrading to the latest version will fix). If I powered and logged on to the other two machines, and lansweeper scans it, they will be remediated as well – effectively eliminating all of the Zoom CVE’s that have a patch.

Bonus: Installing Zoom with Winget

If you would like an application installed on devices, you can create a report for each asset that is missing it, use the same deployment package, and schedule a deployment pointing to the below report:

Software: Winget Workstations Missing Zoom (Past 15 Minutes)

Installing/Updating Zoom using Lansweeper Deployment and Chocolatey

Seeing the UAC prompt for many Winget app installs, and having to catch everything when the user is logged on, I moved on to Chocolatey – a similar command-line tool that updates and installs applications from repositories (local or online). (reference: https://chocolatey.org/how-chocolatey-works ).

Pros

• It’s a More Mature Product over Winget
• It’s easy to install/deploy (powershell being preferred with windows)
• It’s simple to use – basically ‘choco install’ or ‘choco upgrade’
• The community-based application library is vast and widely supported
• It is widely used with other paid and free/open-source tools that allow you to manage your own repository with package creation/etc. This is the preferred method for larger businesses.
• It has a paid business version with support, should you need it
• Great vetting process for software packages
• It works with profile-based and systemwide deployment/applications
• Based on the nuget framework

Cons

• The free/community version is community maintained – research the vetting process and use at your own risk (reference: Chocolatey Software Docs | Package Verifier Moderation Service )
• As with anything similar, pay attention and adhere to licensing requirements for any application you install
• The free version doesn’t scan the local machine’s application inventory to figure out what’s installed or not (the paid versions do)

Chocolatey is Easier

Fortunately, moving over to testing chocolatey was easy, thanks to the fact that our methodology stays the same as above – so we already know how to do it and switching is pretty straightforward. Chocolatey uses an exe (choco.exe) that thankfully is accessible outside of a logged-on profile, so we can run this behind the scenes like normal.

Deploying Chocolatey

The deployment for the windows version of Chocolatey is a powershell script maintained on their website, and is called via a powershell command to query it and execute it – so if the main installation procedure changes, we won’t have to change anything on our side. (reference: Installing Chocolatey )

To accomplish the deployment package to install Chocolatey, I decided to create a temporary folder locally, and copy the initial powershell script over and execute it. (yes, if it fails, the folder and potentially the contents of the folder are left on the machine and would require a task to clean it up, like the first two steps of the package)

First, I create the powershell script/command as given by Chocolatey to a file:

Download install_chocolatey.ps1

Next I create the deployment package, and run it under the scanning credentials.

Download Chocolatey deployment package

Add the file for scanning: C:\ProgramData\chocolatey\bin\choco.exe

Create a Report for Workstations Missing Chocolatey

Now we can make a report showing workstations/laptops that are missing that file (i.e. missing Chocolatey)

Report: Workstations Missing Chocolatey

You can now deploy or schedule a deployment to install chocolatey to anything you wish simply by modifying the WHERE clause for the criteria you want – or for example, the above report of workstations missing chocolatey.

Caveat: the free version of choco doesn’t scan the machine to know what’s on it or not, or see non-chocolatey application installations– so once you perform “choco list” it will only see itself at first. (This example I’ve deployed choco and then used it to update Agent Ransack – so now Agent Ransack appears on the list)

Fortunately, Lansweeper knows all the software both on the machine and in your entire environment, so if you wish, you can deploy the desired application with -y -n arguments to just download and do a ‘what if’ versus actually install the application – this will effectively make the app package show up in Chocolatey.

Creating a Report to Find Chocolatey Computers that Have Outdated Zoom Versions

We will need to make a report that checks for choco.exe. The good thing is, we don’t have to add the stipulation of the “scanned less than 15 minutes ago” (unless you want to) as the functionality doesn’t immediately disappear when the user logs off, like winget does.

Zoom versions sometimes have the revision in parenthesis, depending on the package you installed previously. The below report is similar to the winget report, but gets rid of that part in order to calculate the version comparisons.

Report: Chocolatey Workstations With Outdated Zoom Versions

Creating the Upgrade Deployment Package

Search for the package you need and copy the command Packages

To upgrade an application, you simply change ‘Install’ to ‘Upgrade’

Download deployment package Install Zoom with Chocolatey

Automating the Deployment Package

This is the same as the Winget Scheduled Deployment – however you can choose your plan schedule according to whatever you prefer.

The deployment cycle will work just like Winget’s version – except this deployment will show the appropriate exit code (success/fail).

Bonus Report: Choco Workstations Missing Zoom

Recreate the deployment package and scheduled deployment as appropriate, simply change the ‘upgrade’ choco command back to ‘install.‘

Chocolatey Clean-Up

Packages for Chocolatey often get left in temporary folders on local PC’s. To clean them up, you can deploy ‘choco-cleaner’) How to clear Chocolatey cache in the free version?

Bonus Software Version Chart Reports

Using the ‘Not Latest Version’ report methodology, here are some chart reports to make a software compliance dashboard that quickly shows you the different software versions, as well as the latest version installed. I will provide one for a Version/Major/Minor scenario (like Zoom – 5.17.11) as well as a standard Version/Major/Minor/Hotfix scenario (Like Chrome). You can take these reports and simply pick the appropriate versioning report and change the application name to what you want to see.

Chart Reports: Software Versions

In Conclusion

Winget is a Bust: Winget isn’t mature enough to be used to update system-wide applications yet, unless all the logged-on users happen to be local administrators on their computer. This is a much-requested fix that may be fulfilled at a future date.

Chocolatey is a ‘can-do’: Chocolatey works really well for this purpose and is more flexible in options. The community version is fine for smaller environments – however for corporate or enterprise environments, both Chocolatey and I recommend standing up a local package repository and upgrading to the enterprise level, to have more control over packages versus relying on community packages. Also, make sure that Choco either inventories/sees the existing non-choco application installation before you deploy to everything.

Lansweeper Sites‘ Risk Insights + Lansweeper On-Prem Deployment Feature Can Reduce Your Attack Surface and Increase Your Security Posture

Lansweeper’s Security and Risk Insights is an invaluable tool that shows you clear and concise risks in your environment and the steps to remediate them. On-Prem’s powerful Deployment Feature can facilitate compliance by updating vulnerable applications – no matter what method of updating you choose.

Go forth and conquer – Your overworked deployment admin and security team will thank you!