Finding applications vulnerable to CVE-2023-4863 (WebP)

Last week Google announced a buffer overlflow vulnerability in the WebP media format that impacts both browsers and electron applications that handle media. Most vendors have released patches to fix their software, but, how can you make sure that every application in your environment that needs to be patched actually has been?

Using Elastic and OSquery to find WebP vulnerable applications

In this blog post, we will show you how to use Elastic and OSquery to find applications vulnerable to CVE-2023-4863 (WebP).

Pre-requisites

This post assumes that you have a working elastic stack instance and OSquery agents deployed to your endpoints. This is the default configuration for all Expedient OperationsCTRL and SIEM clients, but this post should apply for anyone who using elastic for their monitoring or security solutions.

Choosing an approach

There are basically 2 approaches you can take to find and deal with vulnerable applications on your network. The more complete, but also far more time-consuming approach is to get a list of all applications on your network and then work through that list to determine if they are vulnerable. This is great for being 100% sure that you’re covered, but will take a significant investment of time. The alternate solution is to focus on a few high-priority applications that are likely to be issues and confirming that they’ve been updated to the appropriate version. This approach does run the risk of missing a less-popular app, but also allows you to get to remediating higher-risk applications immediately. It may be appropriate to combine the two solutions and remediate high-risk apps quickly and then attempt to address the long-tail. This github gist may be helpful in attempting to identify applications which may be vulnerable, or at least finding ones which utilize electron as a starting point.

The focused approach

This set of steps will allow you to find all instances of a given application on your network, along with their current version. We’re going to use Chrome for this example, but the same approach can be used for any application you decide is worth searching for on your network.

1. log in to your elasticsearch instance. If you are an expedient customer this can be done via your onelogin portal, where the icon may be labled as “SIEM” “Elastic” or “OperationsCTRL” depending on the services you are subscribed to.
2. log in to your “Default” space if needed
3. navigate to managment > OSquery
4. Select “New Live Query”
5. Choose the “Single Query” type and then select which agents you which to run the query over. In this case we will be targetting our windows hosts, but a similar approach can be used to search for applications on mac and linux, and you can also break down your search by agent policy rather than platoform.
6. Create an OSquery query that will list all machines with a given application installed in this case we are using Google Chrome but this can easily be extended to any other application you want to search for. For anyone unfamiliar, OSquery enables you to query your systems using a SQL-like language. Elastic helps to resolve the inventory and networking complexity usually involved in utilizing osquery across a large network. more information on osquery is available here. once your query is written, click “Submit”
7. Review the results of the query to see which software versions are running on each machine in your network. In this case we are looking for any version prior to 116.0.5845.187 thankfully it appears that all of the servers in our example client with chrome installed have received the appropriate auto-update.
8. If you want to make this search happen on an ongoing basis (for instance if you want to make sure that user laptops that did not happen to be online during the initial run are included) you can select “Save For Later” to create a recurring query.
9. The settings below will run the query every hour and save the results to your elastic instance for later review and to power alerts
10. Once you have saved the query you can navigate to the “Discover” section to reiew the results of each exectuion. First click on ‘discover’ from the navigation menu, then select the “logs-osquery_manager.result*” dataview (if you are not an expedient SIEM or OperationsCTRL client this dataview may not exist within your environment, in that case you should create a new dataview which uses that string as it’s index pattern)
11. Once you have selected the view, you can add the agent.name osquery.name and osquery.version fields to the table, which will give you a similar view to the one you had in the osquery app
12. Finally, from here you can click on “Alerts” to begin creating an alert that can notify you of any time a machine shows up in your network using a version of software below your minimum target. To begin this process click on “Alerts” in the upper right hand corner of the screen and select ‘Create search threshold rule’. This will allow us to create a rule that will generate an alert any time more than a set number of documents are returned by a search. In this case we’ll set the threshold to 0 so that we can get an alert for any out-of-date application.
13. Next we’ll define the query as below and then test it to ensure we’re seeing documents return as expected. Note that I’m using 118 as the minimum version here so that we can show documents in the return, but for the currently discussed vulnerability we would want to search for osquery.version < 117. This query may not work on older versions of elastic which do not have native support for automatically converting the version string in the osquery.version field into a format you can performa a numberical comparison against. In those cases an update to the current version would be reccomended, if that is not possible you may be able to leverage a runtime field to accomplish the same conversion
14. Once you have tested your query you can specify the frequency at which the search runs, as well as what action to take when the search locates a problem machine. The example below shows sending an email but a variety of chat and ITSM solutions are supported. The actual setup of a connector and definition of alert content are beyond the scope of this blog post but expedient clicents should contact the support center at support@expedient.com for assistance with those items if needed. Once your alert is defined click “Save

The broad approach

This set of steps will allow you to find all instances of a given application on your network, along with their current version. This is less useful for alerting and a bit of a firehose but does allow for getting a complete picture of applications on your network, which can then be investigated to confirm that they have been patched to deal with the CVE. In order to generate this full report you can follow steps 1-6 above, but instead of filtering for a specific program like ‘Google Chrome’ leave the WHERE clause off entirely and merely run SELECT * FROM programs

There are some other options here, like running SELECT * from file WHERE path LIKE "C:\progam files\%%"; to recursively search for all file names within the C:\program files directory and then searching against the resultant set of (tens of thousands) of results for electron.exe or other similar signifiers that an app is bundled with electron, but that search can take an extreme amount of time to recursively search every path, and symlinks may cause it to fail entirely.

One final note that in Elastic Endpoint Security customers already have significant protection from this class of vulnerabilities due to both signature and behavioral detection methods built into the endpoint security agent, which should detect and block attempts to execute a heap overflow attack like the one enabled by webp, but no protection is perfect and having multiple layers is always best.