Saturday, November 4, 2023

Vulnerability Management - Suppress Vulnerabilities

Today I will share with you a way by which you can ignore 99.9% of vulnerabilities in your environment. Ha ha ... Just kidding.


But on a serious note there are few vulnerabilities which you can suppress. Let's see them one by one.


1. SSL related vulnerabilities on systems in LAN network:


e.g. SSL Certificate Cannot Be Trusted (https://www.tenable.com/plugins/nessus/51192)

e.g. SSL Self-Signed Certificate (https://www.tenable.com/plugins/nessus/57582)

e.g. SSL Certificate with Wrong Hostname (https://www.tenable.com/plugins/nessus/45411


Reason -> Organizations use use self-signed certificates for systems in LAN.


2. Vulnerabilities which are difficult to exploit due to enforcement of policy

e.g. Microsoft Office Trust Access to VBA Project Model Object Enabled (https://www.tenable.com/plugins/nessus/123461)


Reason -> VBA can be disabled using GPO.


3. Vulnerabilities due to how a OS vendor handles their patching regime and discloses vulnerabilities

e.g. CentOS vulnerabilities on Tenable Core not being mitigated (https://community.tenable.com/s/article/CentOS-vulnerabilities-on-Tenable-Core-not-being-mitigated?language=en_US)


4. In almost all organizations patching on Windows servers is done via various patching tools (not via automatic updates)

e.g. MS KB3119884: Improperly Issued Digital Certificates Could Allow Spoofing (https://www.tenable.com/plugins/nessus/87313)

The plugin was flagged on Windows 2012 R2 servers but was fixed in Windows server 2016 


5. Non availability of patches from OS vendors


e.g. Curl 7.84 <= 8.2.1 Header DoS (CVE-2023-38039) for Windows 10 and Windows 11 OS (https://learn.microsoft.com/en-us/answers/questions/1387774/curl-7-84-(-8-2-1-header-dos-(cve-2023-38039)-for)

(https://www.tenable.com/plugins/nessus/181409)


e.g. Curl 7.69 < 8.4.0 Heap Buffer Overflow (https://www.tenable.com/plugins/nessus/182875)


Reason -> Platform support teams will not update packages from open source projects as it might break things and they will not get vendor support.


I know this is not much but as the saying goes "a little help is worth much more for the wretched". Ultimately you need to use EPSS, CISA KEV, and various threat intel sources for prioritization to reduce actionable vulnerabilities.


Happy Learning !!

Vulnerability Management - Scanning approach to Load Balancers

As we all know how much important are high availability solutions these days. A load balancer (LB) is one such system which provides high availability apart from various other features such as security, scalability and performance. 

A LB is a device or software that sits between clients and servers in a network. It distributes incoming traffic across multiple servers to ensure that the load is balanced and network services remain available. LBs are by their very nature intended to hide what is behind them. 

But scanning through a LB can create unwanted results. As it directs network traffic intelligently among multiple servers, when you scan THROUGH a LB using a VIP, you will get different results for the same VIP address for multiple scans. 

Following issues may arise while scanning through LB:

  • Scanning LBs will show any vulnerabilities of the LBs themselves, which may lead you to thinking that the vulnerability is on the actual server when it is not.
  • Scanning through LBs, assuming there are multiple servers behind those LBs, may give you different results each time you scan the IP. For example, the first scan you hit Server1, then second scan you hit Server2. If those servers are not completely the same the results can show variations.
  • Suppose you are scanning a /24 subnet with 10 assets or so, due to high intensity of the scan, LBs may go into hardware protection mode and just send a reply for every single query that a scanner makes to it. This will result in 255 assets showing alive. 

Hence, you should never scan THROUGH a LB. Either deploy agents, or place a scanner on the inside network of the LB. To scan a LB itself you would need to use its management IP address. 

When scanning using a Virtual IP Address (VIP), currently from scanning solution's perspective, there isn't a way to tell whether an IP address is a VIP or not. You would need to write a script to pull the configs from the LBs and pull the VIPs. 

Please refer the below URLs for more details:

What is a LB? (https://aws.amazon.com/what-is/load-balancing/#:~:text=Load%20balancers%20increase%20the%20fault,or%20upgrades%20without%20application%20downtime)

Scanning approach to LBs (https://community.tenable.com/s/question/0D5f200005YPgFsCAL/scanning-approach-to-load-balancers?language=en_US)

What is a Virtual IP Address (VIP)? (https://www.pubconcierge.com/blog/virtual-ip-what-is-it-and-how-it-works/


Happy Learning !!

Vulnerability Management - Understanding vulnerability posture

Understanding the vulnerability posture of an organisation at a basic level helps you drive remediation efforts. So, I don't know what t...