Vulners Linux Audit API: Security Bulletin Publication Dates in Results

Hello everyone! In this short episode, I want to talk about the new feature in Vulners Linux API.

Alternative video link (for Russia): https://vk.com/video-149273431_456239092

Linux security bulletin publication dates are now included in scan results. Why is it useful?

A few words why this Linux Audit API is needed. You collect a list of packages installed on a Linux host and the version of the operating system for this host. Send it to the Vulners API. As a result, you get a list of detected vulnerabilities. The detection rules are based on the Linux distribution’s security bulletins, so they work accurately. Vulners supports almost all popular Linux distributions, that’s why this API is very useful for security analysis. If you want more details, you can check out the episode “Vulners Linux Audit API for Host Vulnerability Detection: Manual Auditing, Python Scripting and Licensing“.

Now, in the results, we can also see the publication date of the security bulletin. Here is an example for one package:

import requests
import json

packages = '''snapd 2.42.1+18.04 amd64'''

package_list = packages.split("\n")
token = "TOKEN"
data = {"os": "ubuntu",
        "version": "20.04",
        "package": package_list,
        "apiKey": token}
response = requests.post('https://vulners.com/api/v3/audit/audit',
                         data=json.dumps(data))
print(json.dumps(response.json(), indent=4))

Output:

{
    "result": "OK",
    "data": {
        "packages": {
            "snapd 2.42.1+18.04 amd64": {
                "USN-4424-1": [
                    {
                        "package": "snapd 2.42.1+18.04 amd64",
                        "published": "2020-07-15T00:00:00",
                        "providedOSName": "ubuntu",
                        "matchedOSName": "ubuntu",
                        "bulletinOSName": "Ubuntu",
                        "providedOSVersion": "20.04",
                        "bulletinOSVersion": "20.04",
                        "providedVersion": "2.42.1+18.04",
                        "bulletinVersion": "2.45.1+20.04.2",
                        "providedPackage": "snapd 2.42.1+18.04 amd64",
                        "bulletinPackage": "UNKNOWN",
                        "operator": "lt",
                        "bulletinID": "USN-4424-1",
                        "cvelist": [
                            "CVE-2020-11934",
                            "CVE-2020-11933"
                        ],
                        "cvss": {
                            "score": 4.6,
                            "vector": "AV:L/AC:L/Au:N/C:P/I:P/A:P"
                        },
                        "fix": "sudo apt-get --assume-yes install --only-upgrade snapd"
                    }
                ],
...

This is a small improvement, but a very useful one.

  1. We can find the oldest bulletin and guess when the host was last updated. Accordingly, it can be concluded whether IT administrators comply with the agreements on the regularity of patching or not.
  2. If IT administrators patch Linux hosts using a local Linux repository and for some reason this local repository is updated with a delay, we can conclude which vulnerabilities cannot be fixed now. And for example, do not take into account the vulnerabilities published in the bulletins over the past week. The delay in updating packages in the local repository may be the result of some technical problems, but it can also be a precaution. For example, let’s imagine a situation: the maintainer of some opensource project will try to add malicious functionality to it. In this case, it is better not to install updates immediately. We can wait a bit, maybe it will become known and appear in the media, and we can react to it. I talked more about this topic in the episode about malicious open source and the cost of using someone else’s code.

So, it’s a very useful feature, I recommend paying attention to it and using it. I am also going to use it in my open source project Scanvus. Many thanks to the Vulners team for the very fast implementation of my feature request!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.