This article is part of a series where we look at a recent NSA/CISA Joint Cybersecurity Advisory on the top cybersecurity issues identified during red/blue team exercises operated by these organizations. In this article you will find a more in-depth look at the specific issue, with real-world scenarios where it is applicable, as well as mitigation strategies that can be adopted to limit or overcome it. This expands on the information provided by the NSA/CISA report.

–

Often, the default configurations provided by manufacturers are not optimized for security, leaving systems vulnerable to attacks. Default configurations of system services and applications can inadvertently open doors to unauthorized access and malicious activities or facilitate adversarial reconnaissance operations by relying on well-known operational conditions. 

Two significant issues are prevalent: default credentials and permissive default service permissions and configuration settings. These configurations, intended for ease of setup and use, often become the weakest link in cybersecurity. 

Real-World Impact

When deploying a well-known software stack (for example, LAMP – Linux, Apache, Mysql, and PHP), the resulting system state can easily be inferred and replicated. This makes it easy to recreate a potential target’s system and probe for vulnerabilities, instead of triggering monitoring and alert systems on probe attempts by threat actors against the actual systems. It will also make it easier for an adversary to identify potential attack vectors by simply identifying one component and then assuming (correctly) that the entire stack is present.

Default Configuration Issues

In their red/blue team tests, the NSA and CISA found the following common examples:

Default Credentials

Commercial Off-The-Shelf (COTS) network devices often come with predefined default credentials for administrative accounts. These are easily discoverable and exploitable by malicious actors for unauthorized device access, resetting administrative accounts, or leveraging VPN credentials. Furthermore, devices like printers, scanners, and IoT devices, with their loaded privileged domain accounts, can provide attackers with lateral movement capabilities within a network.

In the past, very high-profile incidents occurred, or were exacerbated, by exploiting such default configurations. Botnets targeting IoT devices, in particular, thrive and grow in environments where movement and discovery of new bots is made by exploiting known default configuration states, thus enabling fast and simple spread of the botnet across multiple devices, networks and organizations.

Insecure Active Directory Certificate Services (ADCS)

ADCS, a critical component in managing Public Key Infrastructure (PKI) within Active Directory environments, can be compromised due to template misconfigurations. For instance, enabling web enrollment without adequate protections can allow attackers to obtain fraudulent certificates, impersonate legitimate entities, and gain unauthorized access to critical systems and data.

Insecure Legacy Protocols and Services

Vulnerable network services such as LLMNR and NetBIOS Name Service in Windows can be exploited through spoofing, poisoning, and relay techniques. These protocols, if left enabled, allow attackers to intercept domain hashes and gain system access, posing a significant threat to Windows environments.

Insecure Server Message Block (SMB) Service

The SMB service, primarily used for file sharing in Windows, is another victim of insecure default settings. The lack of mandatory SMB signing allows attackers to perform machine-in-the-middle attacks, accessing remote systems without needing to capture and crack hashes.

While these results seem to indicate that the problem is more prevalent on Windows-based networks, that is not necessarily the case. The results can simply have been skewed by the available test environments. Known default configurations can, and in fact do, affect any type of operating system and environment. For example, most Linux distributions will ship with an enabled sshd (secure shell daemon) configuration that does not enforce key-based login (or even enables it) by default, even if that form of authentication is more resilient than traditional login and password. Another common default configuration is the lack of any brute-force protection on the same sshd service, making any newly deployed (and Internet-facing) Linux system immediately a target for armies of bots probing for vulnerable accounts through trial and error.

Mitigation Strategies

To combat these vulnerabilities, it is crucial to modify the default configurations of applications and appliances before their deployment. This includes changing or disabling vendor-supplied default usernames and passwords and enforcing the use of strong passwords. For ADCS, ensure secure configurations by updating and patching infrastructure, employing robust monitoring and auditing mechanisms, and implementing stringent access controls. Reviewing and restricting permissions on ADCS templates is also essential to prevent unauthorized certificate issuance.

As a more invasive strategy, systems should not be left in a usable state immediately after deployment. When a system is deployed and is immediately usable, then the benefits of changing the configuration will become diminished. Thus, making it so that the default state is not immediately usable would make the need for configuration changing mandatory rather than optional. While this runs counter to expectations and has some detractors, it would also force IT teams to intentionally apply environment-specific configuration modifications that would make one deployment different from the next, greatly reducing this type of risk. This type of approach, while more effective, thus has some disadvantages – namely the increase in workload and time-to-deploy of new systems.

In short, some possible strategies to mitigate the problem include:

Modify Default Configurations Before Deployment

Change or disable default usernames and passwords before deploying systems. Employ strong passwords and adhere to vendor-provided security guidelines.

Employ Configuration Management Tools

Use automated tools for configuration management to ensure secure deployment from the outset.

Incorporate Regular Audits and Updates

Conduct regular audits of configurations and apply necessary updates to address vulnerabilities.

Educate and Train Employees

Implement comprehensive training programs to increase awareness of the risks associated with default configurations. This is especially important in BYOD environments, where the risk of default configurations comes from foreign devices.

Implement a Non-Usable Default State Policy

Deploy systems in a non-usable default state to compel IT teams to apply necessary security configurations. Discuss the trade-offs of this approach, such as increased deployment time and potential resistance.

Continuous Monitoring and Logging

Establish continuous monitoring and logging practices to detect unauthorized changes to configurations. Consider creating alerts for default configurations being present in a system.

The post Default Configurations of Software and Applications in Cybersecurity appeared first on TuxCare.

*** This is a Security Bloggers Network syndicated blog from TuxCare authored by Joao Correia. Read the original post at: https://tuxcare.com/blog/default-configurations-of-software-and-applications-in-cybersecurity/