Security Bloggers Network 
SBN

CVEs – The double edged sword

by David Michael Berry on May 19, 2024

Up until the late 1990’s, vulnerability scanners shared no common point of reference. Two different scanners could detect the same vulnerability, and it would be very difficult for security professionals to tell if it was the same vulnerability, or two different ones.

Enter the MITRE corporation and a proposed “Common Enumeration of Vulnerabilities…” calling for each vulnerability to be uniquely identifiable. No more cross referencing across multiple vendors…

This sounds simple today, but back in late 1999 this was solving a huge problem. A great example of this was in mid 2000 when the MITRE corporation deviced to tackle the backlog of “CVEs”, they received over 8,400 submissions. After cross referencing and removing duplicates, this was in fact whittled down to 562…

So why am I calling CVEs a double edged sword? As much as they are a critical component of vulnerability notifications, they are also a great place for malicious actors to start.

Take the case of Tinyproxy and CVE-2023-49606.

a security researcher from TALOS intelligence found a use-after-free vulnerability in tinyproxy
in december 2023, claiming to have contacted upstream and waited 6 months for publication.
whatever he did to contact upstream, it wasn’t effective and not what was described on either the tinyproxy homepage nor in README.md. he certainly didn’t try hard to find a responsive contact, and probably pulled a random email address out of git log and sent a mail there.

the vulnerability was made public on may 01 2024, and it took a full 5 days until i was notified on IRC by a distro package maintainer.
here’s the official write-up: https://talosintelligence.com/vulnerability_reports/TALOS-2023-1889
don’t spend too much time reading it, as it goes into a lot of quite useless details, while not focusing on the actual bug.

This CVE was given a base score of 9.8/10, which is CRITICAL. However, because of an apparently broken process, the vendor doesn’t know about it for about 5 months. However, because TALOS said they reached out to the vendor, it wasn’t classified as a zero day. Instead, it was published to the NVD giving attackers lots of time to target an estimated 90,000 publicly exposed instances of tinyproxy.

This seems like we are just giving ammunition to attackers. How can we, as developers, ensure we are remediating vulnerabilities in a timely manner?

Exploring the NVD

Let’s assume the worst case scenario. Like the tinyproxy case above, if there are published CVEs for code you are responsible for, and you are not, for whatever reason, made aware, your product, reputation and business are at risk.

The National Vulnerability Database is a great resource. Free to use and offering APIs, it seems like the logical place to start checking if CVEs are present in a given environment.

Make no mistake, attackers will already be aware of new CVEs the moment they are published, and actively looking to exploit them. Hopefully you have already been made aware of a ‘yet to be published’ vulnerability, but if not, this is your backup plan…

First, you should register to get an API key. While you can use the API without one, the public rate limit is 5 requests in a rolling 30 second window; the rate limit with an API key is 50 requests in a rolling 30 second window, so requesting an API key significantly raises the number of requests that can be made in a given time frame.

Once you’ve got your API key, you are can start exploring…

To test out the API, we can simply start with curl. Make sure you replace ‘your-api-key’ in my example below with your own. Here’s I am checking one of the two versions of Tinyproxy referenced in CVE-2023-49606 :

curl -H "Accept: application/json" -H "apiKey: your-api-key" https://services.nvd.nist.gov/rest/json/cves/2.0\?cpeName\=cpe:2.3:a:tinyproxy_project:tinyproxy:.1.10.0

This gives us a huge wall of text back that is really hard to read through. At least we know it is working…

{"resultsPerPage":2,"startIndex":0,"totalResults":2,"format":"NVD_CVE","version":"2.0","timestamp":"2024-05-20T02:04:47.633","vulnerabilities":[{"cve":{"id":"CVE-2017-11747","sourceIdentifier":"[email protected]","published":"2017-07-30T16:29:00.250","lastModified":"2020-03-31T15:15:14.910","vulnStatus":"Modified","descriptions":[{"lang":"en","value":"main.c in Tinyproxy 1.8.4 and earlier creates a \/run\/tinyproxy\/tinyproxy.pid file after dropping privileges to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account

We can clean this up a bit with python. The mjson.tool is probably perfect for this task.

{
    "resultsPerPage": 2,
    "startIndex": 0,
    "totalResults": 2,
    "format": "NVD_CVE",
    "version": "2.0",
    "timestamp": "2024-05-20T02:09:57.537",
    "vulnerabilities": [
        {
            "cve": {
                "id": "CVE-2017-11747",
                "sourceIdentifier": "[email protected]",
                "published": "2017-07-30T16:29:00.250",
...snip...

There we go, now we are getting a nicely formatted json output that we can work with. That json format could be pulled right into any SIEM. You could probably make a simple bash script of this command, schedule it in crontab, and have a log shipper pick it up if there are any new additions seen.

API Key Management – Best Practices

Keys, secrets, passwords. Never hard code these into your scripts. Once you’ve manually ran it from the command line and know it works, set your key as a variable. From the command line you can enter:

export API_KEY='your-api-key'

Then, could can call it in your bash script with $API_KEY

Further Development Options

Depending on your environment, a bash script may not be optimal. We could look at using python to grab vendor specific data. While we are at it, we can also pass the vendor name as a command line argument.

Once we’ve got our json output, we could look at making a time plot of some of the severity scores as well.

Further development of this idea is available here on my GitHub as an Open Source project: https://github.com/David-M-Berry/cve-analyzer

*** This is a Security Bloggers Network syndicated blog from Berry Networks authored by David Michael Berry. Read the original post at: https://berry-networks.com/2024/05/19/cves-the-double-edged-sword/

David Michael Berry , , , , ,