**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.

CVE-2022-38758: NetIQ iManager 3.2 Service Pack 6 Release Notes

Syncro, a remote management and monitoring tool, emerges as an increasingly common tool for adversaries.
By Caitlin Huey.
Ransomware continued to be a top threat Cisco Talos Incident Response (Talos IR) responded to this quarter, with appearances from both previously seen and newly observed ransomware families. However, IR also observed

Thursday, January 26, 2023 04:01

Syncro, a remote management and monitoring tool, emerges as an increasingly common tool for adversaries.

_By_ _Caitlin Huey__._

Ransomware continued to be a top threat Cisco Talos Incident Response (Talos IR) responded to this quarter, with appearances from both previously seen and newly observed ransomware families. However, IR also observed a significant number of cases in which post-exploitation activities occurred where the actor’s motivation could not be determined. For example, phishing campaigns, our top initial-access vector this quarter, were equally as common and featured a variety of post-exploitation activities, including command execution to perform credential harvesting, red-teaming framework deployment and remote access tooling installation.

This quarter also featured several engagements where adversaries leveraged Syncro, a legitimate and full-featured remote access platform. Syncro was among many other remote access and management tools, including AnyDesk and SplashTop, that adversaries leveraged to establish and maintain remote access to compromised hosts. The use of Syncro to support a number of operations is consistent with a key finding from the Talos’ 2022 Year in Review, which reported that adversaries are increasingly relying on dual-use tools to stay undetected in victim environments.

**Targeting**

The telecommunications sector was the most targeted this quarter, closely followed by the education and manufacturing sectors, respectively. Telecommunications was a consistently top-targeted vertical in Talos IR engagements in 2022, apart from Q3, in which organizations in the education sector were most targeted.

**Ransomware**

Talos IR observed the BlackCat (ALPHV) ransomware, a ransomware family consistently seen in incidents throughout 2022, in a few engagements this quarter. This quarter also featured Royal ransomware, which had not previously been observed in Talos IR engagements. First emerging in early 2022 as a suspected Conti rebrand, Royal has been increasingly observed in attacks since September, according to public reporting.

This quarter Talos IR responded to an incident involving Royal ransomware. The group did not start posting victim data, which has been used as a means of extortion for over 50 companies globally spanning multiple business verticals, to their Tor leaks site until September 2022. In one Royal ransomware incident, Talos IR identified the affiliate(s) using red team frameworks such as Cobalt Strike and Mimikatz, and by performing mass uninstallation of security software across the environment. Talos IR also observed both the legitimate utility PsExec executing a shell on a remote share on one host, as well as AnyDesk service’s creation for persistence. The actor also used batch script files for persistence to perform various actions such as adding admin accounts using the “net user /add” command, executing commands to boot in Safe Mode and modifying the registry.

The emergence of Royal ransomware, as a suspected rebrand of Conti, which shut down its operations in June 2022, highlights the resilience of ransomware actors following the shut down and/or rebrand of high-profile groups. Royal’s appearance in an engagement this quarter coincided with increased public reporting on a malware downloader, dubbed BatLoader, which has delivered Cobalt Strike Beacon implants that distributed Royal ransomware. Researchers identified several attributes within the BatLoader attack chain that are similar to activity linked to Conti. The overlaps between the two include shared indicators of compromise (IOCs) and tactics, techniques and procedures (TTPs) such as the use of the Atera agent for remote access, as well as an IP address used by Conti affiliates in a campaign leveraging Log4j. While the exact relationship between Conti and BatLoader is still unknown, this nexus may suggest BatLoader’s potential for adoption by multiple ransomware operators/affiliates. Additionally, BatLoader’s incorporation of Royal as a primary ransomware payload likely indicates Royal rising in prominence as operators look to incorporate new threats and techniques to carry out financially motivated operations that will help them remain effective.

**Adversaries increasingly relying on Syncro**

Talos IR observed the Syncro remote management and monitoring (RMM) tool used in nearly 30 percent of engagements, a significant increase compared to previous quarters. Syncro is a commercially available RMM solution that advertises remote desktop access, remote registry editor, remote event viewer and more. Talos IR observed Syncro used as part of attack chains supporting multiple threats this quarter, including BatLoader. Syncro was also distributed in phishing campaigns to gain access to newly-compromised accounts. While the reason for Syncro’s increased usage is unknown, its use as a full-featured remote access platform for managed service providers (MSPs) and its ubiquity across enterprise environments likely makes it an attractive option.

First discovered in February 2022, BatLoader uses legitimate tools, like Syncro and the Atera remote access software, to maintain access to infected systems. Since October 2022, Talos has observed a general uptick in our endpoint telemetry and Talos IR investigations associated with BatLoader, which deploys a variety of secondary malware payloads including the Vidar information stealer and the commodity loader Ursnif/Gozi. In one BatLoader engagement, the initial access vector relied on phishing and/or search engine optimization (SEO) poisoning to lure users to download the malware from attacker-created websites. This is consistent with public reporting on typical BatLoader infections. After initial access was established, the BatLoader infection chain leveraged multiple PowerShell and batch scripts to download tools and components needed for subsequent stages of the attack.

In another incident, Talos IR identified legitimate accounts sending phishing emails with email subjects that translated from Arabic to “Staff Promotion.” The emails contained OneDrive and OneHub phishing links with a compressed Microsoft Windows Installer (MSI) file that would install Syncro. The adversary attempted to use Syncro to stay connected to the targeted user’s workstation. During analysis of the MSI file, multiple Syncro services were installed, including SyncroRecovery (SyncroLive) and SyncroOvermind. The adversary’s tactics appeared to focus on maintaining initial access through installation of Syncro. The lack of two-factor authentication (2FA) for email access allowed the adversary to perform phishing attacks, highlighting the need to ensure multi-factor authentication (MFA) across all critical assets.

Talos IR also observed Syncro installed as part of post-compromise behavior after successful phishing attacks established initial access. In a Qakbot engagement, a phishing email contained a malicious password-protected ZIP file that, when opened, contained an ISO file detected as Qakbot. The adversary was able to crack a weak password for a service account, then used the compromised account to deploy installers for remote access tools Syncro and SplashTop. Active Directory (AD) mapping tools such as ADFind and SharpHound were also identified when a compromised host attempted to access “SharpHound.exe” in the Downloads folder. Shortly after, the adversary created a new folder for the purpose of placing and staging additional tooling.

**Initial vectors**

This quarter, nearly 40 percent of engagements featured phishing emails used as a means to establish initial access, followed by user execution of a malicious document or link. In many engagements, valid accounts and/or accounts with weak passwords also helped facilitate initial access whereby the adversary leveraged compromised credentials. It is important to note that for the majority of incidents, Talos IR could not reasonably determine the initial vector because of logging deficiencies or a lack of visibility into the affected environment.

Talos IR continues to observe threats consistently seen across quarters, including attempts to take advantage of weaknesses or vulnerabilities in public-facing applications. In one engagement, the adversary entered the environment through an exposed Microsoft Remote Desktop Services (RDS) web application. After gaining access, the adversary took over service accounts via a successful Kerberoasting attack. Talos IR identified several script files that contained credentials for various user accounts, many of which had been hard-coded into the scripts themselves. ZIP files were also created shortly after the scripts, suggesting possible data staging activity. Talos IR believes the adversary was able to enter the environment using stolen credentials obtained through a previous phishing campaign against a user account, highlighting the need for user training and password reset policies, especially following suspected phishing attacks.

**Security weaknesses**

Lack of MFA remains one of the biggest impediments for enterprise security. Nearly 30 percent of engagements either had no MFA or only had it enabled on a handful of accounts and critical services. Talos IR frequently observes ransomware and phishing incidents that could have been prevented if MFA had been properly enabled on critical services, such as endpoint detection response (EDR) solutions or VPNs. To help minimize initial access vectors, Talos IR recommends disabling VPN access for all accounts that are not using two-factor authentication.

In all of the ransomware engagements that closed out this quarter, PsExec was used to facilitate lateral movement or execute the final ransomware executable. Talos IR recommends that organizations disable PsExec, as well as access to administrative shares, to limit lateral movement. Additionally, organizations should consider use of Microsoft AppLocker to block tools and files that have been consistently leveraged by adversaries. This helps to create another layer of enforcement for any known malicious or often-misused files.

**Top-observed MITRE ATT&CK techniques**

The table below represents the MITRE ATT&CK techniques observed in this quarter’s Talos IR engagement. Given that some techniques can fall under multiple tactics, we grouped them under the most relevant tactic in which they were leveraged. Please note, this is not an exhaustive list.

Key findings from the MITRE ATT&CK appendix include:

*   Legitimate remote access and management software, such as AnyDesk and TeamViewer, were leveraged in over 35 percent of engagements this quarter.
*   In every ransomware engagement this quarter, PsExec was used to facilitate lateral movement or execute the ransomware executable.
*   Phishing emails with malicious links and/or attachments were the top initial access vector this quarter, seen in nearly 40 percent of engagements. User execution of a malicious file or link would subsequently lead to a variety of malicious threats, including execution of commodity malware such as Qakbot.

Tactic 

Technique 

Example 

Initial Access (TA0001) 

T1078 Valid Accounts  

Adversary leveraged stolen or compromised credentials  

Reconnaissance (TA0043) 

T1592 Gather Victim Host Information 

Text file contains details about host 

Persistence (TA0003) 

T1136 Create Account 

Created a user to add to the local administrator’s group 

Execution (TA0002) 

T1059.001 Command and Scripting Interpreter: PowerShell  

Executes PowerShell code to retrieve information about the client's Active Directory environment 

Discovery (TA0007) 

T1046 Network Service Scanning   

Use a network or port scanner utility  

Credential Access (TA0006) 

T1003 OS Credential Dumping 

Deploy Mimikatz and publicly available password lookup utilities 

Privilege Escalation (TA0004)  

T1484 Domain Policy Modification   

Modify GPOs to execute malicious files  

Lateral Movement (TA0008) 

T1021.001 Remote Desktop Protocol  

Adversary made attempts to move laterally using Windows Remote Desktop 

Defense Evasion (TA0005) 

T1027 Obfuscated Files or Information 

Use base64-encoded PowerShell scripts 

Command and Control (TA0011) 

T1219 Remote Access Software   

Remote access tools found on the compromised system   

Impact (TA0040) 

T1486 Data Encrypted for Impact  

Deploy Hive ransomware and encrypt critical systems 

Exfiltration (TA0010) 

T1048.003 Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol  

Use WinSCP for potential exfiltration of system information   

Collection (TA0009) 

T1560.001 Archive Collected Data: Archive via Utility  

Adversary leveraged xcopy on Windows to copy files  

Software/Tool 

S0002 Mimikatz 

Use Mimikatz to obtain account logins and passwords

Quarterly Report: Incident Response Trends in Q4 2022

One of the most closely watched security startups continues to build bank because its platform appeals to both developers and security pros.

Developers, security professionals, and investors all find something to like about Snyk and its developer security platform, which helps organizations mitigate their risk of exposure to software supply chain attacks.

After closing $196.5 million in Series G investment late last month, Snyk on Tuesday said it secured an additional $25 million from ServiceNow. ServiceNow's investment brings the total amount Snyk has secured to $1.4 billion since 2020.

During those three years, the company behind the developer security platform has been adding on customers. Snyk claims its revenues last year grew 100%, with net revenue retention growing 130%. Snyk reports that it closed out 2022 with over 2,300 customers who remediated more than 5.1 million vulnerabilities. Identity verification provider Veriff ranked Snyk first in an analysis of security startups based on funding amounts, number of investors, employee counts, Twitter following, and the uniqueness of the product portfolio.

**Integrating Snyk With ServiceNow**

Following this investment, ServiceNow will embed Snyk's open source software component analysis (SCA) and intelligence tools into ServiceNow's Vulnerability Response. While Snyk can boost ServiceNow's vulnerability detection capabilities, its developer-focused tools can bring Snyk to more DevSecOps organizations.

"Snyk's vision is all the way from code to cloud, and cloud is really code," Snyk chief product officer Manoj Nair says. "We get people to build security in from the start, rather than putting firewalls and scanners and all that after the fact to catch what's wrong."

ServiceNow VP and general manager of security products Lou Fiorello envisions the Snyk platform extending his company's vulnerability detection capabilities. "This significantly furthers ServiceNow's ability to provide a single view into vulnerabilities across the enterprise technology environment, driving workflows to better prioritize and expedite vulnerability management," Fiorello said in a statement.

**Appealing to Developers and Security Professionals**

Founded in 2015, Snyk has stood out amid escalating growth in software supply chain attacks. Snyk's Developer Security Platform helps organizations reduce the risk of an attack by letting those who build container-based applications generate software bills of materials (SBOMs) during the development process.

"Snyk has been successful at building security tools that the developers like," says Enterprise Strategy Group senior analyst Melinda Marks. Marks emphasizes that developers find especially appealing Snyk's tools to test open source code using SCA and to scan infrastructure as code.

"Snyk was a pioneer in the developer-first security category," she adds. "It's very easy for developers to use while giving security teams visibility and control for setting policies and related functions."

The ServiceNow announcement is significant, Marks adds, given how many large enterprises use ServiceNow for IT service management. ServiceNow says it serves 80% of Fortune 500 companies and approximately 7,400 enterprise customers.

**Recent Security Moves**

Organizations are increasingly looking at how to efficiently make SBOMs, especially in light of software supply chain attacks, vulnerabilities such as Log4j, and government mandates. In November, Snyk released an update to make it easier to automatically generate SBOMs during the software build process. Snyk added a "developer-first" API and command-line interface (CLI) to create SBOMs, which the company says provides broader visibility into customers' complete software supply chains.

Snyk also released an SBOM Checker, a free tool that scans SBOMs for vulnerabilities. Snyk also has added Bomber Integration, which scans SBOMs with the open-source Bomber application, testing them against its open source Snyk Vulnerability Database.

In November, Snyk Cloud — the outgrowth of the company's acquisition of Fugue last year — went live. Snyk Cloud has a common policy engine designed to ensure organizations' cloud applications are secure before deploying them.

"Snyk Cloud will help you secure your cloud environment with common policies for infrastructure code and cloud deployments," Nair said during the November launch event. "Taking a code-centric approach to find and fix cloud issues is something that we were fundamentally focused on."

Snyk Gets Nod of Approval With ServiceNow Strategic Investment

Don't make perfect the enemy of good in vulnerability management. Context is key — prioritize vulnerabilities that are actually exploitable. Act quickly if the vulnerability is on a potential attack path to a critical asset.

The widespread vulnerability that first appeared in Apache Log4j in 2021 will continue to be exploited, potentially even in worse ways than we've seen to date. The more worrisome aspect of these threats is that there's a good chance they'll continue to be exploited months or years into the future.

The Department of Homeland Security's Cyber Safety Review board debuted in 2021, and in 2022 released its inaugural safety report (PDF). In it, the board called Log4j an "endemic vulnerability," chiefly because there isn't a comprehensive "customer list" for Log4j, making keeping up with vulnerabilities a near-impossible task. One federal Cabinet department even spent 33,000 hours on its Log4j response.

And many organizations and security solutions on the market fail to identify the difference between exploitability and vulnerability — leaving an opportunity for attackers to carry out malicious activity.

**Exploitability vs. Vulnerability**

One of the key issues with cybersecurity today is understanding the difference between vulnerabilities and their severity. When it comes to measuring exploitability versus a vulnerability, there's a big difference between whether a security threat is exploitable within your business or if it's just "vulnerable" and cannot hinder the business or reach a critical asset. Security teams spend too much time not understanding the difference between the two and fix each vulnerability as it comes, instead of prioritizing those that are exploitable.

Every company has thousands of common vulnerabilities and exposures (CVEs), many of which score high on the Common Vulnerability Scoring System (CVSS), so it's impossible to fix them all. To combat this, the hope is that risk-based vulnerability management (RBVM) tools will make prioritization easier by clarifying what is exploitable.

However, security prioritization approaches that combine CVSS scores with RBVM threat intel don't provide optimal results. Even after filtering and looking just at what is exploitable in the wild, security teams still have too much to handle because the list is long and unmanageable. And just because a CVE doesn't have an exploit today doesn't mean that it won't have one next week.

In response, companies have been adding predictive risk AI, which can help users understand if a CVE might be exploited in the future. This still isn't enough and leads to too many issues to fix. Thousands of vulnerabilities will still show to have an exploit, but many will have other sets of conditions that have to be met to actually exploit the problem.

For example, with Log4j, the following parameters need to be identified:

*   Does the vulnerable Log4j library exist?
*   Is it loaded by a running Java application?
*   Is the JNDI lookup enabled?
*   Is Java listening to remote connections, and is there a connection for other machines?

If the conditions and parameters aren't met, the vulnerability isn't critical and shouldn't be prioritized. And even if a vulnerability could be exploitable on a machine, so what? Is that machine extremely critical, or maybe it isn't connected to any critical or sensitive assets?

It's also possible the machine isn't important yet it can enable an attacker to continue toward critical assets in stealthier ways. In other words, context is key — is this vulnerability on a potential attack path to the critical asset? Is it enough to cut off a vulnerability at a chokepoint (an intersection of multiple attack paths) to stop the attack path from reaching a critical asset?

Security teams hate vulnerability processes and their solutions, because there are more and more vulnerabilities — nobody can ever fully wipe the slate clean. But if they can focus on what can create _damage_ to a critical asset, they can have a better understanding of where to start.

**Combating Log4j Vulnerabilities**

The good news is that proper vulnerability management can help reduce and fix the exposure to Log4j-centric attacks by identifying where the risk of potential exploitation exists.

Vulnerability management is an important aspect of cybersecurity and is necessary for ensuring the security and integrity of systems and data. However, it's not a perfect process and vulnerabilities can still be present in systems despite best efforts to identify and mitigate them. It's important to regularly review and update vulnerability management processes and strategies to ensure that they are effective and that vulnerabilities are being addressed in a timely manner.

The focus of vulnerability management should not only be on the vulnerabilities themselves, but also on the potential risk of exploitation. It is important to identify the points where an attacker may have gained access to the network, as well as the paths they may take to compromise critical assets. The most efficient and cost-effective way to mitigate the risks of a particular vulnerability is to identify the connections between vulnerabilities, misconfigurations, and user behavior that could be exploited by an attacker, and to proactively address these issues before the vulnerability is exploited. This can help to disrupt the attack and prevent damage to the system.

You should also do the following:

*   **Patch:** Identify all your products that are vulnerable to Log4j. This can be done manually or by using open source scanners. If a relevant patch is released for one of your vulnerable products, patch the system ASAP.
*   **Workaround:** On Log4j versions 2.10.0 and above, in the Java CMD line, set the following: log4j2.formatMsgNoLookups=true
*   **Block:** If possible, add a rule to your Web application firewall to block: "jndi:"

Perfect security is an unachievable feat, so there's no sense making perfect the enemy of good. Instead, focus on prioritizing and locking down potential attack paths that continuously improve security posture. Identifying and being realistic about what actually is vulnerable versus what is exploitable can help do this, since it will allow the ability to strategically funnel resources toward critical areas that matter the most.

Tag

#log4j