In the third segment of our series, we pick up from where we concluded previously, delving deeper into the prevalent vulnerabilities uncovered during penetration testing. We will not only identify these common security weaknesses but also provide comprehensive strategies for their remediation.
In the third segment of our series, we pick up from where we concluded previously, delving deeper into the prevalent vulnerabilities uncovered during penetration testing. We will not only identify these common security weaknesses but also provide comprehensive strategies for their remediation. This part aims to equip you with the necessary knowledge to effectively address and secure your systems against these vulnerabilities, enhancing your network’s resilience against potential cyber threats. By understanding the intricacies of these security gaps and implementing the suggested corrective measures, you can significantly bolster your defenses and maintain the integrity of your digital infrastructure.
- 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)
Accessible Network Shares
Finding: This kind of finding often pertains to a network share that any authenticated user can access, regardless of whether they have read-only or edit permissions. The presence of sensitive data within such a share amplifies the severity of this vulnerability. When access controls are lax, there’s a heightened risk that unauthorized individuals could view or modify confidential information, potentially leading to data breaches, intellectual property theft, or compliance violations.
Impact: Allowing unrestricted access to network shares can result in unintended data exposure or malevolent activities, contingent upon the nature of the data within these shares. If sensitive or confidential information is accessible without proper authorization, it could lead to significant security breaches. This vulnerability might be exploited by malicious actors to extract valuable data, leading to financial loss, reputational damage, or legal consequences for the organization. It’s crucial to implement stringent access controls and regular audits to mitigate these risks and protect the integrity of the data.
Remediation: The technical team of the organization is advised to review network shares to check for any improperly stored sensitive data. By default, user accounts should be restricted from accessing sensitive file shares, with access provided strictly when necessary. Given the types of sensitive data routinely handled and accessed during standard operations, the organization is recommended to invest in an automated solution that identifies and alerts about the existence of commonly sensitive data, including protected health information (PHI), personally identifiable information (PII), and cardholder data (CD), which may be unintentionally located across network sites.
Default Credentials on Devices
Finding: Devices that permit access to multiple services using default credentials present a security risk. To enhance system security, it is a fundamental best practice to have administrators configure authentication settings to establish unique credentials prior to deploying these devices for production use. This proactive measure ensures that each device has a distinct and secure authentication process, reducing the likelihood of unauthorized access and potential security breaches.
Impact: The level of privileges linked to the identified user accounts is crucial; if default credentials are used for access, it could jeopardize the host’s security. Although these default credentials grant only read access, which somewhat limits their threat, altering them is essential to minimize the network’s vulnerability. Since certain exploits necessitate authentication, eliminating all potential methods of gaining authenticated status is a proactive step in thwarting various attack vectors.
Remediation: The organization must update passwords for all devices to ensure each account or service is secured with a distinct, non-default password. These passwords should comply with the organization’s standards for password length and complexity. In the absence of specific guidelines, passwords should be at least 14 characters long and include at least one of each of the following:
- Uppercase Letter
- Lowercase Letter
- Special Character
- Number
For any devices that currently lack authentication requirements, it is imperative to implement authentication measures before permitting access to the relevant resources. Addressing this issue is particularly crucial for resources that pose a significant business risk if compromised due to unauthorized access.
SMB Signing Disabled
Finding: The current configuration indicates that SMB message signing is optional on remote SMB servers. This setting can pose a security risk, as SMB message signing helps to prevent man-in-the-middle attacks by ensuring that the data has not been tampered with during transit. Without requiring SMB message signing, there’s an increased chance that data could be intercepted and altered without detection. It’s recommended to enforce SMB message signing on all servers to maintain the integrity of the data and enhance the overall security posture of the network. By doing so, organizations can protect against certain types of cyber attacks and ensure that communications between clients and servers remain secure.
Impact: An unauthenticated, remote attacker can take advantage of hosts that lack SMB signing to launch man-in-the-middle attacks on the SMB server. This vulnerability allows for an NTLM relay attack, where network authentication attempts are captured and rerouted to the intended host. A successful attack of this nature could lead to the exposure of sensitive information or even complete control of the target host, especially if the credentials used have extensive privileges. It is crucial to enforce SMB signing to prevent such security breaches and protect the network’s integrity.
Remediation: The implications of not enforcing SMB signing extend beyond servers to encompass a variety of devices within a network, including NAS devices, iLO, iDRAC, and more. It’s imperative to have a comprehensive understanding of your network’s architecture and the devices connected to it. In some cases, monitoring network traffic—specifically for SMB communications—may be necessary to identify devices that aren’t enforcing SMB signing.
To ensure the security of SMB transactions across your network, SMB signing should be mandated through Group Policy. This process involves:
To activate SMB Signing through Group Policy, initiate the Group Policy Management interface. This can be accessed via the Server Manager by navigating to Tools > Group Policy Management, or by executing gpmc.msc in PowerShell or Command Prompt. You may opt to formulate a new policy dedicated to SMB packet signing or modify an existing one to suit your requirements.
Proceed to the following path within the policy editor: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
Here, you will find four policy settings related to SMB packet signing, each of which can be toggled on or off based on your operational needs:
SMB Server Packet Signing:
- Microsoft network server: Digitally sign communications (always) – This setting mandates SMB packet signing for all server communications, ensuring that data integrity is verified before any interaction with an SMB client. It is automatically active on domain controllers but not on other servers. Enabling this setting across the board guarantees that all SMB communications are authenticated, potentially disrupting connections with clients that do not support SMB signing.
- Microsoft network server: Digitally sign communications (if client agrees) – This setting allows the SMB server to engage in SMB packet signing if the client requests it. It’s a default setting for domain controllers, promoting secure communication when possible.
SMB Client Packet Signing:
- Microsoft network client: Digitally sign communications (always) – When enabled, this policy ensures that the SMB client will insist on SMB packet signing for all interactions. If the server is non-compliant, the client will refuse connection. This policy is disabled by default, allowing SMB communication without mandatory packet signing.
- Microsoft network client: Digitally sign communications (if server agrees) – This default-enabled policy lets the SMB client seek SMB packet signing with the server. Disabling it prevents the client from initiating any SMB packet signing negotiations. This setting is typically suitable for modern Windows operating systems.
Remember to assess the compatibility of your devices, such as printers, with SMB Signing to avoid connectivity issues. Implementing these policies enhances security by preventing unauthorized data interception and manipulation.
Weak TLS/SSL configuration
Finding: Support for Weak Cipher Suites: Employing weak cipher suites, especially those marked as EXPORT or utilizing the Data Encryption Standard (DES), can significantly lower the difficulty for an attacker aiming to breach secure communications. These outdated encryption methods are more susceptible to cryptographic attacks, which could compromise the confidentiality and integrity of data transmission.
Support for Medium Strength Cipher Suites: Utilizing cipher suites of medium strength, characterized by encryption keys shorter than 64 bits or longer than 112 bits, or those employing CBC mode or 3DES, can facilitate an attacker’s ability to partially decrypt web traffic. This vulnerability may lead to the exposure of sensitive data such as session cookies, Basic Authentication credentials, and other encrypted communication details, posing a substantial security risk. It is crucial to update and enforce stronger encryption standards to safeguard against such threats.
Impact: Misconfiguration issues within a network’s security protocols can present significant vulnerabilities. These weaknesses could enable an attacker to decrypt and access plaintext information from what was supposed to be secure communications. Furthermore, such misconfiguration may facilitate man-in-the-middle attacks, where an attacker intercepts and potentially alters communications between two parties without their knowledge. This not only breaches the confidentiality of the data being exchanged but also compromises its integrity. To maintain robust security, it is essential to regularly audit and rectify any configuration errors that could undermine the effectiveness of encryption and other protective measures. Doing so helps to safeguard against unauthorized access and ensures the reliability of data transmission within the network.
Remediation: I have a complete detailed article on this subject that I did a couple years ago. Disabling SSL 2.0/3.0 and TLS 1.0/1.1
Weak RDP configuration
Finding: The Remote Desktop Protocol (RDP) setup was found to be lacking the enforcement of Network Level Authentication (NLA). This configuration oversight can lead to a range of security issues. NLA adds an extra layer of security by requiring users to authenticate before establishing a full RDP session.
Impact: Without NLA, unauthorized users could potentially initiate a session and attempt to exploit other vulnerabilities to gain access to the system. It’s crucial to configure RDP to enforce NLA, which will help protect against unauthorized access attempts and reduce the server’s exposure to potential attacks. Implementing NLA is a key step in hardening RDP servers and ensuring that only authenticated users can establish remote desktop connections.
Remediation: Network Level Authentication (NLA) is a security feature in Remote Desktop Protocol (RDP) services that adds an additional layer of authentication before establishing a remote desktop session. Essentially, NLA acts as a gatekeeper, ensuring that only authorized users can initiate a full RDP connection to a server or another computer.
Enabling Network Level Authentication (NLA) for Remote Desktop Protocol (RDP) is a security measure that can be implemented to ensure that only authenticated users can establish RDP sessions. Here’s a step-by-step guide on how to enable NLA:
- Open System Properties:
- Press
Win + Rto open the Run dialog. - Type
sysdm.cpland press Enter to open System Properties.
- Press
- Navigate to the Remote Tab:
- In the System Properties window, go to the “Remote” tab.
- Modify Remote Desktop Settings:
- Under Remote Desktop, locate the section titled “Remote Desktop”.
- Check the option that says “Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)”.
- Apply the Changes:
- Click “Apply” and then “OK” to save the changes.
- Group Policy (Optional):
- For organizations using Group Policy, navigate to:
- Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.
- Find and enable the policy “Require user authentication for remote connections by using network level authentication”.
- For organizations using Group Policy, navigate to:
By following these steps, you’ll ensure that NLA is enabled, which adds a layer of security by requiring users to authenticate before an RDP session is fully established
HTTPS not required
Finding: The web application’s current configuration does not mandate encryption for critical operations. Despite the availability of HTTPS, which provides secure communication, users can still navigate the site and carry out sensitive transactions, such as form submissions, over the unsecured HTTP protocol. This oversight could expose sensitive data to potential interception and compromise the confidentiality and integrity of user interactions. It is essential to enforce HTTPS across all pages, especially for actions involving sensitive information, to ensure secure and encrypted communication.
Impact: Failing to enforce HTTPS for traffic permits users to access internal websites unencrypted. While this may not seem like a substantial security risk, it leaves an opening for attackers to easily intercept credentials transmitted over the network, as they are not protected by encryption. This vulnerability underscores the importance of implementing HTTPS to secure user data and prevent unauthorized access.
Remediation: Some systems are designed to enforce HTTPS by default, often through URL rewriting rules that redirect HTTP traffic to HTTPS, ensuring secure communication. However, not all systems have this capability built-in. In scenarios where enforcing HTTPS is not feasible, alternative security measures should be implemented to mitigate the associated risks. This could include network-level controls, such as firewalls and intrusion detection systems, or application-level measures like secure cookies and content security policies. It’s crucial to apply these controls diligently to protect data and maintain the integrity of communications, especially when handling sensitive information.
COMMENTS