The document, titled “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations”, invites buyers and end users of digital hardware, software, and services to conduct due diligence on the origin and security of components of a digital/technology product.

Supply chain attacks have become one of the most dangerous hacking variants, as they allow threat actors to compromise multiple devices at once, in addition to exploiting vulnerabilities in widely used components. Just remember the SolarWinds attack, which impacted thousands of organizations worldwide.

For Ilkka Turunen, software supply chain security specialist at Sonatype, these measures are important to substantially improve the security of organizations: “This document outlines fundamental best practices, such as generating software bills of materials (SBOM), as well as describing the maintenance activities necessary to maintain effective security practices in the supply chain.”

The researcher adds that software risk mitigation begins with understanding how the use of managed and unmanaged software occurs in an organization, in addition to the progressive mitigation of those risks at the vendor level and with the constant participation of customers.

On the other hand, Cequence Security experts recently alerted the cybersecurity community about the persistence of attacks exploiting flaws such as Log4Shell, discovered a few months ago and that allows abusing the Apache Log4j login utility, considered omnipresent.

A new wave of attacks, identified as LoNg4j, demonstrates the interaction between modern enterprise IT infrastructure and the digital supply chain, spreading across all kinds of applications and creating a critical attack vector in case any vulnerability is exploited.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post NIST updates the Cybersecurity Supply Chain Risk Management Guidance (C-SCRM) in Response to Executive Order Signed by President Biden appeared first on Information Security Newspaper | Hacking News.

To prevent Log4Shell exploitation, AWS security teams released several hot patches, each suitable for a different environment, including servers, Kubernetes, Elastic Container Service (ECS), and Fargate. The first patch was included in an RPM or Debian package, an active patch daemonset for Kubernetes clusters and another included as a set of OCI hooks and intended for Bottlerocket hosts.

However, experts at Palo Alto Networks found that, after the hot patch was installed, any container on the server or cluster could exploit it to take control of the underlying host. In addition, any non-privilege process could exploit active patches to escalate privileges and execute code as root user.

According to the report: “After installing any of the patches, new containers can exploit the patch to escape and compromise its underlying host; on hosts that installed the Hot Patch service or the Hot Patch Daemonset, existing containers can also escape.”

To address JavaScript processes on the fly, solutions invoke certain binary containers; without the proper containerization process, the limitations that typically apply to container processes would not also apply to new processes.

A malicious container could have included a binary called ‘java’ to trick the installed solution, leading to invocation with elevated privileges. The malicious ‘java’ process could abuse its elevated privileges to escape the container and seize the underlying host.

In other words, these fixes treat unprivileged processes similarly, meaning that a malicious process without privileges could create a binary called “java” and abuse the hot patch service to elevate its privileges: “These bugs can be exploited regardless of container configuration, so even environments that allow isolation techniques are affected,” adds the report.

AWS has already fixed the issues with these patches, so customers are invited to install the fixes as soon as possible to mitigate the risk of exploitation.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post AWS patches to fix Log4j vulnerabilities could be exploited for privilege escalation or container escape attacks appeared first on Information Security Newspaper | Hacking News.

A Spring Cloud Function vulnerability tracked as CVE-2022-22963 was identified on Tuesday, with additional reports circulating online since then. Now known as Spring4Shell, the vulnerability only affects Spring applications running on Java 9 and above and is caused by insecure deserialization of past arguments.

A zero-day exploit was briefly leaked during Wednesday morning, though it was enough time for cybersecurity specialists to download the PoC code. This leak allowed confirming that the vulnerability exists, is exploitable and represents a severe security risk.

Researchers from the cybersecurity firm Praetorian also confirmed the existence of the vulnerability, although they specify that successful exploitation requires specific configurations previously established: “The attack requires an endpoint with DataBinder enabled, in addition it depends largely on the servlet container for the application,” mentions the company’s blog.

Experts also note that Spring is commonly used with Apache Tomcat, which means there is great potential for widespread exploitation. To make matters worse, multiple reports indicate that cases of active exploitation have already been detected.

Praetorian describes a way to mitigate the exploitation of Spring4Shell by defining spring core databinder functionality as “pattern-specific blocking.” As this vulnerability has not been addressed, it is strongly recommended that administrators using Spring applications implement these mitigations as soon as possible.

Given the characteristics of the attack, cybersecurity specialists recall the risk that was presented at the end of 2021 with the massive exploitation of Log4j servers after the discovery of a vulnerability known as Log4Shell. This vulnerability allowed hacking groups to install malware and deploy ransomware attacks against affected deployments.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post Exploitation code for the zero-day vulnerability in Spring Framework for Java applications is published. New Log4Shell flaw appeared first on Information Security Newspaper | Hacking News.

JFrog researchers mention that JNDI is an API that provides directory functionalities and names for Java applications, while H2 is an open-source Java SQL database widely used, primarily by Internet of Things (IoT) device manufacturers.

According to the report, this flaw was also detected in early December, discovering URLs controlled by threat actors to facilitate remote execution of unauthenticated code, allowing threat actors to take control over affected deployments.

Experts consider this to be the first critical flaw found since the finding of Log4Shell exploiting the same attack root but not being part of Log4j: “There are likely to be more packets affected by the same root cause as Log4Shell, accepting arbitrary JNDI search URLs. We have adjusted our automated vulnerability detection framework to account for the javax.naming.Context.lookup function as a dangerous function and released the framework in the Maven repository to find issues similar to Log4Shell2,” the researchers report.

The H2 database package was one of the first to be validated and reported to its developers, who immediately released a new version, available on GitHub. Experts add that several code paths in the H2 database framework pass unfiltered in attacker-controlled URLs to the javax.naming.Context.lookup function, which would allow remote loading of the code base.

In the report, H2 database users are asked to upgrade their deployments to the latest version available: “If you are running an H2 console that is exposed to your LAN, this issue is extremely critical and you should upgrade your H2 database to version 2.0.206 immediately,” JFrog adds.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post New critical vulnerability similar to log4j discovered in Java applications with H2 databases appeared first on Information Security Newspaper | Hacking News.

This report was published by Blumira researchers, who say that this behavior dismisses the idea that Log4Shell faults were only exploitable remotely: “This means that anyone with a vulnerable version of Log4j can be exploited through a listening server path on their machine or on the local network when navigating to a vulnerable website,”  experts point out.

In other words, there is more malicious potential for exploit development and successful attacks: “New attack vectors include everything from malvertising to creating watering holes for drive-by attacks,” says Matthew Warner, a researcher at Blumira.

WebSockets allows communication between a web browser and web applications, such as chats and alerts on websites. While it allows the browser to quickly send data back and forth to these types of applications, it can also be used for system detail logging and port scanning, so in itself it poses a security risk.

Experts mention that in the case of Log4j, threat actors could make malicious requests via WebSockets to a local host or a vulnerable local network server, so hackers don’t have to target an exposed target on the network.

To make matters worse, this attack could be considered even stealthier than its remote counterparts, as the researchers mention that it can be difficult to get a complete security approach to WebSocket connections within a host, increasing the complexity to detect the attack.

To detect a potential attack, Warner recommends looking for instances of “.*/java.exe” which is used as the primary process for “cmd.exe/powershell.exe”, which can be considered the most accurate indicators of compromise.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post New Log4j attack allows hacking devices that are not exposed to internet via localhost appeared first on Information Security Newspaper | Hacking News.

Tracked as CVE-2021-44228 and dubbed Log4Shell, this flaw would allow threat actors to send a snippet of malicious code that registers in Log4j v2.0 and earlier, allowing full access to the affected system and the ability to execute code remotely.

While online deployment managers and software developers continue to grapple with this flaw, cybersecurity specialists report the detection of two new vulnerabilities associated with this utility that could put millions of deployments around the world at risk.

Incomplete patches

According to a report by Cyber Kendra, on Tuesday the finding of CVE-2021-45046 was confirmed, an error derived from the incorrect implementation of a patch to address the previous flaw, specifically in the correction of errors in certain non-default configurations.

In more detail, the researchers mention that mitigating the previous flaw required upgrading to the latest available version of Log4j (v2.15); however, this update still left thousands of systems vulnerable to remote code execution (RCE) attacks if only the noMsgFormatLookups flag was enabled or if %m{nolookups} was configured when setting data to ThreadContext with attacker-controlled data.

Threat actors with control over thread context map (MDC) input data when registry settings use a non-default pattern layout with a context lookup or thread context map pattern could create malicious input data using a JNDI search pattern, resulting in a denial of service (DoS) condition.

Fully fixing this flaw requires updating Log4j to v2.16.0.

A third flaw appears

On the other hand, this week researchers from the security firm Praetorian revealed the detection of a third vulnerability in Log4j v2.15.0 whose exploitation would allow threat actors to extract sensitive data in certain circumstances.

The researchers did not share great technical details about the flaw, but say that their findings have already been presented to the Apache Foundation, so they recommend users of affected implementations to upgrade to v2.16.0 as soon as possible, although it is not known with certainty if this version is immune to the exploitation of this new vulnerability, which has not received CVE tracking key.

This week, CloudFlare and Microsoft detected multiple threat actors exploiting Log4Shell flaws for various purposes, although one of the hacking campaigns that most caught the attention of the cybersecurity community was detected by Bitdefender, whose researchers discovered that a hacking group was exploiting this flaw to infect affected systems with Khonsari ransomware.

Since the emergence of these dangerous flaws, researchers have been trying to find the best possible mitigation methods, plus Log4j developers have been in constant communication with users to keep them abreast of any new security risks related to Log4Shell.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post Details of CVE-2021-44228 & CVE-2021-45046, the two new Log4j vulnerabilities affecting millions of devices appeared first on Information Security Newspaper | Hacking News.

While the vulnerability has already been addressed, since it was first reported hundreds of developers expressed doubts about Log4j and how to check its installation on a given system.

Although some developers assume that, being a Java library, if the administrator does not use Java applications his system cannot have Log4j installed. However, cybersecurity experts mention that applications can include their own JRE, so it is not necessary to have installed Java for Java applications to run on the system.

Through Stack Exchange, a developer shared a script that can help other users identify the Log4j installation on a system:

Subsequently, the command shown below is executed:

Additional comments are available on GitHub.

The researcher who initially reported the flaw in Log4j also mentions that it is only possible to exploit CVE-2021-44228 if the log4j2.formatMsgNoLookups option in the library settings is set to false. The most recent reports on this issue indicate that the latest version of the affected library keeps this setting set to true, which definitely prevents any attempt at exploitation.

However, threat actors are still looking for vulnerable deployments, so administrators should manually set the feature to true before their systems are affected.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post How to check if you have Log4j installed on your servers? Fix the vulnerability in seconds by setting the log4j2.formatMsgNoLookups variable to true appeared first on Information Security Newspaper | Hacking News.