What do we find most commonly? During penetration testing and other red team engagements, we perform for various organizations, our security advisors frequently find the same vulnerabilities.
These vulnerabilities are often what pose a significant risk to organizations as their commonality increases the likelihood of attackers already knowing how to exploit these.
Therefore I’d like to take a moment to illustrate five of these common vulnerabilities, and ideas for mitigating them.
Misconfigured services
Server Message Block
Out of Date versions
Active Directory
Passwords
Misconfigured services
When performing advisory at our customers, one common vulnerability is services that have been improperly configured. These services vary depending on the nature of the organization; however, all these services show commonalities in the vulnerability of their configurations.
When a service is first implemented, more often than not the responsible party is more concerned with getting the service to work as quickly and inexpensively as possible, which often results in services being configured in their default mode or in ways that they’re vulnerable to many different types of attacks.
For example, during a penetration test, we identified a Jenkins build environment for software development. If one reads the Jenkins Handbook, they can identify the script console, which developers can utilize to execute various .groovy scripts, but if improperly configured attackers can utilize this feature to execute arbitrary commands, which may be utilized for exploitation, privilege escalation, lateral movement or inject their own code in the built software which the server is responsible for.
This is not necessarily considered a significant vulnerability so long as access to this feature is limited to only the users whose job requirements involve this type of access. However, in this instance, the customer had chosen to configure the service in such a way that anyone, even users who were not logged in, could make use of any feature, which is very risky as it allows attackers to utilize this feature, start, stop, and even modify build jobs and chains, and even change user’s passwords.
Ideally, all services should be inventoried and configured as recommended by the service provider, and if steps are taken to tighten or loosen the security of a service, then such should be reasoned and documented.
Commonly services can also be integrated with Active Directory or other systems to ensure easy configuration between the service and its users, and it’s important that such integrations are properly configured and that users, regardless of whether the integration is used or not, are only provided the privileges required by their function, or at the very least, that features which could pose a risk to the system, are properly protected.
SMB
Another example of a misconfiguration is Server Message Block (SMB). This feature in Windows is commonly used in organizations to perform filesharing and makes it easier for users to share documents, reports, installation executables, scripts, and data. However, as with many features which have been around for a while, this feature is riddled with vulnerable components which, when improperly configured, can lead to the compromise of servers, workstations, user accounts, service accounts, and even Active Directory.
One example of a vulnerable component is open network shares. As described above, network shares are utilized to perform filesharing, which is not a vulnerability if properly configured. However, often customers have chosen to create these shares and leave them open to anyone on the network, whether for ease of use or ease of creation. But they have neglected to notice what type of data would be stored on this file share, and what security configurations it would necessitate. Depending on the nature of the contents choosing to leave the shares open may be perfectly reasonable, however often these shares contain business-critical files, customer data, files with cleartext passwords, or may even be the system's disc drive itself.
Ideally, the network shares should require authentication to access and depending on their contents be limited to the people to whom their duties necessitate such access.
Another example of a vulnerable component is SMB signing, which is a security mechanism for SMB that helps prevent man-in-the-middle attacks. While it’s enabled by default on domain controllers it’s not on most Windows operating systems, which means that often we find situations in which we can perform man-in-the-middle attacks against users to get their usernames and passwords, which we can then use to attack the Active Directory, workstations, and servers.
Services running on out-of-date versions.
When we are called out to perform an engagement, we often find systems and services which are out of date. There is a broad variety of reasons why a system remains in place on a version long past what is secure, like an OT environment which often runs on archaic operating systems, DB2 servers that cannot be taken down, moved, or replicated, or even business-critical devices which the provider is no longer working on.
The older, and more outdated the version is, the more likely that a vulnerability has been found on that version that can be exploited by attackers. This is unfortunate since when a penetration tester, or threat actor, comes along, this type of service may be the perfect springboard from which they can move laterally across the network and affect other systems.
Such an example was identified by a customer of ours. A server was running an older version of its firmware and was scheduled to be decommissioned, however, when the penetration testers arrived, they found the server and managed to exploit a vulnerability in the outdated version of the software, which resulted in the service and its host being compromised. While the engagement was performed post-2020, the vulnerability was first identified in 2014 and was common enough to be dubbed ShellShock.
Ideally, systems, servers, and their dependencies, whether those be legacy systems or otherwise, should be kept track of in an inventory. An update schedule should be in place to regularly update and upgrade various systems and services.
Legacy systems that cannot be upgraded or replaced, like OT, Windows NT, and Embedded devices, which simply have no effective replacement or where the provider is no longer able to update, must be protected using other security controls, like firewalls, network segmentation, and zero-trust networking.
Active Directory
Most major organizations use Active Directory to manage their employees' accounts. Active Directory can be a cumbersome and challenging system to implement, even for experienced system administrators, and configuring Active Directory securely can be a daunting task. This is why Active Directory vulnerabilities are frequently used for ransomware attacks.
For example, vulnerabilities in accounts can be attacked using Kerberoasting. To keep it simple, it’s a vulnerability in the encryption when using Kerberos, where the password may be derived from the Kerberos ticket using the user’s Service Principal Name (SPN). This we see regularly at customers when performing various services, including penetration tests, where we can grab the Kerberos ticket from somewhere in the environment, find the associated SPN on the domain and then crack it on our own cracking station.
Another example is when a user’s credentials, passwords, and secrets, are stored on the user’s domain object. It’s common we find that a user's password is written in the description of the user’s domain object and sometimes that other services are using custom fields on the user’s domain object to store the user's password. This is commonly due to administrators not realizing that such information can be requested by anyone from anywhere within the environment if they can reach the domain controller.
Learn more about securing Active Directory in Martin Sohn Christensen’s tech blog ‘Basic Microsoft Active Directory Security’.
Passwords
Despite being a relatively well-known vulnerability, we frequently exploit weaknesses regarding passwords and password management to compromise the confidentiality and integrity of systems, services, and user accounts.
Commonly, we identify files and documents containing passwords in clear text which we can later abuse to elevate our privileges or move laterally through the environment. Similarly, we find cleartext passwords written as part of the descriptions or custom metadata fields of Active Directory users, which everyone can then retrieve. Despite decades of reminders to secure passwords, we still find organizations whose employees or service accounts are protected using easily guessable passwords, such as those which have dates, names, the company name, slogan, and/or similar themes in easily guessable formats.
Ensuring employees are aware of the dangers of having weak passwords and that they are also responsible for promoting good password management is paramount for organizations that deem security an important goal. We frequently recommend organizations make use of security awareness courses, as well as ensure that certain password-based protective measures like LAPS are utilized.
To avoid passwords being written in clear text, or simply forgotten by not writing them down at all, we often recommend organizations utilize and promote the usage of password managers, like LastPass or Bitwarden to store passwords. Proper utilization of such a tool ensures that passwords are not written in cleartext in files deliberately by users.
As for passwords in configuration files, proper access control is key for files that may contain passwords. Ensuring that configuration files for software, which sometimes contain passwords, are not stored on company-wide shares without limiting the access to only the select few employees who require such access.
What can be done?
Despite what many people would believe, immediate mitigation is not always the best course of action. Mitigating a vulnerability immediately as it’s discovered without identifying the root cause of a vulnerability won’t ensure that it or a similar one won’t reappear. For instance, simply upgrading a system to the newest version, does not rule out that it won’t fall behind on versions in the future, and simply ensuring that one service is properly configured does not mean another server in the future will be set up correctly either. As professionals, we are obliged not only to ensure that vulnerabilities are found and mitigated, but also that similar vulnerabilities will not reappear without being addressed.
This should be taken into consideration whenever vulnerabilities are discovered and should be mitigated. Ideally, an organization that aspires to improve its security by mitigating vulnerabilities and their root cause should look at the Plan-Do-Check-Act model and utilize it effectively:
While we won’t go into detail about the model in this article, we can briefly state that the PDCA model is a circular flow in which changes to an environment are planned out, performed on a limited scale, checked for efficiency, and then acted upon to ensure proper rollout or revisualization.
We recommend using this model to implement the following recommendations, which will mitigate the vulnerabilities we commonly find in customer environments.
Proper password policies
When we create password policies it’s to establish a minimum baseline common users must follow to ensure security amongst accounts, however, if these baselines are set too low, we risk putting our users and the systems they utilize at risk, as users tend to leap over the shortest fence.
Ensuring the password policies require users to create strong passwords is a strong start. Depending on whose recommendations you follow, varying recommendations are given, however, the consensus found in Microsoft's password policy recommendations, NIST Special Publication 800-63B, and OWASP Cheat Sheet Series amongst others, is that password length is more important than complexity, that passwords should not be reused between different systems, accounts or platforms, and that common or easily guessable passwords should be avoided.
At Improsec we provide password filtering and auditing solutions, which allows IT departments to easier detect and prevent the usage of weak passwords. You can find more information about this tool in Valdemar Carøe’s blog Improsec Password Solutions.
Update and patch management
While certain client software often comes with automatic updates and patching, not all software has that luxury, but simply neglecting these software updates is not an option as seen above, so establishing a software update schedule is crucial to ensure security patches are applied.
While “keeping software up to date” sounds simple, every IT professional knows that keeping all company software up to date can be challenging for a great variety of reasons.
To keep all hard- and software up to date, it must be inventoried, managed, and tracked, so before establishing an updated schedule, inventorying one’s assets is paramount to success. Once this inventory has been established, along with procedures for bringing up and tearing down systems and services, an organization can begin establishing policies to manage updated schedules. How regularly these updates will be performed, on what systems, and when depends entirely on its role and operational capacity. For instance, scheduling a daily update for a system that runs 24 hours a day 365 days a year can be a challenge for the business if that system is the only one capable of performing the function, so establishing proper procedures for these updates is important.
To assist in accomplishing this colossal quest, parts of its objectives can be managed using automatic patching utilizing grouped rollout.
Microsoft System Center Configuration Manager (SCCM) is a patch management solution that allows for easy rollout and management of patches and updates for Windows hosts. Its replacement Microsoft Endpoint Configuration Manager (MECM) combines SCCM and Intune, allowing for greater levels of patch management. SCCM is ideal for environments that contain legacy systems, like Windows NT and Windows Embedded, and other systems which may not be able to withstand the end-of-life updates for DES and RC4 coming to Microsoft servers.
Another option is Azure Update Management which can be used to perform patch management on both Azure and non-Azure machines, most notably Windows and Linux systems. Using its Log Analytics agent, it retrieves information about the host and then utilizes the WSUS and responsible repositories for installing the updates, based on rulesets defined by the administrators.
While neither option is inexpensive, they are comparatively cheaper than manually updating systems and services, as well as the risks it would entail.
The principle of least privilege
When handling sensitive data, whether it be personal data, like documents involving personal information, or technical data, like key files and client certificates, these should be protected and handled responsibly, so that no unauthorized parties have access to them.
Network shares that contain this kind of information may make it easier for various members of the organization to share data and files, but if improperly configured, may not be adequately protective of its contents, which means any data contained within may be left vulnerable to attackers, who may use this data for further attacks.
In this case, it’s more secure to utilize the principle of least privilege, which states that any accessible data, resource application, and functionality should be accessible only to the users who need it.
Despite mentioning this, concerning sensitive data and resources its application can span a great variety of accesses, including active directory, most notably Microsoft Active Directory Tiering.
While this may not hinder any immediate compromise, it will result in a limited impact on the organization, should such an account be compromised, which will then limit what capabilities an attacker has used such accounts.
NIST Special Publication 800-53 AC-6 further defines Least Privilege and can be utilized to aid organizations in their quest to include the principle to enhance their security posture.
As we too often see accounts with extensive privileges in an environment, the compromise of such an account could be devastating, and had the organizations limited these users’ accessibility to only those resources they needed, we’d have had a harder time.
Following provider guidelines for security
While some products feature pre-enabled security features, some features may not be enabled which could improve an organization’s security posture. Other times these security features are disabled to expedite productive growth.
While many of these security features may impact the ability of workers to make use of the system and accomplish their tasks, these security features are also the ones that interfere with attackers’ capability to leverage the system to advance their compromise of the environment quickly and easily.
We recommend that organizations make use of the security guidelines put forth by their service providers, and upon updating ensure that any changes to security features are taken into consideration and that any security feature actively disabled is documented and depending on impact criticality signed off by the management level responsible for making this decision.