Vulnerability Indexing & Assessment Logs (VIAL)

Background

In 2016, there was some dissatisfaction within the cybersecurity community with the drawn-out nature of the CVE allocation and publishing systems. This led to community-led proposals for CVE alternatives including the Openwall Vulnerability Entries (OVE) and the now-abandoned Distributed Weakness Filing (DWF) systems.

Both of the above systems aimed to address the speed of Mitre's assignment and verification process: OVE did so by making it extremely cheap to publish an entry (clicking a button would generate a unique identifier without human intervention) but risked introducing spam and invalid vulnerabilities into its network - DWF attempted to address these issues by having distributed verification entities which would be closer to the vulnerability (i.e, working as a maintainer or having extensive subject knowledge), and introduced a twist in its protocol by suggesting that the vulnerability entries' database could be hosted on a blockchain.

Neither of these alternatives to CVE found widespread adoption and subsequently faded from public view (or merged with vulnerability database aggregation projects like Google's OSV 'database for open-source').
Over half a decade later, I stumbled upon the original LWN post and was intrigued by the idea of having a vulnerability tracking system that would both reduce reliance on individual providers such as Mitre (CVEs) and GitHub (GHSAs) and the minimize any incongruity that attempts to interoperate with more than one of those systems have been found to introduce, so I decided to make my own vulnerability tracking system that would be capable of linking to existing providers' records whilst maintaining an independent copy of records that could be modified, updated, or corrected with ease.

System Structure

At the core of VIAL is a HTTP API written in Python 3. This API has endpoints for adding, publishing, modifying, and viewing specific vulnerability entries as and when the user requests such an action (either through a web interface or by sending HTTP requests to the API).

A major goal of this project was to minimize the cost and dependencies required to operate VIAL in its entirety over a long term (due to how frequently alternatives such as DWF were seen to be abandoned). To that extent, the user-facing aspects of the Web UI (viewing and enumerating entries) are able to function independently of the Rest API through the techniques outlined below.

Adding a New Entry

When a new vulnerability needs to be added to the database, the following occurs:

• An API request is received with the JSON body containing most of the entry's details
• The entry's JSON is 'tidied' (assigned an incremental VIA-ID and upload date)
• An encryption key is generated randomly using a CSPRNG
• The entry's JSON is symetrically encrypted
• The ciphertext of the above step is uploaded to IPFS without the decryption key and the CID of the new entry is pinned
• The CID of the 'entrylist' (an array of all VIA entries) is resolved via DNSLink (entries.vial.michaelrowley.dev)
• The entrylist is retrieved as a JSON object and the CID and VIA-ID of the new entry are inserted
• A newly-appended entrylist is uploaded to the IPFS network and is pinned by the local system
• The entrylist's new CID is written to the TXT DNS entry of entries.vial.michaelrowley.dev
• The CID and symmetric key are returned to the user where it is displayed on a webpage

This process is essentially language agnostic (but was implemented in Python 3) and essentially all of the key steps above could be emulated with a bash script or your favourite API testing tool.

Publishing an Entry

In order to publish an entry, the symmetric key used to encrypt the entry's JSON is simply attached to its listing in the entrylist which is reuploaded and pinned.

• An API request is received containing a JSON body with the relevant entry's symmetric decryption key
• The CID of the 'entrylist' (an array of all VIA entries) is resolved via DNSLink (entries.vial.michaelrowley.dev)
• The entrylist is retrieved as a JSON object
• The entry is located using the key_hash member of each entrylist item
• Once the correct entry has been found, the provided key is inserted into the entrylist member of the VIA entry
• The new entrylist is uploaded to IPFS and the relevant DNS subdomain's TXT value is set to the new entrylist CID

Browsing/Viewing Entries

Despite it being possible to view entries using the API outlined in the previous sections, doing so would mean that a server/device would need to be running 24/7 to serve such information which isn't ideal. To get around this issue, the viewing/browsing webpages have their own JavaScript code that handles manually retrieving, parsing, displaying, and interacting with VIA entries via the IPFS network without hosting a own backend server.

The client-side JavaScript is only half of the solution as IPFS can only guarantee data's presence when it is 'pinned', and therefore a pinning service (Piñata) and IPFS gateway (the official ipfs.io gateway between the typical HTTP internet and the IPFS network) was used.
As a result of this setup, it's also possible to view unpublished entries by including the hex decryption key in the view.html url, meaning that it's possible for an entry to be viewed by specific people via a 'magic link' containing the decryption key and VIA ID.

Final Notes

While I haven't released the source code to the backend system publicly, the viewing and browsing frontend is available for public use at https://vial.michaelrowley.dev/. The information provided in this post should be enough for anyone interested to develop their own version.
Additionally, it is worth noting that in an attempt to mitigate any ciphertext size-based attacks, the API appends a CSPRNG-generated number of space characters into the JSON of all VIA entries, meaning that any attempts to derive information about the plaintext's key fields based on the ciphertext block size should be invalidated due to cryptographic implementation's block rounding combined with this additional 'postfix' protection.