Vulnerability Management - Scanning using Nessus Essentials

Prepared a document on scanning a Windows 10 workstation using Nessus Essentials. It is a free version of Nessus vulnerability scanner hence you cannot perform compliance checks. However, purpose of creating the document was to let you know how you can scan your workstation successfully. Normally, if you enter correct credentials in scan policy, authentication will be successful still the scanner will not be able to gather much data. Certain registry changes are required and few services need to be enabled for a successful scan. 

Downloading and installing Nessus Essentials is good to learn but the main part is about registry changes and services. One should understand why they need to be enabled and their significance.

I have added references to videos and websites I referred in the document.

 

Happy Learning !!

Cybersecurity - Architect vs Engineer vs Analyst

Cybersecurity Architect - One who decides how security is done and has holistic view of an organization's architecture (Expert in multiple domains)

For e.g. One who knows where firewall, AV, SIEM, VM, IDS/IPS, proxy, DLP etc. should be placed. Decides what policies should govern operation of aforementioned tools.

--> More involved in decision making

Cybersecurity Engineer - One who follows a given design and builds/engineers solutions.

For e.g. One who actually deploys and maintains (Deploy/Configure/Upgrade/Troubleshoot/Decommission) above mentioned solutions. 

--> More involved in implementation

Cybersecurity Analyst - One who uses data generated by these solutions to ensure cybersecurity. Provides feedback and reports issues to engineers based on which engineers finetune solutions.

For e.g. One who works on dashboards, alerts, incidents, reports etc. generated by above mentioned cybersecurity solutions.

--> More involved in analysis

Each role has its challenges, hence one should not reach to immediate conclusion about betterness of these roles over one another.

 

Happy Learning !!

Vulnerability Management - BAU (Business As Usual) and Ad hoc tasks

Once scanners are deployed, scans are scheduled and, reports are configured, one may ask, then what tasks vulnerability analysts/engineers perform?

So following are the tasks which are operationalized:

1. Authentication - Troubleshoot authentication issues.

2. Scan Coverage - Ensure scope for vulnerability scanning (cloud and on-premise) is defined and you are covering all the systems in scope. This may require co-relation with CMDB.

3. Offline Agents - Ensure the agents which are offline are of systems which are decommissioned. Agents can go offline due to variety of other reasons as well.

4. Reports - Normally, a lot of vulnerabilities are not patched by patching teams such as vulnerabilities related to 3rd party applications. They will patch vulnerabilities related to OS and corresponding native applications. Hence, you will always face requests to transfer ownership of such vulnerabilities. So, you will need to make changes to reports frequently if not regularly. You will also need to analyze reports to find assets which are not patched regularly (You can find out assets which are not onboarded in patching tools). 

5. Policy Fine Tuning - There are vulnerabilities which require particular settings to detect them. Similarly, for compliance, there are controls which require modifications depending on the environment.

6. Managing False +ves and Exceptions - As scanning solutions have limitations hence, false +ves and exceptions will generate.

7. Rescan and Decommission requests - These tasks are performed on regular basis.

8. Weekly/Monthly calls with various stakeholders - Normally, current status of remediation efforts and challenges faced by application/platform teams are discussed.

9. Penetration and Audit findings - You will need to work with various teams to fix these findings.

10. VM Policy - Every organization has a policy where SLAs and critical assets are defined. You will need to create/fine tune such policies.

11. Deliver Trainings - As attack surface is ever evolving, you will need to give regular trainings on cybersecurity best practices (Phishing/Shift left approach/Safe browsing etc.).

12. Sync with TI - Be in sync with Threat Intelligence team and prioritize remediation according to their inputs.

Following are the tasks which are done on Ad hoc basis:

1. Scanner/Manager upgrade.

2. Troubleshoot connectivity issues between scanner and manager or agents and manager.

3. Deploy new scanner/manager

4. Integration with various tools such as the following:

• ITSM (e.g. ServiceNow)   
• CMDB (e.g. ManageEngine)
• Risk Assessment (e.g. Kenna)

5. Task automation (e.g. Scripting using Python or VB)

 

Happy Learning !!

Vulnerability Management - Paranoid Mode

In Tenable, detection of few plugins require paranoid mode to be enabled.

It allows a user to specify whether or not we should only report vulnerabilities with a high level of confidence, or be a little more paranoid and flag a system if there is possibility they are or could be vulnerable. It can lead to potential false positives but can give a larger view of their cyber exposure.

Generally, when paranoid mode is enabled, number of vulnerabilities detected will increase. Following are the few reasons:

1. Backported patches are ignored: When applications are backported by package maintainers, the version displayed when installing through a package manager may differ than a package downloaded directly from a vendor. When Paranoid Mode is enabled, backported patches will not be considered, resulting in a false positive for the 'missing' patch.

2. Some plugins (depending on how the detection is performed) may only have version information to work with, and not specific configuration information about the host. Often a vulnerability may only exist if a specific configuration is enabled and if the plugin cannot gather this info, paranoid mode is used. A common example of this is Cisco configurations noted in their advisories. In these instances you may see a false positive.

3. When a plugin is performing a direct check against a host, such as directly exploiting a certain vulnerability, this could lead to potential false positives due to the nature of the vulnerability. For example if we have to rely on an HTTP response header to determine if an exploit was successful, this could lead to a false positive for an unaffected device, or an IDS/IPS/Firewall could alter the response.

Please refer below URLs for more details:

https://community.tenable.com/s/article/How-to-know-when-a-plugin-is-made-paranoid

https://community.tenable.com/s/article/Which-plugins-require-the-paranoia-setting

https://community.tenable.com/s/article/How-does-Show-potential-false-alarms-impact-a-scan-scanning-in-paranoid-mode

Happy Learning !!

Vulnerability Management - Analyze before upgrading versions

Microsoft released a security update for .NET core on December 2022. Tenable also released a signature to detect the update (Plugin ID 168747 https://www.tenable.com/plugins/nessus/168747). Solution was, "Update .NET Core Runtime to version 3.1.32 or 6.0.12 or 7.0.1." Now, if you carefully go through Microsoft's support policy (https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core), you can observe, version 3.1.32 became EoL on December 13th 2022.

If you are below 3.1.32, then obviously the statement "Update .NET Core Runtime to version 3.1.32 or 6.0.12 or 7.0.1." makes sense. But, if you apply the security update to mitigate one detection, another detection of 3.1.32 being EoL will follow you soon. Tenable released a signature to detect .NET core EoL versions on 7th March 2023 (https://www.tenable.com/plugins/nessus/172177).

As a patch analyst, you should not say, I brought old versions of .NET Core to 3.1.32 with huge effort and now you are telling that 3.1.32 became EoL. Please remember, scanning vendors, will not report multiple solutions in one finding. If a version misses a security update, it is a separate finding than the version itself becoming EoL, and hence solutions will also be different. So, one has to be aware of product lifecycle before applying patches.   

So, before updating a software, please check, when the version of the software to which you want to update, is going to become EoL. If it is going to become EoL in coming 2-4 months, you might want to go for major upgrade.

Happy Learning !!

Vulnerability Management - To be or not to be (A false positive)

I wanted to discuss a situation where you clueless !!

VMware released an advisory consisting security updates for vulnerabilities @CVE-2022-31696 and CVE-2022-31699 (https://www.vmware.com/security/advisories/VMSA-2022-0030.html).

Now, Tenable published a signature to detect the vulnerability @168828 (https://www.tenable.com/plugins/nessus/168828).

If you check response matrix for CVE-2022-31696 for ESXi 7.0 in VMware's advisory, it says, fixed version is ESXi70U3si-20841705 ("05"). If you click on the link, it will take you to ESXi 7.0 release notes (https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3i-release-notes.html). Now if you scroll down a bit, you can see the download is for ESXi70U3si-20841708 ("08"). The difference between two versions i.e. "05" and "08", is of component and driver updates. "05" has security updates only while "08" has security, component and driver updates. I observed, in few cases, due to hardware dependencies, support teams are not able to upgrade to "08". But, Tenable is detecting "05" version as vulnerable. Since "05" already has security updates, support teams are claiming this detection as false positive.

Now, in counter, Tenable is saying, when go from VMware's advisory to release notes, the download file is for "08". So this is not a false positive. Either there is a typo from VMware or "08" is the correct build.

So yes, if you understood the scenario, such cases also occur. Our support team has reached out to VMware already but not sure how much time VMware will take to address this issue.  

Not sure what VMware and Tenable will do, in the interim we are trying to make peace with the support team (ha ha).

Happy Learning !!

Vulnerability Management - Tenable.sc First Discovered Date Fluctuating

Some common environmental factors which will cause the first discovered dates to fluctuate are:

1. Targeting a system by FQDN or hostname when that name could resolve to multiple IPs. Two common examples of this are a system that is behind a load balancer or a system that has multiple NICs. Customers should be working with their network and/or DNS admins to determine if this is a possibility for the primary DNS server used by Tenable.sc, which can be found in /etc/resolv.conf.

2. Assigning systems a new IP address via DHCP when the dhcpTracking setting is not uniform across all scans for the organization.

3. Assigning the same IP to multiple systems in different networks and importing the scan results into the same repository. If 172.26.0.1 in network A is a different system than 172.26.0.1 in network B and each are scanned, Tenable.sc will consider them one system and the vulnerability data may not appear accurate due to the differences in the target systems. Customers should be working with their network and/or DNS admins to determine if this is a possibility in the environment.

4. Deploying virtual systems from the same template / image without adjusting the underlying network settings. Any duplication of FQDN, MAC, or NetBIOS across different systems will prevent Tenable.sc from uniquely identifying them, causing all the vulnerability data to collide under the same IP.

Please refer below URL on how one can normalize this behavior:

https://community.tenable.com/s/article/Tenable-sc-First-Discovered-Date-Fluctuating

Happy Learning !!

Vulnerability Management - Scan with low privileged service account

Recently encountered a situation where few false positives appeared on some Cisco devices. Whenever false positives appear, first thing to check is authentication. If it is happening properly then you should go for authorization check.

Now in this case, scan happened with privilege level 1. After investigation, we found that, the service account in use was part of multiple AD groups (ISE is integrated with AD). This created a conflict in privilege level and low privilege was chosen. This in turn resulted in false positives on some Cisco devices.

Hence always ensure, the service accounts dedicated for vulnerability scanning should not be part of any irrelevant groups.

Happy Learning !!

Vulnerability Management - Detection based on application's self-reported version number

Let's understand one use case. 

Apache published a new version of HTTP server i.e. v2.4.55 (https://httpd.apache.org/download.cgi). Now, if you check the version of Apache HTTP servers which are shipped with Redhat, you would find upstream versions are on or below v2.4.53 (https://access.redhat.com/solutions/445713).

Now, Tenable started detecting versions 2.4.x < 2.4.55 as vulnerable to CVE-2006-20001, CVE-2022-36760, CVE-2022-37436 (https://www.tenable.com/plugins/nessus/170113). But these web servers are only vulnerable when "mod_proxy_ajp" module is in use. Solution to this vulnerability is to disable the module (https://access.redhat.com/security/cve/cve-2022-36760). However, even after disabling the module, Tenable will continue to flag the vulnerability as it is not checking whether the module is in use or not.

You can use the command "apache2ctl -M" to check for loaded modules of Apache in Linux systems (https://www.tecmint.com/check-apache-modules-enabled/).

Hence, from my perspective you have the following options:

1. Recast the risk of the vulnerability from "Critical" to "Medium"/"Low" so that it doesn't get counted in any KPI metric

2. Provide temporary exception for 4 or 6 months

So, whenever you come across detections based on application's self-reported version number, be vigilant and perform proper vulnerability analysis.

Happy Learning !!

Vulnerability Management - Skipping scheduled daily agent scans

Many organizations have employees working in shifts. Hence, while running agent based scans, it becomes important to manage coverage of all in scope workstations. Normally, to cover them, scan window is set to 24 hours.

But because of this scan window, scheduled daily agent scans will be skipping. Since the scan will start a few minutes later than scheduled there is a chance that the next scheduled daily scan will not start because the previously scheduled occurrence is still running.

Solution to this issue is to change scan window to 1380 minutes (23 hours). This gives some padding for post processing to complete before the next scan launches avoiding overlapping of scan jobs which results to scheduled scans skipping.

Happy Learning !!

Threat Intelligence vs Threat Hunting vs Threat Modeling

Threat Intelligence -> Data that is collected, processed, and analyzed to understand a threat actor’s motives, targets, and attack behaviors.

Threat Hunting -> Process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions.

Threat Modeling -> Threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.

Please refer the below links for more information:

https://www.crowdstrike.com/cybersecurity-101/threat-intelligence/

https://owasp.org/www-community/Threat_Modeling

Happy Learning !!

Vulnerability Management - Nessus Knowledgebase

A Knowledgebase (KB) is created for each target during a Nessus scan. When a plugin collects information that needs to be "shared" with other plugins it is stored in the KB for that host. The KB can be found for a specific host in the Host Details section of the scan results reached by drilling down on that host.

Note: Nessus also collects a global KB that shares information not only between different scripts but between different hosts.

KBs are in the following format:

timestamp data_type key=value

-> timestamp: Epoch time representing when a scan completes

-> data_type: 1 is for strings, 3 is for integers

For e.g. 1475164035 3 portscanner/14272/Ports/tcp/1334=1

There are several functions used by plugins to read or write information to the KB:

1. set_kb_item(): Adds a new item in the host knowledge base. The value can either be a string or an integer. If an item with the same name already exists in the KB, it's unaffected as the KB can have the same key listed multiple times.

2. set_global_kb_item(): Adds a new item in the global knowledge base. The value can either be a string or an integer. If an item with the same name already exists in the KB, it's unaffected as the KB can have the same key listed multiple times.

3. replace_kb_item(): Same as set_kb_item() except it will replace the value found in the key.

4. get_kb_item(): Fetches the value of the key in the KB (all of them if more than one exists) and returns the result.

5. get_global_kb_item(): Fetches the value of the key in the global KB (only the first value if more than one exists) and returns the result.

6. rm_kb_item(): Deletes a KB entry. If multiple entries exist, specifying a value makes the function only delete the entry for that specific value.

7. get_kb_list(): Returns the list of values for KB keys matching a certain pattern (e.g. "SMB/Registry/*")

8. get_global_kb_list(): Same as get_kb_list but for the global KB.

Please refer the below link for more information:

https://community.tenable.com/s/article/What-is-the-Nessus-Knowledgebase-KB

Happy Learning !!

 

Vulnerability Management - Firewall Detection

NMAP has several techniques for firewall detection. Since enterprise networks have large subnets, it is not practical to employ such advanced techniques for scanning an environment with 10000+ assets.

Below is a general method used by Qualys.

When there is no firewall between a scanner and a target host, all TCP packets sent by the scanner to the target host should trigger a reply packet from the target host. When there is a firewall, this is no longer true. There are two general firewall behaviors that Qualys relies on for this detection:

-> No reply (silently dropped)

-> Connection reset (RST)

With regard to the first behavior, some firewalls will drop TCP SYN packets sent to certain ports. In this case, the TCP SYN packets sent by the scanner to these ports will not generate a reply. So when we send SYN packets to the target host and do not receive a reply, we know there is a firewall.

With regard to the second behavior, other firewalls will respond to TCP SYN packets sent to certain ports with RST packets on behalf of the target host. To detect this type of firewall, Qualys analyzes the TTL values of the RST reply packets (from the firewall) and the SYN-ACK packets (from the target host). This method requires that the firewall allows SYN packets to some ports to go through and reach the target hosts while resending SYN packets to other ports on behalf of the target host.

False positives can come when network conditions are bad leading to packets being dropped. You can choose to disable TCP ping method or consider ICMP unreachable messages as a sign of dead host for proxy ARP replies.

Please refer the below links for more information:

https://success.qualys.com/support/s/article/000006102

https://docs.rapid7.com/nexpose/configuring-asset-discovery/#collecting-information-about-discovered-assets

https://community.tenable.com/s/article/Scan-is-returning-results-for-IPs-which-are-known-to-be-dead-or-non-existing

https://nmap.org/book/firewalls.html

https://www.tenable.com/blog/4-ways-to-improve-nessus-scans-through-firewalls  

Happy Learning !!