SoftwareOOI’s, vulnerabilities and KAT

[underdarknl]

KAT’s OOI model contains a model for ‘software’, in this document we explain what options we see, and propose ways to capture information about software in KAT, and what we can do with this.

Ingestion of SoftwareOOIs
There are multiple ways of learning what software is present in your systems, and as long as you can be precise enough about discovering those pieces of software, KAT could tell you related information about them. Some of the ways we think KAT can discover software:
• Fingerprinting via network-traffic
• Recognition of software via filenames
• Recognition of software via source code (eg, html, css, javascript snippets)
• (local) Discovery of installed software via appstores, apt/rpm configs.
• Hash based file matching

Expanding Software information
Once we have some software in the model, we can then do the following:
• Find dependencies which in turn deliver new SoftwareOOI’s
• Find the repository
• Find the author(s)
• Find the health of the software, age, community traction, forks, number of issues outstanding etc
• Find the status (supported, EOL, abandoned)
• Known vulnerabilities
• License
• More targeted scans for finer version information, plugin availability.

Matching to vulnerabilities and other issues

Once software is in the Graph, KAT can use its BITS to see if any combination triggers the creation of new Findings. These might be direct hits between a softwareOOI and a known CVE, but might also be softer warnings where for example the age of a project triggers a warning about the project being stale. Other options might be to have a good or bad list of authors or countries of origin. Even license issues could trigger a BIT.
Since all these facts are already kept up to date by our expansion of facts in the previous step, they are neatly stored in the timeline. If for example a CVE originally scores a low score of 3, but then gets updated to a 8, you might want to start alerting people. More importantly, you might need to explain why you did not alert before. Having proof that it was rated a 3 before combined with the alert when it became an 8 should help with that.

[underdarknl]

Options to fingerprint software

• wappalizer
• various Nmap plugins

Options to find local software

• apt list --installed

Options to extend software information based on earlier observations

• WPscan

[zcrt]

Regarding the ingestion of SoftwareOOIs, it may be useful to add some kind of confidence score indicating how sure KAT is that we are dealing with a specific SoftwareOOI. Such a score may change based on the different ways that KAT uses to discover the software;

• If there are multiple findings indicating a specific SoftwareOOI the confidence score should be come higher (e.g. closer to 1.0). This could for example be the case when both fingerprinting and filenames indicate a specific SoftwareOOI.
• If there are findings contradicting a specific SoftwareOOI the score should become lower (e.g. closer to 0.0). This could be the case when KAT is expecting some kind of vulnerability for the SoftwareOOI, which turns out not to be exploitable, suggesting that we are actually dealing with something else or a maybe a different version of the SoftwareOOI.

When having a confidence score for an SoftwareOOI available, this could also be used to write more fine-grained bits. (E.g. only run L4 boefjes on this SoftwareOOI if the confidence score is larger than 0.7 (or another arbitrary number)).

[underdarknl]

Yes, confidence scores are something that we looking into. Also with regards to the age of gathered facts, as that also introduces a certain level of confidence erosion.
Ideally, we'd spend as little resources (by running boefjes + normalizers) on oois (or facts) with the highest confidence levels. By keeping track of the resources spend, and the confidence levels set by the boefjes and normalizers combined with the erosion we should be able to make a good choice there. Also, having these levels would allow us to tell the user about the confidence we have in each object, but also in the weakest facts that are used for compiling a report. Possibly allowing the user to refresh a scan or manually verify things that KAT couldn't do automatically.

This would probably be better handled in a separated Discussion.