F-Secure Radar basic reporting

In previous post about Radar (“F-Secure Radar Vulnerability Management solution“) I was describing how to use it for authenticated and unauthenticated scanning both inside and outside of your network.

But what about the vulnerability reports?

To get vulnerability report you should open Reporting Tab. As you can see, Radar supports reports for single scan results and summary reports. I don’t actually a big fan of standard vulnerability summary reports, because in practice you will always need to change something in them, and it’s impossible in most cases.

F-Secure Radar reports

I have filtered only Linux OS scans using filter. You can also filter by friendly name (some id, that you can set manually), host name/ip , time of scanning, responsible person, severity level, scan group or even by scan tags.

Radar Filters

For single scan report you just need to choose document format in Actions menu:

F-Secure report formats

How the scan looks in web interface:

Radar Report View

Vulnerability entity has all basic attributes: status (can be marked as “false positive” by auditor if it is needed), severity, synopsis, description, solution, findings (how it was detected), tags , risk factor (cvss), applicability for DoS attacks, links to CVEs.

F-Secure Vulnerability View

Basic structure of F-Secure Radar XML report:

<report format="SSNG1.0">
<createdon>23-09-2016 15:50:30</createdon>
<section type="information">...</section>
<section type="platform">...</section>
<starttime>23-09-2016 15:27:53</starttime>
<duration>22 minutes</duration>

Actual vulnerabilities are in “platform”-type section:

<section type="platform">
        <os>CentOS Linux 7 (Core)</os>

Example of single vulnerability. It contains all the same attributes you in web interface and some additional, as id, script version, family, trust (quality of detection), links to other source then cve, risk factor.

<vulnerability risklevel="2" new="true">
<name>CESA-2016:0176: glibc security and bug fix update</name>
<summary>Checks for missing security patches.</summary>
<additionalinfo>The remote host is missing 4 security patches:
glibc-2.17-106.el7_2.4 (currently installed version is: glibc-0:2.17-106.el7_2.1)
glibc-common-2.17-106.el7_2.4 (currently installed version is: glibc-common-0:2.17-106.el7_2.1)
glibc-devel-2.17-106.el7_2.4 (currently installed version is: glibc-devel-0:2.17-106.el7_2.1)
glibc-headers-2.17-106.el7_2.4 (currently installed version is: glibc-headers-0:2.17-106.el7_2.1)</additionalinfo>
<xref name="BUGZILLA" url="https://bugzilla.redhat.com/1298956">"monstartup: out of memory" on PPC64LE [rhel-7.2.z]</xref>
<xref name="BUGZILLA" url="https://bugzilla.redhat.com/1256285">CVE-2015-5229 glibc: calloc may return non-zero memory</xref>
<xref name="BUGZILLA" url="https://bugzilla.redhat.com/1293532">CVE-2015-7547 glibc: getaddrinfo stack-based buffer overflow</xref>
<xref name="REDHAT" url="https://rhn.redhat.com/errata/RHSA-2016-0176.html">RHSA-2016:0176: glibc security and bug fix update</xref>
<attribute name="synopsis">The remote host is missing security patches.</attribute>
<attribute name="description">The glibc packages provide the standard C libraries (libc), POSIX thread libraries (libpthread), standard math libraries (libm), and the name service cache daemon (nscd) used by multiple programs on the system. Without these libraries, the Linux system cannot function correctly.
A stack-based buffer overflow was found in the way the libresolv library performed dual A/AAAA DNS queries. A remote attacker could create a specially crafted DNS response which could cause libresolv to crash or, potentially, execute code with the permissions of the user running the library. Note: this issue is only exposed when libresolv is called from the nss_dns NSS service module. (CVE-2015-7547)
It was discovered that the calloc implementation in glibc could return memory areas which contain non-zero bytes. This could result in unexpected application behavior such as hangs or crashes. (CVE-2015-5229)
The CVE-2015-7547 issue was discovered by the Google Security Team and Red Hat. Red Hat would like to thank Jeff Layton for reporting the CVE-2015-5229 issue.
This update also fixes the following bugs:
* The existing implementation of the "free" function causes all memory pools beyond the first to return freed memory directly to the operating system as quickly as possible. This can result in performance degradation when the rate of free calls is very high. The first memory pool (the main pool) does provide a method to rate limit the returns via M_TRIM_THRESHOLD, but this method is not available to subsequent memory pools.
With this update, the M_TRIM_THRESHOLD method is extended to apply to all memory pools, which improves performance for threads with very high amounts of free calls and limits the number of "madvise" system calls. The change also increases the total transient memory usage by processes because the trim threshold must be reached before memory can be freed.
To return to the previous behavior, you can either set M_TRIM_THRESHOLD using the "mallopt" function, or set the MALLOC_TRIM_THRESHOLD environment variable to 0. (BZ#1298930)
* On the little-endian variant of 64-bit IBM Power Systems (ppc64le), a bug in the dynamic loader could cause applications compiled with profiling enabled to fail to start with the error "monstartup: out of memory". The bug has been corrected and applications compiled for profiling now start correctly. (BZ#1298956)
All glibc users are advised to upgrade to these updated packages, which contain backported patches to correct these issues.</attribute>
<attribute name="solution">Run 'yum update' to install latest security updates.</attribute>
<attribute name="DOS">false</attribute>
<attribute name="trust">100</attribute>
<attribute name="cvss_vector">(AV:N/AC:M/Au:N/C:P/I:P/A:P)</attribute>
<attribute name="cvss_cvss_base_score">6.8</attribute>
<tag technical-name="authcheck" type="dynamic" source="SystemScan">Authenticated Check</tag>
<tag technical-name="centosauthcheck" type="dynamic" source="SystemScan">CentOS Authenticated Check</tag>
<tag technical-name="linux" type="dynamic" source="SystemScan">Linux</tag>
<riskfactor>Security Hole</riskfactor>

The only useful thing I haven’t seen in Vulnerability reports, comparing with Qulys and Nessus, is “exploitability” flag. In the other hand, it’s possible get a list of exploits available for the particular vulnerability in systems like Vulners.

2 thoughts on “F-Secure Radar basic reporting

  1. Pingback: F-Secure Radar Vulnerability Management solution | Alexander V. Leonov

  2. Pingback: Gartner’s view on Vulnerability Management market | Alexander V. Leonov

Leave a Reply

Your email address will not be published. Required fields are marked *

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