A common task for those who manage devices is trying to get a list of things installed on a computer. Plenty of the things are apps. But increasingly there are extensions in apps that expand the functionality of those apps. This is nowhere more true than in web browsers, where it’s possible to intercept endpoints and manipulate text on the screen. Google Chrome stores extensions in /Users/<username>/Library/Application\ Support/Google/Chrome/Default/Extensions. To see a list of all of the extensions in Google Chrome, the following find command can parse through the directory, read the manifest.json, and find the name field. It’s quoted such that it will skip those that also have short_name defined and given that extensions can have multiple versions on a computer, made to be unique.
find ~/Library/Application\ Support/Google/Chrome/Default/Extensions -type f -name "manifest.json" -print0 | xargs -I {} -0 grep '"name":' "{}" | uniqTo put it in the form of a Jamf Extension Attribute:
#!/bin/sh
#
#
#
#Jamf Pro Extension Attribute used to return a list of extensions
#
#
find ~/Library/Application\ Support/Google/Chrome/Default/Extensions -type f -name "manifest.json" -print0 | xargs -I {} -0 grep '"name":' "{}" | uniq
echo "$result "
There are other fields that could be parsed out as well, and the xargs could be further refined to only include the quoted name rather than the uglier json, but this satisfies my own need. One of those fields that is important for people concerned about the security of various extensions is permissions, which can grant an extension the ability to access cameras, storage (e.g. through nmp), downloads, interact with a native app, obtain data from pastebin, etc:
"permissions": [ "activeTab", "alarms", "scripting", "storage" ],For more on how developers define those and what they mean, see https://developer.chrome.com/docs/extensions/mv3/permission_warnings/.
Some extensions are packed in crx files, but can be unpacked and analyzed. Here, it’s worth mentioning that they’re mostly just javascripts (with a manifest and some html if they produce results to the screen). As an example, one I worked on recently ( https://github.com/krypted/webauthn-inspector ) is meant to be run as an R&D tool; therefore it was never packed into crx. That one doesn’t have an update_url, as seen here:
"update_url": "https://clients2.google.com/service/update2/crx",Therefore, if you wanted to produce a list of Chrome Extensions that came from (or that didn’t come from) the Chrome Web Store, it would be possible to parse that. Having said that, removal fromt he Chrome store seems to be retroactive so it’s likely wise to practice the same scanning done on both.
The point of all this is that as systems administrators, we’ve long been concerned about the apps on devices. We now implement ZTNA tools, EDR, pipelines to SEIMs, etc, in attempts to mitigate exfiltration; however, consider this – an extension can encode (or even encrypt) information from a given web session that includes any of the stuff that the permissions in an extension gives it access to (e.g. data on a filesystem) and then POST it to an endpoint, like a lambda built last night that’s waiting for that payload – after all AWS traffic all kinda’ looks the same (especially if using something like protobuffs). That traffic can easily be masked as legitimate traffic. Therefore, any browser extension is potentially equally dangerous, if not more so, than an app on a computer, given how many web apps are integral to work.