Category: Linux

Adobe Commerce Unauthorized XXE Vulnerability

By Security News
July 8, 2024

Overview

The SonicWall Capture Labs threat research team became aware of an XML External Entity Reference vulnerability affecting Adobe Commerce and Magento Open Source. It is identified as CVE-2024-34102 and given a critical CVSSv3 score of 9.8. Labeled as an Improper Restriction of XML External Entity Reference (‘XXE’) vulnerability and categorized as CWE-611, this vulnerability allows an attacker unauthorized access to private files, such as those containing passwords. Successful exploitation could lead to arbitrary code execution, security feature bypass, and privilege escalation.

A proof of concept is publicly available on GitHub. Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8, and earlier and Magento Open-Source versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8, and earlier are vulnerable. Although Magento Open Source is popular mainly for dev environments, according to Shodan and FOFA, up to 50k exposed Adobe Commerce with Magento template are running.

Technical Overview

Magento (Adobe Commerce) is a built-in PHP platform that helps programmers create eCommerce websites and sell online. It is an HTTP PHP server application. Such applications usually have two global entry points: the User Interface and the API. Magento uses REST API, GraphQL, and SOAP.

Attackers can leverage this vulnerability to gain unauthorized admin access to REST API, GraphQL API, or SOAP API, leading to the disclosure of confidential data, denial of service, server-side request forgery (SSRF), port scanning from the perspective of the machine where the parser is located, and complete compromise of affected systems. This vulnerability poses a significant risk due to its ability to exfiltrate sensitive files, such as app/etc/env.php, containing cryptographic keys used for authentication, as shown in Figure 1. This key is generated during Magento 2 installation process. Unauthenticated actors can utilize this key to forge administrator tokens and manipulate Magento’s APIs as privileged users.

Figure 1: app/etc/env.php

The vulnerability is due to improper handling of nested deserialization in Adobe Commerce and Magento. This allows attackers to exploit XML External Entities (XXE) during deserialization, potentially allowing remote code execution. Unauthorized attackers can craft malicious JSON payloads that represent objects with unintended properties or behaviors when deserialized by the application.

Triggering the Vulnerability

XML External Entities (XXE) attack technique takes advantage of XML’s feature of dynamically building documents during processing. An XML message can provide data explicitly or point to a URI where the data exists. In the attack technique, external entities may replace the entity value with malicious data, alternate referrals, or compromise the security of the data the server/XML application has access to.

In the example below, the attacker takes advantage of an XML Parser’s local server access privileges to compromise local data:

  • The sample application expects XML input with a parameter called “username.” This parameter is later embedded in the application’s output.
  • The application typically invokes an XML parser to parse the XML input.
  • The XML parser expands the entity “test” into its full text from the entity definition provided in the URL. Here, the actual attack takes place.
  • The application embeds the input (parameter “username,” which contains the file) in the web service response.
  • The web service echoes back the data.

Attackers may also use External Entities to have the web services server download malicious code or content to the server for use in secondary or follow-on attacks. Other examples wherein sensitive files can be disclosed are shown in Figure 2.

Figure 2: Disclosing targeted files.

Exploiting the Vulnerability

A crafted POST request to a vulnerable Adobe instance with an enabled Magento template is the necessary and sufficient condition to exploit the issue. An attacker only needs to be able to access the instance remotely, which could be over the Internet or a local network. A working PoC with a crafted POST query aids in exploiting this vulnerability. Figure 4 shows a demonstration of exploitation leveraging the publicly available PoC.

Exploiting CVE-2024-34102, steps are enumerated below, which will exfiltrate the contents of the system’s password file from the target server.

  • Create a DTD file (dtd.xml) on the attacker’s machine. This file includes entities that will read and encode the system’s password file, then send it to your endpoint.
  • Host the dtd.xml file on the attacker’s machine, accessible via HTTP on a random port.
  • Send the malicious payload via a sample curl request to the vulnerable Magento instance, as shown in Figure 3. The payload includes a specially crafted XML payload referencing the DTD file hosted on the attacker’s machine.
  • The XML parser in Magento will process the DTD file, triggering the exfiltration of the system’s password file as shown in Figure 4.
  • Lastly, observe your endpoint to capture and decode the exfiltrated data.

Figure 3: CVE-2024-34102 attack request

00:00

00:15

Figure 4: CVE-2024-34102 Exploitation

Out of the 50k exposed Magento instances in the wild, multiple events were observed wherein attackers leveraged this vulnerability, as only 25% of instances have been updated since the vulnerability was exploited in the wild. According to Sansec analysis, CVE-2024-34102 can be chained with other vulnerabilities, such as the PHP filter chains exploit (CVE-2024-2961), leading to remote code execution (RCE).

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:

  • IPS: 4462 – Adobe Commerce XXE Injection

Remediation Recommendations

Considering the severe consequences of this vulnerability and the trend of nefarious activists trying to leverage the exploit in the wild, users are strongly encouraged to upgrade their instances, according to Adobe advisory, to address the vulnerability.

Relevant Links

Source :
https://blog.sonicwall.com/en-us/2024/07/adobe-commerce-unauthorized-xxe-vulnerability/

The Potential Impact of the OpenSSH Vulnerabilities CVE-2024–6387 and CVE-2024-6409

By: Jagir Shastri
July 17, 2024
Read time: 5 min (1331 words)

We check the OpenSSH vulnerabilities CVE-2024–6387 and CVE-2024-6409, examining their potential real-world impact and the possibility of exploitation for CVE-2024–6387 in x64 systems.

Introduction

CVE-2024–6387, also known as “regreSSHion,” is a vulnerability that exists in OpenSSH, a widely-used suite of secure networking utilities based on the SSH protocol. This vulnerability, which was discovered in July 2024, allows for remote unauthenticated code execution, potentially providing attackers root privileges on affected systems. The Common Vulnerability Scoring System (CVSS) has rated this vulnerability with a score of 9.8

The OpenSSH vendor advisory mentions that the successful exploitation of CVE-2024-6387 has been demonstrated on 32-bit Linux and GNU C Library systems with (ASLR). It also mentions that exploitation on 64-bit systems might be possible but this has not been demonstrated at the time of publishing.

On July 8, another similar vulnerability, the signal handler race condition CVE-2024-6409 was discovered. This flaw occurs when a client fails to authenticate within the LoginGraceTime period, which is 120 seconds by default, and 600 seconds in older OpenSSH versions. Consequently, this can lead to a signal handler race condition in the cleanup_exit() function within the child process of the SSHD server.

Figure 1. How the exploit works
Figure 1. How the exploit works

The “regreSSHion” vulnerability arises from the unsafe handling of the SIGALRM signal during SSH authentication. When the LoginGraceTime expires, the SIGALRM signal is raised, and the corresponding handler performs certain actions, including calling non-async-signal-safe functions like syslog(). This can create a race condition, where the timing of operations could lead to memory corruption or other unexpected behaviors.

SIGALRM
SIGALRM is a signal in Unix-like operating systems that indicates an alarm or timer expiration. When a process sets and a function triggers, it schedules a SIGALRM signal to be sent to the process after a specified number of seconds. This signal is commonly used for timing operations, such as implementing timeouts for network requests or scheduling periodic tasks. Processes can define custom signal handlers to respond to SIGALRM, allowing them to perform actions such as terminating processes, resetting timers, or managing execution time limits. Overall, SIGALRM facilitates time-sensitive operations within Unix processes by providing a mechanism to handle scheduled alarms and timing events.

Exploiting CVE-2024–6387 requires an attacker to initiate thousands of connection attempts to trigger the race condition accurately. The process involves repeatedly setting and resetting LoginGraceTime, causing the server to invoke the SIGALRM signal handler. This requires precise timing and proper inputs to manipulate the server’s memory layout, leading to heap corruption and code execution.

Signal handlers
Signal handlers are special functions that get called in response to specific signals sent to a program. These signals can be generated, either by the operating system or by the program itself. However, not all functions are safe to call from within a signal handler since they may not be reentrant, therefore cannot safely be interrupted and called again (“async-signal-safe”). For instance, syslog() is a function used to log messages to the system logger and is not considered async-signal-safe.

Researchers have found that approximately 10,000 attempts are needed to successfully exploit this vulnerability. While the exploit could take days to complete, it is still not guaranteed that the attempt would be successful . The presence of modern security mechanisms such as Address Space Layout Randomization (ASLR) and No-eXecute (NX) bits further complicate the exploitation process but do not entirely mitigate the risk.

CVE-2024-6409 technical details

Like CVE-2024-6387, this vulnerability occurs when the SSHD’s SIGALRM handler is called asynchronously, which in turn calls various functions that are not async-signal-safe.

The race condition in grace_alarm_handler() calls cleanup_exit() from the privsep child process. However, cleanup_exit() is not designed to be called from a signal handler, potentially invoking unsafe functions. Cleanup function calls can be interrupted by signals, causing unsafe state changes and potential remote code execution (RCE).

As a privsep child process run’s with reduced privileges, there is less reason to worry about the vulnerability. In addition, working exploits for the CVE-2024-6409 have not been yet discovered, therefore proof of its actual exploitation has not been established at the time of publishing.

Exploitability of CVE-2024-6387 in x64 Systems

The OpenSSH vendor advisory mentions that the successful exploitation of CVE-2024-6387 has been demonstrated on 32-bit Linux and GNU C Library (glibc) systems with (ASLR). It also mentions that exploitation on 64-bit systems might be possible. However, certain characteristics of X64 systems make this exploitation much more difficult, which we’ll expound on in this section.

In x64 systems, ASLR plays a crucial role by randomizing memory addresses, including those of the GNU C Library (glibc), with each program execution. This randomness makes it very difficult for attackers to predict the location of the glibc base address, thus mitigating exploits that depend on precise memory targeting. The x64 architecture’s expansive address space further complicates exploitation, as attackers have to guess an exponentially greater amount of addresses. Combined with security measures such as stack canaries and NX bits, exploiting vulnerabilities such as CVE-2024-6387 becomes highly impractical on x64 systems.

While theoretically possible under specific conditions, the effective implementation of ASLR and the inherent complexities of the x64 environment significantly reduce real-world exploitability, highlighting the robust security benefits of these architectural safeguards.

Potential impact

Our As per our internal telemetry we did not notice any trend change for CVE-2024–6387, which could be considered a known exploited vulnerability (KEV)that is being exploited in wild. .

While CVE-2024–6387 presents a critical security risk, its real-world impact is mitigated by several factors. The technical complexity of the exploit and the extensive time required to execute it make large-scale attacks impractical. Each attack attempt resets the login timer, requiring precise timing and substantial effort from the attacker.

Moreover, the vulnerability affects specific versions of OpenSSH (up to 4.4p1 and 8.5p1 to 9.7p1) running on Linux systems using the GNU C Library. Systems with additional protections against brute force attacks and distributed denial-of-service (DDoS) are less likely to be successfully exploited. Therefore, while targeted attacks are possible, mass exploitation is unlikely due to the unavailability of working exploits and the time required to exploit these vulnerabilities.

Mitigation

To mitigate the risks associated with CVE-2024–6387, administrators should immediately update OpenSSH to version 9.8 or later. If immediate updating is not feasible, reducing the LoginGraceTime can provide temporary mitigation against this vulnerability.

Additionally, organizations can consider implementing the following best practices for general vulnerability exploit protection:

Patch management
Regularly updating and patching software, operating systems, and applications is the most straightforward method for organizations to avoid the exploitation of vulnerabilities within their systems.

Network segmentation
Separating critical network segments from the larger network can minimize the impact of a potential vulnerability exploitation.

Regular security audits
Performing security audits and vulnerability assessments can identify and remediate potential weaknesses within the infrastructure before they can be exploited.

Security awareness training
Educating employees about the common tactics used by attackers can help them avoid falling victim to social engineering attacks that might precede vulnerability exploitation.

Incident response plan
Developing, testing, and maintaining an incident response plan can help organizations quickly and effectively respond to security breaches and vulnerability exploitations.

Additionally, employing network-based access controls, intrusion prevention systems such as Trend Vision One™, and regular vulnerability scanning can further enhance security.
For Trend customers, the following IPS smart rules can detect the attack on a surface level:

  • 1003593 Detected SSH Server Traffic (ATT&CK T1021.004)
  • 1005748 Multiple SSH Connection Detected (ATT&CK T1499.002, T1110)

Conclusion

According to other researchers, there could be non-functional exploits in circulation that claim to be working proofs-of-concept (POCs) for CVE-2024-6387. These fake exploits contain payloads that download files from remote servers and establish persistence on the systems of security researchers. Assuming they are testing a legitimate POC for the vulnerability, the security features of their systems might be disabled, making them vulnerable to malicious activities.

Overall, while CVE-2024–6387 and CVE-2024-6409 is a critical vulnerability, it does not pose a widespread threat to the internet due to its exploitation complexity and existing mitigations. However, administrators should remain vigilant, apply patches promptly, and implement recommended security practices to protect their systems.

Source :
https://www.trendmicro.com/en_us/research/24/g/cve-2024-6387-and-cve-2024-6409.html

WordPress 6.5.5 Security Release – What You Need to Know

Alex Thomas
June 25, 2024

Did you know Wordfence runs a Bug Bounty Program for all WordPress plugin and themes at no cost to vendors? Researchers can earn up to $10,400, for all in-scope vulnerabilities submitted to our Bug Bounty Program! Find a vulnerability, submit the details directly to us, and we handle all the rest. For a limited time, all high risk issues are in-scope for all researchers!

WordPress Core 6.5.5 was released yesterday, on June 24, 2023. Contained within this release are three security fixes addressing two Cross-Site Scripting (XSS) vulnerabilities and one Windows-specific Directory Traversal vulnerability. Despite these vulnerabilities being medium-severity, the worst of them (specifically, the XSS vulnerabilities) can allow for site takeover by an authenticated, contributor-level user if successfully exploited.

The Directory Traversal vulnerability has been backported to every version of WordPress since 4.1, with the XSS vulnerabilities being backported to the major version in which the functionality was released. WordPress has supported automatic core updates for security releases since WordPress 3.7, and the vast majority of WordPress sites should receive a patch for their major version of WordPress automatically over the next 24 hours. We recommend verifying that your site has been automatically updated to one of the patched versions. Patched versions are available for every major version of WordPress since 4.1, so you can update without risking compatibility issues.

The Wordfence Threat Intelligence Team released a new firewall rule the same day to protect Wordfence Premium, Wordfence Care, and Wordfence Response customers for one of the XSS vulnerabilities that didn’t have adequate protection.This rule will be available to free Wordfence users in 30 days, on July 24th, 2024. All Wordfence users have protection for the remaining two vulnerabilities.

If your site has not been updated automatically we strongly recommend updating manually as soon as possible, as two of the vulnerabilities patched in this release can be used by an attacker with a low-privileged contributor-level account to take over a site.

Technical Analysis and Overview

As with every WordPress core release containing security fixes, the Wordfence Threat Intelligence team analyzed the code changes in detail to evaluate the impact of these vulnerabilities on our customers, and to ensure our customers remain protected.

Contributor+ Stored Cross-Site Scripting in the HTML API

Description: WordPress Core < 6.5.5 – Authenticated (Contributor+) Stored Cross-Site Scripting via HTML API
Affected Versions: WordPress Core < 6.5.5
Researcher/s: Alex Concha (WordPress Security Team), Dennis Snell (WordPress Core Team), Grzegorz Ziółkowski (WordPress Security Team), Aaron Jorbin
CVE ID: Pending
CVSS Score: 6.4 (Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Fully Patched Version: 6.5.5
Link to Commit 1
Link to Commit 2

WordPress Core is vulnerable to Stored Cross-Site Scripting via the HTML API in various versions up to 6.5.5 due to insufficient input sanitization and output escaping on URLs. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The changeset in WordPress 6.5.5 adds additional protections in the set_attribute() function of the HTML API to further escape URL attributes. Additionally, this changeset adds additional improvements.

Contributor+ Stored Cross-Site Scripting in the Template Part Block

Description: WordPress Core < 6.5.5 – Authenticated (Contributor+) Stored Cross-Site Scripting via Template Part Block
Affected Versions: WordPress Core < 6.5.5
Researcher/s: Rafie Muhammad (Patchstack)
CVE ID: Pending
CVSS Score: 6.4 (Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Fully Patched Version: 6.5.5
Link to Commit

WordPress Core is vulnerable to Stored Cross-Site Scripting via the Template Part block in various versions up to 6.5.5 due to insufficient input sanitization and output escaping on the ‘tagName’ attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The changeset for WordPress 6.5.5 adds additional sanitization to the Template Part block’s ‘tagName’ attribute. The Template Part block is available to contributor-level users. However, exploitation is only possible where the site’s theme uses this particular block.

Windows-only Directory Traversal

Description: WordPress Core < 6.5.5 – Authenticated (Contributor+) Directory Traversal
Affected Versions: WordPress Core < 6.5.5
Researcher/s: apple502j, Rafie Muhammad (Patchstack), Edouard L , David Fifield, x89, mishre
CVE ID: Pending
CVSS Score: 4.3 (Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Fully Patched Version: 6.5.5
Link to Commit

WordPress Core is vulnerable to Directory Traversal in various versions up to 6.5.5 via the Template Part block. This makes it possible for authenticated attackers, with contributor-level access and above, to include arbitrary HTML Files on sites running Windows.

Similar to the previous vulnerability, this Directory Traversal vulnerability is exploitable via the Template Part block. The changeset for WordPress 6.5.5 shows the addition of a path normalization function within the validate_file() function.

Conclusion

WordPress 6.5.5 includes patches for 3 medium-severity vulnerabilities. Two of these vulnerabilities are trivial to exploit as an authenticated, contributor+ user, and we recommend updating immediately if your site has not yet automatically done so.

We have released one new firewall rule to protect Wordfence Premium, Wordfence Care, and Wordfence Response customers. This rule will be available to free Wordfence users in 30 days, on July 24th, 2024.

If you know someone who uses WordPress and isn’t keeping it automatically updated, we recommend sharing this advisory with them to ensure their site remains secure, as several of these vulnerabilities pose a significant risk.

For security researchers looking to disclose vulnerabilities responsibly and obtain a CVE ID, you can submit your findings to Wordfence Intelligence Bug Bounty Program and earn up to $10,400 for your submission.

Special thanks to István Márton, a Wordfence Vulnerability Researcher, for his assistance on reverse engineering the patches and ensuring Wordfence users have adequate coverage. 

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2024/06/wordpress-6-5-5-security-release-what-you-need-to-know/

SANS’s 2024 Threat-Hunting Survey Review

By: Trend Micro
June 04, 2024
Read time: 3 min (709 words)

In its ninth year, the annual SANS Threat Hunting Survey delves into global organizational practices in threat hunting, shedding light on the challenges and adaptations in the landscape over the past year.

The 2024 survey highlights a growing maturity in threat-hunting methodologies, with a significant increase in organizations adopting formal processes.

This marks a shift towards a more standardized approach in cybersecurity strategies despite challenges such as skill shortages and tool limitations. Additionally, the survey reveals evolving practices in sourcing intelligence and an increase in outsourcing threat hunting, raising questions about the efficiency and alignment with organizational goals. This summary encapsulates the essential findings and trends, emphasizing the critical role of threat hunting in contemporary cybersecurity frameworks.

Participants

survey demographics
Figure 1: Survey demographics

This year’s survey attracted participants from a wide array of industries, with cybersecurity leading at 15% and 9% of respondents from the manufacturing sector, which has recently faced significant challenges from ransomware attacks. The survey participants varied in organization size, too, ranging from those working in small entities with less than 100 employees (24%) to large corporations with over 100,000 employees (9%).

The respondents play diverse roles within their organizations, highlighting the multidisciplinary nature of threat hunting. Twenty-two percent are security administrators or analysts, while 11% hold business manager positions, showcasing a balance between technical, financial, and personnel perspectives in threat-hunting practices.

However, the survey does note a geographical bias, with 65% of participants coming from organizations based in the United States, which could influence the findings related to staffing and organizational practices, though it’s believed not to affect the technical aspects of threat hunting.

Significant findings and implications

The survey examines the dynamic landscape of cyber threats and the strategies deployed by threat hunters to identify and counteract these risks. Notably, it sheds light on the prevalent types of attacks encountered:

  • Business email compromise (BEC): BEC emerges as the foremost concern, with approximately 68% of respondents reporting its detection. BEC involves malicious actors infiltrating legitimate email accounts to coerce individuals into transferring funds through social engineering tactics.
  • Ransomware: Following closely behind is ransomware, detected by 64% of participants. Ransomware operations encrypt data and demand payment for decryption, constituting a significant threat in the cybersecurity landscape.
  • Tactics, techniques, and procedures (TTPs): The survey found that TTPS are employed in different attack scenarios. In ransomware incidents, threat actors often deploy custom malware, target specific data for exfiltration, utilize off-the-shelf tools like Cobalt Strike, attempt to delete traces, and sometimes resort to physical intrusion into target companies.

Evolving threat-hunting practices

SANS also found that organizations have significantly evolved their threat-hunting practices, with changes in methodologies occurring as needed, monthly, quarterly, or annually.

Outsourced threat hunting is now used by 37% of organizations, and over half have adopted clearly defined methodologies for threat hunting, marking a notable advancement.

Additionally, 64% of organizations formally evaluate the effectiveness of their threat-hunting efforts, showing a decrease in those without formal methodologies from 7% to 2%. The selection of methods is increasingly influenced by available human resources, recognized by 47% of organizations.

The chief information security officer (CISO) plays a key role in developing threat-hunting methodologies, with significant involvement in 40% of cases.

Benefits of better threat-hunting efforts

Significant benefits from threat hunting include improved attack surface and endpoint security, more accurate detections with fewer false positives, and reduced remediation resources.

About 30% of organizations use vendor information as supplemental threat intelligence, with 14% depending solely on it. Incident response teams’ involvement in developing threat-hunting methodologies rose to 33% in 2024, indicating better integration within security functions.

Challenges such as data quality and standardization issues are increasing, underscoring the complexities of managing expanding cybersecurity data.

Final thoughts

The SANS 2024 Threat Hunting Survey highlights the cybersecurity industry’s evolution and focuses on improving cyber defense capabilities. Organizations aim to enhance threat hunting with better contextual awareness and data tools, with 51% looking to improve response to nuanced threats.

Nearly half (47%) plan to implement AI and ML to tackle the increasing complexity and volume of threats. There’s a significant planned investment in both staff and tools, with some organizations intending to increase their investment by over 10% or even 25% in the next 24 months, emphasizing threat hunting’s strategic importance.

However, a small minority anticipate reducing their investment, hinting at a potential shift in security strategy.

Source :
https://www.trendmicro.com/en_us/research/24/f/sans-2024-threat-hunting-survey-review.html

Not Just Another 100% Score: MITRE ENGENUITY ATT&CK

By: Trend Micro
June 18, 2024
Read time: 4 min (1135 words)

The latest MITRE Engenuity ATT&CK Evaluations pitted leading managed detection and response (MDR) services against threats modeled on the menuPass and BlackCat/AlphV adversary groups. Trend Micro achieved 100% detection across all 15 major attack steps with an 86% actionable rate for those steps— balancing detections and business priorities including operational continuity and minimized disruption.

Trend took part in the MITRE Engenuity ATT&CK Evaluations for managed detection and response (MDR) services—building on a history of strong performance in other MITRE Engenuity tests. Key to that ongoing success is our platform approach, which provides high-fidelity detection of early- and mid-chain tactics, techniques, and procedures (TTPs) enabling quick and decisive counteractions before exfiltration or encryption can occur. Of course, we know real-world outcomes matter more than lab results. That’s why we’re proud to support thousands of customers worldwide with MDR that brings the most native extended detection and response (XDR) telemetry, leading threat intelligence from Trend™ Research and our Trend Micro™ Zero-Day Initiative™ (ZDI) under a single service to bridge real-time threat protection and cyber risk management. 

The evaluation focused on our Trend Service One™ offering, powered by Trend Vision One, which included XDR, endpoint and network security capabilities. The results proved Trend Micro MDR is a great alternative to managed services that rely on open XDR platforms or managed SIEM platforms.

Our detection of adversarial activity early in the attack chain combined with our platform’s deeply integrated native response capabilities enables rapid mean-time-to-detect (MTTD) and mean-time-to-respond (MTTR). At the same time, comprehensive visibility and protection gives security teams greater confidence.

MITRE ENGENUITY ATTACK EVALUATIONS Managed Services Badge

Full detection across all major steps

This most recent MITRE Engenuity ATT&CK Evaluations for Managed Services featured attacks modeled on the real-world adversaries menuPass and BlackCat/AlphV. These took the form of advanced persistent threats (APTs) designed to dwell in the network post-breach and execute harmful activity over time.

Trend MDR achieved full detection coverage, reflecting and reinforcing our achievements in cybersecurity:

  • 100% across all  major attack steps
  • 100% for enriched detail on TTPs
  • 86% actionable rate for major steps

How Trend MDR delivers

To put its MDR evaluation in context, MITRE Engenuity conducted a survey prior to testing, gaining insights into market perceptions and expectations of managed cybersecurity services. More than half (58%) of respondents said they rely on managed services either to complement their in-house SOC or as their main line of defense. For companies with fewer than 5,000 employees, that tally increased to 68%.

Our MDR service at Trend helps meet those needs by combining AI techniques with human threat expertise and analysis. We correlate data and detect threats that might otherwise slip by as lower severity alerts. Our experts prioritize threats by severity, determine the root cause of attacks, and develop detailed response plans.

XDR is a key technology to achieve these security outcomes, extending visibility beyond endpoints to other parts of the environment where threats can otherwise go undetected: servers, email, identities, mobile devices, cloud workloads, networks, and operational technologies (OT). 

Integrated with native XDR insights is deep, global threat intelligence. Native telemetry enables high-fidelity detections, strong correlations and rich context; global threat intelligence brings highly relevant context to detect threats faster and more precisely. Combined with a broad third-party integration ecosystem and response automation across vectors, Trend Vision One introduces a full-spectrum SOC platform for security teams to speed up investigations and frees up time to focus on high-value, proactive security work including threat hunting and detection engineering. In some cases, smaller teams rely on our MDR service completely for their security operations.

With Trend Vision One, teams have access to a continuously updated and growing library of detection models—with the ability to build custom detection models to fit their unique threat models.

Proven strength in delivering higher-confidence alerts

Security and security operations center (SOC) teams are inundated with detection alerts and noise. Our visibility and analytics performance achieves a finely tuned balance between providing early alerts of critical adversarial tactics and techniques and managing alert fatigue to improve the analyst experience. Our MDR operations team takes advantage of the platform advantage and knows only to alert customers when critical.

In each simulation during the MITRE Engenuity ATT&CK Evaluations, there was no scenario where menuPass and BlackCat/AlphV attack attempts successfully breached the environment without being detected or disrupted.

It’s important to note that MITRE Engenuity doesn’t rank products or solutions. It provides objective measures but no scores. Instead, since every service and solution functions differently, the evaluation reveals areas of strength and opportunities for improvement within each offering. 

About the attacks

The menuPass threat group has been active since at least 2006. Some of its members have been associated with the Tianjin State Security Bureau of the Chinese Ministry of State Security and with the Huaying Haitai Science and Technology Development Company. It has targeted healthcare, defense, aerospace, finance, maritime, biotechnology, energy, and government targets—and in 2016–17 went after managed IT service providers. BlackCat is Rust-based ransomware offered as a service and first observed in November 2021. It has been used to target organizations across Africa, the Americas, Asia, Australia, and Europe in a range of sectors. 

Putting our service to the test

In cybersecurity, actions speak louder than words. Our significant investment in research and development extend to our MDR service offering to support thousands of enterprises around the world.

We’re dedicated to continuous iteration and improvement to equip security teams with cutting-edge solutions to keep their organizations safe. As we evolve our solutions, MITRE Engenuity continues to evolve its evaluation approach as well. The category of “actionability” was new in this evaluation, determining if each alert provided enough context for the security analyst to act on. The actionability testing category is an area we’re investing in heavily from a process and technology standpoint to ensure contextual awareness, prioritization, and intelligent guidance are included while maintaining manageable communication cadences and minimizing false positive alerts.

Overall, areas for improvement surfaced through the test scenarios have been resourced with dedicated engineering and development efforts to match the high standard we hold ourselves to-and that our users expect. We are pleased to see our MDR service demonstrated a strong balance of detection capabilities across the entire attack chain, both within the service itself and embedded in the underlying Trend Vision One platform.

We invite all our MDR customers to take a look at the MITRE Engenuity ATT&CK Evaluations for Managed Services to better understand the strength of their defensive posture, and to come to us with any questions or thoughts.

Next steps

For more on Trend MDR, XDR, and other related topics, check out these additional resources:

Forward vision

At Trend, we are dedicated to continuous iteration and improvement to equip security teams with cutting-edge solutions to keep their organizations safe. These relevant areas of improvement surfaced through the scenarios have been resourced with dedicated engineering and development efforts to match the high standard we hold ourselves to and which our users expect.

Source :
https://www.trendmicro.com/en_us/research/24/f/mitre-enginuity-attack-evaluations.html

How to Make Your Employees Your First Line of Cyber Defense

May 01, 2024
The Hacker News

There’s a natural human desire to avoid threatening scenarios. The irony, of course, is if you hope to attain any semblance of security, you’ve got to remain prepared to confront those very same threats.

As a decision-maker for your organization, you know this well. But no matter how many experts or trusted cybersecurity tools your organization has a standing guard, you’re only as secure as your weakest link. There’s still one group that can inadvertently open the gates to unwanted threat actors—your own people.

Security must be second nature for your first line of defense #

For your organization to thrive, you need capable employees. After all, they’re your source for great ideas, innovation, and ingenuity. However, they’re also human. And humans are fallible. Hackers understand no one is perfect, and that’s precisely what they seek to exploit.

This is why your people must become your first line of defense against cyber threats. But to do so, they need to learn how to defend themselves against the treachery of hackers. That’s where security awareness training (SAT) comes in.

What is Security Awareness Training (SAT)? #

The overall objective of an SAT program is to keep your employees and organization secure. The underlying benefit, however, is demonstrating compliance. While content may differ from program to program, most are generally similar, requiring your employees to watch scripted videos, study generic presentations, and take tests on cyber “hygiene.” At their core, SAT programs are designed to help you:

  • Educate your employees on recognizing cybersecurity risks such as phishing and ransomware
  • Minimize your organization’s exposure to cyber threats
  • Maintain regulatory compliance with cyber insurance stipulations

These are all worthwhile goals in helping your organization thrive amidst ever-evolving cyber threats. However, attaining these outcomes can feel like a pipe dream. That’s because of one unfortunate truth about most SAT programs: they don’t work.

Age-Old Challenges of Old-School SATs#

Traditional SAT programs have long been scrutinized for their inability to drive meaningful behavioral changes. In fact, 69% of employees admit to “intentionally bypassing” their enterprise’s cybersecurity guidance.

If you oversee cybersecurity for an organization, then you’re likely familiar with the pain that comes with implementing one, managing it, and encouraging its usage. Given their complexities, traditional SAT solutions practically force non-technical employees to become full-on technologists.

Challenges for AdministratorsChallenges for EmployeesChallenges for Your Organization
Complex, ongoing management is frustrating. Plus, through it all they just find poor results.They’re bored. Unengaging content is detrimental, as it doesn’t lead to knowledge retention. Boring, unengaging content doesn’t help with knowledge retention.Most SATs aren’t effective because they’re created by generalists, not real cybersecurity experts And many are designed with little reporting capabilities, leading to limited visibility into success rates

Because most SAT programs are complex to manage, they’re usually dismissed as a means to an end. Just check a box for compliance and move on. But when done right, SAT can be a potent tool to help your employees make more intelligent, more instinctive, security-conscious decisions.

Ask the Right Questions Before Choosing Your SAT Solution#

When it comes to choosing the right solution for your organization, there are some questions you should first ask yourself. By assessing the following, you’ll be better equipped to select the option that best fits your specific needs.

Learning-Based Questions

  • Are the topics covered in this SAT relevant to my organization’s security and compliance concerns?
  • Are episodes updated regularly to reflect current threats and scenarios?
  • Does this SAT engage users in a unique, meaningful manner?
  • Is this SAT built and supported by cybersecurity practitioners?
  • Is the teaching methodology proven to increase knowledge retention?

Management-Based Questions

  • Can someone outside of my organization manage the SAT for me?
  • Can it be deployed quickly?
  • Does it automatically enroll new users and automate management?
  • Is it smart enough to skip non-human identities so I don’t assign training to, say, our copy machine?
  • Is it simple and intuitive enough for anyone across my organization to use?

Your ideal SAT will allow you to answer a resounding “Yes” to all of the above.

Essential Features of an Effective SAT#

A SAT solution that’s easy to deploy, manage, and use can have a substantial positive impact. That’s because a solution that delivers “ease” has considered all of your organization’s cybersecurity needs in advance. In other words, an effective SAT does all the heavy lifting on your behalf, as it features:

Relevant topics
…based on real threats you might encounter.
What to look for:

To avoid canned, outdated training, choose a SAT solution that’s backed by experts. Cybersecurity practitioners should be the ones regularly creating and updating episodes based on the latest trends they see hackers leveraging in the wild. Additionally, every episode should cover a unique cybersecurity topic that reflects the most recent real-world tradecraft.
Full management by real experts
…so you don’t have to waste time creating, managing, and assigning training.
What to look for:

Ideally, you want a SAT solution that can manage all necessary tasks for you. Seek a SAT solution that’s backed by real cybersecurity experts who can create, curate, and deploy your learning programs and phishing scenarios on your behalf.
Memorable episodes
…with fun, story-driven lessons that are relatable and easy to comprehend.
What to look for:

Strive for a SAT solution that features character-based narratives. This indicates the SAT is carefully designed to engage learners of all attention spans. Remember, if the episodes are intentionally entertaining and whimsical, you’re more likely to find your employees conversing about inside jokes, recurring characters, and, of course, what they’ve learned. As a result, these ongoing discussions only serve to fortify your culture of security.
Continual enhancements …so episodes are updated regularly in response to real-world threats.
What to look for:
Seek out a SAT solution that provides monthly episodes, as this will keep your learners up to date. Regular encounters with simulated cybersecurity scenarios can help enhance their abilities to spot and defend against risks, such as phishing attempts. These simulations should also be dispersed at unpredictable time intervals (i.e. morning, night, weekends, early in the month, later in the month, etc.), keeping learners on their toes and allowing them to put their security knowledge into practice.
Minimal time commitment
…so you don’t have to invest countless hours managing it all.
What to look for:
For your learners, choose a SAT solution that doesn’t feel like an arduous chore. Look for solutions that specialize in engaging episodes that are designed to be completed in shorter periods of time.
For your own administrative needs, select a SAT that can sync regularly with your most popular platforms, such as Microsoft 365, Google, Okta, or Slack. It should also sync your employee directories with ease, so whenever you activate or deactivate users, it’ll automatically update the information. Finally, make sure it’s intelligent enough to decipher between human and non-human identities, so you’re only charged for accounts linked to real individuals.
Real results …through episodes that instill meaningful security-focused behaviors and habits.
What to look for:
An impactful SAT should deliver monthly training that’s rooted in science-backed teaching methodologies proven to help your employees internalize and retain lessons better. Your SAT should feature engaging videos, text, and short quizzes that showcase realistic cyber threats you and your employees are likely to encounter in the wild, such as:PhishingSocial engineeringPhysical device securityand more
Measurable data …with easy-to-read reports on usage and success rates.
What to look for:
An impactful SAT program should provide robust reporting. Comprehensible summaries should highlight those learners who haven’t taken their training or those whom a phishing simulation has compromised. Additionally, detailed reports should give you all the data you need to help prove business, insurance, and regulatory compliance.
Easy adoption
….that makes it easy to deploy and easy to scale with your organization.
What to look for:
Choose a SAT solution that’s specially built to accommodate organizations with limited time and resources. A solution that’s easy to implement can be deployed across your organization in a matter of minutes.
Compliance …with a range of standards and regulations
What to look for:
While compliance is the bare minimum of what a SAT should offer your organization, it shouldn’t be understated. Whether to meet insurance check boxes or critical industry regulations, every business has its own compliance demands. At the very least, your SAT solution should cover the requirements of:
Health Insurance Portability and Accountability Act (HIPAA)Payment Card Industry Data Security Standard (PCI)Service Organization Control Type 2 (SOC 2)EU General Data Protection Regulation (GDPR)

The Threat Landscape is Changing. Your SAT Should Change With It. #

Cybercriminals think they’re smart, maliciously targeting individuals across organizations like yours. That’s why you need to ensure your employees are smarter. If they’re aware of the ever-changing tactics hackers employ, they can stand as your first line of defense. But first, you need to deploy a training solution you can trust, backed by real cybersecurity experts who understand emerging real-world threats.

Huntress Security Awareness Training is an easy, effective, and enjoyable solution that helps:

  • Minimize time-consuming maintenance and management tasks
  • Improve knowledge retention through neuroscience-based learning principles
  • Update you and your employees on the current threat landscape
  • Establish a culture that values cybersecurity
  • Inspire meaningful behavioral habits to improve security awareness
  • Engage you and your employees in a creative, impactful manner
  • Assure regulatory compliance
  • Keep cyber criminals out of your organization

Discover how a fully managed SAT can free up your time and resources, all while empowering your employees with smarter habits that better protect your organization from cyber threats.

Say goodbye to ineffective, outdated training. Say hello to Huntress SAT.

Start your free trial of Huntress SAT today.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :
https://thehackernews.com/2024/05/everyones-expert-how-to-empower-your.html

NIST Launches Cybersecurity Framework (CSF) 2.0

By: Shannon Murphy, Greg Young
March 20, 2024
Read time: 2 min (589 words)

On February 26, 2024, the National Institute of Standards and Technology (NIST) released the official 2.0 version of the Cyber Security Framework (CSF).

What is the NIST CSF?

The NIST CSF is a series of guidelines and best practices to reduce cyber risk and improve security posture. The framework is divided into pillars or “functions” and each function is subdivided into “categories” which outline specific outcomes.

As titled, it is a framework. Although it was published by a standards body, it is not a technical standard.

https://www.nist.gov/cyberframework

What Is the CSF Really Used For?

Unlike some very prescriptive NIST standards (for example, crypto standards like FIPS-140-2), the CSF framework is similar to the ISO 27001 certification guidance. It aims to set out general requirements to inventory security risk, design and implement compensating controls, and adopt an overarching process to ensure continuous improvement to meet shifting security needs.

It’s a high-level map for security leaders to identify categories of protection that are not being serviced well. Think of the CSF as a series of buckets with labels. You metaphorically put all the actions, technology deployments, and processes you do in cybersecurity into these buckets, and then look for buckets with too little activity in them or have too much activity — or repetitive activity — and not enough of other requirements in them.

The CSF hierarchy is that Functions contain many Categories — or in other words, there are big buckets that contain smaller buckets.

What Is New in CSF 2.0?

The most noteworthy change is the introduction of Governance as a sixth pillar in the CSF Framework. This shift sees governance being given significantly more importance from just a mention within the previous five Categories to now being its owna separate Function.

According to NIST the Govern function refers to how an organization’s, “cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored.”  This is a positive and needed evolution, as when governance is weak, it often isn’t restricted to a single function (e.g. IAM) and can be systemic.

Governance aligns to a broader paradigm shift where we see cybersecurity becoming highly relevant within the business context as an operational risk. The Govern expectation is cybersecurity is integrated into the broader enterprise risk management strategy and requires dedicated accountability and oversight.

There are some other reassignments and minor changes in the remaining five Categories. CSF version 1.0 was published in 2014, and 1.1 in 2018. A lot has changed in security since then. The 2.0 update acknowledges that a review has been conducted.

As a framework, the CISO domain has not radically changed. Yes, the technology has radically evolved, but the greatest evolution in the CISO role really has been around governance: greater interaction with C-suite and board, while some activities have been handed off to operations.

NIST Cybersecurity Framework

So How Will This Impact Me in the Short Term?

The update to the NIST CSF provides a fresh opportunity to security leaders to start or reopen conversations with business leaders on evolving needs.

  • The greatest impact will be to auditors and consultants who will need to make formatting changes to their templates and work products to align with version 2.0.
  • CISOs and security leaders will have to make some similar changes to how they track and report compliance.
  • But overall, the greatest impact (aside from some extra billable cybersecurity consulting fees) will be a boost of relevance to the CSF that could attract new adherents both through security leaders choosing to look at themselves through the CSF lens and management asking the same of CISOs.
Category

Source :
https://www.trendmicro.com/it_it/research/24/c/nist-cybersecurity-framework-2024.html

Setting up a Multi-Server CrowdSec Security Engine Installation

MARCH 28, 2024
15 MIN. READ
WRITTEN BY Manuel Sabban

This article was originally published on 30 April 2021 in the Linux Journal.

Updated: 14 March 2024

With the launch of Security Engine 1.0.x, we enabled the Security Engine to function as an HTTP REST API, allowing it to gather signals from other Security Engines.

In this guide, I will guide you through the steps to set up the CrowdSec Security Engine across multiple servers, where one server will serve as the parent and two additional machines will forward alerts to it.

To learn about the three different ways to achieve secure TLS communications between your CrowdSec Security Engines in this multi-server setup, check out the second part of this series: Secure A Multi-Server CrowdSec Security Engine Installation With HTTPS.

Benefits

Sharing cybersecurity incidents across machines using the CrowdSec Security Engine is a highly effective strategy to enhance collective security defenses. By leveraging CrowdSec’s capability to distribute remediations among connected machines, each machine benefits from real-time updates about new threats detected elsewhere in the network.

Architecture

‍

In the diagram above, the parent Security Engine, designated as server-1, will be set up as the HTTP REST API, commonly known as the LAPI (Local API). This engine will be in charge of storing and distributing the gathered signals. Remediation is managed through the Remediation Components, which depend on the LAPI offered by server-1. It’s crucial to understand that mitigation can occur independently from detection.

Server-2 and server-3 are designated as internet-facing machines that will host services available to the public and will be known as the child Log Processors. On these servers, we will install CrowdSec Security Engine and Remediation Components, which will interact with the server-1 LAPI. 

Note: The phrase “child Log Processors” refers to a CrowdSec Security Engine that operates with its LAPI turned off. For more information on this, consult our Taxonomy Update Article. 

We strongly encourage you to explore the CrowdSec Hub to learn about the extensive range of services the Security Engine can protect. This platform showcases the diverse capabilities of the Engine in securing everything from web applications to databases against cyber threats.

Architecture Decisions

I chose a postgresql backend for the server-1 LAPI to achieve greater stability in database read and write operations. Nevertheless, depending on your operational scale, you might discover that the default SQLite with WAL (Write-Ahead Logging) enabled meets your needs, if so you can skip section 1b.

Prerequisites

To follow this tutorial, you will need the following:

  • Two internet-facing Ubuntu 22.04 machines hosting services.
  • One Ubuntu 22.04 machine.
  • A local network connection between the Parent and Child machines.

Step 1: Setup and Configure Parent LAPI server-1

Step 1a: Install CrowdSec Security Engine

Let’s install the Security Engine, following the installation guide.

https://youtube.com/watch?v=VwXiMLUhdXQ%3Fenablejsapi%3D1%26origin%3Dhttps%3A


curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
sudo apt install crowdsec

Step 1b (Optional): Using postgresql on Parent server-1 

Install the PostgreSQL package using the apt package manager.


sudo apt install postgresql

Next, transition to the postgres Linux user and then connect by executing the psql command.


sudo -i -u postgres
psql

You can set up the database and create an authorized user using the commands below. Replace  with a password you select, you must keep it within the single quotes.


postgres=# CREATE DATABASE crowdsec;
CREATE DATABASE
postgres=# CREATE USER crowdsec WITH PASSWORD ‘[PASSWORD]’; CREATE ROLE
postgres=# GRANT ALL PRIVILEGES ON DATABASE crowdsec TO crowdsec;
GRANT

Now, we’ll set up the Security Engine to utilize this newly created database as its backend. This requires updating the db_config section in the /etc/crowdsec/config.yaml file.


db_config:
  log_level: info
  type:	postgres
  user: crowdsec
  password: ""
  db_name: crowdsec
  host: 127.0.0.1
  port: 5432

During the installation of the Security Engine, the local machine was configured to use the SQLite database. To switch to the newly set up postgres database, you will need to regenerate the credentials and then proceed to restart the Security Engine.


sudo cscli machines add -a –force
sudo systemctl restart crowdsec

Step 1c: Expose LAPI port

To enable communication between the LAPI and the child Log Processors/Remediation Components, it is necessary to adjust the LAPI’s settings to accept connections from external sources, since its default configuration binds it to the machine’s loopback address (127.0.0.1). This adjustment can be made by editing the /etc/crowdsec/config.yaml configuration file and changing the specified settings.


api:
  server:
    listen_uri: 10.0.0.1:8080

In the mentioned setup, we adjust the settings to listen on the 10.0.0.1 interface on port 8080. Should you wish to listen on several interfaces, you can change this to 0.0.0.0 and implement firewall rules to permit specific connections.

Step 2: Setup and Configure Child Log Processors

Step 2a: Install CrowdSec Security Engine

Let’s install the Security Engine, following the installation guide.

https://youtube.com/watch?v=VwXiMLUhdXQ%3Fenablejsapi%3D1%26origin%3Dhttps%3A


curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
sudo apt install crowdsec

Step 2b: Configure to use LAPI server

First, lets register the Log Processor to the LAPI server using the following command


sudo cscli lapi register -u http://10.0.0.1:8080

Ensure you adjust the -u flag to suit your network. Utilize the IP address if it’s static, or opt for the hostname if your network allows it.

Next, we’ll turn off the local API on the Security Engine, turning it into a Log Processor. This action is taken because the API won’t be utilized, which will conserve system resources and avoid occupying a TCP port unnecessarily.

To achieve this, we can disable the API in the configuration with:


api:
  server:
    enable: false

Step 2c: Validate the registration request on LAPI

Since we used the cscli lapi register on the child Log Processor we must validate the request on server-1 via the following commands:


sudo cscli machines list
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
  NAME                                              IP ADDRESS      LAST UPDATE           STATUS  VERSION                                                            
  --------------------------------------------------------------------------------------------------------------------------------------------------------------------
  dc6f34b3a4994700a2e333df43728701D0iARTSQ6dxiwyMR  10.0.0.1  2021-04-13T12:16:11Z  ✔️  v1.0.9-4-debian-pragmatic-a8b16a66b110ebe03bb330cda2600226a3a862d7
  9f3602d1c9244f02b0d6fd2e92933e75zLVg8zSRkyANxHbC  10.0.0.3   2021-04-13T12:24:12Z  🚫
--------------------------------------------------------------------------------------------------------------------------------------------------------------------

From this output, it’s evident there’s a new machine that hasn’t been validated yet by the 🚫 within the status column. We need to manually validate this machine to ensure the LAPI recognizes which machines are authorized to transmit signals.

Note: If you don’t see a new machine marked with a 🚫 in the status column, make sure you are executing the command on the LAPI server.


sudo cscli machines validate 9f3602d1c9244f02b0d6fd2e92933e75zLVg8zSRkyANxHbC

Make sure to change the argument following validate to correspond with the new machine name displayed in the list output.

Step 2d: Restart the child Log Processor service

On the child Log Processor machine you can run the following command to restart the service:


sudo systemctl restart crowdsec

Then, for each machine you wish to connect, repeat step 2. In our case, we will perform this action twice, once for each Ubuntu machine.

Step 3: Setting up Remediation

Now, it’s important to configure remediation measures for your internet-facing servers since merely running the Log Processor does not implement enforcement actions. In this article, we’ll focus on setting up the Linux firewall Remediation Component. For additional remediation options, be sure to explore the extensive list available in the CrowdSec Documentation.

Step 3a: Generating API key on LAPI

First, we’ll create API token on the LAPI server by executing the following command:


sudo cscli bouncers add server-2-firewall
Api key for 'server-2-firewall':

    02954e85c72cf442a4dee357f0ca5a7c
    
Please keep this key since you will not be able to retrieve it!

I used server-2-firewall as the name for the key, but you can choose any name you prefer. It’s crucial to select a descriptive name for the key to facilitate future management, especially if you need to revoke a key due to a token compromise.

Step 3b: Install the Remediation Component

IPtables firewall is among the most commonly used on Linux, so we’ll proceed to install the Component that interacts with it, using the apt package manager.


sudo apt install cs-firewall-bouncer-iptables

Once the Component is installed, we will edit the configuration under /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml to point towards the LAPI


api_url: http://10.0.0.1:8080/
api_key: 02954e85c72cf442a4dee357f0ca5a7c

Ensure you modify the api_url to align with your LAPI address and update the api_key to the one generated by the previous command. Remember, you can use either the IP address or the hostname.

Once you have altered the configuration, let’s restart the firewall Remediation Component.


sudo systemctl restart crowdsec-firewall-bouncer

Then, for each Remediation Component you wish to connect, repeat step 3. In our case, we will perform this action twice, once for each firewall on the Ubuntu machines. Make sure to alter the naming scheme of the API key.

A few closing thoughts

This guide illustrated the process for establishing a multi-server Security Engine setup. While this example utilized three servers, the architecture allows for easy expansion. The resource consumption on server-2 and server-3 remains minimal since the majority of operations are directed towards server-1, facilitating straightforward scalability of the system:

  • Register and validate additional Security Engines on the LAPI server
  • Add any additional Remediation Components

As previously stated, there’s no requirement for the Remediation Components and Security Engines to be installed on the same server. This implies that the Security Engine should be installed at the location where logs are produced, whereas the Remediation Component can be deployed at any desired location.

It’s important to note that this configuration comes with certain limitations:

  • The communication between Security Engines occurs via unencrypted HTTP, which is suitable for a local network but not secure for internet use. However, the CrowdSec Security Engine supports the use of HTTPS for these interactions.
  • This article does not delve into monitoring or alerting. Nonetheless, the Security Engine supports comprehensive monitoring capabilities via Prometheus, and you can find more detailed information about it in this article.
  • Having both the CrowdSec LAPI and PostgreSQL on server-1 creates a single point of failure, potentially leading to delays in threat response should any issues arise with the server.

Now you may be wondering — how do I build a highly available multi-server CrowdSec setup? We will have a dedicated article on that in the coming weeks, so stay tuned! 

We are always more than happy to receive your feedback! Don’t hesitate to reach out to us on our community platforms on Discord and Discourse.

Source :
https://www.crowdsec.net/blog/multi-server-setup

Secure A Multi-Server CrowdSec Security Engine Installation With HTTPS

MARCH 28, 2024
10 MIN. READ
WRITTEN BY Manuel Sabban

This article was originally published on 31 August 2021 in the Linux Journal.

Updated: 14 March 2024

Welcome to the second part of our tutorial on how to set up and secure a multi-server CrowdSec Security Engine installation. In the first part, I walked you through the setup of CrowdSec Security Engines across multiple servers, with one server serving as the parent and two additional machines forwarding alerts to it.

In this part, I will address security issues posed by clear HTTP communication in the previous multi-server Security Engine installation. To solve this, I propose establishing the communication between Security Engines over encrypted channels. This solution allows server-2 or server-3 to trust the server-1 identity and avoid man-in-the-middle attacks.

Using self-signed certificates

Create the certificate

First, you need to create a certificate. This can be achieved with the following one-liner.


openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242

For now, the Security Engine is not able to ask for the passphrase of the private key when starting. So, you have the choice to decipher the private key by hand each time you start or reload the Security Engine or store the key unencrypted. In any way, to strip the passphrase, you can use the following:


openssl rsa -in encrypted-key.pem -out key.pem

Then, the unencrypted key file can be safely deleted after the Security Engine is started.

Configure the Security Engine to use a self-signed certificate

On server-1 you need to configure the Security Engine to use the generated certificate. As seen below, the  tls.cert_file and tls.key_file option in the api.server section of the following /etc/crowdec/config.yaml excerpt is set to the generated certificate file.


api:

  server:

    log_level: info
    listen_uri: 10.0.0.1:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    online_client: # Crowdsec API credentials (to push signals and receive bad 

    tls:
      cert_file: /etc/crowdsec/ssl/cert.pem
      key_file: /etc/crowdsec/ssl/key.pem

On the client side, configuration changes happen in two files. First, modify /etc/crowdec/config.yaml to accept self-signed certificates by setting the insecure_skip_verify to true.

You also need to change HTTP for HTTPS in the /etc/crowdsec/local_api_credentials.yaml file in order to reflect the changes. This small change has to be done on all three servers (server-1, server-2 andserver-3).

‍Note: Please keep in mind that this LAPI configuration has to be done on server-1 as well if it’s used as a log processor too.


url: https://10.0.0.1:8080/
login: [login]
password: [password]

Side note: Obviously using self-signed certificates doesn’t provide any confidence over ownership on the LAPI server. Servers using the service (server-2 or server-3 in this setup) are still vulnerable to man-in-the-middle attacks, but at least this setup provides encrypted communications. That’s the reason why the InsecureSkipVerify option is needed.

Using a Certificate Authority-issued certificate

Let’s Encrypt, or services like Amazon ACM, can be leveraged to workaround the InsecureSkipVerify, by issuing a certificate for a fully qualified domain name that can be added to /etc/hosts or to a local DNS server.  /etc/crowdsec/local_api_credentials.yaml can then be filled with this specified fully qualified domain name.

This indeed works and prevents the InsecureSkipVerify option from being set. This ensures that communication between client and server can’t be tampered with as long as the DNS configuration can be trusted, but should still be considered as a workaround.

Using a PKI

The process of configuring and managing an SSL Public Key Infrastructure (PKI) falls outside the scope of this tutorial, but I highly recommend you take a look at the official OpenSSL documentation. The simple PKI scenario is enough for this Security Engine setup.

Following the OpenSSL documentation, there are a few things worth mentioning.

To be usable in our CrowdSec TLS scenario, the certificate requests have to be issued with a subject alternative name corresponding to the IP of the Crowdsec LAPI server. This can be done by positioning the SAN environment variable when invoking OpenSSL for the certificate request (see step 3.3 in the OpenSSL simple PKI scenario).


SAN=IP:10.0.0.1 openssl req -new -config etc/server.conf -out certs/crowdsec.csr -keyout certs/crowdsec.key

The public part of the root and the signing certificates (bundle file created at step 4.5 in the OpenSSL simple PKI scenario) have to be added to the local certificate store before starting the CrowdSec Security Engine. In this setup, this is required to connect to the LAPI server. There’re many ways to do so, golang sources specify where certificates are expected, or you can use the SSL_CERT_FILE environment variable in the systemd service file to specify where to find the certificate when launching the Security Engine.

Updated note on CrowdSec and TLS authentication

After the first publication of this article, we added a new feature to the Security Engine you are now able not only to secure communication over TLS but also ensure authentication with certificate. In the official documentation you can find a great example that shows how TLS authentication can be done using certificates between Security Engines or between Security Engine and Remediation Component.

Conclusion

This article gives some highlights on how to secure communications between different CrowdSec Security Engine installations. The considered use case is Security Engine installations in a private network, but this can also be deployed on a public network with communication over the internet. In such a case, a third-party certificate would easily do the trick.

Depending on the needs, I proposed three different ways to achieve secure TLS communications between your Security Engines — using self-signed certificates, using certificates issued by a Certificate Authority, and using an SSL Public Key Infrastructure.

The first scenario, with self-signed certificates, only applies if you want to ensure encrypted communication with no need for authentication. The second scenario proposed may only be considered as a workaround when you have the possibility to modify local DNS resolutions. The third proposed scenario is the most complicated but would fit in most use cases and may be the way to go when security concerns are high.

I hope this tutorial comes in handy. Thanks for reading and stay tuned! 

If you have any questions or feedback, don’t hesitate to reach out to us on our community platforms on Discord and Discourse.

Source :
https://www.crowdsec.net/blog/secure-a-multi-server-installation-with-https

New Surge in VMware Workspace ONE Vulnerability CVE-2022-22954 Exploit Attempts Detected

MARCH 19, 2024
10 MIN. READ
WRITTEN BY Emanuel Seemann

Among the 29,000 vulnerabilities published as a CVE in 2022, CVE-2022-22954 is one of the more dangerous vulnerabilities, with a CVSS base score of 9.8. Recently there has been a significant uptick in exploitation attempts detected by the CrowdSec Network from bad actors located in China. To swiftly remediate this issue, we added the exploit as a rule for The CrowdSec AppSec Component.

This article serves as a reminder for security professionals to patch your VMware workspaces. Here I will also share some insights into the new attackers using this vulnerability.

The exploit

Since its introduction in 1999 there have been over 200,000 vulnerabilities published in the Common Vulnerabilities and Exposures (CVE) framework. As the number of vulnerabilities published each day grows, cyber security professionals are overwhelmed with figuring out whether a given vulnerability is actually at risk of being exploited. By leveraging CrowdSec’s large threat intelligence network, we know that most of these vulnerabilities very rarely lead to widespread adoption by threat actors. We suspect that this is mostly because proof-of-concept attacks are rarely published, which means that attackers don’t know a priori how difficult it will be to exploit the vulnerability in practice.

In the case of CVE-2022-22954, however, the exploit, as explained very succinctly by the Rapid7 team back in 2022, is simple and small enough to fit into a tweet. The Rapid7 team also showed that this vulnerability could be chained with other vulnerabilities of VMware products to gain a root shell for remote code execution. This showed that the exploit was both easy to use and significantly powerful in practice, which gave it a very high CVSS score.

The exploit itself is a classic case of Server-Side Template Injection (SSTI). Templating engines are systems used to insert user data into static HTML websites. For example, the web developer can write the template: 

And for the user John Doe, it will then show up as:

In an SSTI, the user is able to get the server to render a user-submitted template. The templating engine used by VMware, Apache FreeMarker, allows a developer to execute system commands within the template using the freemarker.template.utility.Execute function. This function call is, therefore, often used in template injection attacks. In the specific case of CVE-2022-22954, templates could be injected into the deviceUdid parameter of the /catalog-portal/ui/oauth/verify endpoint. 

To detect this, the CrowdSec Security Engine looks for calls to the utility.Execute function at this endpoint. Note that modern versions of FreeMarker allow sandboxing of the Execute function to prevent template injections from being easily exploitable.

A new surge in exploit attempts of the CVE-2022-22954

Usually, high CVSS scores cause defenders to patch their systems quickly and attacks to fall off as the attack surface rapidly decreases. This has been the case with log4shell as well. After a while, the real attacks drop away and, in turn, are replaced by a vast number of security scanners. This means that it’s not unusual to still see signals for old outdated vulnerabilities. To avoid such scanners polluting our threat intelligence, we maintain curated filters for the addresses of most scanner companies. 

The following chart depicts the number of unique IPs reported for CVE-2022-22954 each day over the past 3 months:

Unique IPs Reported for CVE-2022-22954

The chart is split into two phases. A stable phase for 2 months, followed by a growth phase starting on the 19th of February 2024. The first phase is the baseline noise generated by vulnerability scanners. The second phase is the new surge in attacks. The same trend can be seen in the number of signals and the number of unique Security Engines reporting attacks.

Signals and Security Engines Reporting CVE-2022-22954

Most of the attackers participating in this new attack wave have previously not been seen by the CrowdSec network. A good 40% of them come from Chinese IP addresses. Overlap analysis also reveals that the attackers attempt multiple similar attacks. Of note here should be the http-probing scenario which detects attackers that get served a significant number of 404/403 responses in a short time span. 

Combined with the fact that most of these IPs were previously unseen, we suspect that this might be an attempt to build a new botnet using very common vulnerabilities, not all of which we currently have detection scenarios for. 

Scenario Overlap

We provide the following top 3 Indicators of Compromise (IoC) for this new wave of attacks:


180[.]184[.]92[.]67
101[.]37[.]172[.]117
175[.]6[.]99[.]204

Response

In response to this new wave of attacks, we have added detection for this exploit to our Web Application Firewall (WAF) using a rule in the CrowdSec AppSec Component. CrowdSec WAF users are now protected against future attempts by these attackers. If you are not using the CrowdSec WAF solution yet, make sure to activate the AppSec Component in your Security Engine. You can find more information in the CrowdSec documentation.

In addition to the new AppSec Component rule, about 30% of the malicious IPs performing CVE-2022-22954 exploitation attempts are by now part of the CrowdSec Intelligence Blocklist, and considering the ramping intensity of these attackers, more will be added in the coming days. 

Want to stay ahead of the curve? Proactively block these IPs and don’t take any chances with the IPs massively exploiting the CVE-2022-22954 vulnerability potentially reaching your systems.

Source :
https://www.crowdsec.net/blog/new-surge-in-vmware-cve-2022-22954-exploit-attempts