CISA, FBI, and South Korean intelligence agencies warn that the North Korean government is sponsoring ransomware attacks to fund its cyber-espionage activities.

Organizations in the US healthcare and public health sector are among the top targets for state-sponsored North Korean cyber-threat actors seeking to fund espionage activities via ransomware and other attacks.

That's the assessment of the US Cybersecurity and Infrastructure Security Agency (CISA), the FBI, the US Department of Health and Human Services, and South Korean intelligence agencies. In a joint advisory Feb. 9, the group described the North Korean government as using revenues — in the form of cryptocurrency — from these ransomware attacks to fund other cyber operations that include spying on US and South Korean defense sector and defense industrial base organizations.

**State-Sponsored Ransomware Attacks With a Mission**

"The authoring agencies assess that an unspecified amount of revenue from these cryptocurrency operations supports DPRK national-level priorities and objectives," the advisory said.

The alert also cautioned ransomware victims in healthcare and critical infrastructure sectors against paying ransoms. "Doing so does not guarantee files and records will be recovered and may pose sanctions risks," it said.

There is little in the advisory to indicate whether it was prompted by new threat intelligence or word about imminent attacks. But it comes amid a continuing increase in ransomware attacks against healthcare entities overall. A report by the Journal of the American Medical Association (JAMA) earlier this year identified a doubling in the number of ransomware attacks against healthcare entities between 2016 and 2021. Of the total 374 ransomware attacks on US healthcare organizations during that period, some 44% disrupted heathcare delivery.

The most common disruptions included systems downtime, cancellations of scheduled care, and ambulance diversions. JAMA's study found an increase especially in ransomware attacks against large healthcare organizations with multiple facilities between 2016 and 2021.

A June 2022 report from Sophos showed 66% of healthcare organizations experienced at least one ransomware attack in 2021. Sixty-one percent of those attacks ended with the attackers' encrypting data and demanding a ransom for the decryption key.

"Healthcare saw the highest increase in volume of cyberattacks (69%) as well as the complexity of cyberattacks (67%) compared to the cross-sector average of 57% and 59% respectively," Sophos said.

**New Intel, New Tactics**

CISA's latest cybersecurity advisory this week updates its earlier guidance on state-sponsored ransomware attacks from North Korea directed against the US healthcare and public health sector. It highlighted multiple tactics, techniques, and procedures (TTPs) that North Korean cyber actors are currently employing when executing ransomware attacks against healthcare targets. Most of the TTPs are typical of those observed with ransomware attacks and include tactics like lateral movement and asset discovery.

The advisory also highlighted several ransomware tools — and associated indicators of compromise (IoCs) — that North Korean actors have been using in attacks on healthcare organizations. Among them were privately developed variants such as Maui and H0lyGh0st and publicly available encryption tools such as BitLocker, Deadbolt, Jogsaw, and Hidden Tear.

"In some cases, DPRK actors have portrayed themselves as other ransomware groups, such as the REvil ransomware group," in an attempt to evade attribution, the advisory said.

In addition to obfuscating their involvement by operating with other affiliates and foreign third parties, North Korean actors frequently use fake domains, personas, and accounts to execute their campaigns, CISA and the others said. "DPRK cyber actors will also use virtual private networks (VPNs) and virtual private servers (VPSs) or third-country IP addresses to appear to be from innocuous locations instead of from DPRK."

The advisory highlighted some of newer software vulnerabilities that state-backed groups in North Korea have been exploiting in their ransomware attacks. Among them were the Log4Shell vulnerability in the Apache Log4j framework (CVE-2021-44228) and multiple vulnerabilities in SonicWall appliances.

CISA's recommended mitigations against the North Korean threat included stronger authentication and access control, implementing the principle of least privilege, employing encryption and data masking to protect data at rest, and securing protected health information during collection, storage, and processing.

The advisory also urged healthcare entities to maintain isolated backups, develop an incident response plan, update operating systems and applications, and monitor remote desktop protocol (RDP) and other remote access mechanisms.

Healthcare in the Crosshairs of North Korean Cyber Operations

State-backed hackers from North Korea are conducting ransomware attacks against healthcare and critical infrastructure facilities to fund illicit activities, U.S. and South Korean cybersecurity and intelligence agencies warned in a joint advisory.
The attacks, which demand cryptocurrency ransoms in exchange for recovering access to encrypted files, are designed to support North Korea's

Threat Intelligence / Ransomware

State-backed hackers from North Korea are conducting ransomware attacks against healthcare and critical infrastructure facilities to fund illicit activities, U.S. and South Korean cybersecurity and intelligence agencies warned in a joint advisory.

The attacks, which demand cryptocurrency ransoms in exchange for recovering access to encrypted files, are designed to support North Korea's national-level priorities and objectives.

This includes "cyber operations targeting the United States and South Korea governments — specific targets include Department of Defense Information Networks and Defense Industrial Base member networks," the authorities said.

Threat actors with North Korea have been linked to espionage, financial theft, and cryptojacking operations for years, including the infamous WannaCry ransomware attacks of 2017 that infected hundreds of thousands of machines located in over 150 countries.

Since then, North Korean nation-state crews have dabbled in multiple ransomware strains such as VHD, Maui, and H0lyGh0st to generate a steady stream of illegal revenues for the sanctions-hit regime.

Besides procuring its infrastructure through cryptocurrency generated through its criminal activities, the adversary is known to function under third-party foreign affiliate identities to conceal their involvement.

Attack chains mounted by the hacking crew entail the exploitation of known security flaws in Apache Log4j, SonicWall, and TerraMaster NAS appliances (e.g., CVE 2021-44228, CVE-2021-20038, and CVE-2022-24990) to gain initial access, following it up by reconnaissance, lateral movement, and ransomware deployment.

In addition to using privately developed ransomware, the actors have been observed leveraging off-the-shelf tools like BitLocker, DeadBolt, ech0raix, Jigsaw, and YourRansom for encrypting files, not to mention even impersonating other ransomware groups such as REvil.

As mitigations, the agencies recommend organizations to implement the principle of least privilege, disable unnecessary network device management interfaces, enforce multi-layer network segmentation, require phishing-resistant authentication controls, and maintain periodic data backups.

The alert comes as a new report from the United Nations found that North Korean hackers stole record-breaking virtual assets estimated to be worth between $630 million and more than $1 billion in 2022.

The report, seen by the Associated Press, said the threat actors used increasingly sophisticated techniques to gain access to digital networks involved in cyberfinance, and to steal information from governments, companies, and individuals that could be useful in North Korea's nuclear and ballistic missile programs.

It further called out Kimsuky, Lazarus Group, and Andariel, which are all part of the Reconnaissance General Bureau (RGB), for continuing to target victims with the goal of creating revenue and soliciting information of value to the hermit kingdom.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

North Korean Hackers Targeting Healthcare with Ransomware to Fund its Operations

Here are three of the worst breaches, attacker tactics and techniques of 2022, and the security controls that can provide effective, enterprise security protection for them.
#1: 2 RaaS Attacks in 13 Months
Ransomware as a service is a type of attack in which the ransomware software and infrastructure are leased out to the attackers. These ransomware services can be purchased on the dark web from

Here are three of the worst breaches, attacker tactics and techniques of 2022, and the security controls that can provide effective, enterprise security protection for them.

**#1: 2 RaaS Attacks in 13 Months**

Ransomware as a service is a type of attack in which the ransomware software and infrastructure are leased out to the attackers. These ransomware services can be purchased on the dark web from other threat actors and ransomware gangs. Common purchasing plans include buying the entire tool, using the existing infrastructure while paying per infection, or letting other attackers perform the service while sharing revenue with them.

In this attack, the threat actor consists of one of the most prevalent ransomware groups, specializing in access via third parties, while the targeted company is a medium-sized retailer with dozens of sites in the United States.

The threat actors used ransomware as a service to breach the victim's network. They were able to exploit third-party credentials to gain initial access, progress laterally, and ransom the company, all within mere minutes.

The swiftness of this attack was unusual. In most RaaS cases, attackers usually stay in the networks for weeks and months before demanding ransom. What is particularly interesting about this attack is that the company was ransomed in minutes, with no need for discovery or weeks of lateral movement.

A log investigation revealed that the attackers targeted servers that did not exist in this system. As it turns out, the victim was initially breached and ransomed 13 months before this second ransomware attack. Subsequently, the first attacker group monetized the first attack not only through the ransom they obtained, but also by selling the company's network information to the second ransomware group.

In the 13 months between the two attacks, the victim changed its network and removed servers, but the new attackers were not aware of these architectural modifications. The scripts they developed were designed for the previous network map. This also explains how they were able to attack so quickly - they had plenty of information about the network. The main lesson here is that ransomware attacks can be repeated by different groups, especially if the victim pays well.

"RaaS attacks such as this one are a good example of how full visibility allows for early alerting. A global, converged, **cloud-native SASE platform** that supports all edges, like Cato Networks provides complete network visibility into network events that are invisible to other providers or may go under the radar as benign events. And, being able to fully contextualize the events allows for early detection and remediation.

**#2: The Critical Infrastructure Attack on Radiation Alert Networks**

Attacks on critical infrastructure are becoming more common and more dangerous. Breaches of water supply plants, sewage systems and other such infrastructures could put millions of residents at risk of a human crisis. These infrastructures are also becoming more vulnerable, and attack surface management tools for OSINT like Shodan and Censys allow security teams to find such vulnerabilities with ease.

In 2021, two hackers were suspected of targeting radiation alert networks. Their attack relied on two insiders that worked for a third party. These insiders disabled the radiation alert systems, significantly debilitating their ability to monitor radiation attacks. The attackers were then able to delete critical software and disable radiation gauges (which is part of the infrastructure itself).

"Unfortunately, scanning for vulnerable systems in critical infrastructure is easier than ever. While many such organizations have multiple layers of security, they are still using point solutions to try and defend their infrastructure rather than one system that can look holistically at the full attack lifecycle. Breaches are never just a phishing problem, or a credentials problem, or a vulnerable system problem - they are always a combination of multiple compromises performed by the threat actor," said Etay Maor, Sr. Director of Security Strategy at **Cato Networks**.

**#3: The Three-Step Ransomware Attack That Started with Phishing**

The third attack is also a ransomware attack. This time, it consisted of three steps:

**1\. Infiltration** - The attacker was able to gain access to the network through a phishing attack. The victim clicked on a link that generated a connection to an external site, which resulted in the download of the payload.

**2\. Network activity** - In the second phase, the attacker progressed laterally in the network for two weeks. During this time, it collected admin passwords and used in-memory fileless malware. Then on New Year's Eve, it performed the encryption. This date was chosen since it was (rightfully) assumed the security team would be off on vacation.

**3\. Exfiltration** - Finally, the attackers uploaded the data out of the network.

In addition to these three main steps, additional sub-techniques were employed during the attack and the victim's point security solutions were not able to block this attack.

"A multiple choke point approach, one that looks horizontally (so to speak) at the attack rather than as a set of vertical, disjointed issues, is the way to enhance detection, mitigation and prevention of such threats. Opposed to popular belief, the attacker needs to be right many times and the defenders only need to be right just once. The underlying technologies to implement a multiple choke point approach are full network visibility via a cloud-native backbone, and a single pass security stack that's **based on ZTNA**." said Etay Maor, Sr. Director of Security Strategy at Cato Networks.

**How Do Security Point Solutions Stack Up?**

It is common for security professionals to succumb to the "single point of failure fallacy". However, cyber-attacks are sophisticated events that rarely involve just one tactic or technique which is the cause of the breach. Therefore, an all-encompassing outlook is required to successfully mitigate cyber-attacks. Security point solutions are a solution for single points of failure. These tools can identify risks, but they will not connect the dots, which could and has led to a breach.

**Here's Watch Out for in the Coming Months**

According to ongoing security research conducted by Cato Networks Security Team, they have identified two additional vulnerabilities and exploit attempts that they recommend including in your upcoming security plans:

**1\. Log4j**

While **Log4j** made its debut as early as December of 2021, the noise its making hasn't died down. Log4j is still being used by attackers to exploit systems, as not all organizations have been able to patch their Log4j vulnerabilities or detect Log4j attacks, in what is known as "virtual patching". They recommend prioritizing Log4j mitigation.

**2\. Misconfigured Firewalls and VPNs**

Security solutions like firewalls and VPNs have become access points for attackers. Patching them has become increasingly difficult, especially in the era of architecture cloudification and remote work. It is recommended to pay close attention to these components as they are increasingly vulnerable.

**How to Minimize Your Attack Surface and Gain Visibility into the Network**

To reduce the attack surface, security professionals need visibility into their networks. Visibility relies on three pillars:

*   Actionable information - that can be used to mitigate attacks
*   Reliable information - that minimizes the number of false positives
*   Timely information - to ensure mitigation happens before the attack has an impact

Once an organization has complete visibility to the activity on their network they can contextualize the data, decide whether the activity witnessed should be allowed, denied, monitored, restricted (or any other action) and then have the ability to enforce this decision. All these elements must be applied to every entity, be it a user, device, cloud app etc. All the time everywhere. That is what SASE is all about.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

3 Overlooked Cybersecurity Breaches

**ORLANDO, Fla.****,** **Feb. 8, 2023** **/PRNewswire/ --** The U.S. utilities industry is banding together to help suppliers identify and remediate vulnerabilities in software managing mission-critical applications for the U.S. energy industry. Several investor-owned utilities -- including American Electric Power and Avangrid Networks – today partnered with Fortress Information Security (Fortress) to launch the North America Energy Software Assurance Database (NAESAD) at the 2023 DistribuTECH Conference. NAESAD will provide the energy industry with a comprehensive Software Bill of Materials (SBOM) repository for every vendor.

Over the past several years, SolarWinds and Log4J vulnerabilities have highlighted the need to have a fundamental accounting for every software component used within the energy industry.

"The challenges for utilities and their supply chain partners are significant, but there is a clear path to mitigating critical risks," said Alex Santos, CEO of Fortress, the supply chain cybersecurity leader for critical infrastructure. "Industry players must collaborate – from the smallest supplier to the largest utility. The SBOM for every critical product needs to be carefully analyzed to reveal, prioritize, and eliminate the vulnerabilities that pose the greatest threat to the U.S. energy industry."

SBOMs provide the recipe of proprietary and open-source ingredients in software that run critical infrastructure technologies. SBOMs provide actionable information to purchasers so they can make informed decisions about software and help improve the security of applications. While many standards and guidelines require varying levels of software security, an effectively prepared and analyzed SBOM can be invaluable in meeting tomorrow's critical infrastructure application cybersecurity challenges.

NAESAD will securely aggregate SBOMs for every utility industry vendor. In close collaboration with forward-looking software providers, the repository will enable utilities to identify, triage, and remediate the most impactful and destructive risks. NAESAD is following the private-public partnership blueprint developed by the Cyberspace Solarium Commission.

Today's NAESAD launch comes as regulators, policymakers, and utilities focus more on SBOMs. A triad of SBOM regulations and recommendations from The Cybersecurity and Infrastructure Security Agency (CISA), The National Institute of Standards & Technology (NIST), The Office of Management and Budget (OMB), and a Presidential Executive Order has laid the groundwork for new SBOM requirements for companies that work with the U.S. Department of Energy, U.S. Department of Homeland Security, and other organizations responsible for U.S. critical infrastructure. Additional SBOM requirements for utilities and other critical industries are expected over the next year.

More details about how to join NAESAD and share SBOMs with utility partners can be found at NAESAD.com.

**About Fortress Information Security**  
Fortress secures North America's power and defense supply chains from cyberattacks on operational and critical enterprise technologies. Fortress' proprietary technology platform orchestrates North America'smost advanced cyber supply chain risk management and vulnerability management programs. Fortress operates the Asset to Vendor Network and the North American Energy Software Assurance Database, which give critical operators confidence that the products, services, and software they obtain from others are cyber-safe. Fortress is a Goldman Sachs portfolio Company.

SOURCE Fortress Information Security

Leading Energy Companies Tap Fortress to Build and Operate Industry Repository to Identify and Remediate Critical Software Vulnerabilities

An issue was discovered in Couchbase Server 7.x before 7.0.5 and 7.1.x before 7.1.2. A crafted HTTP REST request from an administrator account to the Couchbase Server Backup Service can exhaust memory resources, causing the process to be killed, which can be used for denial of service.

CVE-2022-42950: Couchbase Alerts

SQL Injection vulnerability in Talend ESB Runtime 7.3.1-R2022-09-RT thru 8.0.1-R2022-10-RT when using the provisioning service.

**Security incident response information**

Publication date: February 01, 2023

****CVE-2022-45588 and CVE-2022-45589****

Publication date: December 22, 2022

**Okta code repository breach disclosure**

Talend security team is aware of the recent Okta code repository breach disclosure. Per Okta statement here, Talend system has not been impacted and Talend security team continue to monitor the situation.

_Okta statement :_ "**There is no impact to any customers**, including any HIPAA, FedRAMP or DoD customers. No action is required by customers."

Publication date: October 28, 2022

 **CVE-2022-3602 and CVE-2022-3786 Vulnerabilities in OpenSSL 3.0.x**

Talend is aware of and monitoring the pre-announced OpenSSL 3.x (CVE-2022-3602 and CVE-2022-3786) security vulnerability.

Talend is scoping the remediation efforts throughout its Product portfolio and is in the process of developing fixes and remediations to address the vulnerability.

Update: November 1, 2022

To the best of our knowledge and the information currently available, Talend products are **not impacted** by \*\* CVE-2022-3602 and CVE-2022-3786 \*\* security vulnerabilities present in OpenSSL 3.0.x

While not directly exposed to vulnerable version of OpenSSL, we have proactively implemented preventative mitigations and continuous monitoring in Talend Cloud as an added precaution.

  
Publication date: October 20, 2022

﻿**Apache Commons Text variable interpolation (CVE-2022-42889)**

Talend is aware of and monitoring CVE-2022-42889 (Apache Commons Text aka Text4Shell) security vulnerability.  
Mitigations for the vulnerability were implemented in Talend Cloud on October 20, 2022 with no observed impact as a result of the vulnerability prior to implementing the mitigations.  
Talend is scoping the remediation efforts throughout its Product portfolio and is in the process of developing the code fix to address the impacted Products.

Update: October 24, 2022

The Apache Commons Text vulnerability CVE-2022-42889 only applies when the StringSubstitutor API is used with untrusted input. At Talend, we do not use the StringSubstitutor API directly in any of our on-prem products with untrusted input. We have not found any instance of a third-party dependency that we include with our products that uses StringSubstitutor in an insecure way. However, to fully remediate the issue we will be updating the Commons Text version for all our of impacted products.

The Apache Security team have released a statement to clarify the impact of CVE-2022-42889: https://blogs.apache.org/security/entry/cve-2022-42889

_"This issue is different from Log4Shell (CVE-2021-44228) because in Log4Shell, string interpolation was possible from the log message body, which commonly contains untrusted input. In the Apache Common Text issue, the relevant method is explicitly intended and clearly documented to perform string interpolation, so it is much less likely that applications would inadvertently pass in untrusted input without proper validation."_

Publication date: May 26, 2022

**CVE-2022-31648**

Publication date: May 3, 2022

****CVE-2022-29942 and CVE-2022-29943****

Publication date: April 5, 2022

****Spring4Shell (CVE 2022-22965; CVE-2022-22963)****

Talend is aware of and monitoring CVE 2022-22965 and CVE-2022-22963 security vulnerabilities for whether they affect any of our Talend products.

We have been working diligently on addressing the situation throughout our Product portfolio and are in process of developing the code fix to address the impacted Products.

For updates on our investigation and what you can do to assist remediation or mitigation of the vulnerability, please periodically visit the documentation page located at https://help.talend.com/r/RUfDtlfQvuDzJUZC4P9Z9g/7G3ZMXPTMt2klpS~SJ0vtg

As of April 1, 2022, we implemented blocking of external exploitation attempts on Talend Cloud Products for these CVEs.

Publication date: February 10, 2022

****CVE-2021-40684 and CVE-2021-42837****

Publication date: January 18, 2022

**Log4j2 Issue (CVE-2021-44228)******CVE-2021-44228 and CVE-2021-45046****

Talend is aware of the recently disclosed vulnerabilities related to the open-source Apache Software Foundation “Log4j2" utility (reported under CVE-2021-44228 and CVE-2021-45046 as critical severity level). Talend has patched all relevant Products to remedy these vulnerabilities.

Here, you can find additional Product specific information regarding remediation efforts. Certain Talend Products may require configuration changes, which will be shared as they become available. Until deployment of Log4j v2.16, please follow the steps below.

****CVE-2021-45105 and CVE-2021-44832****

Talend is aware of the recently disclosed medium severity vulnerabilities reported under CVE-2021-45105 and CVE-2021-44832 related to the open-source Apache Software Foundation “Log4j2" utility.

CVE-2021-45105 is only applicable when the logging configuration uses a non-default Pattern Layout with a Context Lookup. By default, Talend Products do not use Context Lookups, meaning the vulnerability is only applicable if the Customer manually changed the logging configuration. For Customers that manually changed the logging configuration, the CVE-2021-45105 vulnerability is addressed in Log4J 2.17.0. For Remote Engine Gen1, CVE-2021-45105, Talend addressed the CVE-2021-45105 vulnerability by updating to Log4J 2.17.0 in version 2.11.7.

CVE-2021-44832 is only applicable when the logging configuration uses a JDBC appender with a JNDI data source, or the log4j configuration is modified by an attacker. Talend products do not use a JDBC appended by default for logging. The CVE-2021-44832 vulnerability is addressed in Log4J 2.17.1.

Both medium severities CVEs are resolved with Log4j 2.17.1., which will be released during Talend’s monthly patch within its Continuous Maintenance Development process.

If you need additional details or assistance, please contact Talend Support on Talend Support portal (https://login.talend.com/support-login.php) or by sending an e-mail to customercare@talend.com.

**References**

Apache Log4j2 CVE-2021-44228   
Apache Log4j2 CVE-2021-45046  
Apache Log4j Security Vulnerabilities

**Changelog**

_2022.01.18_  
\- TDC On-Prem section update

_2022.01.07_  
\-  EOL versions evaluation sentence updated

_2022.01.06  
_\- “References” Section updated

_2022.01.04_  
\- “Summary” Table updated:

*   ESB Runtime 7.1.1 Patch information updated
*   Remote Engine Gen1 (Marketplace) patch information updated
*   Talend Cloud Application updated

_2021.12.28_  
\- “Summary” Table updated:

*   ESB Runtime 7.3.1 Patch information updated
*   LogServer 7.1.1 Patch information updated

_2021.12.27  
_\- “Summary” Table updated:

*   Talend Studio 7.2.1 and 7.1.1 Patch information updated
*   IAM 7.1.1 Patch information updated

_2021.12.24  
_\- “Summary” Table updated:

*   ESB Runtime 7.2.1 Patch information updated
*   Remote Engine Gen1 Patch information updated
*   Remote Engine Gen1 (Marketplace) Patch information updated
*   Talend Data Catalog Patch information updated

_2021.12.23  
_\- “Summary” Table updated:

*   ESB Runtime 7.3.1 Patch information updated: Pending Date
*   ESB Runtime 8.0.1 Patch information updated
*   Remote Engine Gen 1 Patch information updated: Pending Date
*   Talend Data Catalog Patch information updated: Pending Date

_2021.12.22  
_\- “Summary” Table updated:

*   Studio 7.3.1 Patch information updated

_2021.12.21  
_\- “Summary” Table updated with:

*   available patch information
*   Studio Mitigation information update

_2021.12.20  
_\- “Summary” Table updated:

*   ESB Runtime 7.1.1 Mitigation and Patch information added
*   IAM 7.1.1 Mitigation and Patch information added
*   LogServer 7.1.1 Mitigation and Patch information added
*   JobServer 7.1.1 Mitigation and Patch information added
*   MDM 7.1.1 Mitigation and Patch information added
*   Talend Administration Center (TAC) Mitigation and Patch information added
*   Talend Data Preparation 7.1.1 Mitigation and Patch information added
*   Talend Data Stewardship 7.1.1 Mitigation and Patch information added
*   Talend Studio On-prem 7.1.1 Mitigation and Patch information added

\- Section “Mitigation steps for TAC” updated  
\- Section “Mitigation steps for ESB Runtime” updated with pre-requisite instructions for 7.2.1 and 7.1.1  
\- Section “Mitigation steps for Remote Engine Gen1” updated with optional step if “impersonate job” feature used

_2021.12.17  
_\- “Summary” Table updated:

*   Talend Data Preparation Mitigation and Patch information added
*   Talend Data Stewardship Mitigation and Patch information added
*   Talend Remote Engine Gen1 (Marketplace) Mitigation and Patch information added
*   Talend Studio Cloud Mitigation information updated
*   Talend Studio on-prem Mitigation and Patch 7.2 information updated

\- Section “Mitigation steps for IAM” - startup script updated  
\- Section “Mitigation steps for MDM” - startup script updated  
\- Section “Mitigation steps for TAC” - startup script updated

_2021.12.16  
_\- “Summary” Table updated:

*   ESB Runtime patch information updated
*   Jobserver Mitigation and Patch information updated
*   MDM Mitigation updated
*   Remote Engine Gen1 Patch information updated
*   Talend Data Catalog Mitigation and Patch updated
*   Talend Studio Mitigation and Patch information updated

\- Section “Mitigaton steps for ESB Runtime” updated with new parameter JAVA\_TOOL\_OPTIONS  
\- Section “Mitigaton steps for JobServer” updated with specific instructions per version  
\- Section “Mitigation steps for MDM” added  
\- Section “Mitigation steps for Remote Engine Gen1” updated with new parameter JAVA\_TOOL\_OPTIONS

_2021.12.15_  
\- Original version

**Summary**

_Remediation for Talend Open Source is not in scope. End-of-Life versions evaluations have been completed. For further details, please contact Talend Support._

**Additional Details**

To accommodate better up-to-date content, all the mitigation technical step section has been moved to the “Log4j2 Issue (CVE-2021-44228)” section of Talend Documentation site. The section is locate at <https://document-link.us.cloud.talend.com/talend\_log4j2\_cve\_statement?lang=en&version=latest&env=prd\>

**Frequently Asked Questions**

**Does Talend employ affected versions of Log4j its software?  
**Yes. Certain Talend Services use Log4j2 or provide it to customers as part of their Services. Details regarding specific Talend Service versions and steps to address the issues are provided in the Security Incident Response.

**Is Log4j part of any functionality a Talend customer uses when working with Talend?  
**Yes.

**Does Talend have a patch available now or when will it be available?  
**Patches are specific to Talend Service, the version of the Talend Service, the severity of the risk, and other mitigating controls Talend maintains. While Talend has developed and implemented patches for the Apache Log4j2 vulnerability, the situation is dynamic, and updates are disclosed on a continuous basis. To stay up to date with the most relevant information, please refer to the table in the Summary section of this document.

**How will Talend notify its customers and how will customers receive the patch?** We have reached out to Customers via registered support contacts with instructions to monitor the Security Incident response page. This page is updated regularly and is the best source for up-to-date information.

**If Talend is hosting the customers Talend instance, is Talend using Apache Log4j on any of its systems?  
**Yes. Certain Talend Services use Log4j2, or provide it to customers as part of their Services.

**What steps has Talend taken to mitigate the threat?  
**Since disclosure of the Apache Log4j2 vulnerability, Talend has taken steps to identify all the instances where Apache Log4j2 is utilized within Talend Services, developed, and implemented patches where applicable and as needed, implemented other mitigating controls, and contacted Talend vendors regarding their exposure to Apache Log4j2.

Mitigation efforts, including software patches, are specific to Talend Service, the version of the Talend Service, and the severity of the risk. While Talend has developed patches for the Apache Log4j2 vulnerability, the situation is dynamic, and updates are disclosed on a continuous basis. To stay up to date with the most relevant information, please refer to the table in the Summary section of this document.

**Is Talend monitoring its systems for any indication of compromise (IOC)?  
**Yes.

**Have any of Talend's 3rd parties been affected by this threat?  
**Yes. Part of what makes the Apache log4j2 vulnerability so severe, is its widespread use. Talend is in the process of communicating with critical vendors to coordinate remediation.

**Will Talend publish information related to versions which have reached their end of life (e.g.** 5.X, 6.X, or earlier 7.X releases**)?**  
Yes. Currently supported products are our priority.  To determine if a version is supported or has reached its end-of-life, please refer to Talend's Product support lifecycle https://www.talend.com/technical-support/support-statements/. Please see summary table above for version-specific information.

**With use of the dynamic distribution feature of Talend to connect with a cluster; is it necessary to rebuild/republish jobs to remediate the log4j vulnerability?  
**Yes. 

**For Talend v7.3 and Talend v8.0, do I need to rebuild my Talend jobs and Routes after  
installing the Studio patch?**   
Yes.

CVE-2022-45589: Talend Security

The average organization does business with 11 third parties, and 98% of organizations do business with a third party who has suffered a breach, an analysis finds.

Nearly every company does business with — or uses the products of — a third party that has suffered a compromise, thus increasing their security risks.

That's according to data science firm Cyentia Institute, which has issued an analysis that includes external measurements of security from more than 230,000 organizations provided by cybersecurity risk-management firm SecurityScorecard. It found that the average firm had around 10 third-party relationships, and hundreds of indirect fourth-party relationships, with the typical firm having 60 to 90 times more fourth parties than third parties. Nearly all firms (98%) had at least one third-party partner who had suffered a breach, the report stated.

The IT sector has the most third parties, with an average of 25, while the finance sector had the fewest, at 6.5. Those numbers quickly balloon when fourth-party relationships are included, as did their risk. The average firm has an indirect relationship with 200 fourth parties that have had a breach, the analysis found.

The research underscores the sprawling nature of third- and fourth-party relationships for corporations, and the dramatic increase in risk that they can cause, says Wade Baker, founder and partner at the Cyentia Institute.

"Risk goes downhill," he says. "The first parties are more likely to have good security \[risk\] scores than their third parties, and with fourth parties, the numbers really explode. You need to expect \[these firms and products\] to not be up to your standards for security."

That's because while many organizations have become more mature regarding their own cyber risks, few are cognizant of the extended risks, Cyentia and SecurityScorecard stated in the analysis.

"Many organizations are still unaware of the dependencies and exposures inherent to third-party relationships, and simply focus on managing their own security posture," the report stated. "Others are aware of those issues, but don't make vendor decisions based on security and/or require vendors to meet certain standards. Even firms that do establish third-party security requirements can struggle to continually monitor compliance and progress."

    

Almost all companies did business with a third party who had been compromised in the past 2 years. Source: Cyentia Institute and SecurityScorecard

Third-party and supply-chain risk have become significant issues in recent years. And CISOs have become increasing wary of their third-party providers, ever since the compromise of an HVAC supplier led to the breach of retail giant Target.

While the analysis looks at third-party risk, the definition of what a third party is extends not just to vendors and partners, but software providers and open source projects. Now-infamous attacks on software suppliers such as SolarWinds, and vulnerabilities in widely used software components such as Log4J, have raised the visibility of the risk that this arena poses.

The top 5 technologies included in third-party relationships within the data are Google Analytics, Google Tag Manager, Amazon Web Hosting, PHP, and Facebook products — all of which were involved in two-thirds (68%) of third-party relationships, the report stated.

"A lot of these third and fourth party relationships \[involve us\] both agreeing to adhere to certain policies just by virtue of using a product, and now I'm opening up myself to a certain degree of risk," Baker says.

**Risk Rises With Each Hop**

The analysis also found that third parties typically have a weaker security posture than the companies they served. Overall, there is a much higher likelihood that third parties will have security problems, meaning that companies can't assume that all of their third parties are as diligent about security.

"I view it in the same way as all of us knowing we have too many privileges — in general, people have access to more data than they need to do their job," Baker says. "It would be good to reduce the number of third parties, especially if they're not needed, and also be a little bit more choosy."

The data, however, does not suggest a clear path forward, beside becoming more aware of the problem. Baker does not necessarily recommend, for example, that organizations cut the bottom 25% of their third parties from their business. However, evaluating them more closely or more frequently might be more realistic, he says.

"If we really want to protect our supply chains, we've got to we've got to make the weakest link stronger," Baker says. "And I think the analysis is showing that there's a lot of weak links across third parties and fourth parties, and that is where the challenge lies."

Nearly All Firms Have Ties With Breached Third Parties

Malware eventually has to exfiltrate the data it accessed. By watching DNS traffic for suspicious activity, organizations can halt the damage.

**Question: How does a threat actor utilize DNS communications in malware attacks?**

**Dave Mitchell, CTO, Hyas:** The idea that you can protect yourself from all malware is unrealistic, especially considering malware is an umbrella term that does not refer to any specific exploit, vector, goal, or methodology. Because the range of cyber threats is so wide and varied, there is no magic bullet that will repel every attack. So it's really only a matter of time before your network environment is compromised, forcing you to make some very hard decisions.

For instance, in the medical field, successful cyber attacks don't just affect an organization's ability to function; they also have major legal and reputational repercussions. Because of these circumstances, medical industry victims end up paying out ransomware demands at a higher rate than any other industry. If they were able to detect indicators of problems before they become full-blown attacks, healthcare organizations could save an average of $10.1 million per incident averted.

Most security solutions address a specific subsection of malware and/or infiltration vectors, but none of them can stop all threats at the gate. Even if they could, sometimes the gate is bypassed altogether. As we saw with the Log4J exploit and the recent compromise of the popular Ctx Python package, "trusted" resource libraries hosted on places like GitHub can be compromised by outside entities and used to deliver payloads of malware to thousands of endpoints without immediately triggering a red flag.

Not all threats lurk solely in cyberspace. Returning to the healthcare industry as an example highlights another attack vector that can get around all of your perimeter security — physical access. Most hospitals, physician's offices, pharmacies, and other medical facilities rely on networked terminals and devices located (or accidently left) in places where they can be accessed by patients, visitors, or other unauthorized users. In situations like these, it doesn't matter how well-defended your network is from outside attacks because the bad actor can simply insert a USB stick or use a logged-in device to access malware, compromising the network from within.

This may seem like an unwinnable situation, but thankfully there is one feature that ties the overwhelming majority of malware together — a shared Achilles' heel called the Domain Name System (DNS). More than 91% of malware utilizes DNS communication at some point during its attack lifecycle, making DNS an invaluable choke point in the fight against cyber threats.

When a piece of malware first finds its way onto your network, it tries to avoid detection. It uses this time as a reconnaissance phase during which it attempts to spread to more devices in the network environment, locate critical resources, and compromise backup storage.

It is also during this time that the malware needs to communicate back to the hackers' command and control (C2) infrastructure to receive instructions and report the information it has uncovered about the network. Like any traffic on the Internet, to communicate back out into the world, it needs to make a request to a domain name server. By employing a protective DNS solution, network administrators can monitor DNS traffic for indicators of malicious activity and then take action by blocking, quarantining, or otherwise disrupting it.

Unfortunately, with new threats being developed all the time and the ever-present risk of a physically initiated attack, companies must prepare for the inevitable successful breach of their network. However, once malware has gotten inside your network, it is almost certain to employ DNS communication at some point. A protective DNS solution can detect these abnormal requests and block them entirely, rendering the malware inert and letting you quickly begin the process of cleaning your systems and shoring up your defenses for next time.

How Can Disrupting DNS Communications Thwart a Malware Attack?

An issue was discovered in the rollback feature of Elastic Endpoint Security for Windows, which could allow unprivileged users to elevate their privileges to those of the LocalSystem account.

CVE-2022-38775: Security issues

Cross-site Scripting (XSS) vulnerability in NetIQ iManager prior to version 3.2.6 allows attacker to execute malicious scripts on the user's browser. This issue affects: Micro Focus NetIQ iManager NetIQ iManager versions prior to 3.2.6 on ALL.

February 2022

NetIQ iManager 3.2 SP6 resolves previous issues. Many of these improvements were made in direct response to suggestions from our customers. We thank you for your time and valuable input. We hope you continue to help us ensure our products meet all your needs. You can post feedback in the iManager Community Support Forums, our community Web site that also includes product notifications, blogs, and product user groups.

For a full list of all issues resolved in NetIQ iManager 3.x, including all patches and service packs, refer to TID 7016795, “History of Issues Resolved in NetIQ iManager 3.x”.

For more information about this release and for the latest release notes, see the iManager Documentation Web site. To download this product, see the Software License and Download portal.

*   What’s New
    
*   System Requirements
    
*   Installing or Upgrading
    
*   Known Issues
    
*   Legal Notice
    

**1.0 What’s New**

iManager 3.2 SP6 provides the following enhancements and fixes in this release:

*   Operating System Support
    
*   Updates for Dependent Components
    
*   Fixed Issues
    

**1.1 Operating System Support**

In addition to the platforms supported in previous releases of iManager, this release adds support for the following:

*   Red Hat Enterprise Linux (RHEL) 8.5
    
*   Windows Server 2022
    

**1.2 Updates for Dependent Components**

This release adds support for the following third-party components:

*   Azul Zulu 1.8.0\_312
    
*   Apache Tomcat 9.0.55-1
    
*   OpenSSL 1.0.2za
    
*   Log4j 2.17.1
    

**1.3 Fixed Issues**

This release includes the following software fixes that resolve several previous issues:

**Resolved Security Vulnerabilities**

This version of iManager resolves security vulnerability CVE-2021-38134. Special thanks to Kajetan Rostojek for responsibly disclosing the information about CVE-2022-38758 to us.

**Occasional Delay When Loading Pages on the iManager User Interface After Upgrading to iManager 3.2.5**

_Fix:_ With the latest version of Tomcat 9.0.55-1 bundled with iManager 3.2.6, there is no longer any delay while loading the pages on the iManager User Interface.(Defect 440043)

**Connection Timeout Issue Seen When Modifying Directory Objects or Using Plug-Ins**

_Fix:_ With the latest version of Tomcat 9.0.55-1 bundled with iManager 3.2.6, there is no longer any delay while navigating the pages or browsing objects on the iManager User Interface. (Defect 448035)

**2.0 System Requirements**

For information about prerequisites, computer requirements, installation, upgrade or migration, see Planning to Install iManager in the NetIQ iManager Installation Guide.

_NOTE:_iManager uses the modified version of XULRunner on Windows. The source code for the modified XULRunner is available under the Mozilla Public License version 2.0. If you need further assistance with any issue, contact Technical Support.

**3.0 Installing or Upgrading**

To upgrade to iManager 3.2 SP6, you need to be on iManager 2.7.7 P11 or higher.

For more information on upgrading to iManager 3.2 SP6, see the NetIQ iManager Installation Guide.

IMPORTANT:

*   This version of iManager supports only eDirectory 9.2.6 or above when both are installed on the same machine. If you are upgrading iManager 2.7.7 P11 to 3.2 SP6, ensure that your eDirectory is also upgraded to 9.2.6 before upgrading iManager.
    
*   When you install or upgrade to iManager 3.2 SP6, a new imanager\_logging.xml file is created that includes the latest log4j 2.17.1 capabilities. During the upgrade process, the existing imanager\_logging.xml file is replaced with a new one. As a result, the previous audit settings are lost. To allow auditing for iManager events, you must configure the audit settings again in the new imanager\_logging.xml file after the upgrade. Make sure to take a backup of the existing file in a different location before performing the upgrade. For more information, see Auditing iManager Events in the NetIQ iManager Administration Guide.
    

**4.0 Known Issues**

NetIQ Corporation strives to ensure our products provide quality solutions for your enterprise software needs. There are no new issues other than the issues mentioned in the NetIQ iManager 3.2 SP5 Release Notes. If you need further assistance with any issue, please contact Technical Support.

**4.1 iManager Workstation Does Not Work on SLED 12 SP3, SLED 15, OpenSUSE Leap 42.3, OpenSUSE 13.2, and Onward**

_Workaround:_ To workaround this issue, launch iManager using the iManager.sh command and access the workstation through another browser via the URL: http://localhost:8080/nps. The port number can differ. You can find the port number in the iManager.log file located at <extracted\_directory>/imanager/bin/iManager.log location.

**5.0 Legal Notice**

For information about legal notices, trademarks, disclaimers, warranties, export and other use restrictions, U.S. Government rights, patent policy, and FIPS compliance, see https://www.netiq.com/company/legal/.

Copyright © 2022 NetIQ Corporation, a Micro Focus company. All Rights Reserved.

Tag

#log4j