In part two and three of the "Surviving and Passing SOC Audits", we are going to discuss the most common findings that come up in a penetration test, and ways that you can remediate those findings through configuration changes or controls. First, lets discuss Severity ratings and CVSS Scores, below is a table that shows the common scoring for vulnerabilities.
In part two and three of the “Surviving and Passing SOC Audits”, we are going to discuss the most common findings that come up in a penetration test, and ways that you can remediate those findings through configuration changes or controls. First, lets discuss Severity ratings and CVSS Scores, below is a table that shows the common scoring for vulnerabilities.
Vulnerability Scoring
Severity Rating | CVSS Score | Description |
---|---|---|
Critical | 9.0-10.0 | Findings receive a Critical-severity classification instead of a High-severity one if they pertain to attack scenarios executable with administrative privileges, or if there’s a considerable chance of gaining elevated privileges after a successful breach. Moreover, findings that are actively exploited in real-world attacks merit a Critical rating. These findings require immediate attention. |
High | 7.0-8.9 | Findings categorized as High-severity pose a significant threat to the target system and its associated infrastructure. Such findings allow attackers, irrespective of their location, to gain user-level read or write access, or to carry out commands on the target service, the base operating system, or interconnected systems, all without needing administrative privileges. It’s important to address High-severity findings swiftly, after giving precedence to any findings of Critical-severity. |
Medium | 4.0-6.9 | Findings labeled as Medium-severity are noteworthy due to their potential to cause a denial-of-service condition or allow privilege escalation without administrative credentials. Additionally, they could enable the compromised system to serve as a pathway for attacks on other targets, or assist in gathering passwords and configuration information, aiding in the orchestration of subsequent attacks. |
Low | 0.1-3.9 | Findings designated as Low-severity essentially serve as warnings that may represent vulnerabilities, depending on their impact on the target system. This classification might also encompass findings that offer attackers informational perspectives about the target system or client. Typically, such findings should undergo further examination by network administrators, system administrators, or the information security team. |
Informational | N/A | Informational findings are significant to the target organization and relevant entities, even though they are not independently exploitable. They include identified vulnerabilities based solely on software or service versions, significant deviations from established information security protocols, or other conditions pertinent to a penetration test. Like Low-severity findings, these Informational points require additional analysis by the target organization to determine if additional actions are necessary. |
In a network penetration test, you’re likely to come across a range of findings. Some can be rectified swiftly, while others demand greater time and resources. We’ll delve into each to deepen your understanding of what they entail and how to address them. Although I may offer PowerShell code for quick fixes, it’s advisable to implement remediation through Group Policy whenever feasible. This ensures a uniform application of changes across all current and future Windows systems.
Part One
- Local Network Poisoning – LLMNR, NBT-NS, mDNS (High)
- Unmanaged IPv6 Man in the middle (High)
- Outdated Software and Services (Critical or High)
- WPAD Man-in-the-middle
- Weak SSH configuration
- Deprecated TLS Protocol Support – TLS 1.0 or 1.1 (Medium)
- ARP Poisoning (High)
Part Two
- Accessible Network Shares (High)
- Default Credentials on Devices (Medium)
- SMB Signing Disabled (Medium)
- Weak TLS/SSL configuration (Medium)
- Weak RDP configuration (Medium)
- HTTPS not required (Medium)
- Weak SSH configuration (Medium)
Local Network Poisoning
Finding: Local Network Poisoning is a frequent and troublesome issue that persistently emerges in various forms such as LLMNR, NBT-NS, or mDNS. Each variant requires a unique approach to remediation. LLMNR, NBT-NS, and mDNS are integral to contemporary Microsoft Windows operating systems. LLMNR, which debuted with Windows Vista, was designed to supplant NBT-NS. By default, both LLMNR and NBT-NS are active. On the latest Windows 10, Windows 11, and Server 2022 versions, as well as on Mac and iOS devices, mDNS is also enabled by default. Windows further permits applications to employ mDNS for specialized broadcasts, a functionality utilized by browsers such as Google Chrome and Microsoft Edge. Moreover, devices like printers, projectors, and screen-casting tools commonly utilize mDNS for device detection.
Impact: Attackers may exploit LLMNR, NBT-NS, and mDNS protocols to conduct man-in-the-middle attacks. They do this by monitoring for LLMNR (5355/UDP), NBT-NS (137/UDP), and mDNS (5353/UDP) broadcasts or multicast requests for host resolution within a local network. An intercepted request can be manipulated to reroute the user to a machine under the attacker’s control. This misuse of protocols can lead to authentication requests being mistakenly sent to the attacker, which were meant for legitimate hosts. Attackers might leverage these requests to launch further attacks on the network. Should the intercepted credentials be plaintext, they can be directly used for authentication on other systems and services. Alternatively, if the credentials are hashed, they can be retained for future cracking attempts or used in relay attacks targeting other systems in the network.
NBT-NS/LLMNR Remediation: To mitigate this issue, a few adjustments are necessary, and consistency is key across all Windows systems, encompassing servers and end-user laptops/workstations. Within the settings of each network card, you must deselect the “Enable LMHOSTS Lookup” option and choose to disable “Netbios over TCP/IP”.
Here is a powershell script that can be used to disable both settings:
# Disable LMHOSTS lookup on all network adapters $adapters = Get-WmiObject Win32_NetworkAdapterConfiguration foreach ($adapter in $adapters) { if ($adapter.IPEnabled -eq $true) { $null = $adapter.SetWINSEnableLMHostsLookup($false) } } # Disable NetBIOS over TCP/IP on all network adapters $regkey = "HKLM:SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces" Get-ChildItem $regkey | ForEach-Object { Set-ItemProperty -Path "$regkey\$($_.PSChildName)" -Name NetbiosOptions -Value 2 }
mDNS Remediation: To mitigate this issue you can use the following powershell code, or create a GPO with the same registry update.
# Disable "Automatically detect settings" in Internet Options Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\" -Name EnableMDNS -Value 0 -Type DWord
Unmanaged IPv6 Man in the middle (High)
Finding: This one can be a real headache if you do not have infrastructure in place to handle IPv6 traffic. Most auditing companies will recommend that you enable RA Guard or DHCP guard on all your switches, or on your VMware virtual switches (which requires NSX) to prevent DHCP spoofing. However, you may not have that capability on your switches, I have been in that position before, or maybe you don’t use NSX in your virtual environment.
Impact: Operating systems’ favoring of IPv6 allows attackers to establish unauthorized services and interact with unmanaged hosts. They can set up a rogue DHCPv6 server that, once operational, enables IPv6-capable hosts and devices to obtain IPv6 addresses. This rogue server can also distribute DNS addresses, causing hosts to route DNS requests through the attacker’s system.
On Microsoft Windows systems, DNS settings from DHCPv6 take precedence over those from DHCPv4. If the DHCPv6-assigned DNS server lacks a record, other DNS settings act as a backup. Attackers can exploit this by assigning DNS servers through DHCPv6 Router Advertisements, positioning themselves as the primary option for DNS poisoning while reducing network disruption. This is because any unanswered DNS request by the attacker defaults to the legitimate DNS server.
Such vulnerabilities allow attackers to intercept requests, issue harmful responses, and possibly capture network credentials on Microsoft Windows systems. Exploitation happens when a Windows client uses the malicious DNS server to look up internal hostnames and connects to credential-requiring services like SMB. The attacker can redirect the DNS query, leading the Windows client to an attacker-controlled IP where a decoy SMB service gathers authentication attempts.
Unmanaged IPv6 networks’ exploitation predominantly impacts Microsoft Windows systems due to their DNS assignment preference via DHCPv6 and their common use of services requiring credentials. Other operating systems might also be vulnerable under certain unique and as-yet-unknown conditions.
Remediation: The most effective solution I’ve discovered for addressing this issue is to deploy a DHCP server in every domain configured for IPv6 with extended lease duration, such as 300 days. An alternative method involves assigning a static IPv6 address to every system and device, but this can be overly burdensome. It’s important to recognize that the number of devices using IPv6 on your network is likely greater than anticipated, extending beyond servers to include hardware like iLO interfaces, PDUs, switches, and routers.
Outdated Software and/or Services
Finding: Despite our best efforts, it’s inevitable that a few systems will need version updates. Often, it’s the Linux-based systems that catch users off guard, mainly because they’re not interacted with as frequently as Windows-based systems. The score for each of these findings can vary greatly depending on the severity of the vulnerabilities, if any, in the version you currently are using.
Impact: Malicious individuals often exploit known vulnerabilities in outdated software versions, making them prime targets. Commonly, the initial step in a malicious attack is to scan for known vulnerabilities based on software versions.
Remediation: Update to the latest version, as painful as that can be sometimes it is a vital first step in securing your network against attackers!
WPAD Man-in-the-middle
Finding: WPAD enables hosts to consult various local network resources to pinpoint local proxies, including DNS, Windows Internet Name Service (WINS), and host resolution protocols such as NBT-NS and LLMNR. Authentic proxies supply a wpad.dat file that hosts use to set up their proxy configurations, directing their traffic via the designated proxy.
Impact: Utilizing local host resolution protocols, an adversary within the local network can manipulate the resolution process to corrupt broadcast or multicast requests directed at the WPAD hostname. This type of assault can also be executed through DNS hijacking, IPv6 poisoning, or similar methods that compromise or control DNS lookups. Should the adversary prevail, they can distribute a manipulated wpad.dat file, directing the target to route all web traffic via a proxy server under the adversary’s command, effectively setting up a web-traffic man-in-the-middle attack. The success of such an attack is contingent upon the operating system, the target’s configuration, and the nature of the intercepted web traffic. The attacker, positioned in the middle, might then capture sensitive data such as authentication credentials, web application session IDs, cryptographic hashes, and other critical information, potentially enabling further attacks on additional hosts and systems within the network.
WPAD Remediation: To mitigate this issue there are two steps. Step one under proxy for all network adapters disable the “Auto Detect Settings”, this can be done with a GPO policy for consistency. Step two create a DNS entry for WPAD with an IP of 127.0.0.1
# Disable "Automatically detect settings" in Internet Options Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name AutoDetect -Value 0
Weak SSH Configuration
Finding: Utilizing subpar Key Exchange Algorithms (KEXAlgorithms) that employ frail hash functions (such as sha1) or have key sizes less than 1024 bits could expose SSH connections to decryption and interception by attackers.
Employing feeble Encryption Algorithms (Ciphers) such as those based on DES, RC4, or CBC cipher modes (for instance, AES128-CBC), with key sizes or block sizes under 128 bits, or configurations that permit ‘none’, might enable attackers to recover plaintext from encrypted communications.
Incorporating weak MAC Algorithms (MACs) that rely on compromised hashing algorithms (like md5 or sha1), with key or tag sizes below 128 bits, could compromise the integrity of communications, leaving them vulnerable to tampering by attackers.
Impact: The aforementioned configuration vulnerabilities could potentially allow an attacker to decrypt SSH connections, intercept SSH communications, or compromise the overall security integrity of SSH exchanges.
Remediation: The organization is advised to update SSH configurations to deactivate weak Encryption, MAC, and Key Exchange algorithms. Below are the suggested configurations for each SSH option:
Key Exchange Algorithms (KEXAlgorithms)
- curve25519-sha256@libssh.org
- diffie-hellman-group-exchange-sha256
Encryption Algorithms (Ciphers)
- aes256-gcm@openssh.com
- aes128-gcm@openssh.com
- aes256-ctr
- aes192-ctr
- aes128-ctr
MAC Algorithms (MACs)
- hmac-sha2-512
- hmac-sha2-256
- umac-128@openssh.com
Settings are typically managed within the SSH daemon’s configuration file (sshd_config) on the server itself.
Here’s a general approach to how you would disable weak algorithms in the SSH configuration file:
- Open the SSH daemon configuration file, typically located at /etc/ssh/sshd_config.
- Locate the lines that define Ciphers, MACs, and KexAlgorithms.
- Comment out or remove any weak algorithms from these lines.
- Add strong algorithms that you wish to use. For example:
- Ciphers: aes256-gcm@openssh.com, aes128-gcm@openssh.com, aes256-ctr,aes192-ctr,aes128-ctr
- MACs: hmac-sha2-512, hmac-sha2-256, umac-128@openssh.org
- KexAlgorithms: curve25519-sha256@libssh.org, diffie-hellman-group-exchange-sha256
- Save the changes and restart the SSH service to apply the new configuration.
For example, your sshd_config might include lines like this after modification:
- KexAlgorithms curve25519-sha256@libssh.org, diffie-hellman-group-exchange-sha256
- Ciphers aes256-gcm@openssh.com, aes128-gcm@openssh.com, aes256-ctr,aes192-ctr,aes128-ctr
- MACs hmac-sha2-512, hmac-sha2-256, umac-128@openssh.org
After making these changes, you would typically run sshd -t
to test the configuration for errors and then restart the SSH service using a command like systemctl restart sshd
.
Deprecated TLS Protocol Support – TLS 1.0 or 1.1
Finding: Unsupported versions of the TLS protocol, including TLSv1 and TLSv1.1.
Impact: TLSv1 and TLSv1.1 have been superseded and are not advised for contemporary web browsers, web servers, and other services secured by TLS. The ciphers these protocols employ are inherently weak, and they do not accommodate newer, more robust ciphers and security features. Consequently, these older protocols are considered unreliable for ensuring the confidentiality of communications.
Remediation: Services utilizing TLSv1.0 and TLSv1.1 should be updated to deactivate these outdated protocol versions. Only the more secure and recent protocols, TLSv1.2 and TLSv1.3, should be enabled and supported. I have an entire article on Disabling Deprecated SSL and TLS
ARP Poisoning
Finding: Network switches without ARP spoofing defenses are susceptible to attacks that could result in unauthorized access to the switches and compromise of sensitive data.
Impact: ARP spoofing, or ARP cache poisoning, is a method where fraudulent ARP messages induce a network switch to link an incorrect MAC address with a valid IP address. This allows an attacker to hijack network traffic meant for the true IP address holder, potentially leading to unauthorized access to confidential information.
Remediation: Network administrators are advised to implement Dynamic ARP Inspection (DAI) alongside other ARP spoofing countermeasures on network switches to bolster defenses against ARP spoofing attacks. DAI thwarts the introduction of spurious ARP entries into the ARP cache by validating that each ARP packet’s sender IP and MAC addresses correspond with the DHCP snooping database records, thereby averting ARP poisoning. Enabling ARP inspection and ARP rate limiting further reinforces security; ARP inspection authenticates ARP packets to confirm accurate IP-MAC associations, while ARP rate limiting identifies and rejects abnormal ARP traffic, hindering attackers from inundating the switch with counterfeit ARP messages.
For all network communications, the deployment of secure protocols such as HTTPS and SSH is crucial. These protocols facilitate end-to-end encryption, significantly increasing the difficulty for attackers to intercept and decipher sensitive data. It is also advisable to keep your subnets small so that ARP requests and responses would be easier to manage on the per-subnet level.
COMMENTS